"Trip report: Winter ISO C++ standards meeting (Kona), C++17 is complete" by Herb Sutter

[Lynn McGuire]

"Trip report: Winter ISO C++ standards meeting (Kona), C++17 is complete" by Herb Sutter
https://herbsutter.com/2017/03/24/trip-report-winter-iso-c-standards-meeting-kona-c17-is-complete/

"The big news is that we completed C++17, which dominated the work of the meeting: C++17 is now technically finished and being sent
out for its final ISO balloting. All that remains for C++17 now is some ISO red tape and minor touch-up to get it officially
published, which is expected to be just mechanical."

Lynn

[Alf P. Steinbach]

The `std::byte` thing is really sad.

Both that it was adopted, and Herb holding it up as a kind of positive
achievement.

Looking at the feature set over at <url:
https://en.wikipedia.org/wiki/C%2B%2B17>:

• Now optional message for `static_assert`, too late. Everybody has some
macro, and it will still need to be used to support feature-lagging
compilers. Otherwise one can just use "!" as message.

• UTF-8 character literal is a way to restrict a character literal on
octet-based machines (just about all modern computers) to ASCII. It's
IMHO the most useless and silly concept in all of C++ history. It could
possibly have been useful if it was named mnemonically for ASCII, had
some corresponding constraint feature for strings, and worked as a
constraint also on 16-bit byte and 32-bit byte architectures.
<url: https://isocpp.org/files/papers/n4267.html>

• Template fold expressions, sounds nice so one can avoid those silly
declare-an-array workarounds for pack transforms. But I guess the proof
is in the eating of the pudding. What does it really taste like, and
does it cause gas, or not?

• Initializers in conditions. That's ungood in itself, as I see it,
because it adds complicating syntax for something that can be simply
expressed without it. But, this feature can be abused to provide a
locally scoped variable declaration for a block guaranteed without any
overhead. That practically requires a macro like Expressive C++ `$with`,
or else writing painfully convoluted cryptic code, but still. This
feature is apparently an /enabling wart/! :)

• Template deduction of constructors, oh finally! Now /that/'s a nice
feature. No more silly factory functions, yay!


In the library, `std::string_view` is better than nothing, but has the
design problem of returning references instead of values, thus
preventing a later more sane string handling. Let's constrain things
just because we can. Ouch.

File system, hope that works out. It implies wide string constructors
for the fstreams, in Windows. Silly platform-specificity in a standard,
grumble. Yes I did something positive about it once: I filed a bug
report with Boost Filesystem, because BFS didn't work for the case of
international text filenames with MinGW g++, because that compiler's
standard library didn't have those wide string constructors. And I
created a workaround based on existing g++ extended standard library
functionality, so that's possible and shows that the Windows-specific
requirement of the C++17 standard isn't necessary at all: instead one
could have more general functionality, supporting more portable code.

The main problem I see is that at least the proposal used the phrasing
“/encouraged/ to provide” about the wide string constructors, and if
that's also the wording in the standard then one is not guaranteed that
international file names will work in Windows with g++. :(


- Alf (a bit disappointed)

[Lynn McGuire]

And there is no standard C++ user interface toolkit.

Lynn

[Ian Collins]

On 03/26/17 11:34 AM, Lynn McGuire wrote:
>
> And there is no standard C++ user interface toolkit.
>
> Lynn

Hooray!

--
Ian

[Mr Flibble]

And hopefully there never will be!

My C++ user interface toolkit:

http://neogfx.org

/Flibble

[Alf P. Steinbach]

On 25-Mar-17 1:34 AM, Lynn McGuire wrote:

A summary of core language features with examples, plus some of the
library stuff:

<url: https://github.com/tvaneerd/cpp17_in_TTs/blob/master/ALL_IN_ONE.md>

Not sure how I overlooked coroutines in all that.

I'll have to try them, and hey, Visual C++ already supports them.

(It was such fun with coroutines in Modula-2.)


Cheers!,

- Alf

[Bo Persson]

On 2017-03-26 22:37, Stefan Ram wrote:
> r...@zedat.fu-berlin.de (Stefan Ram) writes:
>> I might now say that
>> ( int )u'A' == 65
>> is true.
>
> OTOH, now I don't know whether
>
> ::std::cout << u'A';
>
> will appear as an »A« on the console everywhere.
>

Probably not. On EBCDIC-based machines 'A' is still 193.

[Bo Persson]

On 2017-03-26 22:30, Stefan Ram wrote:

> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:

>> - Alf (a bit disappointed)
>

> Many people are disappointed because there are no modules and
> no concepts and no ... (you name it). But we might be able to
> use TS /and/ implementations for them before C++20 (which is
> called »C++19/20« by some now).
>
> Of course with regard to a graphical output or a GUI, there does
> not even seem to be a TS in sight.
>

Well, there might be:

"A Proposal to Add 2D Graphics Rendering and Display to C++"

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0267r4.pdf

[Alf P. Steinbach]

On 26-Mar-17 10:30 PM, Stefan Ram wrote:
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:

>> The -std::byte- thing is really sad.
>
> Is it sad because of the naming (»::std::byte« instead of
> »byte_t« or a new »byte« keyword) or do you oppose a type
> with any name for the semantics of »a byte, but neither a
> number nor a character«?
>
> Some do not like the naming because it adds yet another
> style for fundamental types (after keywords and the names
> ending in »_t«).

A standard name for the byte type would just have been a non-issue,
because it's defined by every other library and can be freely redefined
with that same common definition (namely `unsigned char`). Naming is
good because it helps communication from code writer to code reader. I
wouldn't have reacted negatively to a standard name.

But what we have here is an incompatible definition, as enum type.

Bummer.

Since it's not simply `unsigned char` it must differ in some way, but in
what way? I'm not going to try to find out what restrictions it has on
operations. If there are no operational restrictions compared to the
real byte then the type is useless as a distinct type, and if there are
restrictions, then the type is less useful than the real byte.

Bummer.

Then, it's designed as a library type, presumably to avoid having to
change the core language parts of the standard, but if the core language
parts of the standard don't provide special support for it then it
doesn't enjoy the special status that the real byte type `unsigned char`
has, such as any object being convertible to bytes.

Again, bummer.

I can't think of anything positive about this, as opposed to a name for
the real byte type, which would be useful for clarity, and which, as
mentioned, every other 3rd party library provides for that reason. This
C++17 std::byte type isn't even useful for clarity, but the opposite.
The name implies an unrestricted `unsigned char`, but the type can't be,
so the name misdirects instead of clarifying.

This is like the human appendix. A useless part of the anatomy that can
sometimes cause real trouble, and for that reason is sometimes removed
(also before the trouble manifests). But C++17 std::byte is not a
holdover from earlier evolution: it's like one had a human body, with
all its problems but without an appendix, and /added/ an appendix.

It should never have even entered the standardization process, it is
certainly not existing practice in any way, and Herb holding it up as an
achievement, that's really sad – it must be a political achievement.


Cheers!,

- Alf

[Chris Vine]

On Mon, 27 Mar 2017 07:24:01 +0200
"Alf P. Steinbach"
[snip]

> Then, it's designed as a library type, presumably to avoid having to
> change the core language parts of the standard, but if the core
> language parts of the standard don't provide special support for it
> then it doesn't enjoy the special status that the real byte type
> `unsigned char` has, such as any object being convertible to bytes.

On a quick look through the draft standard, any object in memory is
convertible to an array of unsigned char or of std::byte
interchangeably, and can be accessed through either the unsigned char
type or the std::byte type.

I do not know why std::byte is implemented as an enum class with
unsigned char as its underlying type rather than as a typedef to
unsigned char. Presumably that is explained in p0298r3.pdf (the paper
referenced in the article in question), which I have not read and
probably will not do so. It might have been chosen wrongly (last
minute changes can be), but I doubt it was chosen whimsically.
Probably views about type safety came into it.

[Bo Persson]

Making it a distinct type affects overloading and implicit conversions.

std::byte should not be mistaken for std::uint8_t or inadvertently be
displayed as a character using ostream operator<<.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0298r3.pdf



Bo Persson

[David Brown]

There are, however, overloaded operators for bit operations and shifts,
which seems strange to me. I would have preferred to see std::byte to
be more opaque, but with overloaded versions of std::memcpy and other
functions aimed specifically and moving and copying raw memory.

[Lynn McGuire]

On 3/26/2017 3:30 PM, Stefan Ram wrote:
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> writes:

...

> Many people are disappointed because there are no modules and
> no concepts and no ... (you name it). But we might be able to
> use TS /and/ implementations for them before C++20 (which is
> called »C++19/20« by some now).
>
> Of course with regard to a graphical output or a GUI, there does
> not even seem to be a TS in sight.

What is a TS ?

Thanks,
Lynn

[Scott Lurndal]

First hit on google "C++ TS" gives the answer.