As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm learning C++ and the book I'm reading (The C++ Programming Language) says to not reinvent the wheel, to rely on the standard libraries. In C, I often end up creating a linked list, and link list iteration over and over again (maybe I'm doing that wrong not sure), so the ideas of containers available in C++, and strings, and algorithms really appeal to me. However I have read a little online, and heard some criticisms from my friends and coworkers about STL, so I thought I maybe I'd pick some brains here.
What are some best practices for using STL, and what lessons have you learned about STL?
There is a companion book to the Effective C++ series, which is called "Effective STL". It's a good starting point for learning about best practises using the Standard C++ library (neé STL).
You might want to pick up a copy of "Effective C++: 50 Specific Ways to Improve Your Programs and Design (2nd Edition)":
http://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0201924889
I've found it to be invaluable, and it's still very relevant today, even if you aren't programming in C++.
If you really want to learn the C++ Standard Library (which includes things like strings, which have not traditionally been seen as part of the STL), you need a good book. The best one in this area is "The C++ Standard Library" by Nicolai Jossutis.
The only cases I can think of off the top of my head when the SC++L is not appropriate to use are some rare situations in which either a proper implementation is not provided (perhaps you're working on some obscure platform for which only limited C++ compilers have implemented) or extreme performance is required (perhaps for code that exists at the core of a graphics rendering system for next-generation games).
If you're using an ordinary computer, it's 99% certain that you're not in the first case. As for the second case, you should absolutely only consider implementing your own set of containers and algorithms for performance reasons if you have definitive evidence from good profiling tools that the bottleneck in your program is the SC++L.
The best practice regarding the SC++L is to simply use it whenever possible. In addition, almost all modern C++ code makes heavy use of Boost, which you can think of as an excellent and massive extension to the SC++L. Whenever you find yourself wanting to do a fairly standard algorithmic task, you should use Google to see if either the SC++L or Boost provide premade, tested, proven facilities for accomplishing this task.
Why don't you tell us those criticisms, and we'll respond? If the criticisms are valid, we'll tell you that. And if they're not, we'll tell you why not.
The STL has a mixed history, because initially, 1) few people understood it, and 2) few compilers implemented it correctly. But that was a decade ago. Today? It works. It's efficient. It solves a lot of problems. The biggest problem with it is that it takes some time to wrap your head around how it works.
The simplest best practice is "Use the STL whenever it offers functionality that you need".
And it's hard to offer more specific advice unless we know what criticisms it's up against.
But in general, it's typically the case that people who criticize it are simply not C++ programmers. C programmers who have learned to use classes fall into this category.
The STL was written by the best brains. You probably won't come up with better implementation than that in most cases.
Its performance is good, it's bug free, and it's a good standard for passing parameters between methods, APIs, code components, and needless to say, it encapsulates all the ugly stuff.
The thing is, you have to know how to choose the right container for your problem. Otherwise, you might not enjoy its benefits.
There are some articles on the web regarding how to pick the right STL container.
One good link is: STL Containers
, and it has a nice flow chart of how to pick your container.
You should understand the concept of template, and other polymorphism, in order to efficiently use the STL.
to learn about STL you need to understand templates and also you should be good in data structures.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Opinion-based Update the question so it can be answered with facts and citations by editing this post.
I don't know much about C++ data structures but I am wondering do you (programmers) use STL or write your own code? After all STL is designed for doing tasks like searching, replacing and much more through a list of data.
Someone really don't need to learn much about the linked list, binary search and many more because I could use STL. What would you suggest?
You should use STL, because it is well tested and optimized.
That doesn't mean you shouldn't know how to write these data structures yourself. With that ability under your belt, you will be able to choose the best STL data structure for your application.
While the Standard Template Library is convenient when it comes to performing tasks as you mentioned like Searching, Replacing, using Linked Lists, it should not replace the knowledge of what is going on inside of the Library.
You mentioned not needing to learn about linked lists, binary searches and "many more", however you should have at least a working knowledge of how these Data Structures and procedures work as it will make using them (and knowing when to use them) much more effective.
Basically - you don't have to reinvent the wheel, but at least know what makes the wheels effectively turn.
Use STL and standard libraries in general when you can. First it is probably way better tested than your own code, and second it helps keep your code portable. The only time you should rewrite any of this functionality is for learning purposes. It may be educational to write your own associative map or linked list, but for production code, stick with well tested and standard compliant code.
A working knowledge of the underlying data structures, methods and applications of the tools provided by the STL will make you a much better programmer. Knowing when to use what container type, or which algorithm is as important as a proper implementation. Sometimes, the easiest way to understand some of the more complex concepts is to implement them yourself in the context of a data structures and algorithms class.
That said, the code in the STL has been written by experts and refined over time into a standard library that is used my millions of people world wide. In practicality, there is almost never a reason to "roll your own" except for extreme cases where performance (or size) matter to a point that is critical for your exact application.
I hesitate to write, since I haven't written C++ in 5 years. But a couple of things came to mind that haven't been discussed yet.
If the implementation is a bad fit for what you need, don't use it if you can write and test your own easier than using the library. I recently ran into this in Java, where I needed a fast bitset. Details:: There are two relevant classes in the JVM (BitSet and BigInteger). BitSet doesn't support initialization other than by setting one bit at a time; BigInteger has an irrelevant signum that confused things, and is immutable, which is costly in my case. I ended up writing my own, with tests, in a few hours. It fits better, is faster, and I can do whatever I want to it.
The other reason to write your own is if you don't understand the specification of the library implementation relative to your requirements, can't easily test it or read it to figure out what it does, and can easily roll your own. This is/was a particular problem with STL implementations that are (or at least used to be) shipped with terse, inadequate, cryptic documentation and commentless, opaque source code that rolls over your head like a huge rogue wave.
Just to add my answer (from comment above):
Yes you should think about implementing e.g. a sequence, a linked list, using your own code.
This is what they teach on Comp Sci courses and it is not without good reason. But, if you're looking to work quickly then just use STL.
I just think people should understand how the tools really work.
I use the C/C++ Standard library and STL because it is a really big time saver and I don't see the need to reinvent the wheel. I also use boost where I can.
It is still a good learning exercise to write your own container class and algorithms.
Use STL unless you have a compelling reason, e.g. speed or correctness, not to. Definitely know how to write basic data structures on your own.
In general you should use STL or Boost containers because of their effectiveness and reliability. Still you need to have a corresponding world view on existing containers. You should know its con and pros. Studying of the container internal structure and working principles allows you to reach better understanding.
STL is well tested and reliable but it is not the fastest solution. Some of the containers allocate a lot of small memory blocks rather than one big block. If you really have a speed problem then you may consider making your own fixed-size list. But for many purposes STL is the standard solution.
Very smart people wrote the STL. Then more very smart people have used it, tested it, and refined it. You think you are going to do better? Rarely. It is a great tool; you should use it whenever possible!
Write low-level stuff yourself when learning/playing, but at work use code that was written and refined by experts over years, and has/is being tested by thousands of engineers in thousands of different conditions.
In other words, use your code only if your code can beat the other codes!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
C++ introduces OOPS, templates and variety of other concepts. But sometimes I am stuck in unmanageable storm of calling convention incompatibilities between methods, convoluted casting between distantly connected classes and struggling with code that forces me think in the level of byte-alignment.
I am very tempted to go back to plain old-C language that is low level enough and simple enough that I can spend much of my time solving a problem at hand, than having to figure out the conceptual implementation and nuances of using C++.
What is your take on such an issue. Using C-language as the first class citizen in my code-base and coating it at the end with a C++ primer make for a better way to manage a conceptual code-base ??
sometimes I am stuck in unmanageable storm of calling convention incompatibilities between methods, convoluted casting between distantly connected classes and struggling with code that forces me think in the level of byte-alignment.
It sounds like you might be doing something wrong. I don't know what sorts of projects you work on, but I've rarely had to deal with any of those things--certainly never in over 99.9% of the code I've written--and I've written a bit of C++ code (though not nearly as much as others here on StackOverflow).
What is your take on such an issue.
You should consider getting a good book on C++ (like one of the introductory books or any of the best practices books listed in The Definitive C++ Book Guide and List) and really learn C++ if you want to use C++.
I often feel the way you do. C++ compilers are incredibly bitchy about insignificant details and, if you considered them an object, they have appalling encapsulation, and they give horrendously bad error messages. Sometimes, programming C++ feels like fighting against the Standard.
However, I'd never, ever ditch it for C. If you're considering it, you fail C++. Yes, templates and their syntax and some of their semantics can be a bitch, but the power they offer is unparalleled. The things offered like automatic memory management and the power of the STL just can't be matched by C.
In addition, nobody is forcing you to use templates. You could write a whole C++ program using nothing but the pre-provided templates. You could never use polymorphism, or templates, or encapsulation, or object-orientation as a whole, and yes, sometimes none of those solutions are appropriate. But it's plain stupid not to give yourself the option.
And if you're casting classes in C++ (frequently), it sounds to me like whoever wrote the original code flat out didn't know what they were doing. Same for byte alignment.
I've never had to worry about byte alignment unless I was writing binary files.
Casting distantly related classes to each other is bad design.
I've never worried about calling conventions unless I was writing interrupt routines.
If you forced to frequently "cast distantly connected classes" and "think in the level of byte-alignment" - there is something wrong with the architecture of the project. Language is not the problem here.
C++ is heavy. You probably should not use all the features it provides. KISS principle, you know.
You can always pretend that C++ is just "C with classes" and exploit templates and other "hard" stuff only when it will provide reasonable improvement in some areas (like code simplicity, as a matter of fact).
I recently switched back from C++ to C and took a liking in C99. But it certainly depends on what you are doing. For a library of reasonable size, C99 with its advantages over C89, is good enough, and as somebody else said you can easily provide a C++ wrapper, if necessary. C++, I only would go for a big project that has large amount of code reuse (internal or external) with templates.
Things from C++ I missed in C89 have nothing to do with objects or so, but are simple things as declaration of variables inside the for and a well defined inline feature. C99 has that plus variable length arguments for macros, so I am happy with it.
You are not alone. These are all well-known flaws in C++, a language which forces developers to attend incompatible conventions, to struggle to overcome a convoluted caste system, and to take their code in for byte-realignment every 3,000 lines. Definitely switch back to C.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
My teacher for Advanced C++ has opened the class up for students to suggest whatever topics we want. What are some good advanced C++ topics to know? We've already covered:
template metaprogramming
the STL (obviously)
introduction to the boost libraries
Please give reasons for suggestions as well.
1) Exception Safety + RAII. Because this is the part where I find C++ very different from other languages I know. It is easier to do exception handling in C++ if you understand the rules and why they are set that way they are, especially how to benefit from RAII when doing exception handling.
2) Introduction to C++0x. Because I can't wait any more the fourth edition of The C++ Programming Language ;) If you have the chance to learn some useful facilities you would be ready for the transition.
Concurrency. Most students don't cover this and it's a growing necessity in modern computing, as they get more CPUs.
Consequences of C++ design on C++ compilers
related: failure of the export keyword and why no one implements it
Custom allocators
placement new/delete and when you actually want to use them
Design of a C++ garbage collector
Also, if you only started out with C++ and did not come from pure C, it might be worth going in a low level direction rather than a high level direction:
Understanding the proper use of 'volatile'
linking C++ with other languages (ie calling java or fortran from C++ or vice versa)
performance analysis and tuning of code
I would say lambda, either in boost or in C++ 0x. this is not something people will find on their own most likely, but I think it allows to reduce code and maintenance significantly.
Plus changes the way you look at programming in certain way. moreover, it gives solid introduction to functional programming.
for example, you can sort collection very concisely using some weird requirement:
std:: sort(begin, end, lambda::_1 + lambda::_2 > 0);
I would also add template expressions. I am currently playing with them, they are powerful tool to produce very efficient code while maintaining very close resemblance to problem description. plus, I do not think any other language has similar facilities. http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Expression-template
Concurrency and thread management?
Some cases studies from GOTW
How much of template metaprogramming have you done? This deserves a full course, so if it ignited your imagination you might want to dig into that farther. Diving deep into template programming will get you a long long way into modern C++ programming.
Patterns, real application building, app architecture design, etc. Everything else (you mentioned boost libraries, STL, etc) can be easily discovered while self-educating, but good and rational design is much harder to learn.
It wasn't clear if this was covered in your existing knowledge, so a few "advanced basics" are noteworthy:
Multiple inheritance
Polymorphism
Operator Overloading
Advanced Streams, creating custom streams
Socket programming
and possibly GUI programming although most likely this is a separate course altogether.
C++ concepts, which if eventually adopted, will make it possible to typecheck templates and to get sensible error messages. You could study recent papers by Jeremy Siek and by Gabriel Dos Passos and Bjarne Stroustrup.
Creating a COW (Copy On Write) String class ?
Reflection and RTTI.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have tried to keep up with C++ since they introduced 1998 ANSI/ISO C++. I absorbed the new concepts and tried to understand them. I learned about exception handling, templates, and namespaces. I've read about the new cast mechanisms and worked with the STL library.
All of these concepts required a lot of energy. But now I am somewhat worried about the future of C++ when having a look at the new C++0x standard.
Things are getting more and more complicated. This language is becoming a monster.
I'm not sure that I want to keep up with the language anymore, since I don't do my day-to-day hacking in C++ anyway. I mostly use interpreted or bytecode languages.
So why should I bother to learn this difficult, yet exceptionally powerful, language? I can do 95% of my business with Python et al. With the remaining 5%, I can deal with plain old C++ or C without hassle.
What do you think?
Everyone uses a subset of C++. For almost all application programming in C++, whether server or client side, that subset is manageable. In my opinion, the only folks that need to stay on top of absolutely every nuance of the language are the library writers -- people implementing Boost, STL, Loki, etc.
But I would absolutely use the language that fits the task. If Python is more readable and more maintainable than C++ for your job, and you don't need what C++ offers, then certainly stick with Python.
Hear what Bruce Eckel { author of the two of the so-called best C++ books } commented on C++ a few weeks ago:
That said, I hardly ever use C++
anymore. When I do, it's either
examining legacy code, or to write
performance-critical sections,
typically as small as possible to be
called from other code (my preferred
approach is to quickly write an app in
Python, then profile it and if
necessary improve performance by
calling small portions of C++ using
Python's ctypes library).
Because I was on the C++ Standards
Committee, I saw these decisions being
made. They were all extremely
carefully considered, far more so than
many of the decisions made in Java.
However, as people have rightly
pointed out, the resulting language
was complicated and painful to use and
full of weird rules that I forget as
soon as I'm away from it for a little
while -- and I figured out those rules
from first principles while I wrote
books, not just by memorizing them.
Additionally, you should read this thread and Danny Kalev's predictions on C++.
However, the growing complexity of C++ will create pressure towards splitting the language into quasi-official dialects. We can already see this trend today; it will probably intensify in the future.
EDIT:
You should take a look at this discussion, too:
C++ - Anyone else feel like C++ is getting too complicated?
First, many features of C++0x are to make the language easier to use. More readable template compile errors, more consistent initialization syntax, support for threading, which would otherwise have to rely on platform-specific libraries and so on.
So if you do use C++, I feel learning the important parts of C++0x should be a manageable task. Remember that you don't need to learn all the new features to use the language. Some features are primarily added as an aid for library implementers, for example allowing the STL to be implemented more efficiently, but which shouldn't really affect the end-users usage of the language. And some are only really necessary in very rare cases. Ignore those parts of the language.
One of their stated goals with C++0x is to avoid it becoming harder to use.
But apart from that, do you need C++? If you do your coding in other languages, why bother keeping up with C++?
You're not forced to use every feature a language provides. I don't use setjmp/longjmp in C despite it being there. I also don't use every aspect of the Java collections.
If you think the new features will make your code delivery better (faster or higher quality or both), then use them. Otherwise ignore them.
It's useful to know at a high level what they all are, if only to get you through job interviews, but half the stuff they add to languages are unnecessary in my opinion.
I never even got around to using C++ templates before switching to Java, but I knew what they were for.
It's not always about learning the latest and greatest. Software (at least at your job) is about delivery of product. That can be done in COBOL or FORTRAN if you're proficient enough at it.
No one, except maybe Bjarne and Herb Sutter, know all of C++. As you've said it's an incredibly huge language. Expecting to be able to take the entire standard + the specific implementation details of your specific compiler or compilers is truthfully unrealistic.
But you don't need to know everything in order to use C++. Instead only learn the subset of C++ that is valuable to you and your projects. It doesn't hurt to keep expanding your knowledge but unless you're writing a C++ compiler, there's no reason to know the whole thing. Even if you accomplish it, all of the people you work with won't.
So why should I bother to learn this
difficult, yet exceptionally powerful,
language? I can do 95% of my business
with python et al. With the remaining
5%, I can deal with plain old C++ or C
without hassle.
Well, for the most part you answer your own question. There is no need for you to keep up with the bleeding edge of C++ at this time.
However, the language will keep marching on. In a few years, some of the concepts you consider a bleeding-edge waste of time today will be in common use. Someday you may find during your 5% of using "plain-old C++" that some example code or code you're collaborating on uses a construct you're not familiar with. At that point, you'll need to hit the net and brush up on the new "current" C++.
Is that going to be a problem? Of course not. You're a programmer. You keep abreast of the latest programming concepts in the context of your 95% language, which also changes over time. You will likely already be quite familiar with the concepts and need only familiarize yourself with its C++ syntax when the time comes that you must use them.
Personally I hope to continue keeping up with C++, even if my career moves more toward Java or another next-gen language. Why? I would like to say because it interests me the most and because I love the complexity and expressiveness of it all. More likely, though, is just because it was my first professional language; I consider it my "native tongue".
If it does not interest you, and does not concern your job or future job, don't bother. What's wrong with that? Nothing.
Good answers.
Computer makers compete for buyers, software competes for your disk space, and languages compete for users. They do this by trying to snag each other's features.
I'm wondering how long before we see Fortran come out with lambda expressions :-)
I am hard-pressed to find a single instance where C++0x has been made more complex than C++98. There are two things which really are complex:
Concepts.
the Memory Model
but the first one has been removed again (thankfully; standardizing unimplemented features has never worked out in C++, witness throw specifications, extern templates, auto_ptr, ...), and the second isn't really something that a modern programming language can escape. It's been externally induced by Intel & Co helpfully breaking your programs to make them run faster.
The rest is just fixing annoyances that every C++ programmer has been frequently hitting in the last decades.
As a side note: I find it ... amusing ... to see how languages such as C# get packed with a database query language (LINQ) and C++ is objurgated as being bloated.
You don't need to know every standard that comes out by heart. It does help to know about the big picture though. The 5% that you do code in may have you reinvent the occasional wheel. Depending on how much time, importance that 5% has (think Pareto) you need to take a call.
Also, any particular reason (like legacy code dependency) why you can't move that 5% to python?
First try attending a course on c++0x and make your firm pay for that :)
Our brains can fit amazing amounts of junk-knowledge. Instead of cursing and having programmer-wtf-moments we should first learn from program users and listen to other people's opinions/knowhows. Knowledge transfers much faster that way.
My suggestion would be to learn the new keywords of c++0x ( && FTW) but not bother trying to learn the entire lib. Use python for w/e you want, possibly C# for apps, then use C++(0x) when you need to do something powerful. and ask stackoverflow & google about the new container when prototyping.
You dont need to use a select few language,
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I ran into this supposed interview of Bjarne Stroustrup, the inventor of C++.
http://artlung.com/smorgasborg/Invention_of_Cplusplus.shtml
Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would...
Interviewer: Yes, but C++ is basically a sound language.
Stroustrup: You really believe that, don't you? Have you ever sat down and worked on a C++ project? Here's what happens: First, I've put in enough pitfalls to make sure that only the most trivial projects will work first time. Take operator overloading. At the end of the project, almost every module has it, usually, because guys feel they really should do it, as it was in their training course. The same operator then means something totally different in every module. Try pulling that lot together, when you have a hundred or so modules. And as for data hiding, God, I sometimes can't help laughing when I hear about the problems companies have making their modules talk to each other.
Is this a hoax? Do any of these points seem true for any of the veteran C++ programmers out there?
You just have to check the Stroustrup's website (the FAQ part) to find that it's wrong - a well known hoax as Judah Himango already pointed :
Did you really give an interview to IEEE?
in which you confessed that C++ was
deliberately created as an awful
language for writing unmaintainable
code to increase programmers'
salaries? Of course not. Read the
real IEEE interview.
It's a well-known hoax.
And no, learning C++ isn't a waste of your time, something that's been discussed on StackOverflow many times.
As mentioned, this is a well-known hoax.
But it does provoke some interesting points. These days C++ is a waste of time, except for when you can't afford to waste time. Less opaquely: C++ is a waste of development time, except for when you can't afford to waste execution time.
From the article titled "The Real Stroustrup Interview" in IEEE Computer Magazine Vol. 31 Issue 6 pp.110-114 (June 1998):
For the past few months, a hoax interview between Stroustrup and Computer has been making the rounds in cyberspace. While we regret the incident, it offers us a welcome opportunity to have the father of C++ share his insights on Standard C++ and software development in general. We can also attest to his continued sense of proportion and humor—he suggests that the fictitious interview would have been a much funnier parody had he written it himself.
As others mentioned, this Interview is hoax.
Well, I am one of the persons who hate C++ and normally doesnt use it, but learning it was definitely not a waste of time. At least now I know why I hate C++ and I understand why other persons use this language and think it is good.
If you want to learn this language to know about its concepts, its benefits and its drawbacks, to be able to read code written in it, and in general to be able to "talk about" it, it is never a waste of time. Same for any other programming language. It will increase your expierience. For example, C++ shows one common way of OOP - a way I dont like, but a way many other people use.
But if you want to learn it because "the people say that it is the best" (as I sometimes read), then it is really a waste of time. Same for any other programming language.
Programmers that feel attracted to higher level languages that take care of memory management and other tasks for them, could feel that C++ is a waste of time.
It certainly is if you can achieve the same goal with another language in less time and with less bug fixing and don't mind the downsides as efficiency.
But I don't regret having learned and spent so many hours coding in C/C++ for it's such a beautiful language and allows you to produce things that not many other languages can.
I mean, don't you want to use the language with which operating systems and compilers are written? that's not a waste of time at all from my perspective.
C++ is far from being a waste of your time. You'll understand valuable concepts that will help you understand many other concepts in different programming languages. I.E.: VTABLE.
There is not a single framework which uses all language features of C++. This introduces a huge inconsistency to the language's ecosystem.
QT is one of the few APIs which I would call a framework (or API for a lot of things):
But it defines own string, own array, ...
What's the point of a "standard" library when no one can use it in a portable and compatible way (from the aspect of interaction with other APIs)?
I know, there is boost, but what is boost compared to an API such as QT? Nothing.
Look at Java: The is the standard Java API, and every "foreign" API uses it, it's all perfectly compatible.
C++ (and Java) probably the best language to learn to understand concepts of OOP.
I remember learning it in college benefited me a lot.
Stroustrup is not that stupid to say that! It is definitely a hoax!