
Orthodox C++ - girvo
https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b
======
wmu
It is written from the perspective of amateur. C++ exceptions comes at no
cost. RTTI comes at no cost. C printf is unsafe; one can write perfectly safe
printf-like formatters in C++ (did it, works well). Why one can use
metaprogramming but not STL? A programmer can plug a custom allocator in STL
containers, if an allocator is a problem.

~~~
pkolaczk
C++ exceptions definitely come at some non-zero cost, albeit very small on the
happy path, both in terms of runtime and code size. RTTI also comes at a cost
of higher memory footprint, but more importantly relying on RTTI is a sign of
bad design in most cases. C printf is unsafe, but most IDEs figure this out
and show appropriate warnings. The biggest problem with C++ streams is not
lack of printf-like formatters, but the fact that formatting is part of stream
_state_ and is not as clearly separated from the printed content as in printf.

~~~
wmu
It was comparison posted at HN -- exceptions were more efficient in case of
deep stack unwinding, when compared to testing return codes. But of course,
they are not totally free. RTTI memory footprint is negligible in practice; I
work on a huge application, having thousands of classes. Nobody cares about
the size of RTTI structures, it was never a problem. (Lack of standard API for
RTTI is a pain in the neck -- GCC has nice non-standard solution, but MSVC has
nothing.) I agree with you that overusing RTTI, like dynamic_cast, might be a
sign of design flaw.

Speaking of printf, I meant its counterpart, like boost::format; it accepts
format strings but is safe. It can throw an exception in case of an error, and
a programmer can react accordingly.

I hate C++ streams, they're slow and cumbersome, one of the worst solution
ever. I think lack of format string is their main problem.

------
mathw
But _why_? It doesn't really explain the purpose of this. What is it about
Modern C++ that the author doesn't like? It could easily be read as a person
who decided that C++ has too many things which are new and different and they
couldn't be bothered to learn them properly so now has to tell everyone not to
use them.

Most of this is really about specifics of your situation. Yes, pay attention
to what's supported by compilers on the platforms you need to support. Yes,
pay attention to memory usage and performance characteristics of the STL (but
that's just part of being a good engineer, and the performance behaviour of
STL constructs is part of the spec so it's not exactly hard to find out). Yes,
use your own data structures where they fit your use case better than the STL
ones.

But that doesn't mean, in general, that you shouldn't be using vectors. You
just need to be aware what it's doing, and use intelligence and data to
profile things properly when you're assessing whether the performance and
memory usage of your code is acceptable.

Really, this feels more like specific guidance for a specific project that has
specific requirements from its target platforms.

Except the bit about staying comprehensible to C programmers. C wasn't some
mystical nadir in language design, and C programmers have brains. If they want
to use C++ they can sit down and actually learn it, radical though that idea
might be.

~~~
pjmlp
> If they want to use C++ they can sit down and actually learn it, radical
> though that idea might be.

I was always radical since the 90's, the C vs C++ discussions we have
nowadays, I used to have them on USENET.

Even before C++98, the language already provided a sanity path to get rid of
many of the typical C exploits and programmer errors, but those guys will
never leave C.

Which with the success of free UNIX clones like *BSD and GNU/Linux, means we
will never get rid of it until there is a radical change in computer
architectures.

------
SakiWatanabe
More like Amish C++

~~~
bbmario
This!

------
osullivj
The prohibition on anything in STL that allocs mem is odd. I've been coding in
C++ since 92, and started using STL and templates in earnest circa 2002. In
the early 90s we were still in the C front world and template support wasn't
mature. By 2002 templates were well supported, and STL's mature container code
was a big step forward in terms of abstracted but deterministic memory
management.

------
emtel
> Don't use anything from STL that allocates memory, unless you don't care
> about memory management.

I don't even know what to make of this. If you can't afford to use dynamically
allocated memory _at all_ , then there's nothing special about STL, you need
to avoid _all_ libraries that call malloc(). If you ask somebody why they are
using `float* ptr = (float _)malloc(sizeof(float)_ array_size)` instead of
`vector<float> vec; vec.reserve(array_size)`, and their answer is "because STL
is slow", run away. If someone complains about std::allocator being stupid,
they have a point, but you still have a program that isn't going to write
itself, and just because std::allocator is stupid does not mean that STL is
categorically awful.

What is true is that you should understand the overhead of things like
std::set<> and std::map<>, and how to get avoid that overhead when you need
to, but this recommendation is basically a tiny subset of the recommendation
"understand and use Modern C++".

~~~
tetromino_
> If you can't afford to use dynamically allocated memory at all, then there's
> nothing special about STL, you need to avoid all libraries that call
> malloc().

I think the idea (as seen in traditional high-performance C++ code) is to be
very aware of allocations. Dynamic memory allocation is slow; sometimes, the
slowest part of one's code. So it's fine to use a library that calls malloc()
behind your back for small, occasional allocations (whether that library is
the STL or libc or any of your other dependencies), but not in your inner
loops, and not for your multi-GB data structures. Instead, manage your own
buffers, size them right from the beginning using application-specific logic,
realloc exponentially if you need to (but hopefully you don't need to), and
use placement new to construct your objects in your buffer in a way to
optimize access locality.

------
daemin
This is another one of those articles saying that people tend to overuse easy-
of-programming and language power features to the detriment of
speed/efficiency (of compiling and perceived execution) and understanding.
While this sort of argument has some merit, in that typically new features are
overused just after introduction, it basically relies on the infallibility of
the programmer not to make simple mistakes.

To me the trick is not to have magic things in the code, but instead use the
language to the best of ones ability to write simple non-magical code. Unlike
in the article I include things like smart pointers and the STL as some things
helping me do this.

------
maxnoe
Just when I thought C++ started to become a sane language again.

------
bbmario
Having second thoughts about the bgfx library now.

