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

C++20, How Hard Could It Be

docs.google.com

Post reply on HN
Print view View original

161–170 of 444 posts

Re: C++20, How Hard Could It Be

#161

Post by Calavar »

Sharlin wrote: post #112
jmillikin wrote: post #94

Earlier quoted context omitted.

When I was going to university the computer science department's primary system had two compilers available, GCC 2.96[0] and TenDRA. GCC was generally more popular but it didn't have std::string and any code that threw an exception would crash, so adventurous students would use TenDRA for development. One of the stranger behaviors of TenDRA was that it put all standard library symbols, including the C headers , into…

C symbols are supposed to be in std if you use the cstdio style headers. It’s just that for a very long time compilers put them into the global namespace too.

GCC, Clang, and MSVC all still duplicate c* header definitions into the global namespace by default as far as I'm aware.

In fact, the last time I checked, the MSVC cstdio header was implemented more or less like this:

    namespace std {
        #include 
    }

    using namespace std;
It's kind of crazy how major compilers have been ignoring the standard for so long that people consider a standard compliant compiler to be weird and broken.

Re: C++20, How Hard Could It Be

#162

Post by [deleted] »

jmillikin wrote: post #94
fouronnes3 wrote: post #88

Earlier quoted context omitted.

One day in the far away future the standard C++ hello world will use 'import std;' and 'std::print' and it will be glorious.

When I was going to university the computer science department's primary system had two compilers available, GCC 2.96[0] and TenDRA. GCC was generally more popular but it didn't have std::string and any code that threw an exception would crash, so adventurous students would use TenDRA for development. One of the stranger behaviors of TenDRA was that it put all standard library symbols, including the C headers , into…

[deleted]

Re: C++20, How Hard Could It Be

#163

Post by deadbeeves »

JonChesterfield wrote: post #115
spoiler wrote: post #86

Earlier quoted context omitted.

I kinda feel bad for taking this jab at C++, since it feels a bit below the belt... But that's kinda C++'s thing, isn't it? You can either do the correct thing, or the succinct thing. There's hardly ever a satisfying compromise between the two either. Obviously, we want to do the correct thing most of the time, so that's why C++ ends up being full of ceremonious implementations in practice. And alas, they're usually…

That seems a fair observation to me, with the tweak that "correct" changes over time. C++ code can be written perfectly and still rot as the ecosystem changes, without changing the source. We are really keen on preserving backwards compatibility, but break existing code anyway. We will not define a stable ABI, but also won't fix stdlib if it breaks ABI. Also all code definitely has UB in it waiting for a compiler cha…

>C++ code can be written perfectly and still rot as the ecosystem changes, without changing the source.

But that's true of any system that depends on other systems with lax respect for contracts, or with no contract. You can depend on a third-party function get_time() that returns the seconds since the program started, and later on if its maintainers decide to change it to return a UNIX timestamp because they realized the wording was vague enough to allow it, any code that makes the wrong assumption will break.

C++ is, I would say, quite good as far as backwards compatibility goes. The problem IMO is that it's rather complex and some of its features have been misunderstood over time, such as the meaning of volatile or inline, and thus people have been writing subtly broken code that just happened to work when they originally wrote it.

Re: C++20, How Hard Could It Be

#164

Post by xyzzy4747 »

superdimwit wrote: post #159
xyzzy4747 wrote: post #156

I wonder how long it would take an experienced developer to rewrite all of Chrome in Rust. It would probably take a special person though who is an expert in C++, Rust, and the codebase.

30 years?

Why do you think that? How complicated could it possibly be? Also as a person becomes more of an expert in a specific thing, they make progress much faster (if they remain motivated).

Also it’s just rewriting the logic. One could theoretically write unit tests for every function to make sure the inputs/outputs match.

Re: C++20, How Hard Could It Be

#165

Post by tialaramex »

kasajian wrote: post #146
codeflo wrote: post #53

Many are of the listed items are merely being deprecated. These shouldn’t really qualify as breaking changes. In fact, the ability to migrate away incrementally is precisely the point of deprecating instead of removing a feature. What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a s…

The real solution, which decades from now will be the eventual common-place, but no one dares to imaging the possibility today is that when languages deprecate a feature, the compilers deliver code-mods that migrate your code-base perfectly. But people are afraid of going that route because of the bad press around Python 2 / 3. We need a new generation of developers that don't remember that. Today, there's already st…

Transformations are difficult.

Rust provides best effort transformation for its Editions (which only touch syntax) in cargo fix --edition, but even that's only best effort. If a proc macro does something ludicrous (see Mara's whichever-compiles! macro for example) how can the transformation hope to keep up?

C++ versions are in much deeper, they not only change the language syntax, but also semantics of existing features. Sometimes the intended effect is null (but intentions may not match reality) and sometimes it is not.

C++ also substantially changes the standard library. Rust's standard library grows but doesn't get redefined in new Editions, so if you call a deprecated Rust function it's not going anywhere, whereas a deprecated C++ method might actually go away in a future version.

It's a shame that the best effort tools aren't provided with C++ compilers, but even if they were provided on a large codebase it's only the beginning for large projects.

Re: C++20, How Hard Could It Be

#166

Post by fouronnes3 »

scatters wrote: post #129
fouronnes3 wrote: post #88

Earlier quoted context omitted.

One day in the far away future the standard C++ hello world will use 'import std;' and 'std::print' and it will be glorious.

The far away future? You mean next year?

I don't mean available as in the committee has published their final version of the standard that allows it. I mean available in production.

Re: C++20, How Hard Could It Be

#167

Post by nikic »

pjmlp wrote: post #16

It is so ironic, that now that Apple and Google decided to focus on their own language stacks, the C and C++ compiler vendors that profit from clang's license aren't that keen in making the upstream work for catching up with ISO C++. Thus making the once famous clang having an honorable third place in ISO C++ compliancy. Seeing this from a Google team makes it even more ironic.

This has no relation to Clang's permissive license. The problem here is generally that nobody has implemented the necessary support, not that they have implemented support in their private forks but did not bother to upstream it. A GPL-style license doesn't magically force contributors to start working on a particular feature.

Google at least is one of the largest contributors to the LLVM project -- it's just that their contributions don't tend to focus on Clang frontend work.

Re: C++20, How Hard Could It Be

#168

Post by RicardoLuis0 »

munch117 wrote: post #93
mgaunard wrote: post #42

Earlier quoted context omitted.

well to begin with if you're using volatile, you're probbaly doing something wrong already. The valid use cases for it are ridiculously few.

But if you're using volatile correctly, then there's nothing wrong with ++*v. I was wondering about that slide that says the meaning is unclear, I don't see what's unclear about it. What particular assembly instructions it translates into is irrelevant. It's not like ++ is guaranteed atomic or anything.

it's not guaranteed atomic, and if you ARE using volatiles, "maybe" doesn't really cut it, so now you need to do `++*v` the proper way (ex. `lock cmpxchg` / `__atomic_compare_exchange`), or explicitly write it out the long way (`*v = *v + 1`) and risk the small chance of the value changing under you between read/write

Re: C++20, How Hard Could It Be

#170

Post by cesaref »

cletus wrote: post #135
arinlen wrote: post #128

Earlier quoted context omitted.

> The C++ standard currently sits at >1800 pages. Looking through these examples, I'm honestly horrified. I feel you're embelishing too much your personal feeling of horror. The C++20 standard doc is a hair smaller than 1900 pages, but the complete core language is specified in the first 460 pages, of which around 100 are dedicated to templates. Thus around 1400 pages of a 1900page doc are dedicated to specify librar…

You could focus on those 460 pages but I'll raise 2 points: 1. There's still a lot of complexity and ambiguity you can fit in 460 pages. This presentation notes one example of decrement operators on volatile variables being deprecated because the behaviour was undefined; and 2. Can you really separate the standard library from the language at this point? Things like move semantics depend on std. Does anyone actually…

1. The problem you've highlighted (pre/post increment of volatiles) is present in C, and hasn't been addressed there. This is a problem in c2x on compiler explorer for example. So i'd probably say laying this at the feet of the overly large C++ language spec isn't fair. I'm going to probably say it's been there since K&R C days (I think volatile was supported even that far back, but my memory is a bit hazy about such things).

2. This is a good point. I'd counter it by asking does anyone use all of the standard library in a project? If I were to include what i'd ever used, it's probably a subset of the standard.

I hadn't thought about std::move, and actually had to look up which header it's pulled in from, since it tends to get pulled in by other stuff i'm using!

Post reply on HN