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 )

"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

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

"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

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

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

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

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

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