OSNews

If you are interested in a substantial reengineering of C++, in something that actually fixes its major shortcomings, try the D programming language.

I second that. D is a very nice language with a clear focus. My first impression was that it has the best of Java, the best of C++ and none of they're major weaknesses.

I second that. D is a very nice language with a clear focus. My first impression was that it has the best of Java, the best of C++ and none of they're major weaknesses.

Adds one major weekness - its memory model is based on conservative GC, which makes it unpredictable and in reality unusable for some important applications (like cryptography or any other software that deals with noise-like data).

its memory model is based on conservative GC, which makes it unpredictable and in reality unusable for some important applications

Not really, automatic memory management is not mandatory in D. You can handle memory manually just like in C++. So if C++'s memory model serves your purposes well so does D's.

Not really, automatic memory management is not mandatory in D. You can handle memory manually just like in C++. So if C++'s memory model serves your purposes well so does D's.

Well, in theory yes. In practice, all D libraries will use GC, so not using conservative GC means you are excluded from any library use.

My first impression was that it has the best of Java, the best of C++ and none of they're major weaknesses.

Well, except for the fact that D includes unnecessary stuff in the core language instead of delegating it to a library. Where is the need to bloat the core language with stuff which is perfectly well achieved with the basic constructs?

If you are interested in a substantial reengineering of C++, in something that actually fixes its major shortcomings, try the D programming language.

http://www.digitalmars.com/d/comparison.html

That comparison chart is at least dubious, not to mention dishonest. The chart's author opted to ignore simple facts about the C++ language, claiming that it doesn't have certain elements (garbage collection, resizeable arrays, built-in strings, etc..) that it certainly has. If the D programming language is that great why do the people behind it try to spread incorrect information and ignoring simple C++ facts about basic stuff just to add a couple of plus signs in the comparison? Moreover, how come that comparison chart is still up even after the author himself, while trying to spam C++ newsgroups about his new wonderful language, was shown time and again that he incorporated false information about C++?

Last time I checked, C++ did NOT have a Garbage Collector.

C++09 will have GC.

Do you have a link to the proposal for that? Don't remember to have seen this.

There are quite a few C++ Garbage Collector libraries which anyone can choose, which is the right way of doing things. After all it enables those who really want GC in their C++ projects to use it and those who don't to not use it. At least to me that is the right way of doing thins, instead of mandating what you can and cannot do.

Claiming that there aren't GC in C++ is similar to the claim that C++ doesn't have resizeable vectors or even strings. It is a claim which is only made by those who are ignorant of C++ or wish to ignore the facts to be able to make some other product look better than it is. Where is the need to lie about such trivial things? Isn't D capable of standing up on it's own without having to resort to misleading jabs and dishonest alegations?

Quote -> "Claiming that there aren't GC in C++ is similar to the claim that C++ doesn't have resizeable vectors or even strings. It is a claim which is only made by those who are ignorant of C++ or wish to ignore the facts to be able to make some other product look better than it is. Where is the need to lie about such trivial things? Isn't D capable of standing up on it's own without having to resort to misleading jabs and dishonest alegations?"

If you read the http://www.digitalmars.com/d/comparison.html page, you'll realize we are talking about /core/ language features, not features implemented as library add-ons.

Quote from the comparison page...
"
The Hans-Boehm garbage collector can be successfully used with C and C++, but it is not a standard part of the language.
"

Another quote from the comparison page...
"
Part of the standard library for C++ implements resizeable arrays, however, they are not part of the core language. A conforming freestanding implementation of C++ (C++98 17.4.1.3) does not need to provide these libraries.
"

In addition, there is a lot to be gained by implementing these features in the /core/ language rather than as a library add-on. For reason's on this, I point you to this page http://www.digitalmars.com/d/cppstrings.html

Not having a standard GC forced on me is an advantage as far as I'm concerned.

As for the second part, it seems irrelevant. Whether or not the standard specifies that a comformant C++ implementation should include std::vector, all C++ compilers include it.

Why do the D people have to try so hard to argue against C++ that they have to resort to dissecting obscure details of the spec to try to get their point across?
Please argue purely on technical merit. If your language is really that good, it should be enough.

Here are some facts for you D apologists:

- Standard containers are part of all relevant C++ compilers.

- The standard library ships with all relevant C++ compilers.

- Exception handling in C++ doesn't involve setting up special stack frames (at least on good compilers, which exclude visual c++)

It is used as part of an argument as to why D, using GC, is faster than C++ - which is, as always when it come to discussing the GC issue, not supported by any kind of benchmark anyway.

Oh, and the builtin string in D help concatenating strings. Nice.
This bit of syntactic sugar doesn't justify switching to a different language.

While this could be improved in C++, this is not an issue one runs often into, and if it does you can live with constructing a temp string object.

1) D doesn't force you to use the GC. If you are a competent enough programmer, you can disable the GC and use the C runtime malloc/free to do your memory management with. Walter Bright (language author) wrote his entire Empire game in D without a garbage collector.

2) It is not dishonest to say that C++ does not have a re-sizable array implementation built into its core language spec, because it doesn't. It is implemented as a part of the C++ standard library. This is mentioned on the comparison page. It is much nicer to have resizable arrays in the /core/ language rather than as a library add on. If the D language author _was_ trying to be dishonest, he wouldn't create a link on the comparison chart that goes to explain that vectors are implemented as part of the C++ standard library.

3) If you looked at the link, there _is_ a benchmark to support that garbage collection does give you better performance.
http://www.digitalmars.com/d/cppstrings.html
Look at the word count example.

Resistance is futile... you will be assimilated.

~ Clay

The fact that GC performance can beat manual memory management performance is something not enough people realize. The same people who in 2006 bitch about the performance cost of GC have probably never written their own memory allocator. They think malloc() and free() are magic instructions implemented in the CPU. They don't realize that both usually involve the processor traipsing merrily around non-localized list structures looking for blocks and doing coalescing.

2) It is not dishonest to say that C++ does not have a re-sizable array implementation built into its core language spec, because it doesn't.

It's dishonest because it's irrelevant. Whether it's in the language or in the library is an implementation detail.

By the way, with the code in that benchmark, you essentially get the difference of time to cleanup after executing the program.

The D version will actually never run through an actual GC cycle (because nothing is ever discarded in the example during the execution) and just discard the heap, whereas the C++ version will have to delete the map.

Once again, it's a situation chosen carefully to advantage D.

Give me a benchmark for a real world application manipulating a lot of objects, including both creating and discarding them, and whose execution does involve garbage collection cycles to actually be performed.

So in one issue (the GC) the D apologist claimed that he listed C++ as not having because it isn't included in the standards but in another issue (string, vector) he claimed that he listed C++ as not having because, although it is very much part of the standards, it isn't part of the core language.

Don't you find it a bit dishonest that the author of the comparison arbitrarily claims that C++ doesn't have something that it indeed has just because the author feels like it? And what does it say about the D programming language itself if the D authors are only capable of pushing it by lying about C++'s capabilities?

why you all start to glorify your favourite/own language by saying c++ is bad? in fact java and c# and whatever else just copied most features of c++ and added some marketing... if you cannot write good portable code this is not problem of c++...

why you all start to glorify your favourite/own language by saying c++ is bad?

Well, I think this is because C++ is still the most relevant language for its application domain.

I'm not really sure about D.

C++ has the very useful property that you don't pay what you don't use. The language is entirely designed around that idea.
This is why it doesn't, for instance, include a garbage collector.

D obviously isn't designed around that concept, so whenever I use one of the D features, how do I know if it's expensive or not? Anything that has a runtime cost associated with it in C++, like dynamic_cast, virtual functions, exceptions and so on are clearly indicated as such.

Also, in C++ there is a clear rational as to why a feature is present in the language, ie what real-world, common problem it solves.

D seems a random mishmash of "cool" features without clear explanation as to why they have been implemented.
For instance, the static_if thing: in which situation would you want to use this?

Also, why would I want unit testing to be part of the language? What does it achieves? C++ gives you the freedom of choosing whatever implementation of unit test framework you want.

I also find their D/other languages comparison to be a bit disingenuous.
First column: name of feature XXX as found in D. Other columns: No, even though different but god solutions may exist to achieve the same thing in these languages.

Finally, I bothered reading their rationale for including a garbage collector, and in addition to repeating the same argument twice, some of them are also either plain wrong or dubious.

If I were to nitpick, I'd also mention that the poor grammar at some places in their documentation is a bit of a turn-off too. They should at least fix that.

By the way, that article doesn't mention every change in C++09. It omits some other very interesting things like vararg templates, static assertions and automatic type inference in declaration.

It might not look very useful features, but along with concept checking it will make template much more useful. Currently, one of the big problem with templates is not what they can do, it's that doing complicated stuff can very quickly result in nightmarish compilation errors.

iirc currently there are tools that generate class info based on sources - this is not necessarily compiler's task...

Yes, this is the compilers task, at least if you want to do it right. The compiler is the one that's actually parsing the code, building the class hierarchy, etc, so why should you depend on some half-assed external tool to do it?

The Open Dylan compiler (www.opendylan.org) is absolutely phenomenal in this regard. The compiler is structured as a library, which the IDE or CLI links to. The library exposes methods for getting at everything from the parse tree of the sources, to notes from the optimizer.

This is the only sensible way to structure things, especially in a language like C++, for which writing a proper parser is a multi-man-year project.

Edited 2006-11-20 21:40

I very much hope not.

I very much hope not.

Actually, there are many levels of thread support and C++ would need at least the minimal one. At the moment, any multithreaded code has undefined behavior by C++ standard.

We are not speaking here about language constructs to start threads, but very basic stuff like library code for locking, which cannot be (at least in theory) correctly implemented in C++ (because compiler is allowed to perform optimizations that broke many of multi-threaded algorithms).

Aren't threading platform-dependent? Why would a language which aims to be platform-independent adopt platform-dependent features?

Moreover, there are already plenty of threads libraries for C++. As far as I know even boost has a threading library. As I see it, there is no need it in the standard library and even less on the core language.

Aren't threading platform-dependent? Why would a language which aims to be platform-independent adopt platform-dependent features?

Once again, the problem is that many thread safe algorithms depend on specific order of operations performed, which is not guaranteed by C++ standard.

Therefore, according to standard, any multithreaded code in C++ is broken.

Of course, there are existing libraries that work - but they are not _guaranteed_ to continue working when compiled with another C++ compiler or even newer version with better compiler (with e.g. different optimizer).

D libraries do indeed use the GC; D is capable of using any kind of GC that can be "plugged in".

I can be missing something, but from examples given by Walter in either D website or in C++.lang.moderated it is obvious that D can work with conservative GC only (otherwise examples given would be broken).

Memory management in C++ has become a finicky and repetitous task, and likely an expensive one from a business perspective, for programmer's developing software: that's a lot more lines of code, a lot more complexity, and a lot more possibility for bugs and memory leaks!

Yes, but that is just matter of wrong library design. In my C++ world (http://www.ultimatepp.org/www$uppweb$overview$en-us.html) any kind of _resource_ leaks (not only memory) are non-existent. GC would make things only worse.

By the way, if anyone has a look at D, you'll see that the template system is far surpassing C++'s in numerous ways now too.

The problem of templates in C++ is not templates themselves, but STL...

Edited 2006-11-20 09:10

It's easy to write incomprehensible stuff with any language.

Perl? I don't think it needs any example of this.

Python? It can, and willl get horrible in the wrong hands. I had to maintain a 3000+ line python script. And despite the fact that python goes out of its way to discourage you from using global variables (one of the rare things I appreciate in that language), the guy who wrote that script used hundred of them.
Regardless of the language, there are dumbasses out there that WILL manage to write hopelessly awful code with it.

I don't know about ruby, but I don't see how it would be different. And I'm suspicious of languages throwing all their eggs in the OO basket like if it was the single only good programming paradigm in existence.

Edited 2006-11-20 10:46

I myself am very and extremely interesed in D. However, unless the D frontend is included into official GCC, developing and distributing apps mase with it will be a big hassle, since you have to install a special patched version of the compiler to make stuff with it...

Ah, more changes to make C++ even more difficult to implement. It's been 8 years since C++ '98, and today there is still no correct and complete implementation. When the next version of C++ comes out in 2009, it will be 2015 before you can expect high-quality implementations.

And the whole concept of the template mechanism as an embedded functional language is really getting out of hand. First they made it Turing-complete, now it has a type system? What's next, object orientation? It is, for all intents and purposes, a glorified macro system, so why not just bite the bullet and let you use regular C++ code to do code generation? IMHO, the metafunction proposal was a much better, saner, and more usable thing to add into C++ than extending the pointy-bracket sub-language from hell.

You could not have said it in a better way. I couldn't agree more!

And with all these changes, C++ will not have garbage collection!

And the fact that they are introducing yet another reference type makes C++ even more difficult to use...

Although I realize that C++ is actually a very small, simple language at its core, it somehow ends up being overcomplicated and bloated in actual usage. While C++09 is nice, I don't see the added features reducing that tendency too much.

Your code can only start to get bloated and overcomplicated if you intentionally wish that your code becomes bloated and overcomplicated. If you don't want to use features that you consider out of your reach and difficult for you to understand and keep track then don't use it.

And of course that isn't exclusive to C++. It holds true to any other language and it is proportional to your experience and knowledge of it.

Tolerable memory management in C++ is possible, but the problem is that everybody does it differently!

And tell me, if there isn't a consensus to what is the best GC or more appropriate method out there, isn't it better to let the user choose whatever GC is best suited for the task at hand instead of imposing the same generalized component that may not suit anyone's needs? If everyone does things differently then the best thing that anyone can do isn't avoiding the imposition of the one and only solution?

People don't all do different things in C++ because its necessary for the task at hand, they do so because they have no other choice. Hundreds of different ad-hoc memory management schemes don't exist because they're really necessary (most are variations on a few basic schemes), but because lack of standardization means that there is no mechanism for picking common methods.

For almost every task for which "modern C++" is useful, a GC is the right memory management scheme to use. The hit of a GC is a lot less than the hit of smart pointers or the large amount of copying involved in STL collections, for example. Entertainingly, these fancy "move semantics" are largely necessary to make up for the over-use of copying semantics in the STL, which are necessitated by C++'s lack of GC.

There are problem domains for which GC is not appropriate, though they are getting smaller as collectors become more advanced. In any case, the majority of those problem domains aren't appropriate for C++ anyway, at least not in its modern incarnations. If you're on an embedded platform, for example, and can't tolerate the extra memory usage of a GC, you're not going to do very well with the massive memory increase imposed by template code either. If you're doing hard-real time computation, you can't use things like smart pointers, because they're very non-deterministic as well with common data structures (lists, graphs).

For almost every task for which "modern C++" is useful, a GC is the right memory management scheme to use. The hit of a GC is a lot less than the hit of smart pointers or the large amount of copying involved in STL collections, for example. Entertainingly, these fancy "move semantics" are largely necessary to make up for the over-use of copying semantics in the STL, which are necessitated by C++'s lack of GC.

I disagree (and I have one million lines of codebase to prove this point;).

I agree that STL's copy semantics IS THE PROBLEM, but GC is not the solution. The solution is to simply design container library WITHOUT copy semantics requirement, which is completely possible.

In such design, move semantics is still useful, but plays role similar to "break" statement in structured programming (and you do not need language extension to achieve this).

BTW, the main architectural trouble with GC and C++ is that it is impossible to match GC and destructors. You can have GC or destructors, but never both. I vote for desctructors (GC would not close my files).

As for performance claims, many GC advocates do not realize that often old malloc/free implementation are compared to cutting edge GC's. In the end, famous Boehm's GC, which is used in most opensource projects, has its tiny (and very smart) "malloc/free" in its sweep algorithm, so it is not cost free either.

You can implement manual allocator based on similar idea as is used in Boehm's GC - what you get MUST be faster than GC, because it is basically the same code without the sweep phase. Indeed, both malloc and free translate to about 15 machine code instructions executed in the "fast" path. (Note: means I DID implemented memory allocator - I spent years optimizing...;)

To be more concrete, you can check the code at http://www.ultimatepp.org (both for memory "non-management" via owning non-copying containers and fast heap allocator code).

Edited 2006-11-21 08:43

BTW, the main architectural trouble with GC and C++ is that it is impossible to match GC and destructors. You can have GC or destructors, but never both. I vote for desctructors (GC would not close my files).

No, it is not impossible.

First of all, if C++ ever had GC, it would not be obligatory to allocate objects on the heap. Objects could happily live on the stack, as it is right now, therefore RAII would work as it is right now.

But let's say you have heap objects that you want to clean up after a specific operation...The RAII pattern works with garbage-collected objects too, using Lock<T> classes on the stack, where T is the type of garbage-collected objects. For example:

RAII<File> r1(new File());
//...bla bla bla process file
//r1 destructor closes the file.

First of all, if C++ ever had GC, it would not be obligatory to allocate objects on the heap. Objects could happily live on the stack, as it is right now, therefore RAII would work as it is right now.


The real question is: Should GC call destructors?

You will find a lot of reason why it should and a lot of reasons why it shouldn't - but in both cases something gets broken.

The real question is: Should GC call destructors?

Why not? I do not see the reason why.

RAII is programmable and not hardcoded in the compiler, and therefore RAII classes like 'Lock' can use a function other than the destructor to clear resources.

I think it is a mistake that C++ does not have optional garbage collection. There are many programmers driven away from it due to its complexity and sheer number of 'gotchas'...in the end, C++ will become a niche language.

I agree that STL's copy semantics IS THE PROBLEM, but GC is not the solution. The solution is to simply design container library WITHOUT copy semantics requirement, which is completely possible.

There is a reason so much of the C++ world has embraced the STL style. It makes memory management in C++ an order of magnitude less painful. The cost of this is copying objects around everywhere, because sharing semantics would immediately negate that convenience.

BTW, the main architectural trouble with GC and C++ is that it is impossible to match GC and destructors. You can have GC or destructors, but never both. I vote for desctructors (GC would not close my files).

It's not impossible to match GC and destructors, you just have to approach "destructors" in a different way. Leave memory management to the GC, and handle releasing resources when you leave lexical scopes using with-* macros (or something equivalent --- if the metafunction proposal had been accepted, C++ could do it too). The solution is largely equivalent, and you get the flexibility of GC.

As for performance claims, many GC advocates do not realize that often old malloc/free implementation are compared to cutting edge GC's. In the end, famous Boehm's GC, which is used in most opensource projects, has its tiny (and very smart) "malloc/free" in its sweep algorithm, so it is not cost free either.

Boehm GC is hardly the best you can do, and is hampered by having to be conservative. Moreover, while its true that there is something like a malloc()/free() in the heap manager of every garbage collector, you're ignoring that its used in a very different way. First, its invoked far less often. In a generational collector, the normal path is a simple sequential allocation. The heap manager is invoked to handle allocations only when survivors need to be copied out of the young generation. Second, in a moving GC, it can be far more callous about memory fragmentation than a good malloc()/free(). It can handle allocations/frees at a page-level granularity, because the copying/compacting process will ensure you don't end up with lots of partially empty pages.

You can implement manual allocator based on similar idea as is used in Boehm's GC - what you get MUST be faster than GC, because it is basically the same code without the sweep phase.

For the aforementioned reasons, that's not true. Even if you implemented an allocator with shitty fragmentation characteristics that handled things at page granularity, you'd still have to call it on each malloc()/free(), instead of for some (often small) fraction of them.

Indeed, both malloc and free translate to about 15 machine code instructions executed in the "fast" path. (Note: means I DID implemented memory allocator - I spent years optimizing...;)

How many clock cycles is that? When I wrote mine, I was pretty impressed at the brevity of the fast path (though yours is quite a bit smaller) but the cache behavior of accessing list structures is such that one instruction translates to several CPU clock cycles. The fast path of a generational GC, in comparison, can be less than a dozen highly cache-friendly machine instructions. Moreover, the code is so small, it can usually be inlined into the allocation site, saving another dozen cycles of function call overhead.

When I wrote mine, I was pretty impressed at the brevity of the fast path (though yours is quite a bit smaller) but the cache behavior of accessing list structures is such that one instruction translates to several CPU clock cycles.

Obviously, you have to consider this while optimizing and keep cache-lines "hot". And the fragmentation is (for typical patterns) pretty low too (in fact, it has very less than 1 byte of book-keeping info per block and fragmentation for typical usage pattern is constant number of bytes).

You are correct about "GC using memory allocation" in different way and free being much less frequent operation. Anyway, this holds true only as long as total number of reachable blocks is reasonable (e.g. you are creating a lot of temporary objects - this is best scenario for GC). I believe that as number of active blocks increases, GC advantage (if there was any) diminishes - mark/sweep becomes too complex, a lot of memory has to be moved, cache lines are not kept "hot" anymore etc etc....

Therefore IMO GC is acceptable for small datasets and small applications.

To present an opposite argument, GC can sometimes have an advantage in multithreaded environment, as it requires just single lock (world-stop) for the whole sweep phase. All depends on how much locking or TLS (for per-thread cache of blocks in non-GC) are expensive on the platform.

BTW, I mention Boehm's GC because it is what D language, discussed here as better alternative to C++, actually uses.

P.S.: Who speaks about list structures?

Edited 2006-11-21 20:58

I believe that as number of active blocks increases, GC advantage (if there was any) diminishes - mark/sweep becomes too complex, a lot of memory has to be moved, cache lines are not kept "hot" anymore etc etc...

Well, the same is true to a great extent for malloc(), as well. As the number of small allocations increases, you spend a lot more time traversing increasingly fragmented allocation lists. And GC has an edge in one respect, because it doesn't have to manage individual objects in its heap structure, and can instead can deallocate whole pages of dead objects.

I should also point out that for both GC and malloc(), this penalty comes with increasing number of objects, not increasing amounts of memory. If your program is manipulating a few hundred large matrices, even if your heap is gigabytes, a GC (at least one that has object formats and knows a matrix is a leaf object) isn't going to do a lot of scanning.

Well, the same is true to a great extent for malloc(), as well. As the number of small allocations increases, you spend a lot more time traversing increasingly fragmented allocation lists.

Well, only as long as you are using allocation lists and have to traverse them....

In the heap allocator used in U++, no scanning of blocks (well, we are speaking about "small blocks" up to 1KB here to be exact) is ever performed. Either you go fast path, using hot cache line, then there is "medium" path - up to about 500 machine opcodes (no scanning lists over the heap) and if that fails, new memory chunk has to be obtained from OS.

See, this is exactly what I was pointing at when I claimed that usually, outdated malloc implementation is compared to cutting-edge GC. Of course, if you are going to use malloc based on algorithm described in K&R, GC must win.

P.S.: Note that I agree about your opinions and info about reference counting and even on advantages of GC. Just the truth is not complete...

Edited 2006-11-21 21:26

This argument I don't really understand. Templates impose no more code overhead than doing things manually - or do you mean something else?

Well, this is debatable and relative. E.g. vector<T> instance tends to have about 500 bytes per T.

Now if you would have "Object-based" container system design (like in Java), you would have single container class for use with any T (say 1000 bytes once for any number of element types). It would be slower, but smaller.

E.g. vector<T> instance tends to have about 500 bytes per T.

Can you back this up? Which compiler/STL? This seems like an awful lot.

Sorry, it is some time I have checked. But it is not at all unreasonable - such implementation will have to have at least code for expanding vector (which is a loop to copy-construct and destruct elements, in many cases with inlined constructors) - say 150 bytes. Then there must be destructor code, another loop calling destructors for elements, say 100 bytes. Throw in 2-3 "advanced" operations (like insert) and you are close to 500 bytes.

Anyway, I guess my original claim holds true even if it was 50 bytes / vector

If size/vector does not bother you, think about map

Mirek