Modern C++ Won't Save Us (2019)

Post by rhn_mk1 » Mon, Apr 26, 2021, 12:48 PM UTC

throwaway894345 wrote: post #181

rhn_mk1 wrote: post #163

Earlier quoted context omitted.

While I agree with most of what you wrote, CMake feels supercharged compared to the build system part of Cargo. Cargo is failing hard on the integration front, both on integrating things, and being integrated. build.rs is a minimal substitute of a build system: "deal with it yourself". The way Cargo wants to have total control, on the other hand, makes it hard to integrate with existing projects: those which don't us…

I was a C++ developer in a past life and Cmake was a big reason I moved on to greener pastures. It’s the only language that is more toilsome to use than C++ itself, and that by an enormous margin. It’s stringly typed (no, that’s not a typo, everything is a string), it’s syntax is obscure, it extends so poorly that it just bakes-in support for building popular libraries (e.g., Google’s test framework, Qt, etc iirc), i…

Post by klibertp » Mon, Apr 26, 2021, 1:00 PM UTC

kaba0 wrote: post #179

klibertp wrote: post #155

Earlier quoted context omitted.

> From that point on, every "allocation" is equivalent to bumping a pointer in that arena. I'm not a C++ developer, so I have a hard time imagining how would this be implemented in real code. I know how to allocate a blob of memory, but how do I redirect all the later allocations (that use `new` or that are hidden in std::string and other containers) to use parts of that blob? How do I know when the blob is going to…

It’s not an either or thing, there is probably no need to allocate strings in the arena. Some cpp structures do allow for custom allocators, but you are more likely to have an arena instance and call some specific function on it and it will do the allocation for you. It usually operates on only a few types, not meant for arbitrary allocations.

Post by ape4 » Mon, Apr 26, 2021, 1:06 PM UTC

HexDecOctBin wrote: post #34

Animats wrote: post #24

My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…

> three issues: "How big is it", "Who owns it", and "Who locks it" The issue with this kind of thinking is the belief that there is a "it", not "they". Say, you are writing a HTTP server [1]. A beginner mindset (what seems to be demonstrated in this post) with start allocating left and right, for every HTTP header, for every piece of string, for every piece of metadata record, etc. Thus, "how big is it" become no big…

Post by flohofwoe » Mon, Apr 26, 2021, 1:13 PM UTC

kaba0 wrote: post #174

flohofwoe wrote: post #141

Earlier quoted context omitted.

Consider "games" like Minecraft, Roblox or Dreams, those are entirely user-data-driven. Different types of games are at least as different to each other as to other types of applications (or rather, they are not less diverse than other applications, they usually just have a higher focus on performance).

How are they different? You have some primitives like a block, and meaning is given by users to a group of them. The program has to care only about the primitives. (Of course making it performant, not rendering/“simulating” everything and the like is exceedingly hard, but it is true that it is more of a “closed world” as opposed to some other areas of software development.)

Post by jcelerier » Mon, Apr 26, 2021, 1:18 PM UTC

emtel wrote: post #90

nemothekid wrote: post #12

Earlier quoted context omitted.

> Ideally that should be zero-overhead Optionals are not zero-overhead in any other language. If you aren't going to bother checking the optional, why not just return any old pointer type? The type system should be used to enforce a contract and bypassing checks on that feels like you are just spitting in the fact of the type checker.

> Optionals are not zero-overhead in any other language. This is a common misconception, and a pet peeve of mine. Properly designed optional types add neither space nor code-size overhead. Consider the C function: foo(int* ptr) { ... } If it is part of the API of foo that `ptr` may be null, then foo must not dereference `ptr` without verifying that it is non-null. So the body of foo must be something like: foo(int* p…

    foo(int* ptr) {
      if (ptr != NULL) {
        ...
      }
    }

    foo(int* ptr) {
      if (ptr != NULL) {
        *ptr += 1; // optional::operator* would introduce a branch here ?
        *ptr = *ptr / 2 ; // same 
        if(*ptr > some_constant) // same
        { ... } // etc etc 
      }
    }