Goodbye C++, Hello C • Hacker News Board

Re: Goodbye C++, Hello C

#181

Post by gwmnxnp_516a » Sat, Jun 26, 2021, 8:10 PM UTC

Koshkin wrote: post #177

gwmnxnp_516a wrote: post #170

Earlier quoted context omitted.

It is possible to write safe-C, but C is far more error prone than C++. C has more implicit type conversions than C++, which may results in bugs and undefined behaviours. C lacks RAII (Resource-Acquisition Is Initialization) that is useful for memory and resource management. C will actually require more code than C++ since, the C standard library lacks generic data structures such as vectors, hash maps, linked lists…

> C is far more error prone than C++ I don't know about that... C++ (both the language and the library) is orders of magnitude more complex, and the opportunities to make mistakes have grown almost proportionally. (Two characteristic examples recently discussed here on HN: auto references and iterator invalidation.)

But C lacks even strings, lots of C bugs and vulnerabilities are related to memory management, memory ownership and string handling. Even the C subset of C++ is better than C since it at least has more explicit type conversions that forces the developer to state his or her intent. One example of the C string problem is the strcpy(buffer, char* string) that copies a string to a buffer. If an external actor discovers how to manipulate the string size, he or she can take advantage of this buffer overflow vulnerability and even execute arbitrary code remotely if it is used in a server. If the application with this problem is a file, one create a specially crafted file to take advantage of this design flaw.

However using C in the case of the original poster does not matter much as the application is game-related not subject to untrusted input.

Re: Goodbye C++, Hello C

#182

Post by CyberDildonics » Sat, Jun 26, 2021, 8:17 PM UTC

gravypod wrote: post #173

CyberDildonics wrote: post #169

Earlier quoted context omitted.

Do you mean type instead of shape? I also don't know what you mean by incorrect. C will also create casts when using two different number types in a math operation.

For matrix and quaternions multiplication does not output the same type as the input. For example: int a = 1; a + a = 2; (int) a * 2 = 2; (int) auto ma = matrix (); auto mb = matrix (); ma * a is matrix ma * ma is not possible ma * mb is matrix Compilers used to be very bad at telling you what was going on here if you, for example, changed ` ` to ` ` or something. g++ now handles it pretty well: https://hastebin.com/…

Your original comment was about something being incorrect, now you are talking about error messages, but I don't think either has to do with operator overloading.

Re: Goodbye C++, Hello C

#183

Post by UncleMeat » Sat, Jun 26, 2021, 8:52 PM UTC

giomasce wrote: post #44

maleldil wrote: post #12

> Where C++ gives you many slightly different takes on the same concept (e.g. unique_ptr, shared_ptr and raw pointers), C gives you one way to go and that one has a conveniently compact notation (such as float ). You use unique_ptr and shared_ptr because float is unsafe. If you don't care about the safety that smart pointers provide, you can use float* in C++ too. > ticking with the example of matrix math, it is baff…

The problem is not even just safety. You can write safe C, if you are careful (and you need to be careful also for C++, smart pointers do not just magically make everything right). The point is that OP makes the point that C requires to write less code, and this doesn't even seem true: you have to remember, each time some non-trivial object goes out of scope, to call its destructor/deallocator, which results in a lot…

I don't believe that it is possible to write safe C (or C++), even if you are both very careful and also among the most skilled C developers out there. Every sizable project in C has had critical vulnerabilities. It is not possible to train engineers on a team of any meaningful size to consistently write bug free code and catch bugs in code review. Sanitizers, fuzzing, and static analysis all help but are insufficient in the face of the utterly impossible task of writing safe C programs, let alone evolving safe C programs.

Look at all the very smart people that tried and completely failed to write libraries that do such basic things as copying strings.

Re: Goodbye C++, Hello C

#184

Post by Zababa » Sat, Jun 26, 2021, 8:55 PM UTC

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…

How are the compile times? That's a really big point in the article and you don't mention them at all.

Re: Goodbye C++, Hello C

#185

Post by Zababa » Sat, Jun 26, 2021, 9:01 PM UTC

fm77 wrote: post #130

WalterBright wrote: post #8

Earlier quoted context omitted.

> I've seen slow compiling code with hundreds of identically named functions. I sometimes think I've seen everything programmers do, and then something like this pops up. > You can make your C++ code compile fast by simply not using slow paths through the compiler. D is fast to compile because it sidesteps or redesigns features that make for slow compilation.

Walter, I am sorry, completely off-topic… but I have to ask - and you don’t have to answer ;-) …is that you? https://archive.org/details/byte-magazine-1988-09/page/n148/...

There's a (french) wikipedia page about Zortech https://fr.wikipedia.org/wiki/Zortech

Re: Goodbye C++, Hello C

#186

Post by moonchild » Sat, Jun 26, 2021, 9:13 PM UTC

mhh__ wrote: post #132

moonchild wrote: post #10

Earlier quoted context omitted.

D is horribly slow to compile template-heavy code for exactly the same reasons as c++. And it encourages lots of monomorphization in e.g. ranges. The enhanced introspection and reflection (and CTFE) capabilities coupled with mixins also encourage code that is very slow to compile.

As opposed to encouraging manually written code which is also not free to compile but has the added benefit of potentially introducing bugs?

As opposed to encouraging polymorphic code (a la haskell, java), which is fast to compile and provides better type safety.

(Yes, I know neither javac nor ghci are particularly fast, but that doesn't detract from the general point.)

Re: Goodbye C++, Hello C

#187

Post by kaba0 » Sat, Jun 26, 2021, 9:49 PM UTC

Koshkin wrote: post #177

gwmnxnp_516a wrote: post #170

Earlier quoted context omitted.

It is possible to write safe-C, but C is far more error prone than C++. C has more implicit type conversions than C++, which may results in bugs and undefined behaviours. C lacks RAII (Resource-Acquisition Is Initialization) that is useful for memory and resource management. C will actually require more code than C++ since, the C standard library lacks generic data structures such as vectors, hash maps, linked lists…

> C is far more error prone than C++ I don't know about that... C++ (both the language and the library) is orders of magnitude more complex, and the opportunities to make mistakes have grown almost proportionally. (Two characteristic examples recently discussed here on HN: auto references and iterator invalidation.)

There are two problems here, one being complexity, the other being abstraction power. The two correlates. C is an easy language without much complexity, but with laughably little abstraction power. Text-based macros are the worst thing ever, and other than that, the language can’t even express reusable data structures, only with convention.

C++ on the other hand has good expressivity that can better deal with complexity of programs (eg. just simply having string, vector, etc) at the expense of some added language complexity. But unfortunately most of that is due to backward compatibility.

My opinion is that program complexity is inherent for anything interesting, so the C++ tradeoff is worthwhile. Also, by sticking to a good subset of C++, one can minimize the “bad” complexity of the language, imho.

Re: Goodbye C++, Hello C

#188

Post by kaba0 » Sat, Jun 26, 2021, 9:56 PM UTC

bruce343434 wrote: post #179

kaba0 wrote: post #167

Earlier quoted context omitted.

That’s why grandparent wrote “largely”

Their second statement is still simply wrong. C has some ways of doing things which are simply unacceptable in C++. In C, you don't cast mallocs. You can initialize structs like `={0}` or `={prop=val}`. There's more, but the point is: if you are writing C++, you can't write it in a "C way". It won't compile at some point.

I interpreted the “C way” as in avoiding RAI, classes, references, etc. Just writing functions with structs and pointers. Not as “syntactic C”

Re: Goodbye C++, Hello C

#189

Post by kaba0 » Sat, Jun 26, 2021, 9:57 PM UTC

phendrenad2 wrote: post #180

Often the C vs C++ debate comes down to a religious war where the C side is arguing that their hammer is best for pounding in nails and the C++ side is arguing that their screwdriver is best for screwing in screws. I don't believe they're suited for the same purposes at all. If you're writing code where you need to interface with the hardware directly (embedded), or manipulate things in kernel-space efficiently (Open…

I don’t think this argument holds up. You can create very good abstractions over the lower level libs, like OpenGL. There is no need to call it “naked” like in C.

Re: Goodbye C++, Hello C

#190

Post by woodruffw » Sat, Jun 26, 2021, 10:11 PM UTC

loup-vaillant wrote: post #105

woodruffw wrote: post #77

Earlier quoted context omitted.

> Look at all the locked-down walled-garden platforms proliferating I don’t think I’m getting the connection here —- Rust was incubated at Mozilla and is now managed by its own open-source foundation. There’s nothing particularly closed or “walled garden” about it. By contrast, Apple’s ecosystem is the canonical example of a walled garden. But it’s overwhelmingly programmed in unsafe languages (C, C++, and Objective-…

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 analysis).

At the same time, C++ has seen a proliferation of patterns that are slightly safer, but perform miserably at scale: smart pointers (unnecessary lock contention), lambdas (code bloat, more I$ pressure), templates (I$), &c. C avoids most of these, but C written by "clever" programmers has similar pitfalls.