"Russell Borogove" <kaleja@estarcion.com> wrote in message
news:3C9F65C6.9070101@estarcion.com...
<SNIP>
>
> Gosh, this almost seems like another use for classes
> and operator overloading.
>
> -Russell B
>

LOL  :)

--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a7hpv4$145g$1@digitaldaemon.com...
> > > > One poster noted that the run time model for D currently prohibits
its
> > > running
> > > > on 64 bit systems (more properly on systems that allow greater than
32
> > bit
> > > pointers).

This was an error in the documentation. D will work fine with 64 bit pointers.

> > > Another usefull type: an intptr type being an integer garanted large
> > enough
> > > to contain a pointer on the target plateform.

Yes, there should be an import with typedefs in it <g>.

> For systems programming, pointer arithmetic is fairly crucial.  I hear D aims to be a systems programming language.  And I want everything to be easier.  ;)

LOL. In my experience, and in working on other peoples' code, I constantly
find sort implemented and reimplemented, sometimes multiple times in the
same program. Some people do use qsort(), but (at least I) always have to
look up the man page on qsort(), and always have to carefully construct the
right compare() function for it, then test that I put the right number of
*'s on the pointers to it, etc. Even going through all that, it isn't thread
safe if compare() needs additional info.

But in looking at qsort(), all it can sort are arrays. So why not build in a sort as part of an array? Voila, in D,

    type[] array;
    ...
    array.sort;        // sort it

That's all.

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a7nuas$2p23$1@digitaldaemon.com...
> Sure there's that nifty ideal of highly portable and maintainable very
clean
> code... and then there's code that's written in the real world, that actually gets the work done.  The ideal is neat, and I commend anyone who tries to approach it, but face it; it's not possible to make most programs 100% clean.

I like a practical person. I've ported a lot of code between systems, and it really isn't necessary to have your code 100% portable to do it. Just put the code that changes in a separate module and reimplement that module for each platform. No big deal, and I'm not willing to sacrifice performance to the gods of ANSI clean and 100% portable code <g>.

(One horrible thing I do is vptr jamming to change the type of a variant. Naturally, where the vptr is stored varies from compiler to compiler, but I just have a special function to do that and reimplement it for each compiler/system. No biggie.)