C++17 Is Complete, Work On C++20 Is Getting Underway

[liam]

So you blame them both to visit (phoronix) forum flaming abt programming languages? You sir, are a troll!

I'm giving you the benefit of the doubt by assuming English isn't your native language. Otherwise, i don't know how I'm supposed to interpret your response.
I've been on these forums for years (so i didn't "blame then both to visit (phoronix) forum" and i didn't participate in any flaming.
Now, it's possible i misinterpreted your post to which i responded. I read this section:

Then some newcomer hipster comes (often without in-depth knowledge of anything with the need to distinguish himself) and tells them it is all unnecessary deprecated and bad ...

as applying to anyone who thinks the current paradigms are insufficient. That you call such folks "hipsters" adds to my concern that we have a language barrier issue.

[coder]

If you have to support old compilers, you have to write C++ without using the new features - it's unfortunate for you but I'm not sure what benefit you'd get by C++ not being updated for anyone else either? The problem you mention above seems like it would be fixed by just compiling everything on a given platform in the same way.

Leaving aside the embedded DSP, both of the other platforms I mentioned are current and supported. As you might know, enterprise OS distros tend to lag, a couple years. But the Android NDK release is just weeks old!

Again, the problem with the frequent standards updates that add lots of new features is that they tempt library authors into using them, leaving everyone who's not on the bleeding edge in the dust. In the world of real products with real customers that expect reliability and support, bleeding edge isn't an option.

And, as I also mentioned, there are costs associated with transitioning. With a large, real-world codebase, it's often not as simple as updating your compiler and flipping a switch to enable the new standard features. Because of the issues it tends to cause, organizations become more wary of switching to the new standard. We almost had to abort our C++11 transition, when we encountered the incompatible template instantiation problems I mentioned above!

These concerns might not apply to many of you, but you're just wrong if you're arguing that they're not real issues. By alienating a set of its users, the C++ standards committee risks doing more harm than good to the user community, as a whole.

[ldo17]

For decades, people were stuck with text based shells.

You make that sound like it’s a bad thing...

[carewolf]

I've used Boost for about 14 years. Most parts of it are pretty great. Many of the good improvements in the language have come from limitations encountered by its authors, and I agree with the idea of migrating some of its most popular and stable facilities into the standard library.

But I firmly reject the idea that it's a high virtue to write code with no external library dependencies. Yes, you want to keep the number of dependencies low, but it's not worth bloating up the standard just so you can feel "clean". Boost proves that high-quality open source libraries are more than adequate at meeting user needs. All the standard really needs to do is make sure the library authors are unimpeded.

You are right except about using boost. Boost is experimental and unstable. It is not something you should ever rely on in published code.

[garegin]

You make that sound like it’s a bad thing...

Emm. I read the article and it's talking about use of confusing aliases. Nothing to do with the advantages of not scraping text from an output. BTW this issue of text based shells is mentioned in the Unix Hater's Handbook.

[pal666]

This is complete nonsense. The latest Rust nightly from today still compiles code written two years ago for the 1.0

lol. 2 years ago !!!11111

[pal666]

Great, now C++ is worth a book 900 pages instead of 700.

so, how does it compare to java or c#? remember, it does not compete with languages for kids

[pal666]

As a practicing C++ programmer, I really fear they're going to keep adding stuff until it becomes unlearnable and unimplementable. C++ already has a learning curve years long, and that's a big impediment to hiring developers.

practicing c++ programmers are expected to be better educated. "they" are adding stuff with explicit goal of making language easier to learn. and any non-trivial stuff is added only after working implementation

IMO, they should just fix stuff that's broken (i.e. not fully usable as intended or as people are trying to use it). Std libraries should focus on portability, abstract data types, and fundamental algorithms.

imo if you have no idea what are they doing, you shouldn't give you valuable advice

And 2D graphics has a scope far too large, and it's difficult to do in a truly one-size-fits all fashion. Another thing that makes it a poor candidate for ISO standardization is the likelihood that you get everything right in the standard. They'll have to do lots of bug-fixing and cleanup. Industry consortia like Kronos are much better vehicles, for things of this sort.

competitors(java and c#) have 2d graphics. c++ users(not you, but there are several millions of not you) are asking for 2d graphics. they are not doing one size fits all, they are standardising cairo api. and what makes your think kronos standard will magically become better than iso c++? at least iso c++ has to be implemented by all compiler vendors

[pal666]

It's not about agreeing whether feature XYZ is an improvement, it's about whether it offers enough benefit to introduce incompatibilities in code.

people much smarter than you are making sure that there will be no incompatibilities introduced

I have already run into a library that I can't use on a particular platform, because its compiler doesn't yet support some of the C++17 feature the author decided to use.

think of it as you found library written in rust without support for your platform. or like you didn't find library. compatibility does not work like that, it only allows you to compile old code with new compiler

We can both agree on ways that a feature could be improved upon, and still disagree on whether it should be added to the language.

no, we can't. if you don't like feature - don't use it, don't use new language version, or don't use language. go use cobol

As for std::byte, there's already uint8_t, and I fail to see the value in pretending that it can't be treated as a signed or unsigned integer.

byte does not allow arithmetic. regardless of you failures, new enum in std namespace will not make your life harder

And if you like Cairo, great - why not keep using Cairo? Why bloat up the standard with it?

why bloat your post with bullshit ideas that library addition can bloat standard? competing language have orders of magnitude larger standard libraries. and you can't use cairo because it is not in standard - you can't depend on it. besides, random libraries usually have shitty apis from c++ pov

There are two major downsides to putting it in the C++ standard. First, it'll inevitably have shortcomings and bugs

everything inevitably has shortcomings and bugs. it is not reason to not put into standard

, which will push library developers to adopt C++23 features, restricting the usability of their libraries on platforms that aren't at the bleeding edge.

you have to fix your shitty platform instead of crying. btw, does your shitty platform suport cairo?

Second, it further raises the bar for any platform that wants to provide a standards-conformant C++ implementation.

but it lowers the bar for people who want to do 2d graphics in c++. you see, standard is made to help c++ users, not to help some shitty platforms. btw standard will describe implementation of cairo wrapper, so any shitty platform with cairo could copy-paste it and get standards-conforming implementation.

I already have to maintain support for one C++ code base on a DSP without a fully-C++11 conformant compiler,

nobody cares. nobody is going to stop because of you. you have shitty platform - you will live with your shit. everyone else will move forward. next time select platform with proper gcc or llvm port

The C++ standards committee should not be trying

coach experts should not be trying to think, to avoid overloading of brain

They should be

do you know that participation in committee is free for you? why don't you move your ass and join?

[pal666]

For what it's worth, I agree. It's nice(?) that we now have a binary type that does not support certain math operations - but you know what, you can't use it to implement something like compress() because that _will_ need those math operations internally.

first, maybe your compress will need, but my wouldn't. btw, why does your compress need multiplication and division? second, you should think more about functions like memcpy or memcmp (it takes void * and void can do even less than byte)

uint8_t would have been more than enough.

if uint8_t is enough for you, nobody is forbidding you to use it

Moreover, I would like a rule to state that undefined behaviour, _if detected by the compiler_, must actually be an error condition, rather than an excuse to let the optimizer go wild.

it does not work like that. program with ub is not c++ program. c++ compiler expects c++ program from you, so he assumes that there will be no ub in it(because some codepath will never be taken at runtime for example). and that assumption is what allows him to generate better code

C++ would be better off dropping C compatibility completely, except for those bits that allow it to interoperate with a library written in C.

i.e. except all c bits, because all c bits can be found in c library headers

At least that would open the door towards fixing or deprecating the worst parts of the C standard library, and remove at least some warts on the language.

don't forget that all supported c bits are used by non-c c++ code somewhere