Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Initialization in C++ is Seriously Bonkers

mikelui.io

Post reply on HN
Print view View original

41–50 of 130 posts

Re: Initialization in C++ is Seriously Bonkers

#41

Post by slavik81 »

xyzzyz wrote: post #16
tines wrote: post #5

In my view this author falls into the camp of people calling C++ a mess because it gives them too much control when they ask for it. One of his examples which he calls "The Abyss": #include struct A { A(std::initializer_list l) : i(2) {} A(int i = 1) : i(i) {} int i; }; int main() { A a1; A a2{}; A a3(3); A a4 = {5}; A a5{4, 3, 2}; std::cout which outputs: 1 1 3 2 2 he claims to be mysterious but is actually pretty r…

> a2: An empty initializer list should reasonably behave like a default constructor, and a default constructor should be more efficient than processing an initializer_list, so ctor 2 is called. Yes, initializer list with empty initializer list should behave same as empty constructor, and if it doesn’t, it’s really bad style. However, if both are defined, then if you are constructing an object with empty initializer l…

But a2 isn't an empty initializer list. A{} is the same as A(). You could use A{} even if there was no initializer list constructor. The squiggly brackets are from uniform initialization: a feature created to avoid the ambiguity between zero-argument constructors and zero-argument function declarations.

Unfortunately, std::initializer_list created a new ambiguity, so it's only an initializer list if it doesn't match an existing constructor.

Re: Initialization in C++ is Seriously Bonkers

#42

Post by maxxxxx »

williamdclt wrote: post #40
logimame wrote: post #3

Earlier quoted context omitted.

I always think C/C++ is not a good first language to teach, because you need to understand some general concepts about computer systems before diving in. Probably more than half of the beginners in their first C class give up when handling pointers/arrays - it's not because the concept is hard, but because they have no idea what the "memory" in the computer actually is and how it works. You're left with a naive analo…

I learnt C as a first language, and those computer sytems concept were explained as we go. It's not that hard to understand what memory is and that variables values are stored there, and I've had no problem with pointers. And the big advantage is that when you understand those concept and pointers, there's no magic in other languages (value/reference parameters, objects, functions as first-class citizens)

Totally agree. Knowing C and a little assembly takes out the magic from other higher level languages. That's a good thing.

Re: Initialization in C++ is Seriously Bonkers

#43

Post by monocasa »

ajross wrote: post #38
waynecochran wrote: post #35

Earlier quoted context omitted.

It’s the C runtime that zeros it, not the OS. That’s my main point. The OS may initialize too, but that is outside the standard.

On oddball platforms it might be (though I think there's some quibbling as to whether the C runtime in such an environment is really distinct form "the OS"). It's not on Linux. The .bss segment becomes an anonymous mmap which is zeroed by the kernel when first accessed. Glibc never touches it. (Edit to correct: obviously glibc "touches" .bss because it has its own static variables. But there's no "zero .bss" step in…

I mean, there's probably more shipped units of "oddball systems" than there are of Unix-like multi process systems that have to wipe segments like .bss vracuse of their security model. So it's not like it's some pedantic corner case like you're implying.

And there are other parts of the C standard that would just declare 'implementation defined', so the standard doesn't have to say static duration is initialized just because that's what multi process systems do.

Re: Initialization in C++ is Seriously Bonkers

#44

Post by MikeLui »

Author here--some extra context to add:

The post was mostly written to point my students to, so I don't have to keep repeating myself. I get a not-insignificant number of 1st, 2nd, and 3rd years (in a 5-year program) believing C is some antiquated language and believing that they're getting held back in some way by learning C vs C++. One even suggested the department was incompetent for not teaching C++. Because I work in an engineering department, many students have not had a great deal of time learning programming fundamentals early on and regardless, they are eager to learn more advanced tools than they are ready to use. It is a bit rambling for the purpose--I have a tendency to...erm, overwhelm...with information to make my point.

I haven't blogged much so I originally submitted it at lobste.rs[1] for any advice on the writing and visual style of the site. I welcome any constructive feedback. E.g. "I hate that side-nav! It keeps popping in and out!"

Also to clarify, I am not anti-C++ is anyway. I am a firm practitioner of Chesterton's fence[2] and believe in nuance. That cuts both ways. C++ is the way it is because it filled a specific need. It's greatest flaw is trying to appease everyone and, recently, trying to catch up quickly to recent QoL features in other languages. This fortunately gives it a lot of features other languages don't have, and it unfortunately gives it a lot of features other languages don't have.

Once again, the greater point being a warning, that C++ can easily become a time sink in language-specific knowledge instead of domain-specific knowledge. Of course sometimes that's what you want, e.g. when trying to optimize for performance.

[1]: https://lobste.rs/s/tul188/initialization_c_is_seriously_bon...

[2]: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

Re: Initialization in C++ is Seriously Bonkers

#45

Post by MikeLui »

tines wrote: post #5

In my view this author falls into the camp of people calling C++ a mess because it gives them too much control when they ask for it. One of his examples which he calls "The Abyss": #include struct A { A(std::initializer_list l) : i(2) {} A(int i = 1) : i(i) {} int i; }; int main() { A a1; A a2{}; A a3(3); A a4 = {5}; A a5{4, 3, 2}; std::cout which outputs: 1 1 3 2 2 he claims to be mysterious but is actually pretty r…

Hi. I completely agree. C++ is there for very fine control and serves the purpose well (and is constantly adding more control, e.g. trivially relocatable).

My biggest goal for a CS 101 class would just to build computational and critical thinking skills. I would love to just start off with peanut butter and jelly sandwiches[1]. As an engineering department, our students start with an engineering programming class that needs to also serve chemical, mechanical, civil, material, and biomedical engineers along with electrical and computer engineers(I hope I didn't leave anyone out).

[1]: https://edtechmagazine.com/k12/article/2008/07/programming-a...

Re: Initialization in C++ is Seriously Bonkers

#47

Post by tom_ »

valarauca1 wrote: post #33
ori_b wrote: post #8

Earlier quoted context omitted.

> No, it's because i lives in an area allocated at the OS level What OS? I don't have one. I have to link in init code to zero sections of ram before my embedded code runs. Sure, it got into the standard because some popular OSes like Unix zero initialized pages, but it's not a universal truth. The reason it's guaranteed in C is because of the spec.

Not necessarily true. C89 only requires that static values be initialized. A modern C standard (section: 6.7.8(10)) requires static values be initialized, but what the value is initialized too be _technically_ indeterminate. There is the guide line given that integers must be zero, and pointers be NULL. But if a static storage class isn't consisting of purely integers, pointers, or (fixed sized) structures, arrays, a…

The C11 rules for static values are pretty explicit:

``` If an object that has static or thread storage duration is not initialized explicitly, then:

- if it has pointer type, it is initialized to a null pointer;

- if it has arithmetic type, it is initialized to (positive or unsigned) zero;

- if it is an aggregate, every member is initialized (recursively) according to these rules, and any padding is initialized to zero bits;

- if it is a union, the first named member is initialized (recursively) according to these rules, and any padding is initialized to zero bits; '''

I think that covers every possible value you can create, and it seems pretty non-indeterminate by my reading.

Re: Initialization in C++ is Seriously Bonkers

#48

Post by MikeLui »

kllrnohj wrote: post #13

> C++ is not a language I’d want to teach beginners. At no point in this post was there room for systems programming concepts, discourse on programming paradigms, computational-oriented problem solving methodologies, or fundamental algorithms. This is a ridiculous argument. The entire point of the post was, as the author even noted, purely to deep dive into a rabbit hole, get super picky & pedantic about standards wo…

Hi. I appreciate your candor, although I'm not sure what I've done to inspire such contempt. You're correct that the entire point of the post was to deep dive into a rabbit hole. I acknowledged that and also acknowledged that the standardese is unnecessary most of the time, to avoid any miscommunication in my intent. I did this point out how large the language is and, more to the point, to point out how potentially complex it can be, compared to C. If you've ever had to spend entire weekends running through students' broken C code at scale, and see all the interesting ways one can complicate seemingly simple things, then I think you'd agree that giving them more ways to confuse themselves in a fast-paced academic environment is not the way forward. If you have had that experience and didn't have any problems, then you are fortunate to work with such fast learners! (Not to imply the students I've had are dumb in anyway, many are very bright!)
Post reply on HN