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

51–60 of 130 posts

Re: Initialization in C++ is Seriously Bonkers

#51

Post by berkut »

throwawaymath wrote: post #36
userbinator wrote: post #24

Earlier quoted context omitted.

use the new stuff which fixes all the complexity It doesn't, unfortunately it just adds to the complexity.

How so? My experience has been that it actually reduces net complexity, except in the case where you need to support different versions of the language in the same codebase. Take for example, `auto`, added in C++11. If you don't have to support C++98 or C++03, the use of `auto` significantly simplifies many workflows and is often strictly better with less mental overhead.

> Take for example, `auto`, added in C++11. If you don't have to support C++98 or C++03, the use of `auto` significantly simplifies many workflows and is often strictly better with less mental overhead.

When writing code, yes, but in my experience, it can also make interpreting what code that overuses auto is doing (especially what variables are and what functions return) an awful lot harder in many situations, and you end up jumping all over the place to work out that "auto result = ..." is actually "uint32_t result = ..."

That's one of my personal pet peeves about more modern C++ (and other languages to some extent like Rust): they seem to be more optimised for writing code quickly (which generally only happens once), not understanding it later (i.e. you didn't write the code someone else did) and maintaining / altering it in the future, which generally happens a lot more over code's lifetime.

Re: Initialization in C++ is Seriously Bonkers

#53

Post by ahartmetz »

ChrisSD wrote: post #22
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 think it's better to teach basic assembly before C. Using memory addresses makes so much more sense in assembly. But for a first language I'd want to use something like Python or Javascript or even a toy language. It simply needs to be something where some basic, high level concepts can be taught without worrying about the details.

Yeah, there is really no need to be scared of assembly. It is easy to learn because there is not much to it. Only writing nontrivial programs in assembly is hard, and you don't need to do that to understand what's going on behind the scenes in compiled code.

Re: Initialization in C++ is Seriously Bonkers

#55

Post by ben0x539 »

ajross wrote: post #2

> [Why is a global variable zero?] Because i has static storage duration, it’s initialized to unsigned zero. Why, you ask? Because the standard says so. No, it's because i lives in an area allocated at the OS level, and OS has to have initialized that memory with something (otherwise you'd have a security bug). The .bss segment has been zeroed, for obvious reasons, since the advent of modern linkage. The explanation…

You're certainly correct, but I don't understand why you're phrasing this as an objection rather than as a rationale for how the language is specified.

Personally, I enjoy that the C standard makes a bunch of guarantees that I can use for my reasoning about correctness. Of course I can only get so far reasoning in abstract, language-defined terms and ignoring the execution environment, but where it is sufficient, being able to forget about operating system minutiae is certainly a relief.

Since the main thrust of the article is that C++'s language-imposed rules are overly complicated, restricting the perspective to the language specification seems reasonable.

Re: Initialization in C++ is Seriously Bonkers

#56

Post by a1369209993 »

ahartmetz wrote: post #53
ChrisSD wrote: post #22

Earlier quoted context omitted.

I think it's better to teach basic assembly before C. Using memory addresses makes so much more sense in assembly. But for a first language I'd want to use something like Python or Javascript or even a toy language. It simply needs to be something where some basic, high level concepts can be taught without worrying about the details.

Yeah, there is really no need to be scared of assembly. It is easy to learn because there is not much to it. Only writing nontrivial programs in assembly is hard, and you don't need to do that to understand what's going on behind the scenes in compiled code.

> Only writing nontrivial programs in assembly is hard

It's not even really hard, just crushingly tedious and error-prone. You could also write all your programs on 80-column punch cards or with (1)ed, but why bother if there isn't some technical reason why a text editor isn't available?

Re: Initialization in C++ is Seriously Bonkers

#57

Post by giornogiovanna »

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…

A huge reason people teach C/++ to beginners is to understand how the "machine" works. Yes, the model C++ uses doesn't map too well to modern assemblies, and yes, it maps even worse to the actual hardware, but its abstraction is the one everyone uses, so it's worth teaching. Teaching modern C++ doesn't do that, at all. "Modern" C++ even has garbage collection (reference counting) in the form of shared_ptr! The author makes the good point that C is much better suited to this job than C++.

Also, standards definitely shouldn't be inscrutable to programmers. Look at the ECMAScript and Go specifications, they're clear as day. Sometimes you just need to know exactly what your code is doing, and this only becomes more important in the low-level scenarios that C++ is often used for. I haven't read the C++ specification, but if it's as hard to read as everyone says it is, then there needs to be some other way to understand exactly what's going on. How else am I meant to precisely understand how my structs will be laid out, or which casts are guaranteed to be valid, or whether the language allows data pointers and function pointers to be interchangeable?

Re: Initialization in C++ is Seriously Bonkers

#58

Post by Joky »

jstimpfle wrote: post #31
atombender wrote: post #26

Earlier quoted context omitted.

I don't think we should pretend that any of this was planned out. The reason the C standard is like it is because it doesn't just specify the best possible version of C that can exist, but because it encodes historical behaviour. It's possible to post-rationalize those decisions, but as I understand it, there's no particular reason why .bss has to be initialized -- it just happens to be the way Unix has worked since…

> With modern static analysis, there's probably no performance benefit to not initializing stack variables that are read before they're written? Not really relevant because that's a bug. But the common thinking "let's always default-initialize stack variables because the compiler will make it efficient anyway" is clearly "sufficiently smart compiler" thinking. Implicit default initialization will never be 100% as eff…

Note that clang just got a change to experiment with this: https://reviews.llvm.org/rL349442

Re: Initialization in C++ is Seriously Bonkers

#59

Post by giornogiovanna »

berkut wrote: post #51
throwawaymath wrote: post #36

Earlier quoted context omitted.

How so? My experience has been that it actually reduces net complexity, except in the case where you need to support different versions of the language in the same codebase. Take for example, `auto`, added in C++11. If you don't have to support C++98 or C++03, the use of `auto` significantly simplifies many workflows and is often strictly better with less mental overhead.

> Take for example, `auto`, added in C++11. If you don't have to support C++98 or C++03, the use of `auto` significantly simplifies many workflows and is often strictly better with less mental overhead. When writing code, yes, but in my experience, it can also make interpreting what code that overuses auto is doing (especially what variables are and what functions return) an awful lot harder in many situations, and y…

This is one of my worries about type inference (which C++ auto is not), but so far, the Rust code I've read has definitely been much easier to understand than the equivalent C code, and it's often much more generic. I like how Rust forces refuses to infer function signatures, which means you still always know the types of the inputs and outputs. I don't use IDEs, but I'd assume that they also make this whole thing a non-issue.

Re: Initialization in C++ is Seriously Bonkers

#60

Post by berkut »

giornogiovanna wrote: post #59
berkut wrote: post #51

Earlier quoted context omitted.

> Take for example, `auto`, added in C++11. If you don't have to support C++98 or C++03, the use of `auto` significantly simplifies many workflows and is often strictly better with less mental overhead. When writing code, yes, but in my experience, it can also make interpreting what code that overuses auto is doing (especially what variables are and what functions return) an awful lot harder in many situations, and y…

This is one of my worries about type inference (which C++ auto is not ), but so far, the Rust code I've read has definitely been much easier to understand than the equivalent C code, and it's often much more generic. I like how Rust forces refuses to infer function signatures, which means you still always know the types of the inputs and outputs. I don't use IDEs, but I'd assume that they also make this whole thing a…

Relying on IDEs to do this type of thing really doesn't help for situations like merge conflicts (i.e. which merge tools understand languages fully?), and it doesn't completely solve the problem of easily understanding code just at a glance - you still need to go round mouse-overing or clicking on stuff to see extra detail.
Post reply on HN