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

"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

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

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

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

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

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

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

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

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


Sean

"Sean Kelly" <sean@f4.ca> 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.