a three lines program generates 95 lines of error messages; let's throw a template into it, so that it goes up to 112 lines, but look: at the beginning you'll see the error we added!
coupled with the: "To be fair, this doesn't entirely replace decltype. auto doesn't perfect forward. But it seems to work as expected, most of the time" it goes a great way to instil me a sense of safety.
not.
that post should be taken as an example of why C++ has become a liability, and the day won't come too soon when this joke on the whole industry finally gets dumped like COBOL in the nearest ditch, along with the corpses of all the projects that made the mistake of actually using it.
if it were a living thing, I'd shoot C++ in the face to put it out of its misery.
I don't get all this C++ hate from people that has never even used it.
Personally I want a better C and C++ satisfies most of what I want.
1. Type level polymorphism (generics/templates/etc)
2. Easier ways to manage memory (constructors/destructors, auto/shared pointers)
3. A modules system (namespaces)
4. Lambdas, etc to make life easier (C++11)
5. A standard library with useful data structures
6. Fast
It seems all to me all these haters still think that C++ is just C with classes, but C++ is a fairly vast language and OOP is just a small part.
C++ is blazing fast, it has an elegant standard library and templates do make sense if you know what you are doing.
You are trying to use cutting edge features that aren't properly standardised yet and complain that the error message is a bit long? Granted, template error messages aren't always the one liner you are expecting, but they are readable.
> I don't get all this C++ hate from people that has never even used it.
wrong. I use it every day, on a fairly large code base.
obviously, for portability reasons, nobody working on the project is allowed to even think about C++11, as well as other headache-inducing features - and that includes a fair chunk of the standard library.
> a three lines program generates 95 lines of error messages; let's throw a template into it, so that it goes up to 112 lines, but look: at the beginning you'll see the error we added!
95 lines of error messages sounds terrible, no doubt. But which language is better in the real world? I am currently consuming a JSON web service written in Java, and I get no less than 30kb of stack trace back when something blows up. Rails' stack traces are filtered by default, but sometimes you still have to jump in there.
And C++ has the advantage that much of this can happen at compile-time.
I agree that almost everything about C++ is broken, but the verbosity of error messages is the smallest of it IMHO.
I read that blog a bit and it seems to have the following pattern overall: elegant 5-line Haskell program. Then follows 100-line unreadable C++ implementation.
My conclusion is that C++ is a very bad language to try to do Haskell :-)
This doesn't mean that C++ doesn't have its uses, but for your sanity's sake don't use it for high-level metaprogramming.
The issue you describe is more a compiler-specific issue than a language specific issue. Yes, the language allows a lot of flexibility and therefor in some situations it's hard to nail down an error to a nice, specific error message (mostly when templates are involved), but it's not impossible, as clang++ shows.
Believe it or not, there are people (like me) who actually enjoy coding in C++.
It's a language specific issue. Sure clang++ has improved error reporting and GCC is actually quickly catching up. But the problem is a language issue because an error in a template confronts you with implementation details of the template. There is nothing the compiler can do about it.
Clang is not the solution. Yes it has some better error messages. Although GCC is quickly catching up.
But it can't solve the core problem. It's simply the language. The lack of Concepts (or something similar) means that error messages simply refer to implementation internals of the Template you are using. Easily giving you a long cascade of error messages when it's in some Template that is used by the Template.
All of the sudden you have to look at implementation details of your standard library or something even worse such as boost. Just to figure out what the mistake was.
And there is nothing Clang or GCC can do about it.
It's roughly the same as the improved GCC error message ("index out of range"), but with only 29 extra lines of incomprehensible compiler meandering and stdlib internals!
What many people don't understand is that C++ has at least two target audiences: (1) people writing low level libraries using templates and other esoteric stuff; and (2) people writing application code. (1) is needed because C++ is a language that can target multiple environments and operating systems. The template craziness is necessary to make the system fast and easy to use for application developers. If you are writing applications, however, you should try to use only bread and butter features, along with standard libraries such as STL and semi-standard stuff like Qt. Once you understand this, your life will be much easier with C++.
I was just about to make a similar comment. There isn't much about C++98 I don't know, but having ignored C++11 for too long I feel utterly lost looking at stuff like this now.
What concerns me even more is that it must be pretty much impossible for a beginner to pick up C++ today.
> What concerns me even more is that it must be pretty much impossible for a beginner to pick up C++ today.
There certainly are issues when learning C++. But I don't think it's impossible. A major concern is the fact that there was never a centralised website collecting good information and filtering out the crap. There never was a central Tutorial or Reference.
All the knowledge is hidden in very expensive books and worst of all there are many publishers simply spitting out piles of bad C++ books.
Stroustrup's book is a great introduction: http://www.stroustrup.com/Programming/ I wish he'd made it freely available. A lot of programming beginners aren't happy to pay $50-$70 for a book when they can go to other languages offering great beginner tutorials for free.
And C++11 is pretty new. So of course there is a transition period with books, articles, references catching on.
As a beginner programmer (a.k.a. CS student) I was able to pickup the basic of the language in the last 2 months and work on a real world (not a school project, it's a library that other universities use) cuda c++ project. I read a book so I have an idea of what can and can't be done, but when I need to implement something unusual (ie function object) I need to lookup it in the book or ask for help to my mentor. I still need help to understand gcc errors, cuda uses an "old" version (3.4 I think) so we don't get the improvements of the new versions.
I'm not sure that's needed. It would be much better if parts of it are replaced by different languages (and that's exactly what's happening)
haskell, python, erlang, clojure, scala, d, go, lua… take the tasks one by one. the glue is C (but something like llvm-assembly might take it's place eventually)
A language able to do multi-paradigm programming while giving the ability to do low level stuff as well as high level programming, while compiling to native code.
I really miss the ability to compile to native code in most implementations for mainstream languages nowadays.
I am looking forward to D and Rust, but it will take ages before any of them really get into mainstream.
True, but it is one specific case and not multi-platform (Mono does not run everywhere where C++ does).
If you need to make C# work in all scenarios C++ is used, then a compiler with static linkage is also required for scenarios where deploying CLR is not possible. A compiler like Bartok.
Specially if you would like to replace C++ everywhere where it is being used.
So I've learned to make use of "Worse is better" philosophy and keep using C++ for my native code needs.
Can you give specific use cases? Obviously there are some things that need e.g. manual memory management, but my instinct is that situations where you need to have the same module do both that and use high-level C++ features are vanishingly rare. So I'd be inclined to replace C++ with C in a few cases and a high-level languages in other cases.
Maybe. I'm currently playing lots of Kerbal Space Program, and didn't even realise it was written in C# (well, I noticed how hot it makes my laptop).
I can see for something like an FPS engine you'd want as much performance as possible, but doesn't that mean C (and increasingly CUDA and friends)? Similarly big physics number-crunching tends to be in fortran, sometimes with python to glue it together.
- Systems programming
As in kernels? Linux famously uses pure C.
- Compiler development
Does that need to be C++? I believe most if not all of the Java compiler is written in Java.
- Being able to deliver an application without depending on a VM
Why would that ever be a requirement? What's the difference between a VM and a runtime library (which even C has)?
C++ might sometimes be the best choice, but I don't think it's the only option for any of these cases.
Haiku is written in C++ because BeOS 5 was written in C++, using the GCC-2.95 compiler. BeOS used C++ because when it was written, C++ was the new trendy OOP language. They use GCC-2.95 because the GCC 2.96 compiler was badly broken and GCC 3.x changed the ABI. The dialect of C++ supported by GCC-2.95 is based on extensions to C++98 that were rather quite buggy. It's a bit of a mess, and I would hardly hold it up as a positive example of C++ in use.
Similarly, Windows was written primarily in C, as it predated C++. Their compiler was extremely buggy and had only partial support of features in C++98, so the vast majority of the code in Windows is C with Classes. (Unless there's been a lot of rewritten code in the last 15 years or so.) Again, not exactly a positive example.
You know when you get in a really fancy sports car and sit down and look at the console and go "What the fuck?" as your brain tries to parse the myriad of options relating to everything that are usually highly non-intuitive and often buried under many layers of cruft and you need to sit and read the manual that's as thick as a phone book? That's kind of what C++ is getting towards.
There's a simple solution, don't touch all the fancy and extreme language features, use the core, keep your sanity. I code in C++ professionally using Qt, the last time I wrote any code using anything overly fancy was probably when I was in University. It's often not needed, it's guaranteed to make your code base a nightmare, and it's usually horrid to read back over. If you're sensible and put some constraints on what you're doing C++ is a great language choice, but often people stray into using all these areas of C++ that basically make the code an unmaintainable mess.
(note, defining core as the things guaranteed to work on 95%+ of current compilers, if it's non-standard I would really, really thing twice about using it)
Coverity, maker of c++ static analysis software, and where I used to work, has published a paper about their experience trying to parse customer code. It turns out that 'The language people code in? The strings their compiler accepts'
So yes, it is quite common to use syntax not available in other compilers. Most code is vetted against only one compiler to begin with.
Do you use EDG or another frontend? I can only assume that parsing C++ is quite problematic especially with all those compiler extensions and the current transition to C++11.
This particular feature isn't offered by anyone else, so I would not write a program with it and force anyone else who wanted to compile the code to use an unsupported, bleeding edge version of GCC. But I /will/ create a branch of a project or two, using this auto deduction, and send bug reports back if necessary.
I, and many others, have been writing code in Clang and GCC for years that could not be compiled in MSVC. But that code was standard c++11. This is experimental and people should be aware of that while using it.
In my (limited) experience, it is not that popular, compared to the use of semantics not available elsewhere (is char signed? Can you cast a void* to int and back without data loss? What happens when you right shift a signed int? etc) and to the extreme use of third party libraries (why the #%$! do I need that GUI library in this json parser? Half an hour later: oh, so it is only for these three typedefs, a few macros, and this convenience debugging function), but it surely does happen.
I also think programmers do regret the decision. Unfortunately, that is unlikely to change, as the programmers regretting the decision almost always are not the ones who wrote the software. It is way rarer for a code base to move compilers within a project/team than for a team wanting to incorporate a third party library into their codebase/compiler.
It depends on your environment. If you completely control all the environments your application is deployed in (for example, when you provide a SaaS), it's fairly common.
I wonder how many times programmers are even aware that they're using syntax not available in other compilers. I remember the first time I used a non-gcc C compiler and was greatly surprised that things I'd taken for granted and simply assumed was 'C' didn't work.
coupled with the: "To be fair, this doesn't entirely replace decltype. auto doesn't perfect forward. But it seems to work as expected, most of the time" it goes a great way to instil me a sense of safety.
not.
that post should be taken as an example of why C++ has become a liability, and the day won't come too soon when this joke on the whole industry finally gets dumped like COBOL in the nearest ditch, along with the corpses of all the projects that made the mistake of actually using it.
if it were a living thing, I'd shoot C++ in the face to put it out of its misery.