digitalmars.D.announce - DMD 1.004 release
- Walter Bright (3/3) Jan 26 2007 Fixes mixin gc bug.
- Chris Miller (1/1) Jan 26 2007 Changelog need update?
- Bill Baxter (6/13) Jan 26 2007 Amazing turnaround time!
- Chris Miller (16/27) Jan 26 2007 line =
- Walter Bright (2/7) Jan 26 2007 Oops, uploaded the wrong file. Try again.
- Bill Baxter (3/11) Jan 26 2007 Yay! All happy now.
- Walter Bright (3/14) Jan 26 2007 I've automated much of the process of creating an update, but there's
- Vladimir (3/5) Jan 27 2007 Please also automate synchronization of std.compiler.version_* constants
- Andrei Alexandrescu (See Website For Email) (3/18) Jan 27 2007 Sounds like you work under Windows... :o)
- Frits van Bommel (8/13) Jan 27 2007 ----
- Bob W (5/8) Jan 27 2007 He is a smart guy who probably does not feel like
- Walter Bright (11/19) Jan 27 2007 g++ is a slow compiler, and ld is a really slow linker, and I'm just
- Thomas Kuehne (15/21) Jan 28 2007 -----BEGIN PGP SIGNED MESSAGE-----
- Walter Bright (17/35) Jan 28 2007 No, I've never heard of them. Insight isn't on my machine. ddd is, and
- Brad Roberts (34/62) Jan 28 2007 (gdb) break main
- Walter Bright (4/72) Jan 28 2007 I missed the 'info registers' command because gdb doesn't list 'info'
- Leandro Lucarella (12/17) Jan 29 2007 BTW, ddd has a registers window, you have threads, backtrace and
- Thomas Kuehne (15/42) Jan 28 2007 -----BEGIN PGP SIGNED MESSAGE-----
- Daniel Kos (5/5) Jan 28 2007 GDB is simply unintuitive and problematic to use. Of course it has
- Leandro Lucarella (7/17) Jan 29 2007 DDD has an ugly interface, but it's one of the best debuggers I know,
- Kevin Bealer (22/45) Jan 28 2007 (I agree its an ugly interface.)
- Andrei Alexandrescu (See Website For Email) (4/23) Jan 28 2007 And gprof too.
- =?ISO-8859-1?Q?Lu=EDs_Marques?= (3/4) Feb 01 2007 But it's not open source :(
- Bob W (11/14) Jan 27 2007 Still another one mixin bug - causes dmd to crash.
- Jordan Miner (30/30) Jan 27 2007 Here is a problem I've found in post-1.00 versions.
- Walter Bright (5/6) Jan 27 2007 What's happening is you're writing into the string literal, which is not...
- Jeff Nowakowski (5/7) Jan 27 2007 So is there a reasonable way for D to enforce this? I haven't been
- Sean Kelly (5/12) Jan 27 2007 This is enforced on Linux but not Win32. I suspect this means it's an
- Jordan Miner (3/11) Jan 27 2007 I guess I thought that literals were allocated at runtime. Must have use...
- Lionello Lunesu (7/13) Jan 27 2007 Shouldn't string literals be forced "const"? Even D's limited const coul...
- renoX (3/23) Jan 28 2007 Agreed! There's really not reason to create such blatant trap in D..
- Jarrett Billingsley (5/9) Jan 28 2007 That wouldn't help, because even if you pass a const char[] into a funct...
- Lionello Lunesu (6/19) Jan 28 2007 Perhaps, but at least assignments of string literals to variables would ...
- Brad Roberts (7/20) Jan 28 2007 I sincerely hope that passing a const T through an api asking for a T
- Andrei Alexandrescu (See Website For Email) (5/18) Jan 28 2007 This was kind of "forced by design" because const was a storage class
- Derek Parnell (13/24) Jan 27 2007 Does this work for you?
- Jordan Miner (2/32) Jan 27 2007 Yes, I've fixed it now by putting a .dup on the literal both times befor...
- Andrey Khropov (11/16) Jan 28 2007 shootout.binarytrees
Fixes mixin gc bug. http://www.digitalmars.com/d/changelog.html http://ftp.digitalmars.com/dmd.1.004.zip
Jan 26 2007
Walter Bright wrote:Fixes mixin gc bug. http://www.digitalmars.com/d/changelog.html http://ftp.digitalmars.com/dmd.1.004.zipAmazing turnaround time! But no dice. The bug may be fixed but I can't tell because I get:Assertion failure: 'classinfo->structsize == CLASSINFO_SIZE' on line316 in file 'toobj.c'abnormal program terminationwhen I try to compile. --bb
Jan 26 2007
On Fri, 26 Jan 2007 23:58:56 -0500, Bill Baxter = <dnewsgroup billbaxter.com> wrote:Walter Bright wrote:line =Fixes mixin gc bug. http://www.digitalmars.com/d/changelog.html http://ftp.digitalmars.com/dmd.1.004.zipAmazing turnaround time! But no dice. The bug may be fixed but I can't tell because I get: > Assertion failure: 'classinfo->structsize =3D=3D CLASSINFO_SIZE' on=316 in file 'toobj.c' > abnormal program termination when I try to compile. --bbYep, I tracked it down to simply this: class MyException: Exception { /// this(char[] msg) { super(msg); } } Assertion failure: 'classinfo->structsize =3D=3D CLASSINFO_SIZE' on line= 316 = in file 'toobj.c'
Jan 26 2007
Bill Baxter wrote:> Assertion failure: 'classinfo->structsize == CLASSINFO_SIZE' on line 316 in file 'toobj.c' > abnormal program termination when I try to compile.Oops, uploaded the wrong file. Try again.
Jan 26 2007
Walter Bright wrote:Bill Baxter wrote:Yay! All happy now. --bb> Assertion failure: 'classinfo->structsize == CLASSINFO_SIZE' on line 316 in file 'toobj.c' > abnormal program termination when I try to compile.Oops, uploaded the wrong file. Try again.
Jan 26 2007
Bill Baxter wrote:Walter Bright wrote:I've automated much of the process of creating an update, but there's still maddening places where I can overlook something.Bill Baxter wrote:Yay! All happy now.> Assertion failure: 'classinfo->structsize == CLASSINFO_SIZE' on line 316 in file 'toobj.c' > abnormal program termination when I try to compile.Oops, uploaded the wrong file. Try again.
Jan 26 2007
Walter Bright wrote:I've automated much of the process of creating an update, but there's still maddening places where I can overlook something.Please also automate synchronization of std.compiler.version_* constants vladimir
Jan 27 2007
Walter Bright wrote:Bill Baxter wrote:Sounds like you work under Windows... :o) AndreiWalter Bright wrote:I've automated much of the process of creating an update, but there's still maddening places where I can overlook something.Bill Baxter wrote:Yay! All happy now.> Assertion failure: 'classinfo->structsize == CLASSINFO_SIZE' on line 316 in file 'toobj.c' > abnormal program termination when I try to compile.Oops, uploaded the wrong file. Try again.
Jan 27 2007
Andrei Alexandrescu (See Website For Email) wrote:Walter Bright wrote:---- urxae urxae:~/opt/dmd/src$ file `find` | grep text | grep CRLF | wc -l 245 urxae urxae:~/opt/dmd/src$ file `find` | grep text | grep -v CRLF | wc -l 37 ----- Yep, looks like he does (mostly) :).I've automated much of the process of creating an update, but there's still maddening places where I can overlook something.Sounds like you work under Windows... :o)
Jan 27 2007
..........Sounds like you work under Windows... :o)Yep, looks like he does (mostly) :).He is a smart guy who probably does not feel like beta testing operating systems. Or maybe he just ran out of coffee too often while waiting for penguin's favorite compiler and linker to finish their jobs .... ;-)
Jan 27 2007
Bob W wrote:g++ is a slow compiler, and ld is a really slow linker, and I'm just more used to windows quirks than linux quirks. But the worst thing about linux development is gdb. gdb's user interface seems stuck in 1983 era thinking. I can't even get the thing to display the register contents. It won't pick up the program arguments from the command line. Either I'm stupid, all this is missing from the documentation, or gdb really is terrible. I do all my debugging on windows. Even horrible old windbg is a decade ahead of gdb. I do like gcov, though...........Sounds like you work under Windows... :o)Yep, looks like he does (mostly) :).He is a smart guy who probably does not feel like beta testing operating systems. Or maybe he just ran out of coffee too often while waiting for penguin's favorite compiler and linker to finish their jobs .... ;-)
Jan 27 2007
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Walter Bright schrieb am 2007-01-28: [...]But the worst thing about linux development is gdb. gdb's user interface seems stuck in 1983 era thinking.Have you tried "insight" or "ddd"?I can't even get the thing to display the register contents.print $ebp print $eaxIt won't pick up the program arguments from the command line.run what ever argumentEither I'm stupid, all this is missing from the documentation, or gdb really is terrible."info gdb" should provide you with lots of documentation. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFvGx5LK5blCcjpWoRArM2AJ4y8Cd/8qcwcHBjtkYS0y+anwY04gCeLwkv wy4dSHELEC/YIs5A6d+j8SM= =5v6G -----END PGP SIGNATURE-----
Jan 28 2007
Thomas Kuehne wrote:Walter Bright schrieb am 2007-01-28: [...]No, I've never heard of them. Insight isn't on my machine. ddd is, and looks interesting. I'll try it.But the worst thing about linux development is gdb. gdb's user interface seems stuck in 1983 era thinking.Have you tried "insight" or "ddd"?There are a bunch of registers, I have to list them one at a time. It's pretty miserable if you're single stepping trying to keep an eye on the register contents. Every other debugger I've ever used, going back to the 70's, could either dump all regs with a shorter command, or had a window where the reg values were continuously updated.I can't even get the thing to display the register contents.print $ebp print $eaxWhere this falls down is when you've a long list of arguments to the program. I'll write a simple .bat file like: windbg program arg arg arg ... to run the debugger with the args. Doesn't work with gdb, because gdb doesn't pick up debuggee args from the command line, making gdb very tedious to use.It won't pick up the program arguments from the command line.run what ever argumentI didn't know that. You'd think: gdb --help would have provided this information. Thanks for the pointers.Either I'm stupid, all this is missing from the documentation, or gdb really is terrible."info gdb" should provide you with lots of documentation.
Jan 28 2007
(gdb) break main Breakpoint 1 at 0x804b389 (gdb) run Starting program: /home/braddr/sandbox/d/bugs/abstract_15 Failed to read a valid object file image from memory. Breakpoint 1, 0x0804b389 in main () (gdb) info registers eax 0xbff57484 -1074432892 ecx 0xb7dd1e6d -1210245523 edx 0x1 1 ebx 0xb7ee9ff4 -1209098252 esp 0xbff573e8 0xbff573e8 ebp 0xbff57408 0xbff57408 esi 0x0 0 edi 0xb7f4fcc0 -1208681280 eip 0x804b389 0x804b389 <main+9> eflags 0x282 [ SF IF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) help info <snip a long list of helpful program status info options> (gdb) help set args Set argument list to give program being debugged when it is started. Follow this command with any number of args, to be passed to the program.There are a bunch of registers, I have to list them one at a time. It's pretty miserable if you're single stepping trying to keep an eye on the register contents. Every other debugger I've ever used, going back to the 70's, could either dump all regs with a shorter command, or had a window where the reg values were continuously updated.I can't even get the thing to display the register contents.print $ebp print $eaxAlso: $ gdb --args programtodebug arg1 arg2 arg3Where this falls down is when you've a long list of arguments to the program. I'll write a simple .bat file like: windbg program arg arg arg ... to run the debugger with the args. Doesn't work with gdb, because gdb doesn't pick up debuggee args from the command line, making gdb very tedious to use.It won't pick up the program arguments from the command line.run what ever argumentThe built-in help to gdb isn't bad either.. though sometimes hard to find stuff in. Later, BradI didn't know that. You'd think: gdb --help would have provided this information. Thanks for the pointers.Either I'm stupid, all this is missing from the documentation, or gdb really is terrible."info gdb" should provide you with lots of documentation.
Jan 28 2007
Brad Roberts wrote:That's good to know.(gdb) break main Breakpoint 1 at 0x804b389 (gdb) run Starting program: /home/braddr/sandbox/d/bugs/abstract_15 Failed to read a valid object file image from memory. Breakpoint 1, 0x0804b389 in main () (gdb) info registers eax 0xbff57484 -1074432892 ecx 0xb7dd1e6d -1210245523 edx 0x1 1 ebx 0xb7ee9ff4 -1209098252 esp 0xbff573e8 0xbff573e8 ebp 0xbff57408 0xbff57408 esi 0x0 0 edi 0xb7f4fcc0 -1208681280 eip 0x804b389 0x804b389 <main+9> eflags 0x282 [ SF IF ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) help info <snip a long list of helpful program status info options> (gdb) help set args Set argument list to give program being debugged when it is started. Follow this command with any number of args, to be passed to the program.There are a bunch of registers, I have to list them one at a time. It's pretty miserable if you're single stepping trying to keep an eye on the register contents. Every other debugger I've ever used, going back to the 70's, could either dump all regs with a shorter command, or had a window where the reg values were continuously updated.I can't even get the thing to display the register contents.print $ebp print $eaxAlso: $ gdb --args programtodebug arg1 arg2 arg3Where this falls down is when you've a long list of arguments to the program. I'll write a simple .bat file like: windbg program arg arg arg ... to run the debugger with the args. Doesn't work with gdb, because gdb doesn't pick up debuggee args from the command line, making gdb very tedious to use.It won't pick up the program arguments from the command line.run what ever argumentI missed the 'info registers' command because gdb doesn't list 'info' when you type 'help' on its command prompt. Thanks for the tip.The built-in help to gdb isn't bad either.. though sometimes hard to find stuff in.I didn't know that. You'd think: gdb --help would have provided this information. Thanks for the pointers.Either I'm stupid, all this is missing from the documentation, or gdb really is terrible."info gdb" should provide you with lots of documentation.
Jan 28 2007
Walter Bright escribió:BTW, ddd has a registers window, you have threads, backtrace and assembly windows too. GDB it's a great powerful debugger, *commandline* debugger, if you want a GUI debugger, DDD is a great GDB frontend. You can try better-looking KDE's Kdevelop fronten, kdbg (another standalone KDE GDB frontend), insight, and if you like console based there are other fronends too, like cgdb, which even has source displaying with syntax highlight for example, among others. -- Leandro Lucarella Integratech S.A. 4571-5252The built-in help to gdb isn't bad either.. though sometimes hard to find stuff in.I missed the 'info registers' command because gdb doesn't list 'info' when you type 'help' on its command prompt. Thanks for the tip.
Jan 29 2007
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Walter Bright schrieb am 2007-01-28:Thomas Kuehne wrote:info registers info float info vectorWalter Bright schrieb am 2007-01-28: [...]No, I've never heard of them. Insight isn't on my machine. ddd is, and looks interesting. I'll try it.But the worst thing about linux development is gdb. gdb's user interface seems stuck in 1983 era thinking.Have you tried "insight" or "ddd"?There are a bunch of registers, I have to list them one at a time. It's pretty miserable if you're single stepping trying to keep an eye on the register contents. Every other debugger I've ever used, going back to the 70's, could either dump all regs with a shorter command, or had a window where the reg values were continuously updated.I can't even get the thing to display the register contents.print $ebp print $eaxrun `cat file_containing_all_your_arguments` or start GDB with gdb --args your_binary some argument Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFvH2ILK5blCcjpWoRAtrIAJwMIuzjCCWSTp+dZEhReHZr2XPGMACaA5GL WFKOb6fu7u3HhbbkofAltBs= =sKof -----END PGP SIGNATURE-----Where this falls down is when you've a long list of arguments to the program. I'll write a simple .bat file like: windbg program arg arg arg ... to run the debugger with the args. Doesn't work with gdb, because gdb doesn't pick up debuggee args from the command line, making gdb very tedious to use.It won't pick up the program arguments from the command line.run what ever argument
Jan 28 2007
GDB is simply unintuitive and problematic to use. Of course it has thousand commands able to display anything - but entering them is just a way to waste the time. For example hp-ux gdb equivalent has a lot better text mode interface - similar to the "windowed" debuggers.
Jan 28 2007
Walter Bright escribió:Thomas Kuehne wrote:DDD has an ugly interface, but it's one of the best debuggers I know, because it unique (AFAIK) feature to show the memory structures graphically. -- Leandro Lucarella Integratech S.A. 4571-5252Walter Bright schrieb am 2007-01-28: [...]No, I've never heard of them. Insight isn't on my machine. ddd is, and looks interesting. I'll try it.But the worst thing about linux development is gdb. gdb's user interface seems stuck in 1983 era thinking.Have you tried "insight" or "ddd"?
Jan 29 2007
Walter Bright wrote:Bob W wrote:(I agree its an ugly interface.) One thing I like though is the command history -- like most programs in Linux, you have 'readline', which means if you use 'control-R' you can search all previous commands for some string, for example. Other things were answered already, heres some assorted stuff... You can do a "display" to print some value after every command: display $eax display s.c_str() I recommend this, it makes structures readable: set print pretty on Also, "gdb -x filename", tells it to run some file as a startup script. This is a good place to put long command lines and special stuff like this (these are just some examples; the stuff after -- is my comment, I don't know if gdb accepts a comment marker of any kind. rbreak SomeClass:: -- break on all members of a class, takes a regex rbreak __cxa -- this stops at all the exception handling in C++ break main set print pretty on -- readable classes - dont know why its not default open (command) run (arguments) Keving++ is a slow compiler, and ld is a really slow linker, and I'm just more used to windows quirks than linux quirks. But the worst thing about linux development is gdb. gdb's user interface seems stuck in 1983 era thinking. I can't even get the thing to display the register contents. It won't pick up the program arguments from the command line. Either I'm stupid, all this is missing from the documentation, or gdb really is terrible. I do all my debugging on windows. Even horrible old windbg is a decade ahead of gdb. I do like gcov, though...........Sounds like you work under Windows... :o)Yep, looks like he does (mostly) :).He is a smart guy who probably does not feel like beta testing operating systems. Or maybe he just ran out of coffee too often while waiting for penguin's favorite compiler and linker to finish their jobs .... ;-)
Jan 28 2007
Walter Bright wrote:Bob W wrote:True, but now there's zero: www.zero-bugs.com.g++ is a slow compiler, and ld is a really slow linker, and I'm just more used to windows quirks than linux quirks. But the worst thing about linux development is gdb. gdb's user interface seems stuck in 1983 era thinking. I can't even get the thing to display the register contents. It won't pick up the program arguments from the command line. Either I'm stupid, all this is missing from the documentation, or gdb really is terrible. I do all my debugging on windows. Even horrible old windbg is a decade ahead of gdb...........Sounds like you work under Windows... :o)Yep, looks like he does (mostly) :).He is a smart guy who probably does not feel like beta testing operating systems. Or maybe he just ran out of coffee too often while waiting for penguin's favorite compiler and linker to finish their jobs .... ;-)I do like gcov, though.And gprof too. Andrei
Jan 28 2007
Andrei Alexandrescu (See Website For Email) wrote:True, but now there's zero: www.zero-bugs.com.But it's not open source :( Luís
Feb 01 2007
"Walter Bright" <newshound digitalmars.com> wrote in message news:epekud$128$1 digitaldaemon.com...Fixes mixin gc bug. http://www.digitalmars.com/d/changelog.html http://ftp.digitalmars.com/dmd.1.004.zipStill another one mixin bug - causes dmd to crash. (dmd versions: 1.00, 1.002, 1.004) Tried to simplify it as much as I could: template Mix() { int i; } struct Z { // use unions or structs ... union { mixin Mix; } // ... both cause dmd to crash };
Jan 27 2007
Here is a problem I've found in post-1.00 versions. I have this unittest in my library: unittest { char[] c = "Computer"; ArrayCopy!(char)(c, 3, c, 2, 4); assert(c == "Coputeer"); c = "Computer"; ArrayCopy!(char)(c, 2, c, 3, 4); assert(c == "Commputr"); } I have not changed the ArrayCopy function for months and when I updated from 1.00, the second assert started failing. After some work, I tracked down the problem. This line: c = "Computer"; is not doing anything. I put printf(c) right after that assignment, and it prints "Coputeer". I didn't test 1.002, but it is broken in 1.001, 1.003, and 1.004. (I love built-in unittests) The ArrayCopy function: void ArrayCopy(T)(T[] srcData, uint srcStart, T[] destData, uint destStart, uint length) { if((srcData is destData && srcStart == destStart) || length == 0) return; if(srcStart > destStart) { //copy forward for(int i = 0; i < length; ++i) destData[destStart + i] = srcData[srcStart + i]; } else { //copy reverse for(int i = length-1; i >= 0; --i) destData[destStart + i] = srcData[srcStart + i]; } }
Jan 27 2007
Jordan Miner wrote:Here is a problem I've found in post-1.00 versions.What's happening is you're writing into the string literal, which is not allowed. String literals should be regarded as readonly. Post-1.00 versions combine identical string literals, which is why you see the error.
Jan 27 2007
Walter Bright wrote:What's happening is you're writing into the string literal, which is not allowed. String literals should be regarded as readonly.So is there a reasonable way for D to enforce this? I haven't been following the recent const discussion in detail. Would it help here and actually be applied to literal strings in a future D? -Jeff
Jan 27 2007
Jeff Nowakowski wrote:Walter Bright wrote:This is enforced on Linux but not Win32. I suspect this means it's an OS feature that Windows doesn't provide, but I've never heard anyone say for sure either way. SeanWhat's happening is you're writing into the string literal, which is not allowed. String literals should be regarded as readonly.So is there a reasonable way for D to enforce this? I haven't been following the recent const discussion in detail. Would it help here and actually be applied to literal strings in a future D?
Jan 27 2007
Walter Bright Wrote:Jordan Miner wrote:I guess I thought that literals were allocated at runtime. Must have used Ruby too much...nothing wrong with changing its literals. I almost would like D's literals to be that way, but I can't think of a time that I'd actually want to change a literal, so it definitely wouldn't be worth the overhead. Sorry for the mistake.Here is a problem I've found in post-1.00 versions.What's happening is you're writing into the string literal, which is not allowed. String literals should be regarded as readonly. Post-1.00 versions combine identical string literals, which is why you see the error.
Jan 27 2007
"Walter Bright" <newshound digitalmars.com> wrote in message news:epgokh$2q2p$1 digitaldaemon.com...Jordan Miner wrote:Shouldn't string literals be forced "const"? Even D's limited const could do that. To create a mutable copy you'd be forced to used .dup. const char[] either = "asdfsadf"; char[] or = "asdfsd".dup; L.Here is a problem I've found in post-1.00 versions.What's happening is you're writing into the string literal, which is not allowed. String literals should be regarded as readonly. Post-1.00 versions combine identical string literals, which is why you see the error.
Jan 27 2007
Lionello Lunesu a écrit :"Walter Bright" <newshound digitalmars.com> wrote in message news:epgokh$2q2p$1 digitaldaemon.com...Agreed! There's really not reason to create such blatant trap in D.. renoXJordan Miner wrote:Shouldn't string literals be forced "const"? Even D's limited const could do that.Here is a problem I've found in post-1.00 versions.What's happening is you're writing into the string literal, which is not allowed. String literals should be regarded as readonly. Post-1.00 versions combine identical string literals, which is why you see the error.To create a mutable copy you'd be forced to used .dup. const char[] either = "asdfsadf"; char[] or = "asdfsd".dup; L.
Jan 28 2007
"Lionello Lunesu" <lionello lunesu.remove.com> wrote in message news:ephjmf$12sd$1 digitaldaemon.com...Shouldn't string literals be forced "const"? Even D's limited const could do that. To create a mutable copy you'd be forced to used .dup. const char[] either = "asdfsadf"; char[] or = "asdfsd".dup;That wouldn't help, because even if you pass a const char[] into a function that takes a char[], that function can still modify it. The const goes away.
Jan 28 2007
"Jarrett Billingsley" <kb3ctd2 yahoo.com> wrote in message news:epikg9$2lmu$1 digitaldaemon.com..."Lionello Lunesu" <lionello lunesu.remove.com> wrote in message news:ephjmf$12sd$1 digitaldaemon.com...Perhaps, but at least assignments of string literals to variables would be clearly marked as const, and functions written with Copy On Write in mind would have no problems with const strings passed to them. L.Shouldn't string literals be forced "const"? Even D's limited const could do that. To create a mutable copy you'd be forced to used .dup. const char[] either = "asdfsadf"; char[] or = "asdfsd".dup;That wouldn't help, because even if you pass a const char[] into a function that takes a char[], that function can still modify it. The const goes away.
Jan 28 2007
Jarrett Billingsley wrote:"Lionello Lunesu" <lionello lunesu.remove.com> wrote in message news:ephjmf$12sd$1 digitaldaemon.com...I sincerely hope that passing a const T through an api asking for a T will be illegal once D starts to grow some const abilities. If not, what's the point of the const declaration? So, the above will definitely help. Later, BradShouldn't string literals be forced "const"? Even D's limited const could do that. To create a mutable copy you'd be forced to used .dup. const char[] either = "asdfsadf"; char[] or = "asdfsd".dup;That wouldn't help, because even if you pass a const char[] into a function that takes a char[], that function can still modify it. The const goes away.
Jan 28 2007
Jarrett Billingsley wrote:"Lionello Lunesu" <lionello lunesu.remove.com> wrote in message news:ephjmf$12sd$1 digitaldaemon.com...This was kind of "forced by design" because const was a storage class not allowed in function arguments. D will do the right thing as soon as it gets full-fledged const. AndreiShouldn't string literals be forced "const"? Even D's limited const could do that. To create a mutable copy you'd be forced to used .dup. const char[] either = "asdfsadf"; char[] or = "asdfsd".dup;That wouldn't help, because even if you pass a const char[] into a function that takes a char[], that function can still modify it. The const goes away.
Jan 28 2007
On Sat, 27 Jan 2007 16:35:23 -0500, Jordan Miner wrote:Here is a problem I've found in post-1.00 versions. I have this unittest in my library: unittest { char[] c = "Computer"; ArrayCopy!(char)(c, 3, c, 2, 4); assert(c == "Coputeer"); c = "Computer"; ArrayCopy!(char)(c, 2, c, 3, 4); assert(c == "Commputr"); }Does this work for you? unittest { char[] c = "Computer".dup; // Take a copy of the string literal. ArrayCopy!(char)(c, 3, c, 2, 4); assert(c == "Coputeer"); c = "Computer"; ArrayCopy!(char)(c, 2, c, 3, 4); assert(c == "Commputr"); } I suspect that you are trying to (inadvertantly) modify a string literal. -- Derek Parnell
Jan 27 2007
Derek Parnell Wrote:On Sat, 27 Jan 2007 16:35:23 -0500, Jordan Miner wrote:Yes, I've fixed it now by putting a .dup on the literal both times before assigning it to c.Here is a problem I've found in post-1.00 versions. I have this unittest in my library: unittest { char[] c = "Computer"; ArrayCopy!(char)(c, 3, c, 2, 4); assert(c == "Coputeer"); c = "Computer"; ArrayCopy!(char)(c, 2, c, 3, 4); assert(c == "Commputr"); }Does this work for you? unittest { char[] c = "Computer".dup; // Take a copy of the string literal. ArrayCopy!(char)(c, 3, c, 2, 4); assert(c == "Coputeer"); c = "Computer"; ArrayCopy!(char)(c, 2, c, 3, 4); assert(c == "Commputr"); } I suspect that you are trying to (inadvertantly) modify a string literal. -- Derek Parnell
Jan 27 2007
Walter Bright wrote:Fixes mixin gc bug. http://www.digitalmars.com/d/changelog.html http://ftp.digitalmars.com/dmd.1.004.zipshootout.binarytrees (http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=dig italmars.D&artnum=43991) with gc is still very slow (only marginal improvement since 0.173): DMD 0.173 - full GC : 19.720 sec DMD 1.004 - full GC : 17.971 sec It seems like only generational GC (or maybe some other novel GC technology) could help in this case. -- I would love to change the world, but they won't give me the source code...
Jan 28 2007