www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What language role does D fullfill?

reply clayasaurus <clayasaurus gmail.com> writes:
Ok, I'm just wondering what people think. We all know to use the right 
tool for the right job, so when is D the right tool for the job?

C *******************************************************************

Sucessor to assembly.

Pros:
  - easy to implement compile, hence more x-platform
  - very low level, fast

Cons:
  - hard to master
  - ugly

C++ *******************************************************************

Sucessor to C.

Pros:
  - fast
  - object oriented
  - templates
  - customizable

Cons:
  - all the uglyness of C, with some added uglyness of C++ (templates, 
using the library for everything)

  - hard to implement compiler for

Java *******************************************************************

Sucessor to C++

Pros:
  - x-platform 'binaries'
  - huge library
  - suger
  - garbage collected

Cons:
  - slow

C# *******************************************************************

Note: I really don't know much about C#

Sucessor to Java

Pros:
  - Everything java is plus microsofts stuff

Cons:
  - it is microsoft only, unless you look at mono

---------------------

So, what new thing does D bring to the table that no other language has 
done?

D *******************************************************************

Successor to C, C++, and Java.

Pros:
  - garbage collected (Java/C#)
  - high level with low level retainability (C++)
  - not ugly (Java/C#)
  - easy to implement (none other?)
  - fast (C++)
  - fast compile (none other?)
  - design by contract (none other?)

Cons:
  - not enough exposure / usage
  - not as many libraries as C++ / Java


So, here is what I am seeing D's niche as being...

* A more powerful and easier to implement on different platforms (palm, 
etc.)

* If you want a modern garbage collected language that is fast

All other things seem to be already covered by the other langauges. Am I 
missing something? D seems to be an assimilation language to assimilate 
users from other languages, instead of doing something new on its own.

I know D is poised to compete as a 'C/C++' killer, but too many code is 
already in C/C++ for it to be able to kill those languages off.

D seems to want to compete with Java/C# too, and it can if performance 
and easy implementation is the priority.

While Design by Contract is great, I think it would take a while for 
programmers to use it effectively and realize its benefits, who are not 
used to it from C/C++.

Maybe my point is that right now D is a 'trickle-down' language. Users 
trickle in from all sorts of other languages because D does a few things 
that others cannot do (dbc, native & gc, fast, pretty) all at once.

If D is to be used widely, do we need to add something new? Something 
that no other language can do? (metaprogramming anyone?)

Just my 2 cents.

-------- PS ---------

I switched from C++ to D mainly for one reason only. C++ seems like a 
hack, where as D is more thought out and has more elegant answers to the 
same old problems.
Jun 21 2005
next sibling parent reply Brad Beveridge <brad somewhere.net> writes:
clayasaurus wrote:

 
 I switched from C++ to D mainly for one reason only. C++ seems like a 
 hack, where as D is more thought out and has more elegant answers to the 
 same old problems.

That's the main reason that I prefer D where I can, although it doesn't offer anything amazingly special over C/C++ (well, GC maybe), D is actually nice to write code in. After writing even a little bit of D code and getting used to it, I was loath to go back to a C++ compiler! So for me the difference between C/C++ and D is like the difference between driving a Lada and driving a Merceedes - they both get you where you want to do, but one gets you there in style and comfort :) Brad
Jun 21 2005
next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Brad Beveridge wrote:
 clayasaurus wrote:
 
 I switched from C++ to D mainly for one reason only. C++ seems like a 
 hack, where as D is more thought out and has more elegant answers to 
 the same old problems.

That's the main reason that I prefer D where I can, although it doesn't offer anything amazingly special over C/C++ (well, GC maybe), D is actually nice to write code in. After writing even a little bit of D code and getting used to it, I was loath to go back to a C++ compiler! So for me the difference between C/C++ and D is like the difference between driving a Lada and driving a Merceedes - they both get you where you want to do, but one gets you there in style and comfort :) Brad

Yes. Maybe the whole point of D should just simply be to avoid this... http://www.andromeda.com/people/ddyer/topten.html
Jun 21 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
clayasaurus <clayasaurus gmail.com> wrote:

 http://www.andromeda.com/people/ddyer/topten.html

I never thought of number 9. -manfred
Jun 21 2005
prev sibling next sibling parent Victor Nakoryakov <nail-mail mail.ru> writes:
Brad Beveridge wrote:
 So for me the difference between C/C++ and D is like the difference 
 between driving a Lada and driving a Merceedes - they both get you where 
 you want to do, but one gets you there in style and comfort :)

Yeap, good analogy. However current situation has a drawback. If I drive Lada I know that when it brokes I can visit nearest autoshop and buy broken detail for a $3, if I drive Mercedes I'll have to visit half shops of Moscow just to find detail, and another half to find it cheaper then $1000. So if I'll start big project in D I'ld have to write all for myself and GUI lib, and Math lib, and parsers, and plugins for IDE's, and etc etc. So for now I prefer C++ for money and D for fun... an have to drive a Lada in programming as well as in real life :) -- Victor Nakoryakov nail-mail<at>mail<dot>ru Krasnoznamensk, Moscow, Russia
Jun 21 2005
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <d99kcq$hd0$1 digitaldaemon.com>, Brad Beveridge says...
So for me the difference between C/C++ and D is like the difference 
between driving a Lada and driving a Merceedes - they both get you where 
you want to do, but one gets you there in style and comfort :)

OT: Living here in the USA, I had no clue what a "Lada" was. So here we go. This is the low-end model on their website: http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html (at today's rate, thats $9634.39 USD.) And the sales pitch: This saloon not only looks good on the outside! Inside it offers spacious accommodation for 5, easily accessed by 4 doors. The generous interior of the LADA 2110 offers even more comfort-from the four electric windows via the remote bootlock to the electronic immobilizer and the automatic heating system. All fitted as standard in the LADA 2110 with 56kW (77hp) or 67kW (91hp) and unbeatable value for money! - EricAnderton at yahoo
Jun 21 2005
next sibling parent reply Brad Beveridge <brad somewhere.net> writes:
pragma wrote:
 In article <d99kcq$hd0$1 digitaldaemon.com>, Brad Beveridge says...

 
 OT: Living here in the USA, I had no clue what a "Lada" was.  
 
 So here we go. This is the low-end model on their website:
 
 http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html
 
 (at today's rate, thats $9634.39 USD.)
 
 And the sales pitch:
 
 This saloon not only looks good on the outside! Inside it offers spacious
 accommodation for 5, easily accessed by 4 doors. The generous interior of the
 LADA 2110 offers even more comfort-from the four electric windows via the
remote
 bootlock to the electronic immobilizer and the automatic heating system.
 All fitted as standard in the LADA 2110 with 56kW (77hp) or 67kW (91hp) and
 unbeatable value for money!
 
 - EricAnderton at yahoo

I've recently moved to the USA, but couldn't think of a brand of car that has a poor reputation for comfort, etc :) I'm originally from New Zealand, and Lada's (although they may be better now) don't have a good reputation there :) Brad
Jun 21 2005
next sibling parent reply Brad Beveridge <brad somewhere.net> writes:
Oh dear, I should have looked at the link first - they're still UGLY!
Jun 21 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d99ten$nmj$2 digitaldaemon.com...
 Oh dear, I should have looked at the link first - they're still UGLY!

100% true. It is ugly, noisy, simplistic, etc. But remeber that story about noise levels on Russian ships? Also true. But they ARE flying http://news.yahoo.com/news?tmpl=story&cid=624&ncid=624&e=4&u=/ap/20050621/ap_on_sc/russia_space_station_7 :-P This does not mean that ergonomic factors are not valuable. They ARE valuable. Question just about priorities in limited time/resource frame and overall robustness of complex systems. Andrew.
Jun 21 2005
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d99tcn$nmj$1 digitaldaemon.com>, Brad Beveridge says...
I've recently moved to the USA, but couldn't think of a brand of car 
that has a poor reputation for comfort, etc :)  I'm originally from New 
Zealand, and Lada's (although they may be better now) don't have a good 
reputation there :)

The most commonly mentioned car with that sort of reputation in the US is probably the Yugo: http://www.mcnabbs.org/peter/pics/yugo.jpg But I think we're being a bit unfair to C/C++. It's probably closer to this: http://www.sovietarmy.com/vehicles/t-55_icon.jpg :) Sean
Jun 21 2005
parent reply Nod <Nod_member pathlink.com> writes:
In article <d99uv6$ov1$1 digitaldaemon.com>, Sean Kelly says...
 <snip>

But I think we're being a bit unfair to C/C++. It's probably closer to this: http://www.sovietarmy.com/vehicles/t-55_icon.jpg :) Sean

Nah, that would be D. Here is C++ right after a "comparison" :) http://gridflow.ca/latest/images/lada.jpg -Nod-
Jun 21 2005
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Nod" <Nod_member pathlink.com> wrote in message 
news:d9a0g6$qgg$1 digitaldaemon.com...
 In article <d99uv6$ov1$1 digitaldaemon.com>, Sean Kelly says...
 Nah, that would be D. Here is C++ right after a "comparison" :)

 http://gridflow.ca/latest/images/lada.jpg

What's funnier about that picture is that it looks like they're _selling_ it!
Jun 21 2005
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Brad Beveridge wrote:
 pragma wrote:
 
 In article <d99kcq$hd0$1 digitaldaemon.com>, Brad Beveridge says...

 OT: Living here in the USA, I had no clue what a "Lada" was. 
 So here we go. This is the low-end model on their website:

 http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html

 (at today's rate, thats $9634.39 USD.)

 And the sales pitch:

 This saloon not only looks good on the outside! Inside it offers spacious
 accommodation for 5, easily accessed by 4 doors. The generous interior 
 of the
 LADA 2110 offers even more comfort-from the four electric windows via 
 the remote
 bootlock to the electronic immobilizer and the automatic heating system.
 All fitted as standard in the LADA 2110 with 56kW (77hp) or 67kW 
 (91hp) and
 unbeatable value for money!

 - EricAnderton at yahoo

I've recently moved to the USA, but couldn't think of a brand of car that has a poor reputation for comfort, etc :) I'm originally from New Zealand, and Lada's (although they may be better now) don't have a good reputation there :) Brad

I think the USA equivilent is the Geo! Brand new... http://www.canadiandriver.com/articles/jc/images/98metro_cpe.jpg What happens when you drive them too much... http://www.crh.noaa.gov/ict/wxstory/2001070813_mvc-016s.jpg http://www.awsomecar.com/pix/wreckmetro.jpg I know someone who has a geo, it looks like crap.
Jun 21 2005
next sibling parent David Medlock <noone nowhere.com> writes:
clayasaurus wrote:
 Brad Beveridge wrote:
 
 pragma wrote:

 In article <d99kcq$hd0$1 digitaldaemon.com>, Brad Beveridge says...

 OT: Living here in the USA, I had no clue what a "Lada" was. So here 
 we go. This is the low-end model on their website:

 http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html

 (at today's rate, thats $9634.39 USD.)

 And the sales pitch:

 This saloon not only looks good on the outside! Inside it offers 
 spacious
 accommodation for 5, easily accessed by 4 doors. The generous 
 interior of the
 LADA 2110 offers even more comfort-from the four electric windows via 
 the remote
 bootlock to the electronic immobilizer and the automatic heating system.
 All fitted as standard in the LADA 2110 with 56kW (77hp) or 67kW 
 (91hp) and
 unbeatable value for money!

 - EricAnderton at yahoo

I've recently moved to the USA, but couldn't think of a brand of car that has a poor reputation for comfort, etc :) I'm originally from New Zealand, and Lada's (although they may be better now) don't have a good reputation there :) Brad

I think the USA equivilent is the Geo! Brand new... http://www.canadiandriver.com/articles/jc/images/98metro_cpe.jpg What happens when you drive them too much... http://www.crh.noaa.gov/ict/wxstory/2001070813_mvc-016s.jpg http://www.awsomecar.com/pix/wreckmetro.jpg I know someone who has a geo, it looks like crap.

The metro is the Suzuki swift, branded with the geo name. I had a Geo Storm Gsi (which was basically an Isuzu Impulse) which had a handling package by Lotus, and it was a great car(one of my favorites that I have owned). -DavidM
Jun 22 2005
prev sibling parent Charlie <Charlie_member pathlink.com> writes:
In article <d9a158$qmq$1 digitaldaemon.com>, clayasaurus says...
Brad Beveridge wrote:
 pragma wrote:
 
 In article <d99kcq$hd0$1 digitaldaemon.com>, Brad Beveridge says...

 OT: Living here in the USA, I had no clue what a "Lada" was. 
 So here we go. This is the low-end model on their website:

 http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html

 (at today's rate, thats $9634.39 USD.)

 And the sales pitch:

 This saloon not only looks good on the outside! Inside it offers spacious
 accommodation for 5, easily accessed by 4 doors. The generous interior 
 of the
 LADA 2110 offers even more comfort-from the four electric windows via 
 the remote
 bootlock to the electronic immobilizer and the automatic heating system.
 All fitted as standard in the LADA 2110 with 56kW (77hp) or 67kW 
 (91hp) and
 unbeatable value for money!

 - EricAnderton at yahoo

I've recently moved to the USA, but couldn't think of a brand of car that has a poor reputation for comfort, etc :) I'm originally from New Zealand, and Lada's (although they may be better now) don't have a good reputation there :) Brad

I think the USA equivilent is the Geo! Brand new... http://www.canadiandriver.com/articles/jc/images/98metro_cpe.jpg What happens when you drive them too much... http://www.crh.noaa.gov/ict/wxstory/2001070813_mvc-016s.jpg http://www.awsomecar.com/pix/wreckmetro.jpg I know someone who has a geo, it looks like crap.

I had a geo :P. The only card I've ever wrecked lol. Charlie
Jun 23 2005
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
pragma wrote:
 OT: Living here in the USA, I had no clue what a "Lada" was.  
 
 So here we go. This is the low-end model on their website:
 
 http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html

Well, to me Lada is more like this one: http://meelis.klimov.ee/auto/lada.jpg -- Tomasz Stachowiak /+ a.k.a. h3r3tic +/
Jun 21 2005
next sibling parent reply Victor Nakoryakov <nail-mail mail.ru> writes:
Tom S wrote:
 pragma wrote:
 
 OT: Living here in the USA, I had no clue what a "Lada" was. 
 So here we go. This is the low-end model on their website:

 http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html

Well, to me Lada is more like this one: http://meelis.klimov.ee/auto/lada.jpg

Aaarrggghh... That is beggining of 1980-th. http://www.autogazeta.com/c/1/b/ld00111.jpg http://www.mayorov.com/auto/vaz/1119/_images/001.jpg http://img.2dehands.nl/f/normal/8694886.jpg That is Lada. -- Victor Nakoryakov nail-mail<at>mail<dot>ru Krasnoznamensk, Moscow, Russia
Jun 21 2005
parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Victor Nakoryakov" <nail-mail mail.ru> wrote in message 
news:d9a0f7$qg1$1 digitaldaemon.com...
 Aaarrggghh... That is beggining of 1980-th.
 http://www.autogazeta.com/c/1/b/ld00111.jpg
 http://www.mayorov.com/auto/vaz/1119/_images/001.jpg
 http://img.2dehands.nl/f/normal/8694886.jpg
 That is Lada.

Funny, they look very much like early-to-mid-90s Fords.
Jun 21 2005
prev sibling parent pragma <pragma_member pathlink.com> writes:
In article <d99tl5$nv9$1 digitaldaemon.com>, Tom S says...
pragma wrote:
 OT: Living here in the USA, I had no clue what a "Lada" was.  
 
 So here we go. This is the low-end model on their website:
 
 http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html

Well, to me Lada is more like this one: http://meelis.klimov.ee/auto/lada.jpg

- EricAnderton at yahoo
Jun 21 2005
prev sibling parent reply Nod <Nod_member pathlink.com> writes:
In article <d99sua$nkm$1 digitaldaemon.com>, pragma says...
In article <d99kcq$hd0$1 digitaldaemon.com>, Brad Beveridge says...
So for me the difference between C/C++ and D is like the difference 
between driving a Lada and driving a Merceedes - they both get you where 
you want to do, but one gets you there in style and comfort :)

OT: Living here in the USA, I had no clue what a "Lada" was. So here we go. This is the low-end model on their website: http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html (at today's rate, thats $9634.39 USD.) And the sales pitch: This saloon not only looks good on the outside! Inside it offers spacious accommodation for 5, easily accessed by 4 doors. The generous interior of the LADA 2110 offers even more comfort-from the four electric windows via the remote bootlock to the electronic immobilizer and the automatic heating system. All fitted as standard in the LADA 2110 with 56kW (77hp) or 67kW (91hp) and unbeatable value for money! - EricAnderton at yahoo

And here is the more traditional look of the (in)famous Lada: http://mclellansautomotive.com/photos/B31016.jpg -Nod-
Jun 21 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Nod" <Nod_member pathlink.com> wrote in message 
news:d99ups$osl$1 digitaldaemon.com...
 In article <d99sua$nkm$1 digitaldaemon.com>, pragma says...
In article <d99kcq$hd0$1 digitaldaemon.com>, Brad Beveridge says...
So for me the difference between C/C++ and D is like the difference
between driving a Lada and driving a Merceedes - they both get you where
you want to do, but one gets you there in style and comfort :)

OT: Living here in the USA, I had no clue what a "Lada" was. So here we go. This is the low-end model on their website: http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html (at today's rate, thats $9634.39 USD.) And the sales pitch: This saloon not only looks good on the outside! Inside it offers spacious accommodation for 5, easily accessed by 4 doors. The generous interior of the LADA 2110 offers even more comfort-from the four electric windows via the remote bootlock to the electronic immobilizer and the automatic heating system. All fitted as standard in the LADA 2110 with 56kW (77hp) or 67kW (91hp) and unbeatable value for money! - EricAnderton at yahoo

And here is the more traditional look of the (in)famous Lada: http://mclellansautomotive.com/photos/B31016.jpg

"Russian version of the Fiat 124: the "Zhiguli" (marketed abroad by name "Lada") (on the photo, the first version, called "2101", 1970, I guess). This car was, for the Russians, the "car of the people", like the Citroen 2CV in France, or the VW Beetle in Germany. It remains the best-seller in Russia, because of the essentiality, the low price and the facility of reparation." And here is Lada "Revolution 2" :) http://digilander.libero.it/cuoccimix/IMG_revolution2_front.jpg http://digilander.libero.it/cuoccimix/IMG_Revolution2_back.jpg http://digilander.libero.it/cuoccimix/ladatms2.jpg Andrew.
Jun 21 2005
prev sibling next sibling parent "Walter" <newshound digitalmars.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message
news:d99kcq$hd0$1 digitaldaemon.com...
 clayasaurus wrote:

 I switched from C++ to D mainly for one reason only. C++ seems like a
 hack, where as D is more thought out and has more elegant answers to the
 same old problems.

That's the main reason that I prefer D where I can, although it doesn't offer anything amazingly special over C/C++ (well, GC maybe), D is actually nice to write code in. After writing even a little bit of D code and getting used to it, I was loath to go back to a C++ compiler! So for me the difference between C/C++ and D is like the difference between driving a Lada and driving a Merceedes - they both get you where you want to do, but one gets you there in style and comfort :)

And that really is a killer feature when you think about it. The only problem is it doesn't stand out very well just from reading the documentation. You have to drive it, so to speak, to see it. BTW, I'm looking at rewriting another major tool in D. It looks to become a lot simpler.
Jun 24 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message
news:d99kcq$hd0$1 digitaldaemon.com...
 So for me the difference between C/C++ and D is like the difference
 between driving a Lada and driving a Merceedes - they both get you where
 you want to do, but one gets you there in style and comfort :)

LOL, considering the car I'm building is www.mitymopar.com
Jun 24 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d9gcl8$1k2r$1 digitaldaemon.com...
 "Brad Beveridge" <brad somewhere.net> wrote in message
 news:d99kcq$hd0$1 digitaldaemon.com...
 So for me the difference between C/C++ and D is like the difference
 between driving a Lada and driving a Merceedes - they both get you where
 you want to do, but one gets you there in style and comfort :)

LOL, considering the car I'm building is www.mitymopar.com

"they both get you where you want to do, but one gets you there in style and comfort :)" Ha! Here is my Subaru Forester after it felt 30 meters and 3 times over the roof. http://terrainformatica.com/screenshots/subaru.jpg I am lucky that it was deep snow and couple of good pines at the end. AWD works. But not always as you may see. The same about GC and other language features :) Resume: It is a programmer/driver who are responsible. I mean blind relying on AWD (GC/heap/whatever nice features you've got) can cause real problems. Andrew.
Jun 25 2005
parent "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d9kivg$dbs$1 digitaldaemon.com...
 Ha! Here is my Subaru Forester after it felt 30 meters and 3 times over

 roof.
 http://terrainformatica.com/screenshots/subaru.jpg

 I am lucky that it was deep snow and couple of good pines at the end.

Ouch! You are lucky.
Jun 25 2005
prev sibling next sibling parent pragma <pragma_member pathlink.com> writes:
In article <d99jqm$h1i$1 digitaldaemon.com>, clayasaurus says...
I switched from C++ to D mainly for one reason only. C++ seems like a 
hack, where as D is more thought out and has more elegant answers to the 
same old problems.

I know how you feel. I, for one, took the longest possible road to get to D. I was in the middle of writing a "next-generation MUD" using C# for a while, and I abandoned that in favor of C++ for speed and portability; Mono wasn't stable at the time. That C++ architecture grew to incorporate my own object library and garbage collector design. I even had some features built into the GC to assist with remoting and proxy generation ala C#. After all that effort, I wound up with a really fancy class library that took forever to compile, was riddled with templates and macros, and was difficult to understand, document and maintain. It was a mess. Along came D, and just about everything I was looking for. It does OOP and GC correctly, all without a VM. I haven't looked back.
If D is to be used widely, do we need to add something new? Something 
that no other language can do? (metaprogramming anyone?)

Metaprogramming and vectorization come to mind, as they have been talked to death in this newsgroup. I've been convinced of their usefulness for certain applications, and to have a C-like language that has such features would put D well ahead of the rest. I think something along the lines of Java's classloader would be worth having. Sure it's borrowing an idea from another langauge, but I have yet to see a compiled language that breaks from using OS support for dynamic bindings. I've dreamed of something that would just load .obj or .lib files *directly* and bind symbols with the environment at run-time. Its either that or provide ways to build runtime symbolic binding support to the runtime/compiler so we can use dll/so files in this manner. No language outside of a VM or scripting language has this kind of support. Also, having automatic proxy generation is extremely useful for environments like CORBA or OODBMS. This would involve runtime support for creating an object instance that implements stub methods, to satisfy a given interface (vtable). The "proxy object" created will now "feel" like a first-class object, but will have each method communicate over a pipe, stream or socket instead of running local code. Again, this is something that I haven't seen outside an interpreted or VM-based language. The above would also require full dynamic, run-time reflection. Something that includes the degree of introspection seen in Python or at least Java. *Again*, a feature not seen in languages in the same class as D. As for completely original ideas? Well, I'm out of ammo. If it satisfies your thirst for innovation, then perhaps the aim for D to become a feature super-set is all it takes? Right now, I want to tell folks "D takes the best of C, C# and Java", but that's not completely true... yet. - EricAnderton at yahoo
Jun 21 2005
prev sibling next sibling parent Nod <Nod_member pathlink.com> writes:
In article <d99jqm$h1i$1 digitaldaemon.com>, clayasaurus says...
 <snip>

 What language role does D fullfill?

I just think that D hits a sweet spot. C doesn't scale, my apps should. C++ is ugly, my code shouldn't be. Java is slow, I don't want my apps to be. C# is vendor-locked-in, my apps can't be. What I like about D is that it balances all these features, and still manages to be fun to program in.
If D is to be used widely, do we need to add something new? Something 
that no other language can do? (metaprogramming anyone?)

Aspect-oriented programming. While not new, doing it cleanly and sanely would clearly nudge D one notch higher on my scale. (I do have some ideas regarding this, but I'll save that for another thread). -Nod-
Jun 21 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 If D is to be used widely, do we need to add something new? Something that 
 no other language can do? (metaprogramming anyone?)

I guess that first D needs features that C++ can do. Beg my pardon but this again about: opAssign & co., 'const', struct ctor/dtor. and remove 'auto' as too controversial. Without these it is too hard to C++ (btw and Java) developer to switch to D. Serious development teams where 'const' is a matter of culture and tool for collaborative work will definitely stay with C++. In any case phobos shall include string class/object/whatever allowing to use it as std::string or java.lang.String. Andrew.
Jun 21 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 21 Jun 2005 23:03:15 -0700, Andrew Fedoniouk  
<news terrainformatica.com> wrote:
 If D is to be used widely, do we need to add something new? Something  
 that
 no other language can do? (metaprogramming anyone?)


WARNING: for all those who can't stand posts containing opinion and little or no actual argument, stop reading now. I am posting this as a statement of opinion, in response to a statement of opinion. I am not trying to start any of these arguments (again) here and now. If we really want to start any of them up again I suggest a new thread for each one.
 I guess that first D needs features that C++ can do.
 Beg my pardon but this again about: opAssign & co.

I think there is some merit in opAssign for structs. Or, if ctors were added to structs having = call the ctor. IIRC one of the design patterns/goals for D was that opAssign was not required for classes, instead copy constructors should be used. The idea being the explicit/obvious nature of constructors was preferrable to assignment overloading. , 'const' I've read a number of things on const (having never used it myself) to try and understand both sides of the argument. I think we need *something* to solve the desire to protect data and have the compiler help us detect violations to that protection. That said, I don't think we want to implement it exact as exists in C++. I still believe that the first step is to create/enforce the readonly nature of 'in' arguments. Either compile time, runtime or both. i.e. It can be a runtime DBC feature i.e. disabled by -release mode. , struct
 ctor/dtor.

IIRC a struct dtor isn't going to be possible without major changes to D. I can't recall why, or even who said it. Something to do with how/when they're called, the nature of structs i.e. a stack type, and the goal of keeping the compiler as simple as possible. On the other hand a ctor is possible, and I think it'd be useful.
 and remove 'auto' as too controversial.

What's controversial about it?
 Without these it is too hard to C++ (btw and Java) developer to switch  
 to D.

Being primarily a C developer I can't really comment, except to say that I have used C++ and Java and vastly prefer D for a number of reasons.
 Serious development teams where 'const' is a matter of culture and
 tool for collaborative work will definitely stay with C++.

I don't think the fact that it's 'culture' is particularly important. A truly good programming language will form culture, it wont follow it.
 In any case phobos shall include string class/object/whatever allowing
 to use it as std::string or java.lang.String.

I've yet to hear any reason that convinces me a string class is required. I reckon the only problem at present is that library developers will choose different UTF types and we'll need to transcode string data to/from all our library calls. The only solution I can think of is to compile all libraries 6 times, a debug and release for each char type. This allows the application programmer to decide on the string type to use internally and link the correct libraries. Note, I'm only talking about selecting the 'internal' char type, not the char type of the various data sources your application might read/write. Regan
Jun 22 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opssrfjcrn23k2f5 nrage.netwin.co.nz...
 On Tue, 21 Jun 2005 23:03:15 -0700, Andrew Fedoniouk 
 <news terrainformatica.com> wrote:
 If D is to be used widely, do we need to add something new? Something 
 that
 no other language can do? (metaprogramming anyone?)


WARNING: for all those who can't stand posts containing opinion and little or no actual argument, stop reading now. I am posting this as a statement of opinion, in response to a statement of opinion. I am not trying to start any of these arguments (again) here and now. If we really want to start any of them up again I suggest a new thread for each one.
 I guess that first D needs features that C++ can do.
 Beg my pardon but this again about: opAssign & co.

I think there is some merit in opAssign for structs. Or, if ctors were added to structs having = call the ctor. IIRC one of the design patterns/goals for D was that opAssign was not required for classes, instead copy constructors should be used. The idea being the explicit/obvious nature of constructors was preferrable to assignment overloading.

For classes, yes, as variable holding class instance is always reference. For structs situation is different. As a rule struct variable is holding value itself. Naturally class builds a safe envelope around its data. Class a,b; a = b; will not destroy data of a; Struct does not have such feature. a = b there will overwrite 'a' value silently. And D is not helping you here to catch this moment. Classes do not need opAssign. Morover there are just no such operation for class variables. Assignment there is always assignment of references (not data)
 , 'const'

 I've read a number of things on const (having never used it myself) to try 
 and understand both sides of the argument. I think we need *something* to 
 solve the desire to protect data and have the compiler help us detect 
 violations to that protection. That said, I don't think we want to 
 implement it exact as exists in C++.

BTW: 'const' is a part of ANSI C too.
 I still believe that the first step is to create/enforce the readonly 
 nature of 'in' arguments. Either compile time, runtime or both. i.e. It 
 can be a runtime DBC feature i.e. disabled by -release mode.

I think it will be enough to be able to construct 'const' value types. Let's say D will alow us to use keyword const as part of the type name: so I can create: struct String { private char[] data; char opIndex(int i) { ... } char opIndexAssign(int i, char c) { ... } } struct const String { private char[] data; this( char[] d ) { data = d; } char opIndex(int i) { ... } } And this is a different implementation of 'const' in C/C++. Remeber that String.data is in fact reference to some memory location. Having such 'const String' type you can safely return or pass references to string data. struct Url { private char[] urlSource; const String domain() { return const String( urlSource[x..y] ); } const String protocol() { return const String( urlSource[x..y] ); } } The idea is simple: instead of only arryas (like char[] ) D must have another type - const arrays ( like const char[] ) which are the same types but immutable, e.g. const char[] type will have not opIndexAssign op available.
 , struct
 ctor/dtor.

IIRC a struct dtor isn't going to be possible without major changes to D. I can't recall why, or even who said it. Something to do with how/when they're called, the nature of structs i.e. a stack type, and the goal of keeping the compiler as simple as possible.

I hope this is the reason (and not because of some religion involved). But compiler can handle now 'auto' for stack class variables. I don't think that it will be more difficult to implement calling of struct dtors in the same manner. The only complex thing is struct static initialization/destruction. Also intitialization of array of structs could be an implementation problem.
 On the other hand a ctor is possible, and I think it'd be useful.

 and remove 'auto' as too controversial.

What's controversial about it?

auto A a = new A(); .... a = new A() ; // another A instance in the same var. What will happen // with the first one? etc.
 Without these it is too hard to C++ (btw and Java) developer to switch 
 to D.

Being primarily a C developer I can't really comment, except to say that I have used C++ and Java and vastly prefer D for a number of reasons.
 Serious development teams where 'const' is a matter of culture and
 tool for collaborative work will definitely stay with C++.

I don't think the fact that it's 'culture' is particularly important. A truly good programming language will form culture, it wont follow it.

Probably D will form a culture. If it would be enough members in this society. The question is about a critical mass of number of "culture carriers". And we are speaking about motivations to join the society, right? 'const' is the one. Non-deterministic GC (the same as in D, btw) is available for C/C++ so it is not a big motivation. What else? The only thing is 1) better syntax and 2) set of ready to use builtin types. The latter is definitely not full without 'const'. The first is not full without opAssign and ctors/dtors.
 In any case phobos shall include string class/object/whatever allowing
 to use it as std::string or java.lang.String.

I've yet to hear any reason that convinces me a string class is required.

For your personally and for small projects probably not. But consider development of components/libraries of a big scale. char[] s = myobject.name(); int[ char[] ] map; map[ s ] = 1; .... // somewhere in myobject far far away somebody // changed name data to let's say "two". // and after that: assert (map[ "one" ] == 1) ; will throw an error. Simple assignment of one character is making the whole system fragile. Consider that you have two developers on East Coast, three on the West and yourself sitting in lets say Michigan trying to find who and where in depths of your project changed such value. With Java/C++ strings such sitations are just impossible. Again, D char[] is a character array and not a string (value). Yes you can always .dup your 'strings'. The question: is this a real solution?
 I reckon the only problem at present is that library developers will 
 choose different UTF types and we'll need to transcode string data to/from 
 all our library calls. The only solution I can think of is to compile all 
 libraries 6 times, a debug and release for each char type. This allows the 
 application programmer to decide on the string type to use internally and 
 link the correct libraries. Note, I'm only talking about selecting the 
 'internal' char type, not the char type of the various data sources your 
 application might read/write.

 Regan 

Jun 22 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 22 Jun 2005 11:56:23 -0700, Andrew Fedoniouk  
<news terrainformatica.com> wrote:
 I guess that first D needs features that C++ can do.
 Beg my pardon but this again about: opAssign & co.

I think there is some merit in opAssign for structs. Or, if ctors were added to structs having = call the ctor. IIRC one of the design patterns/goals for D was that opAssign was not required for classes, instead copy constructors should be used. The idea being the explicit/obvious nature of constructors was preferrable to assignment overloading.

For classes, yes, as variable holding class instance is always reference.

We agree about classes.
 For structs situation is different. As a rule struct variable is holding
 value itself.

It is a value type.
 Naturally class builds a safe envelope around its data.
 Class a,b; a = b; will not destroy data of a;

 Struct does not have such feature. a = b there will overwrite 'a' value
 silently.

That is the very point of using a struct. A struct is a value type, when you assign something to a value, it assigns that value.
 And D is not helping you here to catch this moment.

Catch what? The fact that you've chosen to assign a value? You may as well ask it to catch the assignment of an 'int', eg "int i = 5;" I cannot see the need to prevent assignments, at present no assignment is allowed except that of the exact same type (talking about structs) eg. struct A {} struct B {} A a; B b; B c; a=b; //error b=c; //ok To prevent assignment to a particular variable you would use const (or whatever we decide the keyword is): const B b; B c; b=c; //error (one would expect) The only point of opAssign (that I can see) for structs would be to facilitate assignment of other types, eg. struct A { char[] value; int opAssign(int rhs) { value = std.string.toString(rhs); } } A a; a = 5;
 I still believe that the first step is to create/enforce the readonly
 nature of 'in' arguments. Either compile time, runtime or both. i.e. It
 can be a runtime DBC feature i.e. disabled by -release mode.

I think it will be enough to be able to construct 'const' value types.

I think we need both. The reason we need both: const char[] foo = "regan was here"; mutilate(foo); //no error, foo is const, mutilate takes an 'in' (so "will not" modify foo). void mutilate(in char[] victum) { victum[0] = 'a'; //error: 'in' parameter not mutable } 'in' is a contract saying "I will only read this parameter". That contract needs to be enforced.
 Let's say D will alow us to use keyword const as part of the type name:
 so I can create:

 struct String
 {
    private char[] data;
    char opIndex(int i) { ... }
    char opIndexAssign(int i, char c)   {  ...  }
 }

 struct const String
 {
    private char[] data;
    this( char[] d ) { data = d; }
    char opIndex(int i) { ... }
 }

 And this is a different implementation of 'const' in C/C++.
 Remeber that String.data is in fact reference to some memory location.
 Having such 'const String' type you can safely return or pass references  
 to string data.

 struct Url
 {
     private char[] urlSource;
     const String domain() {  return  const String( urlSource[x..y] ); }
     const String protocol() {  return  const String( urlSource[x..y] ); }
 }

 The idea is simple: instead of only arryas (like char[] )
 D must have another type - const arrays (  like const char[]  )
 which are the same types but immutable, e.g.
 const char[] type will have not opIndexAssign op available.

As a string class is not required in D (still under debate), lets remove it from the example (we'll come back to it later): struct Url { private char[] urlSource; char[] domain() { return urlSource[a..b]; } char[] protocol() { return urlSource[c..d]; } } The basic problem is being able to create/return/pass a reference to immutable data. In this case returning a slice of mutable data as immutable data. Ideally the addition of 'const' or 'readonly' or whatever we decide is a good keyword would be all that is required, eg. struct Url { private char[] urlSource; const char[] domain() { return urlSource[a..b]; } const char[] protocol() { return urlSource[c..d]; } } The rules being: 1. immutable(const) data cannot ever be mutable. 2. mutable data is implicitly immutable data when passed as such. I think to achieve this all the char[] needs is a readonly flag, which once set to true cannot become false again. This can either be implemented at compile time (compiler uses flag to check for errors), or runtime (runtime checks against flag stored in char[] struct), or both. This ties in with the 'in' parameter checking, the same flag is used for compile time checking. At runtime it could be done without a flag using an implicit 'out' DBC check against the original (that might not catch a change and change back case however). Of course the next problem is how to handle immutability on custom types (we're back to the string class or other similar types). Using 2 example custom types: struct Bob {} class Fred {} we need to be able to indicate they are immutable, ideally in exactly the same way as char[] above, eg. Fred p; static this() { p = new Fred(); } const Fred fooBar() { return p; } this required that the compiler store the same readonly flag within the class and perform compile/runtime checks on it. The same goes for the struct Bob.
 , struct
 ctor/dtor.

IIRC a struct dtor isn't going to be possible without major changes to D. I can't recall why, or even who said it. Something to do with how/when they're called, the nature of structs i.e. a stack type, and the goal of keeping the compiler as simple as possible.

I hope this is the reason (and not because of some religion involved).

I doubt it's a religeon, though I understand your meaning here. Everyone whether they realise it or not will by habit defend preconcieved notions/ideas, the trick is realising that is what you're doing and re-evaluate. Of course, you may come to the same conclusion.
 But compiler can handle now 'auto' for stack class variables.

structs are not classes however, they have no vtable, I believe that is an important part of the problem.
 I don't think that it will be more difficult to implement calling of  
 struct dtors in the same manner.
 The only complex thing is struct static initialization/destruction.
 Also intitialization of array of structs could be an implementation  
 problem.

We'll have to get Walters official word on this again (or find it in the archives).
 On the other hand a ctor is possible, and I think it'd be useful.

 and remove 'auto' as too controversial.

What's controversial about it?

auto A a = new A(); .... a = new A() ; // another A instance in the same var. What will happen // with the first one? etc.

And the controversy is? i.e. what 2 or more answers do people fail to agree on? I believe this should be an error, after all it's illegal to assign something to an auto variable, which is essentially what you're doing. Breaking the statement into parts we see: "new A()" construct an A using this() "a =" assign rhs to reference a;
 Serious development teams where 'const' is a matter of culture and
 tool for collaborative work will definitely stay with C++.

I don't think the fact that it's 'culture' is particularly important. A truly good programming language will form culture, it wont follow it.

Probably D will form a culture. If it would be enough members in this society. The question is about a critical mass of number of "culture carriers". And we are speaking about motivations to join the society, right?

Yep. D already has plenty of these, see my list below.
 'const' is the one.

I agree it's important, but, for me D the whole package was 'the one' eg. - array slicing - GC - low level systems languge - great syntax I dont really make full use of unittesting, dbc, etc but these are also important to the overall package.
 Non-deterministic GC (the same as in D, btw) is available for C/C++ so
 it is not a big motivation.

By itself, no, but added to all the other (sometimes little) things.. it's the overall package that matters. IMO D's overall package is great, and getting better by the day. Sure, there are a number of things I want changed, there are a number you want changed, that's normal, name me a programming language that is perfect, you can't or you wouldn't be here. :)
 What else? The only thing is 1) better syntax
 and 2) set of ready to use builtin types. The latter is definitely not  
 full without 'const'.

Perhaps, they're still 'ready to use' they're just missing certain protection attributes like readonly.
 The first is not full without opAssign and ctors/dtors.

The syntax is better (than other languages) with or without this feature.
 In any case phobos shall include string class/object/whatever allowing
 to use it as std::string or java.lang.String.

I've yet to hear any reason that convinces me a string class is required.

For your personally and for small projects probably not.

I'm not talking about experience, I'm talking about argument, no-one has given an argument 'for' a string class that makes sense.
 But consider development of components/libraries of a big scale.

 char[] s = myobject.name();
 int[ char[] ] map;
 map[ s ] = 1;
 ....
 // somewhere in myobject far far away somebody
 // changed name data to let's say "two".
 // and after that:

 assert (map[ "one" ] == 1) ;

 will throw an error.

This is solved by the 'const' ideas I have explained above.
 Simple assignment of one character is making the whole system fragile.

Until we get 'const' as I have described above.
 Consider that you have two developers on East Coast, three on the West
 and yourself sitting in lets say Michigan trying to find who and where in
 depths of your project
 changed such value. With Java/C++ strings such sitations are just
 impossible.

And will be impossible in D when we get 'const'
 Again, D char[] is a character array and not a string (value).

Technically yes, practically it makes no difference (once we have const).
 Yes you can always .dup your 'strings'.
 The question: is this a real solution?

It's part of the solution. For high-performance mutable strings it's what you do, for high-performance immutable strings you use 'const' (when Walter adds it as I have described). Baiscally, I'm saying, we dont need a string class, we need const. I agree there is a problem. I just prefer my solution to yours, both probably solve the problem, mine seems neater (IMO) and more D like (IMO).
 I reckon the only problem at present is that library developers will
 choose different UTF types and we'll need to transcode string data  
 to/from
 all our library calls. The only solution I can think of is to compile  
 all
 libraries 6 times, a debug and release for each char type. This allows  
 the
 application programmer to decide on the string type to use internally  
 and
 link the correct libraries. Note, I'm only talking about selecting the
 'internal' char type, not the char type of the various data sources your
 application might read/write.


The above is still an issue. I've not heard a better soln than mine above, anyone? Regan
Jun 22 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 23 Jun 2005 10:15:40 +1200, Regan Heath wrote:

[snip]
 I'm not talking about experience, I'm talking about argument, no-one has  
 given an argument 'for' a string class that makes sense.

One thing that is still a bit of a problem is having a 'string' type that is encoding agnostic. It would be very handy to be able to this sort of thing... string a; char[] b; wchar[] c; dchar[] d; a = b ~ c ~ d; Currently we need to explicitly invoke the UTF conversion functions to do this sort of thing. -- Derek Parnell Melbourne, Australia 23/06/2005 8:27:02 AM
Jun 22 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 23 Jun 2005 08:35:52 +1000, Derek Parnell <derek psych.ward> wrote:
 On Thu, 23 Jun 2005 10:15:40 +1200, Regan Heath wrote:

 [snip]
 I'm not talking about experience, I'm talking about argument, no-one has
 given an argument 'for' a string class that makes sense.

One thing that is still a bit of a problem is having a 'string' type that is encoding agnostic. It would be very handy to be able to this sort of thing... string a; char[] b; wchar[] c; dchar[] d; a = b ~ c ~ d; Currently we need to explicitly invoke the UTF conversion functions to do this sort of thing.

True, it is a pain. I once suggested that transcoding (converting from one UTF type to another) could be done implicity. It met with some like and some dislike. The dislike stemmed from the fact that it can be very inefficient where you have several types involved in one statement. Especially as it then happens implicitly and is not obvious. I have come to agree, it's a bad idea, by itself... The solution IMO is building all libraries 6 times (one for each char type, release and debug) If we build all libraries 6 times and link the correct 'internal' char type it means no internal transcoding is done i.e. between libraries, to/from the system (depending on what type you choose). To achieve this everyone would use an alias 'string' where they wanted an encoding agnostic string. 'string' would alias the chosen 'internal' char type. This means that things like you show above would be limited to input/output of different types. (which would most likely, initially, be the non-utf charsets anyway). There is no way to avoid transcoding these, so we call the transcoding functions. The reason I don't think that is a problem is that: 1. transcoding should be obvious and explicit (that's my opinion of course). 2. it's rare (generally speaking). More on #2. You'd generally choose an internal char type to match your most common input/output data. Most applications wouldn't need to transcode input or output, i.e. they can use ASCII right thru. Of course, we could still make transcoding implicit. But IMO only once we remove the bulk of the potential pitfalls resulting in masses of internal transcoding between libraries etc. Regan
Jun 22 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <opsssrzs0623k2f5 nrage.netwin.co.nz>, Regan Heath says...
On Thu, 23 Jun 2005 08:35:52 +1000, Derek Parnell <derek psych.ward> wrote:
 On Thu, 23 Jun 2005 10:15:40 +1200, Regan Heath wrote:

 [snip]
 I'm not talking about experience, I'm talking about argument, no-one has
 given an argument 'for' a string class that makes sense.

One thing that is still a bit of a problem is having a 'string' type that is encoding agnostic. It would be very handy to be able to this sort of thing... string a; char[] b; wchar[] c; dchar[] d; a = b ~ c ~ d; Currently we need to explicitly invoke the UTF conversion functions to do this sort of thing.

True, it is a pain. I once suggested that transcoding (converting from one UTF type to another) could be done implicity. It met with some like and some dislike. The dislike stemmed from the fact that it can be very inefficient where you have several types involved in one statement. Especially as it then happens implicitly and is not obvious.

Personally, I'd be happy with explicit transcoding using the cast operator: dchar[] a; char[] b = cast(char[]) a; Does this already work, or is it just with foreach? I keep forgetting to test it. Sean
Jun 22 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Thu, 23 Jun 2005 01:44:04 +0000 (UTC), Sean Kelly wrote:

 In article <opsssrzs0623k2f5 nrage.netwin.co.nz>, Regan Heath says...
On Thu, 23 Jun 2005 08:35:52 +1000, Derek Parnell <derek psych.ward> wrote:
 On Thu, 23 Jun 2005 10:15:40 +1200, Regan Heath wrote:

 [snip]
 I'm not talking about experience, I'm talking about argument, no-one has
 given an argument 'for' a string class that makes sense.

One thing that is still a bit of a problem is having a 'string' type that is encoding agnostic. It would be very handy to be able to this sort of thing... string a; char[] b; wchar[] c; dchar[] d; a = b ~ c ~ d; Currently we need to explicitly invoke the UTF conversion functions to do this sort of thing.

True, it is a pain. I once suggested that transcoding (converting from one UTF type to another) could be done implicity. It met with some like and some dislike. The dislike stemmed from the fact that it can be very inefficient where you have several types involved in one statement. Especially as it then happens implicitly and is not obvious.

Personally, I'd be happy with explicit transcoding using the cast operator: dchar[] a; char[] b = cast(char[]) a; Does this already work, or is it just with foreach? I keep forgetting to test it.

The "cast(char[])" never does run-time UTF conversion. It does do compile-time UTF conversion for string literals. The 'foreach' does allow character-by-character UTF conversion but it does need a cast to do that. char[] a; foreach(dchar x; a) -- Derek Melbourne, Australia 23/06/2005 12:40:08 PM
Jun 22 2005
prev sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 23 Jun 2005 01:44:04 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:
 Personally, I'd be happy with explicit transcoding using the cast  
 operator:

 dchar[] a;
 char[] b = cast(char[]) a;

Good point. I forgot about that idea.
 Does this already work, or is it just with foreach?  I keep forgetting  
 to test
 it.

Just with foreach, as Derek posted. Regan
Jun 22 2005
prev sibling parent reply Mike Capp <mike.capp gmail.com> writes:
In article <d99jqm$h1i$1 digitaldaemon.com>, clayasaurus says...

Ok, I'm just wondering what people think. We all know to use the right 
tool for the right job, so when is D the right tool for the job?

A few additions/corrections/comments:
C++ *******************************************************************

Sucessor to C.

Pros:
  - object oriented

Optionally. C++ usually describes itself as "multiparadigm" - you can use it for procedural and/or OO and/or generic programming. Plus sort-of-functional if you squint a bit and have a strong stomach. I like OO, but it's not the only game in town, and there are domains for which it's an awkward fit.
  - customizable

Could you expand on this? Do you mean the ability to specify custom ctor/dtor/assign/copy/conversion/operator semantics for UDTs? + Generalized RAII. I can't believe you missed this. It's THE killer feature, and could be made even better given a few tweaks. + Much tighter control over memory usage than GC. (Smaller working set, much less risk of unacceptable pauses.) A bit tedious when you don't need it, but irreplaceable when you do, and manageable given RAII. This point alone creates a sizeable niche in which D will _never_ supplant C/C++.
Cons:

- No ABI. This has greatly hampered component-based development for C++. An awful lot of libraries expose their APIs as C, even if they're written in C++ internally.
Java *******************************************************************

Pros:

+ Some very good tools available, esp. IDEs (Eclipse, IDEA) + Reflection
Cons:
  - slow

Not particularly slow, with a decent JIT. - Exception specifications were a bad idea with hindsight. Very tedious. - Controlled by Sun.
C# *******************************************************************

Pros:

+ It really does feel like "Java done right". Mostly minor tweaks, but they add up. Earlier versions of D looked a LOT like C#; I think it's going to be tough to differentiate.
Cons:
  - it is microsoft only, unless you look at mono

And why wouldn't you look at Mono? From the FAQ: "Mono today ships with a Just-in-Time compiler for x86, PowerPC, S390 and SPARC-based systems. It is tested regularly on Linux, FreeBSD and Windows (with the XP/NT core). There is also an interpreter, which is slower that runs on the x86, s390, SPARC, HPPA, StrongARM and PowerPC architectures." C# is an ECMA standard, which makes it rather more "open" than Java. And it produces cross-platform binaries, like Java.
D *******************************************************************

Successor to C, C++, and Java.

Pros:
  - design by contract (none other?)

Eiffel pioneered this.
Pros:

+ Easier binding to C libs than anything else except C++.
Cons:
  - not enough exposure / usage

Always a problem for new languages.
  - not as many libraries as C++ / Java

And is going to look even worse given that language-neutral libraries look set to be the future, probably coalescing around the .NET and Parrot ABIs. - Few tools as yet.
So, here is what I am seeing D's niche as being...

* A more powerful and easier to implement on different platforms (palm, 
etc.)

It's always going to lose out to VM-based languages (Java, C#) on portability. And bear in mind that both Java (GCJ) and C# (Mono precompiler) can be compiled to native code if you really want to. cheers, Mike
Jun 22 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Wed, 22 Jun 2005 13:18:00 +0000 (UTC), Mike Capp <mike.capp gmail.com>  
wrote:
 + Much tighter control over memory usage than GC. (Smaller working set,  
 much
 less risk of unacceptable pauses.) A bit tedious when you don't need it,  
 but
 irreplaceable when you do, and manageable given RAII. This point alone  
 creates a
 sizeable niche in which D will _never_ supplant C/C++.

D can do this too, just diasble the GC and memory manage to your hearts content. Regan
Jun 22 2005
parent reply Mike Capp <mike.capp gmail.com> writes:
In article <opsssligap23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 + Much tighter control over memory usage than GC. (Smaller working set,  
 much
 less risk of unacceptable pauses.) A bit tedious when you don't need it,  
 but
 irreplaceable when you do, and manageable given RAII. This point alone  
 creates a
 sizeable niche in which D will _never_ supplant C/C++.

D can do this too, just diasble the GC and memory manage to your hearts content.

Except that, to return to an earlier gripe, the rules for 'auto' don't allow automatic refcounted smart pointers along the lines of boost::shared_ptr. Such pointers are pretty much required for robust non-GC memory management. Also, I gather that Phobos assumes GC and will leak like a sieve without it. It's not so much "D can do this" as "you can do this if you're prepared to fight the language every step of the way". You can do (real) GC in C++ by plugging in something like the Boehm collector. Not many people do. You certainly don't see ticks for C++ in the "GC" column in language comparison charts. cheers Mike
Jun 23 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 23 Jun 2005 08:07:06 +0000 (UTC), Mike Capp <mike.capp gmail.com>  
wrote:
 In article <opsssligap23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 + Much tighter control over memory usage than GC. (Smaller working set,
 much
 less risk of unacceptable pauses.) A bit tedious when you don't need  
 it,
 but
 irreplaceable when you do, and manageable given RAII. This point alone
 creates a
 sizeable niche in which D will _never_ supplant C/C++.

D can do this too, just diasble the GC and memory manage to your hearts content.

Except that, to return to an earlier gripe, the rules for 'auto' don't allow automatic refcounted smart pointers along the lines of boost::shared_ptr.

I'll take your word for it. I've never used them.
 Such
 pointers are pretty much required for robust non-GC memory management.

Being a C programmer for a living I can honestly say I haven't had a memory management issue for.. well ages. I think memory management is a skill, one I have learnt thru years of being bitten by it. In addition C is probably much simpler than C++ when it comes to memory management.
 Also, I
 gather that Phobos assumes GC and will leak like a sieve without it.

True, you would be programming without a standard library. I think that is to be expected, it's a "standard" library after all, for doing handling standard situations.
 It's not so much "D can do this" as "you can do this if you're prepared  
 to fight the language every step of the way".

 You can do (real) GC in C++ by plugging in
 something like the Boehm collector. Not many people do.

Are you saying the GC in D is less real than this? If so, how?
 You certainly don't see
 ticks for C++ in the "GC" column in language comparison charts.

In fairness that would be because it's a 'language' comparison, not a language + libraries comparison, right? Regan
Jun 23 2005
next sibling parent reply Mike Capp <mike.capp gmail.com> writes:
In article <opsstiikkp23k2f5 nrage.netwin.co.nz>, Regan Heath says...

Being a C programmer for a living I can honestly say I haven't had a  
memory management issue for.. well ages. I think memory management is a  
skill, one I have learnt thru years of being bitten by it.

It depends very much on the kind of data structures needed for your app domain. In some domains you can write useful C/C++ apps without ever touching malloc/new. In others you really need refcounting, and manual refcounting is just nasty. In still others you have to cope with potential cycles, and GC is pretty much the only way to go.
True, you would be programming without a standard library. I think that is  
to be expected, it's a "standard" library after all, for doing handling  
standard situations.

Fair enough, but it's then a bit of a stretch to claim that the language supports GC-less programming. "Ugh, header files in C are a pain." "But you can do header-less programming in C! As long as you don't mind putting all your code in one file and doing without any libraries, or copying all your prototypes etc into each source file."
 You can do (real) GC in C++ by plugging in
 something like the Boehm collector. Not many people do.

Are you saying the GC in D is less real than this? If so, how?

No, I just meant "real" GC as opposed to refcounting. cheers Mike
Jun 23 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 23 Jun 2005 12:59:47 +0000 (UTC), Mike Capp <mike.capp gmail.com>  
wrote:
 In article <opsstiikkp23k2f5 nrage.netwin.co.nz>, Regan Heath says...

 Being a C programmer for a living I can honestly say I haven't had a
 memory management issue for.. well ages. I think memory management is a
 skill, one I have learnt thru years of being bitten by it.

It depends very much on the kind of data structures needed for your app domain. In some domains you can write useful C/C++ apps without ever touching malloc/new.

I use malloc/strdup all the time.
 In others you really need refcounting, and manual refcounting is just  
 nasty.

I think it depends on the coding style you use. I've never 'needed' refcounting. At one stage I thought it was cool and tried using it, that stage didn't last.
 In still others you have to cope with potential cycles, and GC is pretty  
 much the only way to go.

Cycles? example pls.
 True, you would be programming without a standard library. I think that  
 is
 to be expected, it's a "standard" library after all, for doing handling
 standard situations.

Fair enough, but it's then a bit of a stretch to claim that the language supports GC-less programming.

I disagree. The 'language' supports it just fine. The 'library' doesn't. Compare that with Java, as I understand it (and that might be not at all) you cannot avoid the GC at all. Regan
Jun 23 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsstqq2vz23k2f5 nrage.netwin.co.nz...
 Cycles? example pls.

You know, objects that point to each other. Even if nothing else is pointing to them, and they are for all purposes "dead," they won't be automatically collected because they still point to each other and thus still have one reference each. You'd have to establish some kind of manual cleanup for these objects, such as a "parent-child" relationship, where deleting the parent would cause the child to .Release() the reference to the parent.
Jun 23 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 23 Jun 2005 11:45:29 -0400, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsstqq2vz23k2f5 nrage.netwin.co.nz...
 Cycles? example pls.

You know, objects that point to each other. Even if nothing else is pointing to them, and they are for all purposes "dead," they won't be automatically collected because they still point to each other and thus still have one reference each. You'd have to establish some kind of manual cleanup for these objects, such as a "parent-child" relationship, where deleting the parent would cause the child to .Release() the reference to the parent.

Coo, I suspected that's what was meant :) Like a doubly linked list perhaps? One where you have nulled your pointer to it's root item? This wouldn't happen to me, as I'd be 'free' ing the root, causing a free of the next item, etc. Or perhaps a circular list (I've never had cause to used one). Even there you'd have a pointer to some starting point, or current point or something. When freeing such a list I'd imagine you need it to be double linked so as you can null the previous items 'next' pointer (in other words turning it into a normal list) before recursively freeing the items. How does a GC handle 'cycles'? Does it analyse and figure out it's a cycle or does it just not free them? I suspect it depends on how clever the GC is, right? Regan
Jun 23 2005
next sibling parent reply Brad Beveridge <brad somewhere.net> writes:
Regan Heath wrote:

 How does a GC handle 'cycles'? Does it analyse and figure out it's a 
 cycle  or does it just not free them? I suspect it depends on how clever 
 the GC  is, right?
 
 Regan

As I understand it, it works like: Starting from the CPU registers the GC looks for pointers, it also looks for pointers in the stack and global static data. From those pointers it marks areas of the heap as "don't touch" and further checks those areas. So the GC ends up knowing where all valid (ie, reachable) objects are in memory. All other parts of memory - the lost circular list will be in here - are fair game for the GC to use in future allocations. Brad
Jun 23 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 23 Jun 2005 17:06:11 -0700, Brad Beveridge <brad somewhere.net>  
wrote:
 Regan Heath wrote:

 How does a GC handle 'cycles'? Does it analyse and figure out it's a  
 cycle  or does it just not free them? I suspect it depends on how  
 clever the GC  is, right?
  Regan

As I understand it, it works like: Starting from the CPU registers the GC looks for pointers, it also looks for pointers in the stack and global static data. From those pointers it marks areas of the heap as "don't touch" and further checks those areas. So the GC ends up knowing where all valid (ie, reachable) objects are in memory. All other parts of memory - the lost circular list will be in here - are fair game for the GC to use in future allocations.

Ahh.. thanks, good description. Regan
Jun 23 2005
prev sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opssujy2j723k2f5 nrage.netwin.co.nz...
 On Thu, 23 Jun 2005 11:45:29 -0400, Jarrett Billingsley 
 <kb3ctd2 yahoo.com> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsstqq2vz23k2f5 nrage.netwin.co.nz...
 Cycles? example pls.

You know, objects that point to each other. Even if nothing else is pointing to them, and they are for all purposes "dead," they won't be automatically collected because they still point to each other and thus still have one reference each. You'd have to establish some kind of manual cleanup for these objects, such as a "parent-child" relationship, where deleting the parent would cause the child to .Release() the reference to the parent.

Coo, I suspected that's what was meant :) Like a doubly linked list perhaps? One where you have nulled your pointer to it's root item? This wouldn't happen to me, as I'd be 'free' ing the root, causing a free of the next item, etc. Or perhaps a circular list (I've never had cause to used one). Even there you'd have a pointer to some starting point, or current point or something. When freeing such a list I'd imagine you need it to be double linked so as you can null the previous items 'next' pointer (in other words turning it into a normal list) before recursively freeing the items. How does a GC handle 'cycles'? Does it analyse and figure out it's a cycle or does it just not free them? I suspect it depends on how clever the GC is, right?

Cyclic references is what COM+ (reference counting) these days is dying of. Imagine Recordset class and Field class. class Recordset { Field[] fields; ... } class Field { Recordest rs; .... } As auto deletion of object happens when it reference count becomes zero than such system will never be freed by itself. What does mark-n-sweep GC (it is used in D): 1) It freezes execution of the process. 2) Mark phase: Scans root and perimeter: stack and statics - looks in each memory location and tries to guess is it pointer on the heap or not. If it looks like a pointer for some memory chunk it scans that memory. Doing such scanning, it sets 'marked' flag to accessible blocks. 3) Sweep phase: scans list of all allocated memory chunks and if 'marked' flag is not set for it - frees it (deletes from heap). 4) Resumes execution of your process. As you may see it solves problem of cyclic references. But! As you may also see it stops your process for some amount of time. Obviously as much stuff you have allocated (which was not explicetely deleted) as longer GC pause - your app is non-responsive. Resume: if you you know that something can be deleted you'd better delete it *now* :) All this talks: opAssign, ctors/dtors, 'const' are about this and not about beautification of syntax (this is also matters as Lada example shows but you'd better install first best engine available - it is better that this engine use hybrid technologies, right?). This is why I am personally not buying advices to use .dup when I can simply solve this by using 'const' in 95% of cases. Andrew.
Jun 23 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 23 Jun 2005 17:17:50 -0700, Andrew Fedoniouk  
<news terrainformatica.com> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opssujy2j723k2f5 nrage.netwin.co.nz...
 On Thu, 23 Jun 2005 11:45:29 -0400, Jarrett Billingsley
 <kb3ctd2 yahoo.com> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsstqq2vz23k2f5 nrage.netwin.co.nz...
 Cycles? example pls.

You know, objects that point to each other. Even if nothing else is pointing to them, and they are for all purposes "dead," they won't be automatically collected because they still point to each other and thus still have one reference each. You'd have to establish some kind of manual cleanup for these objects, such as a "parent-child" relationship, where deleting the parent would cause the child to .Release() the reference to the parent.

Coo, I suspected that's what was meant :) Like a doubly linked list perhaps? One where you have nulled your pointer to it's root item? This wouldn't happen to me, as I'd be 'free' ing the root, causing a free of the next item, etc. Or perhaps a circular list (I've never had cause to used one). Even there you'd have a pointer to some starting point, or current point or something. When freeing such a list I'd imagine you need it to be double linked so as you can null the previous items 'next' pointer (in other words turning it into a normal list) before recursively freeing the items. How does a GC handle 'cycles'? Does it analyse and figure out it's a cycle or does it just not free them? I suspect it depends on how clever the GC is, right?

Cyclic references is what COM+ (reference counting) these days is dying of. Imagine Recordset class and Field class. class Recordset { Field[] fields; ... } class Field { Recordest rs; .... } As auto deletion of object happens when it reference count becomes zero than such system will never be freed by itself.

Yep, I see.
 What does mark-n-sweep GC (it is used in D):

 1) It freezes execution of the process.
 2) Mark phase: Scans root and perimeter: stack and statics -
     looks in each memory location and tries to guess is it pointer
     on the heap or not. If it looks like a pointer for some memory chunk
     it scans that memory. Doing such scanning, it sets 'marked' flag to
     accessible blocks.
 3) Sweep phase: scans list of all allocated memory chunks and
     if 'marked' flag is not set for it - frees it (deletes from heap).
 4) Resumes execution of your process.

 As you may see it solves problem of cyclic references.

Yep.
 But! As you may also see it stops your process for some amount of
 time. Obviously as much stuff you have allocated (which was not
 explicetely deleted) as longer GC pause - your app is non-responsive.

Sure. But for 'how long', and is that length of time 'too long' or not. I can see how in a 'realtime' application this might be a *big* problem, but in a typical application as long as the pause is very brief it should be fine, right? In applications with a realtime portion i.e. a game rendering to the screen there are techniques for avoiding pauses when it really matters, they generally involve pre-allocating and not allocating due the rendering phase. I believe a game written *without* a GC would use the same techniques in order to keep the frame rate as fast as possible. I'm no expert though. A friend of mine, much older than I, who once used a GC for some anchient language (I cannot remember the name of) mentioned to me, a few weeks back, about how an application he wrote was 'going away' for a few minutes. That sort of pause is unacceptable in just about every application type. That said, GC implmentation (and the hardware they operate on) has improved vastly.
 Resume: if you you know that something can be deleted you'd better
 delete it *now* :)

This is sensible advice in any case.
 All this talks: opAssign, ctors/dtors, 'const' are about this and
 not about beautification of syntax

I never once thought it was :)
 (this is also matters as Lada
 example shows but you'd better install first best engine available -
 it is better that this engine use hybrid technologies, right?).

 This is why I am personally not buying advices to use .dup
 when I can simply solve this by using 'const' in 95% of cases.

I don't buy them either. To me it smacks of inefficiency and doing something "just in case". While I agree/think Copy-On-Write is a good method (it is efficient) I also think we do need some method to enforce readonly. The best soln I've seen IMO is the compile/runtime flags for verifying readonly data is not modified. In short, I agree there is a problem. I have a favourite solution and it's not 'exactly' what you're saying we should do ;) Regan
Jun 23 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opssum481c23k2f5 nrage.netwin.co.nz...
 But! As you may also see it stops your process for some amount of
 time. Obviously as much stuff you have allocated (which was not
 explicetely deleted) as longer GC pause - your app is non-responsive.

Sure. But for 'how long', and is that length of time 'too long' or not. I can see how in a 'realtime' application this might be a *big* problem, but in a typical application as long as the pause is very brief it should be fine, right? In applications with a realtime portion i.e. a game rendering to the screen there are techniques for avoiding pauses when it really matters, they generally involve pre-allocating and not allocating due the rendering phase. I believe a game written *without* a GC would use the same techniques in order to keep the frame rate as fast as possible. I'm no expert though.

Actually, any call to 'new' in C++ has no guarantee that it will return within a bounded amount of time. Applications where real time latency must be bounded will tend to be written to preallocate all the data and will never use 'new' in the time critical sections.
Jun 25 2005
parent Sean Kelly <sean f4.ca> writes:
In article <d9j73o$12lg$1 digitaldaemon.com>, Walter says...
Actually, any call to 'new' in C++ has no guarantee that it will return
within a bounded amount of time. Applications where real time latency must
be bounded will tend to be written to preallocate all the data and will
never use 'new' in the time critical sections.

I haven't much looked into them, but I imagine specialized memory managers like Hoard provide some basic guarantees on allocation time. Though by the same token, specialized garbage collectors could be implemented in D to serve the same purpose. Sean
Jun 25 2005
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <opsstiikkp23k2f5 nrage.netwin.co.nz>, Regan Heath says...
On Thu, 23 Jun 2005 08:07:06 +0000 (UTC), Mike Capp <mike.capp gmail.com>  
wrote:
 In article <opsssligap23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 + Much tighter control over memory usage than GC. (Smaller working set,
 much
 less risk of unacceptable pauses.) A bit tedious when you don't need  
 it,
 but
 irreplaceable when you do, and manageable given RAII. This point alone
 creates a
 sizeable niche in which D will _never_ supplant C/C++.

D can do this too, just diasble the GC and memory manage to your hearts content.

Except that, to return to an earlier gripe, the rules for 'auto' don't allow automatic refcounted smart pointers along the lines of boost::shared_ptr.

I'll take your word for it. I've never used them.

The basic problem is that D doesn't support copy semantics for user-defined types. So it's impossible to implement anything that does refcounting.
 Such
 pointers are pretty much required for robust non-GC memory management.

Being a C programmer for a living I can honestly say I haven't had a memory management issue for.. well ages. I think memory management is a skill, one I have learnt thru years of being bitten by it. In addition C is probably much simpler than C++ when it comes to memory management.
 Also, I
 gather that Phobos assumes GC and will leak like a sieve without it.

True, you would be programming without a standard library. I think that is to be expected, it's a "standard" library after all, for doing handling standard situations.

Not only Phobos but the *core language*. Remember, dynamic arrays (and associative arrays) are built on the GC. To avoid GC you'd have to pretend D were C and use pointers for all your storage needs. Sean
Jun 23 2005
next sibling parent reply Brad Beveridge <brad somewhere.net> writes:
Sean Kelly wrote:

 
 Not only Phobos but the *core language*.  Remember, dynamic arrays (and
 associative arrays) are built on the GC.  To avoid GC you'd have to pretend D
 were C and use pointers for all your storage needs.
 
 

it. If you want to avoid the GC in D I am assuming that you want to avoid it for performance reasons (lets not talk about avoiding the GC for pure masochistic reasons :)). In which case you must have profiled your code, found that there is a certain area that is slow/non-deterministic _because_ of the garbage collector and now you are trying to fix it. Fixing it could involve 1) Preallocate before the critical areas 2) Use freelists in the critical areas 3) Use memory that is outside the garbage collected areas and don't use new or dynamic arrays inside the critical areas 4) Don't allocate at all inside the critical areas If the garbage collector is slowing your whole program & you can't use any of the above, then I suggest that you have chosen the wrong language for what you're trying to do. I guess to sum up, my opinion is: D has a GC, thinking that the GC will cause performance problems before you have written any code is just premature optimisation. Brad
Jun 23 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d9ek1q$2in8$1 digitaldaemon.com...
 Sean Kelly wrote:

 Not only Phobos but the *core language*.  Remember, dynamic arrays (and
 associative arrays) are built on the GC.  To avoid GC you'd have to 
 pretend D
 were C and use pointers for all your storage needs.

it. If you want to avoid the GC in D I am assuming that you want to avoid it for performance reasons (lets not talk about avoiding the GC for pure masochistic reasons :)). In which case you must have profiled your code, found that there is a certain area that is slow/non-deterministic _because_ of the garbage collector and now you are trying to fix it. Fixing it could involve 1) Preallocate before the critical areas 2) Use freelists in the critical areas 3) Use memory that is outside the garbage collected areas and don't use new or dynamic arrays inside the critical areas 4) Don't allocate at all inside the critical areas

You've forgot to mention: delete. If you know that allocated block is not used anymore - delete it. D is using ordinary heap. And GC is running on this heap. As less 'garbage' you have allocated as less GC cycle would be. Using 'delete' at least is not slower than in C++. Ref-counting is a method of deterministic GC. Combined with current D non-deterministic GC can create unbeatable pair. Ref-counting is a *choice* of developer to create better and optimal system. D just does not provide such choice.
 If the garbage collector is slowing your whole program & you can't use any 
 of the above, then I suggest that you have chosen the wrong language for 
 what you're trying to do.

 I guess to sum up, my opinion is: D has a GC, thinking that the GC will 
 cause performance problems before you have written any code is just 
 premature optimisation.

But to think first is always a good thing right? Coputational complexity of auto_ptr (new/delete) is O(1) and letting GC do all your deletion is O(2*n). Please don't forget that this topic is not about only GC and heap allocations. It is also about stack allocations and *this* is more than 100 times faster than any heap and GC. Real example: in Harmonia I have class named Graphics. It is clearly temporary wrapper around HDC (on windows) class Graphics { HDC hdc; } I am *forced* to allocate it on heap: void paint() { auto Graphics gx = new Graphics(window()); draw(gx); } Paint is one of the most frequent events in GUI. D is not letting me to implement it with maximum efficiency.
Jun 23 2005
next sibling parent reply Brad Beveridge <brad somewhere.net> writes:
Andrew Fedoniouk wrote:

 Real example: in Harmonia I have class named Graphics. It is clearly 
 temporary wrapper
 around HDC (on windows)
 
 class Graphics { HDC hdc; }
 
 I am *forced* to allocate it on heap:
 
 void paint()
 {
    auto  Graphics gx = new Graphics(window());
    draw(gx);
 }
 
 Paint is one of the most frequent events in GUI.
 D is not letting me to implement it with maximum efficiency.

example doesn't matter, it doesn't change the fact you can't easily allocate classes on the stack. I guess our best bet is to gripe about things in the NG and post feature requests here http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList Brad
Jun 23 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d9eo51$2nkn$1 digitaldaemon.com...
 Andrew Fedoniouk wrote:

 Real example: in Harmonia I have class named Graphics. It is clearly 
 temporary wrapper
 around HDC (on windows)

 class Graphics { HDC hdc; }

 I am *forced* to allocate it on heap:

 void paint()
 {
    auto  Graphics gx = new Graphics(window());
    draw(gx);
 }

 Paint is one of the most frequent events in GUI.
 D is not letting me to implement it with maximum efficiency.


"why Graphics isn't a singleton". It is RAII thing. Needs to bee freed as soon as posible and order of creation deletion matters. And each window, image, etc. has its own type of Graphics. Speaking about RAII: there are many things which I am doing in C++ using auto objects (pen, brush, font - OS handles) In D I was forced to do deallocation explicitly - and this does not simplify my life. Thrown errors may create resource leaks so I was forced to redesign hevily what I have in C++ to avoid this.
 example doesn't matter, it doesn't change the fact you can't easily 
 allocate classes on the stack.
 I guess our best bet is to gripe about things in the NG and post feature 
 requests here http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList

Most of features added recently are not in this list. So what is the point maintaining it? ------------ This is from D documentation: "To have a class allocated on the stack that has a destructor, this is the same as a declaration with the auto attribute. Although the current implementation does not put such objects on the stack, future ones can." Read last statement. It is already planned as far as I can see. I think it is more convenient to implement ctors/dtors in structs though as this will cover other use cases also. Andrew.
Jun 23 2005
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
You can allocate classes on the stack, as the documentation describes, 
it's just not recommended afaik.

http://www.digitalmars.com/d/memory.html#stackclass

Anyway, if this is all it really is:

class Graphics { HDC hdc; }

You could also, theoretically, use a struct - which is on the stack by 
default iirc.  Maybe that's "wrong" because it's not using OOP, but 
that's your choice not a restriction of D.

-[Unknown]


 "Brad Beveridge" <brad somewhere.net> wrote in message 
 news:d9ek1q$2in8$1 digitaldaemon.com...
 
Sean Kelly wrote:


Not only Phobos but the *core language*.  Remember, dynamic arrays (and
associative arrays) are built on the GC.  To avoid GC you'd have to 
pretend D
were C and use pointers for all your storage needs.

Which, if I were to try and use D without a GC is exactly how I would do it. If you want to avoid the GC in D I am assuming that you want to avoid it for performance reasons (lets not talk about avoiding the GC for pure masochistic reasons :)). In which case you must have profiled your code, found that there is a certain area that is slow/non-deterministic _because_ of the garbage collector and now you are trying to fix it. Fixing it could involve 1) Preallocate before the critical areas 2) Use freelists in the critical areas 3) Use memory that is outside the garbage collected areas and don't use new or dynamic arrays inside the critical areas 4) Don't allocate at all inside the critical areas

You've forgot to mention: delete. If you know that allocated block is not used anymore - delete it. D is using ordinary heap. And GC is running on this heap. As less 'garbage' you have allocated as less GC cycle would be. Using 'delete' at least is not slower than in C++. Ref-counting is a method of deterministic GC. Combined with current D non-deterministic GC can create unbeatable pair. Ref-counting is a *choice* of developer to create better and optimal system. D just does not provide such choice.
If the garbage collector is slowing your whole program & you can't use any 
of the above, then I suggest that you have chosen the wrong language for 
what you're trying to do.

I guess to sum up, my opinion is: D has a GC, thinking that the GC will 
cause performance problems before you have written any code is just 
premature optimisation.

But to think first is always a good thing right? Coputational complexity of auto_ptr (new/delete) is O(1) and letting GC do all your deletion is O(2*n). Please don't forget that this topic is not about only GC and heap allocations. It is also about stack allocations and *this* is more than 100 times faster than any heap and GC. Real example: in Harmonia I have class named Graphics. It is clearly temporary wrapper around HDC (on windows) class Graphics { HDC hdc; } I am *forced* to allocate it on heap: void paint() { auto Graphics gx = new Graphics(window()); draw(gx); } Paint is one of the most frequent events in GUI. D is not letting me to implement it with maximum efficiency.

Jun 23 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message 
news:d9esl7$2sdf$3 digitaldaemon.com...
 You can allocate classes on the stack, as the documentation describes, 
 it's just not recommended afaik.

 http://www.digitalmars.com/d/memory.html#stackclass

 Anyway, if this is all it really is:

 class Graphics { HDC hdc; }

 You could also, theoretically, use a struct - which is on the stack by 
 default iirc.  Maybe that's "wrong" because it's not using OOP, but that's 
 your choice not a restriction of D.

http://www.digitalmars.com/d/memory.html#stackclass Sorry, but it does not call destructors. Good common library design *must* assume that exception can be thrown in user supplied drawing implementations. class Graphics { HDC hdc; this() { hdc = GetDC(....); .... } ~this() { ...; ReleaseDC(hdc); } } And library as good OS citizen *must* free OS resources allocated. This is all about RAII.
 -[Unknown]


 "Brad Beveridge" <brad somewhere.net> wrote in message 
 news:d9ek1q$2in8$1 digitaldaemon.com...

Sean Kelly wrote:


Not only Phobos but the *core language*.  Remember, dynamic arrays (and
associative arrays) are built on the GC.  To avoid GC you'd have to 
pretend D
were C and use pointers for all your storage needs.

Which, if I were to try and use D without a GC is exactly how I would do it. If you want to avoid the GC in D I am assuming that you want to avoid it for performance reasons (lets not talk about avoiding the GC for pure masochistic reasons :)). In which case you must have profiled your code, found that there is a certain area that is slow/non-deterministic _because_ of the garbage collector and now you are trying to fix it. Fixing it could involve 1) Preallocate before the critical areas 2) Use freelists in the critical areas 3) Use memory that is outside the garbage collected areas and don't use new or dynamic arrays inside the critical areas 4) Don't allocate at all inside the critical areas

You've forgot to mention: delete. If you know that allocated block is not used anymore - delete it. D is using ordinary heap. And GC is running on this heap. As less 'garbage' you have allocated as less GC cycle would be. Using 'delete' at least is not slower than in C++. Ref-counting is a method of deterministic GC. Combined with current D non-deterministic GC can create unbeatable pair. Ref-counting is a *choice* of developer to create better and optimal system. D just does not provide such choice.
If the garbage collector is slowing your whole program & you can't use 
any of the above, then I suggest that you have chosen the wrong language 
for what you're trying to do.

I guess to sum up, my opinion is: D has a GC, thinking that the GC will 
cause performance problems before you have written any code is just 
premature optimisation.

But to think first is always a good thing right? Coputational complexity of auto_ptr (new/delete) is O(1) and letting GC do all your deletion is O(2*n). Please don't forget that this topic is not about only GC and heap allocations. It is also about stack allocations and *this* is more than 100 times faster than any heap and GC. Real example: in Harmonia I have class named Graphics. It is clearly temporary wrapper around HDC (on windows) class Graphics { HDC hdc; } I am *forced* to allocate it on heap: void paint() { auto Graphics gx = new Graphics(window()); draw(gx); } Paint is one of the most frequent events in GUI. D is not letting me to implement it with maximum efficiency.


Jun 23 2005
parent Brad Beveridge <brad somewhere.net> writes:
Andrew Fedoniouk wrote:
 
 http://www.digitalmars.com/d/memory.html#stackclass
 
 Sorry, but it does not call destructors.
 Good common library design *must* assume that
 exception can be thrown in user supplied drawing
 implementations.

Walter can obviously see that auto classes should be put on the stack, I guess he just hasnt gotten to the optimisation phase of DMD's development yet. I would expect optimisation to begin post v1.0 myself. Brad
Jun 23 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d9enev$2n2e$1 digitaldaemon.com...
 Real example: in Harmonia I have class named Graphics. It is clearly
 temporary wrapper
 around HDC (on windows)

 class Graphics { HDC hdc; }

 I am *forced* to allocate it on heap:

 void paint()
 {
    auto  Graphics gx = new Graphics(window());
    draw(gx);
 }

 Paint is one of the most frequent events in GUI.
 D is not letting me to implement it with maximum efficiency.

The interesting thing about auto that I realized after it was implemented is that auto declarations behave as if they were put on the stack, so they can be put on the stack. In the future, the D compiler will do this optimization for you, you won't have to change your code at all.
Jun 25 2005
prev sibling parent reply Mike Capp <mike.capp gmail.com> writes:
In article <d9ek1q$2in8$1 digitaldaemon.com>, Brad Beveridge says...

If the garbage collector is slowing your whole program & you can't use 
any of the above, then I suggest that you have chosen the wrong language 
for what you're trying to do.

Yup. This is all I was saying in my original post. There exists a sizeable subset of C++ programmers for whom D is not a viable alternative, whether they want to switch or not.
I guess to sum up, my opinion is: D has a GC, thinking that the GC will 
cause performance problems before you have written any code is just 
premature optimisation.

A peculiar statement, particularly since D trumpets speed as a selling point. The basic characteristics and tradeoffs of GC have been well-known for decades. You don't need to write and profile a project in a new GC language to have concerns about GC performance in general. cheers Mike
Jun 23 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Mike Capp" <mike.capp gmail.com> wrote in message 
news:d9eri2$2rg0$1 digitaldaemon.com...
 In article <d9ek1q$2in8$1 digitaldaemon.com>, Brad Beveridge says...

If the garbage collector is slowing your whole program & you can't use
any of the above, then I suggest that you have chosen the wrong language
for what you're trying to do.

Yup. This is all I was saying in my original post. There exists a sizeable subset of C++ programmers for whom D is not a viable alternative, whether they want to switch or not.
I guess to sum up, my opinion is: D has a GC, thinking that the GC will
cause performance problems before you have written any code is just
premature optimisation.

A peculiar statement, particularly since D trumpets speed as a selling point. The basic characteristics and tradeoffs of GC have been well-known for decades. You don't need to write and profile a project in a new GC language to have concerns about GC performance in general.

Agreed. I though that GC euphoria already gone but.... GC is just one more way of managing memory. With pluses and minuses. Good new language shall provide developers at least choice what to use: in some places stack type of memory management is better, in other heap and of course GC. The best results can be achieved in combination of these. http://www.geocities.com/carsten_frigaard/the_toll_of_garbage_collection.pdf Andrew.
Jun 23 2005
prev sibling next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Not exactly.  The library *is* what handles dynamic arrays.  You simply 
change that if you don't want it garbage collected.

Of course, you'll still have to handle the memory, but it's not like 
arrays are a black box you can't change.

-[Unknown]


 Not only Phobos but the *core language*.  Remember, dynamic arrays (and
 associative arrays) are built on the GC.  To avoid GC you'd have to pretend D
 were C and use pointers for all your storage needs.

Jun 23 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <d9esdf$2sdf$2 digitaldaemon.com>, Unknown W. Brackets says...
Not exactly.  The library *is* what handles dynamic arrays.  You simply 
change that if you don't want it garbage collected.

Of course, you'll still have to handle the memory, but it's not like 
arrays are a black box you can't change.

But how do you do this without garbage collection? Almost any operation on a dynamic array might require a memory allocation, and the old memory has to go somewhere. If it's cleaned immediately then you could be stuck with dangling pointers (please note that I'm trying to look at this from a compiler/library writer's perspective). I suppose it may be possible to implement a conforming D compiler that does reference counting instead of garbage collection, but I'm not sure it would be a worthwhile endeavor. Sean
Jun 23 2005
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Forgive me, but that just sounds like arguing:

But, if you use a car, you can't haul around large objects like you can 
with a truck.

But, to me, it seems reasonable that if you want to haul around large 
objects, you use a truck.  You can't have dangling pointers with arrays 
anyway without a GC or knowing in advance, can you?  Maybe I'm mistaken, 
but that is specifically one of the disadvantages of reference counting, 
is it not?

Thus, it seems like if you wanted to modify D to not use garbage 
collecting - or even to use reference counting - you would have to avoid 
using slices, and instead use functions (e.g. array.slice(0, 5)) like 
you already have to in C with reference counting!

IMHO, D only makes it easier.  I don't see how it makes it harder to use 
reference counting; you just have to live without some of the nicities D 
gives you that you never had with C/C++ anyway.

-[Unknown]


 But how do you do this without garbage collection?  Almost any operation on a
 dynamic array might require a memory allocation, and the old memory has to go
 somewhere.  If it's cleaned immediately then you could be stuck with dangling
 pointers (please note that I'm trying to look at this from a compiler/library
 writer's perspective).  I suppose it may be possible to implement a conforming
D
 compiler that does reference counting instead of garbage collection, but I'm
not
 sure it would be a worthwhile endeavor.

Jun 23 2005
prev sibling next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 23 Jun 2005 14:29:31 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:
 In article <opsstiikkp23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 On Thu, 23 Jun 2005 08:07:06 +0000 (UTC), Mike Capp  
 <mike.capp gmail.com>
 wrote:
 In article <opsssligap23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 + Much tighter control over memory usage than GC. (Smaller working  
 set,
 much
 less risk of unacceptable pauses.) A bit tedious when you don't need
 it,
 but
 irreplaceable when you do, and manageable given RAII. This point  
 alone
 creates a
 sizeable niche in which D will _never_ supplant C/C++.

D can do this too, just diasble the GC and memory manage to your hearts content.

Except that, to return to an earlier gripe, the rules for 'auto' don't allow automatic refcounted smart pointers along the lines of boost::shared_ptr.

I'll take your word for it. I've never used them.

The basic problem is that D doesn't support copy semantics for user-defined types. So it's impossible to implement anything that does refcounting.

After reading this thread and also this one Andrew dug up: http://www.digitalmars.com/d/archives/7988.html It appears you need a type that: 1 - is stack based. 2 - has deterministic destruction. 3 - has opAssign. It seems (from recent posts) that Walter plans to put auto classes on the stack, so they'd then fulfil requirements 1 and 2. But what about 3? To me, opAssign isn't generally a good idea for classes (assigning a value to a reference seems illogical) but would be a good for structs (they're value types, assignment assigns a value). Can you do reference counting without opAssign? The idea for D (or so I've read) is that opAssign isn't required, instead you use a copy constructor. Now, I've little experience with ref counting, or with writing an implementation of one, but, does this work? import std.c.windows.windows; import std.random; import std.thread; import std.stdio; class RefPtr { RefPtr parent; Object resource = null; int refs = 0; this(Object res) { resource = res; writefln("ThreadID=(",Thread.getThis().id,") Initial RefPtr for resource=(",resource,")"); increment(); } this(RefPtr rhs) { parent = rhs; parent.increment(); writefln("ThreadID=(",Thread.getThis().id,") Ref=(",parent.refs,") for resource=(",parent.resource,")"); } ~this() { int r; if ((r = decrement()) == 0) { writefln("ThreadID=(",Thread.getThis().id,") release last ref Ref=(",r,")"); if (parent) parent = null; else if (resource) { writefln("ThreadID=(",Thread.getThis().id,") delete resource=(",resource,")"); delete resource; resource = null; } } writefln("ThreadID=(",Thread.getThis().id,") release Ref=(",r,")"); } protected: int increment() { int ret; if (parent) ret = parent.increment(); else { synchronized(this) { ret = ++refs; writefln("ThreadID=(",Thread.getThis().id,") increment to Ref=(",refs,")"); } } return ret; } int decrement() { int ret; if (parent) ret = parent.decrement(); else { synchronized(this) { ret = --refs; writefln("ThreadID=(",Thread.getThis().id,") decrement to Ref=(",refs,")"); } } return ret; } } class Resource { char[] name = "11 was a racehorse"; char[] toString() { return name; } } RefPtr pbob; static this() { pbob = new RefPtr(new Resource()); } static ~this() { delete pbob; } void main() { Thread t; int i; writefln("ThreadID=(",Thread.getThis().id,") is the main thread"); for(i = 0; i < 10; i++) { t = new Thread(&thread_function,null); t.start(); } /* How do I wait for all threads? This code cause access violation. while(true) { i = 0; foreach(Thread t; Thread.getAll()) { if (t.getState() == Thread.TS.TERMINATED) i++; } if (i == 10) break; Sleep(100); }*/ Sleep(5000); writefln("Main exiting"); } int thread_function(void* isnull) { auto RefPtr p = new RefPtr(pbob); Sleep(1000+rand()%1000); return 0; } Regan
Jun 23 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
AFAIK, some of the threads in getAll() could be null.  You might want 
something like:

     while(true)
     {
         i = 0;
         foreach(Thread t; Thread.getAll())
         {
             if (t !is null && t.getState() == Thread.TS.TERMINATED) i++;
         }
         if (i == 10) break;
         Sleep(100);
     }

Which may or may not fix the access violation.  Anyway, I'd do this:

     Thread[] t;
     int i;

     writefln("ThreadID=(",Thread.getThis().id,") is the main thread");

     t.length = 10;
     for (i = 0; i < t.length; i++)
     {
         t[i] = new Thread(&thread_function,null);
         t[i].start();
     }

     bool keep_going = true;
     while (keep_going)
     {
         keep_going = false;

         foreach (Thread th; t)
         {
             if (th.getState() != Thread.TS.TERMINATED)
                 keep_going = true;
         }

         Sleep(100);
     }

Or something instead.  There's probably a lot better way than that, though.

-[Unknown]


     /* How do I wait for all threads? This code cause access violation.
     while(true)
     {
         i = 0;
         foreach(Thread t; Thread.getAll())
         {
             if (t.getState() == Thread.TS.TERMINATED) i++;
         }
         if (i == 10) break;
         Sleep(100);
     }*/

Jun 23 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 23 Jun 2005 19:38:43 -0700, Unknown W. Brackets  
<unknown simplemachines.org> wrote:
 AFAIK, some of the threads in getAll() could be null.

Yeah, that was it.
 Which may or may not fix the access violation.  Anyway, I'd do this:

      Thread[] t;
      int i;

      writefln("ThreadID=(",Thread.getThis().id,") is the main thread");

      t.length = 10;
      for (i = 0; i < t.length; i++)
      {
          t[i] = new Thread(&thread_function,null);
          t[i].start();
      }

      bool keep_going = true;
      while (keep_going)
      {
          keep_going = false;

          foreach (Thread th; t)
          {
              if (th.getState() != Thread.TS.TERMINATED)
                  keep_going = true;
          }

          Sleep(100);
      }

 Or something instead.  There's probably a lot better way than that,  
 though.

I considered storing them all, decided I didn't want to (on a whim really). Regan
Jun 23 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:d9eh0b$2et2$1 digitaldaemon.com...
 Not only Phobos but the *core language*.  Remember, dynamic arrays (and
 associative arrays) are built on the GC.  To avoid GC you'd have to

 were C and use pointers for all your storage needs.

Associative arrays, yes. Dynamic arrays, no. Dynamic arrays are only involved with the gc when you 'new' them or 'delete' them or set the .length property or do .dup. You can create dynamic arrays using malloc(), or you can set them to point to anything in memory.
Jun 25 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <d9j6gr$125e$1 digitaldaemon.com>, Walter says...
"Sean Kelly" <sean f4.ca> wrote in message
news:d9eh0b$2et2$1 digitaldaemon.com...
 Not only Phobos but the *core language*.  Remember, dynamic arrays (and
 associative arrays) are built on the GC.  To avoid GC you'd have to

 were C and use pointers for all your storage needs.

Associative arrays, yes. Dynamic arrays, no. Dynamic arrays are only involved with the gc when you 'new' them or 'delete' them or set the .length property or do .dup. You can create dynamic arrays using malloc(), or you can set them to point to anything in memory.

I imagine using the ~= operator could cause a GC allocation too. But what I was getting at is that these are all built-in features of a basic type. How could I reasonably use arrays without setting the length property, for example, since D doesn't use a terminating null to indicate string length? Instead, I'd likely create a new struct similar to the one already used for arrays and slice the data when I wanted to pass it to a (non-modifying) D function. I personally have no problem with this. I just figured it was worth pointing out that some basic types in the language rely to some degree on the existence of a GC. Sean
Jun 25 2005
parent "Walter" <newshound digitalmars.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message
news:d9k04v$2a41$1 digitaldaemon.com...
 I imagine using the ~= operator could cause a GC allocation too.

Yes, you're right.
 But what I was
 getting at is that these are all built-in features of a basic type.  How

 reasonably use arrays without setting the length property, for example,

 doesn't use a terminating null to indicate string length?  Instead, I'd

 create a new struct similar to the one already used for arrays and slice

 data when I wanted to pass it to a (non-modifying) D function.  I

 have no problem with this.  I just figured it was worth pointing out that

 basic types in the language rely to some degree on the existence of a GC.

You can allocate a dynamic array without using the gc via: char* p = cast(char*) malloc(length); char[] a = p[0 .. length]; It's not as convenient as using new, but it does work. I do understand your point, I just wanted to emphasize that one can effectively use dynamic arrays without ever needing the gc.
Jun 25 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Mike Capp" <mike.capp gmail.com> wrote in message
news:d9dqja$15m5$1 digitaldaemon.com...
 In article <opsssligap23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 + Much tighter control over memory usage than GC. (Smaller working set,
 much
 less risk of unacceptable pauses.) A bit tedious when you don't need



 but
 irreplaceable when you do, and manageable given RAII. This point alone
 creates a
 sizeable niche in which D will _never_ supplant C/C++.

D can do this too, just diasble the GC and memory manage to your hearts content.

Except that, to return to an earlier gripe, the rules for 'auto' don't

 automatic refcounted smart pointers along the lines of boost::shared_ptr.

 pointers are pretty much required for robust non-GC memory management.

People have written robust non-GC memory management long before boost::shared_ptr existed. I know, I've done enough of them <g>. Granted, shared_ptr makes it easier, but it isn't required.
 Also, I gather that Phobos assumes GC and will leak like a sieve without

Correct, but someone needing refcounted allocation for some parts of the program doesn't imply they need it for all parts. GC can coexist peacefully with other strategies.
 It's not so much "D can do this" as "you can do this if you're prepared to

 the language every step of the way".

I see it the other way around. A *large* part of the time I'd spend writing C++ code was dealing with memory management issues for just about everything. It sure felt that I was fighting it every step of the way. With D, automatic memory management takes care of the vast bulk of routine chores, and the bit that's left over can be handled explicitly without much pain.
 You can do (real) GC in C++ by plugging in
 something like the Boehm collector. Not many people do.

I've done it.
 You certainly don't see
 ticks for C++ in the "GC" column in language comparison charts.

That's because it isn't part of the standard language, and using it successfully with C++ requires one to be rather thorough in understanding how it works and what its limitations are. Major C++ vendors have neglected it. Digital Mars C++ is the only one I know of to support it in the official distribution.
Jun 24 2005
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Mike Capp" <mike.capp gmail.com> wrote in message
news:d9boe7$26cr$1 digitaldaemon.com...
 + Much tighter control over memory usage than GC. (Smaller working set,

 less risk of unacceptable pauses.) A bit tedious when you don't need it,

 irreplaceable when you do, and manageable given RAII. This point alone

 sizeable niche in which D will _never_ supplant C/C++.

But D does support both RAII and explicit memory allocation. Additionally, the pause issue is easilly dealt with when it matters.
Jun 24 2005