Initialization in C++ is Seriously Bonkers • Hacker News Board

Re: Initialization in C++ is Seriously Bonkers

#101

Post by MichaelMoser123 » Sun, Jan 06, 2019, 4:15 AM UTC

MikeLui wrote: post #100

MichaelMoser123 wrote: post #96

Earlier quoted context omitted.

I am not sure about the following issue: What would make your students more productive? - use C++, given that you stick to some convenient subset of C++ and can use stl - stick with C and force them to do the basics, like linked lists and string abstractions over and over again. I guess in the olden days really good students used to develop their own library of C abstractions, and reuse them with several courses; but…

How else would they learn about linked lists and dynamic arrays?

depends on the course, if its a data structure course then its fine to do the linked list and dynamic array, but forcing your students to do them again and again in later courses will not make them very productive, they also might not enjoy the experience too much.

This could happen for example if the data structure course was in python or java and later courses are in C.

Also you can do the darn list in many ways: single linked list, double, ring, with counter/without counter. All very important in this day and age when you should know to avoid them altogether because linked lists fucks up cache behavior.

Re: Initialization in C++ is Seriously Bonkers

#102

Post by MikeLui » Sun, Jan 06, 2019, 4:48 AM UTC

MichaelMoser123 wrote: post #101

MikeLui wrote: post #100

Earlier quoted context omitted.

How else would they learn about linked lists and dynamic arrays?

depends on the course, if its a data structure course then its fine to do the linked list and dynamic array, but forcing your students to do them again and again in later courses will not make them very productive, they also might not enjoy the experience too much. This could happen for example if the data structure course was in python or java and later courses are in C. Also you can do the darn list in many ways: s…

Funny you mention that: the data structures course I took let us use any language we wanted. I chose python because I thought “hey python’s easier than C!” So I started making some tree implementation from scratch, and I kept having problems because I didn’t understand Python’s name binding system at the time, because I had no mental model of pointers or references or objects really. (Of course it was a shallowcopy/deepcopy issue). The next assignment I did in C and it was much more natural. Only later did I realize how meta and absurd it was to build custom dictionaries out of python primitives.

Re: Initialization in C++ is Seriously Bonkers

#103

Post by MikeLui » Sun, Jan 06, 2019, 4:59 AM UTC

gamma-male wrote: post #90

MikeLui wrote: post #44

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 wo…

Why not teach rust?

I can think of at least 3 reasons! 1) I don’t control the curriculum. 2) I’m pretty sure no one knows it well enough to teach. 3) Rust’s ecosystem and adoption is still too small for being taught as an engineering tool and for delivering employment opportunities to students.

I personally like rust and hope it does well. I see it somewhat orthogonal to both C and C++

Re: Initialization in C++ is Seriously Bonkers

#104

Post by waynecochran » Sun, Jan 06, 2019, 5:26 AM UTC

ajross wrote: post #82

waynecochran wrote: post #74

Earlier quoted context omitted.

./libgcc/config/nds32/crtzero.S .L_bss_init: ! clear BSS, this process can be 4 time faster if data is 4 byte aligned ! if so, use swi.p instead of sbi.p ! the related stuff are defined in linker script la $r0, _edata ! get the starting addr of bss la $r2, _end ! get ending addr of bss beq $r0, $r2, .L_call_main ! if no bss just do nothing movi $r1, 0 ! should be cleared to 0 .L_clear_bss: sbi.p $r1, [$r0], 1 ! Set 0…

How does finding some uncompiled sample code someone added to gcc for an architecture no one has heard of refute the point that glibc on Linux implements bss with an anonymous mmap?

Not meant to refute, just sample code on the C runtime zeroing the bss section. You'll find this for a variety of systems, this was just one of them...

Re: Initialization in C++ is Seriously Bonkers

#105

Post by MichaelMoser123 » Sun, Jan 06, 2019, 5:26 AM UTC

MikeLui wrote: post #102

MichaelMoser123 wrote: post #101

Earlier quoted context omitted.

depends on the course, if its a data structure course then its fine to do the linked list and dynamic array, but forcing your students to do them again and again in later courses will not make them very productive, they also might not enjoy the experience too much. This could happen for example if the data structure course was in python or java and later courses are in C. Also you can do the darn list in many ways: s…

Funny you mention that: the data structures course I took let us use any language we wanted. I chose python because I thought “hey python’s easier than C!” So I started making some tree implementation from scratch, and I kept having problems because I didn’t understand Python’s name binding system at the time, because I had no mental model of pointers or references or objects really. (Of course it was a shallowcopy/d…

a dictionary in python where everything is a dictionary. That's what undergraduate courses are made for!

Re: Initialization in C++ is Seriously Bonkers

#106

Post by Gibbon1 » Sun, Jan 06, 2019, 5:58 AM UTC

angry_octet wrote: post #75

maxxxxx wrote: post #42

Earlier quoted context omitted.

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

Monads are still a little magical though.

I keep thinking that C could support monads with a little work.

Re: Initialization in C++ is Seriously Bonkers

#107

Post by Gibbon1 » Sun, Jan 06, 2019, 6:05 AM UTC

jstimpfle wrote: post #63

Joky wrote: post #58

Earlier quoted context omitted.

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

Doesn't seem to me like a statement that variables should be implicitly initialized. It seems like a workaround around insanity with respect to UB (where compilers fail to notify the programmer that they statically detected a logic bug, and instead go on with compiling, making crazy optimizations based on the wrong assumption that the logic bug was never there).

I'll tell you I'd rather live in the current world where the compiler emits a warning 'foo may be uninitialized' than the world we are heading into where that enables a half assed optimization that speeds up a ubenchmark on an architecture no one uses anymore.

Re: Initialization in C++ is Seriously Bonkers

#108

Post by dingo_bat » Sun, Jan 06, 2019, 6:09 AM UTC

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…

> and you end up jumping all over the place to work out that "auto result = ..." is actually "uint32_t result = ..."

Just hover over "result" and your IDE will tell you the type.

Re: Initialization in C++ is Seriously Bonkers

#109

Post by Gibbon1 » Sun, Jan 06, 2019, 6:14 AM UTC

rabidrat wrote: post #7

amluto wrote: post #4

Earlier quoted context omitted.

> The .bss segment has been zeroed, for obvious reasons, since the advent of modern linkage. For your amusement: in the Linux kernel , at least on x86, .bss isn’t initialized when the kernel is loaded. Instead, the kernel memsets it to zero a little later. I don’t know why. Also, because all this stuff predates any concept of security, there is no read-only equivalent of .bss in most systems, meaning that you get sub…

The OS program loader is who allocates pages to .bss and initializes them to zero. In the case of an OS, who would do that initialization? At best it would be the bootloader. Initialization during kernel_init() before using any globals is acceptable too.

Having seen both sides of this, people are arguing about the proper way to skin a cat. The standard only cares the cat be skinned not how.

On OS it's done by the OS for security and performance reasons. One you don't want people to snoop on memory freed from other processes. Two the OS can use the MMU to map in previously zero's pages of memory on demand, so you don't need to actually zero the entire .BSS section on startup.

On a bare metal system usually it's done either in assembly (or more cheezy in C) + linker magic.

Re: Initialization in C++ is Seriously Bonkers

#110

Post by Retra » Sun, Jan 06, 2019, 6:35 AM UTC

perl4ever wrote: post #98

MaxBarraclough wrote: post #65

Earlier quoted context omitted.

> The reason that stack variables are UNinitialized is (contra the article which thinks it's because the programmer didn't put an initializer in the source code) that memory is on the stack, which is allocated internal to your program and in practice was used previously by some other call for some other purpose. It is because the programmer didn't put an initializer into the source code. That's how the language is de…

"Any C programmer worth anything knows that this initializes i to an indeterminate value. This is wrong. Reading the variable does not simply give you an indeterminate value, it gives undefined behaviour" Undefined behavior in the technical sense is not acceptable in a language at all, let alone a feature. If you take the idea of undefined behavior seriously, then it is valid to blow up the world in response to an er…

>If you take the idea of undefined behavior seriously, then it is valid to blow up the world in response to an error and the compiler cannot protect you

That's not its job. The compiler cannot protect you from everything. (You shouldn't be using a computer that has the ability to blow up the world.) The compiler merely translates code from language A into language B. If you pass it some code in some third language which could parse as mal-formed A code, then how is to detect that?

If I write a language with the same syntax as C but entirely different semantics, and I pass it to a C compiler, what do you think should happen? Undefined behavior is what happens.