|
|
Home » Community » Coffee corner » C++ FQA
|
Re: C++ FQA [message #12518 is a reply to message #12515] |
Wed, 07 November 2007 00:41   |
Mindtraveller
Messages: 917 Registered: August 2007 Location: Russia, Moscow rgn.
|
Experienced Contributor |

|
|
Yes, this FQA led into massive discussion in Russian livejournal segment (more than 250 answers). I`d conclude the discussion mentioned this way: "Yes, C++ may sometimes be difficult as hell and it makes possible writing horrible code, yes there are many other problems with it. But as soon as we don`t have ANOTHER language accumulating all the might of OOP/FP along with C-like performance - C++ will live." (c)
P.S. Some time ago I`ve spent some hours learning new Pascal-languages branch: Oberon, Oberon-2, Zonnon. These are interesting things but, comparing to C++, they lack of some important abilities.
Also I`ve proposed graphical approach for creating programs, but was crucified with other massive livejournal discussion.
So, I would say for now we do not have any adequate alternatives for C++.
[Updated on: Wed, 07 November 2007 00:49] Report message to a moderator
|
|
|
|
Re: C++ FQA [message #12522 is a reply to message #12521] |
Wed, 07 November 2007 11:33   |
cbpporter
Messages: 1427 Registered: September 2007
|
Ultimate Contributor |
|
|
I've read a good deal of the FQA (and the FAQ too) and while it is mostly right, it is also strongly biased. It still makes a point though, and I think a lot of people agree that C++ is too complicated for it's and everybody else's sake. I would love for an alternative, something that is more simple, straight-forward, but still powerful.
Right now D could be the only alternative (C++0x is even more complicated and redundant). I used D for 2500+ line project (which in C++ would have been about 4000-5000 lines) with about 20 files and I think I have a pretty good idea of what it can do. It has some strong points:
1. True module support.
No more including hundreds of kilobytes if not megabytes of header files in each compilation unit. No more writing every ddecalration twice. Modules act like Java packages, can be fully qualified to avoid name clashes and can be combined to create a library with different access levels. And because each module is compiled only once, D is lightning fast. My entire project compiled from scratch almost instantly, and if I only modified the content of a function or other miner detail, truly instantly.
2. A lot of built in features, like variable length array and hash maps, which combined with some extra functions, can be used to create types like Vector or Map, but even more easy to use and without templates. char[] and about 10 extra functions could make String and StringBuffer obsolete.
3. Templates + mixins + static ifs are stronger than templates in C++ + preprocessor. I never used them, because you can do in D a lot more without templates than in C++.
4. Optional (but defaulted to true) garbage collection.
As much as you could dislike the idea of garbage collection, memory management in C++ is a nightmare, and from this point of view, even U++ which has a lot less such issues, is not able to give such pain free management.
But is also has some disadvantages. Mostly because it has been branched to D 1.0, which is stable, and 2.0 which is a moving target, is not compatible with 1.0, and is a little more complex. It introduces const correctness as in C++, but D can live a lot easier without such extra access methods to have to deal with. Also, the standard library is widely disliked, and a third party library has been created, which is pretty good (even though a little to C++ style), but cross linking between the libraries is impossible. Also operator overloading is just a little bit less powerful.
Still, it is quite a good programing language, having a lot of pain free features and performance comparable to C/C++. I would love to see such a great GUI library as U++ for D, and I'm sure it will continue to evolve.
|
|
|
Re: C++ FQA [message #12523 is a reply to message #12522] |
Wed, 07 November 2007 13:15   |
|
Quote: |
1. True module support.
No more including hundreds of kilobytes if not megabytes of header files in each compilation unit. No more writing every ddecalration twice. Modules act like Java packages, can be fully qualified to avoid name clashes and can be combined to create a library with different access levels. And because each module is compiled only once, D is lightning fast. My entire project compiled from scratch almost instantly, and if I only modified the content of a function or other miner detail, truly instantly.
|
Yeah, I like it too but there is a paper about modules in new C++ too http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n207 3.pdf . I do not know how much similar (or not) they are to D modules but it seems to be a step in the right direction.
Quote: |
2. A lot of built in features, like variable length array and hash maps, which combined with some extra functions, can be used to create types like Vector or Map, but even more easy to use and without templates. char[] and about 10 extra functions could make String and StringBuffer obsolete.
|
True. But I remember that D-people wanted to have String class. I prefere it too even if bulit-in char type is powerful and easy to use.
Quote: |
3. Templates + mixins + static ifs are stronger than templates in C++ + preprocessor. I never used them, because you can do in D a lot more without templates than in C++.
|
Yes, some D coders (like Don Clugston for example) proved they are much more powerful than C++ ones.
Quote: |
4. Optional (but defaulted to true) garbage collection.
As much as you could dislike the idea of garbage collection, memory management in C++ is a nightmare, and from this point of view, even U++ which has a lot less such issues, is not able to give such pain free management.
|
I prefer RAII approach and U++ is a very good example that this really works. Frankly if you use NTL or STL (and follow the RAII way) there is a rare situation when you have to worry about memory management. I don't know why this still is an issue.
D uses GC but fortunately it allows for deterministic destruction in "scope classes". At least in theory Must check it.
I think new C++ should break compatibility and be more like D. I don't understand why it cannot be since all current/old apps can be developed with old compilers. This way C++ will be fatter and fatter (and more complicated) with each standard revision.
[Updated on: Wed, 07 November 2007 13:30] Report message to a moderator
|
|
|
Re: C++ FQA [message #12524 is a reply to message #12523] |
Wed, 07 November 2007 14:03   |
Mindtraveller
Messages: 917 Registered: August 2007 Location: Russia, Moscow rgn.
|
Experienced Contributor |

|
|
Talking about D, are there any comparisons in exe size / execution speed of the same code for C++ and D?
Again, I just don`t like an idea of uncontrolled garbage collection. Developing some time-cricical programms for industrial automation, I dislike the fact that my time-critical code can be interrupted or slowned down by some uncontrolled process of garbage collection.
[Updated on: Wed, 07 November 2007 14:11] Report message to a moderator
|
|
|
Re: C++ FQA [message #12526 is a reply to message #12524] |
Wed, 07 November 2007 14:57   |
cbpporter
Messages: 1427 Registered: September 2007
|
Ultimate Contributor |
|
|
Quote: |
I think new C++ should break compatibility and be more like D. I don't understand why it cannot be since all current/old apps can be developed with old compilers. This way C++ will be fatter and fatter (and more complicated) with each standard revision.
|
That sound great and is pretty similar with the modules from D, with the only difference that they are already present in D, and by the time these features will be included in C, we'll all be retired programmers. I hate to be pessimistic, but if history has though us anything is that those behind C++ are a bunch of close minded people who have no intention to break compatibility and will gladly bloat the language with absolutely retarded and redundant features. Just have a look at C++0x, and see that most stuff just tries to fix old problems with new redundant features and by keeping the old ones. And even if they do introduce modules, by the time there will be a compliant compiler, I hope that C++ will be less popular for real-life application development.
Quote: |
I prefer RAII approach and U++ is a very good example that this really works. Frankly if you use NTL or STL (and follow the RAII way) there is a rare situation when you have to worry about memory management. I don't know why this still is an issue.
|
It's probably because I'm not as skilled with high level C++ features, but the issues with memory management are quite present for me in U++.
While the language has deep copy, value references, copy constructors, etc., I think that it is impossible not to have such issues. And in U++ I spend a great deal of time just messing with const correctness and other low level details which I shouldn't be forced to worry about.
Quote: |
Again, I just don`t like an idea of uncontrolled garbage collection. Developing some time-cricical programms for industrial automation, I dislike the fact that my time-critical code can be interrupted or slowned down by some uncontrolled process of garbage collection.
|
Well in D you can always chose not to use garbage collection for a class or even just a part of your code. You can use C style pointers, and even call malloc if there is a need to. But I consider this some kind of a myth. Has there been a documented case where garbage collection had serious impact on performance. It is true that such applications sometimes have the bad habit of hanging for 2-3 seconds when a garbage collection cycle starts, but this shouldn't be an issue in non GUI applications. And U++ and even STL does a lot of "garbage collection", only it is more deterministic, but not necessarily faster.
|
|
|
|
|
|
|
|
Re: C++ FQA [message #12539 is a reply to message #12535] |
Thu, 08 November 2007 00:13   |
Mindtraveller
Messages: 917 Registered: August 2007 Location: Russia, Moscow rgn.
|
Experienced Contributor |

|
|
cbpporter | They are by far not uncontrolable, and only happen in some apps.
| OK, as a developer who likes D programming paradigm, and who wants writing efficient applications, I will consider changing language to D if
1) There`s a simple way to guarantee no hangups at all.
2) My .exe will be <10%-15% slower than corresponding C++ code in any case.
These are critical conditions. Can D, or any other alternative fit?
P.S. luzr, I just thought that D and U++ comparison is not quite honest. It would be better to compare internal language features of D and C++. According to the tests described in D site (I looked at them as you recommended), D is no slower than C++ (at least in some cases?). So porting the U++ classes and algorithms to D, adopting them for D specifics could make U+D (U++ for D) as fast as original U++. It`s just a theory, of course.
[Updated on: Thu, 08 November 2007 00:20] Report message to a moderator
|
|
|
|
Re: C++ FQA [message #12543 is a reply to message #12539] |
Thu, 08 November 2007 05:34   |
 |
mirek
Messages: 14257 Registered: November 2005
|
Ultimate Member |
|
|
Mindtraveller wrote on Wed, 07 November 2007 18:13 |
cbpporter | They are by far not uncontrolable, and only happen in some apps.
| OK, as a developer who likes D programming paradigm, and who wants writing efficient applications, I will consider changing language to D if
1) There`s a simple way to guarantee no hangups at all.
2) My .exe will be <10%-15% slower than corresponding C++ code in any case.
|
3) Add to mix memory requirements. In that "Alice" benchmark, D used about 2-3 times more memory than U++ (if I remember well).
BTW, it is some time when I last tried it. I would really be very glad if somebody reproduced my results; here is U++ code:
#include <Core/Core.h>
using namespace Upp;
#define BENCHMARK // for benchmark purposes, output is omitted
#ifdef BENCHMARK
#define BENCHBEG for(int i = 0; i < 1000; i++) {
#define BENCHEND }
#else
#define BENCHBEG
#define BENCHEND
#endif
void main(int argc, const char *argv[])
{
VectorMap<String, int> map;
BENCHBEG
for(int i = 1; i < argc; i++) {
String f = LoadFile(argv[i]);
int line = 1;
const char *q = f;
for(;;) {
int c = *q;
if(IsAlpha(c)) {
const char *b = q++;
while(IsAlNum(*q)) q++;
map.GetAdd(String(b, q), 0)++;
}
else {
if(!c) break;
if(c == '\n')
++line;
q++;
}
}
}
BENCHEND
Vector<int> order = GetSortOrder(map.GetKeys());
#ifndef BENCHMARK
for(int i = 0; i < order.GetCount(); i++)
Cout() << map.GetKey(order[i]) << ": " << map[order[i]] << '\n';
#endif
printf("%d\n", map.GetCount());
}
(I had to loop over it more times, otherwise the execution for Alice.txt was too fast to be measurable).
Quote: |
P.S. luzr, I just thought that D and U++ comparison is not quite honest. It would be better to compare internal language features of D and C++. According to the tests described in D site (I looked at them as you recommended), D is no slower than C++ (at least in some cases?). So porting the U++ classes and algorithms to D, adopting them for D specifics could make U+D (U++ for D) as fast as original U++. It`s just a theory, of course.
|
I think this is not quite possible, as language features are way too different.
OTOH, in this particular benchmark, D is using internal language features, while C++/U++ is using library. Still, we are faster and the code is shorter. That IMO says a lot about language flexibility.
Mirek
|
|
|
Re: C++ FQA [message #12546 is a reply to message #12539] |
Thu, 08 November 2007 13:33   |
Zardos
Messages: 62 Registered: April 2007
|
Member |
|
|
Mindtraveller wrote on Thu, 08 November 2007 00:13 | OK, as a developer who likes D programming paradigm, and who wants writing efficient applications, I will consider changing language to D if
1) There`s a simple way to guarantee no hangups at all.
2) My .exe will be <10%-15% slower than corresponding C++ code in any case.
These are critical conditions. Can D, or any other alternative fit?
|
I switched from D to UPP because:
D uses an old object format which makes it impossible to link you d programs with ordinary c libraries. You have to compile the c libraries with digital mars c. Or you have to use some convertes which converts the libs in the old format
Lack of D libraries: While I was in the language - D was an constant moving target. Every weekly new version broke your code (and the code of the libraries)
No professional GUI library available. Well you could build one of you own.. But see the point above.
Performance: Some D code compiles to very efficient code. Sometimes even better than MSVC, but some parts are unacceptable slow. For example the built in associative arrays are horrible slow. ...And you can not fix this by fixing the library, because they are really built into the language
Garbage collection: Even if the last version of the grabage collection is less conservative it is still a conservative garbage collection. -> See Mireks comment.
No useful IDE with integrated dubugger avilable. Productivity is not only related to the language...
And I completely lost interest of the language at the time when Walter decided to at CONST to the language (currently only in the development branch). Well he claims "you don't have to use it..." but I doubt this. I expect a similar disaster as in C++: Add one const and the source is infected...
IMHO C++ sucks. But I don't see a serious choice for my requirements. UPP showed me again that you can ship (most times) around the flaws of C++...
But I'm still dreaming of a language like D without the shortcomings. May be compiled to C++ in the first incarnation to make all C++ libraries available automatically?
So don't get me wrong. I think D is really great (except of the added const). It has fantastic template and meta programming capabilities and its design is clean and ellegant. It has all the state of the art constructs you would expect from a modern language...
[Updated on: Thu, 08 November 2007 14:01] Report message to a moderator
|
|
|
|
|
Re: C++ FQA [message #12558 is a reply to message #12556] |
Fri, 09 November 2007 08:51   |
 |
mirek
Messages: 14257 Registered: November 2005
|
Ultimate Member |
|
|
mdelfede wrote on Thu, 08 November 2007 17:39 |
luzr wrote on Thu, 08 November 2007 19:25 |
Well, as of const, I generally tend to thing that while initially it feels like plague, after a while you can find it quite useful, at least to describe the interface better.
Been through it ages ago....
|
me too.... at the beginning I found it boring and ennoying stuff, now I find it very useful. The bad thing is that c++ allow you to recast const to non-const... so a badly written library can do what he wants.
Max
|
Well, but that is useful feature and this is one of things I like with C++ - the "default" mode is "safe", but you can always do dirty things when you need them.
In other words, you can also say that a well written library can do what it needs 
Actually, interestingly it seems like I am the only one here who in fact likes C++ as it is (except some quite small issues and the standard library, which IMO only looks like a good design).
Mirek
|
|
|
Re: C++ FQA [message #12576 is a reply to message #12515] |
Fri, 09 November 2007 12:56   |
 |
tvanriper
Messages: 85 Registered: September 2007 Location: Germantown, MD, USA
|
Member |
|
|
Actually, I rather like C++ as it is, too.
But then, after having worked with it for so many years, I'm maybe rather comfortable with it, enough to make it do pretty much whatever I want.
I don't want a language that coddles me (by trying to prevent me from doing something dumb), but I also don't want to deal with machine-code. I want something that can scale, but let me deal with the bit-twiddling details if necessary. C++ provides all of this for me.
And, most of the time, if I've found my application is starting to look a little wordy, it's probably because of a bad design.
This isn't to say that I'm not intrigued by some of the other developments I've heard about in C++0x and others, but I'm happy with C++ as it is.
C++0x, if I recall, is really an attempt to make the language easier to handle for folks new to the language. As such, at this point in my life, I have no need for it.
I haven't really looked deeply into D, so I can't really comment on it, except to say that I haven't met a lot of people who know how to program in D, so commercial projects written in D would require a very special person to maintain it, which could drive up costs. I might consider writing fun stuff with D, but until the language becomes more mainstream, I'd hesitate to use it for work that provides me with a paycheck.
|
|
|
Goto Forum:
Current Time: Sun May 11 17:15:44 CEST 2025
Total time taken to generate the page: 0.04639 seconds
|
|
|