Re: GTKD - addOnButtonPress faulty?
On Thursday, 23 June 2016 at 22:00:18 UTC, Mike Wey wrote: addOnPressed is deprecated addOnButtonPress is not. Ah, okay. I changed the event type to addOnButtonRelease and it works fine now, i don't know if it's just me or if addOnButtonPress behaves a little bit strange.
Re: Get calling this, if exists
On Friday, 24 June 2016 at 03:10:51 UTC, Mike Parker wrote:
Oh, perhaps I misunderstood your question. Do you meant this:
class Foo() {
void bar() { Log(); } // Pass reference to Foo instance
}
void doSomething() { Log(); } // Null reference
If so, the answer is no. And I don't see how that could work as
a compile time parameter, given that the reference itself is a
runtime value.
It actually is possible. You just have to be explicit.
void log(alias self)(string s)
{
pragma(msg, self.stringof);
}
struct Test
{
void test(string s)
{
log!this(s);
}
}
void main()
{
Test t;
t.test("asdf");
}
Re: Get calling this, if exists
On Friday, 24 June 2016 at 03:04:25 UTC, Mike Parker wrote:
On Friday, 24 June 2016 at 02:57:28 UTC, "Smoke" Adams wrote:
Is there a type of __THIS__ construct similar to __FILE__ and
__LINE__?
Something that returns the current this ptr if it exists, null
otherwise.
Log(string filename = __FILE__, Object obj = __THIS__)()
{
// inspect obj and do stuff
}
There is no 'this' pointer unless you are calling a member
function on an aggregate, so you can never have one that is
null.
Oh, perhaps I misunderstood your question. Do you meant this:
class Foo() {
void bar() { Log(); } // Pass reference to Foo instance
}
void doSomething() { Log(); } // Null reference
If so, the answer is no. And I don't see how that could work as a
compile time parameter, given that the reference itself is a
runtime value.
Re: Get calling this, if exists
On Friday, 24 June 2016 at 02:57:28 UTC, "Smoke" Adams wrote:
Is there a type of __THIS__ construct similar to __FILE__ and
__LINE__?
Something that returns the current this ptr if it exists, null
otherwise.
Log(string filename = __FILE__, Object obj = __THIS__)()
{
// inspect obj and do stuff
}
There is no 'this' pointer unless you are calling a member
function on an aggregate, so you can never have one that is null.
Get calling this, if exists
Is there a type of __THIS__ construct similar to __FILE__ and
__LINE__?
Something that returns the current this ptr if it exists, null
otherwise.
Log(string filename = __FILE__, Object obj = __THIS__)()
{
// inspect obj and do stuff
}
Re: Shorthand for defining numeric literals as size_t and ptrdiff_t
On 6/23/16 6:22 PM, pineapple wrote: There are suffixes for numbers like 0L, 0u, 0f, 0d, etc. What about suffixes representing size_t and ptrdiff_t? Do they exist? If not, why? They do not exist, because the types themselves are not compiler-builtin, they are aliases to the appropriate integer types. But you can use constructor syntax: size_t(0) ptrdiff_t(0) -Steve
Shorthand for defining numeric literals as size_t and ptrdiff_t
There are suffixes for numbers like 0L, 0u, 0f, 0d, etc. What about suffixes representing size_t and ptrdiff_t? Do they exist? If not, why?
Re: GTKD - addOnButtonPress faulty?
On 06/23/2016 10:30 AM, TheDGuy wrote:
Hi,
sorry for my next thread but i did encounter a strange behaviour of the
"Button.addOnButtnPress" - Event. Sometimes if i click very fast on the
GTKD button, it reacts twice! I am working on a small game and i noticed
that if i click slowly everything works as expected but sometimes i have
to click a button more than once and if i do it very fast it is often
recognized as 3 clicks. I did it like this:
I'm not sure about this one, but when you click the button more than
once the event is also called more than once.
Button btn_1 = new Button();
auto call1 = &btn1ClickedEvent;
btn_1.addOnButtonPress(call1);
bool btn1ClickedEvent(Event e, Widget widget){
userInput ~= 1;
checkForWin();
return true;
}
So is it my bad code or was it recognized by others as well? I know that
GTKD claims that this method is deprecated but i didn't find anything
else that works.
addOnPressed is deprecated addOnButtonPress is not.
--
Mike Wey
Re: Real implicitly converts to float?
On 06/23/2016 06:57 AM, Steven Schveighoffer wrote:
> On 6/23/16 5:37 AM, Jonathan M Davis via Digitalmars-d-learn wrote:
>> On Thursday, June 23, 2016 04:55:09 Tofu Ninja via Digitalmars-d-learn
>> wrote:
>
>>> Should I make a bug report? I am not sure it's a bug, seems
>>> intentional. Maybe a dip for a compiler flag to warn on implicit
>>> down conversions, but it would be a pretty small dip.
>
> It's not a bug. Floating point is in general an approximation, so it's
> not expected to accurately capture the value. It's not the same as a
> narrowing conversion.
>
> For instance:
>
> int x = 1_000_000;
> byte b = cast(byte)x;
> assert(b == 64);
>
> 64 is nowhere near 1 million.
>
> However:
>
> double x = 1_000_000_000_000_000;
> float f = x;
> assert(f == 999_999_986_991_104);
But there is also the representable value range. The difference between
the maximum values are worse in the case of floating point types.
void main() {
pragma(msg, long.max / byte.max);
pragma(msg, real.max / float.max);
}
72624976668147841L
3.49631e+4893L
So it's more nowhere near for floating point types from that point of
view: :)
Ali
Re: Real implicitly converts to float?
On 6/23/16 11:41 AM, Tofu Ninja wrote: On Thursday, 23 June 2016 at 15:25:49 UTC, Steven Schveighoffer wrote: I disagree. I've used languages where converting floating point types is not implicit, and it's painful. Most of the time, the loss in precision isn't important. Which is why a flag would be nice, for some applications the precision matters, for some it doesn't. You can attempt to make a wrapper that prevents the conversion, probably the best that can be had. -Steve
Re: How to use a char[] buffer in D
On Thu, Jun 23, 2016 at 08:36:57AM -0700, H. S. Teoh via Digitalmars-d-learn
wrote:
> On Thu, Jun 23, 2016 at 10:00:33AM -0400, Steven Schveighoffer via
> Digitalmars-d-learn wrote:
[...]
> > > On Wednesday, 22 June 2016 at 22:41:24 UTC, H. S. Teoh wrote:
[...]
> > > > Maybe try:
> > > >
> > > > if (buffer[] in myHash) { ... }
> > > >
> > > > ? Does that make a difference?
> > > >
> > > >
> > > > T
> > >
> > >
> >
> > This seems like a bug in the runtime, or am I missing something?
> [...]
>
> It might well be a bug. I'll take a look.
[...]
It is indeed a bug. It's caused by the AA implementation receiving a
static char array when it's expecting a string (immutable(char)[])
according to the declared key type of the AA.
Filed a bug for this:
https://issues.dlang.org/show_bug.cgi?id=16199
The compiler should either reject indexing an AA with a char[n], or it
should automatically slice the char[n] so that the AA implementation
gets the correct type in the key argument.
T
--
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N
Re: Real implicitly converts to float?
On Thursday, 23 June 2016 at 15:25:49 UTC, Steven Schveighoffer wrote: I disagree. I've used languages where converting floating point types is not implicit, and it's painful. Most of the time, the loss in precision isn't important. -Steve Which is why a flag would be nice, for some applications the precision matters, for some it doesn't.
Re: How to use a char[] buffer in D
On Thu, Jun 23, 2016 at 10:00:33AM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 6/23/16 1:59 AM, Andrew Chapman wrote:
> > Perfect, thank you! :-) Works like a charm.
> >
> > On Wednesday, 22 June 2016 at 22:41:24 UTC, H. S. Teoh wrote:
> > > On Wed, Jun 22, 2016 at 09:57:04PM +, Andrew Chapman via
> > > Digitalmars-d-learn wrote:
> >
> > > Maybe try:
> > >
> > > if (buffer[] in myHash) { ... }
> > >
> > > ? Does that make a difference?
> > >
> > >
> > > T
> >
> >
>
> This seems like a bug in the runtime, or am I missing something?
[...]
It might well be a bug. I'll take a look.
T
--
Genius may have its limitations, but stupidity is not thus handicapped. --
Elbert Hubbard
Re: Real implicitly converts to float?
On 6/23/16 11:16 AM, Tofu Ninja wrote: On Thursday, 23 June 2016 at 13:57:57 UTC, Steven Schveighoffer wrote: Whenever you work with floating point, the loss of precision must be expected -- a finite type cannot represent an infinite precision number. The loss in precision should still be a warning. If I am using reals then I obviously needed a certain level of precision, I don't want to accidentally lose that precision somewhere because the compiler decided it was not important enough to warn me about it. I disagree. I've used languages where converting floating point types is not implicit, and it's painful. Most of the time, the loss in precision isn't important. -Steve
Re: Real implicitly converts to float?
On Thursday, 23 June 2016 at 13:57:57 UTC, Steven Schveighoffer wrote: Whenever you work with floating point, the loss of precision must be expected -- a finite type cannot represent an infinite precision number. The loss in precision should still be a warning. If I am using reals then I obviously needed a certain level of precision, I don't want to accidentally lose that precision somewhere because the compiler decided it was not important enough to warn me about it.
Re: How to use a char[] buffer in D
On 6/23/16 1:59 AM, Andrew Chapman wrote:
Perfect, thank you! :-) Works like a charm.
On Wednesday, 22 June 2016 at 22:41:24 UTC, H. S. Teoh wrote:
On Wed, Jun 22, 2016 at 09:57:04PM +, Andrew Chapman via
Digitalmars-d-learn wrote:
Maybe try:
if (buffer[] in myHash) { ... }
? Does that make a difference?
T
This seems like a bug in the runtime, or am I missing something?
-Steve
Re: Real implicitly converts to float?
On 6/23/16 5:37 AM, Jonathan M Davis via Digitalmars-d-learn wrote: On Thursday, June 23, 2016 04:55:09 Tofu Ninja via Digitalmars-d-learn wrote: Should I make a bug report? I am not sure it's a bug, seems intentional. Maybe a dip for a compiler flag to warn on implicit down conversions, but it would be a pretty small dip. It's not a bug. Floating point is in general an approximation, so it's not expected to accurately capture the value. It's not the same as a narrowing conversion. For instance: int x = 1_000_000; byte b = cast(byte)x; assert(b == 64); 64 is nowhere near 1 million. However: double x = 1_000_000_000_000_000; float f = x; assert(f == 999_999_986_991_104); Now, f and x aren't equal, but they are very close. Much more accurate than 64 and 1 million. Whenever you work with floating point, the loss of precision must be expected -- a finite type cannot represent an infinite precision number. You're original code is almost certainly not a bug thanks to VRP No, VRP only works on the current expression (statement maybe?). The compiler does not examine previous lines to see what the range of a particular variable should be. For example, this is an error: int x = 10; byte b = x; // error This isn't: int x; byte b = x = 10; -Steve
Re: Access vialotion
On 6/22/16 9:00 AM, Moro Greenhand wrote:
On Wednesday, 22 June 2016 at 12:47:31 UTC, TheDGuy wrote:
On Wednesday, 22 June 2016 at 12:45:29 UTC, TheDGuy wrote:
I have an array of buttons:
class Window : MainWindow{
private Button[4] bArr;
this(){
Button btn_1 = new Button();
Button btn_2 = new Button();
Button btn_3 = new Button();
Button btn_4 = new Button();
Button[4] bArr = [btn_1,btn_2,btn_3,btn_4];
}
private void letButtonsFlash(){
for(int i = 0; i < 4; i++){
writeln(this.bArr[i].getName());
}
}
}
i don't understand why i get an 'Access Violation' - Error in the
'for'-loop?
Okay, i solved it, instead of:
Button[4] bArr = [btn_1,btn_2,btn_3,btn_4];
this:
bArr = [btn_1,btn_2,btn_3,btn_4];
I would expect DMD to output a warning here, because of the
shadowing...but after 3 verifications, nothing. Dscanner does.
Variable shadowing only is reported by the compiler for function locals.
That is, variables cannot shadow other variables from the same function.
It allows shadowing of variables outside the function. This is
deliberate. Otherwise, someone may name a variable somewhere else the
same as yours, and your perfectly working code is now flagged as an error.
-Steve
Re: How to use a char[] buffer in D
On Thursday, 23 June 2016 at 05:59:10 UTC, Andrew Chapman wrote:
Perfect, thank you! :-) Works like a charm.
On Wednesday, 22 June 2016 at 22:41:24 UTC, H. S. Teoh wrote:
On Wed, Jun 22, 2016 at 09:57:04PM +, Andrew Chapman via
Digitalmars-d-learn wrote:
Maybe try:
if (buffer[] in myHash) { ... }
? Does that make a difference?
T
If the keys are fixed-length, you may want to consider using
immutable(char[4]) as key. That way there is no GC allocation for
the strings at all, the only allocations are done by the AA.
Re: Real implicitly converts to float?
On Thursday, June 23, 2016 04:55:09 Tofu Ninja via Digitalmars-d-learn wrote: > On Wednesday, 22 June 2016 at 14:17:42 UTC, Jonathan M Davis > > wrote: > > Well, that particular value should probably work thanks to VRP > > (value range propagation), since 10 can fit into float with no > > loss of precision. However, what's far more disconcerting is > > that > > > > real x = real.max; > > float y = x; > > > > compiles. real to float is a narrowing conversion, which should > > be an error barring the compiler detecting that the value will > > fit in the target type even if it's a narrowing conversion > > (which only happens with VRP). That's not the sort of thing > > that I would have expected to be broken such that it begs the > > question as to whether it's intentional, but given that > > narrowing conversions without a cast are illegal everywhere > > else, this definitely seems broken. > > > > - Jonathan M Davis > > Should I make a bug report? I am not sure it's a bug, seems > intentional. Maybe a dip for a compiler flag to warn on implicit > down conversions, but it would be a pretty small dip. You're original code is almost certainly not a bug thanks to VRP, but I would think that the example with real.max would be. So, it makes sense to me to report it. Worst case, it gets closed as invalid. I certainly wouldn't suggest a DIP for it at this point. If the bug were closed as invalid, then then a DIP might make sense (though if it were intentional, then I question that we could get Walter to change it), but I'd treat it as a bug first. - Jonathan M Davis
GTKD - addOnButtonPress faulty?
Hi,
sorry for my next thread but i did encounter a strange behaviour
of the "Button.addOnButtnPress" - Event. Sometimes if i click
very fast on the GTKD button, it reacts twice! I am working on a
small game and i noticed that if i click slowly everything works
as expected but sometimes i have to click a button more than once
and if i do it very fast it is often recognized as 3 clicks. I
did it like this:
Button btn_1 = new Button();
auto call1 = &btn1ClickedEvent;
btn_1.addOnButtonPress(call1);
bool btn1ClickedEvent(Event e, Widget widget){
userInput ~= 1;
checkForWin();
return true;
}
So is it my bad code or was it recognized by others as well? I
know that GTKD claims that this method is deprecated but i didn't
find anything else that works.
