I have no constructor, and I must initialize

https://consteval.ca/2024/07/03/initialization/

by cyber1 • 2 years ago

325 226 2 years ago

jakewins3• 2 years ago

Man I get vertigo reading this. Reminds me of trying to understand Java constructors and object initialisation.

It’s been a while now, and at least in my experience so far Go and Rusts choice of not having special constructors really simplifies a lot.

Is there anyone that’s had the experience of missing constructors once you swapped away from them?

_ZeD_• 2 years ago

dude, java constructor are easy... that C++ stuff is really black magic

and from what I understand rust constructors are basically the same as java, no?

masklinn3• 2 years ago

Rust does not have constructors at all[0], it uses factory functions (conventionally named `new_somethignsomething`) but those are not special to the language.

[0] except in the more generalised haskell-ish sense that structs or enum variants can be constructed and some forms (“tuple structs” and “tuple variants”) will expose an actual function

mmaniac• 2 years ago

Rust doesn't have constructors. By convention, a static method called new returns a struct - no magic.

jakewins3• 2 years ago

I think if you think constructors in Java are easy, you are much, much smarter than I am or have missed some really, really subtle footguns.

Eg:

- Java constructors can return the object before they complete construction, finishing at a later time; this is visible in concurrent code as partially constructed objects

- Java constructors can throw exceptions and return the partially constructed object at the same time, giving you references to broken invalid objects

- Just.. all the things about how calling super constructors and instance methods interleaved with field initialization works and the bazillion ordering rules around that

- Finalizers in general and finalizers on partially constructed objects specifically

I don't in any way claim it's on the same level as C++, but any time I see a Java constructor doing any method calls anymore - whether to instance methods or to super constructors - I know there are dragons

DougBTX• 2 years ago

Inside a constructor you can access a partially initialised "this" value, and even call methods on it, which leads to rules like: "Do not call overridable methods in constructors"[0], as they can lead to surprising, non-local, bugs.

Rust has functions associated with types which are conventionally used like constructors, but critically the new objects must have all their fields provided all at once, so it is impossible to observe a partially initialised object.

[0] https://learn.microsoft.com/en-us/dotnet/fundamentals/code-a...

masklinn3• 2 years ago

There are a few somewhat esoteric cases where constructors working in-place allow magic which can be hard to replicate otherwise e.g. Rust is still missing guaranteed “placement new” type behaviour.

Unless you want to `ptr::write` individual fields by hand into a `MaybeUninit`, which you can absolutely do mind but that… is not very ergonomic, and requires structs to be specifically opted into this.

wongarsu2• 2 years ago

Which can be an issue if you want to initialize a 2MB large heap-allocated object (e.g. heap-allocating a large nested struct or a big array).

Without guaranteed “placement new” that can mean that your 2MB object gets constructed on the stack and copied to the heap. And while Linux defaults to a 4MB stack, Windows defaults to 1MB and will crash your program. Or it might work if the compiler optimizes in your favor.

It's not something you encounter frequently, it can be worked around, and Rust will eventually solve it ergonomically without introducing constructor hell (probably with just a keyword). But finding the best language-level solution isn't straightforward (efforts to fix this for rust are ongoing for 9 years)

throwawaymaths• 2 years ago

I mean go's zero initialization requires a bit of language lawyering sometimes too.

https://codefibershq.com/blog/golang-why-nil-is-not-always-n...

chipdart8• 2 years ago

It’s been a while now, and at least in my experience so far Go and Rusts choice of not having special constructors really simplifies a lot.

This take makes no sense. Think about it: you're saying that not having the compiler do any work for you "really simplifies things a lot". Cool, so you have to explicitly declare and define all constructors. That's ok. But think about it, doesn't C++ already offer you that option from the very start? I mean, you are talking about a feature in C++ that is not mandatory or required, and was added just to prevent those programmers who really really wanted to avoid writing boilerplate code to lean on the compiler in and only in very specific corner cases. If for any reason you want the compiler to do that work for you, you need to be mindful of the specific conditions where you can omit your own member functions. For the rest of the world, they can simply live a normal life and just add them.

How is this complicated?

Complaining that special member functions make obvious things less simple is like complaining that English is not simple jus because you can find complicated words in a dictionary. Yes, you can make it complicated if that's what you want, but there is nothing forcing you to overcomplicate things, is there?

tyg133• 2 years ago

You're mistaken. Rust does not require you to define all constructors. Rust does not have constructors.

All structs in Rust must be initialized using brace syntax, e.g. `Foo { bar: 1, baz: "" }`. This is commonly encapsulated into static functions (e.g. `Foo::new(1, "")`) that act similarly to constructors, but which are not special in any way compared to other functions. This avoids a lot of the strangeness in C++ that arises from constructors being "special" (can't be named, don't have a return type, use initializer list syntax which is not used anywhere else).

This combined with mandatory move semantics means you also don't have to worry about copy constructors or copy-assignment operators (you opt into copy semantics by deriving from Clone and explicitly calling `.clone()` to create a copy, or deriving from Copy for implicit copy-on-assign) or move constructors and move-assignment operators (all non-Copy assignments are moves by default).

It's actually rather refreshing, and I find myself writing a lot of my C++ code in imitation of the Rust style.

jakewins3• 2 years ago

How is this complicated?

Here are some ways:

- As a junior programmer, it made the language harder to learn. Language complexity increases super-linearly as each new feature has rules of interaction with several existing features

- Although one eventually learns to avoid the anti-features, you cannot control the actions of others. These features meant to help save keystrokes are happily employed every day, producing hard to read code

Particularly when writing library code for other to use or when maintaining large codebases shared by hundreds of engineers, my experience is that complex features in the language end up used by junior engineers or require consideration in API design.

marton78• 2 years ago

After almost 20 years of experience with C++, there are still some gnarly details I wouldn't have imagined. What a God awful language!

Kudos to that author for the great, eye catching title and the in depth detail!

unwind• 2 years ago

In case it's not known to everyone, the title is an obvious nod to "I Have No Mouth, and I Must Scream" [1], a 1960s US sci-fi story by Harlan Ellison.

1: https://en.wikipedia.org/wiki/I_Have_No_Mouth,_and_I_Must_Sc...

bookofjoe2• 2 years ago

https://talesofmytery.blogspot.com/2018/10/harlan-ellison-i-...

_vaporwave_• 2 years ago

That plot summary is... dark. Does anyone know how long the story is? Most of the copies I found online are collections of short stories.

tannhaeuser• 2 years ago

The question is which IHNMAIMS character the poster identifies with to have deserved his OOP misery, given all protagonists are imprisoned for life (or for eternity, actually, I believe) as a sentence for the bad things they did ;) Note there's also the adventure game created after the book, overseen and with a script also by Ellison.

tpoacher• 2 years ago

pc adventure game was good too (i.e., messed up)

shadowgovt6• 2 years ago

I assume AM is filled with so much hate because it's just three billion lines of C++.

wavemode3• 2 years ago

Always obligatory https://mikelui.io/img/c++_init_forest.gif

CoastalCoder2• 2 years ago

Thanks, I'd never seen that one!

So horrifyingly true.

queuebert• 2 years ago

I should print this and put it on my wall for all those times when I'm frustrated with Rust lifetimes.

GuB-422• 2 years ago

C++ is a popular multi-paradigm language that is both cutting edge and 40 years old (more if you count C), there is simply no way around that level of complexity.

You have "C with classes" that coexist with the "modern" way, full of smart pointers and functional programming. It is popular in embedded systems, video games, servers, and GUIs (mostly Qt). And if you look at the code, it is as if it was a different language, because the requirements are all very different. Embedded system need low level hardware access, video games are all about performance, servers want safety, and GUIs want flexibility.

There are less awful alternative to C++. For example C on one end of the spectrum and Rust on the other end. But none of them cover every C++ use case.

hu3• 2 years ago

Zig looks promising too.

marcosdumay3• 2 years ago

multi-paradigm

Well, it does unstructured imperative, structured imperative, and OOP imperative!

Except if you count template programming, because that one is pure functional, but only runs at compile time.

bee_rider3• 2 years ago

C++ needs a different name from multi-paradigm. Java is a multi-paradigm language. C++ is an omni-paradigm language. If there’s a paradigm,

- There’s at least an ugly library to do it in C++

- There might be support baked directly into the language

- Or you could do it in Lisp, but that would be too easy

aaroninsf• 2 years ago

But none of them cover every C++ use case.

Literal lol... this is not an argument in favor of C++.

slashdave• 2 years ago

I would sort of agree, except when c++ was invented, it was even more awful in practice (does anyone remember the chaos around STL and template caches?). So, age isn't really a factor.

wredue2• 2 years ago

If you’re looking for a language with less complexity than C++, you’re surely not going to find that in rust.

ghosty141• 2 years ago

I've been working with C++ at my job for 2.5 years now and I've already come to this conclusion. Wouldn't wanna use it if there is any other way.

The fact that you can do almost anything IS pretty cool, but without having at least one C++ wizard at hand it can drive you nuts.

ryandrake• 2 years ago

Just another person’s opinion: I’ve been using C++ for my entire career, and to be honest, if I’m starting a new solo project, I reach for it unless there is some major technical reason not to. Yes, it can be messy. Yes, there are footguns. But as a developer, you have the power to keep it clean and not shoot the footguns, so I’m still ok with the language.

If I was starting a new work project with a lot of junior team members, or if I was doing a web project, or a very simple script, fine I’ll use a different language. There can definitely be good reasons not to use C++. But I’m at the point in my expertise that I will default to C++ otherwise. I’m most productive where I am most familiar.

philsnow2• 2 years ago

I don’t think I’ve ever gotten paid for a line of c++ but Google has a “style guide” for internal c++ code that omits something like 3/4 of the language, and people seemed pretty happy with it overall. Maybe not “happy” but “grudgingly accepting because it beats the Wild West alternative”.

FreezerburnV• 2 years ago

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” - Bjarne Stroustrup

Not disagreeing that C++ is awful in a lot of ways and super difficult though. But I still weirdly like it, personally. I find it a fun challenge/puzzle to work with.

zarathustreal2• 2 years ago

I find it annoying to have to solve a puzzle to make progress solving my intended puzzle (i.e. whatever I’m computing)

umanwizard3• 2 years ago

I think we can say Rust is beyond the “nobody uses” stage by now, and it’s much simpler and easier than C++. (And people who use it tend to like it, proving Bjarne wrong).

diffxx• 2 years ago

I truly loathe that quote. It is a tautology that is used to deflect legitimate criticism.

catlifeonmars2• 2 years ago

I feel that if the language is a challenge to work with, it better give you your money’s worth. In 2024, there are plenty of other languages with better ROI, if you want a challenge.

In any case, I think the primary goal of any programming language is to get out of your way and let you tackle more interesting problems related to the problem domain that led you to start writing a program in the first place.

nottorp2• 2 years ago

a fun challenge/puzzle to work with

You're basically saying the language gets in the way of solving your problem :)

qsdf38100• 2 years ago

So you hate C++. Great, thanks for your informative insights.

echelon2• 2 years ago

A language shouldn't be this complicated. This is dangerous and impossible for teams full of juniors and busy people with deadlines. We're only human.

082349872349872• 2 years ago

I believe those teams just use constructors; this is a corner case, not SOP.

echelon2• 2 years ago

C++ should start pulling things out of the language with new editions. It would improve quality of life dramatically.

dataflow• 2 years ago

They can't pull the rug out now, but I highly recommend making your own clang-tidies to flag confusing constructs (like defaulted out-of-line constructors) and preventing them from being committed.

gosub100• 2 years ago

My guess is all these details are necessary to provide C++ "strong exception guarantee" against partially constructed objects. Perhaps if your member objects can throw exceptions, some of these pedantic initialization rules can come to the rescue and allow, say, a library implementor to limit initialization code to places where exceptions can be handled.

bun_terminator2• 2 years ago

True, however in practice this is rarely an issue. You usually only use a tiny subset of construction rules. And if you ever make a mistake, they are easily caught by static analysis tools.

smackeyacky• 2 years ago

It’s quite a big issue. It’s actually a bit worse than the article makes out if you throw static objects into the mix and get race conditions where you don’t know which objects get constructed first. C++ has to be approached with caution even by experienced devs.

dathinab3• 2 years ago

it being this complicated can be fine (if there isn't too much of it)

but only if not knowing how the complicated parts work doesn't create any subtle issues and has reasonable compiler time errors and isn't fundamental needed to write any code

Because then you can use the language without needing to know how exactly that complexity works and if you get it wrong you get a reasonable compiler error. And then decide to either spend some time to learn what you didn't know or you just write the code differently. But in either case you don't have a situation with a unexpected runtime error which should be impossible and where you have no good way to know where to even start looking.

dathinab3• 2 years ago

its funny how people are down voting this when it's exactly the approach rust uses

jjmarr• 2 years ago

Working as a junior in a C++ codebase is great for my career because the skill floor is so high. Because it's so difficult to do anything there's a lot of room to distinguish myself.

No other language creates as many problems for programmers as C++.

userbinator• 2 years ago

I've come to the conclusion that most if not all the complexity is largely to justify the existence of those who work on "moving the language forward".

wateralien• 2 years ago

Upvote for the title.

gattilorenz• 2 years ago

What an beautiful blog theme, obviously inspired by the DEC-era computers but also clean and minimal. Refreshing!

imperialdrive• 2 years ago

Ditto

georgestagg• 2 years ago

I like how the rules to the right of the headings react to the page width and how many lines are used.

kazinator• 2 years ago

Otherwise, zero-initialize and then default-initialize.

That can't be right ... is it? Things cannot be initialized twice. Isn't it more like "Otherwise, recurse the value-initialization over the bases and members". Then, those that are not classes or arrays get zero-initialized.

SpaghettiCthulu2• 2 years ago

I think it would be perfectly legal to zero-initialize the entire thing and then default-initialize, because initialization assumes the value is undefined.

bregma• 2 years ago

                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    You can only initialize once. After it's been initialized you're just assigning values, and that's not what happens during initialization. It's either a misunderstanding on behalf of the author or the words as written are not conveying the correct idea.

leni536• 2 years ago

Both "zero-initialize" and "default-initialize" are terms that have precise definitions. In this context if you substitute the definitions it just means first zero-initializing the non-static data members (and zeroing the padding), then calling the default constructor.

It doesn't mean that the lifetime of the object starts twice, or anything weird like that.

3l3ktr4• 2 years ago

This is the best title, OP.

gpderetta3• 2 years ago

[...] The printed result would be 0. This is because we value-initialize t and, since T has a non-user-provided default constructor, the object is zero-initialized (hence t.x is zero-initialized) then default-initialized (calling the implicitly-defined default constructor, which does nothing).

T̶h̶a̶t̶ d̶o̶e̶s̶n̶'t̶ s̶e̶e̶m̶ c̶o̶r̶r̶e̶c̶t̶:̶ a̶ d̶e̶f̶a̶u̶l̶t̶e̶d̶ c̶o̶n̶s̶t̶r̶u̶c̶t̶o̶r̶ s̶t̶i̶l̶l̶ d̶e̶f̶a̶u̶l̶t̶-̶i̶n̶i̶t̶i̶a̶l̶i̶z̶e̶s̶ t̶h̶e̶ m̶e̶m̶b̶e̶r̶s̶, n̶o̶t̶ v̶a̶l̶u̶e̶ i̶n̶i̶t̶i̶a̶l̶i̶z̶e̶. I̶ d̶o̶n̶'t̶ t̶h̶i̶n̶k̶ t̶h̶e̶r̶e̶ i̶s̶ a̶n̶y̶ d̶i̶f̶f̶e̶r̶e̶n̶c̶e̶ b̶e̶t̶w̶e̶e̶n̶ d̶e̶f̶a̶u̶l̶t̶i̶n̶g̶ i̶n̶l̶i̶n̶e̶ a̶n̶d̶ o̶u̶t̶ o̶f̶ l̶i̶n̶e̶. G̶C̶C̶ s̶e̶e̶m̶s̶ t̶o̶ a̶g̶r̶e̶e̶:̶ h̶t̶t̶p̶s̶:̶//g̶c̶c̶.g̶o̶d̶b̶o̶l̶t̶.o̶r̶g̶/z̶/r̶4̶r̶e̶5̶T̶E̶5̶a̶

edit: I missed that the author is actually value-initializing x!!! The result definitely violates expectations!

Generally, the details of the rules are arcane and sometimes have non-sensical dark corners having been extended and patched up for the last 40 years. But 99.9%[1] of the time you get what you expect.

I big improvement would be making default initialization explicit, and otherwise always value initialize. Explicit value initialization is so common that the very rare times I want default initialization (to avoid expensively zeroing large arrays) I need to write a fat comment. Writing "std::array<int, 100> = void;" (or whatever the syntax would be) would be much better.

[1] I had an extra 9 here... I hedged.

adrianN• 2 years ago

Once every thousand lines you don’t get what you expect? Rip

gpderetta3• 2 years ago

Once every 1000 initializations. But hey, I would sign up for only one bug every 1000 lines.

chipdart8• 2 years ago

I big improvement would be making default initialization explicit

Actually initializing your instances, which is what's expected of every single instantiation, is enough to not experience any problem. This also means that if you want to call a constructor, you need to define it.

This is a case of people trying to be too clever for their own sake, and complaining that that's too much cleverness for them to handle.

hwc• 2 years ago

I'm so glad I use Go more than C++ these days. In Go, all values are always zero-initialized if you don't explicitly assign a value. If you need a constructor, you write a regular function that returns an explicitly assigned object.

I like keeping the rules of the language simple enough that there is never any confusion.

javierhonduco2• 2 years ago

Personally I’m not a fan of Go’s default zero-initialisation. I’ve seen many bugs caused by adding a new field, forgetting to update constructors to intialise these fields to “non-zero” values which caused bugs. I prefer Rust’s approach where one has to be explicit.

That being said it’s way less complex than C++’s rules and that’s welcomef.

ErikBjare• 2 years ago

Haven't written Go in a long time, but I do remember being bit by this.

zarathustreal2• 2 years ago

Yea this can be problematic if you don’t have sum types, it’s hard to enforce correct typing while also having correct default / uninitialized values.

maccard2• 2 years ago

I spent a year and a half writing go code, and I found that it promised simplicity but there an endless number of these kinds of issues where it boils down to "well don't make that mistake".

crowdyriver• 2 years ago

You can always use exhaustruct https://github.com/GaijinEntertainment/go-exhaustruct

to enforce all fields initialized.

If you care, the linter is there, so this is more of a skill issue.

catlifeonmars2• 2 years ago

FWIW there is a linter that enforces explicit struct field initialization.

dgfitz3• 2 years ago

Wouldn’t it just be considered bad practice to add a field and not initialize it? That feels strongly like something a code review is intended to catch.

kccqzy4• 2 years ago

The problem you are describing in Go is rarely a problem in C++. In my experience, a mature code base rarely has things with default constructors, so adding a new field will cause the compiler to complain there's no default constructor for what you added, therefore avoiding this bug. Primitive types like `int` usually have a wrapper around them to clarify what kind of integers, and same with standard library containers like vector.

However I can't help but think that maybe I'm just so fortunate to be able to work in a nice code base optimized for developer productivity like this. C++ is really a nice language for experts.

thowruasdf• 2 years ago

The downside is now all types must dogmatically have a nullary constructor.

The Default typeclass (or trait) as seen in Haskell and Rust, is a far better design, as this makes the feature opt-in for data types that truly support them.

kccqzy4• 2 years ago

Don't even need to go that far. In C++ it is common to delete the default constructor anyways. So that achieves the opt-in.

jeffbee3• 2 years ago

Go makes a completely reasonable tradeoff, giving away performance to gain ease of use. C++ also makes a tradeoff that seems reasonable or necessary to its users, that it makes it possible to not be forced to write to the same class member twice, in exchange for a more complex language. Any language that attempts to offer this property unavoidably adopts the complexity as well. See, for example, Java.

AlexandrB• 2 years ago

For more C++ wackiness, I recommend the C++ FQA: https://yosefk.com/c++fqa/

It's 15 years out of date now, but also timeless since C++ rarely/never removes old features or behaviours.

bookofjoe2• 2 years ago

I Have No Mouth, and I Must Scream (1967)

https://talesofmytery.blogspot.com/2018/10/harlan-ellison-i-...

e40• 2 years ago

Came for this. I once talked with Harlan Ellison. He called my house when I was 17. At 2am. This was in the days of sharing a phone via a 30ft cord and taking it into your bedroom and closing the door. As teenagers would do. Martin H Greenberg and his family were staying at our house. He was calling for Martin. I was big into SciFi and had read a few of his books. The conversation was odd. I said Martin was asleep and asked who he was. Everything after hearing his name was sort of a blur. Yes, I did wake Martin and hand him the phone. It was hard to sleep after that.

jolj2• 2 years ago

Is there a C++ tool that adds/shows all the implicit stuff that happens behind the scenes?

Such as all the constructors that are being added, implicit copy constructor and all the other surprises?

fouronnes32• 2 years ago

Best you're gonna get is a combination of godbolt and cppinsights.

jolj2• 2 years ago

cppinsights looks like what I was looking for, there's even a vscode extension thanks

sixtram• 2 years ago

Great link, I'm going to add this to my list of favorite interview questions. (^_-)

jeffbee3• 2 years ago

I agree there is a lot of complexity in C++ in the year 2024, however I feel that much of the appearance of complexity around initialization is due to the pedantic, dogmatic use of the word "default" by the committee to mean "not".

amluto• 2 years ago

I’m surprised there were no snarky comments about:

So, here’s the glue between list-initialization and aggregate initialization: if list-initialization is performed on an aggregate, aggregate initialization is performed unless the list has only one argument, of type T or of type derived from T, in which case it performs direct-initialization (or copy-initialization).

The word “unless” is even bold.

We have fancy syntax:

    T t{v0};

And we also have:

    T t{v0, v1};

And so on. But the one-element case does not reliably work like the 2+-element case. And this is in a language that increasingly works toward making it straightforward to create a struct from a parameter pack and has support for variable length array-ish things that one can initialize like this. And the types can, of course, be templated.

So you can write your own constructors, and you can initialize a tuple or array with only one element supplied, and you might trip over the wrong constructor being invoked in special cases.

I remember discovering this when C++11 initializer lists were brand new and thinking it was nuts.

TinkersW2• 2 years ago

Initializer lists is irreverent, nobody uses it anyway. Other than a few standard containers that use it, you can completely ignore the silly thing.

alex_lav5• 2 years ago

As is the nature of bad design, “nobody uses it other than some people sometimes” is a silly sentiment and indicative of a problem.

Maxatar4• 2 years ago

That's the biggest problem with them. Something isn't as dangerous when it's in your face and you need to confront it on a regular basis. What's dangerous are the things that rarely need to think about, except for that very rare moment when it bites you in the ass precisely because it's not on your mind.

shadowgovt6• 2 years ago

I've definitely seen initializer lists recommended as best-practice in safety-critical code.

vsgherzi• 2 years ago

this has got to be one of my favorite blog names i've seen on this site

pierrebai• 2 years ago

The article is just plain wrong about classes: if you have declared any constructor, then the language will not provide a default constructor and default-initialization will fail with a compiler diagnostic.

So their claim that "T t;" will "do nothing" is incorrect.

    class T
    {
    public:
        T(int);
    };
    T t;

Will fail.

shadowgovt6• 2 years ago

I think I missed where in the article they did a `T t;`... Doesn't seem to show up with an eyeball scan?

vitus4• 2 years ago

In the first few paragraphs:

Primarily, there are two kinds of initialization of concern: default-initialization and value-initialization. The rules given in the standard look roughly like this:
* For any type T, T t; performs default-initialization on t as follows: ...

As GP mentions, the article's descriptions of default and value initialization are both incorrect for classes that do not have default constructors, as that code will simply not compile.

wavemode3• 2 years ago

I'm confused at how your comment is relevant to this article. Here you've written `T(int);`, i.e. a constructor with an argument. None of the classes declared in the article have a constructor that takes any arguments. Nor does the text of the article seem to make any statement which contradicts what you've asserted here. And all of the examples in the article compile successfully.

OptionOfT• 2 years ago

    T::T() = default;

> You’d expect the printed result to be 0, right? You poor thing. Alas—it will be garbage. Some things can never be perfect, it seems. Here’s a relevant excerpt from our description of value-initialization:

Link: https://consteval.ca/2024/07/03/initialization/#:~:text=You%...

That actually isn't that weird, because it would allow any consumer of your library to change how your library behaves.

Twisol• 2 years ago

The alternative not making sense doesn't automatically make this solution make sense :( It just highlights how many corners C++ has backed its design into.

nxobject• 2 years ago

As an aside, I see that DEC front panel you've got there in your blog header.

shadowgovt6• 2 years ago

Realizing the spec for C++23 is about two-and-some-change-times the length of the King James Bible has really reframed my thinking on this language.

For good or for ill, I don't really trust anything that long to be something the average human can wrestle down. And when you mix in undefined behavior and the fact it's still used on safety-critical systems... It's a bit horrifying really.

CRConrad2• 2 years ago

Realizing the spec for C++23 is about two-and-some-change-times the length of the King James Bible has really reframed my thinking on this language.

I wonder how much shorter the spec for a radically simplified version of C++ -- say, one that zero-initializes everything, and has no default constructors ("not writing a constructor raises an error" or something) -- would be? 5% 50? 95...?

MathMonkeyMan• 2 years ago

Show me someone who understands the rules, and I'll show you a compiler engineer... who probably doesn't understand the rules.

gnarlouse• 2 years ago

this title makes me want to shout

"Call J. G. Wentworth, 877 Cash Now!"

nickysielicki5• 2 years ago

The whole thing is wrong. Don’t put const references in your structs. Use std::reference_wrapper if you must.

Edit: this response is a bit dismissive but honestly my main beef with this article is that its conclusion is just straight up wrong. Do not write your own constructors, do follow the rule of 5/3/0, and if you find yourself needing to hold a const reference, you should look out for whether you’re passing in an rval temporary… none of this is really scary.

forrestthewoods• 2 years ago

I’ve never used std::reference_wrapper in my life. Nor have I seen it used in any of the numerous C++ code bases I’ve worked in. Although I’m sure it’s used in deep, gnarly template BS.

Your statement may be correct! But it’s certainly not common knowledge in my experience.

shrimp_emoji• 2 years ago

I use them now and then -- and I never touch templates. It's just a reference you can reassign. Or, in other words, truly a pointer that can't be null. :D (And that you can actually use in collections that require reassignable types.)

nickysielicki5• 2 years ago

My stance is just based on cpp core guidelines:

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

std::reference_wrapper still can’t save you from yourself, but it’s better than violating the first link and ending up in this limbo that OP is talking about.

See also: https://youtu.be/YxSg_Gzm-VQ (about 3:30 in)

Guvante• 2 years ago

If you want to use assignment operators with references that is what it does.

Nothing else.

chipdart8• 2 years ago

Edit: this response is a bit dismissive but honestly my main beef with this article is that its conclusion is just straight up wrong.

That's my take as well. The blogger clearly went way out of his way to find something to whine about while purposely ignoring a few of the most basic principles and guidelines.

In the meantime, everyone who ever went through a basic tutorial just casually steps over these artificial scenarios.

Too• 2 years ago

Rule of 5/3/0 is about destructors, move and copy constructors. Apart from the last example, the article mainly talks about quirks with the standard constructor, if you can call it that.

nickysielicki5• 2 years ago

main takeaway of the article according to the author, quoting:

In my humble opinion, here’s the key takeaway: just write your own fucking constructors! You see all that nonsense? Almost completely avoidable if you had just written your own fucking constructors. Don’t let the compiler figure it out for you. You’re the one in control here. Or is it that you think you’re being cute? You just added six instances of undefined behaviour to your company’s codebase, and now twenty Russian hackers are fighting to pwn your app first. Are you stupid? What’s the matter with you? What were you thinking? God.

The problem with C++ and the danger with an article like this is someone might actually follow this advice, instead of eg: the core guidelines.

Every other example is a violation of the core guidelines in some form or another. There is no other problem.

IAmLiterallyAB2• 2 years ago

Horrific. One of the things that scares me about C++. A real shame because it has some cool features and some brilliant minds working on it.

I'm hoping something like Herb's C++ syntax 2 will make the language useable for mortals like me.

chipdart8• 2 years ago

Horrific.

I think you're whining about something that doesn't pose any problem to anyone with any passing experience in software development.

The examples in the blog post boil down to far-fetched cases devised to trigger corner-cases of a feature where a programming language in exceptional cases auto-generates specific functions when programmers somehow explicitly decided not to do it themselves. The blogger then proceeds to explore edge conditions that lead these exceptional cases to either be enabled or disabled.

In the meantime, be mindful of the fact that this is about a language with a clear design goal of paying only for what you use,and also the widely established rule of 3/rule of 5, which is C++101 and states that when anyone defines one of these special member functions, they should define them all. Why? Because it's C++101 that these special member functions are only generated by the compiler in specific corner cases, and given their exceptional nature the compiler will not generate them automatically if any of the requirements is not met.

Therefore, any programmer who goes through the faintest introduction knows that they have to set the constructors they will use. Is this outlandish?

Also, does it catches anyone by surprise that you need to initialize instances when you instantiate them? Is this too much of a gotcha to justify being called "horrific"?

I think people like you just feel the need to have something to complain about. In the meantime, everyone in the real world happily does real work with them without any fuss.

quietbritishjim• 2 years ago

Are you joking? The profusion of initialisation types and exceptions to those rules (and exceptions to those exceptions...) absolutely pose a practical problem to all C++ programmers everywhere.

IAmLiterallyAB2• 2 years ago

I think people like you just feel the need to have something to complain about

Thanks for the ad hominem

I have no constructor, and I must initialize

Related Stories