www.digitalmars.com         C & C++   DMDScript  

D - Breath of fresh air

reply "Syd Barrett" <sydbarrett74%REMOVE%THIS% hotmail.com> writes:
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
May 25 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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!
May 25 2002
parent reply "Matthew Wilson" <mwilson nextgengaming.com> writes:
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!
May 27 2002
next sibling parent reply "Sandor Hojtsy" <hojtsy index.hu> writes:
"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
May 28 2002
parent "Matthew Wilson" <mwilson nextgengaming.com> writes:
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
May 28 2002
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
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))) ]
May 29 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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?")...
May 29 2002
prev sibling next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"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
May 29 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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.
May 29 2002
prev sibling next sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"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
May 29 2002
parent reply andy <acoliver apache.org> writes:
 
 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.
 


but then you're tied to a platform.


 
 --
 Stijn
 OddesE_XYZ hotmail.com
 http://OddesE.cjb.net
 _________________________________________________
 Remove _XYZ from my address when replying by mail
May 29 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"andy" <acoliver apache.org> wrote in message
news:3CF52268.3040008 apache.org...


 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.


 but then you're tied to a platform.


Not really. AddRef() and Release() are easily implemented anywhere...

... but then you get a reference-counting based garbage collector, as
seen in VB, with all its problems like cyclic interdependencies...
May 29 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
Some good thoughts. -Walter

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


 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
Jun 09 2002
prev sibling parent reply "anderson" <anderson firestar.com.au> writes:
"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3CF4E83B.80BDA02E deming-os.org...

 Matthew Wilson wrote:


<snip>


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


<snip>


I'd suggest being able to turn the garbage collector on and off. When it is
off, it would be in a danger mode and all removal would have to be done
manaually. Debug mode could still use the GC to detect memory leaks (though
that should also be able to be turned off). Ie it could be turn off during
unnecessary GC's reads between a frame loop, or if part of the program
definately doesn't need it.

It also be good if it had to modes,  deterministic and non-dertimistic
(default). Deterministic would be for advanced programmers and implemented
in the optimisation programming cycle.

Also you should be able to give the GC an estimate of aprox howmuch memory
is needed to be freed at any one time or how long it is to run for. The GC
would stop when goes past this amount.  Programmers could then tweek this to
the applications needs.
May 30 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:ad5bo2$1i9q$1 digitaldaemon.com...


 I'd suggest being able to turn the garbage collector on and off. When it


is

 off, it would be in a danger mode and all removal would have to be done


It is possible to turn off garbage collector. I don't remember the exact
function, just look for it in gc.d.
May 30 2002
parent reply "anderson" <anderson firestar.com.au> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:ad5kch$etn$1 digitaldaemon.com...

 "anderson" <anderson firestar.com.au> wrote in message
 news:ad5bo2$1i9q$1 digitaldaemon.com...




 It is possible to turn off garbage collector. I don't remember the exact
 function, just look for it in gc.d.


I guess most of my suggestions are more like questions.

Then why do they say that it's a turn off for C++ programmers. They don't
get a GC (deterministic or not) at all and they can program the same way in
D.
May 30 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:ad6sbm$19e4$1 digitaldaemon.com...


 Then why do they say that it's a turn off for C++ programmers. They don't
 get a GC (deterministic or not) at all and they can program the same way


in

 D.


The problem is, you still don't get automated clean-up. You have to delete
all objects yourself. It is deterministic, but it's quite a lot to type.

Me, I don't care much. Just got used to Delphi, I suppose, so, when I need
it,
I don't mind calling "delete"...
May 31 2002