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

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

alexgaynor.net

Post reply on HN
Print view View original

241–250 of 266 posts

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

#241

Post by klibertp »

clddd wrote: post #203
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…

You either pass the allocator around to every stl container, and everything that uses an stl container. Or you override new/delete and have a sidechannel that defines what arena to allocate in.

The second option seems much more convenient - I didn't know you can do that!

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

#242

Post by kazinator »

notacoward wrote: post #233
kazinator wrote: post #226

Earlier quoted context omitted.

> And it's an inoperative concept for most kernel/embedded work I recently integrated mini_httpd (a small forking server) into an embedded system as part of a solution for distributing updates across a cluster of these systems. You must be talking about 15 cent microcontrollers (that still have a TCP/IP stack with SSL) or something, not ARM cores with MMU's running Linux.

I said most kernel or embedded. It's lovely that there are all sorts of embedded devices nowadays capable to support a style of programming indistinguishable from a general-purpose system, but that's not the only or even most relevant case. There are also billions of devices out there - not just 15-cent microcontrollers either - that don't lend themselves to that style because of real-time or other requirements. Even…

This subthread is strictly about web serving. Requirements combinations like "HTTPS serving in pre-init or board-support code" or "real-time HTTPS serving in under-powered embedded board" are not practical or relevant, unless we replace "HTTPS serving" with something else.

With regard to the other point, if we are using a memory-safe language, then we can use fork to get an instant arena, regardless of how that language performs resource management under the hood. Whatever allocations happen in the request, of memory or file descriptors, are reliably gone when that exits. If there is any problem in the implementation of the memory safety, the failure is contained to a process. Thus we have an additional reason to use process containment: not having control over the memory management, and not trusting it 100%.

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

#243

Post by brundolf »

vineek wrote: post #149

I completely agree with the points from this article. It is fundamentally infeasible to make all C and C++ code safe. The main reason, PAST code. There are countless lines of unsafe code already written. However, there is nothing magical about Rust's facilities (e.g. borrow checker) that make them inapplicable to FUTURE C and C++ code. I believe this is the only way forward for C and C++. They need to offer mechanism…

Language semantics matter. If a language doesn't place very strong meaning on certain things from the get-go, no amount of static checking will ever be able to guarantee certain traits of the code written in it, because it doesn't have enough information to work off of. And I'm not just talking about undefined behavior.

People have been writing safety checkers/linters/etc for C and C++ for decades. Many of them are very impressive and useful. None of them can ever be totally sound, as a fact of the languages themselves.

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

#244

Post by matvore »

emtel wrote: post #220
jcelerier wrote: post #218

Earlier quoted context omitted.

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

Well if you have aesthetic objections to the way rust does it, I can't argue with you. Kotlin does it the way you like, though. Anyway, I started in on this thread because I was objecting to the claim that optional types always have overhead. They don't. That's all I wanted to show.

  > Well if you have aesthetic objections to the way rust does it,
I agree with GP that it is harder to maintain ("messy" they say) if there is more than one variable referring to the same value. It is not so subjective as you make it to be.

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

#245

Post by v8dev123 »

gpderetta wrote: post #212
v8dev123 wrote: post #71

Earlier quoted context omitted.

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…

there is very little OOP in boost.

I believe he imply two different things. Boost heavy on templates and the malware heavy on OOP.

His original comment was,

"Using boost to turn the code into a clusterfuck of OOP and sadness)"

Whatever. Everything is true because I've done RE my-self.

It's hard.

Another one also said,

"Reverse engineering objective-c code with heavy QT framework usage makes me seriously doubt my life and career choices."

I guess the same applies with C++ with heavy QT framework usage.

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

#246

Post by Foomf »

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…

CMake variables are also dynamically scoped, just in case things weren't crazy enough!

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

#247

Post by pjmlp »

01100011 wrote: post #238
pjmlp wrote: post #117

Earlier quoted context omitted.

Better hold your jaw with both hands while reading this, https://www.f-secure.com/en/consulting/foundry/usb-armory

Uh, if you think that's bad, I once worked at a company that made communications gear for first responders and the military. Most of their stack was written in Python 2. I'm not talking UI, I'm talking systems software level stuff. Python tied together with dbus on top of a shake-n-bake Yocto distro that was out of date. People's lives depended on that tower of crap.

Why should it be bad?

One less device running C, with firmware written in a type safe language that takes bounds checking seriously.

As for Python, I recommend you to have a look at IEEE magazine.

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

#248

Post by shinazueli »

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…

I was with you until the last sentence. I write Rust code at scale, with schedule and performance constraints. I’ve literally never had to use the word unsafe in my code.

If you can’t figure out how to do it without fucking up the borrow checker, that’s because you can’t figure it out, and you need to learn how to do your job. You’re never “forced” to hack anything.

Blaming “a whip of agile” is just bad taste. Don’t be bad. Like, wtf, you had a decent comment and then shat the bed right at the end.

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

#249

Post by rhn_mk1 »

hctaw wrote: post #239
rhn_mk1 wrote: post #236

Earlier quoted context omitted.

> But it's really good at one thing: compiling crates. Unless you're using "compiling" as strictly compiling, and not "building", then I don't agree either. It falls flat on its face if you want a build time choice between dependency versions, for example. And build.rs means that Cargo washes its hands from compiling parts of crates that are not written in Rust, so it's arguably not good at compiling (of anything but…

As much as I agree that Rust needs a better story for builds and interacting with other languages, it sounds like you have a misunderstanding over what Cargo primarily does and what crates are. A crate is a single compilation unit of Rust. Cargo is a tool for compiling crates and pulling in other crates that it references. build.rs is a half measure to include foreign symbols in compilation artifacts like static/shar…

A crate may be a compilation unit, but it's irrelevant. Within the Rust space, a crate is a library. something like 95% of crates are using Cargo, and Cargo requires that dependencies are also using Cargo. Today it's impossible to ditch Cargo, and publish your crate with e.g. Bazel as the build system.

There's no misunderstanding that what Cargo does it build Cargo crates. The problem is that it doesn't allow for sanely built (so not using Cargo) crates.

> specifying dependency versions at build time

Packaging for different distributions, where different versions of a dependency are provided, is quite a common thing, and has justifications beyond technical reasons.

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

#250

Post by vineek »

wdpk wrote: post #234
vineek wrote: post #149

I completely agree with the points from this article. It is fundamentally infeasible to make all C and C++ code safe. The main reason, PAST code. There are countless lines of unsafe code already written. However, there is nothing magical about Rust's facilities (e.g. borrow checker) that make them inapplicable to FUTURE C and C++ code. I believe this is the only way forward for C and C++. They need to offer mechanism…

by the same token you could say it's also fundamentally infeasible for Rust to be code safe, otherwise they would not have unsafe code... so in the end it's an article that says nothing interesting at all

The ability to occasionally opt-out is both a feature and a necessity because certain systems are inherently unstable and offer varying guarantees. I’m arguing for an opt-in feature in C++. Of course there is no panacea.
Post reply on HN