Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » Coffee corner » C++ FQA
C++ FQA [message #12515] Tue, 06 November 2007 23:27 Go to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

May be interesting..
http://yosefk.com/c++fqa/
Re: C++ FQA [message #12518 is a reply to message #12515] Wed, 07 November 2007 00:41 Go to previous messageGo to next message
Mindtraveller is currently offline  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 #12521 is a reply to message #12518] Wed, 07 November 2007 10:40 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

Quote:

So, I would say for now we do not have any adequate alternatives for C++.

Some claim it is D (www.digitalmars.com/D). At least it has comparable set of features.

[Updated on: Wed, 07 November 2007 10:40]

Report message to a moderator

Re: C++ FQA [message #12522 is a reply to message #12521] Wed, 07 November 2007 11:33 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
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 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

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 Wink 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 Go to previous messageGo to next message
Mindtraveller is currently offline  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 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Quote:


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:


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 #12527 is a reply to message #12524] Wed, 07 November 2007 15:14 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Mindtraveller wrote on Wed, 07 November 2007 08:03

Talking about D, are there any comparisons in exe size / execution speed of the same code for C++ and D?



Dig in D website. There is an example where D beats C++/STL.

Of course, I could not resist to do the same thing in U++ Smile (And yes, U++ is about twice as fast as D, with shorter code).

Mirek
Re: C++ FQA [message #12529 is a reply to message #12527] Wed, 07 November 2007 15:39 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
Well, speaking about 'different' languages, there's also Borland's Delphi (objectpascal) that makes stuffs much easier than C++.
You can have low level (and so *fast*) programs when you need, without loosing the comfort and type-safe pascal character.
Plus, the extensions Borland introduced over simple pascal are quite powerful... and makes true modularity possible.
Compilation is among the fastest, and resulting code is quite good, too... being only few percent slower (IMHO !) than c++ normal code.
It has also true RTTI built-in. It's only a pity that Kilix (Delphi ported to linux...) had no good luck in market.

Ciao

Max
Re: C++ FQA [message #12532 is a reply to message #12515] Wed, 07 November 2007 17:05 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
"have the bad habit of hanging for 2-3 seconds"

Oh.. Smile There are applications which have to respond within 10 milliseconds otherwise something nasty happens to some device... Very Happy

2-3sec is like ages for them.
(and yes, some of those applications are written in C)
Re: C++ FQA [message #12534 is a reply to message #12526] Wed, 07 November 2007 18:02 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 917
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

cbpporter

such applications sometimes have the bad habit of hanging for 2-3 seconds when a garbage collection cycle starts
This is totally unacceptable for a great number of applications including industrial automation, net exchange, multimedia, device i/o, games, etc.

luzr

U++ is about twice as fast as D, with shorter code
Oops... with these calculations and 2-3 sec uncontrollable delays... just forgetting about D Cool

Any more alternatives to discuss?
Re: C++ FQA [message #12535 is a reply to message #12534] Wed, 07 November 2007 19:30 Go to previous messageGo to next message
cbpporter is currently offline  cbpporter
Messages: 1401
Registered: September 2007
Ultimate Contributor
Quote:

Oops... with these calculations and 2-3 sec uncontrollable delays... just forgetting about D

I said that they can accur. They are by far not uncontrolable, and only happen in some apps. And I really wish they were so short in Java, but there they are a lot longer and totally uncontrolable, yet it is still used a lot (too much). With my application I was wery happy with it's performance. And very short allocation time plus almost zero deep copies can make up for it.
Re: C++ FQA [message #12539 is a reply to message #12535] Thu, 08 November 2007 00:13 Go to previous messageGo to next message
Mindtraveller is currently offline  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 #12542 is a reply to message #12526] Thu, 08 November 2007 05:25 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
cbpporter wrote on Wed, 07 November 2007 08:57


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.


Note that the price of this feature is the use of conservative GC.

Which makes D code behaviour dependent on data processed. E.g. it is dangerous to use D to process large cryptography application.

In the end, IMO, this makes D a toy language.

Mirek
Re: C++ FQA [message #12543 is a reply to message #12539] Thu, 08 November 2007 05:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 Go to previous messageGo to next message
Zardos is currently offline  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 #12551 is a reply to message #12546] Thu, 08 November 2007 19:25 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Zardos wrote on Thu, 08 November 2007 07:33


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



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....
Re: C++ FQA [message #12556 is a reply to message #12551] Thu, 08 November 2007 23:39 Go to previous messageGo to next message
mdelfede is currently offline  mdelfede
Messages: 1307
Registered: September 2007
Ultimate Contributor
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
Re: C++ FQA [message #12558 is a reply to message #12556] Fri, 09 November 2007 08:51 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 Smile

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 Go to previous messageGo to previous message
tvanriper is currently offline  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.
Previous Topic: Tools or methodologies you use when developing software
Next Topic: About vista....
Goto Forum:
  


Current Time: Fri Mar 29 14:22:30 CET 2024

Total time taken to generate the page: 0.01598 seconds