Orthodox C++

orthodoxc++.md

Orthodox C++

This article has been updated and is available here.

This should be the default way of doing C++
Feature creep is never good.

@GabrielRavier

GCC and clang should introduce new switch: /orthodox

@DBJDBJ what would the flag do?

Enforce "all" the "rules" discussed here. The very first post on this page explains it. I would also add: bar std::

Yo, hopping in the discussion, my style is that I just use std::vector and string and things like that. I think that using them is very nice and they don't really have many problems for 99% of use cases, writing them is horrible tho, so I would never write them. So basically I write C with methods, operation overloading, vectors, lambdas, std::file_system and one time a year templates 😂. I also never use destructors.

@bkaradzic , I have a small doubt I wish to ask you. Heap fragmentation is a problem when it comes to STL, so why not write something to a bump allocator? Have a continuous block of memory, and when a realloc is requested, if requested size is bigger than existing, expand the pool, move it to the end and get rid of the hole in between (using memmove).

A simple implementation of this comes with asmjit. See Zone, ZoneAllocator, ZoneVector, ZoneHash, ZoneString. It is used in what amounts to compiler-class code that has to be light and fast. It delivers on that.

Question @bkaradzic : What would be considered "selective" use of C++20? I'm planning on upgrading my C++ version for a game engine I'm working on. Any particular features in mind, or just keep using features that existed in C++17 that might have additional power in C++20 (for example, updates to constexpr)?

As a side note, personally, struct/enum/union without typedef, reference parameters, and constexpr are all I use from C++.

trcrsired/Portable-Cpp-Guideline

@DBJDBJ

GCC and clang should introduce new switch: /orthodox

I've implemented it, pretty much. See https://github.com/d-musique/orthodoxy
It does the enforcement of programming rules that you mention.

It's quite recent and it works for me well. This thing was born out of extreme frustration with the ongoing ens*ittification of C++ to a point that I could no longer accept it.
This lead me to revise my approach to C++ programming to a large degree, and I judged this kind of tool to increasingly become a necessity. This has been on my mind for maybe a year or so but finally I dedicated some time so I could bring it to reality.

@d-musique Excellent! 👍

Any language starts to grow features with which you can accomplish the same task in a large number of ways.
As a result, when you read someone else's C++ code, it looks alien, because the language provides many ways to do the same thing.
Rust follows the same path. C# similarly adds new keywords with each version instead of removing them and making the language simpler and clearer.

what is your standing on references ?

references are 💩

void do_something (int& x)
{
    x += 1; //mutate! hahaha
}

int main(int argc, char** argv) {  
    int q = 0;    
    do_something(q); // You won't know that q will be mutated unless you read the documentation or the function impl.

No, guys.
Even Orthodox C++ doesn't fix the fundamental problem with C++, where any class can behave however it wants depending on its set of constructors and destructor. A class can be a value type (copied by value), act like a reference type, have an explicit free() method, or be a proxy value type that references a ref-counted object which destroys itself when the last reference in scope disappears. And that's not even mentioning the ability to template all of this and essentially create a mini programming language on top of C++.
Because of this variety, you are forced to study every single class to keep in your head exactly how it behaves during assignment and argument passing.

This results in multiple layers of mental pattern unfolding while reading code. Very high cognitive load.
Even if you add a rule to Orthodox C++ banning the use of class and constructors inside struct, it still doesn't save you from classes with diverse constructors coming from other libraries you use - because a library might provide an API where the class is designed as a proxy to a ref-counted object.
This would mean that such "Orthodox C++" needs its own separate repository of libraries, which is obviously absurd.

In light of this, using C++ even as "C+" just for namespaces and function overloading isn't worth the effort. Plain C is cognitively simpler: you know that all structs are copied by value, and the compiler simply won't accept anything else.