Popular Myths about C++, Part 1

http://isocpp.org/blog/2014/12/myths-1

by jabaldonedo • 12 years ago

103 141 12 years ago

0942v8653• 12 years ago

Not showing up. Here's an archived version: https://archive.today/LoOe1

Thanks. Very short post though. What I have to say is, that C++11 and onwards had indeed made C++ much more approachable. I think Herb Sutter's talk on modern C++ is also worth a look. [0]

[0] https://www.youtube.com/watch?v=TJHgp1ugKGM

rumdz• 12 years ago

I just finished watching this and 48:58 really blew my mind.

pjmlp18• 12 years ago

Yes, with C++14 many of my rants over C++ are now out-of-date.

I just would like to have modules today.

ExpiredLink3• 12 years ago

Good luck trying to understand C++ without C. The numerous C++ traps and pitfalls will just look mad to you. BTW, 'multi-paradigm' is an oxymoron. Not even Scala uses that concept any more.

throwawayaway19• 12 years ago

Scott Meyers says in Effective C++, view C++ as a confederation of languages: C, C++, the preprocessor and templates.

When some people say that when you are learning C++ you should not be exposed to C, I really have to disagree.

bewuethr• 12 years ago

I think he says "OO C++" and "STL", not "C++" and "preprocessor".

stinos• 12 years ago

Good luck trying to understand C++ without C

look at it this way: suppose some alternate universe where there is no such thing as C, it just doesn't exist, nobody ever heard of it. Why would you not be able to completely master C++ that universe? The traps and pitfalls which you consider C, would then just be known as C++ (just as in reality they are C++ now, maybe not just always named as such). I think that's one thing what's being advocated here.

Anyway, what traps do you have in mind specifically?

millstone2• 12 years ago

Much of C++ can only be understood in the context of C. For example, why are string literals not std::string, and what the heck are null-terminated strings about? In your alternate universe, C++ would be a nonsense language full of absurd design decisions. Understanding C is perhaps necessary to understand why C++ works the way it does.

mikeash10• 12 years ago

C++ wouldn't exist in that universe.

But if we accept the hypothetical, I think that people in that universe would still identify and separately consider the C-ish subset of C++, much like template metaprogramming is considered its own subset of the language.

So no, I don't think they would understand C++ without first understanding C, even if they didn't call it "C" or consider it to be a completely separate entity.

aikah• 12 years ago

Good luck trying to understand C++ without C.

You need a basic understanding of C.But C and C++ are different languages,period.

Ragnarork4• 12 years ago

What exactly do you need to know about C, that is not part of C++, to understand C++?

Genuine question.

throwawayaway19• 12 years ago

why do pointers exist if you have references? why does printf exist? what is everything in the cstdlib?

omaranto• 12 years ago

I think what ExpiredLink1 meant is what millstone says here [1], which I took to mean that although you don't need to know C before learning C++, psychologically it may help to know about C (i.e., that a language called C existed before C++ and that C++ is designed to be mostly backwards compatible with C), so that C++'s design choices don't seem as weird.

[1] https://news.ycombinator.com/item?id=8722655

AnimalMuppet• 12 years ago

BTW, 'multi-paradigm' is an oxymoron.

False.

What's a paradigm? It's a way of viewing things. What ways are there of viewing programming? Well, there's functional, there's structured, there's object-oriented, there's generic, and maybe some more.

Can C++ be used to write non-object-oriented, non-functional, purely structured-programming-style procedural code? Yes, it can. (Essentially, that's the subset that's in common between C and C++.) Can it be used to write object-oriented code? Certainly. Can it be used to write functional code? Again, yes (though not nearly as purely as the Haskell zealots would like - but C++ doesn't enforce the purity the way Haskell does precisely because C++ is multi-paradigm). Can C++ be used to write generic code? Yes. (I have heard that the STL was written in C++ because, at the time, it was the only widely used language that would do what Stepanov wanted to be able to do.)

Four different paradigms. You can write C++ code using any of them, or you can mix and match. That's multi-paradigm.

Or are you arguing that, if you have more than one paradigm, you don't have any? That might be true of a program, though I think that the argument is merely a matter of definition, and therefore not very interesting. But if the language makes it easy to write in several paradigms, it seems perfectly appropriate to call it multi-paradigm.

pherocity_• 12 years ago

I'm getting so tired of the word myth and how it's used so incorrectly. These may be misconceptions, but they are not myths. In truth, some of these are factually accurate and you're framing them as a misconception to drive a narrative. I can't help but consider that link-bait, even though structured differently, this would be a good article.

Iftheshoefits• 12 years ago

First, which of the "myths" are "factually accurate" and in what sense?

Second, I don't find his use of "myth" objectionable, in much the same way I (as a scientist) don't find objectionable the use of "theory" to mean "guess" in non-scientific speech (attempting to impose "guess" as a meaning when discussing scientific theories is anathema). This use of "myth" here is fairly common, at least colloquially in America, as a rhetorical flourish in place of "misconception."

robert_tweed2• 12 years ago

Myth 6: off-by-one errors are prevalent, even in articles about C++.

PS: Since HN is specially humour-impaired, and for the DNRTFA crowd: this is a complaint about the article's formatting.

Ragnarork4• 12 years ago

I'm looking forward for the next part, as the last three myths are the ones I'm waiting for their answers, as they should be pretty interesting.

C++ has come a long way, and I really feel C++ 11 could very well replace Java as a learning language for computer science students (I don't think it'd be a good choice for an introduction to programming for non CS students), and I see many benefits in this, the biggests being IMHO C++ NOT being fully object-oriented, and the possibility to do either low- or high-level stuff, depending on what you're teaching.

wmt• 12 years ago

My biggest issue with most garbage collection implementations is the lack of RAII. While I love the ease of reading and writing Python or Lua, I'd love to be able to create a local object, like an open file or a database connection, and have it destructed immediately on return.

idbfs• 12 years ago

I'm not sure about Lua, but for Python it sounds like you may be interested in the "with" statement.

pjmlp18• 12 years ago

You can do this in all modern GC languages.

Either with a using/try with resources/with construct, or by using closures.

    // Pseudo language with FP capabilities
    let withFile filename action = 
        let fd = open filename
        action fd
        close fd

    withFile "config.sys" (fun fd -> write (readlines fd))

Real production code would also take care about proper closing the file in case of errors.

mike-cardwell6• 12 years ago

"Finally, which version is likely to be the most efficient? Yes, the C++ version, because it does not have to count the argument characters and does not use the free store (dynamic memory) for short argument strings."

I just compiled the C code and the C++ code using:

  gcc -std=c99   -Wall -Wextra test.c   -o test
  g++ -std=c++11 -Wall -Wextra test.cpp -o test

According to valgrind:

  C:   total heap usage: 1 allocs, 1 frees, 21 bytes allocated
  C++: total heap usage: 4 allocs, 4 frees, 145 bytes allocated

Using gcc (Debian 4.7.2-5)

[edit] Repeated using gcc 4.9.1 and clang 3.5.0 with -std=c++14. No difference.

[edit] Seems with Clang and libc++ it's better than the C implementation as it doesn't do any heap allocation:

  clang++ -stdlib=libc++ -std=c++14 -Wall -Wextra -g test.cpp -o test
  total heap usage: 0 allocs, 0 frees, 0 bytes allocated

But still, that's only because the C version was explicitly written to use heap allocation. It need not do so.

nly2• 12 years ago

The articles promise is actually terribly dubious. Firstly, in the real world, name+'@'+domain is likely to exceed the capacity for any SSO anyway. Even the example composition, which is 21 chars, may resort to heap allocation under some implementations. It's a bad solution to depend on it for performance.

Secondly, as you discovered, the current GNU stdlibc++ implementation of std::string will always allocate for short strings. Even 1 byte. This is for binary back-compat and will hopefully be fixed in GCC 5.0. For now try it with Clang and libc++. See[0] for more information and a comparison of current implementations.... the standard doesn't require SSO at all.

Thirdly, and getting to the deeper issue, once the heap is involved the C version is nearly (it needs length params) optimal and will still always be more efficient than the C++ code. Why? The C++ solution uses uses operator+ which is fundamentally performing a different and less general algorithm. For composition it will introduce some amount of repeated work which even the best link-time optimizing compilers probably won't remove, and may, depending on the length of the trailing string segments, and the growth strategy used under the covers, force two allocations. The standard doesn't give complexity guarantees for mutation on std::string at all, so the resulting performance could, on some platforms, be very bad. In all cases you will be able to construct an input that forces more than one allocation (exponentially growing segment sizes).

There's also another efficiency issue in the naive op+ approach... C++s allocator specification doesn't provide realloc() so a portable solution will always use more peak memory, on average, when it is forced to reallocate.

The C++ solution is just using the wrong algorithm for the job. You can write, and I have toyed with[1], a variadic strcat() function that will be optimal in the generic case. The standard library just lacks one. It's embarrassing, but fairly understandable given that variadic templates didn't come in to the standard until 2011. I'm hoping if they introduce one it'll be called scat() :-)

I'm a big C++ fan, but we shouldn't be deluding ourselves here. Fortunately, these things can be fixed within the framework of the current language.

[0] https://github.com/elliotgoodrich/SSO-23/blob/master/README....

[1] http://codepad.org/rkmNTkIn

mike-cardwell6• 12 years ago

That's the good thing about C. With C++, you don't know what is being allocated, where. With C, it is explicit. You know what's happening if you call malloc.

And this compose function could easily be written in C to take the "addr" as an argument to be filled, rather than provide it as a return value. Then it can be entirely stack allocated. The caller would need to make sure that the "addr" array was large enough of course.

I started learning C and C++ together at the same time a few years ago. I prefer to code in C++, using the standard template library, but there's always this extremely annoying little voice in the back of my head saying, "you could do this more efficiently if you operated on character arrays instead of a std::string"

millstone2• 12 years ago

Right. Also, the C version would be cleaner using the printf family of functions. Idiomatic C would use snprintf and accept a buffer. If you insist on returning a heap-allocated object, you could use asprintf, which is not universal but is common. Either way it's a one-liner.

robert_tweed2• 12 years ago

To paraphrase Don Knuth, "I have only proven it correct, I haven't tested it."

To be fair, he says "likely to be" and results may vary between compilers. He also makes reference to the speed penalty of calling strlen(), which isn't necessary with std:string because it stores the length. Even with more allocations, it's possible the C++ version runs faster. It should have a lower computational complexity, meaning it would be faster if the input strings were much longer than they are in this example.

BudVVeezer• 12 years ago

Try it with -stdlib=libc++, since that's what will control the behavior of std::string.

mike-cardwell6• 12 years ago

Ooh. Nice:

  total heap usage: 0 allocs, 0 frees, 0 bytes allocated

pjmlp18• 12 years ago

Your comparison entails the fallacy of using compiler specific behavior for what the standard doesn't specify.

pierrebai• 12 years ago

This is the archetypal problem with benchmarks: not only are they hard to design, but people will incorrectly nit-pick the results.

You count the number of allocations, without looking at the big picture: this is a toy example. It provides the hard-coded input to the function. This results in the C version not having to allocate memory for the hard-coded literals and the function problably being inlined and optimized away and the strlen() calls being equally optimized away as the length of the strings are known at compile time.

In the real world, these would come from some input where they would need to be allocated on the heap, just like the C++ version does. It would use just as many allocations, except they will all be hand-rolled, hand-held, error-prone, with every bit of memory management explicit. C++ is superior in every measure here. Only in toy programs and hard-coded strings does C wins.

If the goal was to have as few allocations from hard-coded strings, then just write "foo@bar" and avoid the concatenation altogether. That is not the point of the example.

(Also, the newer C++ standard support std::string literals, FWIW.)

mnem• 12 years ago

It may not be the point of the example but it's mentioned explicitly by the article's author as a feature. Doesn't that make allocations in the example fair to comment on?

StephanTLavavej2• 12 years ago

C++14's "meow"s is syntactic sugar for string("meow"), with identical efficiency.

maxlybbert5• 12 years ago

Try it with optimizations on:

gcc -std=c99 -O3 -Wall -Wextra test.c -o test

g++ -std=c++11 -O3 -Wall -Wextra test.cpp -o test

In my experience, C++ compilers are great at eliding temporaries and various constructor calls (and related memory allocations), but only if optimizations are turned on.

mike-cardwell6• 12 years ago

Made no difference

Symmetry• 12 years ago

What sort of C programmer wouldn't use snprintf to do the formatting? If the C++ program can use std::string then it's only fair to let the C program import <stdio.h>. And honestly printf is so much nicer to use than iostreams I've always considered the relative ease of putting together a formated string one of C's strengths relative to C++.

linuxlizard5• 12 years ago

What sort of C programmer wouldn't test for malloc() failing.

Drives me batty to see articles where malloc() is happily assumed to always succeed.

ExpiredLink3• 12 years ago

Drives me batty to see articles where malloc() is happily assumed to always succeed.

... as in Linux.

kabdib• 12 years ago

Rule #1 of systems programming: "Never check for an error that you don't know how to handle." This is, of course, a joke, but it has a kernel of truth.

I've worked on production code where, if allocation fails, the system fails, too, and restarts. The allocator never returns. There's usually some kind of helper system watching for the failure, which can take a dump or at least a stack trace.

The theory is that any attempt at recovery is going to be a disaster; not well tested, and probably doomed in the face of memory pressure anyway. On 64 bit systems the memory ceiling is essentially infinite, but reaching the point where we start to swap is horrible and a pyrrhic victory at best, so instead let's do a controlled crash and log enough information so we can analyze and fix the actual problem (which is a misunderstanding of load and resources, or maybe a bug or an attack where we're trying to allocate twenty gazillion bytes).

That's one philosophy. Another (which was prevalent on the Mac in the 80s, in user applications) is to have a reserve; you test the crap out of the code and give it enough memory in some kind of emergency mode to succeed at getting back to a normal state, or at least quitting in an orderly fashion (ditch dynamically loaded code, fonts, whatever) so that the user's work isn't totally lost.

There's a lot to be said for both designs, and of course these don't cover the case when you're writing library code that can be used by anyone, where reliably returning failure to the caller is important. Here you don't have a choice other than to check and be robust.

So three, yes, three philosophies.

fsloth• 12 years ago

If malloc fails for trying to allocate a few miserable bytes I would claim the game is over. Why would he need a fallback strategy, anyway? The program is tiny and really, really doesn't do anything important.

Matters of taste I suppose, but I've always felt that for tutorial and proof of concept code it's better to skip unnecessry details.

Not every line of code lives in a production environment...

CountHackulus• 12 years ago

snprintf isn't a standard function. There's certain platforms that don't have it. I know, it happened to me on z/Linux.

vonmoltke• 12 years ago

snprintf is a standard function, but only as of C99.

divs1210• 12 years ago

Has Linus read this yet? I can hear him screaming in fury. :D

pjmlp18• 12 years ago

Linus has ported his Subsurface project to Qt, thanks to the current state of affairs in Gtk, so I imagine he might be a bit more welcoming to C++ nowadays.

throwawayaway19• 12 years ago

https://github.com/torvalds/subsurface

pretty interesting! the .c's heavily outnumber the .cpp's.

there's nothing like having your prejudices confirmed to harden them, so I question whether he is more welcoming.

mikeash10• 12 years ago

A major problem with C++ is a lack of consistency, which you run into if you start trying to generalize the ideas presented in this article.

The article demonstrates string concatenation using +. That is great! Except it's inconsistent. The article's example works fine, of course:

    return name+'@'+domain;

I'll skip over the weird use of '' instead of "". Now let's say I want to prepend mailto: as well:

    return "mailto:" + return name+'@'+domain;

So far so good. But I think it might be clearer if the colon was separated out:

    return "mailto" + ":" + name+'@'+domain;

Oops, this no longer compiles. Hey beginner programmers, let's take time out from the arduous task of learning basic programming to understand what a const char * is and how it differs from const string and why you can + two strings or a string and a const char * or a const char * and a string but you can't + two const char *s.

The next example demonstrates initializing a vector:

    vector<int> v = {1,2,3,5,8,13};

This is great, of course. The example after that introduces "auto" so you don't have to write the type of a variable. Well heck, let's combine the two!

    auto v = {1,2,3,5,8,13};

Kaboom. Oops. You can use auto, or you can use {} to make a vector, but you can't do both at the same time! OK, beginners, let's take some more time out from learning what you came for and instead learn about the complex machinery that handles initializing a custom type with {} and why "a = b" can do arbitrarily complex things depending on the types of a and b.

I had a job in college tutoring students in my CS department's first-semester programming course, which was taught in C++. People would routinely come in with code that wouldn't compile because of some tiny mistake, but which produced literally pages of error output. There was no way for new students who were still struggling with the concept of a loop to figure out what they were doing wrong, besides finding somebody who had already been through it.

This was a long time ago, and C++ has improved, especially in the error message department. But these problems are still there, even if somewhat diminished, and other languages don't have them.

The fundamental problem with C++ is that it grew organically from humble beginnings without any apparent plan. This allowed to adopt a lot of nifty features and become extremely powerful, but it also means that there are a ton of bizarre corner cases and inconsistencies to deal with. For many projects, the tradeoff is worthwhile. But it's one of the worst choices imaginable for teaching new people to program.

humanrebar3• 12 years ago

To be fair everything you're upset about is a problem with the standard C++ library, not the language itself.

Not to say that the language doesn't have issues. The initializer list example you provide is half of one, but only because people don't like to write algorithm-based code.

This is actually fine:

   auto v = {1, 2, 3, 5, 8, 13};
   for (auto i : v) {
       std::cout << i << '\n';
   }

...all that being said, the C++ standard library gets strings very wrong. I've ranted about it here before. But, to be fair:

1. What language gets strings right?

2. C++ has some interesting ideas around the bend (concepts) that should make using library code much easier. Whether writing library code will be easier is another question, but I'm hopeful.

mikeash10• 12 years ago

The standard library is part of the language. But that aside, the fact that + doesn't work on string literals cannot possibly be a problem with the standard library. The fact that the language lets you extend + to work with some types but not others is not a problem with the standard library.

As for initializer lists, the problem isn't simply that {} doesn't produce a vector, it's that identical-looking constructs do completely different things in different contexts. a = b can do completely different things depending on where you see it and what declarations are visible and on and on. Again, not a problem with the standard library.

The standard library suffers from these problems, as it must since it exists within the language that causes them. But the problems are not in the standard library.

Retra• 12 years ago

Standard libraries are part of the language. I would go so far as to say anybody who designs a language that isn't meant to make their standard libraries powerful, consistent, and elegant isn't doing any favors for the discipline.

jlarocco2• 12 years ago

auto v = {1,2,3,5,8,13};
Kaboom. Oops. You can use auto, or you can use {} to make a vector, but you can't do both at the same time!

IMO it would be more confusing if that created a vector<int>. Unless the compiler is reading your mind, how is it supposed to know you meant a vector<int>, a set<int>, deque<int>, a struct { int a,b,c,d,e,f}, or some other object who's constructor can take 6 ints?

mikeash10• 12 years ago

The way most other languages handle it is that the list literal construct just creates a list, and if you want something else then you need to explicitly convert. For example, in Python:

    x = [1, 2, 3, 5, 8, 13] # this is a list of integers
    y = set([1, 2, 3, 5, 8, 13]) # this is a set of integers

There's nothing inherently wrong with C++'s initializer list approach. Nor is there anything inherently wrong with auto. But they collide in unfortunate ways because they haven't been designed such that they go well together. C++ is full of things like this. Responding with "well, that makes the most sense" for any given feature is missing the point entirely.

jerf5• 12 years ago

Go would do:

    v := []TYPEHERE{1, 2, 3}

where TYPEHERE is the type of array[1] that you're creating. Is there any equivalent C++ technique here? Explaining all the machinery may blow out a novice's mind, but I think explaining "You need to give C++ some clue about the type" isn't so bad.

[1]: Before you complain I just created a slice, remember the slice has to point at an array; I've created both a slice and an array so it's not "wrong" to say I've created an array with that syntax.

Scea914• 12 years ago

The aim of C++ is not to be accessible to beginners. There are other languages for that. The philosophy of C++ is to give you power and it's up to you how to handle it.

mikeash10• 12 years ago

The article explicitly states that C++ is a good language for beginners, and the entire point of my comment is to argue against that.

npalli• 12 years ago

>The next example demonstrates initializing a vector:
> vector<int> v = {1,2,3,5,8,13};
>This is great, of course. The example after that introduces "auto" so you don't have to write the type of a variable. Well heck, let's combine the two!
> auto v = {1,2,3,5,8,13};

The auto example creates an std::initializer_list which then can be converted into a vector or a set

    std::vector<int> newvectorfromauto(v);

    std::set<int> newsetfromauto(v);

Which seems the best you can expect with auto deduction. What else do you have in mind?

netheril962• 12 years ago

What he has in mind is that it is logical and reasonable for C++ to behave in this way, but completely incomprehensible for beginners who has just learned the basics of programming.

axiak• 12 years ago

Not that this is necessarily any cleaner, but in C++14 one would write:

    return "mailto"s + ":"s + name + "@"s + domain;

and it would compile fine. (s being a literal for std::string)

mikeash10• 12 years ago

It's sad that it can't become the default for "" literals without breaking a ton of code, but I'm glad to see this change.

maratc2• 12 years ago

return "mailto" + ":" + name+'@'+domain;

Apparently, the first `+` is a problem, so just take it away:

    return "mailto"  ":" + name+'@'+domain; // there, problem solved.

mikeash10• 12 years ago

Of course. Now, do you want to sit down and explain why that's necessary to somebody who's still grappling with the concept of for loops?

WhitneyLand• 12 years ago

Does anyone choose C++ anymore unless it is required by environment/legacy/performance constraints?

Back in the day I read Bjarne's book cover to cover, used C++ for very large scale projects, and was one of those guys who could make sense of arbitrarily complex pointer expressions.

Now I mostly regret it. Led down the rabbit hold of multiple inheritance, STL being much more complicated than templating in other languages, and watching devs take years to master all of the subtleties.

He alludes (next article) to garbage collection not being more reliable than manually memory management? Yes GC has it's own disadvantages and there are many ways in C++ to mitigate memory management problems, but seriously I wish I had a dollar for every hour of time spent on a memory allocation bug in C++.

bstamour• 12 years ago

I still use C++ because it not only allows me to write high performance code, but also allows me to easily express high level ideas without worrying about too much overhead. I can write generic algorithms in terms of monoids and semigroups and I can write device drivers. I do a lot of signal processing at work, so sometimes these high-level and low-level concepts exist side-by-side in the same codebase.

Edit: I should mention that by no means to I think C++ is perfect. Very few other languages, however, give you the amount of low-level control, and the tools to build cheap, powerful abstractions, like C++ does.

Scea914• 12 years ago

With the recent updates to the standard C++ is actually a really pleasant language to use. You just have to know a lot, but the reward is there.

jbergens• 12 years ago

Yes, but it seems the whole team (or all teams in large enterprise projects) must know a lot. Otherwise you still and up with a lot of hard to read, unsafe code. If you start with a very large codebase of old C/C++ you might have to rewrite large parts of it to reap the benefits and in that case you might want to look into other languages as alternatives. I agree that for a green field project with very good developers C++ 14 looks nice.

jj00• 12 years ago

Couldn't you say this for any language? As soon as you start applying it to larger projects things start to get more complicated. It's not the same problem per language, but each has their own issues.

pjmlp18• 12 years ago

Does anyone choose C++ anymore unless it is required by environment/legacy/performance constraints?

At work no. Typical enterprise world using JVM and .NET languages.

For side projects, surely yes!

It is the only language supported across all mobile OS SDKs with full access to the hardware.

If you have control over the codebase, the ability to use C++11/14 is quite comfortable, even in terms of memory management.

Now for the typical enterprise projects, with offshore developers at work I wouldn't use it. I already cry when I look at code written in less powerful languages.

drblast• 12 years ago

I like C++, but using it to teach beginners who have no knowledge of C or compilers in general is a horrible idea. My college CS101 course was taught using C++, and I was lucky because I already knew multiple programming languages before that.

1. There are a lot of abstractions in C++ that make it very powerful, but the reason those exist would be completely lost on a newbie. Pass-by-reference vs. pass-by-value? Oh yeah, there are pointers too that you might run into, that's almost exactly like a reference but with a different syntax. We have smart pointers instead to obscure that from you, but if you search for examples online you might run into any of these. But don't worry about all of this; these language features only exist because of type safety and performance which you have no clue about. Just change the syntax until it compiles and runs.

2. Programming is more than write->compile. Debugging is as important, if not more, and heaven help you if you're a beginner trying to debug C++. With C you'll at least get exposure to machine code that pretty much looks like the program you wrote.

3. C++11 is an improvement, but it's not ubiquitous and it adds abstraction that someone without a solid C/Assembly background will have very little chance of understanding.

Teaching C++ to someone with a firm grasp of C would be a lot easier and additive. "Here are the new features that can help the compiler make your program more performant or type-safe or fix your memory leaks." Otherwise you're throwing a bunch of solutions at students to problems they've never had.

cheez• 12 years ago

It is the end of 2014 and I am using C++11 on Windows, OSX and Linux without too many incompatibilities. Of course, you need the latest versions of the compilers but it's ubiquitous enough.

pjmlp18• 12 years ago

Teaching C++ to someone with a firm grasp of C would be a lot easier and additive.

Where I took my CS degree, students were introduced to C++ straight after Pascal.

netheril962• 12 years ago

The list initialization syntax touted by Bjarne Stroustrup himself as beginner friendly is not even friendly to advanced users. Tell me how to debug or teach students the difference between

    std::vector<int>{10}
    std::vector<std::string>{10}

Popular Myths about C++, Part 1

Related Stories