Re: Operator overloading giving encrypted error messages.
> It sees the post-increment fires the opBinary template too. I think this is a > front-end bug, for Bugzilla if confirmed and not already present. http://d.puremagic.com/issues/show_bug.cgi?id=5551
Re: Operator overloading giving encrypted error messages.
Charles McAnany: > My issue here is that I have already used the exact same syntax in the first > unit test as my code for the ++ overload has, but here it fails me. (Plus, why > is line 166 having trouble with opBinary? ++ is unary, no? > Any ideas? In similar situations I suggest you to keep reducing your code until you have a minimal test case. Your code reduced: struct Foo { Foo opUnary(string op:"++")() { return this; } Foo opBinary(string op)(int y) { return this; } } void main() { auto f = Foo(); f++; } It sees the post-increment fires the opBinary template too. I think this is a front-end bug, for Bugzilla if confirmed and not already present. Bye, bearophile
Operator overloading giving encrypted error messages.
Hi, all. I'm playing around with a BigRational struct to get more comfortable with D. The plan: Allow binary operators so that a BR (BigRational) is the lhs and one of {BR, BigInt, int, long} is the rhs. So BR(5) + 2 compiles just as well as BR(5)+BR(2) Here's the opBinary code I've worked out: BigRational opBinary(string op,T)(T arg){ BigRational y = BigRational(arg); static if(op == "+"){ BigRational temp = this; }}} /// and so on, ending with an assert(0) after all the static ifs. So, unit testing this with auto br1 = BigRational(25,"2"); writefln("br1+1 = %s",br1+1); works beautifully. Now, I'd like to define the ++ to increase this by 1. So, I write: BigRational opUnary(string op)(){ static if(op == "++"){ this = this+1; return this; //There are other overloads, too. }} Now, when I unittest writefln("br1++ = %s", br1++); //This is line 166. I get a weird error message: C:\DProjects\BigRational\src>dmd BigRational.d -unittest BigRational.d(166): Error: template BigRational.BigRational.opBinary(string op,T ) does not match any function template declaration BigRational.d(166): Error: template BigRational.BigRational.opBinary(string op,T ) cannot deduce template function from argument types !()() My issue here is that I have already used the exact same syntax in the first unit test as my code for the ++ overload has, but here it fails me. (Plus, why is line 166 having trouble with opBinary? ++ is unary, no? Any ideas? Thanks, Charles. begin 644 BigRational.d M:6UP;W)T('-T9"YB:6=I;G0[#0II;7!O2X@5&AEPT* M?0T*#0HO*BH-"D$@0FEG4F%T:6]N86PN(%!E2UP MPT*<')I=F%T93H-"@E":6=) M;G0@;G5M97)A=&]R.PT*"4)I9TEN="!D96YO;6EN871O4UE*"E[#0H)"2\O1FER&-E<'1I;VXH(D1I M=FED92!B>2!Z97)O(BD[#0H)"7T-"@D):68H;G5M97)A=&]R(#T](#`I>PT* M"0D);G5M97)A=&]R(#U":6=);G0H,"D[#0H)"0ED96YO;6EN871OPT* M"0EA=71O(')E4UE*"D["0D-"@E]#0H)#0H)=&AIPT*"0ES9715<%-T871E*'-T87)T+FYU;65R871OPT*"0D)0FEG4F%T M:6]N86P@9F%I;"`]($)I9U)A=&EO;F%L*#$L,"D[#0H)"0EA&-E<'1I;VX@92E[?0T*"7T-"@D-"@D)#0H)PT* M"0D)7B`H17AP;VYE;G1I871I;VXI#0H)0FEG4F%T:6]N M86P@;W!":6YA2`]($)I9U)A=&EO;F%L*&%R9RD["0D-"@D)2YD96YO;6EN871O M2YN=6UE2YD96YO;6EN871O7B(I>PT*"0D)+R]4:&4@=6YD97)L>6EN9R!":6=);G0@ M;&EB2!O;FQY(&1O97,@97AP;VYE;G1I871I;VX@=VET:`T*"0D)+R\@ M;&]N9W,L(&YO="!O=&AE("@Q+S(I(&ES(`T*"0D)+R\@:7)R M871I;VYA;"X-"@D)"6EF("AY+F1E;F]M:6YA=&]R("$](#$@?'P@>2YN=6UE M"!\?"!Y+FYU;65R871O2YN=6UE/2!Y+FYU;65R871O2YN M=6UEPT*"0D)"71E;7`N;G5M97)A=&]R(#T@=&AI7B!Y+FYU;65R871O('DN;G5M97)A=&]R+G1O3&]N M9SL-"@D)"7T-"@D)"7)E='5R;B!T96UP.PT*"0E]"0T*"0EAR`O+U1H92!B2X-"B\O"0ER971U2$H;W`L0FEG4F%T M:6]N86PI*$)I9U)A=&EO;F%L*'DI*3L-"B\O"7T-"@T*"2\O5&AE(%1D=6UM M>2!I7!E(&%R9W5M96YT+"`-"@DO+V5V96X@:68@:70@:7,@=6YU2`]('9O:60I*$)I9U)A=&EO;F%L('DI M>PT*"0EA=71O('1E;7`@/2!T:&ES+7D[#0H)"6EF("AT96UP+FYU;65R871O M2!O9B!T>7!E
Re: Ranges
> Related discussion: > http://www.digitalmars.com/d/archives/digitalmars/D/getNext_113217.html Oh sorry; thank you for the link!
Re: Using D libs in C
On 2011-02-07 20:07, Steven Schveighoffer wrote: On Mon, 07 Feb 2011 13:53:14 -0500, spir wrote: On 02/07/2011 04:32 PM, Steven Schveighoffer wrote: On Mon, 07 Feb 2011 06:42:46 -0500, spir wrote: On 02/07/2011 07:53 AM, GreatEmerald wrote: Hmm, no, it won't work right on Linux for some reason. This is the output: /usr/lib/gcc/x86_64-linux-gnu/4.3.2/../../../libphobos2.a(deh2_4e7_525.o): In function `_D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable': src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x4): undefined reference to `_deh_beg' src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc): undefined reference to `_deh_beg' src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13): undefined reference to `_deh_end' src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x37): undefined reference to `_deh_end' collect2: ld returned 1 exit status --- errorlevel 1 The shell script I'm using to compile it is: #!/bin/sh dmd -m32 -c -lib dpart.d gcc -m32 -c cpart.c dmd -m32 cpart.o dpart.a /usr/lib/libphobos2.a (Although it appears that you don't need to explicitly link with libphobos2, it does it automatically... and fails with the above error.) Any ideas about what the error means? Take my words with much doubt, I've few exp in that. Are you sure you did use same source under both OSes? "undefined reference to `_deh_end' / `_deh_beg'" deh == d exception handling (or handler, not sure) ;) Looks like the module that's failing to link is rt.deh Are you sure of that? I get exactly the same kind of linker error when forgetting a fake main(){} (whatver the number of modules). Eg: ... src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0xc): undefined reference to `_deh_beg' src/rt/deh2.d:(.text._D2rt4deh213__eh_finddataFPvZPS2rt4deh213DHandlerTable+0x13): undefined reference to `_deh_end' ... repeted n times. Hm... it looks like _deh_beg and _deh_end is something defined by the compiler? It's used in deh2.d but not defined anywhere in druntime. I'm pretty sure deh stands for d exception handler. -Steve The compiler puts this in the binary. -- /Jacob Carlborg