www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD 1.004 release

reply Walter Bright <newshound digitalmars.com> writes:
Fixes mixin gc bug.

http://www.digitalmars.com/d/changelog.html

http://ftp.digitalmars.com/dmd.1.004.zip
Jan 26 2007
next sibling parent "Chris Miller" <chris dprogramming.com> writes:
Changelog need update?
Jan 26 2007
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Fixes mixin gc bug.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.004.zip
Amazing 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 line 
316 in file 'toobj.c'
 abnormal program termination
when I try to compile. --bb
Jan 26 2007
next sibling parent "Chris Miller" <chris dprogramming.com> writes:
On Fri, 26 Jan 2007 23:58:56 -0500, Bill Baxter  =

<dnewsgroup billbaxter.com> wrote:

 Walter Bright wrote:
 Fixes mixin gc bug.
  http://www.digitalmars.com/d/changelog.html
  http://ftp.digitalmars.com/dmd.1.004.zip
Amazing 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=
line =
   316 in file 'toobj.c'
  > abnormal program termination

 when I try to compile.

 --bb
Yep, 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
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 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.
Yay! All happy now. --bb
Jan 26 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:
 Walter Bright wrote:
 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.
Yay! All happy now.
I've automated much of the process of creating an update, but there's still maddening places where I can overlook something.
Jan 26 2007
next sibling parent Vladimir <vlasov scatt.com> writes:
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
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Bill Baxter wrote:
 Walter Bright wrote:
 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.
Yay! All happy now.
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) Andrei
Jan 27 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Andrei Alexandrescu (See Website For Email) 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.
Sounds like you work under Windows... :o)
---- 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) :).
Jan 27 2007
parent reply "Bob W" <nospam aol.com> writes:
 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
parent reply Walter Bright <newshound digitalmars.com> writes:
Bob W wrote:
 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 .... ;-)
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.
Jan 27 2007
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----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 $eax
 It won't pick up the program arguments from the command line.
run what ever argument
 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. Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFFvGx5LK5blCcjpWoRArM2AJ4y8Cd/8qcwcHBjtkYS0y+anwY04gCeLwkv wy4dSHELEC/YIs5A6d+j8SM= =5v6G -----END PGP SIGNATURE-----
Jan 28 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Thomas Kuehne wrote:
 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"?
No, I've never heard of them. Insight isn't on my machine. ddd is, and looks interesting. I'll try it.
 I can't even get the thing to display the register contents.
print $ebp print $eax
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.
 It won't pick up the program arguments from the command line.
run what ever argument
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.
 
 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.
I didn't know that. You'd think: gdb --help would have provided this information. Thanks for the pointers.
Jan 28 2007
next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
 I can't even get the thing to display the register contents.
print $ebp print $eax
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.
(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.
 It won't pick up the program arguments from the command line.
run what ever argument
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.
Also: $ gdb --args programtodebug arg1 arg2 arg3
 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.
I didn't know that. You'd think: gdb --help would have provided this information. Thanks for the pointers.
The built-in help to gdb isn't bad either.. though sometimes hard to find stuff in. Later, Brad
Jan 28 2007
parent reply Walter Bright <newshound digitalmars.com> writes:
Brad Roberts wrote:
 I can't even get the thing to display the register contents.
print $ebp print $eax
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.
(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.
 It won't pick up the program arguments from the command line.
run what ever argument
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.
Also: $ gdb --args programtodebug arg1 arg2 arg3
That's good to know.
 
 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.
I didn't know that. You'd think: gdb --help would have provided this information. Thanks for the pointers.
The 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 28 2007
parent Leandro Lucarella <llucarella integratech.com.ar> writes:
Walter Bright escribió:
 The 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.
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-5252
Jan 29 2007
prev sibling next sibling parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright schrieb am 2007-01-28:
 Thomas Kuehne wrote:
 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"?
No, I've never heard of them. Insight isn't on my machine. ddd is, and looks interesting. I'll try it.
 I can't even get the thing to display the register contents.
print $ebp print $eax
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.
info registers info float info vector
 It won't pick up the program arguments from the command line.
run what ever argument
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.
run `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-----
Jan 28 2007
prev sibling next sibling parent Daniel Kos <unodgs pac.pl> writes:
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
prev sibling parent Leandro Lucarella <llucarella integratech.com.ar> writes:
Walter Bright escribió:
 Thomas Kuehne wrote:
 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"?
No, I've never heard of them. Insight isn't on my machine. ddd is, and looks interesting. I'll try it.
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-5252
Jan 29 2007
prev sibling next sibling parent Kevin Bealer <kevinbealer gmail.com> writes:
Walter Bright wrote:
 Bob W wrote:
 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 .... ;-)
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.
(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) Kevin
Jan 28 2007
prev sibling parent reply "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Walter Bright wrote:
 Bob W wrote:
 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 .... ;-)
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.
True, but now there's zero: www.zero-bugs.com.
 I do like gcov, though.
And gprof too. Andrei
Jan 28 2007
parent =?ISO-8859-1?Q?Lu=EDs_Marques?= <luismarques gmail.com> writes:
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
prev sibling next sibling parent "Bob W" <nospam aol.com> writes:
"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.zip
Still 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
prev sibling next sibling parent reply Jordan Miner <jminer2613 no.spam.students.pcci.edu> writes:
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
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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
next sibling parent reply Jeff Nowakowski <jeff dilacero.org> writes:
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
parent Sean Kelly <sean f4.ca> writes:
Jeff Nowakowski wrote:
 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?
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. Sean
Jan 27 2007
prev sibling next sibling parent Jordan Miner <jminer2613 no.spam.students.pcci.edu> writes:
Walter Bright Wrote:

 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.
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.
Jan 27 2007
prev sibling parent reply "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Walter Bright" <newshound digitalmars.com> wrote in message 
news:epgokh$2q2p$1 digitaldaemon.com...
 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.
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.
Jan 27 2007
next sibling parent renoX <renosky free.fr> writes:
Lionello Lunesu a écrit :
 "Walter Bright" <newshound digitalmars.com> wrote in message 
 news:epgokh$2q2p$1 digitaldaemon.com...
 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.
Shouldn't string literals be forced "const"? Even D's limited const could do that.
Agreed! There's really not reason to create such blatant trap in D.. renoX
 To create a mutable copy you'd be forced to used .dup.
 
 const char[] either = "asdfsadf";
 char[] or = "asdfsd".dup;
 
 L. 
 
 
Jan 28 2007
prev sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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
next sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"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...
 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.
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.
Jan 28 2007
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
Jarrett Billingsley wrote:
 "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.
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, Brad
Jan 28 2007
prev sibling parent "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail erdani.org> writes:
Jarrett Billingsley wrote:
 "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.
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. Andrei
Jan 28 2007
prev sibling parent Derek Parnell <derek psych.ward> writes:
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
prev sibling next sibling parent Jordan Miner <jminer2613 no.spam.students.pcci.edu> writes:
Derek Parnell Wrote:

 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
Yes, I've fixed it now by putting a .dup on the literal both times before assigning it to c.
Jan 27 2007
prev sibling parent "Andrey Khropov" <andkhropov_nosp m_mtu-net.ru> writes:
Walter Bright wrote:

 Fixes mixin gc bug.
 
 http://www.digitalmars.com/d/changelog.html
 
 http://ftp.digitalmars.com/dmd.1.004.zip
shootout.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