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

Modern C++ Won't Save Us

alexgaynor.net

Post reply on HN
Print view View original

371–380 of 395 posts

Re: Modern C++ Won't Save Us

#371

Post by tomtung »

jstimpfle wrote: post #294
lmm wrote: post #292

Earlier quoted context omitted.

> I don't see why that should be the case. At the most basic level, if project A makes use of library B and library C, then you want to be able to verify the behaviour of library B and library C independently and then make use of your conclusions when analysing project A. But if library B and library C use global state then you can't have any confidence that that will work. E.g. if both library B and library C use so…

> At that point you're not using global state in the library, which was the point. Yes. But I want to make clear that you are still using global state for all uses within the project itself. The library can be implemented in whatever way. For example, setting the pointer in a global variable on API entry ;-) > That doesn't solve the problem at all. WHICH problem? I don't think there is one. > Indeed, and they're seen…

At this point I'm really unsure whether this is trolling or not.

Re: Modern C++ Won't Save Us

#372

Post by colanderman »

int_19h wrote: post #354
colanderman wrote: post #95

Earlier quoted context omitted.

What parts specifically? By my estimation, the only non-deprecated part of the standard library that really reeks of pre-C++11 (what I believe most consider the advent of "modern") is iostream. Most of e.g. the containers have been kept up to date with new features of the language (e.g. move semantics, constexpr). The standard library certainly is lacking things which are commonly used (say, JSON parsing or database…

Surely JSON does have a settled, obvious, lowest-common-denominator semantics?

Of the design of a parsing and encoding library? Not at all. Do you parse as a stream or all in one go? Are values represented as a special "json" type, or as built-in types? How should arrays and objects be represented? Are integers and reals different types? Are trailing zero decimals significant? Do you allow construction of arrays and objects in any order, or only sequentially?

(Granted, I've written my own C++ JSON library which I believe answers all these questions in an intuitive way, following both the design principles of the C++ standard library, and the lowest-common-denominator semantics of JSON, but it's sufficiently opinionated that I doubt I could convince any significant portion of C++ users that it's the "right" way to do things. Even if it "is", demonstrating such is nowhere near as easy as it is for unique_ptr, vector, string, thread, etc., each of which are more or less the "obvious" designs given certain constraints such as RAII to which the standard library adheres.)

Re: Modern C++ Won't Save Us

#373

Post by tmyklebu »

dman wrote: post #4
781 wrote: post #3

There was an article recently about a behavior which in a recent version of C++ was made from defined behavior into undefined behavior, because making it undefined allowed for better compiler optimizations. I always thought that undefined behaviors were historical accidents. But apparently sometime people just say "hey, lets add a few more undefined behaviors" This is the insanity of C++

Can you please find a reference? That sounds interesting.

Not exactly what you asked for, but C11 added this bit that was not there in C99:

An iteration statement whose controlling expression is not a constant expression, that performs no input/output operations, does not access volatile objects, and performs no synchronization or atomic operations in its body, controlling expression, or (in the case of a for statement) its expression, may be assumed by the implementation to terminate.

And C++11 added this bit that wasn't there in C++03:

A loop that, outside of the for-init-statement in the case of a for statement, - makes no calls to library I/O functions, and - does not access or modify volatile objects, and - performs no synchronization operations (1.10) or atomic operations (Clause 29) may be assumed by the implementation to terminate.

[Note: This is intended to allow compiler transformations, such as removal of empty loops, even when termination cannot be proven. -- end note]

Re: Modern C++ Won't Save Us

#374

Post by geezerjay »

daemin wrote: post #276
barrkel wrote: post #192

Earlier quoted context omitted.

Standard libraries shouldn't include "leaf" modules, but probably should include interface / adapter modules. So no to JSON, but maybe yes to a serde interface. No to a database driver, but maybe yes to an interface like JDBC. Without common interfaces, flexibility in implementation is much more expensive, and innovation suffers too, as new things are harder to get off the ground without existing code that they can c…

There's an argument to be made for having basic so-called leaf modules in the standard library. That is it makes it far simpler to get a basic installation of C++ and start doing cool things with it. Experienced developers or people that need domain specific features would be using their own specialised libraries anyway. So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a w…

> So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a window and have it change colour, you just write it using the standard library.

Congrats, now you're stuck with something like Xwindows or MFC or AWT.

Re: Modern C++ Won't Save Us

#375

Post by pjmlp »

kaens wrote: post #285
pjmlp wrote: post #275

Earlier quoted context omitted.

People should reference more the original works of the past instead of rediscovering them

I think more rediscoveries may be references than you suspect, but in the cases that are rediscoveries there is a bit of a knowledge and discoverability issue for PL features for people who aren't PL nerds already. I'd love it if more people had a more solid understanding of the ideaspaces that have been covered in the PL landscape, but considering that most common paths to working in software (and even to creating a…

I keep posting them here.

How I got to learn about them?

Having a solid Informatics Engineering degree, with focus on systems programming, graphics and compilers, and a very nice university library.

That was it, we had to hunt for books, compuserve, gopher and BBS were still a thing.

Nowadays learning about the history of PL is a google/bing/... search away, a couple of seconds with access to plenty of scanned papers and conference proceddings since the early 60's, so one has to be quite lazy not to research them.

Re: Modern C++ Won't Save Us

#376

Post by coldtea »

geezerjay wrote: post #343
coldtea wrote: post #223

Earlier quoted context omitted.

> I strongly disagree. It's quite obvious that the C++ standard library does not need to add support for "common things", because they already exist as third-party modules. It's not obvious to me at all. In fact, if that was a valid argument, it would be for C++ not having a standard library at all, as everything (including vectors, strings, etc) also exists as "third-party modules".

> In fact, if that was a valid argument, it would be for C++ not having a standard library at all Putting aside the continuum fallacy, it's easy to understand how the C++ would be better served by having access to a collection of third-party components instead of repeating C's and even Java's mistakes. The Boost project is a very good example, so as the wealth of JSON and XML parsers. In fact, this lesson is so blata…

>Putting aside the continuum fallacy, it's easy to understand how the C++ would be better served by having access to a collection of third-party components instead of repeating C's and even Java's mistakes.

Java is very well served with its library. It would have been nowhere near as successful without it.

Re: Modern C++ Won't Save Us

#377

Post by jstimpfle »

tomtung wrote: post #371
jstimpfle wrote: post #294

Earlier quoted context omitted.

> At that point you're not using global state in the library, which was the point. Yes. But I want to make clear that you are still using global state for all uses within the project itself. The library can be implemented in whatever way. For example, setting the pointer in a global variable on API entry ;-) > That doesn't solve the problem at all. WHICH problem? I don't think there is one. > Indeed, and they're seen…

At this point I'm really unsure whether this is trolling or not.

Just discussing. Why would it be trolling what I do and not what the other guy does?

Re: Modern C++ Won't Save Us

#378

Post by pjmlp »

geezerjay wrote: post #374
daemin wrote: post #276

Earlier quoted context omitted.

There's an argument to be made for having basic so-called leaf modules in the standard library. That is it makes it far simpler to get a basic installation of C++ and start doing cool things with it. Experienced developers or people that need domain specific features would be using their own specialised libraries anyway. So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a w…

> So instead of trying to figure out which one of the dozens of GUI frameworks to use in making a window and have it change colour, you just write it using the standard library. Congrats, now you're stuck with something like Xwindows or MFC or AWT.

Which while not ideal, are guaranteed to be present, contrary to third party libs.

Re: Modern C++ Won't Save Us

#379

Post by pjmlp »

ncmncm wrote: post #322
lmm wrote: post #254

Earlier quoted context omitted.

> It has been many years since I shipped a memory bug in C++. It is just not a real worry for me. Can you write down the algorithm that you use to avoid writing memory bugs? Can you teach others how to do it? Experienced C++ programmers do seem to learn how to avoid those bugs (although very often what they write is still undefined according to the standard - but e.g. multithreading bugs may be rare enough not to be…

>Can you write down the algorithm that you use to avoid writing memory bugs? Can you teach others how to do it? Yes. Code using powerful libraries. Every use of a powerful library eliminates any number of every kind of bug. Rust has not caught up to C++'s ability to code powerful libraries, and might never. C++ is a moving target. C++20 is more powerful than C++17, which was more powerful than 14, 11, 03. There are c…

Rust cannot displace Ada until it fulfills the business and security requirements that keep Ada alive.

Re: Modern C++ Won't Save Us

#380

Post by pjmlp »

lmm wrote: post #358
ncmncm wrote: post #355

Earlier quoted context omitted.

This is the classic False Dichotomy. Rust programs have bugs. Rust programs have security bugs. Are they mediated by memory usage bugs? Probably not, unless the program has unsafe blocks, or uses libraries with unsafe blocks, or libraries that use libraries that have unsafe blocks, or call out to C libraries. Or tickle a compiler bug. Can it leak my credentials to a network socket as a consequence of any of those bug…

> Can it leak my credentials to a network socket as a consequence of any of those bugs, memory or otherwise? Sure, that class of bugs still exists. But they're rarer and less damaging (even with stolen credentials, an attacker can't do as much damage as one who had arbitrary code execution). Rust eliminates many classes of bugs. C++ does not: the fact that theoretically there could be non-buggy C++ libraries doesn't…

Kind of true, AFAIK Rust binary libraries don't expose safety information, like it happens in ClearPath or .NET Assemblies.

Still too many libraries make use of unsafe when they could be fully written in safe Rust.

Post reply on HN