|
Archives
D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger
C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows
digitalmars.empire
digitalmars.DMDScript
|
digitalmars.D - What language role does D fullfill?
↑ ↓ ← → 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.
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → Brad Beveridge <brad somewhere.net> writes:
Oh dear, I should have looked at the link first - they're still UGLY!
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → 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-
↑ ↓ ← → "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!
↑ ↓ ← → 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.
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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 +/
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → 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-
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → 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-
↑ ↓ ← → "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.
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → "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
↑ ↓ ← → 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
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → "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
↑ ↓ ← → "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);
}*/
↑ ↓ ← → "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
↑ ↓ ← → "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.
↑ ↓ ← → 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
↑ ↓ ← → "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.
↑ ↓ ← → "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.
↑ ↓ ← → "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.
|
|
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next
