Orthodox C++

orthodoxc++.md

Orthodox C++

This article has been updated and is available here.

It's not easy to adhere to these tenets when using libraries written after modern C++ (including C++11, obviously).

It's not easy to adhere to these tenets when using libraries written after modern C++ (including C++11, obviously).

unique_ptr is huge issue in C++. It should not exist in the first place.

I agree that C++ has a lot of problems in its design stemming from the fact that the language is old and the standard comity is too reluctant to change things. I hate how a lot of features in C++ are often implemented halfway due to debate between contributors, such as how std::optional has no specialization for references because the comity couldn't agree on the behavior of the assignment operator. However, I don't think the solution is to go back in time and utilize older functionality. I think the solution is to create a successor language, create a library that wraps around and fixes the issues of the standard library, or switch to Rust. The problem is not with C++, but its rather with the standard template library. I have been messing around lately with rewriting parts of the standard library myself, and I have been surprised at how much easier it is to work with when you remove some of the more complicated "features". Why did they have to name the mersene twister random number generator such a weird and hard to remember name (std::mt19937)? In my opinion, simplification without the addition of new functionality is the best kind of improvement, and it would not take much to make C++ more bearable to work with.

No. The problem is the language itself. The exception handling was the language's biggest design failure.

Also, i do not quite buy the argument they do not change because the language is old. C++ as a capitalist imperialist product, it will always serve the interests of big capitalists. These capitalists write shit and that is why they keep promoting shit into the language, like std::format.

If you look at the history of exception handling, it was added not by fixing the issues of C++ but served the interests of big companies in 1990s (HP and Intel). The capitalists influence on C++ is why C++ sucks.

The changes we want as programmers never matter to WG21, we do not donate money to them. They only listen to capitalists. Again, you cannot work around for capitalism and you have to defeat it.

"*C++ as a capitalist imperialist product, it will always serve the interests of big capitalists.*" LMAO, couldn't skip on this one. You're welcome to introduce a communist/socialist made language. I bet it will replace C++ same way a soviet made tech once replaced the western counterpart(Surprise, it never did.The replier was born in the USSR). Cheers.

…

On Thu, Dec 28, 2023, 18:37 cqwrteur ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ I agree that C++ has a lot of problems in its design stemming from the fact that the language is old and the standard comity is too reluctant to change things. I hate how a lot of features in C++ are often implemented halfway due to debate between contributors, such as how std::optional has no specialization for references because the comity couldn't agree on the behavior of the assignment operator. However, I don't think the solution is to go back in time and utilize older functionality. I think the solution is to create a successor language, create a library that wraps around and fixes the issues of the standard library, or switch to Rust. The problem is not with C++, but its rather with the standard template library. I have been messing around lately with rewriting parts of the standard library myself, and I have been surprised at how much easier it is to work with when you remove some of the more complicated "features". Why did they have to name the mersene twister random number generator such a weird and hard to remember name (std::mt19937)? In my opinion, simplification without the addition of new functionality is the best kind of improvement, and it would not take much to make C++ more bearable to work with. No. The problem is the language itself. The exception handling was the language's biggest design failure. Also, i do not quite buy the argument they do not change because the language is old. C++ as a capitalist imperialist product, it will always serve the interests of big capitalists. These capitalists write shit and that is why they keep promoting shit into the language, like std::format — Reply to this email directly, view it on GitHub <https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b#gistcomment-4810208> or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADLBAF4EDOJV4T6MUFXANTYLWN4TBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFQKSXMYLMOVS2I5DSOVS2I3TBNVS3W5DIOJSWCZC7OBQXE5DJMNUXAYLOORPWCY3UNF3GS5DZVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVAZTAMJQGMZDAMNHORZGSZ3HMVZKMY3SMVQXIZI> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

We're discussing the practical realities of the real world here, not delving into idealistic notions of socialism or communism.

The truth is, decisions made within WG21 predominantly cater to the interests of large international corporations. If these corporations have a plethora of issues to contend with, such as exceptions for bad_alloc or an overreliance on object-oriented programming, meaningful change becomes unlikely.

Should WG21 cease to serve the interests of these corporations, it's plausible that the organization would dissolve, or its leader might be strategically removed to safeguard those interests. This aligns with the principles of historical materialism. Much like World War II would have occurred without Hitler, the functioning of the US empire remains consistent regardless of whether Donald Trump or Joe Biden assumes the presidency.

In essence, WG21 has become an arena dominated by these major corporations. For instance, while Google advocates for an ABI break, other corporations may resist. Our opinions and expressions carry minimal weight in this scenario.

You mentioned "historical reasons," and this is precisely one of them. What you and I may criticize about the language is inconsequential.

To begin with, they are unlikely to heed our concerns. They disregarded them 30 years ago, and the situation remains unchanged. Had they been receptive, issues like permitting HP to incorporate exception handling in the manner they did 30 years ago would have been avoided. Similarly, if they were attentive, freestanding would not have lacked ::std::addressof until C++23, as Nvidia desired. Even in C++26, std::array remains absent in the freestanding context. The addition of features like std::filesystem, marred by dual error reporting mechanisms, stands as another testament to their lack of heedfulness.

Bjarne himself is clearly a big fan of bourgeois democracy and believes democracy fixes everything. While in reality, it is just another kind of dictatorship.

I actually believe that C++ is communist. C++ is corner stone of Linux community, and everyone knows supporters of the free software movement are communist. It may as well be renamed to Communist++.

Don't let me even get started on JavaScript...

Free software has nothing to do with communism.

Whatever, C++'s history is always big corporation controlled. It is a fact and nobody should deny. If you look at how they vote in ISO, only big companies are allowed to vote. And companies like IBM had a long history of pushing C++ to support many legacy nonsenses, like EBCDIC execution charset.
If no one funds the WG21, it would just collapse.

The feature we as individual programmers need do not align with big corporations.

@bkaradzic hi,

After using Orthodox C++ standard for a few years, I can say the rule to allow new C++ features should probably be reworded in a different way.

• "Due to lag of adoption of C++ standard by compilers, OS distributions, etc. it's usually not possible to start using new useful language features immediately. General guideline is: if current year is C++year+5 then it's safe to start selectively using C++year's features." - Orthodox C++

I don't think this rule is strict enough.
My reasoning is, in the statement you mainly provide a safety clause for ensuring people don't use unstable features.
While that is good, I don't think that's as specific as it should be.
Mainly because the problem of using modern features only bare their face after a few years of overusing them in your codebase.

For example:

• Lambdas from your example, destroy compilation speed, and increase memory consumption of supporting tools like LSPs (clangd specifically).
• Similarly constexpr functions also slow compilation, and severely increase memory consumption for LSPs.
• Templates are also problematic, but we can use extern templates to make them usable, while still remaining fast to compile.

As I've observed, everything in modern C++ over-complicates the language, and slows down compilation.

All in all, if one allows modern C++ features without warning about the potential dangers of those features, and/or how to safely use them, then, I don't think it is Orthodox anymore, as they would need to depend on new standards (--std=c++11 --std=c++14 etc), and anyone could use bad modern features like std::ranges and think they're being safe.

Thanks.

@aerosayan What would you suggest doing, then ? Stay on C++98 ? It seems quite obvious that most of the things you are complaining about are just as present there, along with bigger footguns that the more recent standards have actually managed to remove over the years.

@GabrielRavier , I think most things that were included after C++11, are a mistake.

C++11 seems to be good enough for most things.

Though I should point out, that my aversion to modern features is due to unintended side effects, and not for the language version.

For example:

• Almost all C++ devs heavily promote smart pointers, as they're supposed to be safe.
• However, almost no one mentions that std::shared_ptr uses atomic locks and atomic addition internally for reference counting, so for critical software engineering, like scientific code development in my case, std::shared_ptr are harmful, as they'll degrade performance, but it will be extremely difficult, or even impossible, for us to find the cause of it.

If a team knows what is best for them, they can use whichever feature they want.

GCC and clang should introduce new switch: /orthodox

GCC and clang should introduce new switch: /orthodox

@DBJDBJ what would the flag do ?

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! 👍