[lazyjones]

While I find the "sane C++" approach pragmatic and practical all things considered, I'm firmly in the "time to use a better language if possible" camp.

The problem with approaches requiring extra discipline is: it's an extra mental burden to bear while programming. Also, you'll always be limited by the fact that you're working in a less pure ecosystem and will likely end up using libraries written in "not very sane C++" anyway.

We seem to have flexible compiler SDKs these days (LLVM etc.), why isn't there a strict "sane C++" or "orthodox C++" subset available as a custom language or compiler option yet?

[mbel]

> why isn't there a strict "sane C++" or "orthodox C++" subset available as a custom language or compiler option yet?

Probably because sanity is (1) subjective, (2) in this case doesn't really come from disabling features (restricting language). He is still using most of the C++ features (overloads, operator overloading, templates) but only in semantic context that is obvious for them (i.e. templates for collections, overloaded operators for vectors and matrices). Therefore it might be a little bit hard to create a compiler front end that would understand which class acts as a collection or whether given structure is implementation of well known mathematical concept.

[simias]

The first step would be to actually define such a subset. And what happens when this subset calls into "full" C++? If you don't want to lose interoperability you have to be pretty conservative with the things you disallow.

In particular since C++ kept the C-style preprocessor "just copy and paste that file in there" includes it would be tricky to handle "sane C++" including "full C++", especially since templated C++ tends to put a massive amount of code in the headers (think boost for instance, which is mostly .hpp "headers"). You'd have to tell the compiler to switch the "sane" flag on and off within the same translation unit depending on the original source of the code. Nothing impossible, but not exactly elegant. Alternatively you could use a new `extern "sane-C++" { ... }`-type block around all your code to tell the compiler what to do.

At any rate you'll have to make sure that your sane subset can always inter-operate with the "wild" C++ without any cross-contamination.

But really I think the main problem is that you'd have trouble getting a consensus on what would be your sane subset. Some devs will tell you to get rid of exceptions altogether, others will tell you that multiple inheritance is the work of the devil. Some will want to ban raw pointers (or at least severely gimp them). And some will want none of that but something else instead.

[lazyjones]

> But really I think the main problem is that you'd have trouble getting a consensus on what would be your sane subset.

This can probably be solved by adding flexible configuration options (C++ compilers already have plenty). In practice, project leaders would then decide on a set of such options, similar to what happens with code style guidelines.

Perhaps some day a majority of people will agree on a "good" subset of C++ / option set and it will become standardized as a new language or dialect.

[otabdeveloper1]

Because catering a C++ compiler towards people who can't (and won't) actually learn C++ is stupid.

[dbartolini]

People are working towards that objective, see for example Jonathan Blow's Jai.

[jcalabro]

I'm really excited about this language. Here is a link where Blow live codes and explains features:

https://www.youtube.com/playlist?list=PLmV5I2fxaiCKfxMBrNsU1...

[sqeaky]

Debatably, this exists. With GCC or Clang there are several command line flags that can help.

If you use the flag -Werror all warnings will be errors.

Then add -Wall which enables all unambiguously good warnings, which will stop a whole lot of things that skirt the type system, it will prevent silly rounding bugs and in general reduce the bug surface of your code.

Then if you enable "-pedantic" more errors are found, but not all are clearly improvements. I think most of them are good and I think most would agree that mandating the "override" keyword is good, but not all would agree with every signed to unsigned comparison warning.

Put together this add "-Werror -Wall -pedantic" or a "/w4" MSVC) to the command line, or more likely makefile/CMakeLists.

I personally advocate enabling all these and a similar set from msvc then adding a set of robust warning suppression macros to you code and suppress the warning that really make no sense to fix. This has prevented a ton of bugs in my code, it minimizes the amount of premature optimizations I see in code that tried to cast from one type to another by relying on some unspecified binary compatibility and in general makes writing C++ really enjoyable.

[pierrec]

The best argument I've seen for using orthodox C++ is when writing something you want to compile to both native platforms and web using emscripten, while aiming for good performance and small distribution size.

For example, this is what Oryol achieves, targeting OpenGL on native and WebGL on web. I don't think anything could beat the "Orthodox C++" approach for that purpose, aside from using C (which is what I'm using for a project right now).

https://github.com/floooh/oryol/

[politician]

I think what you're referring to is D.

[goldfire]

There was an attempt at a somewhat standardized C++ subset called Embedded C++. Even within embedded circles I don't think it ever got much traction, presumably because it was _too_ limited.

[GuB-42]

For embedded systems there is MISRA C. It is a set of guidelines that is included in some compilers and analysis tools. MISRA C++ exists too but I don't know how well supported it is.

It is, however, a rather restrictive standard with critical systems in mind. Usually, you don't want such restrictions in regular software development, you want the full power of the language.

Ensuring sanity is better served with static analyzers (linters) that can be tailored to the specific needs of the project and be regularly updated with new rules.

[jahnu]

I guess the reason is that a combination of static analysis and code formatting does most of the same job.

But I would also love to have it as a compiler switch.