• Mick_K (58/58) Jul 01 2002 Hi, newbie to D, but been in embedded/realime C/C++ for years blah blah
• Syd Barrett (13/18) Jul 01 2002 of
• Sandor Hojtsy (16/24) Jul 05 2002 with
• anderson (47/104) Jul 02 2002 90% or of the things you mentioned are already implemented in D, and
• anderson (7/23) Jul 02 2002 of
• Mick (69/144) Jul 02 2002 Well, if I was wise, I would shut up now, but I'll respond purely
• anderson (21/40) Jul 02 2002 That is planned, I think there something in the specs about that. It's
• anderson (4/5) Jul 02 2002 str4 = str1[0..4] ~ str2[2..6] ~ str3[str3.length-5..str3.length-1];
• Sean L. Palmer (27/70) Jul 02 2002 older
• anderson (2/6) Jul 02 2002 You're right, of coarse exceptions can't be removed from the release. Wh...
• Sean L. Palmer (48/106) Jul 02 2002 This has been discussed before.

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 )

"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

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

too,
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

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

There have been several lengthy threads about improving the handling of
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

"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

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

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

with
 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

"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

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

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

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)

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

featured
 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

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

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

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 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),

and
 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/.

"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

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;
Array[Array.length-1] = NewValue;

or

Array ~= NewValue;

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

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


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

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)

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)

D Garbage collection is variable, as memory gets more scarce, it works
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

featured
 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

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

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

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 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

"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



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.

 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.

"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.

"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

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" :)

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

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

think
 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

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.

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



like
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


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?) :)

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

"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?

"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

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

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

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)

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

featured
 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

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

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

c++?
 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),

and
 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