www.digitalmars.com         C & C++   DMDScript  

D - Newbies Question, and Humble Suggestions

reply Mick_K <Mick_K_member pathlink.com> writes:
Hi, newbie to D, but been in embedded/realime C/C++ for years blah blah

A few things that would be nice (forgive me if they are already in:

* Dynamic arrays - give a growth/shrinkage factor in the object 
(maybe default 1)
I would prefer my int array grows by 4 in some cases, as I only have to
do a memory realloc a quarter of the time etc  
The .length can always return the real number of elements in the array.
* 256 bit ints - Add them to the language.  (or even better, allow a way of
defining any sized int, eg int_256, int_512 etc.)  I see no reason not too, 
and  a) i think it could be useful and b) ive needed them at times
* pragmas etc - keep em fully! useful for telling the compiler to optimise in
certain ways (optimise small, optimise fast, optimisation options, on 
functions or blocks of code.  (also Useful for projects where management
is scared of the general use of the -O flag, but you have to 
optimise inner loops anyway)
* Garbage collection - is there a way to set the desirable memory limits?
Id prefer the garbage collector to kick in at 1-2 megabytes, not at 200.
(think now low memory systems, they are more common than you think!  
Including PDA's)
* Strings - Make the default string class better and easier and more featured
that basic/c++!  Its surprising how often we use strings, but c++ in
general has underpowered string support.
* obviously keep volatile flag
* has some kind of (I know you hate em) define for debugging, along the lines
of __FILE__, __LINE__, but add __FUNCTION_NAME__, __CLASS__, __VERSION__ and
__FULL_INFO___ (which might have FILE:VERSION:CLASS:FUNCTION:LINE )
A __Class_ID__ would also be nice, as a 128 bit int, which might be a hash etc
of the class name - this would be useful for streaming applications etc
* is there anyway to do an atomic operation?   
eg int result =  atomic_set_if_zero( myvariable, myId );  
// if myvariable is zero, set to myId, otherwise leave alone
// return value after in result
It is very useful and fast for multithreaded operations, and many 
processors have this built in to the instruction set etc
* int is defined as 32 bits.  All well and good.  Could you add a variable
type which is the fastest int for this machine? (32 bits and above).
If I am ultra optimising code, I would prefer the optimum respresentation.
(some 64 bits processors have to put in extra asm code for 32 bit, eg
assign 64 bit int = (32 bit int, then 
(sign extend instruction, or clear upper 32 bits instrucion)  ) as an
example.

To a lesser degree:

* does exceptions increase code size and dramaticly hit performance like c++?
Can it be turned off in certain cases/functions etc?
* Always remember small and fast.  Java is large (memory footprint etc), and
I feel underpowered.  (and dont get me started on how they screwed the
GUI) ;-)
* intrinsic checking for bad free/demallocs or memory overwrite or
double deallocation?  
* Will there be an option to check memory access?  (array bounds checking,
stack pointer checking, anything else paranoid) that can be turned on when
tracking down a bug....  (thinking Purify-ish here)

Anyway, those are my suggestions/crazed mumblings,

To all of you, great idea, keep up the good work, all the best!

Regards,
Mick K.


(p.s.  When the language is a little more grounded, put me down for
writing boost like libraries.  (www.boost.com) happy to help )
Jul 01 2002
next sibling parent reply "Syd Barrett" <sydbarrett74%REMOVE%THIS% hotmail.com> writes:
"Mick_K" <Mick_K_member pathlink.com> wrote in message
news:afqa38$373$1 digitaldaemon.com...
 * 256 bit ints - Add them to the language.  (or even better, allow a way

 defining any sized int, eg int_256, int_512 etc.)  I see no reason not

I think that we should add this as a supplemental class (like Java does with the BigInteger class).
 * Strings - Make the default string class better and easier and more

 that basic/c++!  Its surprising how often we use strings, but c++ in
 general has underpowered string support.

strings. Jump in! --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.372 / Virus Database: 207 - Release Date: 6/25/2002
Jul 01 2002
parent "Sandor Hojtsy" <hojtsy index.hu> writes:
"Syd Barrett" <sydbarrett74%REMOVE%THIS% hotmail.com> wrote in message
news:afralu$rkt$1 digitaldaemon.com...
 "Mick_K" <Mick_K_member pathlink.com> wrote in message
 news:afqa38$373$1 digitaldaemon.com...
 * 256 bit ints - Add them to the language.  (or even better, allow a way

 defining any sized int, eg int_256, int_512 etc.)  I see no reason not

I think that we should add this as a supplemental class (like Java does

 the BigInteger class).

Hmm, than will be stuck with: BigInteger a = new Biginteger("2345897623523457892348976"), b = new Biginteger("2345897623523457892348976"), c = a.add(b).mul(b); instead of Biginteger a = "2345897623523457892348976", b = "2345897623523457892348976", c = (a + b) * b; Now which do you like better? It would also solve the problem, if D was extended to support such syntax for classes. Yours, Sandor
Jul 05 2002
prev sibling next sibling parent reply "anderson" <anderson firestar.com.au> writes:
90% or of the things you mentioned are already implemented in D, and
probably in a much better way then you suggested.

Please read, a bit more www.digitalmars.com/d/ especially the comparisons of
C with D www.digitalmars.com/d/ctod.html

See below

"Mick_K" <Mick_K_member pathlink.com> wrote in message
news:afqa38$373$1 digitaldaemon.com...
 Hi, newbie to D, but been in embedded/realime C/C++ for years blah blah

 A few things that would be nice (forgive me if they are already in:

 * Dynamic arrays - give a growth/shrinkage factor in the object
 (maybe default 1)

Most Arrays in D are dynamic. You can resize by either Array.length = Array.length + 1
 I would prefer my int array grows by 4 in some cases, as I only have to
 do a memory realloc a quarter of the time etc
 The .length can always return the real number of elements in the array.

D doesn't do this, but there's a big disscusion about it on this newsgroup. Most people agree that D should use some type of block array technique.
 * 256 bit ints - Add them to the language.  (or even better, allow a way

 defining any sized int, eg int_256, int_512 etc.)  I see no reason not

 and  a) i think it could be useful and b) ive needed them at times

512 doesn't fit well into memory! Here are D's data types http://www.digitalmars.com/d/type.html
 * pragmas etc - keep em fully! useful for telling the compiler to optimise

 certain ways (optimise small, optimise fast, optimisation options, on
 functions or blocks of code.  (also Useful for projects where management
 is scared of the general use of the -O flag, but you have to
 optimise inner loops anyway)

No comment.
 * Garbage collection - is there a way to set the desirable memory limits?
 Id prefer the garbage collector to kick in at 1-2 megabytes, not at 200.
 (think now low memory systems, they are more common than you think!
 Including PDA's)

D Garbage collection is variable, as memory gets more scarce, it works harder to clean up memory. It's very effecient.
 * Strings - Make the default string class better and easier and more

 that basic/c++!  Its surprising how often we use strings, but c++ in
 general has underpowered string support.

D's array strings are so good that a string class is not needed.
 * has some kind of (I know you hate em) define for debugging, along the

 of __FILE__, __LINE__, but add __FUNCTION_NAME__, __CLASS__, __VERSION__

 __FULL_INFO___ (which might have FILE:VERSION:CLASS:FUNCTION:LINE )
 A __Class_ID__ would also be nice, as a 128 bit int, which might be a hash

 of the class name - this would be useful for streaming applications etc

Check out D's Versioning for some of those things. I forget where, but D also has the property classinfo, which has properties such as class name. Note that D no longer supports macros (which is a good thing).
 * is there anyway to do an atomic operation?
 eg int result =  atomic_set_if_zero( myvariable, myId );
 // if myvariable is zero, set to myId, otherwise leave alone
 // return value after in result
 It is very useful and fast for multithreaded operations, and many
 processors have this built in to the instruction set etc

//Even C could do that int result = (myvariable == 0)?(myvariable = myID):myvariable;
 * int is defined as 32 bits.  All well and good.  Could you add a variable
 type which is the fastest int for this machine? (32 bits and above).
 If I am ultra optimising code, I would prefer the optimum respresentation.
 (some 64 bits processors have to put in extra asm code for 32 bit, eg
 assign 64 bit int = (32 bit int, then
 (sign extend instruction, or clear upper 32 bits instrucion)  ) as an
 example.

D's specification is designed in such a way that it allows complier vendors great freedoms in optimising there compliers in situations such as mentioned.
 To a lesser degree:

 * does exceptions increase code size and dramaticly hit performance like

 Can it be turned off in certain cases/functions etc?

No, exceptions can be done in debug time, so when you do a release compile, there's all taken out. Note that only a debug version of the complier is currently available.
 * Always remember small and fast.  Java is large (memory footprint etc),

 I feel underpowered.  (and dont get me started on how they screwed the
 GUI) ;-)

That's D, it's has the ability to be even faster then C.
 * intrinsic checking for bad free/demallocs or memory overwrite or
 double deallocation?

The GC takes care of most of these problems.
 * Will there be an option to check memory access?  (array bounds checking,
 stack pointer checking, anything else paranoid) that can be turned on when
 tracking down a bug....  (thinking Purify-ish here)

It's on in debug mode (I think).
 Anyway, those are my suggestions/crazed mumblings,

 To all of you, great idea, keep up the good work, all the best!

 Regards,
 Mick K.

I hope that helps
 (p.s.  When the language is a little more grounded, put me down for
 writing boost like libraries.  (www.boost.com) happy to help )

Some people such as the legendary Pavel are aready porting libaries to D. It's a good thing to get in early, before people take up all the easy tasks. Also the D-Journal proposal may be of interest to you check out http://www.thedjournal.com/.
Jul 02 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:afrp3d$1e61$1 digitaldaemon.com...
 90% or of the things you mentioned are already implemented in D, and
 probably in a much better way then you suggested.

 Please read, a bit more www.digitalmars.com/d/ especially the comparisons

 C with D www.digitalmars.com/d/ctod.html

 See below

 "Mick_K" <Mick_K_member pathlink.com> wrote in message
 news:afqa38$373$1 digitaldaemon.com...
 Hi, newbie to D, but been in embedded/realime C/C++ for years blah blah

 A few things that would be nice (forgive me if they are already in:

 * Dynamic arrays - give a growth/shrinkage factor in the object
 (maybe default 1)

Most Arrays in D are dynamic. You can resize by either

Array.length = Array.length + 1; Array[Array.length-1] = NewValue; or Array ~= NewValue;
Jul 02 2002
prev sibling parent reply Mick <Mick_member pathlink.com> writes:
Well, if I was wise, I would shut up now, but I'll respond purely
to be the Shakspearean fool....  (or just rant and make painfully obviously
my ignorance on the D issue) :-)


In article <afrp3d$1e61$1 digitaldaemon.com>, anderson says...
90% or of the things you mentioned are already implemented in D, and
probably in a much better way then you suggested.

Maybe, but not visible with the explanation that you gave. :) If so, excellent.
 I would prefer my int array grows by 4 in some cases, as I only have to
 do a memory realloc a quarter of the time etc
 The .length can always return the real number of elements in the array.

D doesn't do this, but there's a big disscusion about it on this newsgroup. Most people agree that D should use some type of block array technique.

Excellent. Hope it gets put it.
 * 256 bit ints - Add them to the language.  (or even better, allow a way

 defining any sized int, eg int_256, int_512 etc.)  I see no reason not

 and  a) i think it could be useful and b) ive needed them at times


512 doesn't fit well into memory!

Sure it does! Its just bloody big! Yes, a int_512 would require special code for multiplies etc etc, but is that any different from the days when we had 8 bit machines and had to multiply 32 bits? Although I could see the case for "make it into a seperate library", Im guessing thats what the C designers though when they left our 64 bit integers, as well all know its bigger than the registers, and no-one will ever need an integer that big... :-) In fact, as It may be nice to have a reason for people adopting D over older standards (apart from the obvious), why not take the concept further: Implicit language sactioned floats of given size? ie float_512 (or whatever you want to call it), setting a ultra high resolution implicit floating point number directly into the langauge. (For mathematicians, science, fft's, simulations etc) But hey, I suppose that this may be considered a tad outlandish to some/most, and Im well prepared to be "wrong" :)
Here are D's data types
http://www.digitalmars.com/d/type.html

Yeah, I had read them. Was still liking the idea of ints and floats of adjustable (read "real bloody big") size. (or at least, bigger than is currently offered)
 * pragmas etc - keep em fully! useful for telling the compiler to optimise

 certain ways (optimise small, optimise fast, optimisation options, on
 functions or blocks of code.  (also Useful for projects where management
 is scared of the general use of the -O flag, but you have to
 optimise inner loops anyway)

No comment.

Yeah, the other chap mentioned that they shouldnt be in, should be up to the compiler to optimise fully etc. Fair enough, really. I still like being a control freak. :)
 * Garbage collection - is there a way to set the desirable memory limits?
 Id prefer the garbage collector to kick in at 1-2 megabytes, not at 200.
 (think now low memory systems, they are more common than you think!
 Including PDA's)

harder to clean up memory. It's very effecient.

Yeah, was just wondering if you could set an upper bound, ie maybe I want a windows taskbar utility than wont use more than 1 meg of ram etc. But Ill take it as read then that this works.
 * Strings - Make the default string class better and easier and more

 that basic/c++!  Its surprising how often we use strings, but c++ in
 general has underpowered string support.

D's array strings are so good that a string class is not needed.

Oh, so it has a find char/string/substring/regexp? It has simple str4 = str1.left(5) + str2.mid(3,4) + str3.right(6); ???? (without three lines of brackets or more of brackets?) Does it have implicit hash of the string contents? To Upper/toLower? Equals with and without case sensitivity? Maybe basic reg expressions? Optimised store size (ie incrementing size by 16 to speed up small appended sections) Anyway, the moral of the story is: Dont be afraid to offer a standard yet very powerful/beefy base string class which does everything. People will want it, and use it, no matter what Armchair University Zealots have to think about minimalic purity etc
 * has some kind of (I know you hate em) define for debugging, along the

 of __FILE__, __LINE__, but add __FUNCTION_NAME__, __CLASS__, __VERSION__

 __FULL_INFO___ (which might have FILE:VERSION:CLASS:FUNCTION:LINE )
 A __Class_ID__ would also be nice, as a 128 bit int, which might be a hash

 of the class name - this would be useful for streaming applications etc

Check out D's Versioning for some of those things. I forget where, but D also has the property classinfo, which has properties such as class name. Note that D no longer supports macros (which is a good thing).

Cool, yes macros can be done without. And the classinfo property was just what was after.. (add these to the faq) :)
 * is there anyway to do an atomic operation?
 eg int result =  atomic_set_if_zero( myvariable, myId );
 // if myvariable is zero, set to myId, otherwise leave alone
 // return value after in result
 It is very useful and fast for multithreaded operations, and many
 processors have this built in to the instruction set etc

//Even C could do that int result = (myvariable == 0)?(myvariable = myID):myvariable;

Wrong, not multithreaded nor multiprocessor safe. But maybe I should put it another way, and asked what kind of fast threaded mutexing (and other threadsafe components) exists in the language. (fast implicit mutexes are important, doubly so if you're adding a java like synchronized sections etc) But I guess I should have posed the question better. p.s. slightly less dodgy way: inline int atomic_get_set(int & myvariable, int & myId) { if (myvariable == 0) { myvariable ^= myId; /* xor */ if (myvariable == myId) /* make sure not interrupted */ return myId; myvariable ^= myId; /* was interrupted, exit */ } return 0; }
 * int is defined as 32 bits.  All well and good.  Could you add a variable
 type which is the fastest int for this machine? (32 bits and above).
 If I am ultra optimising code, I would prefer the optimum respresentation.
 (some 64 bits processors have to put in extra asm code for 32 bit, eg
 assign 64 bit int = (32 bit int, then
 (sign extend instruction, or clear upper 32 bits instrucion)  ) as an
 example.

D's specification is designed in such a way that it allows complier vendors great freedoms in optimising there compliers in situations such as mentioned.

Excellent.
 * does exceptions increase code size and dramaticly hit performance like

 Can it be turned off in certain cases/functions etc?

No, exceptions can be done in debug time, so when you do a release compile, there's all taken out. Note that only a debug version of the complier is currently available.

Excellent. (another one to be added to faq?) :)
 (p.s.  When the language is a little more grounded, put me down for
 writing boost like libraries.  (www.boost.com) happy to help )


Some people such as the legendary Pavel are aready porting libaries to D.
It's a good thing to get in early, before people take up all the easy tasks.
Also the D-Journal proposal may be of interest to you check out
http://www.thedjournal.com/.

Cool, but apparently templates arent in yet, which may stifle things :) Anyway, what can I say? Well done chaps! Thanks and all the best. Regards, Mick
Jul 02 2002
next sibling parent reply "anderson" <anderson firestar.com.au> writes:
512 doesn't fit well into memory!


What I ment by that is you mite as well use 16-bit and check your own boundaries.
 Yeah, I had read them.  Was still liking the idea of ints and floats of
 adjustable (read "real bloody big") size.  (or at least, bigger than
 is currently offered)

That is planned, I think there something in the specs about that. It's platform dependent I think. You'd be able to find it at runtime like in ada (I could be wrong).
 * Garbage collection - is there a way to set the desirable memory



 Id prefer the garbage collector to kick in at 1-2 megabytes, not at



 (think now low memory systems, they are more common than you think!
 Including PDA's)

harder to clean up memory. It's very effecient.

Yeah, was just wondering if you could set an upper bound, ie maybe I want a windows taskbar utility than wont use more than 1 meg of ram etc. But Ill take it as read then that this works.

It's up to the complier vendor/platform to write something that works well.
D's array strings are so good that a string class is not needed.


Actually now that I re-read that, It's not what I ment. I ment to say that you don't need a string class, because char arrays are greatly improved over C's and still being improved.
 Oh, so it has a find char/string/substring/regexp?

 It has simple str4 = str1.left(5) + str2.mid(3,4) + str3.right(6);    ????

Um, there was talk about a range operation that could be done like this, I don't know if it was implemented or not yet... str4 = str1[5] ~ str2[3..7] ~ str3[str3.length-6];
 (without three lines of brackets or more of brackets?)

 Wrong, not multithreaded nor multiprocessor safe.

D is a very typed language and is designed in such as way to take advantage of multiprocessor machines. It also has multithreading support. I can't expand much an that because I haven't done much C or D threading (although I've done a lot in java a while ago).
 Cool, but apparently templates arent in yet, which may stifle things :)

Yer, Walter was working on them before he when on vacation (the documention side of things). I think they'll be part of 2.0 . Generics and overloading are the two things missing the most from D.
Jul 02 2002
parent "anderson" <anderson firestar.com.au> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:afsciv$23rl$1 digitaldaemon.com...
 str4 = str1[5] ~ str2[3..7] ~ str3[str3.length-6];

str4 = str1[0..4] ~ str2[2..6] ~ str3[str3.length-5..str3.length-1]; But I don't think that'll work.
Jul 02 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"Mick" <Mick_member pathlink.com> wrote in message
news:afs8ts$209g$1 digitaldaemon.com...
 In fact, as It may be nice to have a reason for people adopting D over

 standards (apart from the obvious), why not take the concept further:
 Implicit language sactioned floats of given size?   ie float_512 (or

 you want to call it), setting a ultra high resolution implicit floating
 point number directly into the langauge.
 (For mathematicians, science, fft's, simulations etc)  But hey, I suppose
 that this may be considered a tad outlandish to some/most, and Im well
 prepared to be "wrong" :)

It'd be cool, but probably hard to implement a generic "any sized" multiply and divide routine. You also don't want standard sizes going through such a slow software emulation.
 Yeah, the other chap mentioned that they shouldnt be in, should be up
 to the compiler to optimise fully etc.  Fair enough, really.  I still
 like being a control freak.  :)

I do too, I just don't like being forced to be a control freak to obtain good performance. ;)
 Yeah, was just wondering if you could set an upper bound, ie maybe I want
 a windows taskbar utility than wont use more than 1 meg of ram etc.  But
 Ill take it as read then that this works.

That's a good idea. The GC is a standard module, and there are some functions available to control its behavior.
D's array strings are so good that a string class is not needed.

Oh, so it has a find char/string/substring/regexp?

Those are in the string module I think. I haven't had a use for them yet.
 Anyway, the moral of the story is:  Dont be afraid to offer a standard
 yet very powerful/beefy base string class which does everything.  People

 want it, and use it, no matter what Armchair University Zealots have to

 about minimalic purity etc

The nice thing about being minimalistic is that it makes it much easier to provide working standards-conforming implementations of D. ;)
 * is there anyway to do an atomic operation?
 eg int result =  atomic_set_if_zero( myvariable, myId );
 // if myvariable is zero, set to myId, otherwise leave alone
 // return value after in result
 It is very useful and fast for multithreaded operations, and many
 processors have this built in to the instruction set etc

//Even C could do that int result = (myvariable == 0)?(myvariable = myID):myvariable;

Wrong, not multithreaded nor multiprocessor safe. But maybe I should put it another way, and asked what kind of fast

 mutexing (and other threadsafe components) exists in the language.
 (fast implicit mutexes are important, doubly so if you're adding a java

 synchronized sections etc)  But I guess I should have posed the question
 better.

D has a synchronized attribute keyword that works on methods or variables which generates critical sections (implemented using test-and-set instructions etc). I'm pretty sure you're covered here.
 * does exceptions increase code size and dramaticly hit performance



c++?
 Can it be turned off in certain cases/functions etc?

No, exceptions can be done in debug time, so when you do a release


there's all taken out. Note that only a debug version of the complier is
currently available.

Excellent. (another one to be added to faq?) :)

That is not true. You can't turn off exceptions (they're a core language feature) and the alpha compiler does support optimizations already; it's not debug only. Sean
Jul 02 2002
parent "anderson" <anderson firestar.com.au> writes:
 That is not true.  You can't turn off exceptions (they're a core language
 feature) and the alpha compiler does support optimizations already;  it's
 not debug only.

 Sean

You're right, of coarse exceptions can't be removed from the release. What was I thinking?
Jul 02 2002
prev sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"Mick_K" <Mick_K_member pathlink.com> wrote in message
news:afqa38$373$1 digitaldaemon.com...
 Hi, newbie to D, but been in embedded/realime C/C++ for years blah blah

 A few things that would be nice (forgive me if they are already in:

 * Dynamic arrays - give a growth/shrinkage factor in the object
 (maybe default 1)
 I would prefer my int array grows by 4 in some cases, as I only have to
 do a memory realloc a quarter of the time etc
 The .length can always return the real number of elements in the array.

This has been discussed before.
 * 256 bit ints - Add them to the language.  (or even better, allow a way

 defining any sized int, eg int_256, int_512 etc.)  I see no reason not

 and  a) i think it could be useful and b) ive needed them at times

The routines for multiply and divide get more and more difficult to generate. ;)
 * pragmas etc - keep em fully! useful for telling the compiler to optimise

 certain ways (optimise small, optimise fast, optimisation options, on
 functions or blocks of code.  (also Useful for projects where management
 is scared of the general use of the -O flag, but you have to
 optimise inner loops anyway)

Management should not be telling you whether or not to use -O. Not their business. Use it if it works, otherwise don't. I understand you want to be a control freak and fine-tune everything. Sometimes I do too. But you generally want the compiler to be smart and not force you to micromanage everything.
 * Garbage collection - is there a way to set the desirable memory limits?
 Id prefer the garbage collector to kick in at 1-2 megabytes, not at 200.
 (think now low memory systems, they are more common than you think!
 Including PDA's)

I'm sure the GC on a PDA target will work differently than the one for Win32. ;)
 * Strings - Make the default string class better and easier and more

 that basic/c++!  Its surprising how often we use strings, but c++ in
 general has underpowered string support.

String and dynarray of char are the same thing in D. Yes, string handling is fundamental and should be fully addressed. It's not bad as is (better than C!) but they're still working on improving it I think, making library functions and properties etc.
 * obviously keep volatile flag

As a general "don't optimize accesses" attribute?
 * has some kind of (I know you hate em) define for debugging, along the

 of __FILE__, __LINE__, but add __FUNCTION_NAME__, __CLASS__, __VERSION__

 __FULL_INFO___ (which might have FILE:VERSION:CLASS:FUNCTION:LINE )
 A __Class_ID__ would also be nice, as a 128 bit int, which might be a hash

 of the class name - this would be useful for streaming applications etc

There may be a better way to accomplish streaming.
 * is there anyway to do an atomic operation?
 eg int result =  atomic_set_if_zero( myvariable, myId );
 // if myvariable is zero, set to myId, otherwise leave alone
 // return value after in result
 It is very useful and fast for multithreaded operations, and many
 processors have this built in to the instruction set etc

I think this is planned, if not already present.
 * int is defined as 32 bits.  All well and good.  Could you add a variable
 type which is the fastest int for this machine? (32 bits and above).
 If I am ultra optimising code, I would prefer the optimum respresentation.
 (some 64 bits processors have to put in extra asm code for 32 bit, eg
 assign 64 bit int = (32 bit int, then
 (sign extend instruction, or clear upper 32 bits instrucion)  ) as an
 example.

I'd rather know what sized int I'm getting, and the compiler is always free to cache a value in an "optimal-sized" register if it wants to. You can also make one yourself using alias (the opposite of C's problem... in C, you had to make a typedef just to have fixed-size types)
 To a lesser degree:

 * does exceptions increase code size and dramaticly hit performance like

 Can it be turned off in certain cases/functions etc?

D has a simpler destructor mechanism so stack unwinding is easier. I don't think it's possible to turn it off. All the tricks C++ compilers can do (in theory) to improve exception performance also apply to D.
 * Always remember small and fast.  Java is large (memory footprint etc),

 I feel underpowered.  (and dont get me started on how they screwed the
 GUI) ;-)

I think Walter fully groks this. ;)
 * intrinsic checking for bad free/demallocs or memory overwrite or
 double deallocation?

Checking for bad or double delete should be easy enough in debug builds. Checking for memory overwrite is something either the memory allocator or the OS has to do. Part of it can be inserted by the compiler, and hardware assistance (GPF) helps also.
 * Will there be an option to check memory access?  (array bounds checking,
 stack pointer checking, anything else paranoid) that can be turned on when
 tracking down a bug....  (thinking Purify-ish here)

I think there's already array bounds checking. Surely there has to be stack pointer checking in debug builds or it'd never be safe to write interrupt handlers and callbacks etc.
 Anyway, those are my suggestions/crazed mumblings,

 To all of you, great idea, keep up the good work, all the best!

 Regards,
 Mick K.


 (p.s.  When the language is a little more grounded, put me down for
 writing boost like libraries.  (www.boost.com) happy to help )

It's pretty darn functional already even though it's only got an alpha compiler. There's no template support until D 2.0 so no boost stuff is possible yet. Enjoy! Sean
Jul 02 2002