digitalmars.D - What language role does D fullfill?

clayasaurus (77/77) Jun 21 2005 Ok, I'm just wondering what people think. We all know to use the right

Brad Beveridge (9/13) Jun 21 2005 That's the main reason that I prefer D where I can, although it doesn't

clayasaurus (3/20) Jun 21 2005 Yes. Maybe the whole point of D should just simply be to avoid this...

Manfred Nowak (3/4) Jun 21 2005 I never thought of number 9.

Victor Nakoryakov (14/17) Jun 21 2005 Yeap, good analogy. However current situation has a drawback. If I drive...
pragma (13/16) Jun 21 2005 OT: Living here in the USA, I had no clue what a "Lada" was.

Brad Beveridge (6/26) Jun 21 2005 I've recently moved to the USA, but couldn't think of a brand of car

Brad Beveridge (1/1) Jun 21 2005 Oh dear, I should have looked at the link first - they're still UGLY!

Andrew Fedoniouk (13/14) Jun 21 2005 100% true.

Sean Kelly (7/11) Jun 21 2005 The most commonly mentioned car with that sort of reputation in the US i...

Nod (4/8) Jun 21 2005 Nah, that would be D. Here is C++ right after a "comparison" :)

Jarrett Billingsley (4/7) Jun 21 2005 What's funnier about that picture is that it looks like they're _selling...

clayasaurus (8/42) Jun 21 2005 I think the USA equivilent is the Geo!

David Medlock (6/57) Jun 22 2005 The metro is the Suzuki swift, branded with the geo name.
Charlie (4/46) Jun 23 2005 I had a geo :P.

Tom S (5/10) Jun 21 2005 Well, to me Lada is more like this one:

Victor Nakoryakov (10/21) Jun 21 2005 Aaarrggghh... That is beggining of 1980-th.

Jarrett Billingsley (3/8) Jun 21 2005 Funny, they look very much like early-to-mid-90s Fords.

pragma (3/11) Jun 21 2005 Yikes, not at all easy on the eyes. Reminds me of a Yugo.

Nod (4/22) Jun 21 2005 And here is the more traditional look of the (in)famous Lada:

Andrew Fedoniouk (13/45) Jun 21 2005 "Russian version of the Fiat 124: the "Zhiguli" (marketed abroad by name...

Walter (7/19) Jun 24 2005 And that really is a killer feature when you think about it. The only
Walter (3/6) Jun 24 2005 LOL, considering the car I'm building is www.mitymopar.com

Andrew Fedoniouk (14/20) Jun 25 2005 "they both get you where you want to do, but one gets you there in style...

Walter (4/8) Jun 25 2005 the

pragma (39/44) Jun 21 2005 I know how you feel. I, for one, took the longest possible road to get ...
Nod (10/14) Jun 21 2005 I just think that D hits a sweet spot. C doesn't scale, my apps should. ...
Andrew Fedoniouk (10/12) Jun 21 2005 I guess that first D needs features that C++ can do.

Regan Heath (43/56) Jun 22 2005 WARNING: for all those who can't stand posts containing opinion and litt...

Andrew Fedoniouk (82/138) Jun 22 2005 For classes, yes, as variable holding class instance is always reference...

Regan Heath (132/259) Jun 22 2005 We agree about classes.

Derek Parnell (16/18) Jun 22 2005 One thing that is still a bit of a problem is having a 'string' type tha...

Regan Heath (30/44) Jun 22 2005 True, it is a pain.

Sean Kelly (7/33) Jun 22 2005 Personally, I'd be happy with explicit transcoding using the cast operat...

Derek Parnell (11/49) Jun 22 2005 The "cast(char[])" never does run-time UTF conversion. It does do
Regan Heath (4/11) Jun 22 2005 Just with foreach, as Derek posted.

Mike Capp (43/70) Jun 22 2005 Optionally. C++ usually describes itself as "multiparadigm" - you can us...

Regan Heath (5/12) Jun 22 2005 D can do this too, just diasble the GC and memory manage to your hearts ...

Mike Capp (11/20) Jun 23 2005 Except that, to return to an earlier gripe, the rules for 'auto' don't a...

Regan Heath (14/40) Jun 23 2005 I'll take your word for it. I've never used them.

Mike Capp (15/24) Jun 23 2005 It depends very much on the kind of data structures needed for your app ...

Regan Heath (11/29) Jun 23 2005 I use malloc/strdup all the time.

Jarrett Billingsley (9/10) Jun 23 2005 You know, objects that point to each other. Even if nothing else is

Regan Heath (15/27) Jun 23 2005 Coo, I suspected that's what was meant :)

Brad Beveridge (9/14) Jun 23 2005 As I understand it, it works like: Starting from the CPU registers the

Regan Heath (4/16) Jun 23 2005 Ahh.. thanks, good description.

Andrew Fedoniouk (31/58) Jun 23 2005 Cyclic references is what COM+ (reference counting) these days is dying...

Regan Heath (31/100) Jun 23 2005 Yep, I see.

Walter (6/19) Jun 25 2005 Actually, any call to 'new' in C++ has no guarantee that it will return

Sean Kelly (6/10) Jun 25 2005 I haven't much looked into them, but I imagine specialized memory manage...

Sean Kelly (7/38) Jun 23 2005 The basic problem is that D doesn't support copy semantics for user-defi...

Brad Beveridge (20/26) Jun 23 2005 Which, if I were to try and use D without a GC is exactly how I would do...

Andrew Fedoniouk (31/57) Jun 23 2005 You've forgot to mention: delete.

Brad Beveridge (7/23) Jun 23 2005 I was going to ask why Graphics isn't a singleton - but really the

Andrew Fedoniouk (23/45) Jun 23 2005 "why Graphics isn't a singleton".

Unknown W. Brackets (9/95) Jun 23 2005 You can allocate classes on the stack, as the documentation describes,

Andrew Fedoniouk (14/108) Jun 23 2005 http://www.digitalmars.com/d/memory.html#stackclass

Brad Beveridge (6/13) Jun 23 2005 I think that the only solution to this is to wait :)

Walter (6/18) Jun 25 2005 The interesting thing about auto that I realized after it was implemente...

Mike Capp (10/16) Jun 23 2005 Yup. This is all I was saying in my original post. There exists a sizeab...

Andrew Fedoniouk (9/26) Jun 23 2005 Agreed. I though that GC euphoria already gone but....

Unknown W. Brackets (5/8) Jun 23 2005 Not exactly. The library *is* what handles dynamic arrays. You simply

Sean Kelly (9/13) Jun 23 2005 But how do you do this without garbage collection? Almost any operation...

Unknown W. Brackets (16/23) Jun 23 2005 Forgive me, but that just sounds like arguing:

Regan Heath (143/174) Jun 23 2005 After reading this thread and also this one Andrew dug up:

Unknown W. Brackets (35/46) Jun 23 2005 AFAIK, some of the threads in getAll() could be null. You might want

Regan Heath (5/29) Jun 23 2005 Yeah, that was it.

Walter (7/10) Jun 25 2005 pretend D

Sean Kelly (10/20) Jun 25 2005 I imagine using the ~= operator could cause a GC allocation too. But wh...

Walter (15/24) Jun 25 2005 Yes, you're right.

Walter (25/47) Jun 24 2005 it,

Walter (7/11) Jun 24 2005 much

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





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:

  - high level with low level retainability (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.


and easy implementation is the priority.

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

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

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

Just my 2 cents.

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

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

Jun 21 2005

Brad Beveridge <brad somewhere.net> writes:

clayasaurus wrote:

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

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

Brad

Jun 21 2005

clayasaurus <clayasaurus gmail.com> writes:

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

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

Yes. Maybe the whole point of D should just simply be to avoid this... 
http://www.andromeda.com/people/ddyer/topten.html

Jun 21 2005

Manfred Nowak <svv1999 hotmail.com> writes:

clayasaurus <clayasaurus gmail.com> wrote:

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

I never thought of number 9.

-manfred

Jun 21 2005

Victor Nakoryakov <nail-mail mail.ru> writes:

Brad Beveridge wrote:
 So for me the difference between C/C++ and D is like the difference 
 between driving a Lada and driving a Merceedes - they both get you where 
 you want to do, but one gets you there in style and comfort :)

Yeap, good analogy. However current situation has a drawback. If I drive 
Lada I know that when it brokes I can visit nearest autoshop and buy 
broken detail for a $3, if I drive Mercedes I'll have to visit half 
shops of Moscow just to find detail, and another half to find it cheaper 
then $1000. So if I'll start big project in D I'ld have to write all for 
myself and GUI lib, and Math lib, and parsers, and plugins for IDE's, 
and etc etc.
So for now I prefer C++ for money and D for fun... an have to drive a 
Lada in programming as well as in real life :)

-- 
Victor Nakoryakov
nail-mail<at>mail<dot>ru

Krasnoznamensk, Moscow, Russia

Jun 21 2005

pragma <pragma_member pathlink.com> writes:

In article <d99kcq$hd0$1 digitaldaemon.com>, Brad Beveridge says...
So for me the difference between C/C++ and D is like the difference 
between driving a Lada and driving a Merceedes - they both get you where 
you want to do, but one gets you there in style and comfort :)

OT: Living here in the USA, I had no clue what a "Lada" was.  

So here we go. This is the low-end model on their website:

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

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

And the sales pitch:

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

- EricAnderton at yahoo

Jun 21 2005

Brad Beveridge <brad somewhere.net> writes:

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

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

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

Brad

Jun 21 2005

Brad Beveridge <brad somewhere.net> writes:

Oh dear, I should have looked at the link first - they're still UGLY!

Jun 21 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d99ten$nmj$2 digitaldaemon.com...
 Oh dear, I should have looked at the link first - they're still UGLY!

100% true.

It is ugly, noisy, simplistic, etc.

But remeber that story about noise levels on Russian ships?
Also true. But they ARE flying
http://news.yahoo.com/news?tmpl=story&cid=624&ncid=624&e=4&u=/ap/20050621/ap_on_sc/russia_space_station_7
:-P

This does not mean that ergonomic factors are not valuable. They ARE 
valuable.
Question just about priorities in limited time/resource frame and overall
robustness of complex systems.

Andrew.

Jun 21 2005

Sean Kelly <sean f4.ca> writes:

In article <d99tcn$nmj$1 digitaldaemon.com>, Brad Beveridge says...
I've recently moved to the USA, but couldn't think of a brand of car 
that has a poor reputation for comfort, etc :)  I'm originally from New 
Zealand, and Lada's (although they may be better now) don't have a good 
reputation there :)

The most commonly mentioned car with that sort of reputation in the US is
probably the Yugo:

http://www.mcnabbs.org/peter/pics/yugo.jpg

But I think we're being a bit unfair to C/C++.  It's probably closer to this:

http://www.sovietarmy.com/vehicles/t-55_icon.jpg


:) Sean

Jun 21 2005

Nod <Nod_member pathlink.com> writes:

In article <d99uv6$ov1$1 digitaldaemon.com>, Sean Kelly says...
 <snip>

But I think we're being a bit unfair to C/C++.  It's probably closer to this:

http://www.sovietarmy.com/vehicles/t-55_icon.jpg


:) Sean

Nah, that would be D. Here is C++ right after a "comparison" :)

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

-Nod-

Jun 21 2005

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Nod" <Nod_member pathlink.com> wrote in message 
news:d9a0g6$qgg$1 digitaldaemon.com...
 In article <d99uv6$ov1$1 digitaldaemon.com>, Sean Kelly says...
 Nah, that would be D. Here is C++ right after a "comparison" :)

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

What's funnier about that picture is that it looks like they're _selling_ 
it!

Jun 21 2005

clayasaurus <clayasaurus gmail.com> writes:

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

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

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

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

 And the sales pitch:

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

 - EricAnderton at yahoo

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

I think the USA equivilent is the Geo!

Brand new...
http://www.canadiandriver.com/articles/jc/images/98metro_cpe.jpg

What happens when you drive them too much...
http://www.crh.noaa.gov/ict/wxstory/2001070813_mvc-016s.jpg
http://www.awsomecar.com/pix/wreckmetro.jpg

I know someone who has a geo, it looks like crap.

Jun 21 2005

David Medlock <noone nowhere.com> writes:

clayasaurus wrote:
 Brad Beveridge wrote:
 
 pragma wrote:

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



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

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

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

 And the sales pitch:

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

 - EricAnderton at yahoo



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

 Brad

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


The metro is the Suzuki swift, branded with the geo name.

I had a Geo Storm Gsi (which was basically an Isuzu Impulse) which had a 
handling package by Lotus, and it was a great car(one of my favorites 
that I have owned).

-DavidM

Jun 22 2005

Charlie <Charlie_member pathlink.com> writes:

In article <d9a158$qmq$1 digitaldaemon.com>, clayasaurus says...
Brad Beveridge wrote:
 pragma wrote:
 
 In article <d99kcq$hd0$1 digitaldaemon.com>, Brad Beveridge says...

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

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

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

 And the sales pitch:

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

 - EricAnderton at yahoo

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

I think the USA equivilent is the Geo!

Brand new...
http://www.canadiandriver.com/articles/jc/images/98metro_cpe.jpg

What happens when you drive them too much...
http://www.crh.noaa.gov/ict/wxstory/2001070813_mvc-016s.jpg
http://www.awsomecar.com/pix/wreckmetro.jpg

I know someone who has a geo, it looks like crap.


I had a geo :P.

The only card I've ever wrecked lol.

Charlie

Jun 23 2005

Tom S <h3r3tic remove.mat.uni.torun.pl> writes:

pragma wrote:
 OT: Living here in the USA, I had no clue what a "Lada" was.  
 
 So here we go. This is the low-end model on their website:
 
 http://www.lada.de/html_e/content_e/models/lada_2110_pricelist.html

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



-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

Jun 21 2005

Victor Nakoryakov <nail-mail mail.ru> writes:

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

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

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

Aaarrggghh... That is beggining of 1980-th.
http://www.autogazeta.com/c/1/b/ld00111.jpg
http://www.mayorov.com/auto/vaz/1119/_images/001.jpg
http://img.2dehands.nl/f/normal/8694886.jpg
That is Lada.

-- 
Victor Nakoryakov
nail-mail<at>mail<dot>ru

Krasnoznamensk, Moscow, Russia

Jun 21 2005

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Victor Nakoryakov" <nail-mail mail.ru> wrote in message 
news:d9a0f7$qg1$1 digitaldaemon.com...
 Aaarrggghh... That is beggining of 1980-th.
 http://www.autogazeta.com/c/1/b/ld00111.jpg
 http://www.mayorov.com/auto/vaz/1119/_images/001.jpg
 http://img.2dehands.nl/f/normal/8694886.jpg
 That is Lada.

Funny, they look very much like early-to-mid-90s Fords.

Jun 21 2005

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

Yikes, not at all easy on the eyes.  Reminds me of a Yugo.

- EricAnderton at yahoo

Jun 21 2005

Nod <Nod_member pathlink.com> writes:

In article <d99sua$nkm$1 digitaldaemon.com>, pragma says...
In article <d99kcq$hd0$1 digitaldaemon.com>, Brad Beveridge says...
So for me the difference between C/C++ and D is like the difference 
between driving a Lada and driving a Merceedes - they both get you where 
you want to do, but one gets you there in style and comfort :)

OT: Living here in the USA, I had no clue what a "Lada" was.  

So here we go. This is the low-end model on their website:

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

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

And the sales pitch:

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

- EricAnderton at yahoo

And here is the more traditional look of the (in)famous Lada:

http://mclellansautomotive.com/photos/B31016.jpg

-Nod-

Jun 21 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

"Nod" <Nod_member pathlink.com> wrote in message 
news:d99ups$osl$1 digitaldaemon.com...
 In article <d99sua$nkm$1 digitaldaemon.com>, pragma says...
In article <d99kcq$hd0$1 digitaldaemon.com>, Brad Beveridge says...
So for me the difference between C/C++ and D is like the difference
between driving a Lada and driving a Merceedes - they both get you where
you want to do, but one gets you there in style and comfort :)

OT: Living here in the USA, I had no clue what a "Lada" was.

So here we go. This is the low-end model on their website:

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

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

And the sales pitch:

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

- EricAnderton at yahoo

 And here is the more traditional look of the (in)famous Lada:

 http://mclellansautomotive.com/photos/B31016.jpg

"Russian version of the Fiat 124: the "Zhiguli" (marketed abroad by name 
"Lada") (on the photo, the first version, called "2101", 1970, I guess). 
This car was, for the Russians, the "car of the people", like the Citroen 
2CV in France, or the VW Beetle in Germany. It remains the best-seller in 
Russia, because of the essentiality, the low price and the facility of 
reparation."

And here is Lada "Revolution 2" :)

http://digilander.libero.it/cuoccimix/IMG_revolution2_front.jpg
http://digilander.libero.it/cuoccimix/IMG_Revolution2_back.jpg
http://digilander.libero.it/cuoccimix/ladatms2.jpg

Andrew.

Jun 21 2005

"Walter" <newshound digitalmars.com> writes:

"Brad Beveridge" <brad somewhere.net> wrote in message
news:d99kcq$hd0$1 digitaldaemon.com...
 clayasaurus wrote:

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

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

And that really is a killer feature when you think about it. The only
problem is it doesn't stand out very well just from reading the
documentation. You have to drive it, so to speak, to see it.

BTW, I'm looking at rewriting another major tool in D. It looks to become a
lot simpler.

Jun 24 2005

"Walter" <newshound digitalmars.com> writes:

"Brad Beveridge" <brad somewhere.net> wrote in message
news:d99kcq$hd0$1 digitaldaemon.com...
 So for me the difference between C/C++ and D is like the difference
 between driving a Lada and driving a Merceedes - they both get you where
 you want to do, but one gets you there in style and comfort :)

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

Jun 24 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

"Walter" <newshound digitalmars.com> wrote in message 
news:d9gcl8$1k2r$1 digitaldaemon.com...
 "Brad Beveridge" <brad somewhere.net> wrote in message
 news:d99kcq$hd0$1 digitaldaemon.com...
 So for me the difference between C/C++ and D is like the difference
 between driving a Lada and driving a Merceedes - they both get you where
 you want to do, but one gets you there in style and comfort :)

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

"they both get you where you want to do, but one gets you there in style and 
comfort :)"

Ha! Here is my Subaru Forester after it felt 30 meters and 3 times over the 
roof.
http://terrainformatica.com/screenshots/subaru.jpg

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

AWD works. But not always as you may see.

The same about GC and other language features :)

Resume: It is a programmer/driver who are responsible.
I mean blind relying on AWD (GC/heap/whatever nice features you've got)
can cause real problems.

Andrew.

Jun 25 2005

"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

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

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

Ouch! You are lucky.

Jun 25 2005

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


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

Java", but that's not completely true... yet.

- EricAnderton at yahoo

Jun 21 2005

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

vendor-locked-in, my apps can't be.

What I like about D is that it balances all these features, and still manages to
be fun to program in.

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

Aspect-oriented programming. While not new, doing it cleanly and sanely would
clearly nudge D one notch higher on my scale. (I do have some ideas regarding
this, but I'll save that for another thread).

-Nod-

Jun 21 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

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

I guess that first D needs features that C++ can do.
Beg my pardon but this again about: opAssign & co., 'const', struct 
ctor/dtor.
and remove 'auto' as too controversial.

Without these it is too hard to C++ (btw and Java) developer to switch to D.
Serious development teams where 'const' is a matter of culture and
tool for collaborative work will definitely stay with C++.

In any case phobos shall include string class/object/whatever allowing
to use it as std::string or java.lang.String.

Andrew.

Jun 21 2005

"Regan Heath" <regan netwin.co.nz> writes:

On Tue, 21 Jun 2005 23:03:15 -0700, Andrew Fedoniouk  
<news terrainformatica.com> wrote:
 If D is to be used widely, do we need to add something new? Something  
 that
 no other language can do? (metaprogramming anyone?)


WARNING: for all those who can't stand posts containing opinion and little  
or no actual argument, stop reading now. I am posting this as a statement  
of opinion, in response to a statement of opinion. I am not trying to  
start any of these arguments (again) here and now. If we really want to  
start any of them up again I suggest a new thread for each one.

 I guess that first D needs features that C++ can do.
 Beg my pardon but this again about: opAssign & co.

I think there is some merit in opAssign for structs. Or, if ctors were  
added to structs having = call the ctor.

IIRC one of the design patterns/goals for D was that opAssign was not  
required for classes, instead copy constructors should be used. The idea  
being the explicit/obvious nature of constructors was preferrable to  
assignment overloading.

, 'const'

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

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

, struct
 ctor/dtor.

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

On the other hand a ctor is possible, and I think it'd be useful.

 and remove 'auto' as too controversial.

What's controversial about it?

 Without these it is too hard to C++ (btw and Java) developer to switch  
 to D.

Being primarily a C developer I can't really comment, except to say that I  
have used C++ and Java and vastly prefer D for a number of reasons.

 Serious development teams where 'const' is a matter of culture and
 tool for collaborative work will definitely stay with C++.

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

 In any case phobos shall include string class/object/whatever allowing
 to use it as std::string or java.lang.String.

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

I reckon the only problem at present is that library developers will  
choose different UTF types and we'll need to transcode string data to/from  
all our library calls. The only solution I can think of is to compile all  
libraries 6 times, a debug and release for each char type. This allows the  
application programmer to decide on the string type to use internally and  
link the correct libraries. Note, I'm only talking about selecting the  
'internal' char type, not the char type of the various data sources your  
application might read/write.

Regan

Jun 22 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opssrfjcrn23k2f5 nrage.netwin.co.nz...
 On Tue, 21 Jun 2005 23:03:15 -0700, Andrew Fedoniouk 
 <news terrainformatica.com> wrote:
 If D is to be used widely, do we need to add something new? Something 
 that
 no other language can do? (metaprogramming anyone?)


 WARNING: for all those who can't stand posts containing opinion and little 
 or no actual argument, stop reading now. I am posting this as a statement 
 of opinion, in response to a statement of opinion. I am not trying to 
 start any of these arguments (again) here and now. If we really want to 
 start any of them up again I suggest a new thread for each one.

 I guess that first D needs features that C++ can do.
 Beg my pardon but this again about: opAssign & co.

 I think there is some merit in opAssign for structs. Or, if ctors were 
 added to structs having = call the ctor.

 IIRC one of the design patterns/goals for D was that opAssign was not 
 required for classes, instead copy constructors should be used. The idea 
 being the explicit/obvious nature of constructors was preferrable to 
 assignment overloading.

For classes, yes, as variable holding class instance is always reference.
For structs situation is different. As a rule struct variable is holding
value itself. Naturally class builds a safe envelope around its data.
Class a,b; a = b; will not destroy data of a;
Struct does not have such feature. a = b there will overwrite 'a' value 
silently.
And D is not helping you here to catch this moment.

Classes do not need opAssign. Morover there are just no such operation
for class variables. Assignment  there is always assignment of references 
(not data)

 , 'const'

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

BTW: 'const' is a part of ANSI C too.

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

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

Let's say D will alow us to use keyword const as part of the type name:
so I can create:

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

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

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

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

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

 , struct
 ctor/dtor.

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

I hope this is the reason (and not because of some religion involved).
But compiler can handle now 'auto' for stack class variables.
I don't think that it will be more difficult to implement calling of struct 
dtors
in the same manner.

The only complex thing is struct static initialization/destruction.
Also intitialization of array of structs could be an implementation problem.

 On the other hand a ctor is possible, and I think it'd be useful.

 and remove 'auto' as too controversial.

 What's controversial about it?

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

 Without these it is too hard to C++ (btw and Java) developer to switch 
 to D.

 Being primarily a C developer I can't really comment, except to say that I 
 have used C++ and Java and vastly prefer D for a number of reasons.

 Serious development teams where 'const' is a matter of culture and
 tool for collaborative work will definitely stay with C++.

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

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

Non-deterministic GC (the same as in D, btw) is available for C/C++ so
it is not a big motivation. What else? The only thing is 1) better syntax
and 2) set of ready to use builtin types. The latter is definitely not full 
without 'const'.
The first is not full without opAssign and ctors/dtors.

 In any case phobos shall include string class/object/whatever allowing
 to use it as std::string or java.lang.String.

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

For your personally and for small projects probably not.

But consider development of components/libraries of a big scale.

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

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

will throw an error.

Simple assignment of one character is making the whole system fragile.
Consider that you have two developers on East Coast, three on the West
and yourself sitting in lets say Michigan trying to find who and where in 
depths of your project
changed such value. With Java/C++ strings such sitations are just 
impossible.
Again, D char[] is a character array and not a string (value).

Yes you can always .dup your 'strings'.
The question: is this a real solution?

 I reckon the only problem at present is that library developers will 
 choose different UTF types and we'll need to transcode string data to/from 
 all our library calls. The only solution I can think of is to compile all 
 libraries 6 times, a debug and release for each char type. This allows the 
 application programmer to decide on the string type to use internally and 
 link the correct libraries. Note, I'm only talking about selecting the 
 'internal' char type, not the char type of the various data sources your 
 application might read/write.

 Regan

Jun 22 2005

"Regan Heath" <regan netwin.co.nz> writes:

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

 I think there is some merit in opAssign for structs. Or, if ctors were
 added to structs having = call the ctor.

 IIRC one of the design patterns/goals for D was that opAssign was not
 required for classes, instead copy constructors should be used. The idea
 being the explicit/obvious nature of constructors was preferrable to
 assignment overloading.

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

We agree about classes.

 For structs situation is different. As a rule struct variable is holding
 value itself.

It is a value type.

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

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

That is the very point of using a struct. A struct is a value type, when  
you assign something to a value, it assigns that value.

 And D is not helping you here to catch this moment.

Catch what? The fact that you've chosen to assign a value? You may as well  
ask it to catch the assignment of an 'int', eg "int i = 5;"

I cannot see the need to prevent assignments, at present no assignment is  
allowed except that of the exact same type (talking about structs) eg.

struct A {}
struct B {}

A a;
B b;
B c;

a=b; //error
b=c; //ok


To prevent assignment to a particular variable you would use const (or  
whatever we decide the keyword is):

const B b;
B c;

b=c; //error (one would expect)


The only point of opAssign (that I can see) for structs would be to  
facilitate assignment of other types, eg.

struct A {
   char[] value;
   int opAssign(int rhs) {
     value = std.string.toString(rhs);
   }
}

A a;
a = 5;

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

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

I think we need both. The reason we need both:

const char[] foo = "regan was here";
mutilate(foo);  //no error, foo is const, mutilate takes an 'in' (so "will  
not" modify foo).
void mutilate(in char[] victum) {
	victum[0] = 'a';  //error: 'in' parameter not mutable
}

'in' is a contract saying "I will only read this parameter". That contract  
needs to be enforced.

 Let's say D will alow us to use keyword const as part of the type name:
 so I can create:

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

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

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

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

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

As a string class is not required in D (still under debate), lets remove  
it from the example (we'll come back to it later):

struct Url
{
	private char[] urlSource;
	char[] domain()   { return urlSource[a..b]; }
	char[] protocol() { return urlSource[c..d]; }
}

The basic problem is being able to create/return/pass a reference to  
immutable data. In this case returning a slice of mutable data as  
immutable data.

Ideally the addition of 'const' or 'readonly' or whatever we decide is a  
good keyword would be all that is required, eg.

struct Url
{
	private char[] urlSource;
	const char[] domain()   { return urlSource[a..b]; }
	const char[] protocol() { return urlSource[c..d]; }
}

The rules being:

1. immutable(const) data cannot ever be mutable.
2. mutable data is implicitly immutable data when passed as such.

I think to achieve this all the char[] needs is a readonly flag, which  
once set to true cannot become false again.

This can either be implemented at compile time (compiler uses flag to  
check for errors), or runtime (runtime checks against flag stored in  
char[] struct), or both.

This ties in with the 'in' parameter checking, the same flag is used for  
compile time checking. At runtime it could be done without a flag using an  
implicit 'out' DBC check against the original (that might not catch a  
change and change back case however).


Of course the next problem is how to handle immutability on custom types  
(we're back to the string class or other similar types).

Using 2 example custom types:

struct Bob {}
class Fred {}

we need to be able to indicate they are immutable, ideally in exactly the  
same way as char[] above, eg.

Fred p;
static this() { p = new Fred(); }
const Fred fooBar() { return p; }

this required that the compiler store the same readonly flag within the  
class and perform compile/runtime checks on it. The same goes for the  
struct Bob.

 , struct
 ctor/dtor.

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

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

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

 But compiler can handle now 'auto' for stack class variables.

structs are not classes however, they have no vtable, I believe that is an  
important part of the problem.

 I don't think that it will be more difficult to implement calling of  
 struct dtors in the same manner.
 The only complex thing is struct static initialization/destruction.
 Also intitialization of array of structs could be an implementation  
 problem.

We'll have to get Walters official word on this again (or find it in the  
archives).

 On the other hand a ctor is possible, and I think it'd be useful.

 and remove 'auto' as too controversial.

 What's controversial about it?

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

And the controversy is? i.e. what 2 or more answers do people fail to  
agree on?

I believe this should be an error, after all it's illegal to assign  
something to an auto variable, which is essentially what you're doing.  
Breaking the statement into parts we see:

"new A()" construct an A using this()
"a =" assign rhs to reference a;

 Serious development teams where 'const' is a matter of culture and
 tool for collaborative work will definitely stay with C++.

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

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

Yep. D already has plenty of these, see my list below.

 'const' is the one.

I agree it's important, but, for me D the whole package was 'the one' eg.

- array slicing
- GC
- low level systems languge
- great syntax

I dont really make full use of unittesting, dbc, etc but these are also  
important to the overall package.

 Non-deterministic GC (the same as in D, btw) is available for C/C++ so
 it is not a big motivation.

By itself, no, but added to all the other (sometimes little) things.. it's  
the overall package that matters.

IMO D's overall package is great, and getting better by the day. Sure,  
there are a number of things I want changed, there are a number you want  
changed, that's normal, name me a programming language that is perfect,  
you can't or you wouldn't be here. :)

 What else? The only thing is 1) better syntax
 and 2) set of ready to use builtin types. The latter is definitely not  
 full without 'const'.

Perhaps, they're still 'ready to use' they're just missing certain  
protection attributes like readonly.

 The first is not full without opAssign and ctors/dtors.

The syntax is better (than other languages) with or without this feature.

 In any case phobos shall include string class/object/whatever allowing
 to use it as std::string or java.lang.String.

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

 For your personally and for small projects probably not.

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

 But consider development of components/libraries of a big scale.

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

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

 will throw an error.

This is solved by the 'const' ideas I have explained above.

 Simple assignment of one character is making the whole system fragile.

Until we get 'const' as I have described above.

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

And will be impossible in D when we get 'const'

 Again, D char[] is a character array and not a string (value).

Technically yes, practically it makes no difference (once we have const).

 Yes you can always .dup your 'strings'.
 The question: is this a real solution?

It's part of the solution. For high-performance mutable strings it's what  
you do, for high-performance immutable strings you use 'const' (when  
Walter adds it as I have described).

Baiscally, I'm saying, we dont need a string class, we need const. I agree  
there is a problem. I just prefer my solution to yours, both probably  
solve the problem, mine seems neater (IMO) and more D like (IMO).

 I reckon the only problem at present is that library developers will
 choose different UTF types and we'll need to transcode string data  
 to/from
 all our library calls. The only solution I can think of is to compile  
 all
 libraries 6 times, a debug and release for each char type. This allows  
 the
 application programmer to decide on the string type to use internally  
 and
 link the correct libraries. Note, I'm only talking about selecting the
 'internal' char type, not the char type of the various data sources your
 application might read/write.


The above is still an issue. I've not heard a better soln than mine above,  
anyone?

Regan

Jun 22 2005

Derek Parnell <derek psych.ward> writes:

On Thu, 23 Jun 2005 10:15:40 +1200, Regan Heath wrote:

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

One thing that is still a bit of a problem is having a 'string' type that
is encoding agnostic. It would be very handy to be able to this sort of
thing...

  string a;
  char[] b;
  wchar[] c;
  dchar[] d;

  a = b ~ c ~ d;

Currently we need to explicitly invoke the UTF conversion functions to do
this sort of thing.

-- 
Derek Parnell
Melbourne, Australia
23/06/2005 8:27:02 AM

Jun 22 2005

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


most common input/output data. Most applications wouldn't need to  
transcode input or output, i.e. they can use ASCII right thru.

Of course, we could still make transcoding implicit. But IMO only once we  
remove the bulk of the potential pitfalls resulting in masses of internal  
transcoding between libraries etc.

Regan

Jun 22 2005

Sean Kelly <sean f4.ca> writes:

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

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

 One thing that is still a bit of a problem is having a 'string' type that
 is encoding agnostic. It would be very handy to be able to this sort of
 thing...

   string a;
   char[] b;
   wchar[] c;
   dchar[] d;

   a = b ~ c ~ d;

 Currently we need to explicitly invoke the UTF conversion functions to do
 this sort of thing.

True, it is a pain.

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

Personally, I'd be happy with explicit transcoding using the cast operator:

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

Does this already work, or is it just with foreach?  I keep forgetting to test
it.

Sean

Jun 22 2005

Derek Parnell <derek psych.ward> writes:

On Thu, 23 Jun 2005 01:44:04 +0000 (UTC), Sean Kelly wrote:

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

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

 One thing that is still a bit of a problem is having a 'string' type that
 is encoding agnostic. It would be very handy to be able to this sort of
 thing...

   string a;
   char[] b;
   wchar[] c;
   dchar[] d;

   a = b ~ c ~ d;

 Currently we need to explicitly invoke the UTF conversion functions to do
 this sort of thing.

True, it is a pain.

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

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

The "cast(char[])" never does run-time UTF conversion. It does do
compile-time UTF conversion for string literals.

The 'foreach' does allow character-by-character UTF conversion but it does
need a cast to do that.

  char[] a;
  foreach(dchar x; a) 


-- 
Derek
Melbourne, Australia
23/06/2005 12:40:08 PM

Jun 22 2005

"Regan Heath" <regan netwin.co.nz> writes:

On Thu, 23 Jun 2005 01:44:04 +0000 (UTC), Sean Kelly <sean f4.ca> wrote:
 Personally, I'd be happy with explicit transcoding using the cast  
 operator:

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

Good point. I forgot about that idea.

 Does this already work, or is it just with foreach?  I keep forgetting  
 to test
 it.

Just with foreach, as Derek posted.

Regan

Jun 22 2005

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.



Pros:

+ It really does feel like "Java done right". Mostly minor tweaks, but they add

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


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



to native code if you really want to.

cheers,
Mike

Jun 22 2005

"Regan Heath" <regan netwin.co.nz> writes:

On Wed, 22 Jun 2005 13:18:00 +0000 (UTC), Mike Capp <mike.capp gmail.com>  
wrote:
 + Much tighter control over memory usage than GC. (Smaller working set,  
 much
 less risk of unacceptable pauses.) A bit tedious when you don't need it,  
 but
 irreplaceable when you do, and manageable given RAII. This point alone  
 creates a
 sizeable niche in which D will _never_ supplant C/C++.

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

Regan

Jun 22 2005

Mike Capp <mike.capp gmail.com> writes:

In article <opsssligap23k2f5 nrage.netwin.co.nz>, Regan Heath says...
 + Much tighter control over memory usage than GC. (Smaller working set,  
 much
 less risk of unacceptable pauses.) A bit tedious when you don't need it,  
 but
 irreplaceable when you do, and manageable given RAII. This point alone  
 creates a
 sizeable niche in which D will _never_ supplant C/C++.

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

Except that, to return to an earlier gripe, the rules for 'auto' don't allow
automatic refcounted smart pointers along the lines of boost::shared_ptr. Such
pointers are pretty much required for robust non-GC memory management. Also, I
gather that Phobos assumes GC and will leak like a sieve without it. 

It's not so much "D can do this" as "you can do this if you're prepared to fight
the language every step of the way". You can do (real) GC in C++ by plugging in
something like the Boehm collector. Not many people do. You certainly don't see
ticks for C++ in the "GC" column in language comparison charts.

cheers
Mike

Jun 23 2005

"Regan Heath" <regan netwin.co.nz> writes:

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

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

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

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

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

Being a C programmer for a living I can honestly say I haven't had a  
memory management issue for.. well ages. I think memory management is a  
skill, one I have learnt thru years of being bitten by it. In addition C  
is probably much simpler than C++ when it comes to memory management.

 Also, I
 gather that Phobos assumes GC and will leak like a sieve without it.

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

 It's not so much "D can do this" as "you can do this if you're prepared  
 to fight the language every step of the way".

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

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

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

In fairness that would be because it's a 'language' comparison, not a  
language + libraries comparison, right?

Regan

Jun 23 2005

Mike Capp <mike.capp gmail.com> writes:

In article <opsstiikkp23k2f5 nrage.netwin.co.nz>, Regan Heath says...

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

It depends very much on the kind of data structures needed for your app domain.
In some domains you can write useful C/C++ apps without ever touching
malloc/new. In others you really need refcounting, and manual refcounting is
just nasty. In still others you have to cope with potential cycles, and GC is
pretty much the only way to go.

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

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

"Ugh, header files in C are a pain." 

"But you can do header-less programming in C! As long as you don't mind putting
all your code in one file and doing without any libraries, or copying all your
prototypes etc into each source file."

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

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

No, I just meant "real" GC as opposed to refcounting.

cheers
Mike

Jun 23 2005

"Regan Heath" <regan netwin.co.nz> writes:

On Thu, 23 Jun 2005 12:59:47 +0000 (UTC), Mike Capp <mike.capp gmail.com>  
wrote:
 In article <opsstiikkp23k2f5 nrage.netwin.co.nz>, Regan Heath says...

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

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

I use malloc/strdup all the time.

 In others you really need refcounting, and manual refcounting is just  
 nasty.

I think it depends on the coding style you use. I've never 'needed'  
refcounting. At one stage I thought it was cool and tried using it, that  
stage didn't last.

 In still others you have to cope with potential cycles, and GC is pretty  
 much the only way to go.

Cycles? example pls.

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

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

I disagree. The 'language' supports it just fine. The 'library' doesn't.  
Compare that with Java, as I understand it (and that might be not at all)  
you cannot avoid the GC at all.

Regan

Jun 23 2005

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsstqq2vz23k2f5 nrage.netwin.co.nz...
 Cycles? example pls.

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

Jun 23 2005

"Regan Heath" <regan netwin.co.nz> writes:

On Thu, 23 Jun 2005 11:45:29 -0400, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsstqq2vz23k2f5 nrage.netwin.co.nz...
 Cycles? example pls.

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

Coo, I suspected that's what was meant :)

Like a doubly linked list perhaps? One where you have nulled your pointer  
to it's root item? This wouldn't happen to me, as I'd be 'free' ing the  
root, causing a free of the next item, etc.

Or perhaps a circular list (I've never had cause to used one). Even there  
you'd have a pointer to some starting point, or current point or  
something. When freeing such a list I'd imagine you need it to be double  
linked so as you can null the previous items 'next' pointer (in other  
words turning it into a normal list) before recursively freeing the items.

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

Regan

Jun 23 2005

Brad Beveridge <brad somewhere.net> writes:

Regan Heath wrote:

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

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

Brad

Jun 23 2005

"Regan Heath" <regan netwin.co.nz> writes:

On Thu, 23 Jun 2005 17:06:11 -0700, Brad Beveridge <brad somewhere.net>  
wrote:
 Regan Heath wrote:

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

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

Ahh.. thanks, good description.

Regan

Jun 23 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opssujy2j723k2f5 nrage.netwin.co.nz...
 On Thu, 23 Jun 2005 11:45:29 -0400, Jarrett Billingsley 
 <kb3ctd2 yahoo.com> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsstqq2vz23k2f5 nrage.netwin.co.nz...
 Cycles? example pls.

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

 Coo, I suspected that's what was meant :)

 Like a doubly linked list perhaps? One where you have nulled your pointer 
 to it's root item? This wouldn't happen to me, as I'd be 'free' ing the 
 root, causing a free of the next item, etc.

 Or perhaps a circular list (I've never had cause to used one). Even there 
 you'd have a pointer to some starting point, or current point or 
 something. When freeing such a list I'd imagine you need it to be double 
 linked so as you can null the previous items 'next' pointer (in other 
 words turning it into a normal list) before recursively freeing the items.

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

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

What does mark-n-sweep GC (it is used in D):

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

As you may see it solves problem of cyclic references.

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

Resume: if you you know that something can be deleted you'd better
delete it *now* :)

All this talks: opAssign, ctors/dtors, 'const' are about this and
not about beautification of syntax (this is also matters as Lada
example shows but you'd better install first best engine available -
it is better that this engine use hybrid technologies, right?).

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

Andrew.

Jun 23 2005

"Regan Heath" <regan netwin.co.nz> writes:

On Thu, 23 Jun 2005 17:17:50 -0700, Andrew Fedoniouk  
<news terrainformatica.com> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opssujy2j723k2f5 nrage.netwin.co.nz...
 On Thu, 23 Jun 2005 11:45:29 -0400, Jarrett Billingsley
 <kb3ctd2 yahoo.com> wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsstqq2vz23k2f5 nrage.netwin.co.nz...
 Cycles? example pls.

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

 Coo, I suspected that's what was meant :)

 Like a doubly linked list perhaps? One where you have nulled your  
 pointer
 to it's root item? This wouldn't happen to me, as I'd be 'free' ing the
 root, causing a free of the next item, etc.

 Or perhaps a circular list (I've never had cause to used one). Even  
 there
 you'd have a pointer to some starting point, or current point or
 something. When freeing such a list I'd imagine you need it to be double
 linked so as you can null the previous items 'next' pointer (in other
 words turning it into a normal list) before recursively freeing the  
 items.

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

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

Yep, I see.

 What does mark-n-sweep GC (it is used in D):

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

 As you may see it solves problem of cyclic references.

Yep.

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

Sure. But for 'how long', and is that length of time 'too long' or not. I  
can see how in a 'realtime' application this might be a *big* problem, but  
in a typical application as long as the pause is very brief it should be  
fine, right?

In applications with a realtime portion i.e. a game rendering to the  
screen there are techniques for avoiding pauses when it really matters,  
they generally involve pre-allocating and not allocating due the rendering  
phase. I believe a game written *without* a GC would use the same  
techniques in order to keep the frame rate as fast as possible. I'm no  
expert though.

A friend of mine, much older than I, who once used a GC for some anchient  
language (I cannot remember the name of) mentioned to me, a few weeks  
back, about how an application he wrote was 'going away' for a few  
minutes. That sort of pause is unacceptable in just about every  
application type. That said, GC implmentation (and the hardware they  
operate on) has improved vastly.

 Resume: if you you know that something can be deleted you'd better
 delete it *now* :)

This is sensible advice in any case.

 All this talks: opAssign, ctors/dtors, 'const' are about this and
 not about beautification of syntax

I never once thought it was :)

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

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

I don't buy them either. To me it smacks of inefficiency and doing  
something "just in case". While I agree/think Copy-On-Write is a good  
method (it is efficient) I also think we do need some method to enforce  
readonly.

The best soln I've seen IMO is the compile/runtime flags for verifying  
readonly data is not modified.

In short, I agree there is a problem. I have a favourite solution and it's  
not 'exactly' what you're saying we should do ;)

Regan

Jun 23 2005

"Walter" <newshound digitalmars.com> writes:

"Regan Heath" <regan netwin.co.nz> wrote in message
news:opssum481c23k2f5 nrage.netwin.co.nz...
 But! As you may also see it stops your process for some amount of
 time. Obviously as much stuff you have allocated (which was not
 explicetely deleted) as longer GC pause - your app is non-responsive.

 Sure. But for 'how long', and is that length of time 'too long' or not. I
 can see how in a 'realtime' application this might be a *big* problem, but
 in a typical application as long as the pause is very brief it should be
 fine, right?

 In applications with a realtime portion i.e. a game rendering to the
 screen there are techniques for avoiding pauses when it really matters,
 they generally involve pre-allocating and not allocating due the rendering
 phase. I believe a game written *without* a GC would use the same
 techniques in order to keep the frame rate as fast as possible. I'm no
 expert though.

Actually, any call to 'new' in C++ has no guarantee that it will return
within a bounded amount of time. Applications where real time latency must
be bounded will tend to be written to preallocate all the data and will
never use 'new' in the time critical sections.

Jun 25 2005

Sean Kelly <sean f4.ca> writes:

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

I haven't much looked into them, but I imagine specialized memory managers like
Hoard provide some basic guarantees on allocation time.  Though by the same
token, specialized garbage collectors could be implemented in D to serve the
same purpose.


Sean

Jun 25 2005

Sean Kelly <sean f4.ca> writes:

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

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

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

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

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

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

Being a C programmer for a living I can honestly say I haven't had a  
memory management issue for.. well ages. I think memory management is a  
skill, one I have learnt thru years of being bitten by it. In addition C  
is probably much simpler than C++ when it comes to memory management.

 Also, I
 gather that Phobos assumes GC and will leak like a sieve without it.

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

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


Sean

Jun 23 2005

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.
 
 

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

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

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

Brad

Jun 23 2005

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

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

You've forgot to mention: delete.
If you know that allocated block is not used anymore - delete it.
D is using ordinary heap. And GC is running on this heap.
As less 'garbage' you have allocated as less GC cycle would be.
Using 'delete' at least is not slower than in C++.

Ref-counting is a method of deterministic GC. Combined
with current D non-deterministic GC can create unbeatable pair.

Ref-counting is a *choice* of developer to create better and optimal
system.  D just does not provide such choice.

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

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

But to think first is always a good thing right?

Coputational complexity of auto_ptr (new/delete) is
O(1) and letting GC do all your deletion is O(2*n).

Please don't forget that this topic is not about only GC and heap 
allocations.
It is also about stack allocations and *this* is more than 100 times faster 
than any
heap and GC.

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

class Graphics { HDC hdc; }

I am *forced* to allocate it on heap:

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

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

Jun 23 2005

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.

I was going to ask why Graphics isn't a singleton - but really the 
example doesn't matter, it doesn't change the fact you can't easily 
allocate classes on the stack.
I guess our best bet is to gripe about things in the NG and post feature 
requests here http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList

Brad

Jun 23 2005

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

 I was going to ask why Graphics isn't a singleton - but really the

"why Graphics isn't a singleton".
It is RAII thing. Needs to bee freed as soon as posible and order
of creation deletion matters. And each window, image, etc. has its own type 
of Graphics.
Speaking about RAII: there are many things which I am doing
in C++  using auto objects (pen, brush, font - OS handles)
In D I was forced to do deallocation explicitly - and this does not simplify
my life. Thrown errors may create resource leaks so I was forced
to redesign hevily what I have in C++ to avoid this.

 example doesn't matter, it doesn't change the fact you can't easily 
 allocate classes on the stack.
 I guess our best bet is to gripe about things in the NG and post feature 
 requests here http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList

Most of features added recently are not in this list. So what is the point 
maintaining it?

------------
This is from D documentation:
"To have a class allocated on the stack that has a destructor, this is the 
same as a declaration with the auto attribute. Although the current 
implementation does not put such objects on the stack, future ones can." 
Read last statement. It is already planned as far as I can see.

I think it is more convenient to implement ctors/dtors in structs though as 
this will cover other
use cases also.

Andrew.

Jun 23 2005

"Unknown W. Brackets" <unknown simplemachines.org> writes:

You can allocate classes on the stack, as the documentation describes, 
it's just not recommended afaik.

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

Anyway, if this is all it really is:

class Graphics { HDC hdc; }

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

-[Unknown]


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


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

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

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

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

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

Jun 23 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

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

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

 Anyway, if this is all it really is:

 class Graphics { HDC hdc; }

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

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

Sorry, but it does not call destructors.
Good common library design *must* assume that
exception can be thrown in user supplied drawing
implementations.

class Graphics {
    HDC hdc;
    this() { hdc = GetDC(....); .... }
    ~this() { ...; ReleaseDC(hdc); }
}

And library as good OS citizen *must* free OS resources allocated.

This is all about RAII.

 -[Unknown]


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

Sean Kelly wrote:


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

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


 You've forgot to mention: delete.
 If you know that allocated block is not used anymore - delete it.
 D is using ordinary heap. And GC is running on this heap.
 As less 'garbage' you have allocated as less GC cycle would be.
 Using 'delete' at least is not slower than in C++.

 Ref-counting is a method of deterministic GC. Combined
 with current D non-deterministic GC can create unbeatable pair.

 Ref-counting is a *choice* of developer to create better and optimal
 system.  D just does not provide such choice.


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

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


 But to think first is always a good thing right?

 Coputational complexity of auto_ptr (new/delete) is
 O(1) and letting GC do all your deletion is O(2*n).

 Please don't forget that this topic is not about only GC and heap 
 allocations.
 It is also about stack allocations and *this* is more than 100 times 
 faster than any
 heap and GC.

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

 class Graphics { HDC hdc; }

 I am *forced* to allocate it on heap:

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

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

Jun 23 2005

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.

I think that the only solution to this is to wait :)
Walter can obviously see that auto classes should be put on the stack, I 
guess he just hasnt gotten to the optimisation phase of DMD's 
development yet.  I would expect optimisation to begin post v1.0 myself.

Brad

Jun 23 2005

"Walter" <newshound digitalmars.com> writes:

"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d9enev$2n2e$1 digitaldaemon.com...
 Real example: in Harmonia I have class named Graphics. It is clearly
 temporary wrapper
 around HDC (on windows)

 class Graphics { HDC hdc; }

 I am *forced* to allocate it on heap:

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

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

The interesting thing about auto that I realized after it was implemented is
that auto declarations behave as if they were put on the stack, so they can
be put on the stack. In the future, the D compiler will do this optimization
for you, you won't have to change your code at all.

Jun 25 2005

Mike Capp <mike.capp gmail.com> writes:

In article <d9ek1q$2in8$1 digitaldaemon.com>, Brad Beveridge says...

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

Yup. This is all I was saying in my original post. There exists a sizeable
subset of C++ programmers for whom D is not a viable alternative, whether they
want to switch or not.

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

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

cheers
Mike

Jun 23 2005

"Andrew Fedoniouk" <news terrainformatica.com> writes:

"Mike Capp" <mike.capp gmail.com> wrote in message 
news:d9eri2$2rg0$1 digitaldaemon.com...
 In article <d9ek1q$2in8$1 digitaldaemon.com>, Brad Beveridge says...

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

 Yup. This is all I was saying in my original post. There exists a sizeable
 subset of C++ programmers for whom D is not a viable alternative, whether 
 they
 want to switch or not.

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

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

Agreed. I though that GC euphoria already gone but....
GC is just one more way of managing memory. With pluses and minuses.

Good new language shall provide developers at least choice what to use:
in some places stack type of memory management is better, in other heap
and of course GC. The best results can be achieved in combination of these.

http://www.geocities.com/carsten_frigaard/the_toll_of_garbage_collection.pdf

Andrew.

Jun 23 2005

"Unknown W. Brackets" <unknown simplemachines.org> writes:

Not exactly.  The library *is* what handles dynamic arrays.  You simply 
change that if you don't want it garbage collected.

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

-[Unknown]


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

Jun 23 2005

Sean Kelly <sean f4.ca> writes:

In article <d9esdf$2sdf$2 digitaldaemon.com>, Unknown W. Brackets says...
Not exactly.  The library *is* what handles dynamic arrays.  You simply 
change that if you don't want it garbage collected.

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

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


Sean

Jun 23 2005

"Unknown W. Brackets" <unknown simplemachines.org> writes:

Forgive me, but that just sounds like arguing:

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

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

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

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

-[Unknown]


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

Jun 23 2005

"Regan Heath" <regan netwin.co.nz> writes:

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

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

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

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

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

After reading this thread and also this one Andrew dug up:
   http://www.digitalmars.com/d/archives/7988.html

It appears you need a type that:

1 - is stack based.
2 - has deterministic destruction.
3 - has opAssign.

It seems (from recent posts) that Walter plans to put auto classes on the  
stack, so they'd then fulfil requirements 1 and 2.

But what about 3? To me, opAssign isn't generally a good idea for classes  
(assigning a value to a reference seems illogical) but would be a good for  
structs (they're value types, assignment assigns a value).

Can you do reference counting without opAssign?

The idea for D (or so I've read) is that opAssign isn't required, instead  
you use a copy constructor. Now, I've little experience with ref counting,  
or with writing an implementation of one, but, does this work?

import std.c.windows.windows;
import std.random;
import std.thread;
import std.stdio;

class RefPtr
{
	RefPtr parent;
	Object resource = null;
	int refs = 0;

	this(Object res)
	{
		resource = res;
		writefln("ThreadID=(",Thread.getThis().id,") Initial RefPtr for  
resource=(",resource,")");
		increment();		
	}

	this(RefPtr rhs)
	{
		parent = rhs;
		parent.increment();
		writefln("ThreadID=(",Thread.getThis().id,") Ref=(",parent.refs,") for  
resource=(",parent.resource,")");
	}
	
	~this()
	{
		int r;
		
		if ((r = decrement()) == 0)
		{
			writefln("ThreadID=(",Thread.getThis().id,") release last ref  
Ref=(",r,")");
			if (parent) parent = null;
			else if (resource)
			{
				writefln("ThreadID=(",Thread.getThis().id,") delete  
resource=(",resource,")");
				delete resource;
				resource = null;
			}
		}
		writefln("ThreadID=(",Thread.getThis().id,") release Ref=(",r,")");
	}
protected:
	int increment()
	{
		int ret;
		
		if (parent) ret = parent.increment();
		else {
			synchronized(this)
			{
				ret = ++refs;
				writefln("ThreadID=(",Thread.getThis().id,") increment to  
Ref=(",refs,")");
			}
		}
		
		return ret;
	}
	int decrement()
	{
		int ret;
		
		if (parent) ret = parent.decrement();
		else {
			synchronized(this)
			{
				ret = --refs;
				writefln("ThreadID=(",Thread.getThis().id,") decrement to  
Ref=(",refs,")");
			}
		}
		
		return ret;
	}
}

class Resource
{
	char[] name = "11 was a racehorse";
	char[] toString() { return name; }
}

RefPtr pbob;

static this()
{
	pbob = new RefPtr(new Resource());
}

static ~this()
{
	delete pbob;
}

void main()
{
	Thread t;
	int i;
	
	writefln("ThreadID=(",Thread.getThis().id,") is the main thread");
	
	for(i = 0; i < 10; i++)
	{
		t = new Thread(&thread_function,null);
		t.start();
	}
	
	/* How do I wait for all threads? This code cause access violation.
	while(true)
	{
		i = 0;
		foreach(Thread t; Thread.getAll())
		{
			if (t.getState() == Thread.TS.TERMINATED) i++;
		}
		if (i == 10) break;
		Sleep(100);
	}*/
	
	Sleep(5000);
	
	writefln("Main exiting");
}

int thread_function(void* isnull)
{
	auto RefPtr p = new RefPtr(pbob);
	Sleep(1000+rand()%1000);	
	return 0;
}

Regan

Jun 23 2005

"Unknown W. Brackets" <unknown simplemachines.org> writes:

AFAIK, some of the threads in getAll() could be null.  You might want 
something like:

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

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

     Thread[] t;
     int i;

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

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

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

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

         Sleep(100);
     }

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

-[Unknown]


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

Jun 23 2005

"Regan Heath" <regan netwin.co.nz> writes:

On Thu, 23 Jun 2005 19:38:43 -0700, Unknown W. Brackets  
<unknown simplemachines.org> wrote:
 AFAIK, some of the threads in getAll() could be null.

Yeah, that was it.

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

      Thread[] t;
      int i;

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

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

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

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

          Sleep(100);
      }

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

I considered storing them all, decided I didn't want to (on a whim really).

Regan

Jun 23 2005

"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

pretend D
 were C and use pointers for all your storage needs.

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

Jun 25 2005

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

pretend D
 were C and use pointers for all your storage needs.

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

I imagine using the ~= operator could cause a GC allocation too.  But what I was
getting at is that these are all built-in features of a basic type.  How could I
reasonably use arrays without setting the length property, for example, since D
doesn't use a terminating null to indicate string length?  Instead, I'd likely
create a new struct similar to the one already used for arrays and slice the
data when I wanted to pass it to a (non-modifying) D function.  I personally
have no problem with this.  I just figured it was worth pointing out that some
basic types in the language rely to some degree on the existence of a GC.


Sean

Jun 25 2005

"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

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.

You can allocate a dynamic array without using the gc via:

    char* p = cast(char*) malloc(length);
    char[] a = p[0 .. length];

It's not as convenient as using new, but it does work. I do understand your
point, I just wanted to emphasize that one can effectively use dynamic
arrays without ever needing the gc.

Jun 25 2005

"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



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.

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

it.

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

fight
 the language every step of the way".

I see it the other way around. A *large* part of the time I'd spend writing
C++ code was dealing with memory management issues for just about
everything. It sure felt that I was fighting it every step of the way. With
D, automatic memory management takes care of the vast bulk of routine
chores, and the bit that's left over can be handled explicitly without much
pain.

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

I've done it.

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

That's because it isn't part of the standard language, and using it
successfully with C++ requires one to be rather thorough in understanding
how it works and what its limitations are. Major C++ vendors have neglected
it. Digital Mars C++ is the only one I know of to support it in the official
distribution.

Jun 24 2005

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

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


But D does support both RAII and explicit memory allocation.

Additionally, the pause issue is easilly dealt with when it matters.

Jun 24 2005

D Programming

C/C++ Programming

Other

digitalmars.D - What language role does D fullfill?