Re: Constructor template -- bug?
On 2011-03-02 08:47, Jonathan M Davis wrote: On Tuesday 01 March 2011 23:43:27 Jonathan M Davis wrote: On Tuesday 01 March 2011 22:18:49 Bekenn wrote: Code: class MyException : Exception { this(string message, string file, size_t line, Throwable next = null) { super(message, file, line, next); } this(string file = __FILE__, size_t line = __LINE__)(string message, Throwable next = null) { this(message, file, line, next); } } void main() { throw new MyException("Bluh!"); } Error message: test.d(8): Error: template test.MyException.__ctor(string file = __FILE__,size_t line = __LINE__) conflicts with constructor test.MyException.this at test.d(3) If I remove the normal constructor and call super instead of this from the constructor template, then I get this slightly different error message: test.d(1): Error: constructor test.MyException.this conflicts with template test.MyException.__ctor(string file = __FILE__,uint line = __LINE__) at test.d(3) Is this a compiler bug, or am I Doing It Wrong? You cannot currently templatize class constructors: http://d.puremagic.com/issues/show_bug.cgi?id=435 And currently if one overload of a function is templatized, _all_ overloads of that function must templatized: http://d.puremagic.com/issues/show_bug.cgi?id=2972 http://d.puremagic.com/issues/show_bug.cgi?id=4749 I should also point out that there is absolutely no need to use template for what you're trying to do. Just declare the constructor like so: this(string message, string file = __FILE__, size_t line = __LINE__ Throwable next = null) { ... } - Jonathan M Davis I guess the reason why he would do that is to catch the file and line number where the constructor is called. -- /Jacob Carlborg
Re: Constructor template -- bug?
On Tuesday 01 March 2011 23:43:27 Jonathan M Davis wrote: > On Tuesday 01 March 2011 22:18:49 Bekenn wrote: > > Code: > > class MyException : Exception > > { > > > > this(string message, string file, size_t line, Throwable next = > > null) > > { > > > > super(message, file, line, next); > > > > } > > > > this(string file = __FILE__, size_t line = __LINE__)(string > > message, > > > > Throwable next = null) > > > > { > > > > this(message, file, line, next); > > > > } > > > > } > > > > void main() > > { > > > > throw new MyException("Bluh!"); > > > > } > > > > Error message: > > test.d(8): Error: template test.MyException.__ctor(string file = > > > > __FILE__,size_t line = __LINE__) conflicts with constructor > > test.MyException.this at test.d(3) > > > > If I remove the normal constructor and call super instead of this from > > > > the constructor template, then I get this slightly different error message: > > test.d(1): Error: constructor test.MyException.this conflicts with > > > > template test.MyException.__ctor(string file = __FILE__,uint line = > > __LINE__) at test.d(3) > > > > Is this a compiler bug, or am I Doing It Wrong? > > You cannot currently templatize class constructors: > > http://d.puremagic.com/issues/show_bug.cgi?id=435 > > And currently if one overload of a function is templatized, _all_ overloads > of that function must templatized: > > http://d.puremagic.com/issues/show_bug.cgi?id=2972 > http://d.puremagic.com/issues/show_bug.cgi?id=4749 I should also point out that there is absolutely no need to use template for what you're trying to do. Just declare the constructor like so: this(string message, string file = __FILE__, size_t line = __LINE__ Throwable next = null) { ... } - Jonathan M Davis
Re: Constructor template -- bug?
On Tuesday 01 March 2011 22:18:49 Bekenn wrote: > Code: > > class MyException : Exception > { > this(string message, string file, size_t line, Throwable next = > null) > { > super(message, file, line, next); > } > > this(string file = __FILE__, size_t line = __LINE__)(string > message, > Throwable next = null) > { > this(message, file, line, next); > } > } > > void main() > { > throw new MyException("Bluh!"); > } > > Error message: > > test.d(8): Error: template test.MyException.__ctor(string file = > __FILE__,size_t line = __LINE__) conflicts with constructor > test.MyException.this at test.d(3) > > If I remove the normal constructor and call super instead of this from > the constructor template, then I get this slightly different error message: > > test.d(1): Error: constructor test.MyException.this conflicts with > template test.MyException.__ctor(string file = __FILE__,uint line = > __LINE__) at test.d(3) > > Is this a compiler bug, or am I Doing It Wrong? You cannot currently templatize class constructors: http://d.puremagic.com/issues/show_bug.cgi?id=435 And currently if one overload of a function is templatized, _all_ overloads of that function must templatized: http://d.puremagic.com/issues/show_bug.cgi?id=2972 http://d.puremagic.com/issues/show_bug.cgi?id=4749 - Jonathan M Davis
Constructor template -- bug?
Code: class MyException : Exception { this(string message, string file, size_t line, Throwable next = null) { super(message, file, line, next); } this(string file = __FILE__, size_t line = __LINE__)(string message, Throwable next = null) { this(message, file, line, next); } } void main() { throw new MyException("Bluh!"); } Error message: test.d(8): Error: template test.MyException.__ctor(string file = __FILE__,size_t line = __LINE__) conflicts with constructor test.MyException.this at test.d(3) If I remove the normal constructor and call super instead of this from the constructor template, then I get this slightly different error message: test.d(1): Error: constructor test.MyException.this conflicts with template test.MyException.__ctor(string file = __FILE__,uint line = __LINE__) at test.d(3) Is this a compiler bug, or am I Doing It Wrong?
Re: comparing pointers passed to and returned from funcs
On 3/1/2011 4:12 PM, bearophile wrote: Bekenn: I'd remove those parens; you don't want people modifying TRUE or FALSE. Please, show me working code that implements your idea :-) Bye, bearophile Here you go; I only changed the one line. Compiles and works just fine in dmd 2.051. const Foo* TRUE, FALSE; instead of const(Foo)* TRUE, FALSE;
Re: About const and C functions
On 3/1/2011 2:33 PM, bearophile wrote: Do you know why DMD doesn't give a compilation error here? import core.stdc.stdio: sscanf; immutable int value = 5; void main() { sscanf("10".ptr, "%d".ptr,&value); } Bye, bearophile I'm not sure that's checkable. I think this falls squarely into the realm of "undefined behavior".
Re: comparing pointers passed to and returned from funcs
On 3/1/11 5:31 PM, bearophile wrote: Bekenn: Touche. I'll have to test that out once I get back from work... Sorry for that answer of mine, we are here to learn and cooperate, not to fight :-) It's just I sometimes have problems with const things in D, and sometimes DMD has problems with const things. Hey, no problem; I thought it was funny...
Re: comparing pointers passed to and returned from funcs
Bekenn: > Touche. I'll have to test that out once I get back from work... Sorry for that answer of mine, we are here to learn and cooperate, not to fight :-) It's just I sometimes have problems with const things in D, and sometimes DMD has problems with const things. Bye, bearophile
Can't figure out segfault
I put together bindings for DevIL in D to use on a school assignment. The bindings (attached) work fine on Windows, but cause a segfault on Linux when I call ilInit. this can be demonstrated by a little test program " import graphics.bindings.devil; public void main(string[] args) { ilInit(); } " compiled with "dmd -L-ldl test.d devil.d" where test.d is the above program and devil.d is attached. When run, this program segfaults, but if lines 112,113,165,166 of devil.d are commented out, the program works fine, and I can't figure out what the problem with those lines is. The fact that this works on Windows confuses me even more. Any help would be appreciated. begin 644 devil.d M;6]D=6QE(&=R87!H:6-S+F)I;F1I;F=S+F1E=FEL.PH*:6UP;W)T('-T9"YS M=')I;F<["@IV97)S:6]N*%=I;F1O=W,I"GL*"6EM<&]R="!S=&0N8RYW:6YD M;W=S+G=I;F1O=W,["GT*96QS92!V97)S:6]N*&QI;G5X*0I["@EI;7!O#$Y,#`["G!U8FQI8R!I;6UU=&%B;&4@=6EN="!)3%]#3TQ/ M4E])3D1%6"`@("`@(#T@,'@Q.3`P.PIP=6)L:6,@:6UM=71A8FQE('5I;G0@ M24Q?04Q02$$)"0D@(#T@,'@Q.3`V.PIP=6)L:6,@:6UM=71A8FQE('5I;G0@ M24Q?4D="("`@("`@("`@("`@("`](#!X,3DP-SL*<'5B;&EC(&EM;75T86)L M92!U:6YT($E,7U)'0D$@("`@("`@("`@("`@/2`P>#$Y,#@["G!U8FQI8R!I M;6UU=&%B;&4@=6EN="!)3%]"1U(@("`@("`@("`@("`@(#T@,'@X,$4P.PIP M=6)L:6,@:6UM=71A8FQE('5I;G0@24Q?0D=202`@("`@("`@("`@("`](#!X M.#!%,3L*<'5B;&EC(&EM;75T86)L92!U:6YT($E,7TQ534E.04Y#12`@("`@ M("`@/2`P>#$Y,#D["G!U8FQI8R!I;6UU=&%B;&4@=6EN="!)3%],54U)3D%. M0T5?04Q02$$@(#T@,'@Q.3!!.PH*<'5B;&EC(&EM;75T86)L92!U:6YT($E, M7T)95$4@("`@("`@("`@(#T@,'@Q-#`P.PIP=6)L:6,@:6UM=71A8FQE('5I M;G0@24Q?54Y324=.141?0EE412`@/2`P>#$T,#$["G!U8FQI8R!I;6UU=&%B M;&4@=6EN="!)3%]32$]25"`@("`@("`@("`](#!X,30P,CL*<'5B;&EC(&EM M;75T86)L92!U:6YT($E,7U5.4TE'3D5$7U-(3U)4(#T@,'@Q-#`S.PIP=6)L M:6,@:6UM=71A8FQE('5I;G0@24Q?24Y4("`@("`@("`@("`@/2`P>#$T,#0[ M"G!U8FQI8R!I;6UU=&%B;&4@=6EN="!)3%]53E-)1TY%1%])3E0@("`](#!X M,30P-3L*<'5B;&EC(&EM;75T86)L92!U:6YT($E,7T9,3T%4("`@("`@("`@ M(#T@,'@Q-#`V.PIP=6)L:6,@:6UM=71A8FQE('5I;G0@24Q?1$]50DQ%("`@ M("`@("`@/2`P>#$T,$$["G!U8FQI8R!I;6UU=&%B;&4@=6EN="!)3%](04Q& M("`@("`@("`@("`](#!X,30P0CL*"B\O26UA9V4@5'EP97,*<'5B;&EC(&EM M;75T86)L92!U:6YT($E,7U194$5?54Y+3D]73B`](#!X,#`P,#L*<'5B;&EC M(&EM;75T86)L92!U:6YT($E,7T)-4"`@("`@("`@("`](#!X,#0R,#L@("\O M(3P@36EC'1E;G-I;VX* M<'5B;&EC(&EM;75T86)L92!U:6YT($E,7T-55"`@("`@("`@("`](#!X,#0R M,3L@("\O(3P@1'(N($AA;&\@+2`N8W5T(&5X=&5N#`T,C,[("`O+R$\($1O M;TT@9FQA=',@+2!N;R!S<&5C:69I8R!E>'1E;G-I;VX*<'5B;&EC(&EM;75T M86)L92!U:6YT($E,7TE#3R`@("`@("`@("`](#!X,#0R-#L@("\O(3P@36EC M'1E;G-I;VX*<'5B;&EC M(&EM;75T86)L92!U:6YT($E,7U!#6"`@("`@("`@("`](#!X,#0R.#L@("\O M(3P@6E-O9G0@4$-8("T@+G!C>"!E>'1E;G-I;VX*<'5B;&EC(&EM;75T86)L M92!U:6YT($E,7U!)0R`@("`@("`@("`](#!X,#0R.3L@("\O(3P@4$E#("T@ M+G!I8R!E>'1E;G-I;VX*<'5B;&EC(&EM;75T86)L92!U:6YT($E,7U!.1R`@ M("`@("`@("`](#!X,#0R03L@("\O(3P@4&]R=&%B;&4@3F5T=V]R:R!'#`T,D([("`O+R$\(%!O2!- M87`@+2`N<&)M+"`N<&=M+"`N<'!M(&%N9"`N<&YM(&5X=&5N6QE($AE861E2!E>'1E;G-I M;VX*<'5B;&EC(&EM;75T86)L92!U:6YT($E,7TU$3"`@("`@("`@("`](#!X M,#0S,3L@("\O(3P@2&%L9BU,:69E($UO9&5L(%1E>'1U'1U#`T,S4[("`O+R$\($UU;'1I<&QE+6EM86=E($YE='=O'1E;G-I;VX*<'5B;&EC(&EM M;75T86)L92!U:6YT($E,7T1$4R`@("`@("`@("`](#!X,#0S-SL@("\O(3P@ M1&ER96-T1')A=R!3=7)F86-E("T@+F1D'1E;G-I;VX*<'5B;&EC(&EM M;75T86)L92!U:6YT($E,7T1#6"`@("`@("`@("`](#!X,#0S.#L@("\O(3P@ M6E-O9G0@375L=&DM4$-8("T@+F1C>"!E>'1E;G-I;VX*<'5B;&EC(&EM;75T M86)L92!U:6YT($E,7U!31"`@("`@("`@("`](#!X,#0S.3L@("\O(3P@061O M8F4@4&AO=&]3:&]P("T@+G!S9"!E>'1E;G-I;VX*<'5B;&EC(&EM;75T86)L M92!U:6YT($E,7T58248@("`@("`@("`](#!X,#0S03L@("\O(3P@"G!U8FQI M8R!I;6UU=&%B;&4@=6EN="!)3%]04U`@("`@("`@("`@/2`P>#`T,T([("`O M+R$\(%!A:6YT4VAO<"!0'(@97AT M96YS:6]N"G!U8FQI8R!I;6UU=&%B;&4@=6EN="!)3%]84$T@("`@("`@("`@ M/2`P>#`T,T4[("`O+R$\(%@@4&EX96P@36%P("T@+GAP;2!E>'1E;G-I;VX* M<'5B;&EC(&EM;75T86)L92!U:6YT($E,7TA$4B`@("`@("`@("`](#!X,#0S M1CL@("\O(3P@4F%D:6%N8V4@2&EG:"!$>6YA;6EC(%)A;F=E("T@+FAD'1E;G-I;VX*<'5B;&EC(&EM;75T86)L92!U:6YT($E,7TE#3E,)"0D](#!X M,#0T,#L@("\O(3P@36%C:6YT;W-H($EC;VX@+2`N:6-N'1E;G-I;VX* M<'5B;&EC(&EM;75T86)L92!U:6YT($E,7TI0,@D)"3T@,'@P-#0Q.R`@+R\A M/"!*<&5G(#(P,#`@+2`N:G`R(&5X=&5N#`T-#([("`O+R$\($]P96Y%6%(@+2`N97AR M(&5X=&5N#`T-#,[("`O+R$\($UI8W)O'1E;G-I;VX* M<'5B;&EC(&EM;75T86)L92!U:6YT($E,7U-53@D)"3T@,'@P-#0V.R`@+R\A M/"!3=6X@4F%S=&5R("T@+G-U;BP@+G)A#`T-#<[("`O+R$\($EN=&5R8VAA;F=E($9I;&4@ M1F]R;6%T("T@+FEF9B!E>'1E;G-I;VX*<'5B;&EC(&EM;75T86)L92!U:6YT M($E,7U103`D)"3T@,'@P-#0X.R`@+R\A/"!'86UE8W5B92!497AT=7)E("T@ M+G1P;"!E>'1E;G-I;VX*<'5B;&EC(&EM;75T86)L92!U:6YT($E,7T9)5%,) M"0D](#!X,#0T.3L@("\O(3P@1FQE>&EB;&4@26UA9V4@5')A;G-P;W)T(%-Y MGIA M#`T-$0[("`O+R$\($AE879Y($UE M=&%L.B!&04M+,B!497AT=7)E("T@+F9T>"!E>'1E;G-I;VX*<'5B;&EC(&EM M;75T86)L92!U:6YT($E,7U)/5`D)"3T@,'@P-#1%.R`@+R\A/"!(;VUE=V]R M;&0@,B`M(%)E;&EC(%1E>'1U#`T-$8[("`O+R$\($UE M9&EE=F%L($E).B!4;W1A;"!787(@5&5X='5R92`M("YT97AT=7)E(&5X=&5N M#`T-3`[ M("`O+R$\($1I9VET86P@4&EC='5R92!%>&-H86YG92`M("YD<'@@97AT96YS M:6]N"G!U8FQI8R!I;6UU=&%B;&4@=6EN="!)3%]55%@)"0D](#!X,#0U,3L@ M("\O(3P@56YR96%L("AA;F0@56YR96%L(%1O=7)N86UE;G0I(%1E>'1U#`T-3([("`O+R$
Re: comparing pointers passed to and returned from funcs
On 3/1/11 4:12 PM, bearophile wrote: Bekenn: I'd remove those parens; you don't want people modifying TRUE or FALSE. Please, show me working code that implements your idea :-) Touche. I'll have to test that out once I get back from work...
Re: comparing pointers passed to and returned from funcs
Bekenn: > I'd remove those parens; you don't want people modifying TRUE or FALSE. Please, show me working code that implements your idea :-) Bye, bearophile
Re: comparing pointers passed to and returned from funcs
On 3/1/11 3:00 PM, bearophile wrote: const(Foo)* TRUE, FALSE; I'd remove those parens; you don't want people modifying TRUE or FALSE.
Re: Win7 64-bit
never mind, i got it. i had to pass the switches: -D -unittest -cov life is hard. it's even harder when you're dumb.
Win7 64-bit
I am running the dmd2 compiler on my Win7 64 bit machine and everything appears to work except the -cov switch. i cannot seem to generate a .lst file. any ideas? thanks dan mcleran
Re: comparing pointers passed to and returned from funcs
http://d.puremagic.com/issues/show_bug.cgi?id=5678
Re: Doubt about Synchronized Code Clocks
On 01/03/2011 22:52, Spacen Jasset wrote: On 01/03/2011 16:59, d coder wrote: > I'm afraid that I have no idea what would be "stale" about a shared variable. > sychronized uses a mutex, and if you want to avoid race conditions, you need to > use mutexes or something similar when dealing with shared variables. But I don't > know what would be "stale" about a variable. > One thread modifies a shared variable and the other thread still gets an old value. I do not know if this is applicable to D at all. Just wanted to get a clarification after I read an article in "Java Concurrency in Practice" book. I quote a relevant paragraph: Locking is not just about mutual exclusion; it is also about memory visibility. To ensure that all threads see the most up-to-date values of shared mutable variables, the reading and writing must synchronize on a common lock. Regards Perhaps what you mean is synchronising a function vs shared data object. If you have one Function A and some data D, then so long as ONLY function A (and it's callees) change or read D, then everything should work fine. Hence you're synchronising function A (or putting it in a critical section) However, if you have two functions A and B, and data D. If function A and B can read and or write to the data D, then thread 1 can execute in A (but no other if it's synchronised) But, it may be pre-empted and another thread can then start executing in function B that is also synchronised. The problem here is that function A is half way though execution when B starts, hence you could likely have data in D that has been partially changed, "old" other otherwise inconsistent, which can cause problems, or even proper disasters. The answer in this case is to have a mutex to protect D, so function A or B must obtain this and hold it while is modifies data D. Any other function will then have to wait for the mutex to be unlocked before reading or writing. See: http://www.digitalmars.com/d/2.0/statement.html#SynchronizedStatement So you can EITHER use synchronised to mark a block of code for execution by one thread only. OR if you provide it with an expression, you mark the block to be run only if an object is "unlocked", therin only one thread may accesses a bit shared of data. AFAIK this very similar to java http://www.herongyang.com/Java/Synchronization-Support-in-Java-synchronized.html
Re: comparing pointers passed to and returned from funcs
This seems to work: import core.stdc.stdio: printf; struct Foo { bool b; this(bool b_) { this.b = b_; } } const(Foo)* TRUE, FALSE; static this() { TRUE = new const(Foo)(true); FALSE = new const(Foo)(false); } const(Foo)* not(const(Foo)* op) { return (op == TRUE) ? FALSE : TRUE; } void main() { assert(not(TRUE) == FALSE); printf("%x\n", TRUE); printf("%x\n", FALSE); printf("%x\n", not(TRUE)); printf("%x\n", not(not(TRUE))); } Bye, bearophile
Re: Doubt about Synchronized Code Clocks
On 01/03/2011 16:59, d coder wrote: > I'm afraid that I have no idea what would be "stale" about a shared variable. > sychronized uses a mutex, and if you want to avoid race conditions, you need to > use mutexes or something similar when dealing with shared variables. But I don't > know what would be "stale" about a variable. > One thread modifies a shared variable and the other thread still gets an old value. I do not know if this is applicable to D at all. Just wanted to get a clarification after I read an article in "Java Concurrency in Practice" book. I quote a relevant paragraph: Locking is not just about mutual exclusion; it is also about memory visibility. To ensure that all threads see the most up-to-date values of shared mutable variables, the reading and writing must synchronize on a common lock. Regards Perhaps what you mean is synchronising a function vs shared data object. If you have one Function A and some data D, then so long as ONLY function A (and it's callees) change or read D, then everything should work fine. Hence you're synchronising function A (or putting it in a critical section) However, if you have two functions A and B, and data D. If function A and B can read and or write to the data D, then thread 1 can execute in A (but no other if it's synchronised) But, it may be pre-empted and another thread can then start executing in function B that is also synchronised. The problem here is that function A is half way though execution when B starts, hence you could likely have data in D that has been partially changed, "old" other otherwise inconsistent, which can cause problems, or even proper disasters. The answer in this case is to have a mutex to protect D, so function A or B must obtain this and hold it while is modifies data D. Any other function will then have to wait for the mutex to be unlocked before reading or writing.
Re: comparing pointers passed to and returned from funcs
spir: > It seems to be the kind of stupid issue that will make you laugh about me. > But > I cannot grasp and want to move forward anyway; so, let us be bold and take > the > risk ;-) Be bold. Understanding things is much more important. I've being wrong hundreds of times on D newsgroups, but I'm getting better. > This fails! It even fails "doubly"... Reduced program (and Walter thinks that avoiding printf-related bugs is not important. He's wrong. I use printf often enough in D): import core.stdc.stdio: printf; struct Foo { bool b; this(bool b_) { this.b = b_; } } enum Foo* TRUE = new Foo(true); enum Foo* FALSE = new Foo(false); Foo* not(Foo* op) { return (op == TRUE) ? FALSE : TRUE; } void main() { //assert(not(TRUE) == FALSE); printf("%x\n", TRUE); printf("%x\n", FALSE); printf("%x\n", not(TRUE)); printf("%x\n", not(not(TRUE))); } > Here, I operate on the structs instead of on the pointers, both to perform > the > operation and in the assert. What I understand is: all happens like if D > would > copy the pointed structs on parameter passing and on return. I thought D > would > only copy the pointers (in both directions), which would let me compare said > pointers directly. > What do I miss? DMD is not copying the structs, just pointers. I think it's happening something like with enum associative arrays. Pointers are run-time things. You are asking for a new at compile-time. This is the asm produced by that program (-O -release): _D4test3Foo6__ctorMFNcbZS4test3Foo comdat pushEAX mov CL,8[ESP] mov [EAX],CL pop ECX ret 4 _D4test3notFPS4test3FooZPS4test3Foo comdat L0: pushEAX mov ECX,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ pushEAX pushEBX push1 pushECX callnear ptr __d_newarrayT add ESP,8 mov EAX,EDX push1 callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo cmp EAX,8[ESP] jne L3D mov EDX,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ push1 pushEDX callnear ptr __d_newarrayT add ESP,8 mov EAX,EDX push0 callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo jmp short L56 L3D:mov EBX,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ push1 pushEBX callnear ptr __d_newarrayT add ESP,8 mov EAX,EDX push1 callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo L56:pop EBX add ESP,8 ret __Dmain comdat L0: pushEAX mov EAX,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ pushEBX pushESI push1 push1 pushEAX callnear ptr __d_newarrayT add ESP,8 mov EAX,EDX callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo mov ECX,offset FLAT:_DATA pushEAX pushECX callnear ptr _printf mov EDX,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ push0 push1 pushEDX callnear ptr __d_newarrayT add ESP,8 mov EAX,EDX callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo mov EBX,offset FLAT:_DATA pushEAX pushEBX callnear ptr _printf mov ESI,offset FLAT:_D20TypeInfo_PS4test3Foo6__initZ push1 push1 pushESI callnear ptr __d_newarrayT add ESP,8 mov EAX,EDX callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo callnear ptr _D4test3notFPS4test3FooZPS4test3Foo pushEAX pushEBX callnear ptr _printf push1 push1 pushESI callnear ptr __d_newarrayT add ESP,8 mov EAX,EDX callnear ptr _D4test3Foo6__ctorMFNcbZS4test3Foo callnear ptr _D4test3notFPS4test3FooZPS4test3Foo callnear ptr _D4test3notFPS4test3FooZPS4test3Foo pushEAX push
About const and C functions
Do you know why DMD doesn't give a compilation error here? import core.stdc.stdio: sscanf; immutable int value = 5; void main() { sscanf("10".ptr, "%d".ptr, &value); } Bye, bearophile
Re: Some weird crashes
On 28.02.2011 20:24, Denis Koroskin wrote: On Mon, 28 Feb 2011 22:04:44 +0300, simendsjo wrote: On 28.02.2011 18:52, simendsjo wrote: // ERROR auto res = mysql_library_init(0, null, null); auto cn = mysql_init(null); auto oldcn = cn; writeln(mysql_errno(cn)); assert(cn == oldcn); // when the last assert is active, the above line changes cn and thus fails. auto err = mysql_errno(cn); assert(cn == oldcn); Btw, if I don't use writeln it doesn't fail.. I think you have a bug at line 42. On a serious note, it might have helped if you'd attached source code, or at least binaries. Hmmm.. Seems my post last night didn't get through.. Here's the code and necessary libraries: http://share1t.com/4xgt2l
Re: Mixins: to!string cannot be interpreted at compile time
That worked, thanks. This is interesting because the example used in "The D Programming Language" on page 83 gets away with it just fine. I had no problem running this: result ~= to!string(bitsSet(b)) ~ ", ";
Re: Template argument deduction
On 02/28/2011 07:39 PM, Tom wrote: > foo([[1,2],[3,4],[5,6]]); // ERROR [1] > bar([[1,2],[3,4],[5,6]]); // OK > foo!int([[1,2],[3,4],[5,6]]); // OK ... > void foo(T)(T[2][] t) { > writeln(typeid(t)); > } > > void bar(T)(T[][] t) { > writeln(typeid(t)); > } On 03/01/2011 04:30 AM, bearophile wrote: > Ali Çehreli: > >> That's because the type of literals like [1, 2] are slices (dynamic >> arrays), not fixed-sized arrays. > > Then why is this accepted? > > foo!int([[1,2],[3,4],[5,6]]); // OK If I have to guess, I think supplying T as int now becomes a problem of matching [1,2] with int[2] and it already works: int[2] a = [1, 2]; int[2][] b = [ [1, 2] ]; I don't know whether the compiler should go the extra mile and help Tom in the original case. :-/ Ali
comparing pointers passed to and returned from funcs
Hello, It seems to be the kind of stupid issue that will make you laugh about me. But I cannot grasp and want to move forward anyway; so, let us be bold and take the risk ;-) I'm modeling a little dynamic language. Elements (values, objects) are pointers to structs (actually tagged unions) allocated on the heap. I have a problem in passing and returning those pointers to and from primitive procedures. Precisely, unlike in D, Logical (boolean) operations only accept Logical elements true/false (called TRUE/FALSE on implementation side for obvious reason): enum TRUE = new DElement(true); enum FALSE = new DElement(false); So, I thought I could write those operations by comparing pointers directly, eg: Element not (Element operand) { // checks type operand.checkLogical() return (operand == TRUE) ? FALSE : TRUE; } ... assert ( not(TRUE) == FALSE ); This fails! It even fails "doubly"... When I call not(TRUE), TRUE (the pointer) inside the func is not equal to the global constant. Thus, not always returns FALSE. And in fact this is also wrong, because I have the same problem on the return value as well: the FALSE returned is not equal to the global FALSE. But the pointed structs are ok. Each one holds a D boolean of the correct value (a member called 'logical'). Thus, the following succeeds: Element not (Element operand) { // checks type & returns the 'logical' member auto log = operand.checkLogical(); return (log) ? FALSE : TRUE; } ... assert ( not(TRUE).logical == false ); Here, I operate on the structs instead of on the pointers, both to perform the operation and in the assert. What I understand is: all happens like if D would copy the pointed structs on parameter passing and on return. I thought D would only copy the pointers (in both directions), which would let me compare said pointers directly. What do I miss? It is not a serious problem since the workaround is easy and not very costly. But I wish to understand why I cannot operate on constant 'identity'. As said above, this must a trivial issue I simply cannot guess... Thank you, Denis -- _ vita es estrany spir.wikidot.com
Re: Doubt about Synchronized Code Clocks
> I'm afraid that I have no idea what would be "stale" about a shared variable. > sychronized uses a mutex, and if you want to avoid race conditions, you need to > use mutexes or something similar when dealing with shared variables. But I don't > know what would be "stale" about a variable. > One thread modifies a shared variable and the other thread still gets an old value. I do not know if this is applicable to D at all. Just wanted to get a clarification after I read an article in "Java Concurrency in Practice" book. I quote a relevant paragraph: Locking is not just about mutual exclusion; it is also about memory > visibility. To ensure that all threads see the most up-to-date values of > shared mutable variables, the reading and writing must synchronize on a > common lock. Regards
Re: Doubt about Synchronized Code Clocks
On Tuesday 01 March 2011 06:40:31 d coder wrote: > Greetings > > I have a doubt about synchronized code blocks. > > I learnt that in Java the synchronized keyword has two fold effect. > Firstly it locks the code to make sure that only a single thread gets > access to the code block at a given time. Secondly, it makes sure that > the data elements accessed inside the code block are not "stale". As a > result Java programming practice is to synchronize even access > functions that access shared data elements. > > How about D? Does D synchronized keyword just result in mutex locking > of the code block? Or does it also ensure that the accessed shared > data elements are not stale? I'm afraid that I have no idea what would be "stale" about a shared variable. sychronized uses a mutex, and if you want to avoid race conditions, you need to use mutexes or something similar when dealing with shared variables. But I don't know what would be "stale" about a variable. - Jonathan M Davis
Re: Problem with std.regex: *+? not allowed in atom
On 2011-03-01 16:54, Dmitry Olshansky wrote: On 27.02.2011 13:41, Jacob Carlborg wrote: On 2011-02-26 19:49, Dmitry Olshansky wrote: On 26.02.2011 19:52, Jacob Carlborg wrote: On 2011-02-26 12:29, Dmitry Olshansky wrote: On 26.02.2011 14:10, Jacob Carlborg wrote: I'm trying to use the std.regex module but when I run my application I get an exception. The exception message says: *+? not allowed in atom The code I have is: import std.regex; void main () { regex(`\.(?=(?:[^\"]*\"[^\"]*\")*(?![^\"]*\"))`, "m"); } Well the thing is, std.regex is not quite ECMA complaint (as vaguely stated in docs). To the best of my knowledge not a single one variant of the forms (?:...) ... (?=...) is supported . Also see http://d.puremagic.com/issues/show_bug.cgi?id=5169, you may try out my patch there to support (?:...). It's a slightly outdated, but std.regex wasn't in very active development. I tried the patch but with no success. I still get the same error. The patch fixes only (?: ) form and not the lookahead and others. Sorry, it was the only one I needed back then. I'll check if I can make a patch for them as well when I have some spare time. That's would be around monday if, of course, nobody else wishes to rush into the depths of std.regex. Ok. So here it is, hot and bobbling. For now no lookbehind. I added it into another Bugzilla requesthttp://d.puremagic.com/issues/show_bug.cgi?id=5673 Ok, thanks. -- /Jacob Carlborg
Re: Is std.regex.match completely broken?
On 2011-03-01 14:03, Dmitry Olshansky wrote: On 28.02.2011 22:37, Jacob Carlborg wrote: The following code will result in an AssertError or RangeError when run. import std.regex; import std.stdio; void main () { auto m = "abc".match(`a(\w)b`); writeln(m.hit); // AssertError in regex.d:1795 writeln(m.captures); // RangeError in regex.d:1719 } Should I report this as a bug? Well, there won't be a match. If you meant "abc".match(`a(\w)c`) then it works for me. At the bottom of it all, I also was sort of surprised to get an Assert and not an Exception, but it's the way it works with ranges in Phobos. So you should check m.empty before use. That seems quite strange, to design an API like that. Why doesn't "hit" just returns an empty string and "captures" an empty range. P.S. I'm in the process of patching in lookahead regexes, I think I can get them fairly soon. As for lookbehind, well, that's would be somewhat harder it seems. Sounds good. -- /Jacob Carlborg
Re: Problem with std.regex: *+? not allowed in atom
On 27.02.2011 13:41, Jacob Carlborg wrote: On 2011-02-26 19:49, Dmitry Olshansky wrote: On 26.02.2011 19:52, Jacob Carlborg wrote: On 2011-02-26 12:29, Dmitry Olshansky wrote: On 26.02.2011 14:10, Jacob Carlborg wrote: I'm trying to use the std.regex module but when I run my application I get an exception. The exception message says: *+? not allowed in atom The code I have is: import std.regex; void main () { regex(`\.(?=(?:[^\"]*\"[^\"]*\")*(?![^\"]*\"))`, "m"); } Well the thing is, std.regex is not quite ECMA complaint (as vaguely stated in docs). To the best of my knowledge not a single one variant of the forms (?:...) ... (?=...) is supported . Also see http://d.puremagic.com/issues/show_bug.cgi?id=5169, you may try out my patch there to support (?:...). It's a slightly outdated, but std.regex wasn't in very active development. I tried the patch but with no success. I still get the same error. The patch fixes only (?: ) form and not the lookahead and others. Sorry, it was the only one I needed back then. I'll check if I can make a patch for them as well when I have some spare time. That's would be around monday if, of course, nobody else wishes to rush into the depths of std.regex. Ok. So here it is, hot and bobbling. For now no lookbehind. I added it into another Bugzilla requesthttp://d.puremagic.com/issues/show_bug.cgi?id=5673 -- Dmitry Olshansky
Doubt about Synchronized Code Clocks
Greetings I have a doubt about synchronized code blocks. I learnt that in Java the synchronized keyword has two fold effect. Firstly it locks the code to make sure that only a single thread gets access to the code block at a given time. Secondly, it makes sure that the data elements accessed inside the code block are not "stale". As a result Java programming practice is to synchronize even access functions that access shared data elements. How about D? Does D synchronized keyword just result in mutex locking of the code block? Or does it also ensure that the accessed shared data elements are not stale? Thanks and Regards - Puneet
Re: Is std.regex.match completely broken?
On 28.02.2011 22:37, Jacob Carlborg wrote: The following code will result in an AssertError or RangeError when run. import std.regex; import std.stdio; void main () { auto m = "abc".match(`a(\w)b`); writeln(m.hit); // AssertError in regex.d:1795 writeln(m.captures); // RangeError in regex.d:1719 } Should I report this as a bug? Well, there won't be a match. If you meant "abc".match(`a(\w)c`) then it works for me. At the bottom of it all, I also was sort of surprised to get an Assert and not an Exception, but it's the way it works with ranges in Phobos. So you should check m.empty before use. P.S. I'm in the process of patching in lookahead regexes, I think I can get them fairly soon. As for lookbehind, well, that's would be somewhat harder it seems. -- Dmitry Olshansky
Re: Mixins: to!string cannot be interpreted at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=5671
Re: Mixins: to!string cannot be interpreted at compile time
David Nadlinger: > Maybe I missed something as well, but to me it seems to be a CTFE bug, > because if you split the offending line into two parts, it > > result ~= to!string(i); > result ~= ", "; > > Please consider filing this to Bugzilla. Wow. I was wrong, and you are right. It's not a problem of to!() then. Bye, bearophile
Re: Mixins: to!string cannot be interpreted at compile time
Peter Lundgren: > I'm trying to use mixins to generate an array of numbers that are coprime to a > statically known value. I've tried the following, but I receive the error: > > Error: to(i) ~ ", " cannot be interpreted at compile time Currently to!() can't run at compile-time. Are you sure you need string mixings? Isn't compile-time run of functions enough for you? If you really want to create that at compile-time as string, you are able to use the ToStringNow, converting makePossibleAValues into a recursive template, and running coprime() at compile-time from the template. But it will eat lot of RAM at compile-time. Bye, bearophile
Re: Mixins: to!string cannot be interpreted at compile time
On 3/1/11 11:45 AM, spir wrote: makePossibleAValues() obviously returns a runtime value, so mixin() cannot evaluate it, I guess. Nope, that's not the problem due to CTFE (compile time function execution). David
Re: Mixins: to!string cannot be interpreted at compile time
On 3/1/11 7:58 AM, Peter Lundgren wrote: I'm trying to use mixins to generate an array of numbers that are coprime to a statically known value. I've tried the following, but I receive the error: Error: to(i) ~ ", " cannot be interpreted at compile time […] Maybe I missed something as well, but to me it seems to be a CTFE bug, because if you split the offending line into two parts, it result ~= to!string(i); result ~= ", "; Please consider filing this to Bugzilla. David
Re: Template argument deduction
Ali Çehreli: > That's because the type of literals like [1, 2] are slices (dynamic > arrays), not fixed-sized arrays. Then why is this accepted? foo!int([[1,2],[3,4],[5,6]]); // OK Bye, bearophile
Re: @property ref foo() { ...} won't work...?
On Tue, 01 Mar 2011 07:19:21 -0500, Lars T. Kyllingstad wrote: On Tue, 01 Mar 2011 12:25:30 +0100, Magnus Lie Hetland wrote: 2. How can I make r.front = foo work, when I only have r.front(), returning a ref (which seems like it is used in actual code)? I think this is a bug, but I'm not entirely sure. It is most definitely a bug. Please file. -Steve
Re: @property ref foo() { ...} won't work...?
On Tue, 01 Mar 2011 12:25:30 +0100, Magnus Lie Hetland wrote: > In Andrei's book, as well as in the Phobos source, there are property > getters that return refs, as in... > > @property ref T front() { > return _payload[0]; > } > > ... and code that uses this with simple assignments, such as: > > r.front = foo; > > For some reason, I can't get this to work in my code :-/ DMD seems to > insist that I add a setter as well (i.e., @property T front(T val) { > return _payload[0] = val; }). > > On the other hand, I *do* get > > r.front() = foo; > > to work. That works well even without @property, of course; and r.front > fails even without @property. > > Then, again, if I write both the getter (front()) and the setter > (front(T)), that works even without @property (which, then, seems rather > redundant?). > > So ... I guess I have two questions: > > 1. What's the point of @property (when it seems I get the same > functionality without it)? That is because @property is a relatively new feature. In D1, and until recently in D2, there was no such thing as @property. The choice of whether to write x = s.foo(); s.foo(x); or x = s.foo; s.foo = x; was completely up to the user. The plan is for the compiler to enforce the first syntax for non-@property functions and the latter syntax for @property functions. I believe the reason this hasn't been implemented yet is that it will break a *lot* of code, so people are currently getting a chance to update their code base before it breaks. > 2. How can I make r.front = foo work, when I only have r.front(), > returning a ref (which seems like it is used in actual code)? I think this is a bug, but I'm not entirely sure. Even though assignment doesn't work, this does: r.front++; The same happens when you overload the indexing operator, []: struct S { ref int opIndex(int i) { ... } } S s; s[0]++; // works s[0] = 123; // fails You have to define opIndexAssign() for the last line to work. -Lars
Re: string vs. w/char*
On 3/1/2011 7:18 PM, Bekenn wrote: On 3/1/2011 12:25 AM, Tyro[a.c.edwards] wrote: Nevertheless, execution haults at the very next line following/catch and Create() never returns. CreateWindow sends a few messages to your window proc; anything interesting happening there? Not sure how to check those messages, but I guess that's a cue for me to do some more research. Off to Google land I go...
@property ref foo() { ...} won't work...?
In Andrei's book, as well as in the Phobos source, there are property getters that return refs, as in... @property ref T front() { return _payload[0]; } ... and code that uses this with simple assignments, such as: r.front = foo; For some reason, I can't get this to work in my code :-/ DMD seems to insist that I add a setter as well (i.e., @property T front(T val) { return _payload[0] = val; }). On the other hand, I *do* get r.front() = foo; to work. That works well even without @property, of course; and r.front fails even without @property. Then, again, if I write both the getter (front()) and the setter (front(T)), that works even without @property (which, then, seems rather redundant?). So ... I guess I have two questions: 1. What's the point of @property (when it seems I get the same functionality without it)? 2. How can I make r.front = foo work, when I only have r.front(), returning a ref (which seems like it is used in actual code)? -- Magnus Lie Hetland http://hetland.org
Re: Mixins: to!string cannot be interpreted at compile time
On 03/01/2011 07:58 AM, Peter Lundgren wrote: I'm trying to use mixins to generate an array of numbers that are coprime to a statically known value. I've tried the following, but I receive the error: Error: to(i) ~ ", " cannot be interpreted at compile time string makePossibleAValues(string name, byte m) { string result = "immutable byte[] "~name~" = ["; foreach (i; 0 .. m) { if (coprime(i, m)) { result ~= to!string(i) ~ ", "; } } return result ~ "];"; } bool coprime(ulong a, ulong b) { return gcd(a, b) == 1; } ulong gcd(ulong a, ulong b) { while (b) { auto t = b; b = a % b; a = t; } return a; } mixin(makePossibleAValues("aValues", 26)); makePossibleAValues("aValues", 26) produces the correct result, "immutable byte[] aValues = [1, 3, 5, 7, 9, 11, 15, 17, 19, 21, 23, 25, ];", at runtime and I know to!string can be used in mixins. Any idea as to why this particular code is having trouble with to!string? Not sure because I never use string mixins, but I guess the answer is precisely what the error says. Why don't you believe it? makePossibleAValues() obviously returns a runtime value, so mixin() cannot evaluate it, I guess. Denis -- _ vita es estrany spir.wikidot.com
Re: string vs. w/char*
On 3/1/2011 12:25 AM, Tyro[a.c.edwards] wrote: Nevertheless, execution haults at the very next line following/catch and Create() never returns. CreateWindow sends a few messages to your window proc; anything interesting happening there?
Re: string vs. w/char*
== Quote from Denis Koroskin (2kor...@gmail.com)'s article > On Tue, 01 Mar 2011 02:08:48 +0300, Tyro[a.c.edwards] > wrote: > > == Quote from Denis Koroskin (2kor...@gmail.com)'s article > >> On Mon, 28 Feb 2011 19:35:47 +0300, Tyro[a.c.edwards] > > > >> wrote: > >> > On 2/28/2011 11:08 PM, J Chapman wrote: > >> >> == Quote from Tyro[a.c.edwards] (nos...@home.com)'s article > >> >>> Both implementations results in error code 1812 being > > returned from > >> >>> GetLastError. explanation of the code reads: > >> >>>ERROR_RESOURCE_DATA_NOT_FOUND > >> >>>1812 (0x714) > >> >>>The specified image file did not contain a resource > > section. > >> >>> The code I'm porting initially consisted of a resource.h > > file, a > >> >>> generic.rc file and two icons. I have not tried to include > > the icons > >> >>> and > >> >>> generic.rc file in the compilation because I do not know how > > to as yet > >> >>> and I've only used half of the resource.h file: didn't think > > I need the > >> >>> whole thing. Could this be the reason for the error? If so > > could you > >> >>> direct me to the explanation of how to prepare these files > > for > >> >>> inclusion > >> >>> in the compilation process? > >> >>> Thanks, > >> >>> Andrew > >> >> > >> >> You need to compile the .rc file (see > >> >> http://www.digitalmars.com/ctg/rcc.html), then add the > > resulting .res > >> >> file > >> >> to dmd's command line. > >> > > >> > Awesome, this does the trick. However I get get a "GP Fault"? > > during > >> > execution. Using windbg, I tracked it down to this piece of > > code: > >> > > >> > void Create() > >> > { > >> >_hwnd = CreateWindowExA( > >> > _exStyle, > >> > cast(const(char*))_wc.GetName(), // returns string > >> > cast(const(char*))_windowName, // string variable > >> > _style, > >> > _x, > >> > _y, > >> > _width, > >> > _height, > >> > _hWndParent, > >> > _hMenu, > >> > _wc.GetInstance(), > >> > _data); > >> > > >> > assert(_hwnd, "Internal error: Window Creation Failed."); > >> > } > >> > > >> > The program craps at assert() but the error is generated. It > > just > >> > displays a dialog box with the message: "test.exe has stopped > > working, > >> > Windows is checking for a solution to the problem..." > >> > > >> > I'm thinking that _hwnd was never initialized and that assert > > is access > >> > a null pointer but I cannot be sure. Any suggestions or ideas? > >> The > >> > cast(const(char*))_wc.GetName() > >> line look *very* suspicious. You can't get a string and just > > cast it to > >> const(char)*. Most importantly, the string (most likely) is not > >> null-terminated. > >> What you need to do here is the following: > >> auto className = toStringz(_ws.GetName()); > >> auto caption = toStringz(_windowName); > >> and pass those 2 to the function. > > > > Actually I've already tried that, it has no effect on the outcome. > > From your suggestion though, I've gone back and replace all the > > cast(const(char*)) usage throughout the program. Final verdict: > > the program still crashes it the same location. It actually never > > returns from CreateWindowExA(). > > > >> Alternatively, you could make sure your strings are null- > > terminated and > >> pass the pointer directly (e.g. _windowName.ptr): > >> string _windowName = "foo"; // null-terminated automatically > >> string _caption = ("Hello, World" ~ "\0")[0..$-1]; // append > > trailing zero > >> to an existing string but exclude it from result (so that it's > > not > >> included in _caption.length) > > > This is indeed strange, but it has nothing to do with the function itself. > I still think the parameters you are passing might be invalid. Try setting > them to default values and see if that helps. Also try wrapping the call > with a try/catch block and output an exception you are getting (if any). The problem occurs at the site of the assertion. I wrapped the function in a try/catch block and placed a call to MessageBoxA() on either end of the the try block. Both calls to MessageBox fires and the appropriate messages displayed. No exception is thrown: made evident my the fact that the third call to MessageBox, embeded in catch{}, is not fired. Nevertheless, execution haults at the very next line following/catch and Create() never returns.