3 ms·

The complexity argument is just not true. You do have to know this stuff in c++, you run into it all the time. I wish I didn’t have to know about std::launder

The complexity argument is just not true. You do have to know this stuff in c++, you run into it all the time. I wish I didn’t have to know about std::launder but I do

ryao 1y ago
I feel like C++ is a bunch of long chains of solutions creating problems that require new solutions, that start from claiming that it can do things better than C. Problem 1: You might fail to initialize an object in memory correctly. Solution 1: Constructors. Problem 2: Now you cannot preallocate memory as in SLAB allocation since the constructor does an allocator call. Solution 2: Placement new Problem 3: Now the type system has led the compiler to assume your preallocated memory cannot change since you declared it const. Solution 3: std::launder() If it is not clear what I mean about placement new and const needing std::lauder(), see this: https://miyuki.github.io/2016/10/21/std-launder.html https://miyuki.github.io/2016/10/21/std-launder.html C has a very simple solution that avoids this chain. Use structured programming to initialize your objects correctly. You are not going to escape the need to do this with C++, but you are guaranteed to have to consider a great many things in C++ that would not have needed consideration in C since C avoided the slippery slope of syntactic sugar that C++ took.
- monkeyelite 1y ago
  I absolutely agree - your chain of reasoning follows as well. It doesn't seem like it at first, but the often praised constructor/destructor is actually a source of incredible complexity, probably more than virtual.
- jcelerier 1y ago
  But the c++ solution is transparent to the user. You can write entire useful programs that will use std:: containers willy-nilly and all propagate their allocators automatically and recursively without you having to lift a finger because all the steps you've mentioned have been turned in a reusable library, once.
  - nxobject 1y ago
    I'd file that in the category of "what I can't recreate, I can't understand".
    - account42 1y ago
      With that argument you could discard JavaScript because V8 is hard to understand. C++ giving you the ability to create your own containers that equal the standard library is a bonus, it doesn't make those containers harder to use.
      - nxobject 1y ago
        That's a false comparison. There's a huge difference between a standard container library, and the combination of a (a) best-in-class byte code interpreter with a (b) caching, optimizing JIT, supported by (c) a best-in-class garbage collector. I would argue that it's reasonable to say that creating a robust data structure library at the level of the STL shouldn't be that arcane.
  - monkeyelite 1y ago
    Yes, and to get that nice feature you have to pay an enormous cost.
- AnimalMuppet 1y ago
  Problem 1 happens, say, 10% of the time when using a C struct. Problem 2 happens only when doing SLAB allocations - say, 1% of the time when using a C++ class. (Might be more or less, depending on what problem space you're in.) Problem 3 happens only if you are also declaring your allocated stuff const - say, maybe 20% of the time? So, while not perfect, each solution solves most of the problem for most of the people. Complaining about std::launder is complaining that solution 2 wasn't perfect; it's not in any way an argument that solution 1 wasn't massively better than problem 1.
jandrewrogers 1y ago
You need something like std::launder in any systems language for certain situations, it isn’t a C++ artifact. Before C++ added it we relied on undefined behavior that the compilers agreed to interpret in the necessary way if and only if you made the right incantations. I’ve seen bugs in the wild because developers got the incantations wrong. std::launder makes it explicit. For the broader audience because I see a lot of code that gets this wrong, std::launder does not generate code. It is a compiler barrier that blocks constant folding optimizations of specific in-memory constants at the point of invocation. It tells the compiler that the constant it believes lives at a memory address has been modified by an external process. In a C++ context, these are typically restricted to variables labeled ‘const’. This mostly only occurs in a way that confuses the compiler if you are doing direct I/O into the process address space. Unless you are a low-level systems developer it is unlikely to affect you.
- monkeyelite 1y ago
  Do you see all the concepts you had to describe here? > Unless you are a low-level systems developer it is unlikely to affect you. Making new data structure is common. Serializing classes into buffers is common.
  - jandrewrogers 1y ago
    If you are doing something equivalent to placement new on top of existing objects, the compiler often sees that. If that is your case you can avoid it in most cases. That is not what std::launder is for. It is for an exotic case. std::launder is a tool for object instances that magically appear where other object instances previously existed but are not visible to the compiler. The typical case is some kind of DMA like direct I/O. The compiler can’t see this at compile time and therefore assumes it can’t happen. std::launder informs the compiler that some things it believes to be constant are no longer true and it needs to update its priors.
    - monkeyelite 1y ago
      With placement new you need to hold on to the pointer. If you need to get an object back out of a buffer you need launder. Std::vector needs launder.

The complexity argument is just not true. You do have to know this stuff in c++, you run into it all the time. I wish I didn’t have to know about std::launder but I do

ryao 1y ago

I feel like C++ is a bunch of long chains of solutions creating problems that require new solutions, that start from claiming that it can do things better than C. Problem 1: You might fail to initialize an object in memory correctly. Solution 1: Constructors. Problem 2: Now you cannot preallocate memory as in SLAB allocation since the constructor does an allocator call. Solution 2: Placement new Problem 3: Now the type system has led the compiler to assume your preallocated memory cannot change since you declared it const. Solution 3: std::launder() If it is not clear what I mean about placement new and const needing std::lauder(), see this: https://miyuki.github.io/2016/10/21/std-launder.html https://miyuki.github.io/2016/10/21/std-launder.html C has a very simple solution that avoids this chain. Use structured programming to initialize your objects correctly. You are not going to escape the need to do this with C++, but you are guaranteed to have to consider a great many things in C++ that would not have needed consideration in C since C avoided the slippery slope of syntactic sugar that C++ took.

monkeyelite 1y ago
I absolutely agree - your chain of reasoning follows as well. It doesn't seem like it at first, but the often praised constructor/destructor is actually a source of incredible complexity, probably more than virtual.
jcelerier 1y ago
But the c++ solution is transparent to the user. You can write entire useful programs that will use std:: containers willy-nilly and all propagate their allocators automatically and recursively without you having to lift a finger because all the steps you've mentioned have been turned in a reusable library, once.
- nxobject 1y ago
  I'd file that in the category of "what I can't recreate, I can't understand".
  - account42 1y ago
    With that argument you could discard JavaScript because V8 is hard to understand. C++ giving you the ability to create your own containers that equal the standard library is a bonus, it doesn't make those containers harder to use.
    - nxobject 1y ago
      That's a false comparison. There's a huge difference between a standard container library, and the combination of a (a) best-in-class byte code interpreter with a (b) caching, optimizing JIT, supported by (c) a best-in-class garbage collector. I would argue that it's reasonable to say that creating a robust data structure library at the level of the STL shouldn't be that arcane.
- monkeyelite 1y ago
  Yes, and to get that nice feature you have to pay an enormous cost.
AnimalMuppet 1y ago
Problem 1 happens, say, 10% of the time when using a C struct. Problem 2 happens only when doing SLAB allocations - say, 1% of the time when using a C++ class. (Might be more or less, depending on what problem space you're in.) Problem 3 happens only if you are also declaring your allocated stuff const - say, maybe 20% of the time? So, while not perfect, each solution solves most of the problem for most of the people. Complaining about std::launder is complaining that solution 2 wasn't perfect; it's not in any way an argument that solution 1 wasn't massively better than problem 1.

jandrewrogers 1y ago

You need something like std::launder in any systems language for certain situations, it isn’t a C++ artifact. Before C++ added it we relied on undefined behavior that the compilers agreed to interpret in the necessary way if and only if you made the right incantations. I’ve seen bugs in the wild because developers got the incantations wrong. std::launder makes it explicit. For the broader audience because I see a lot of code that gets this wrong, std::launder does not generate code. It is a compiler barrier that blocks constant folding optimizations of specific in-memory constants at the point of invocation. It tells the compiler that the constant it believes lives at a memory address has been modified by an external process. In a C++ context, these are typically restricted to variables labeled ‘const’. This mostly only occurs in a way that confuses the compiler if you are doing direct I/O into the process address space. Unless you are a low-level systems developer it is unlikely to affect you.

monkeyelite 1y ago
Do you see all the concepts you had to describe here? > Unless you are a low-level systems developer it is unlikely to affect you. Making new data structure is common. Serializing classes into buffers is common.
- jandrewrogers 1y ago
  If you are doing something equivalent to placement new on top of existing objects, the compiler often sees that. If that is your case you can avoid it in most cases. That is not what std::launder is for. It is for an exotic case. std::launder is a tool for object instances that magically appear where other object instances previously existed but are not visible to the compiler. The typical case is some kind of DMA like direct I/O. The compiler can’t see this at compile time and therefore assumes it can’t happen. std::launder informs the compiler that some things it believes to be constant are no longer true and it needs to update its priors.
  - monkeyelite 1y ago
    With placement new you need to hold on to the pointer. If you need to get an object back out of a buffer you need launder. Std::vector needs launder.