“A good programming language is far more than a simple collection of features. My ideal is to provide a set of facilities that smoothly work together to support design and programming styles of a generality beyond my imagination. Here, I briefly outline rules of thumb (guidelines, principles) that are being applied in the design of C++0x. Then, I present the state of the standards process (we are aiming for C++09) and give examples of a few of the proposals such as concepts, generalized initialization, being considered in the ISO C++ standards committee. Since there are far more proposals than could be presented in an hour, I’ll take questions.” Dr. Bjarne Stroustrup is the original designer and implementer of the C++ Programming Language.
C and its children are the Esperanto of programming languages.
Just good enough to be used, just bad enough to inspire countless revisions, and even with vastly superior successors it’ll probably never die just due to the inertia of having been there first.
Does anyone have a link to a transcript?
no no, c is not bad. macro’s, global variables, pointers, no range checking (for arrays), bufferoverflows, the stl error messages and that kind of stuff are bad.
c(++) has a nice syntax. java and c# don’t have the problems mentioned above, and that’s why they are often used.
Macros are bad. Global variables are necessary. Pointers are useful (although not always necessary). Range checking is good in all but the most performance-critical code. I’ll add that manual memory management is usually (but not always) unnecessary.
C++ does NOT have nice syntax and it’s semantics are even worse. Java is nice, C# is a little nicer, but neither compiles very well to native code.
D ftw!
C++ does NOT have nice syntax and it’s semantics are even worse. Java is nice, C# is a little nicer, but neither compiles very well to native code
While I agree C++’s syntax could be a lot better, I very much disagree with your assertion that C++’s semantics are bad. When used properly they are extremely powerful. For example, neither of them have an alternative for RAII (Resource Acquisition Is Initialization). Efficient & correct managing of resources is greatly eased by this pattern. Nor do they have a decent look-up mechanism for functions (there are plenty of things better left a function than a method). Or an alternative for templates (the STL containers are a blessing to work with). Saying its semantics are bad is nonsense: they are different. Different is not bad, as long as you use the right tool for the job.
Not necessarily. Macros provide for a way to transform text into other text, what’s bad is the usage of macros that some people do.
With macros you could do this, in C++:
synchronized(object)
{
// Atomic operations here
}
Just like in java, and it would be totally legal C++, provided the macro synchronized expanded to something like this:
#define synchronized(o) for((o).Lock(); (o).isLocked(); (o).unLock())
Where o would be an object of a class exposing the Lock/isLocked/unLock methods. If a class inherited from a, say, synchronizable class implementing those methods, you would be able to do
someclass::somemethod()
{
synchronized(*this)
{
// bla bla bla
}
}
Which would be the equivalent of a synchronized method in the Java language.
You can have range checking in C++, you just need to either implement it in a class of your own or use some of the already existing classes.
You can have managed memory handling in C++ as well.
Well, I admit, you can’t decapitate a for loop with an inline function. But you also can’t do this:
#define BAD_MACRO(x) if(x) cout << “Are macros bad?” << endl;
if(true) BAD_MACRO(might_be_zero);
else cout << “Macros are bad!” << endl;
Macros can change the way we think about truth.
Use inline functions in place of macros. If you need to inline something that isn’t a function, you’re doing something wrong. What’s so bad about this?:
o.Lock();
// stuff
o.unLock();
That’s the way C++ works, plus you avoid the unnecessary isLocked() call. Should C++ have multithreading primitives? Probably, but that’s another issue.
Yes, I know you can extend C++ in all sorts of ways. But a lot of these hacks are workarounds for missing language features. You shouldn’t need a special class to have a bounds-checked array. This should be an opt-out feature.
Edited 2007-08-13 22:08
The mentality of C++ is you only use what you are willing to pay for, you only pay for what you use. There is an associated cost (processing time) with the features your talking about. They are “hacks” because not everyone wants the same features so why should everyone pay for them.
You don’t pay for the features you don’t use, so there’s no harm in implementing the features the right way for those who wish to use them.
For example, D provides a boat-load of features, but if you want to write straight C, you can. You don’t have to pay the price of garbage collection, bounds checking, and so forth if you don’t want to.
The C++ mentality means that there’s a much greater penalty for using advanced features. Not only a penalty in performance, but also usability and maintainability. No wonder developers are scared to use it as anything beyond C with Classes.
As already said, blame the programmer, not the tool.
The fact that you need to invoke the unLock() method explicitely, which is prone to error and is the reason for using the macro in the first place.
Why not?
Placing the closing bracket of your for loop is prone to error, and if you leave it out completely, I imagine the resulting compiler error being non-trivial to track down. Coverity is useful for verifying arbitrary locking conventions.
Why make the bounds-checked array the default array? Because you very rarely want to reference outside the bounds of an array, and you very rarely care enough about the minimal overhead to warrant the risk of bugs and vulnerabilities. For those times where you want to linearly traverse a 2D array or where you need to squeeze everything out of that inner loop, you can opt for the simple array.
1) It’s less prone to error than having to write a full method call, since you’re likely to get a graphical hint from the editor you’re using. In any case, it’s not more prone to error than omitting any other closing braket.
2) The compiler might emit a non trivial error, this depends on the compiler, but at least it will complain. A far better situation than it not complaining at all.
Quite a controversial statement from soneone who advocates the compiler to have all features one needs… then use an external tool to do something the compiler can already do? 😉
I don’t agree, I don’t want to pay for what I don’t use. But in any case, “default array” is nonsense: declaring the type of an object is up to me, it’s me who decides whether or not to use a certain type or not, certainly not the compiler. Therefore, wherever I want I can use the bound-checked array.
That is to say, the “default bound-checked array” is a policy I, the programmer, have to and can adopt without any extra efforts.
… and where would the .Lock() method come from? c++.lang.Object? (sorry, couldn’t resist 🙂
Macros mean that language is not full-featured and many things can not be done with language itself. Using macros is stupid.
Macros are part of the language: your point is moot.
Edited 2007-08-14 06:30
For being part of the language, they are surprisingly unaware of how the language works.
Macros will gladly mess up anything, without worrying about things like namespaces.
Having the following code messed up, just because “Sun” is #define’d when you try to compile on Solaris is really not very helpful.
namespace x
{
class C
{
private:
enum { Mon, Tue, Wed, Thu, Fri, Sat, Sun };
};
}
synchronized(object)
{
// Atomic operations here
}
Just like in java, and it would be totally legal C++, provided the macro synchronized expanded to something like this:
#define synchronized(o) for((o).Lock(); (o).isLocked(); (o).unLock())
That “synchronized” macro will only work if you have non-throwing code synchronized. Otherwise you’ll end up with a lock that will stay locked forever.
In C++ you will probably want to use something like scoped locking.
You’ll find an example of how that is done here:
http://en.wikipedia.org/wiki/Singleton_pattern
The MutexLocker class replaces your macro and does a better job.
In it’s simplest version it looks something like this:
class MutexLocker
{
public:
MutexLocker(Mutex& pm): m(pm) { m.lock(); }
~MutexLocker() { m.unlock(); }
private:
Mutex& m;
};
In C++ there are actually very few times I feel the need to use macros. Macros create more problems than they fix in my opinion.
The MutexLocker class replaces your macro and does a better job.
Of course, you can use such an AutoLock in the macro, if you insist on having a “lock” keyword. See here: http://www.stoks.nl/rants/lock.html
Edited 2007-08-14 09:51
Sure, but then you’re just using macros for the sake of using macros, or to change the appearance of the code.
In both those cases, macros actually do a good job.
The page you linked to does not correctly mimic the C# “lock”. If you use the same syntax in C++ as C#, the scope of the lock will be different from that in C#.
Since the lock macro is outside the block that should be locked, the lock won’t go out of scope when the block ends and the unlocking will take place at a later time, which may or may not be a problem.
“
”
That’s true, of course. It was just an example meant to show the flexibility of the preprocessor and its possible uses, thought up in 5 seconds.
To have better examples as of why the preprocessor is useful, just have a look at the BOOST preprocessor library.
It is amazing you a synchronize keyword, which is a REALLY simply concept in say Java, or C# and created a discussion.
Now imagine writing application code. The C# and Java person can focus on actually getting the problem done. Whereas the C++ developer will be arguing with another C++ on how to write a bleeden lock statement.
Yeah I am SOOOOO glad I ran from C++…
Edited 2007-08-14 09:37
While I didn’t run from C++, I’m glad I have the option to chose different languages when I want to.
In C++ you sometimes have the illusion of success, just because you solved a problem that you have only because you use C++. It might feel good, but you haven’t really accomplished much.
You can have range checking in C++, you just need to either implement it in a class of your own or use some of the already existing classes.
Range-checking (memory safety in general) is useless as an added feature. It’s something that really needs to be in the guts of the system, used by not just your code, but everything under your code.
The cost of validity-checking is zero compared to good (defensively programmed) C++ code, which does it manually anyway. It’s small even compared to bad code that blindly assumes it is passed correct parameters.
Anatomy of a check (in a magnitude-squared example):
double mag_squared(vector vec) {
double sum = 0.0;
double t0, t1;
for(int i = 0; i less_than vec.length; ++i) {
if(i greater_equal vec.length()) throw_error();
t0 = vec[i];
if(i greater_equal vec.length()) throw_error();
t1 = vec[i];
sum += (t0 * t1);
}
return sum;
}
This is the canonical, naively-inserted check, in pretty much the worst case (tight loop). It looks pretty bad, doubling the code inside the loop. This canonical description also shows all the reasons why checks are actually really cheap.
1) Range analysis can easily show that the induction variable (i) can never be greater than the length of the vector, making the checks completely unnecessary.
2) Redundency analysis can easily show that the second check is made redundent by the first check. This is obvious in this particular case, but happens in code where valies are reused. Type checks in particular, are easily removed by redundency analysis.
3) Even if you can’t get rid of the checks, it’s not so bad. It’s easy to prove that the length of the vector doesn’t change, so it can be loaded into a register outside the loop. Inside the loop, the checks are a simple compare and and perfectly-predictable conditional jump. On a modern load/store-limited CPU, there are almost always idle integer units available to execute these ops, and as a result they’re almost free.
You can have managed memory handling in C++ as well.
See above rant on range-checking.
Edited 2007-08-14 21:47
The thing funny with range checking is that its cost is, at least for numerical code, much lower than the ones caused by aliasing. I am often baffled by people who think that C or C++ has not cost at all for performance critical code. Generally, I feel like C++ encourage premature optimization (the virtual keyword, for example), for no reason at all.
rayiner,
your example in C++ would be best implemented with an iterator or with the foreach macro described earlier. All your example proves is that when there’s no link between syntax and semantics the compiler cannot optimize unnecessary code away, therefore the solution is to create that link, which is what an interator pattern does.
My example was to show that it’s easy for the optimizer to get rid of range checks. The code shown was how naive range-checks would be inserted, before optimization.
In any case, using an iterator in a tight loop is a bad idea. The iterator version would expand into something like:
double* ptr = vec;
double sum = 0.0;
while(ptr != vec.end) {
double t0 = *ptr;
if(ptr != vec.end) ++ptr; // will be eliminated
sum += (t0 * t0);
}
The range-check can be eliminated because the condition protecting it is made redundent by the loop-end test. This is exactly the same reason the range-check can be eliminated in the other example I showed.
However, this example is worse because it replaces array accesses with pointer arithmetic. The compiler will eventually lower the array accesses to pointer arithmetic anyway, but late in the optimizer. Before that, keeping things in array form makes classical loop/array optimizations (eg: dependence analysis) much easier.
Pointers are useful (although not always necessary)
You have GOT to be kidding me. This REEKS of someone who doesn’t really know how to use pointers. Pointers is what it’s all about.
C++ does not have nice syntax… when it comes to templates. Templates over complicate the syntax, not to mention the debugging output.
So, I take that you rather to overload functions?
“Just good enough to be used, just bad enough to inspire countless revisions, and even with vastly superior successors it’ll probably never die just due to the inertia of having been there first.”
That sounds exactly like a desciption of the average programmer who is incapable of programming C or it’s children because they require nappies in the runtime environment to keep making up for the buggy, diseased code they end up slapping together.
Vastly superior successors? Do you have ANY experience with real development?
There’s a time and a place for C and C++, just like there’s a time and a place for Java and C#, just like there’s a time and a place for machine code and assembly programming.
There are a number of tasks that I wouldn’t want to do in any other language than C. It is simply the best tool for some jobs.
I’d really like to hear about some of these vastly superior languages, so I can write my kernel drivers in them.
I’d really like to hear about some of these vastly superior languages, so I can write cellphone applications in them.
Please, share with me what these wonderful panacea languages are, so that I can write my toolkit libraries in them, and let my customers call them from whatever language they use.
When people talk of vastly superior languages, they are really talking about a shift in language application. People can do much more much quicker in Java/C#/Perl/Python/Ruby then in C/C++ (speaking from experience as a former Java/C/C++ programmer). Thus the application space for C/C++ shrinks, people move to more modern languages, and they begin to frame their discussions wrt those languages.
Ahh, finally. Someone bringing an intelligent comment to the discussion.
I’m so tired of GC-jerks going around talking about the death of C/C++, and how inferior they are. They are little children running around shouting how much better their G.I. Joe is than your He-Man. Yeah, G.I. Joe’s got guns and fighter jets, but He-Man has a magic sword, and battlecat, AND advanced technology.
Er, ummm, yeah – sorry for the tangent. But the point is, they have their application domain, where they make sense, where they’re the best tool (so far) for the job.
Pascal, D. At least they have better syntax and don’t have stupid “features” like header files.
The problem with C++ are people using it thinking it’s just C with additional stuff.
No, why?
Many simply don’t like all the additional complexities of C++ and use it as an improved C.
I like C. But I also like references better than pointers, and prefer std::string to an array of char.
What’s wrong with that?
Nothing in and of itself. The problem is when you have lots of people working on the same code. Some people will write C++ like you do, some people will go template happy and use them for everything, a third person will write C++ in a completely different way. And much confusion will arise.
The problem with C++ are people using it thinking it’s just C with additional stuff.
No. The problem with C++ is all the people using it who don’t know that it is just C with additional stuff.
As someone who learned to program in Pascal, I’ve always disliked C/C++ syntax, but it really is the only widely supported language that compiles to native machine code.
Take this link, educate yourself, then re-read your post, sir:
http://gcc.gnu.org/
And I quote:
“The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Java, and Ada”
Objective-C is virtually unused and unsupported outside of OS X. Fortran is a niche language these days and only used within certain high performance computing circles. Ada is even less used and less supported than Fortran in the real world. Java could be a contender, but the gcc support is woefully behind and incomplete.
So I fail to see what your link is supposed to prove. C and C++ are in fact the only widely supported language that compiles to native machine code.
I am familiar with GNAT. Compilers aplenty there may be but I need libraries as well. Toolkits, sound and graphics APIs, networking, threading and so on. No language is anywhere near as well supported as C.
You realize of course that the reason your operating system isn’t dog slow is because they *are* using a very close to asm-like language, aka C and some use C++.
<rant>
Just because C/C++ don’t hold your hand doesn’t mean they don’t have a use. They are system level languages, and I have to think of the fantastic duo that created it and Unix everytime I have to write embedded software. ASM is a pain in the ass, C is like a better ASM without the hassle of remembering all the machine specifics, and C++ is like a better C, adding in some great features that save time if you know how to use them. Thinking about it in those terms, it makes perfect sense why they exist and why they are so popular. I have no doubt more than half the programmers out there despise these languages because they never understood how a computer really worked in the first place, or even if they did, despised the effort required to write proper C/C++ programs. Hell C++ makes it even easier if you follow a few simple paradigms and common practices. Of course your not going to learn it over night in some C++ 24hrs book which teaches a glorified C as C++.
</rant>
The point to this whole article is that C++ could be pushed further, to be a even better OOP/system-level language. So why not try and improve it, or learn why C++ is a dead-end design-wise?
RANT
BEGIN
Most software isn’t system software and doesn’t need all that low-level stuff. Yet C/C++ are the default languages of programming. Office software, web browsers, games etc. are all written in C++. Why? Stability and cost of development are much more important than perfomance, even in games. C++ is used because it’s widely known, which thus reduces the cost of development, not because it’s an inherently good language for software development. It allows you to make mistakes most people have absolutely no need to make and the result is not that the only programmer is a good programmer, but rather that there are an awful lot of very bad programs in the wild. Crashes and memory leaks are as much the fault of the choice of language as they are the fault of the programmer. There are plenty of other languages that are just as fast for most things. C/C++ do indeed have their place, it’s just that that place isn’t everywhere.
END RANT.
Performance is not important until it’s a problem. Games are definitely still pushing the limits of hardware and performance is very important. Even a lot of complex desktop apps are not so fast that a move to a higher level language wouldn’t hurt them. Imagine Photoshop coded in Java. Or OpenOffice. Openoffice is already slow enough as it is, mostly due to years of cruft. Add the overhead of a higher level language on top of that and you’ve got serious problems. Just look at Eclipse. Complex applications are possible in Java/C#/Whatever but they are also very resource intensive.
Anyway, C++ is fine with the right toolkit. I almost never have to worry about managing memory in my C++/Qt apps. Almost everything is done on the stack anyway and passed around with references or copy-on-write semantics. It’s just traditionally C++ tools were crap, or used C libraries for things like string handling.
Who said anything about higher level? You don’t have to use a virtual machine just because you don’t want to use C++. There are the likes of Pascal/Modula-2/Ada. They have their own flaws, but for many purposes they are very good. And you won’t loose any performance.
(!C++) != dog_slow
The C family of languages was not chosen as the de facto standard because they were so great, it just happened that way. They are good at low-level programming, but most people shouldn’t be doing that (yes, even games programmers, beyond the odd shader) – that’s what OSs are for, after all.
Ada is the only one out of the list I’ve seen, and it certainly looks very nice, and it is also used in embedded applications from what I’ve seen. I think I read boeing used it in one of their planes even.
I’m not saying (!C++) == dog_slow
I’m saying compiled C++ produces pretty darn fast and reasonably (though not always true…) compact binaries compared to *most* of the languages people are saying are the new wonder-bread language. Especially things like C#, Java, Ruby, etc.
I don’t hear people saying “lets all use Pascal now” or “lets all use Ada now” I hear… lets all use “C#” or “Java” or whatever the new fancy pants language is.
D is probably the only exception to the list of new wonder-bread languages that appears to be worth squat. It needs more bindings to popular otherwise it looks very nice.
I’d rather not play games that are dog slow either, thank you very much.
Actually, performance is pretty key in most desktop applications. No one likes waiting. As I said before as well, C++ makes it fairly easy if you use it the right way, aka RAII and some other common practices.
Sure, no one likes segfaults, but once the program works properly speed is usually important. People still rag on OO.o over MS Office because of the speed, though not a language specific issue it does point out performance is actually a desired attribute of most programs; even those crufty old office type programs.
Its a real competative edge when your program is significantly faster, and the language choice can matter.
Think of any sort of image, video, or audio processing and editing. Think about movie playback (especially the H264 codec). Think about your desktop in general.
Now think about all of that 4x slower and using up 4x as much ram. Suddenly all the nice new hardware isn’t worth a damn thing. Now lets say you have 4 programs running, all 4x slower, taking up 4x as much memory. Your computer isn’t doing 4x more work, no, its doing 16x more than it would’ve been doin had some devs not gone the lazy way out.
Features are not free.
Sometimes its an acceptable loss, most of the time its not. My desktop (brand spankin new) would quite literally be unusable if everything were written that way.
It looks that You heard of only two languages C and someking of Java/PHP/Perl. So you have divided everything into two categories: C and not C. And everything that is not C is bad. Actually C is bad – it has nothing useful nowadays.
ASM is NOT a pain in ass. And OSes does not need to be written in C/C++ to be fast – there are some languages which are better/easier/safer and compilers for them do generate a very good binaries. Sometimes even better then C-ones.
So you can enlighten us and show HIGH QUALITY OSes written in those “some languages which are better/easier/safer” ?
A programming language is as bad as the skill of the programmer.
As long as you have a nice toolkit like Qt, C++ can be a joy to program on. And there really isn’t a replacement for it, Java/Mono and the like are higher level languages meant for a very different purpose.
I’m a real c++ fanboy. Yes, it’s big. Yes, it’s ugly. Yes, every conceivable feature is implemented in at least two ways due to the commitee effect.
However, to get stuff done in the system programming space while keeping performance top notch, c++ is the way to go.
And thank god concepts are in… templates will be pretty darn powerful now. And delegating ctors are welcome too.
Edited 2007-08-13 18:10
Not every feature. I find languages that don’t implement closures boring. Iterating over a data-set should be as simple as passing a closure, none of this silly Iterator stuff.
It would be smarter to put the same energy into D. (http://digitalmars.com/d/)
I thought D was Intel-only. C++ works on any processor.
I thought the g++ frontend is as portable as the gdc frontend … intel only as it looks like.
Yes, let’s dump the hundreds of millions of lines of code written in this tried and tested, standardised language, and put lots of resources into a brand new, proprietary language supported by only one company, and which (as far as I can tell) doesn’t even have a standard library.
What a great idea! Well done!
Edited 2007-08-13 19:28
Not to start a language war, but D does work under gcc (multi-platform) and can use the C++ libraries.
If there be remaining niggles, why not address them? The end result may well be a whole lot cleaner than more patches on C++.
The title of this thread is “The Next Generation C++”. The language war is officially on-topic.
I’m totally with you on D. It has two FOSS implementations, one of them in GCC. D is binary-compatible with anything written in C, including your native libraries. Besides macros, C code compiles unmodified in D, and there are scripts to convert your #includes and headers to imports and modules.
The feature set is more like Java and C# than C++, but it compiles to native code. It lets you go as low as you want, from pointers and manual memory management down to the inline assembler. But it also has template meta-programming, multithreading primitives, garbage collection, and even built-in unit testing.
The tradeoff is no C++ compatibility. So, unfortunately, it can’t use C++ libraries as you’ve described. Because of its design, a language must implement almost the entire C++ semantics and compiler in order to link to C++. For this reason, the only language that can link to C++ is, well, C++.
D is designed to simplify compiler development, allowing for better optimization and more compliant implementations. A large subset of D (minus inline assembly and other low-level features) is suitable for compiling to bytecode for various virtual machines.
It’s everything that C++ should have been, and the only downside is that it’s not C++. Inertia sucks.
…it can’t use C++ libraries as you’ve described… Sorry, I had C++ on the brain, I did mean C libraries. Thanks for the catch.
I use or have used all of the above (except C#) so believe me when I say C++ and Java are frustrating. My use tends to focus on prototypes so it is well I have moved on. Their learning/re-learning curve is steep and as such, they are not well-suited for newbies, casual users, and those that don’t use them everyday. That is not to say that they don’t have their place, they do.
I’m finding my preferred suite to be C, D and Python. They are not perfect, but they seem to give me the “right” blend of learning curve, RAD, performance, maintainability, cleanliness (for tutorial purposes), and multi-platform I want. YMMV. (I’m still not happy with GUIs and the amount of work required for quick, ad hoc projects. Mebbie someday that will change.)
Anyway, nice discussion and hopefully our world will continue to improve. …and yeah, Inertia does suck. 😉
Here’s why I love C++: it is essentially the ONLY object-oriented language that provides the programmer with very tight control over the generated assembly code (OK, I haven’t tried D).
I love C++ for this exciting interplay between high-level abstraction and low-level brute force.
If you know the C++ language well enough, you get exactly the same excellent low-level control as with C. The object-oriented aspects, such as templates and inheritance, do not bring any overhead — actually the assembly code doesn’t even “remember” those abstractions.
Sure, a FEW features of the C++ language do introduce an overhead. These are: virtual methods, and runtime type identification. But you can easily avoid them if this overhead is unacceptable for your program (in most cases where this overhead matters, templates can do the job at compile-time). Without using them, you can still enjoy most of the aspects of C++. I know I developed a whole C++ template library (Eigen) without using them at all.
Ada is better at OOP then any C++ out there and it compiler to native code.
Good for you. Fortunately, it’s still easy to do that sort of stuff, if a little verbose. There is a closure syntax under discussion for C++09, as well as a range-based for loop (i.e. foreach in certain other languages).
What changes do you propose for the template syntax? So far as debugging, C++09 improves that by leaps and bounds with the introduction of concepts and concept maps. Those are a way to provide a sort of type-checking to templates, somewhat similar in idea to interfaces but without locking users into a rigid class hierarchy (and allowing templates to still work with both native and user-defined data types that match a particular concept).
With the exception of automatic vs manual memory management, I’m not so sure I believe this line anymore. The only reason I’m ever able to do things quickly in Python/PHP/Java is because the standard library is huge and contains a bazillion functions and classes useful for a variety of things that C++ doesn’t. As soon as you drop in a nice utility library for C++ that includes things like HTTP/SMTP wrappers, a large assortment of string and vector utility functions, and so on, C++ makes it just as easy to do things as those other languages. Automatic memory management can even be had thanks to GCs like the Boehm GC.
There are clearly some cases where C++ still isn’t the best bet (text-file processing, where Perl is king, for example), but that’s just fine. No language is going to do EVERYTHING perfectly. That’s why we have multiple languages. Use Perl for what Perl is good for, use Python for what Python is good for, use C++ for what C++ is good for, etc.
There’s nothing worse among programmers than being a “one trick pony” (a programmer who is only proficient in one language).
I never expected to see so many passionate comments against C++… I’m not joking, I always thought that programmers really liked it.
I, for one, fell pretty comfortable with it, but most of the times it depends on the framework/libs/toolkits I’m using. Some of them are great (QT) and some of them really suck (no examples, I’m not in the mood for a flamewar).
BTW, I also use Ruby, PHP, plain good old C, and a handful of other languages. For me, languages are simple tools, some of them more suited for certain tasks than others, that’s all.
I am so damn tired of people uploading interlaced video to the web without de-interlacing it first.
Sorry, had to say it. Mod me down, I don’t care
You take the blue pill, the story ends and you wake up believing whatever you want to believe. You take the red pill, you stay in wonderland and i show you just how deep the rabbit hole goes.
blue pill:= C++
red pill:= D
The whole thing boils down to whether you want to keep link compatibility with C++ (I said C++, not C) and chain yourself or loose it and free yourself.
About the negative views, maybe it has to do with the extensive delays when something becomes popular. For a long time, C++ was on top. What did people do during all that if they didn’t like it? And now with Java, how many people hate it? And right now, I don’t dislike MS as much as I used to and more people nowadays don’t even know who they are. Before that, IBM was truly hated. This is just an opinion, but I think the perceived lockin of things that are too popular angers a lot of people (or the lack of choice).
About C++, I still want properties and named parameters for functions, objects and templates. But Bjarne says no way and will never put them in.
I’m very sad!
About C++, I still want properties and named parameters for functions, objects and templates. But Bjarne says no way and will never put them in.
I’m very sad!
And I must say I agree with him. Both issues can be solved as library solution. Here’s simple property code:
http://rafb.net/p/0N82yE26.html
Named parameters are mentioned in “C++ Template Metaprogramming: Concepts, Tools, and Techniques …”, Abrahams, Gurtovoy.
http://www.digitalmars.com/d/overview.html
Works on Windoze, OSX, Linux (GCD), dmd, … it has Wx (WxD)…
Perfect!
.V
I love C++. I’ve made a very good living as a contract programmer sorting out the utter messes that people create in this mongrel of a language, and now Bjarne is `crafting’ my meal-ticket right through to retirement !
Mr Stroustrup, you should have a Paypal link on your website. I definitely owe you a bung.
I would call myself fairly C++ knowledgeable and i use it often for user mode programming. But once i had to debug someone else’s code written in C++ and following were my horrors:
1. templates inside templates inside templates….Nested templates are the worst thing designed in C++
2. Operator overloading – While looking at the code, i really did not know whether a + is a function call that can throw or it is a simple addition.
3. Exception handling – It just makes large project so much harder to debug because you never know once an internal function throw, where the exception will get caught. And the handler that catches the exception usually doesn’t have any idea on what to do with it.
4. smart pointer type stuff – C++ doesn’t have garbage collection and people shouldn’t try to mimic that. With all the auto_ptr crap associated with nested templates, finding where and when an object leaks was a nightmare.
After this C++ experience, i became quite anit-complex-C++. I like some of the features it provides like data abstraction using classes etc but it is becoming increasingly complex.
For myself i only use following C++ features:
1. Basic C features
2. Classes
3. Derived classes with single inheritance or multiple inheritance rarely
4. Well design STL type templates
5. Virtual function where appropriate but not very often
The things i avoid like anything are:
1. Nested Templates (and in general all templates except STL)
2. Exception handling – I hate compiler unwinding the call stack etc. It is so much harder to debug.
3. auto_ptr style memory management – It is never right and when it is wrong, it is nightmare to maintain.
4. Operator overloading – I avoid it mostly but i know for some math related tasks it is nice. Use with caution…don’t overdo it. One person overloaded operator >> for sending data on socket and that is too much for me.
5. Crap stuff like virtual constructor etc etc and all the *extra smart* C++ receipes available in some books.
And yeah, if you really want to know how twisted C++ can be, read Effective C++ series. After reading that i realized how complex C++ can get and how to never get in that trap.
Edited 2007-08-14 02:03
Nice to see that someone agrees with me… I’ve been saying this for years, taking the flames. If you need/want a more powerful language than C++, go for it but don’t complain when you can’t twiddle bits fast or access your system as easily.
Why is it better to write 5 lines of code instead of 25, if:
– it can’t be read or maintained even by me
– portability is shaky
– if it doesn’t compile, it’s easier to switch to the 25 line version than figure out why
– if it doesn’t work, it really can’t be debugged
– it takes just as long to write and longer to compile.
I do use templates, but I don’t nest them; I throw exceptions, but very rarely out of a function; I’m leery of auto_ptr-type things I didn’t write; and banning boost from production code was worth it for the saved research time alone.
I call this method “Aim low and SHIP!” and it’s served several companies (and me) very well.
‘depressing’
I took a look at the web site. It’s not a language design, it’s a buffet of features based on the idiosyncratic tastes of the authors.
C is, perhaps, the best language ever designed. That is to say, it is the closest to doing what its designer intended of any language I’ve every used, and I’ve used a few dozen languages over the years.
C++ is an abomination. It was a poor attempt to graft classes onto C that grew like Topsy, and the one thing it doesn’t need is more growing. Were it not for Koenig’s idea of using C++ as a ‘safer C’, the language would be unusable.
Java is just like C++, only different.
I wholly agree about this (the ‘D’ part). I was hoping for something innovative and ended up disappointed.
Case in point is the massive number of keywords.
It’s more a language expansion than a new refactored language. Smorgasboard it is.
What can be done to “expand” c++ is also limited as is. It seems writing a fully compliant compiler is a daunting task.
c++ is not totally an abomination. Strict discipline and having smart policies for what should and shouldn’t be used are needed. It can be fairly expressive and powerful.
c++ was a proving ground for a lot of good technologies, especially efficient generics. The implementation has been somewhat wanting in some areas.
I seriously doubt much more can be done with the current c++ framework. Time for a new, better, smarter ‘c’ offspring. Maybe ‘d lite’ or something.
Edited 2007-08-14 03:51 UTC
… every problem looks like a nail.
This applies to many C++ programmers — they use C++ for (almost) everything, even when it is not appropriate. C++ has its uses, but they are few. For low-level OS stuff, plain C is better (it is more predictable, and objects don’t really have much use in low-level OS code) and for programming complex systems, SML, OCaml, Haskell and C# are far better.
Don’t you wish your mail program and web browser was made in a language where buffer overflows can’t happen? Do you see any reason these need to be programmed in a close-to-the-iron programming model? Before you say “performance”, please look at the figures: Once you get to something more complex than micro-benchmarks, SML (using the MLTon compiler) and OCaml produce code that matches typical C++ for performance.
As for C++ syntax and semantics, my main gripe is with the syntax. As far as I know, no C++ parser is fully compliant with the standard (which gives informal disambiguation rules instead of an unambiguous grammar). This is not only a problem for compiler writers, it is also a problem for programmers: If the syntax is so complex, there is a good chance that even programmers can’t read or write code correctly, and you risk that different compilers parse the same code differently.
Lack of runtime bounds checks, manual memory management etc. bothers me less. It allows the programmer close control over what code is generated, which is good when it is really needed. It rarely is, though, and few programmers understand C++ well enough to really do it (once they go outside the plain C core of C++).
C++ is not a language. C++ is something about four programming languages, each with it’s own syntax, each with it’s own ideology, each one of the designed to solve a scope of problems, slapped together with no coherent vision whatsoever.
Let’s see. In C++ we have:
C
Macros
object oriented additions to C
Templates
While I really like C (with all it’s problems and catches), there is no gain for me in using C++ over C. The additional effort I have when using ‘proper C++’ weights far more then the gains. Not to mention the problems with the ABI that still exist as of 2007.
For low-level problems I use C. For rapid-prototyping I use Python. For high-level problems I use Java (or C#).
Now D, however… It is everything C++ should have been: Object orientation, Garbage collection, Generics, Collection-iterators (foreach). And while D gives me all the sweets of a managed language like Jave or C#, it actually compiles to native machine code. Yay! Compatibility to C. Yay!
I don’t see no need in riding a dying horse. Why try to correct all the mistakes made in C++ when there is a worthy successor ready?
By the way; the gdc-package for Debian should be available in unstable as of yesterday, I think.
Edited 2007-08-14 08:10
Pfeifer,
you have Object orientation in C++ too, you can have garbage collection, you have generics (templates), you can have foreach**.
In short, all you’ve listed from D is available in C++ as well. Tell me again why should I use D?
** http://www.boost.org/doc/html/foreach.html
Edited 2007-08-14 08:26
falemagn,
all those things (with the exception of object-orientation) are not part of the C++ core. Some of the features I mentioned are available for C++, yes. But only through hacks, not as a coherent part of the language.
Maybe I didn’t make it very clear in my first post; I don’t like C++ because it consists of four (five if you need IDL) different programming languages, all forced together with a big roll of duct tape.
Providing core features of a programming language through third-party “addons” is not going to help. Even Stroustrup realizes this and tries to push C++ forward (see tfa).
D gives you binary compatibility to C (and thus access to all your old C libraries), gives you real interface definitions, includes (optional) garbage collection, a versatile collection iterator, generics/templates, all roled into one coherent language, one concept.
But D is ready. C++09 will arrive 2009. Why wait when you can have D now?
They are not part of “the core” because they don’t need to be part of the core: as shown, they can be implemented in libraries. That’s not an hack, that’s how it’s supposed to be.
If you want those features, just use them, no one is stopping you: they’re already implemented, tested and well working.
Would it turn out to be C++ then? It is like Linux 1.0 which is very fast and snappy. Then you start to add functions and suddenly it is getting big and slow. Would this apply to D as well?
I think that C++ is an abomination. You can do some very complex things in it, but that takes years of practice. Why not turn to a simpler language that allows you to do those complex things in a simple way then?
I heard that it took years before a C++ compiler came that could compile ANSI C++. And still C++ compilers have problems following ANSI? How complex is C++ then? Jesus. And if C++ dies, you have spent much time learning those weird C++ things that gets useless in other languages. You have wasted your time.
“Then you start to add functions and suddenly it is getting big and slow.”
Actually, that’s one of the things C++ doesn’t suffer from. (unless you by “slow” means the evolution of the language). C++ does a pretty good job of making sure you don’t pay for features you don’t use.
There have been a million similar discussions on the net C vs C++ vs Java, etc. Programming language is a tool and you need better tools to create more complex software. Programmers have been using the same old tools for decades and the quality of software they create is abysmal. New languages/methodologies need to reflect the fact that the future systems need to support fine grained multithreading if they are to effectively utilise multicore CPUs with UMA or NUMA hardware configurations. Parallel programming is a difficult challenge and the current programming languages are not suited for such tasks.
“Next generation C++” sounds like a farce to me. I think in order to get the optimal performance and rigidity, the hardware, system software and development tools, need to be designed as a unity, with references to one another. Creating a programming language in near vacuum will not achieve the flexibility required for high-performance, reliable and complex software.
Parallel programming you say. Let’s see: OpenMP auto-parallelization works with C/C++/Fortran (yes, Fortran!). Intel’s new TBB library (low level lock-free/fine grained locks algorithms and data structures) works with C++. SIMD (SSE, 3dNow, AltiVec) based parallelization — languages with inline assembly: C/C++. Doesn’t sound like farce to me.
C was like DOS: Broken, flawed, and an smashing success.
C++ was like Windows 95: Backwards compatible with its predecessor but for the same reason ugly, overcomplex and full of gotchas.
Ada was like OS/2: A superior alternative to its competitor but not backwards compatible. Not a bad choice from a technical standpoint but pretty much dead by now.
Objective C was like a Mac: A world of its own. Pretty nice, but nobody notices.
Java was like Unix: Ubiquitous, fairly well engineered, well entrenched in the big corps, will be around forever.
C# was like Windows XP: a clean room implementation of already done ideas that somehow managed to coexist with its predecessors while gradually eating them.
C++09 is like Windows ME: C++ with bells and whistles, fixes none of the glaring problems with its predecessor piling even more shit on top of it instead.
No wonder people are running away from the sinking ship that’s C++09 and looking alternatives such as D.
What does he know about C++?!?
Okay … maybe he does know a thing or two about the subject… ;-p
(whoever modded me down, apparently you have no sense of humor)
Edited 2007-08-14 22:03