Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye C++, Hello C

momentsingraphics.de

Post reply on HN
Print view View original

141–150 of 222 posts

Re: Goodbye C++, Hello C

#141

Post by skohan »

Thiez wrote: post #131
skohan wrote: post #71

Earlier quoted context omitted.

I actually think safety should be guaranteed at an OS/hardware level and not at a software level. If it's guaranteed that my process can only make a mess inside it's own memory allocations, let the software be as unsafe as it wants.

Then you'll be happy to learn that what you propose has been the case for consumer computers since protected mode was added to Intel 80286 processors in 1982. I think few people in this discussion are worrying about programs directly affecting other programs through memory unsafety, exactly because this doesn't really happen for software that isn't a driver or inside the OS kernel. The problem with memory unsafety is…

But I don't understand how data stealing can happen if each process is effectively sandboxed. If my process can't read or write to memory outside of what it allocated, how can I corrupt or steal user data?

Re: Goodbye C++, Hello C

#142

Post by qalmakka »

andreidd wrote: post #89
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…

Is the library open source? If so, would you share a link?

Sorry but the source is closed sadly, so I can't share it. I would like to write a blog post someday about some of the patterns I've used though, I think they could be useful to someone.

Re: Goodbye C++, Hello C

#143

Post by qalmakka »

detaro wrote: post #135
Santosh83 wrote: post #134

Earlier quoted context omitted.

Would you mind sharing a link to the ISO C++ guidelines you mention?

presumably https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

That's correct. Also see https://github.com/microsoft/GSL, which is a header-only C++ library that implements the Guidelines Support Library as specified by ISO C++. It's extremely useful (especially to get std::span if you don't have C++20 support) because it provides several constructs to explicitly clarify the _intent_of your code, like `gsl::not_null>`, `gsl::narrow_cast()` or `gsl::owner>`. `gsl::finally()` is also pretty useful.

Re: Goodbye C++, Hello C

#144

Post by tomn »

jcelerier wrote: post #40

I wonder what kind of hardware OP runs on, and which compiler is used. Here on my laptop (Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz), on linux, compiling an eigen example takes 0.7 seconds clang++ -fuse-ld=lld eigen.cpp -I/usr/include/eigen3/ 0,66s user 0,07s system 100% cpu 0,728 total if I put the eigen header in a PCH this drops to 0.1 seconds clang++ -fuse-ld=lld eigen.cpp -I/usr/include/eigen3/ -include-pch 0,08s…

Unfortunately our example isn't representative, and avoids a lot of things that make eigen slow to work with. Parsing the header file will take a constant time, but template expansion etc. can take a long time if you have more code.

Try adding a bunch of matrix operations (particularly chained ones resulting in massive expression templates), fixed size matrices of various sizes, and compile with optimisation and SIMD enabled, and you'll see different results. I really like eigen and use it a lot, but it can definitely result in long compile times.

Re: Goodbye C++, Hello C

#145

Post by giomasce »

MaxBarraclough wrote: post #102
giomasce wrote: post #44

Earlier quoted context omitted.

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…

> You can write safe C, if you are careful In practice this pretty much cannot be done unless you use a formal verification framework, which almost no one does. Even the most well-resourced projects written in C tend to have trouble with low-level bugs. Same goes for C++. Both the Linux kernel and Chromium have plenty of these issues.

My comment seems to have sparked a lot of reaction about safety, but that wasn't the main point. The main point (and the one OP talks about) was about conciseness, and I can't really see how C can be considered a concise language.

Re: Goodbye C++, Hello C

#146

Post by tomn »

pjmlp wrote: post #57
yoz-y wrote: post #42

Earlier quoted context omitted.

Haven’t used Eigen for quite a while, but I do remember it being rather slow to compile once it proliferates. Those templates are clever but also quite taxing.

Even so, using another math library would have been the solution then.

The bits of eigen that make it slow to compile are the same bits that make it both easy to use and fast. I'm sure there are improvements that could be made, but ultimately eigen is big and slow to compile for a reason.

Re: Goodbye C++, Hello C

#147

Post by Thiez »

skohan wrote: post #141
Thiez wrote: post #131

Earlier quoted context omitted.

Then you'll be happy to learn that what you propose has been the case for consumer computers since protected mode was added to Intel 80286 processors in 1982. I think few people in this discussion are worrying about programs directly affecting other programs through memory unsafety, exactly because this doesn't really happen for software that isn't a driver or inside the OS kernel. The problem with memory unsafety is…

But I don't understand how data stealing can happen if each process is effectively sandboxed. If my process can't read or write to memory outside of what it allocated, how can I corrupt or steal user data?

Well it depends on your definition of sandboxed. Does your program have permission to perform I/O, either by reading/writing to a filesystem or sending/receiving data on a network?

Most "interesting" programs can perform I/O. Then you run into ambient authority and confused deputies.

Re: Goodbye C++, Hello C

#148

Post by thechao »

WalterBright wrote: post #8
thechao wrote: post #3

I like to think of a compiler as a virtual machine whose instructions are the tokens in your code, and whose output is object code. Taken that way, you can for sure optimize the input program (your C++) to execute faster on the interpreter (the compiler). Understanding how the language (any language with such features) is implemented lets you stray away from the slow parts. For instance, in C, every function has a un…

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

If I told you the first attempt was several million identically named functions, split across several hundred files, and the compile and link times were ~72 hours on a distributed build would you be happier?

A single templated function & a few n*100kloc macros later, and I got the compile time down to ~1s on a crappy laptop.

Macros are 'fast paths' through compilers — they copy structures in memory, rather than going through the entire disk->lex->parse chain.

Re: Goodbye C++, Hello C

#149

Post by humanrebar »

jolux wrote: post #24
badsectoracula wrote: post #19

Earlier quoted context omitted.

FWIW i've seen a lot of 3D codebases in C++ that avoid operator overloading and instead use something like `A.multiply(B).add(c)` to make more explicit what is going on. Some even break that into multiple calls instead of using a single expression.

I fail to understand how that’s more explicit to be perfectly honest. If it’s hard to resolve where overloads are coming from then that’s a problem but otherwise it just seems more verbose for no benefit. Addition and multiplication are the operations in use here, why shouldn’t we use their operators to represent them?

I like operator overloading, but it is susceptible to argument dependent lookup while member methods are not. The syntax is literally more explicit about what logic is being called.

Re: Goodbye C++, Hello C

#150

Post by thrower123 »

It seems like most of the issues with C++ are solved by not using the parts that suck. You can still write C++ as C-with-classes/RAII/operator overloads, and leave all the smart pointers and template meta-programming and boost (do people still use boost?) magic at the door.
Post reply on HN