C++ 17 in detail - Part 1 - Language Features

[Real Troll]

<https://lp.embarcadero.com/Cpp17eBook?utm_source=Eloqua&utm_medium=email&utm_content=Article-200306-CppBuildereBook>

I have uploaded the book here:

<https://drive.google.com/file/d/1W0Em5ioHiBdIG3LeXqpwla4wcPxvOBKq/view?usp=sharing>

It saves you filling out the form!!!!

[jacobnavia]

Interesting. A document of about 100 pages just to explain de
differences between C++17 and C++14.

C++ programmers must have big brains, the standard of C++17 is 1633
pages long! Imagine how much brain space that takes...

The whole bible (King James edition) has 1513 pages...

And everybody is happy of course. The committee goes on adding and
adding features, then adding features to fix added features, then adding
features to fix the fixings...

Is anyone following? Maybe, some enthusiast people are always trying to
learn the latest fad, but this incredible featurism is leading the
language into a pit it will never be able to get out.

Just too complex, too much time needed to master a small part of it that
could be useful... It is SO BIG that a beginner has no chance in the
first few years, of understanding why something compiles or why it doesn't.

[Daniel]

On Sunday, March 8, 2020 at 4:31:10 PM UTC-4, jacobnavia wrote:
>
> Interesting. A document of about 100 pages just to explain de
> differences between C++17 and C++14.
>

Only 100?

C++ Move Semantics - The Complete Guide, _started_ with 110 pages, and, as
the author explains, "...the content grows with new chapters, examples, and
caveats about the features of move semantics and I integrate all feedback I
get for the pages already published" - https://leanpub.com/cppmove

Daniel

[Juha Nieminen]

jacobnavia <ja...@jacob.remcomp.fr> wrote:
> Just too complex, too much time needed to master a small part of it that
> could be useful... It is SO BIG that a beginner has no chance in the
> first few years, of understanding why something compiles or why it doesn't.

Then don't use it. Your infantile whining is useless. Grow up.

[Daniel]

It is, nonetheless, a legitimate observation, and I'm doubtful that many with
repute on this newsgroup would dispute it. Whether making it serves any
purpose, of course, is another matter.

Daniel

[Cholo Lennon]

Why your critic? "Then don't use it" is really an infantile phrase.

He's right, the language is too complex even for advance programmers,
and the complexity is not free, it costs a lot of money and time
(programmers, companies, tool vendors, compiler vendors, etc, all of
them suffer it). It's too complex that the whole tool ecosystem sucks if
you compare it with other languages. And a language that has bad tools
it's a complete failure IMHO. Hiring new competent C++ programmers is
really hard nowadays, and a language without users... you know... tend
to disappears.


--
Cholo Lennon
Bs.As.
ARG

[Öö Tiib]

On Monday, 9 March 2020 02:37:40 UTC+2, Cholo Lennon wrote:
> On 3/8/20 8:12 PM, Juha Nieminen wrote:
> > jacobnavia <ja...@jacob.remcomp.fr> wrote:
> >> Just too complex, too much time needed to master a small part of it that
> >> could be useful... It is SO BIG that a beginner has no chance in the
> >> first few years, of understanding why something compiles or why it doesn't.
> >
> > Then don't use it. Your infantile whining is useless. Grow up.
>
> Why your critic? "Then don't use it" is really an infantile phrase.
>
> He's right, the language is too complex even for advance programmers,
> and the complexity is not free, it costs a lot of money and time
> (programmers, companies, tool vendors, compiler vendors, etc, all of
> them suffer it).

Most of the complexity plus pointless backwards compatibility support
of useless peculiarities like octal numbers and EBCDIC character
encodings is perhaps voted in by monsters who have huge piles of legacy
trash C++ code lying around and on other hand want C++ to look like
garbage compared to their proprietary toy languages (swifts, golangs,
javas, csharps).

> It's too complex that the whole tool ecosystem sucks if
> you compare it with other languages. And a language that has bad tools
> it's a complete failure IMHO. Hiring new competent C++ programmers is
> really hard nowadays, and a language without users... you know... tend
> to disappears.

It is pointless to whine. For example why there is constexpr if there are
no way to detect compile time if something is constexpr or not?
It was in C++14. There was rule in C++14 that constexpr is noexcept.
However that was removed by P0003
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html>
by C++17. The committee (read clicque consisting mostly of wormtongues
of monsters) was informed, but they left it like it was. So C++ is
technically doomed to become worse and worse pile of debris with each
iteration.

[jacobnavia]

Well, of course I will not use it. Even if I wanted to use it, it would
take me so many years to be productive that it is not really worth the
effort.

But your answer, devoid of any arguments, is typical of the "group
think" that abounds in C++ expert circles. Critics to this race to ever
increasing complexity will just be dismissed without even trying to
adress the concerns about this complexity nightmare.

[Jorgen Grahn]

On Sun, 2020-03-08, Daniel wrote:
> On Sunday, March 8, 2020 at 7:12:11 PM UTC-4, Juha Nieminen wrote:
>> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>> > Just too complex, too much time needed to master a small part of it that
>> > could be useful... It is SO BIG that a beginner has no chance in the
>> > first few years, of understanding why something compiles or why it doesn't.
>>
>> Then don't use it. Your infantile whining is useless. Grow up.
>
> It is, nonetheless, a legitimate observation, and I'm doubtful that many with
> repute on this newsgroup would dispute it.

Don't know I have repute, but I dispute it, even though I'm sceptical
to the current pace and direction of C++ development.

If you get over the fact that you don't know the whole language
(including standard library) I don't think C++ is that difficult to
master. And in particular, I'm pretty sure that in terms of working,
useful code, you can do a lot more, earlier, if you start with C++
than with C.

> Whether making it serves any purpose, of course, is another matter.

The "OMG it's so complex!" message may prevent some migration from C
to C++.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Maciej Sobczak]

> C++ programmers must have big brains, the standard of C++17 is 1633
> pages long! Imagine how much brain space that takes...
>
> The whole bible (King James edition) has 1513 pages...

This still does not tell whether the C++ standard is too long, or The Bible is too short, or both are too long, or ... The sure difference being that you can be forgiven for using only a subset of C++. ;-)

But:

Java: The Complete Reference, Eleventh Edition = 1248 pages.
Core Java (Vol. I+II) = 928 + 960 = 1888 pages.

These are *references*, so presumably they were made as short as reasonably possible.

> And everybody is happy of course.

Of course. And those who are not, are free to move to Java.

> The committee goes on adding and
> adding features,

And judging by the size of Java books, you could conclude that perhaps this is what the programming community actually asks for. Because even if you invent a much smaller language, it will (inevitably?) grow to address the needs that it did not address when it was young and small.

> this incredible featurism is leading the
> language into a pit it will never be able to get out.

And where exactly you would like it to get out?

> too much time needed to master a small part of it that
> could be useful...

I disagree. Most of the complexity addresses the needs of library authors. The language can be immensely useful for library *users* in some reasonably small subset, that can be understood by, even if not complete beginners, then by people who have already seen the ideas of statically typed imperative languages (it is also the task for library authors to design their APIs for wider audience). Then, more advanced concepts can be acquired as the professional career progresses in its natural pace.
You can only complain that you cannot not get 20 years of experience within the first 2 years of practice. Well.

But in other languages it does not seem to be any different.

--
Maciej Sobczak * http://www.inspirel.com

[Ian Collins]

On 09/03/2020 19:52, jacobnavia wrote:
> Le 09/03/2020 à 00:12, Juha Nieminen a écrit :
>> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>> Just too complex, too much time needed to master a small part of it that
>>> could be useful... It is SO BIG that a beginner has no chance in the
>>> first few years, of understanding why something compiles or why it doesn't.
>>
>> Then don't use it. Your infantile whining is useless. Grow up.
>>
>
> Well, of course I will not use it. Even if I wanted to use it, it would
> take me so many years to be productive that it is not really worth the
> effort.

You could be more productive tomorrow with just a the C subset and a
tiny bit more. But you already know (and will probably carry on
ignoring) that.

--
Ian.

[David Brown]

On 09/03/2020 09:14, Maciej Sobczak wrote:
>> C++ programmers must have big brains, the standard of C++17 is 1633
>> pages long! Imagine how much brain space that takes...
>>
>> The whole bible (King James edition) has 1513 pages...
>
> This still does not tell whether the C++ standard is too long, or The
> Bible is too short, or both are too long, or ... The sure difference
> being that you can be forgiven for using only a subset of C++. ;-)
>

The key point is to use the subset of C++ that works for you. C++ is a
big language, with a big library, and a huge range of uses. No one is
ever expected to know it all, or find all of it useful. But each part
of it is likely to be useful to /somebody/.

> But:
>
> Java: The Complete Reference, Eleventh Edition = 1248 pages. Core
> Java (Vol. I+II) = 928 + 960 = 1888 pages.
>
> These are *references*, so presumably they were made as short as
> reasonably possible.

For most large languages, complete references and documentation will be
huge. The documentation for Python or PHP will also be massive, and the
languages are full of features that are useful to a few people, and
totally beyond most programmers. Hands up all Python programmers who
truly understand metaclasses, decorators and generators? Hands up all
MSVC programmers who know the entire Windows API? Hands up all C
programmers who understand all the details of floating point?

Hands up all the English speakers who know all the words in the OED?

There is nothing wrong with a language being too big for people to know
it all. Problems only occur when a lack of knowledge of some parts
means you make subtle mistakes in parts that you think you know. But
that occurs in smaller languages too (like C).

>
>> The committee goes on adding and adding features,
>

I've seen several types of features added to C++ over the years. Some
are pure library additions - use them if you want them, or ignore them
if you don't. Some are language enhancements that are hard to
understand, but can mostly be ignored if you want (like rrefs and move
semantics). Some language enhancements sound complex, but make code
simpler (like concepts eliminating gruesome "enable_if" code). Some are
incomprehensible to many people, but allow useful libraries (you don't
have to understand how to write variadic templates in order to use
variants).

C++ does suffer from a some serious issues, however. Backwards
compatibility can make things more awkward or bulky than it should be
(someone mentioned EBCDIC, for example). And sometimes the balance
between "make this feature available so that people can use it" and "be
sure this feature doesn't have unexpected problems before it is
released" doesn't hit the mark.

>
>> this incredible featurism is leading the language into a pit it
>> will never be able to get out.
>
> And where exactly you would like it to get out?
>
>> too much time needed to master a small part of it that could be
>> useful...
>
> I disagree. Most of the complexity addresses the needs of library
> authors. The language can be immensely useful for library *users* in
> some reasonably small subset, that can be understood by, even if not
> complete beginners, then by people who have already seen the ideas of
> statically typed imperative languages (it is also the task for
> library authors to design their APIs for wider audience). Then, more
> advanced concepts can be acquired as the professional career
> progresses in its natural pace. You can only complain that you cannot
> not get 20 years of experience within the first 2 years of practice.
> Well.
>
> But in other languages it does not seem to be any different.
>

Agreed.

[Bart]

Until you make a typo that would be thrown out by a C compiler, but is
legal in C++ and does something you don't expect.

Or if it is not legal in C++ either, it generates a 300-line error
message that you can't make head nor tail of.

[Kenny McCormack]

In article <r456d2$e7f$1...@dont-email.me>,

David Brown <david...@hesbynett.no> wrote:
>On 09/03/2020 09:14, Maciej Sobczak wrote:
>>> C++ programmers must have big brains, the standard of C++17 is 1633
>>> pages long! Imagine how much brain space that takes...
>>>
>>> The whole bible (King James edition) has 1513 pages...
>>
>> This still does not tell whether the C++ standard is too long, or The
>> Bible is too short, or both are too long, or ... The sure difference
>> being that you can be forgiven for using only a subset of C++. ;-)
>>
>
>The key point is to use the subset of C++ that works for you. C++ is a
>big language, with a big library, and a huge range of uses. No one is
>ever expected to know it all, or find all of it useful. But each part
>of it is likely to be useful to /somebody/.

These funny threads. All you supposedly smart people tripping over the
simplest things.

The point here, that everybody seems to be ignoring (and which Jacob has
seen fit not to elucidate - no doubt because it winds you people up) is
that the "Use the small subset that you are comfortable with" mantra falls
apart in the following, all-too-common scenario:

You work in a company on a large project. Everybody agrees to use C++
for the project. Everybody programs their part in their own, known,
comfortable subset of the C++ language. Nobody can
understand/critique/debug any else's code. Even though they are all
using exactly the same language.

Job security!

This situation wouldn't occur if they used a smaller, uniform language,
that everybody understood completely.

--
If it seems like I'm not responding to some moronic criticism that you've
posted in response to one of my posts, be aware that I do not debate with idiots.

It doesn't mean you've won anything...

[David Brown]

That's not a language problem - that is a management problem.

>
> Job security!
>
> This situation wouldn't occur if they used a smaller, uniform language,
> that everybody understood completely.
>

And what, exactly, would that language be?

[Paavo Helde]

On 9.03.2020 13:20, Kenny McCormack wrote:
>
> The point here, that everybody seems to be ignoring (and which Jacob has
> seen fit not to elucidate - no doubt because it winds you people up) is
> that the "Use the small subset that you are comfortable with" mantra falls
> apart in the following, all-too-common scenario:
>
> You work in a company on a large project. Everybody agrees to use C++
> for the project. Everybody programs their part in their own, known,
> comfortable subset of the C++ language. Nobody can
> understand/critique/debug any else's code. Even though they are all
> using exactly the same language.
>
> Job security!
>
> This situation wouldn't occur if they used a smaller, uniform language,
> that everybody understood completely.

A smaller language will miss many features, meaning that everybody has
to invent their own wheels. What makes you think that understanding and
debugging e.g. N half-baked and partially copy-pasted hash container
variants from various colleagues is easier than learning the interface
of std::unordered_map once?

Or is it really easier if every colleague reinvents C++ templates in C
each by their own way, some by macros, some by copy-paste, etc?

Linux kernel is successful because they have lots of discipline and a
lot of common agreements in place, like how to implement virtual tables
and OOP in C in an unified way etc. I'm sure it would take more than
1000 pages to specify all those agreements in detail.

[Juha Nieminen]

jacobnavia <ja...@jacob.remcomp.fr> wrote:
> Le 09/03/2020 à 00:12, Juha Nieminen a écrit :
>> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>> Just too complex, too much time needed to master a small part of it that
>>> could be useful... It is SO BIG that a beginner has no chance in the
>>> first few years, of understanding why something compiles or why it doesn't.
>>
>> Then don't use it. Your infantile whining is useless. Grow up.
>>
>
> Well, of course I will not use it. Even if I wanted to use it, it would
> take me so many years to be productive that it is not really worth the
> effort.

Are you in the habit of going to forums for different kinds of things,
like programming languages, software, operating systems and the like,
which you don't use, and complaining that it's "too complicated"?

If you are not using the thing, then why are you whining?

[jacobnavia]

1: I am reflecting about the direction C++ is heading and expressing a
view that it is keeping a wrong direction: instead of simplifying it
keeps adding features piled upon more features. This is my opinion.
You can qualify it as "whining" in a pejorative way, but I really do not
care about your polemic.

2: I am a C programmer/developper, and since C++ is C compatible to a
certain extent, I am interested in it. Besides, I have landed some
consulting jobs to fix C++ software, so I try to follow (as far as I
can) the new developments in it.

3: Fixing C++ bugs gives you a different perspective on its development.
For instance the new feature of C++17 that allows to distinguish between
a function that throws and one that doesn't (where it is unclear if a
function that throws an int is different that one that throws a long
long, the example doesn't mention that possibility) and that is a NEW
feature. Will that change or affect old code?

Most of these consulting jobs are like this:

Customer:
Hey jacob, this code compiled under gcc 4.2 but now it doesn't. Can you
fix that?

Jacob:
Sure, but that is C++. Penalties apply for the bill.

Customer
Look jacob just FIX IT ok?

Jacob
Sure sure, don't get angry.

After that I go to the forums, look in google, and figure out what
changes to the language are affecting the code. Sometimes I can read the
error message, google around, etc.

It takes an awful lot of work but in most cases I can fix it or develop
a work around.

This "usage" is not really usage in the common sense of the word. I am
not really programming in C++, just trying to make money from its bugs...

:-)

jacob

[Paavo Helde]

These problems mostly appear because the code was sloppy and
non-conforming in the first place, but older gcc versions did not check
it so thoroughly.

There have been very few actual code breaking changes in the C++
standards. Unless your customers are using trigraphs or marking all
their variables 'auto' or 'register', it should work fine, assuming the
code was correct C++98 in the first place. And obsolete usage of
trigraphs, auto and register is trivial to fix.

> Can you
> fix that?
>
> Jacob:
> Sure, but that is C++. Penalties apply for the bill.
>
> Customer
> Look jacob just FIX IT ok?
>
> Jacob
> Sure sure, don't get angry.
>
> After that I go to the forums, look in google, and figure out what
> changes to the language are affecting the code. Sometimes I can read the
> error message, google around, etc.

Suggesting to compile it with clang, it makes some effort to produce
helpful error messages and actually suggests necessary fixes like
injecting missing template/typename keywords (a frequent source of
problems with compiler version upgrades).

>
> It takes an awful lot of work but in most cases I can fix it or develop
> a work around.

Of course it will take a lot of time if you do work which you are not
really qualified for.

>
> This "usage" is not really usage in the common sense of the word. I am
> not really programming in C++, just trying to make money from its bugs...

The customer bugs, you mean.

[Daniel]

Is it? Do you know of another language where && means two completely
different things, depending on whether is template or not? Or T{} means
different things for 0, 1 and 2 arguments, depending on T's constructors? Is
there another language where somebody felt they had to write an entire book
entitled Move Semantics - The Complete Guide? A std::string_view that has
conversion semantics with std::string that are opposite to those of const char*? The list is endless. In the meantime we don't have int128_t because
modifying intmax_t is an ABI break, we don't have big_integer or big_decimal
or big_float, or unicode conversion utilities, or random number generators
that game developers or finance risk engines can use. Now there are many
stakeholders that don't use the standard library - game developers have EASTL,
Facebook has folly, Google has Abseil. Maybe that's a better way forward.

Daniel

[Maciej Sobczak]

> You work in a company on a large project.

OK.

> Everybody agrees to use C++
> for the project.

Not likely, because usually not everybody takes part in the decision process. If that was a big project, the decision was centralized. Most likely, it was taken even before most of the participants got on board.
But let's move on.

> Everybody programs their part in their own,

No. The company has (better) selected an existing or (worse, but passable) invented their own coding standard that was imposed on everybody in the project. Non-complying individuals are systematically discouraged from diverting from the common standard. The company uses tools to automate those checks.

> Nobody can
> understand/critique/debug any else's code.

No, see above. Your argument fell apart.

Unless you work in a very badly managed company. But then, the choice of programming language is not your biggest problem.

> This situation wouldn't occur if they used a smaller, uniform language,
> that everybody understood completely.

Like the one defined by their chosen coding standard?
Sure, and that's why those coding standards get invented.

[Maciej Sobczak]

> Is it? Do you know of another language where && means two completely
> different things, depending on whether is template or not?

Heck, at least this is known statically... Duck-typed languages can make such differences even funnier.

But you might entertain yourself learning about equality operation in LISP:

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node74.html

And you thought C++ is complex? :-)

[Daniel]

On Monday, March 9, 2020 at 7:50:53 AM UTC-4, Paavo Helde wrote:

> A smaller language will miss many features, meaning that everybody has
> to invent their own wheels.

Everybody is already reinventing their own wheels. game developers have EASTL,
Facebook has folly, Google has Abseil. Game developers and finance risk
systems can't use standard library random number generators for repeatability
and verifiability reasons. Rapidjson and some other json libraries have their
own floating point parsing, more have their own floating point printing. All
json libraries have their own unicode conversion and validation code. The list
goes on.

Daniel

[Daniel]

On Monday, March 9, 2020 at 10:29:53 AM UTC-4, Maciej Sobczak wrote:
>
> But you might entertain yourself learning about equality operation in LISP:
>
> https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node74.html
>
> And you thought C++ is complex? :-)
>

Point taken :-) That link failed for me, but I found this one

http://clhs.lisp.se/Body/f_equal.htm

Daniel

[Paavo Helde]

On 9.03.2020 16:41, Daniel wrote:
> On Monday, March 9, 2020 at 7:50:53 AM UTC-4, Paavo Helde wrote:
>
>> A smaller language will miss many features, meaning that everybody has
>> to invent their own wheels.
>
> Everybody is already reinventing their own wheels.

And sometimes unnecessarily.

> game developers have EASTL,
> Facebook has folly, Google has Abseil. Game developers and finance risk
> systems can't use standard library random number generators for repeatability
> and verifiability reasons. Rapidjson and some other json libraries have their
> own floating point parsing, more have their own floating point printing. All
> json libraries have their own unicode conversion and validation code. The list
> goes on.

Special needs will require special solutions anyway, that's very fine.
The point is that those 99% of language users who don't need EASTL can
use the standard STL.

Moreover, even those with special needs can use the basic template and
OOP mechanisms, instead of reinventing their own as it happens in C. And
they can use other standard means in the program parts which do not
require special means.

[jacobnavia]

Le 09/03/2020 à 15:20, Maciej Sobczak a écrit :
>> Everybody programs their part in their own,
> No. The company has (better) selected an existing or (worse, but passable) invented their own coding standard that was imposed on everybody in the project

I would like to point out the logic behind this reasoning:

1: Everyone agrees that it is impossible for a normal individual to
understand all C++

2: Then, you have to define a new subset of it, accessible to mere
humans and not compilers

3: You "standardize" into that subset.

This is completely incredible as a situation and shows how C++ people
reason!

[Kenny McCormack]

In article <r45snb$po3$1...@dont-email.me>,
jacobnavia <ja...@jacob.remcomp.fr> wrote:
...

>I would like to point out the logic behind this reasoning:
>
>1: Everyone agrees that it is impossible for a normal individual to
>understand all C++
>
>2: Then, you have to define a new subset of it, accessible to mere
>humans and not compilers
>
>3: You "standardize" into that subset.
>
>This is completely incredible as a situation and shows how C++ people
>reason!

Quite so.

And let me note that the responses (other than Jacob's) to my little poke
in this thread have all been of the "circling the wagons" variety. That is
to say, they are all utter nonsense.

--
I've learned that people will forget what you said, people will forget
what you did, but people will never forget how you made them feel.

- Maya Angelou -

[jacobnavia]

Well, of course common lisp is baroque, but that is an unfair comparison.

The page leads to the definition of "equal" in lisp

"equal" is a recursive depth first comparison, that doesn't even exist
in C++ since it compares whole trees of objects for equality. C++ has
only shallow equality, it doesn't follow pointers as in lisp.

There is in lisp the distinction between "eq" (address comparison) and
eql (value comparison) and equal (trees comparison). In C++ you have
"==" that compares values (scalar values) what would be similar to "eql"
but not to "equal" that doesn't exist in C++.

At least the lisp complexity is warranted by more performance (trees
comparison). But I will stop here, maybe if I go on the C++ committee
will hear that and will add it to C++27!

:-)

[Maciej Sobczak]

> I would like to point out the logic behind this reasoning:
>
> 1: Everyone agrees that it is impossible for a normal individual to
> understand all C++

I have not seen any agreement on this (it's just your perspective). I would rather say that it is not *necessary* for a normal individual to understand all of C++. And nobody expects that.

> 2: Then, you have to define a new subset of it, accessible to mere
> humans and not compilers

Wrong. There are also tools for doing useful stuff. Say I have a tool that can draw diagrams based on code (and I value those diagrams a lot), but it is not up to date with all new language features and would break when faced with too fancy code. This is also a reason to standardize locally on a smaller subset.
Another tool might perform static analysis of some important properties of my programs and I also might want to step back with too liberal language use to reap the benefits of these analyses.
And so on. It's not only humans vs. compilers.

> 3: You "standardize" into that subset.

Yes. And interestingly, I might want to pick different subsets for each of my projects.

> This is completely incredible

I guess you have never thought, even for a while, how engineering goes in any other technical domain, right? Multiple levels of standardization and conventions are used everywhere. Your daily life depends on people who choose to only use agreed subsets of what their available tech allows them - and you would be seriously messed up otherwise. C++ is not any different.

And, by the way, there are coding standards for other programming languages, too. For the same reasons.

[Daniel]

On Monday, March 9, 2020 at 6:45:37 PM UTC-4, Maciej Sobczak wrote:
> > I would like to point out the logic behind this reasoning:
> >
> > 1: Everyone agrees that it is impossible for a normal individual to
> > understand all C++
>
> I have not seen any agreement on this (it's just your perspective). I would > rather say that it is not *necessary* for a normal individual to understand > all of C++. And nobody expects that.

It's not so much that C++ has so many things, but rather, that it lacks all coherence, any vision, that it's one ad hoc thing after another. For what reason do we have

std::string s = "foo";

const char* p = s.c_str(); // explicit, good
but
std::string_view sv = s; // implicit, bad for all the reasons we have c_str()

and

s = p; // Seems safe enough
but
s = std::string(sv); // Why?

And collision between uniform initialization and initializer list. Why? The
committee had to have known that, when they voted for it.

And why introduce <system_error> requiring using _global objects_ for
identifying error categories? Uniqueness of address doesn't work with DLL's,
probably not shared libraries either, and the committee would have known that.

The list is endless.

Daniel

[Alf P. Steinbach]

On 10.03.2020 02:24, Daniel wrote:
> On Monday, March 9, 2020 at 6:45:37 PM UTC-4, Maciej Sobczak wrote:
>>> I would like to point out the logic behind this reasoning:
>>>
>>> 1: Everyone agrees that it is impossible for a normal individual to
>>> understand all C++
>>
>> I have not seen any agreement on this (it's just your perspective). I would > rather say that it is not *necessary* for a normal individual to understand > all of C++. And nobody expects that.
>
> It's not so much that C++ has so many things, but rather, that it lacks all coherence, any vision, that it's one ad hoc thing after another. For what reason do we have
>
> std::string s = "foo";
>
> const char* p = s.c_str(); // explicit, good
> but
> std::string_view sv = s; // implicit, bad for all the reasons we have c_str()

For convenience when `std::string_view` is a formal argument type.

This lets you define /one/ function, no overloads, that handles just
about any non-zero-terminated string.

> and
>
> s = p; // Seems safe enough
> but
> s = std::string(sv); // Why?

Yah. That one's ugly as heck.

> And collision between uniform initialization and initializer list. Why?

Agree about that also. It's botched. Bjarne's vision was nice, and I
believe it was the committee that messed it totally up.

> The committee had to have known that, when they voted for it.

Politics I gather, combined with weak leadership.

I think it's the same that happens in a lot of municipalities in Norway.
The political leadership avoids taking on difficult issues. The
bureaucrats then think that they just /have/ to make the decisions on
behalf of the politicians, and they get away with it. However, a
bureaucrat generally sees only his or her little very narrow and short
slice of reality, and additionally, is often constrained by rules
interpreted by the letter. Written rules don't have intelligence. The
result is ungood.

> And why introduce <system_error> requiring using _global objects_ for
> identifying error categories? Uniqueness of address doesn't work with DLL's,
> probably not shared libraries either, and the committee would have known that.
>
> The list is endless.

The lack of support for dynamic libraries is an open large wound in the
language, so to speak. IMO.

But which model to go for: Windows DLLs (very encapsulated), Linux
shared libraries (like static libraries essentially, just dynamic), or
maybe some third model defined by the committee, since there is strong
precedence for not standardizing existing practice, but rather invent?

Happily with C++20 there will be a `std::pi` (of course not the existing
practice M_PI, from the Posix standard, but a pi value, hurray).

And type safe text formatting based on format strings. They managed to
dirty it by adding locale support. But I was wrong in thinking it was
correct, as people had asserted, that they'd really sabotaged that
library: by default locales aren't used, the use has to be requested,
because the formatting is defined in terms of C++17 `std::to_chars`.

So all's not lost. But the half-baked C++20 co-routines, which aren't
really co-routines anyway but more like continuations, that's bad. And
the fragile and inefficient ranges library, with its
yet-another-domain-specific-sub-language-to-learn and `i(di)ota` func. Argh.

- Alf

[Daniel]

On Monday, March 9, 2020 at 9:43:50 PM UTC-4, Alf P. Steinbach wrote:
> On 10.03.2020 02:24, Daniel wrote:
>
> > And why introduce <system_error> requiring using _global objects_ for
> > identifying error categories? Uniqueness of address doesn't work with

>> DLL's probably not shared libraries either, and the committee would have
>> known that.
>

> The lack of support for dynamic libraries is an open large wound in the
> language, so to speak.
>

But that aside, why require equality of _addresses_? Equality of type_info
doesn't require equality of addresses, only that they be the "same", my
understanding is that MSVC satisfies that sameness requirement with string
equality. So why require equality of addresses with error categories? I mean,
the issue with uniqueness of address is understood, it's known.

Daniel

[Daniel]

On Monday, March 9, 2020 at 6:39:40 AM UTC-4, David Brown wrote:
>

> C++ does suffer from a some serious issues, however. Backwards
> compatibility can make things more awkward or bulky than it should be
> (someone mentioned EBCDIC, for example).

Coexisting with EBCDIC is only an issue because C++ lacks proper abstractions for byte sequences and text, and conversion utilities between them. In Java I can read any number of flavors of EBCDIC as bytes, convert those bytes into a unicode string, work with that string, and convert the result back to EBCDIC bytes. There's been prior art for that for a long long time, but C++ still doesn't have it.

Daniel

[Ian Collins]

On 10/03/2020 00:00, Bart wrote:
> On 09/03/2020 08:18, Ian Collins wrote:
>> On 09/03/2020 19:52, jacobnavia wrote:
>>> Le 09/03/2020 à 00:12, Juha Nieminen a écrit :
>>>> jacobnavia <ja...@jacob.remcomp.fr> wrote:
>>>>> Just too complex, too much time needed to master a small part of it
>>>>> that
>>>>> could be useful... It is SO BIG that a beginner has no chance in the
>>>>> first few years, of understanding why something compiles or why it
>>>>> doesn't.
>>>>
>>>> Then don't use it. Your infantile whining is useless. Grow up.
>>>>
>>>
>>> Well, of course I will not use it. Even if I wanted to use it, it would
>>> take me so many years to be productive that it is not really worth the
>>> effort.
>>
>> You could be more productive tomorrow with just a the C subset and a
>> tiny bit more.   But you already know (and will probably carry on
>> ignoring) that.
>
> Until you make a typo that would be thrown out by a C compiler, but is
> legal in C++ and does something you don't expect.

Which you are very unlikely to do.

> Or if it is not legal in C++ either, it generates a 300-line error
> message that you can't make head nor tail of.

Which won't happen with C and a tiny bit more.

You know that already, but like Jacob, you choose to ignore it.

--
Ian.

[David Brown]

Just yesterday, I had a single typo that lead to hundreds of error
messages in a different file - there was no indication of where the real
error lay. That was a missing semicolon in a header - and it was all C,
no C++ in sight. The idea that confusing or unhelpful error messages is
purely a C++ phenomenon is just nonsense.

C++ is a bigger language, and you can do a lot more in a few lines, so
the scope for long error messages is greater. That just means you have
to be a bit smarter, and use better tools, when working with it. A good
IDE will help you navigate, and help you figure out which of the error
messages are most relevant. And compilers have been getting better at
this - gcc's error messages have become steadily more relevant, steadily
better at pointing out what is /actually/ wrong, and steadily better at
giving suggestions for corrections.

Also, one of the motivations for newer C++ features like concepts and
modules is to make it easier to find problems and simplify error
messages. Concepts mean you'll get the messages when you define
templates, rather than when you use them.

[David Brown]

And the reason for that lack of abstraction is backwards compatibility,
from C. That is not an excuse, of course - C++ should be working more
towards a separation here (IMHO). There has been progress (std::byte,
and char8_t are steps in the right direction). The trouble is, in order
to do this properly, you'd need to break a good deal of code.

In my ideal language, you'd have types:

"char8_t" is a code unit for utf-8 data. It can hold any one ASCII
character, and part of other utf-8 characters. Strings are stored in
arrays of char8_t.

"char32_t" is a code unit for utf-32 data.

There is no "char", and certainly not the meaningless "signed char",
"unsigned char" types, or the underspecified "wide char" junk. There is
no utf-16 or UCS16 - these encodings sounded good on creation, but were
dead-ends. (Of course you'd have libraries for importing and exporting
utf-16 and other encodings, but they would not be fundamental types in
the language.)

There would be types "raw8_t", "raw16_t", etc. These are for untyped
data sequences and low-level access. They would be allowed to alias any
other types (like "unsigned char" today), and used for moving data
around. There would be no arithmetic operations on them or comparisons
other than == and !=. (It was a mistake to allow operations on std::byte.)

You'd have signed and unsigned integer types of different sizes, but
these would be entirely independent of the character types and raw types.


How you could get there from today's C++ (assuming other people agreed
with the aim!), I have no idea - it would involve massive changes and
incompatibilities in existing code.

[Bart]

On 10/03/2020 10:11, David Brown wrote:
> On 10/03/2020 09:10, Ian Collins wrote:
>> On 10/03/2020 00:00, Bart wrote:

>>> Or if it is not legal in C++ either, it generates a 300-line error
>>> message that you can't make head nor tail of.
>>
>> Which won't happen with C and a tiny bit more.
>>
>> You know that already, but like Jacob, you choose to ignore it.
>>
>
> Just yesterday, I had a single typo that lead to hundreds of error
> messages in a different file - there was no indication of where the real
> error lay. That was a missing semicolon in a header - and it was all C,
> no C++ in sight. The idea that confusing or unhelpful error messages is
> purely a C++ phenomenon is just nonsense.

But this is hundreds of different error messages, rather than hundreds
of lines of the same message.

The start point will be the first error message; no point in looking at
the rest until the first has been dealt with.

[Alf P. Steinbach]

It /looks/ like `system_error` was lifted from the Boost library, where
the address comparison was just a default for error categories that
lacked id's, and that then for the standard library id's were removed.

<url:
https://www.boost.org/doc/libs/1_69_0/libs/system/doc/html/system.html#ref_nonvirtuals>

Given the very Posix'y nature of `std::runtime_error` I'd guess the
(assumed) id removal is just underhanded or even inadvertent Windows
sabotage. For the "inadvertent" I guess the reasoning went like this:

1. BTW let's fix this, those random 64-bit compile time id's are
kludges. Can we use more robust & safe 128-bit UUIDs? Maybe?
2. Hey, id's are not necessary, we can just use addresses. I tested this
now [not mentioned: in Linux] and simply removed id's and it worked fine!
3. What a jolly good idea, a SIMPLIFICATION! Let's do that, yes.

Same as changing the return type of `std::filesystem::path::u8string` in
C++20 to incompatible: it's only a problem in Windows, not in *nix.


- Alf

[David Brown]

On 10/03/2020 12:02, Bart wrote:
> On 10/03/2020 10:11, David Brown wrote:
>> On 10/03/2020 09:10, Ian Collins wrote:
>>> On 10/03/2020 00:00, Bart wrote:
>
>>>> Or if it is not legal in C++ either, it generates a 300-line error
>>>> message that you can't make head nor tail of.
>>>
>>> Which won't happen with C and a tiny bit more.
>>>
>>> You know that already, but like Jacob, you choose to ignore it.
>>>
>>
>> Just yesterday, I had a single typo that lead to hundreds of error
>> messages in a different file - there was no indication of where the real
>> error lay.  That was a missing semicolon in a header - and it was all C,
>> no C++ in sight.  The idea that confusing or unhelpful error messages is
>> purely a C++ phenomenon is just nonsense.
>
> But this is hundreds of different error messages, rather than hundreds
> of lines of the same message.

Yes, the list I got had a large number of different error messages - and
none of them were from the file with the actual typo.

>
> The start point will be the first error message; no point in looking at
> the rest until the first has been dealt with.

Usually you can get a good idea by looking at the first and the last
error message - that applies equally to C and C++.

[Daniel]

On Tuesday, March 10, 2020 at 7:30:28 AM UTC-4, Alf P. Steinbach wrote:
>
> It /looks/ like `system_error` was lifted from the Boost library, where
> the address comparison was just a default for error categories that
> lacked id's, and that then for the standard library id's were removed.
>
> <url:
> https://www.boost.org/doc/libs/1_69_0/libs/system/doc/html/system.html#ref_nonvirtuals>
>

That was introduced into boost in 1_69_0, though

boost 1_69_0: rhs.id_ == 0? this == &rhs: id_ == rhs.id_

boost 1_68_0: &lhs == &rhs;

And from the release notes to 1_69_0:

"error_category now has a constructor that accepts a 64 bit identifier,
enabling distinct category objects to compare equal."

The 64 bit identifier to be generated randomly by the implementor.

Daniel

[Juha Nieminen]

jacobnavia <ja...@jacob.remcomp.fr> wrote:
> 1: I am reflecting about the direction C++ is heading and expressing a
> view that it is keeping a wrong direction: instead of simplifying it
> keeps adding features piled upon more features. This is my opinion.
> You can qualify it as "whining" in a pejorative way, but I really do not
> care about your polemic.

After about 20 years of hearing the exact same thing repeated over and
over, it starts getting old really fast.

You are not saying anything that hasn't already been said over the
past 20 years. It's not any more relevant today than it was 20 years
ago.

Programming languages that are being actively used evolve all the
time. Java, C#, javascript, Haskell, Python, PHP... all of them.
Heck, even Objective-C has quite a lot more features today than
it had 10 years ago. Yet you don't see people complaining about it.

[Puppet_Sock]

Re: Complexity of C++ 17.

What fraction of the complexity is the "base" language,
and what fraction is the standard libraries? And how big
a jump in complexity is adding in a specific library?

I realize you can't do much without the standard libraries.
But pause a moment.

Are individual libraries of a degree of complexity that
they are manageable? That's conceivably the breaking point.
If it gets to the point I can't deal with bringing in,
for example, standard file IO, then I would need to start
looking for alternatives to C++.

[Paavo Helde]

Curiously, I'm reading this message while looking at the public API of
the openssl library, which consists of 1,588 free functions. Oh well...

[Juha Nieminen]

Paavo Helde <myfir...@osa.pri.ee> wrote:
> Curiously, I'm reading this message while looking at the public API of
> the openssl library, which consists of 1,588 free functions. Oh well...

That's a bit of a common problem with C libraries. (Granted, also some
badly-designed C++ libraries, but mostly C libraries, pretty much by
necessity because there isn't really any other option provided by
the language.)

[Bo Persson]

But that is what makes it "simple" - just functions, a concept that
anyone can understand.

If you add more options, the language becomes "complex". :-)



Bo Persson

[Melzzzzz]

Problem is that C++ library can use only C++. If you want to expose
other languages you either need C or some other language (like D),
that can bind to specific compiler.
>
>
>
> Bo Persson


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[jacobnavia]

Le 11/03/2020 à 18:23, Paavo Helde a écrit :
> Curiously, I'm reading this message while looking at the public API of
> the openssl library, which consists of 1,588 free functions. Oh well...

Yes, C++ does MUCH MUCH better:
The "POCO" library in C++ is a C++ wrapper of the SSL and features:

12 Namespaces
410 Classes
27 Types
56 functions

I did not look at all classes but all that I sampled had much more than
10 methods/member functions.

Where are the C++ gains here?

Oh well... as you say

For people foreign to C++ you have to figure out which name space holds
the method you want to call, which class, etc. None of that is present
in C. Just call the function and be done with it.

[Daniel]

On Thursday, March 12, 2020 at 3:22:39 AM UTC-4, jacobnavia wrote:

> For people foreign to C++ you have to figure out which name space holds
> the method you want to call, which class, etc. None of that is present
> in C. Just call the function and be done with it.

But who has time to call all those functions? :-)

What we're looking for in modern languages is the ability to work with
abstractions.

For example, suppose I receive some CBOR data over the wire in the format

0xd8,0x55 -- Tag 85 (float32 little endian Typed Array)
0x5a - byte string (four-byte uint32_t for n, and then n bytes follow)
03 93 87 00 -- 60000000
00 00 00 00 -- 0.0f
00 00 80 3f -- 1.0f
00 00 00 40 -- 2.0f
...

which contains a typed array of 60 million floats in little endian format.

I want to be able to write simply

std::vector<float> y = cbor::decode_cbor<std::vector<float>>(data);

without having to write any additional code and irrespective of the details
of the data, for example, its endianness, whether the values are float32
or float16 (half precision float), or whether what's inside the data is a
typed array or a classical CBOR array.

Modern languages differ in the support they provide for writers of generic
functions such as decode_cbor. In languages like Java and C# we have
reflection, in languages like C++ and rust, we work with traits. But the goal
is abstraction and expressiveness.

Daniel

[jacobnavia]

Le 12/03/2020 à 22:28, Daniel a écrit :
> or example, suppose I receive some CBOR data over the wire in the format
>
> 0xd8,0x55 -- Tag 85 (float32 little endian Typed Array)
> 0x5a - byte string (four-byte uint32_t for n, and then n bytes follow)
> 03 93 87 00 -- 60000000
> 00 00 00 00 -- 0.0f
> 00 00 80 3f -- 1.0f
> 00 00 00 40 -- 2.0f
> ...
>
> which contains a typed array of 60 million floats in little endian format.
>
> I want to be able to write simply
>
> std::vector<float> y = cbor::decode_cbor<std::vector<float>>(data);
>
> without having to write any additional code and irrespective of the details
> of the data, for example, its endianness, whether the values are float32
> or float16 (half precision float), or whether what's inside the data is a
> typed array or a classical CBOR array.

Sure, C++ is great for that. Just put some hyper general template based
software mountain that will do all details for you.

But...

Is that really necessary? In practical applications isn't it always the
case that you know what you expect, and how much will it change?

There are several implementations of CBOR in C, and they probably need a
few additional calls than your one liner. They do not need a C++ runtime
library and they will fit into a microcontroller.

This is a question of an application environment: if you run in a
workstation with plenty of CPU and memory yes, your approach is useful.
If you run in a more constrained environment your approach is just too
big to fit!

The C approach is based on a different conception of software than the
C++ approach. Avoiding bloat is not one of C++ strengths really. But it
can be justified in some cases, I will not deny that.

This whole discussion would be better served if I expressed my views
with a concrete example, starting a new thread. I will start with
structured bindings and the modification of the if statement introduced
in C++20