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

Post by gpderetta » Mon, Apr 26, 2021, 3:04 PM UTC

v8dev123 wrote: post #71

andyxor wrote: post #14

C++ is a beautiful, pragmatic and very efficient language, just constrain your use of it to STL, and avoid Boost and other over-engineered dependencies. The Ockham's razor principle of code design is not only important but essential when using large mature languages that have many surprising and nuanced ways to skin a cat. Being too clever with C++ is a recipe for disaster. Avoid OOP (inheritance in particular) and t…

OOP and Boost also Templates has benefits when it comes to increasing barrier of static reverse engineering. For example, Security researcher "Marcus Hutchins" famously echoed that Boost is a cluster fuck of OOP sadness [0] Similarly, a close friend of mine "Omer Yair" mentioned [1], "A well written OOP malware might be harder to RE statically than a poorly written C code. Writing OOP malware badly though just makes…

Post by thedracle » Mon, Apr 26, 2021, 3:10 PM UTC

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…

Post by emtel » Mon, Apr 26, 2021, 3:19 PM UTC

jcelerier wrote: post #199

emtel wrote: post #90

Earlier quoted context omitted.

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

> 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* ptr) { if (ptr != NULL) { ... } } then what ? 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 } } and c…

    fn foo(s: Option) -> {
      if (let Some(inner) = s) {
        // now you can access inner repeatedly
        // without branches
      }
    }

Post by jcelerier » Mon, Apr 26, 2021, 3:25 PM UTC

emtel wrote: post #216

jcelerier wrote: post #199

Earlier quoted context omitted.

> 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* ptr) { if (ptr != NULL) { ... } } then what ? 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 } } and c…

That’s why I said properly implemented! Good optional implementations let you do the check once to unwrap the inner value, so you have one branch. In rust: fn foo(s: Option ) -> { if (let Some(inner) = s) { // now you can access inner repeatedly // without branches } } (edit to fix syntax errors)

   if(!bla)
     return;

   // use bla

Post by emtel » Mon, Apr 26, 2021, 3:38 PM UTC

jcelerier wrote: post #218

emtel wrote: post #216

Earlier quoted context omitted.

That’s why I said properly implemented! Good optional implementations let you do the check once to unwrap the inner value, so you have one branch. In rust: fn foo(s: Option ) -> { if (let Some(inner) = s) { // now you can access inner repeatedly // without branches } } (edit to fix syntax errors)

but this declares a new variable - I find this super messy and really decreases readability in practice since now it's not obvious anymore that what you're working with was a function parameter. Also it adds a scope level - I much prefer the if(!bla) return; // use bla early-return style. So that's really a no-go for me from years comparing the two styles