I've been perusing the docs on D and I must say:  D seems like a breath of fresh air.  Java seems to me to be the worst of both worlds.  On the one hand, it got rid of all the useful features of C and C++ (unions, enumeration, pointers).  On the other hand, it kept much of C/C++'s idiosyncratic syntax, and added undesirable features, like an execution model that leans heavily towards interpretation rather than compilation, with all of the memory and speed penalties therein.  D seems to keep all the stuff that's *right* about C/C++, and improve on things.  Good job!

--
If you hold a Unix shell up to your ear, can you hear the C?

-- unknown


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.363 / Virus Database: 201 - Release Date: 5/22/2002

"Syd Barrett" <sydbarrett74%REMOVE%THIS%@hotmail.com> wrote in message news:acnn1o$9sk$1@digitaldaemon.com...
> I've been perusing the docs on D and I must say:  D seems like a breath of fresh air.  Java seems to me to be the worst of both worlds.  On the one hand, it got rid of all the useful features of C and C++ (unions, enumeration, pointers).  On the other hand, it kept much of C/C++'s idiosyncratic syntax, and added undesirable features, like an execution model that leans heavily towards interpretation rather than compilation, with all of the memory and speed penalties therein.  D seems to keep all
the
> stuff that's *right* about C/C++, and improve on things.  Good job!

Thanks!

Agree with the compliments, apart from D's choice to follow Java/.NET down the non-deterministic destructor (or finalize) model. I think this will kill a lot of interest from C++ people, who's use of "resource aquisition is initialisation" is second nature (not to mention being about the most powerful bang-for-buck object-oriented concept).

:(

Matthew

"Walter" <walter@digitalmars.com> wrote in message news:acohdi$1e3v$1@digitaldaemon.com...
>
> "Syd Barrett" <sydbarrett74%REMOVE%THIS%@hotmail.com> wrote in message news:acnn1o$9sk$1@digitaldaemon.com...
> > I've been perusing the docs on D and I must say:  D seems like a breath
of
> > fresh air.  Java seems to me to be the worst of both worlds.  On the one hand, it got rid of all the useful features of C and C++ (unions, enumeration, pointers).  On the other hand, it kept much of C/C++'s idiosyncratic syntax, and added undesirable features, like an execution model that leans heavily towards interpretation rather than compilation, with all of the memory and speed penalties therein.  D seems to keep all
> the
> > stuff that's *right* about C/C++, and improve on things.  Good job!
>
> Thanks!
>
>

"Matthew Wilson" <mwilson@nextgengaming.com> wrote in message
> Agree with the compliments, apart from D's choice to follow Java/.NET down the non-deterministic destructor (or finalize) model. I think this will
kill
> a lot of interest from C++ people, who's use of "resource aquisition is initialisation" is second nature (not to mention being about the most powerful bang-for-buck object-oriented concept).
>
> :(
>
> Matthew

Indeed. I personally know C++ programmers who would consider going towards D
if not
for the non-deterministic destructors.
Sandor

Same here.

Whilst I am enjoying the occasional play with D, I cannot myself seriously contemplate major commercial developments for this sole reason. Sad, because otherwise I think D has a HUGE chance of being unarguably superior to Java and .NET

"Sandor Hojtsy" <hojtsy@index.hu> wrote in message news:acvid2$1dsa$1@digitaldaemon.com...
> "Matthew Wilson" <mwilson@nextgengaming.com> wrote in message
> > Agree with the compliments, apart from D's choice to follow Java/.NET
down
> > the non-deterministic destructor (or finalize) model. I think this will
> kill
> > a lot of interest from C++ people, who's use of "resource aquisition is initialisation" is second nature (not to mention being about the most powerful bang-for-buck object-oriented concept).
> >
> > :(
> >
> > Matthew
>
> Indeed. I personally know C++ programmers who would consider going towards
D
> if not
> for the non-deterministic destructors.
> Sandor
>
>
>

Matthew Wilson wrote:

> Agree with the compliments, apart from D's choice to follow Java/.NET down the non-deterministic destructor (or finalize) model. I think this will kill a lot of interest from C++ people, who's use of "resource aquisition is initialisation" is second nature (not to mention being about the most powerful bang-for-buck object-oriented concept).

I agree that this is unfortunate.  How would you suggest we fix it?

The problem, as I see it, is not actually the destructor model, but the garbage collector.  It would be horribly inefficient to require the GC to run whenever any object or array reference goes out of scope.

That means that we need some way to signal to the compiler that objects need to be cleaned up immediately.  Walter gives us a manual way to do it, by calling 'delete' on the object, but we do not yet have a way to do it automatically.

As I see it, we have 2 types of class objects that get created:
    1) Temporary objects that should be destroyed when the reference goes out of
scope.  Essentially, these are stack objects - even if they are not actually
created on the stack.  We don't have these in D right now.
    2) Longer term objects that will last an arbitrary length of time.  These
are heap objects, and are all objects right now.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF4E83B.80BDA02E@deming-os.org...

> That means that we need some way to signal to the compiler that objects
need to
> be cleaned up immediately.  Walter gives us a manual way to do it, by
calling
> 'delete' on the object, but we do not yet have a way to do it
automatically.

Delphi requires exactly the same (all objects have to be explicitly
deallocated
by a call to Destroy), and is missing the garbage collector, still it's
very successful. Doing it automatically would complicate things both for the
compiler and for the user ("at what point exactly is this object
deleted?")...

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF4E83B.80BDA02E@deming-os.org...
> Matthew Wilson wrote:
>
> > Agree with the compliments, apart from D's choice to follow Java/.NET
down
> > the non-deterministic destructor (or finalize) model. I think this will
kill
> > a lot of interest from C++ people, who's use of "resource aquisition is initialisation" is second nature (not to mention being about the most powerful bang-for-buck object-oriented concept).
>
> I agree that this is unfortunate.  How would you suggest we fix it?

I also find this to be a large drawback of D.  Unpredictability of finalization sucks.

> The problem, as I see it, is not actually the destructor model, but the
garbage
> collector.  It would be horribly inefficient to require the GC to run
whenever
> any object or array reference goes out of scope.

some objects the compiler could in theory know are going away at the end of a scope (because their references were never sent anywhere "outside" the scope)

> That means that we need some way to signal to the compiler that objects
need to
> be cleaned up immediately.  Walter gives us a manual way to do it, by
calling
> 'delete' on the object, but we do not yet have a way to do it
automatically.

Maybe the difference between:

Object x;

and

new Object x;

or

Object x = null;

> As I see it, we have 2 types of class objects that get created:
>     1) Temporary objects that should be destroyed when the reference goes
out of
> scope.  Essentially, these are stack objects - even if they are not
actually
> created on the stack.  We don't have these in D right now.

This is exactly how structs behave though, provided you don't allocate them
with new.
I noticed you can put member functions in a struct, but not ctors/dtors.  If
we could put ctors/dtors in a struct, we could use struct for these types of
"resource acquisition" objects and class for objects we don't care about as
much, but that seems like a bandaid not a real fix.

>     2) Longer term objects that will last an arbitrary length of time.
These
> are heap objects, and are all objects right now.

Maybe we need an auto keyword.  ;)  auto objects can't have their address taken.

Sean

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ad32t5$11mr$1@digitaldaemon.com...

> This is exactly how structs behave though, provided you don't allocate
them
> with new.
> I noticed you can put member functions in a struct, but not ctors/dtors.
If
> we could put ctors/dtors in a struct, we could use struct for these types
of
> "resource acquisition" objects and class for objects we don't care about
as
> much, but that seems like a bandaid not a real fix.

Besides, this is exactly what Walter is trying to avoid. I even think he didn't add dtors to structs for that reason - because the compiler would then have to run them in all appropriate places.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ad32t5$11mr$1@digitaldaemon.com...
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF4E83B.80BDA02E@deming-os.org...
> > Matthew Wilson wrote:
> >
> > > Agree with the compliments, apart from D's choice to follow Java/.NET
> down
> > > the non-deterministic destructor (or finalize) model. I think this
will
> kill
> > > a lot of interest from C++ people, who's use of "resource aquisition
is
> > > initialisation" is second nature (not to mention being about the most powerful bang-for-buck object-oriented concept).
> >
> > I agree that this is unfortunate.  How would you suggest we fix it?
>
> I also find this to be a large drawback of D.  Unpredictability of finalization sucks.
>


It's not *that* bad!
To me, 99% of the time I do not really care exactly when
the destructor on an object is called, as long as it does
get called eventually. For the 1 percent of the situations
where a timely call of the destructor really is necessary,
you can call delete manually (as you already are forced to
do in Delphi).

But how about this for a solution. COM uses a kind of
reference counting. IUnknown already has methods AddRef()
and Release() to accomodate this. Delphi implements a
kind of syntax sugar where these functions get called for
you automatically, whenever an object enters or exits
scope. Combining these you could make stack-like objects
that free themselves automatically whenever the last
reference to it exits scope. It has the price of a
function call when the objects enters or exits scope,
but that is a small price to pay and should be a
consideration. I don't know how difficult this kind
of syntax sugar is to implement, but it could solve
at least part of the problem.


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