Hacker News Reader

Comment by chuckcode | Hacker News Reader

One of the reasons people use "low level code" for performance is because the STL doesn't easily provide control of memory which is critical to performance. Electronic Arts wrote their own version of the STL largely so they could better control memory [1].

I'm not really sure about the rest of the myths. I'm a little confused about how "To understand C++, you must first learn C” is a myth since C++ is a superset of C so you kind of have to learn C.

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227...

View on HN

While the C++ language is indeed a superset of the C language, the paradigms of modern C++ have almost no overlap with those of C. See for example the string qsort vs string std::sort elsewhere in this thread.

The myth in "To understand C++, you must first learn C" is not that C and C++ are unrelated. The myth is that learning C helps you understand C++. The reality is that telling people to learn C first is an excellent way of getting them to write really bad C++ when they switch over to C++11.

I'd argue that UB is an evil enough concept in C that still exists and is expanded on in C++ that should be known by every programmer. Sure, paradigm differences mean that idiomatic C code is not idiomatic C++ code, but knowing the pitfalls of the language should be mandatory, imho.

I guess that depends on your definition of 'easily' - you can provide custom allocator s fairly easily. What's more problematic are things like the memory usage patterns of std::vector and std::string. Once you know how they work you can avoid the pitfalls or use custom alternatives.

Things like alignment support didn't come out in g++ until 4.8 [1] but now you could start actually do most of what the EASTL is doing aside from the access to private members

[1] https://gcc.gnu.org/projects/cxx0x.html

Actually, I've found that it's even undesirable to know C, because programmers, that came from C to C++, usually try to do everything in "C way" that leads to the code is "C with objects". To really learn modern C++, one must "forget" C and start with basic concepts.

There's an example in Part 1, where string concatenation is used as an example. C++ requires "adding" two string objects and C requires manipulating char pointers. And thus, C++ is a better teaching programming language.

Although true, I feel this argument is rather weak: it's true, that when teaching I wouldn't want to start with pointers and malloc's from the get go, but it does not mean C++ is the only alternative.

If you're teaching programming, don't teach C++.

If you're teaching systems programming, don't hide pointers. In this case, knowing the addition operator is useful iff they understand the underlying operations.... chances are, if they're learning C++, they don't.

I completely agree.

It's difficult to find a place for C++ in my little projects, given that I can use C for low level stuff and Python or Lua for high level stuff.

Then don't use C++. There's a tool for every need. I wouldn't use C++ either if there was an option for cross-platform, high performance, non-garbage collected way to program highly interactive VR -applications. There simply isn't, so I must use C++ and learn it.

But got to say, my experiences with learning C++11 has changed how I view C++, it's much more robust and nice environment than what I thought, the new C++11 and C++14 really bring some nice things to the table.

I agree, that C++11 is an improvement. I was actually quite excited when Stroustrup's updated book on the subject came out. But like I said, I still can't find a fit for C++ in any of my projects. My use cases however are far different from yours, so I'm naturally opinionated away from C++.

Not as true any more. Are you familiar with value categories in C++11?

Reply on news.ycombinator.com