Goodbye C++, Hello C

Post by dr_zoidberg » Sun, Jun 27, 2021, 10:02 PM UTC

pjmlp wrote: post #206

dr_zoidberg wrote: post #203

Earlier quoted context omitted.

Sure, its just that these kind of strings were historically called Pascal-strings [0] because they were the way Pascal implemented strings. [0] And still are! For example, Python refers to them as such, see the "p" (lowercase p) character code here: https://docs.python.org/3/library/struct.html#format-strings

Not all C++ string libraries use Pascal strings. Some of them use a fat pointer instead, with a mix of counter, pointer to the end, and null terminator for C compatibility.

Post by Wowfunhappy » Mon, Jun 28, 2021, 6:10 AM UTC

ninepoints wrote: post #213

Wowfunhappy wrote: post #33

Earlier quoted context omitted.

Deprecated, not unsupported. And, like, Apple ported OpenGL to Apple Silicon macs. I suspect it's going to stick around, it's just never, ever going to get updated.

You're kidding. The OpenGL implementation/support of Mac is pretty nonexistent/poor.

Post by qalmakka » Mon, Jun 28, 2021, 8:22 AM UTC

MuffinFlavored wrote: post #178

qalmakka wrote: post #86

Yesterday I finished a complex library in C++20, which I wrote "Rust style" by following the ISO C++ guidelines. I used 0 `new`, no smart pointers, all by-value returns, move semantics and STL containers. It literally took a month to write, but it worked as expected at the second attempt (first failed due to forgetting a `}` in a format string). I did not see a single segmentation fault and it works fine on both Linu…

> And I won't get started with C strings, which are just a historical BadIdea™. What's the better alternative to null-prefixed strings you are referring to, length prefixed?

  struct string_type {
    char *ptr; // or char[]
    size_t size;
  }

  string slice { .data = str.data + 2, .size = 2 }

Post by winrid » Mon, Jun 28, 2021, 4:22 PM UTC

winrid wrote: post #15

If you really like the simplicity of C I highly recommend Nim: * Compiles to C, so you stand on the shoulders of giants wrt compilers. * Very low overhead GC that doesn't "stop the world". I was working on a project recently where I had to just write a bunch of stuff to disk, and I tried Node, and then Java, and they were about the same, and I figured - yep, makes sense, it's IO bound. Nim got twice the throughput w/…

Post by loup-vaillant » Mon, Jun 28, 2021, 7:03 PM UTC

woodruffw wrote: post #190

loup-vaillant wrote: post #105

Earlier quoted context omitted.

With the possible exception of Rust, safety always had performance implications. Forcing people to write their program in C# or Swift or Java causes many programs to be slower than they really need to be, forcing us to either wait on them, or buy a faster palmtop. (Now most devs don't care about performance, so they don't see that as a problem. As a user however I can tell you, I hate when my phone lags for seemingly…

> With the possible exception of Rust, safety always had performance implications. This is common piece of received wisdom, but I don't think it's held up well over the last decade: both Java and C# have extremely well-optimized runtimes that perform admirably after an initial startup period, and (I believe) Swift compiles to native code with many of the same optimization advantages that Rust has (e.g., simpler alias…