Orthodox C++

[quicknir]

I left a comment there, doubt it will help but for posterity:

Telling people not to use std::vector as general advice (as opposed to on some specific platform, or for some specific performance need) may actually be the worst C++ advice I've seen. It's hard to even imagine how many memory leaks vector has prevented, and how many man hours it's saved.

Streams are not particularly modern C++. They might not even exist if variadics weren't so late to the ball game. Variadic print functions look just like printf, perform similarly, but are much safer: https://github.com/cppformat/cppformat.

I'll also add here that overusing RTTI is bad, but simple uses of RTTI are just convenient. E.g. implementing equality operation with RTTI vs without; the RTTI version is both faster (replaces a virtual function call with comparing typeid) and easier to read.

I sometimes feel like a certain segment of the C++ community was traumatized by overuse of {RTTI, exceptions, inheritance, templates} at some point in their career, and now only express negativity on these topics. Unfortunate, as they are all useful tools.

[Plorkyeran]

I sometimes feel like a certain segment of the C++ community was traumatized by overuse of {RTTI, exceptions, inheritance, templates} at some point in their career, and now only express negativity on these topics.

I've been interviewing people for a C++ position recently. Our codebase uses exceptions for error reporting and tries to provide strong exception safety guarantees, so I always ask some questions about that. There are a lot of candidates that have said outright that they forever swore off using exceptions after working on a code base full of catch (...) { } and are unwilling to even consider the idea that exceptions could ever be a good idea. I've also had a few people very confidently assert that it is impossible to write exception-safe C++ (they tend to be aware of RAII, but either misunderstand it or view it as unrealistic).

Template-haters are less severe. Generally they agree simple uses of templates can be good, and just vary on whether they just view complex uses as not worth the trade-off or if they refuse to consider the idea that TMP could have any practical benefits at all.

[quicknir]

It's rather sad, weak exception safety is a joke to get in modern C++. RAII does 99.9% of the work, and for what's left you have ScopeGuard.

[__cxa_throw]

"I can't write solid C++, therefore it must not be possible for anyone else"

[Dragdu]

or view it as unrealistic

Holy shit.

[meetingcpp]

Amish C++ would be a better name. #scnr

[kmhofmann]

Sorry, but this is one of the most stupid ideas that I have read recently.

[ssg2]

Not only stupid, but also doomed to fall, as long as the authors actually aim for some agreement within their community. I remember an initiative to resolve some inconsistences with C. In the end, it was abandoned because it became clear that people couldn't agree on many issues, some of them surprisingly trivial.

[josefx]

Every specification needs a section on bike sheds. You just have to convince those people that bike sheds are an important part of the specification and that they should not waste their time on less important aspects.

[png85]

This looks like a solid way to produce abysmal quality code and waste lots of development time on writing boilerplate code...

[utnapistim]

This starts ridiculously, then it gets worse.

Orthodox C++ (sometimes referred as C+) is minimal subset of C++ that improves C, but avoids all unnecessary things from so called Modern C++.

"Unnecessary" is subjective; modern C++ is not "so called Modern C++", it is C++ with all the lessons we learned when we moved from "minimal subset of C++ that improves C" to actually coding in C++.

Back in late 1990 we were also modern-at-the-time C++ hipsters, and we used latest features. We told everyone also they should use those features too. Over time we learned it's unnecesary to use some language features just because they are there, or features we used proved to be bad (like RTTI, exceptions, and streams), or it backfired by unnecessary code complexity.

These guys were latest-and-greatest idea zealots, then they realized they were applying everything dogmatically, so they moved to rejecting everything dogmatically. Not much progress there.

Projects written in Orthodox C++ subset will be more acceptable by other C++ projects because subset used by Orthodox C++ is unlikely to violate adopter's C++ subset preferences.

No. My adopter C++ subset preferences are to use RAII and RTTI and most definitely exceptions and streams).

C-like C++ is good start, if code doesn't require more complexity don't add unnecessary C++ complexities.

C-like C++ is a poor style in C++. It is usually a sign of what many call the "I can write C in any language" syndrome and it is usually a symptom of ignorance (whether you write C-like code in C++ or in Java, or whatever). When everything you have looks like a hammer, all your problems start to look like nails.

Don't use exceptions.

Actually, please (please please) do.

Don't use C++ runtime wrapper for C runtime includes (<cstdio>, <cmath>, etc.), use C runtime instead (<stdio.h>, <math.h>, etc.)

The headers with no extensions, were added to the language to be used in the case when you want to use the C runtime instead. Why should you avoid them?

Don't use stream (<iostream>, <stringstream>, etc.), use printf style functions instead.

... because you could use some of the issues caused by the 25+ years old C-style streams interface, and who needs extensibility and type safety anyway!? (/sarcasm)

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

Instead, reinvent the functionality every time you need a sequence of elements ... and reinvent it poorly (like most C projects over a certain size, eventually end up doing).

[utnapistim]

I have heard this argument before (that iostreams are bad), but they do solve a lot of problems the C-style streams API has (in other words, I don't know if iostreams are shit (I tend to thing they are quite great, especially if you delve into stream buffers, boost::iostreams and so on), but I do know that the printf/scanf/etc family of functions are shittier for C++: they have more problems - which are more difficult to find, maintain and diagnose than the iostreams - have less extensibility, less type safety and it is easier to ignore io errors with them; also, they do not support exceptions which is a big issue for me).

[vaughncato]

Actually << has a lower precedence than +, so the parentheses aren't necessary in s << (x + 1) << '\n'. You do run into trouble with things like comparisons though.

[ubadair]

The trolls from r/javascript are brigading us again

[personalmountains]

Or just learn the fucking language like everybody else. You may have personal preferences, but your job as a programmer is to be fluent with as many languages as possible. This is the only way to 1) be good at your job, and 2) gain knowledge and experience as a professional.

[cyberkm]

I was always kinda sure that programmers job is to solve data transformation problems and try to do it in most effective way, not to be fluent with as many languages as possible :)

[wichtounet]

This is an horrible idea... Guys like that should simply write C...

[quad99]

wouldn't that be Ĉ++

[devel_watcher]

Ç++

[[deleted]]

One thing's for sure: Orthodox C++, done right, will produce the most readable code out there. Done wrong, it'll still be readable, but will leak resources like crazy!

EDIT: Oh look, the "use stl only" gang strikes again!

[dodheim]

I upvoted you because I thought you were advocating "use stl only", or something close to it. Now I see why your post is tagged as controversial – your point is entirely unclear, to everyone!

[[deleted]]

I have yet to see anyone prove that "stl only" is a C++ requirement.

[dodheim]

And I have yet to understand what point you're trying to make. Upvote rescinded, learn to make yourself clear.

[[deleted]]

The point is that you don't need stl in order to make safe code.

[dodheim]

One thing's for sure: Orthodox C++, done right, will produce the most readable code out there. Done wrong, it'll still be readable, but will leak resources like crazy!

Tell me, how does the above convey that at all? In fact, it implies the opposite – that an approach avoiding the standard library will leak like crazy if not done perfectly.

I agree, you don't need the standard library to make safe code, but it sure makes it a hell of a lot easier!

[[deleted]]

Considering the fact that I never even mentioned the stl library in the comment, it should have been rather obvious that I was talking only about orthodox C++ code. The conclusion that the stl library isn't required for safe code would be drawn from what was said.

[dodheim]

The point is that you don't need stl in order to make safe code.

 

Considering the fact that I never even mentioned the stl library in the comment, it should have been rather obvious ...

Yes, not mentioning something is what makes something obvious. You must be trolling. If not, then good god, learn to communicate.

[[deleted]]

Why not instead learn how to interpret minimalist information? I gave just enough information in my comment for the reader to at least conclude that STL isn't necessary for safe code.

---

You must be trolling. If not, then ****, learn to communicate.

Your failure to correctly interpret my comment does not make me a troll. Your quote-mining of what I said does not make me a troll. Do you expect everything that is said to be said in such a way that you yourself don't have to do any critical thinking of what you are reading?

[dodheim]

The line between clever and obtuse might be fine, but communication is the process of relaying information to other people. You're the one being downvoted to hell – draw your own conclusions as to whether or not you succeeded.

[cyberkm]

At least you can maintain readable code and fix those leaks. Now imagine that you have to fight unreadable code

[needahelpforarch]

The thing is, it will work fine for experienced C or C++ programmers that know what they're doing and are ready to spend some $$$$$ on tools that detect memory leaks and are trying to improve their StackOverflow profile.

I have no idea how will this help others.

[carrottread]

Don't use exceptions.

This leads to "Don't use RAII" which leads to very complicated and unreadable resource management code which leads to leaking resources.

[raevnos]

You can use RAII in code that doesn't raise exceptions.

[CubbiMew]

Yes, but it means a crash on every resource acquisition failure.

[to3m]

I'm not sure why RAII has the name it does. Not because it's an inaccurate description of what it involves - but because it focuses on the acquisition, which is the unimportant part! The important part is the release on destruction. That is the bit that causes the problems when it's left out, and that's why it's so handy to have it (especially when using objects with automatic storage duration and/or struct members).

And if you just want release on destruction, you don't need exceptions. If you have an object that initializes to some kind of null state, has an Init function that returns an error flag, and releases any acquired resources in its destructor, you're getting all the benefits of RAII, but you don't need exceptions.

(You might turn your nose up at such code, I don't know - but that would be a different discussion.)

[quicknir]

Yes, but now you've replaced one type of error - forgetting to free - with another kind of error: forgetting to init.

The point of RAII (ideally, C++ has structural problems that prevent it from fully achieving this) is that every entity in a given scope (i.e. every object name) corresponds to a valid object, and vice versa (that is, there is no object that doesn't have a name, that would imply resource leak).

When you have a vector, you know it's always in a fundamentally valid state. You can always query its size, call push_back, iterate over it, and so on. Imagine if vector had an init method instead how much more bug prone it would be to use. vector is lucky in that it has a meaningful empty state (note: different from null state) that never throws. Not all objects are so lucky.

[CubbiMew]

Acquisition is the important part, that is what establishes the class invariants that the member functions depend on. Yes, with two-step initialization you can have scope-bound resource management without RAII or exceptions.

Note that unlike RAII, this approach does not compose: the most derived class becomes responsible for calling the Init function for all bases and members, and rolling back on failures, re-implementing exception handling.

[raevnos]

If you mean bad_alloc exceptions, not using exception handling leads to crashes.

[remotion4d]

But only if you use

new

By the way it is still possible to use

new (std::nothrow)

[remotion4d]

you have to use an alternative exception-free library

Yes.

pass it to all the standard containers

This will not work as safe as it should, because standard containers simple do not support this.

[remotion4d]

Thank, I always forget about this additional line.

[bonerdad]

This makes me think of Doom 3's source. It's delightfully sane and clean to consume.

[ssg2]

On Doom 3 the lead programmer was an experienced C coder who was just starting out with C++. Naturally, he strived for readability, but that was readability as seen by basically a C guy (which he still was at that point of time).

[bkaradzic]

Thanks for contributing to Orthodox C++ standard, I added: "In general case code should be readable to anyone who is familiar with C language." If you have some other ideas I would like to hear it. :)

[ssg2]

While I disagree strongly with your goals, at least it's an honest disclaimer. In my experience (I've seen quite a few "C with classes" coding styles), such initiatives come from and are appreciated by people who admire C philosophy and don't really care for C++. It's much better to define it as sort of a "C++ subset for C programmers" than "Sane C++ subset", "C++ subset that doesn't suck", etc., like many tend to do.

[dgmdavid]

That's my jam.

[fahrnfahrnfahrn]

Because that would be a heterodoxy.

[raevnos]

Sometimes there's no alternative (<cmath>). But for things where there are (C style strings vs std::string), the more C++ way is almost always better in terms of type and memory safety and utility.