2019 wish list

[woodb...@gmail.com]

Shalom Here's my 2019 wish list:

1. Clang and Gcc keep supporting #import.

2. Microsoft makes it so you don't have to
call WSAStartup(). By the grace of G-d, I've
made this:
https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc

into a nice little program. One of few warts
remaining in it is the call to "winStart" that
wraps the call to WSAStartup(). On FreeBSD and
Linux, winStart() is a no-op. 2019 would be a
good time to clean that up!

3. A compiler (Gcc?) with support for static exceptions.
I'll be able to start taking advantage of static
exceptions in the closed-source part of my work.

4. Std::string_view is back-ported to 2011 C++
and std::span is back-ported to 2017 C++.

These things would go a long way to making 2019
even better than 2018.


Brian
Ebenezer Enterprises - Enjoying programming again.
https://github.com/Ebenezer-group/onwards

[Mr Flibble]

On 26/12/2018 20:56, woodb...@gmail.com wrote:
> Shalom Here's my 2019 wish list:
>
> 1. Clang and Gcc keep supporting #import.
>
> 2. Microsoft makes it so you don't have to
> call WSAStartup(). By the grace of G-d, I've
> made this:
> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc
>
> into a nice little program. One of few warts
> remaining in it is the call to "winStart" that
> wraps the call to WSAStartup(). On FreeBSD and
> Linux, winStart() is a no-op. 2019 would be a
> good time to clean that up!

Just use boost.asio.

[snip]

/Flibble

--
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[woodb...@gmail.com]

On Wednesday, December 26, 2018 at 3:55:56 PM UTC-6, Mr Flibble wrote:
> On 26/12/2018 20:56, woodb...@gmail.com wrote:
> > Shalom Here's my 2019 wish list:
> >
> > 1. Clang and Gcc keep supporting #import.
> >
> > 2. Microsoft makes it so you don't have to
> > call WSAStartup(). By the grace of G-d, I've
> > made this:
> > https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc
> >
> > into a nice little program. One of few warts
> > remaining in it is the call to "winStart" that
> > wraps the call to WSAStartup(). On FreeBSD and
> > Linux, winStart() is a no-op. 2019 would be a
> > good time to clean that up!
>
> Just use boost.asio.
>

That library has the same wart. Also, my program is
intended to be very portable. It's 35 lines and doesn't
have any external dependencies.

> [snip]
>
> /Flibble
>


Brian

[Brian Wood]

On Wednesday, December 26, 2018 at 2:56:10 PM UTC-6, Brian Wood wrote:
> Shalom Here's my 2019 wish list:
>
> 1. Clang and Gcc keep supporting #import.
>

I'm not sure about Clang, but Gcc is still supporting #import.

> 2. Microsoft makes it so you don't have to
> call WSAStartup(). By the grace of G-d, I've
> made this:
> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc

The link for that program has changed:
https://github.com/Ebenezer-group/onwards/blob/master/src/tiers/genz.cc

>
> into a nice little program. One of few warts
> remaining in it is the call to "winStart" that
> wraps the call to WSAStartup(). On FreeBSD and
> Linux, winStart() is a no-op. 2019 would be a
> good time to clean that up!

I don't think there's any progress on this one. It would
be great to hear otherwise.

>
> 3. A compiler (Gcc?) with support for static exceptions.
> I'll be able to start taking advantage of static
> exceptions in the closed-source part of my work.

I'm not sure if there's any progress with this. If so I'd
be happy to hear it.

>
> 4. Std::string_view is back-ported to 2011 C++
> and std::span is back-ported to 2017 C++.
>

I've given up on getting string_view back-ported to 2011 C++.
And I'm thinking about biting the bullet (again) and requiring
2020 C++ of my users:

What I may do is limit my use of 2020 C++ to std::span and
then if someone wants to use my software at the 2017
level, they could do so by providing their own std::span
implementation.

I didn't mention it above, but there's also the Linux/sctp
stuff that I've mentioned in other threads. From one of
my programs:

#ifdef __linux__
#include<linux/sctp.h>
#else
#include<netinet/sctp.h>
#endif

That's another one that seems to be going nowhere fast.

So my wish list for 2021 is about the same as it was for
2019.

Brian
Ebenezer Enterprises - Enjoying programming again.

https://webEbenezer.net

[David Brown]

On 29/12/2020 07:34, Brian Wood wrote:
> On Wednesday, December 26, 2018 at 2:56:10 PM UTC-6, Brian Wood wrote:
>> Shalom Here's my 2019 wish list:
>>
>> 1. Clang and Gcc keep supporting #import.
>>
> I'm not sure about Clang, but Gcc is still supporting #import.

It has been marked "obsolete" and "not a well designed feature" in the
gcc manuals for decades - since at least the oldest conveniently
available gcc manual on the gcc website (gcc 2.95.3). It should never
be used in C or C++ code, even if that code is not intended to be portable.

>
>> 2. Microsoft makes it so you don't have to
>> call WSAStartup(). By the grace of G-d, I've
>> made this:
>> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc
>
> The link for that program has changed:
> https://github.com/Ebenezer-group/onwards/blob/master/src/tiers/genz.cc
>
>>
>> into a nice little program. One of few warts
>> remaining in it is the call to "winStart" that
>> wraps the call to WSAStartup(). On FreeBSD and
>> Linux, winStart() is a no-op. 2019 would be a
>> good time to clean that up!
>
> I don't think there's any progress on this one. It would
> be great to hear otherwise.

It is not relevant to C++, only one odd (albeit popular) implementation.

>
>>
>> 3. A compiler (Gcc?) with support for static exceptions.
>> I'll be able to start taking advantage of static
>> exceptions in the closed-source part of my work.
>
> I'm not sure if there's any progress with this. If so I'd
> be happy to hear it.
>

The proposed new static exception system is, AFAIK, still at the
proposal stage and there are no generally available test
implementations. It will be a while before these are usable for testing
in code, and a good deal longer before there is sufficient standard
library support that they can replace normal (old) exceptions. But you
are not alone in wanting this - it's a feature that I think will be very
eagerly awaited.

>>
>> 4. Std::string_view is back-ported to 2011 C++
>> and std::span is back-ported to 2017 C++.
>>
> I've given up on getting string_view back-ported to 2011 C++.

You can be very confident that these will not be back-ported - at least
not as part of the standard library. But you can always implement your
own similar classes.

> And I'm thinking about biting the bullet (again) and requiring
> 2020 C++ of my users:

How many people will that affect? The advantage of having no users is
that you can impose any requirements you find convenient. This
disadvantage is that it makes it less likely that you will get any users
- no one will use a month-old standard for serious code.

>
> I didn't mention it above, but there's also the Linux/sctp
> stuff that I've mentioned in other threads.

SCTP has nothing to do with C++. (It seems to be a nice protocol, but
as long as Windows doesn't support it natively and off-the-shelf routers
have no support for SCTP connection tracking for NAT, it's mostly useless.)

[Öö Tiib]

On Tuesday, 29 December 2020 at 12:55:36 UTC+2, David Brown wrote:
> On 29/12/2020 07:34, Brian Wood wrote:
> > On Wednesday, December 26, 2018 at 2:56:10 PM UTC-6, Brian Wood wrote:
> >>
> >> 4. Std::string_view is back-ported to 2011 C++
> >> and std::span is back-ported to 2017 C++.
> >>
> > I've given up on getting string_view back-ported to 2011 C++.
> You can be very confident that these will not be back-ported - at least
> not as part of the standard library. But you can always implement your
> own similar classes.

Why to reinvent a wheel? Quite decent implementation is available
under copy-left license:
<https://www.boost.org/doc/libs/1_75_0/boost/utility/string_view.hpp>
It runs fine on all C++11 compilers I can reach and interface is same
as that of std::basic_string_view. If there are some issue with it then
better to fix that (and perhaps to put up pull request to boost) than to
reinvent it again.

[daniel...@gmail.com]

On Tuesday, December 29, 2020 at 7:24:25 AM UTC-5, Öö Tiib wrote:
> On Tuesday, 29 December 2020 at 12:55:36 UTC+2, David Brown wrote:
> > You can be very confident that these will not be back-ported - at least
> > not as part of the standard library. But you can always implement your
> > own similar classes.

> Why to reinvent a wheel?

I'm sure you already know this, but for open source libraries, users for
the most part do not want dependencies on other libraries.

> Quite decent implementation is available

But not self-contained in one or two files.

Daniel

[Jorgen Grahn]

On Tue, 2020-12-29, daniel...@gmail.com wrote:
> On Tuesday, December 29, 2020 at 7:24:25 AM UTC-5, Öö Tiib wrote:
>> On Tuesday, 29 December 2020 at 12:55:36 UTC+2, David Brown wrote:
>> > You can be very confident that these will not be back-ported - at least
>> > not as part of the standard library. But you can always implement your
>> > own similar classes.
>
>> Why to reinvent a wheel?
>
> I'm sure you already know this, but for open source libraries, users for
> the most part do not want dependencies on other libraries.

[citation needed]

Personally I enjoy reinventing wheels (I spent the last few days
implementing and testing calendar and day-of-week functions).

But sometimes I wonder why that particular program isn't done yet.
I started writing it in 2010. I'd like to think others are more
focused on shipping something useful than I am.

/Jorgen

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

[Brian Wood]

On Tuesday, December 29, 2020 at 4:55:36 AM UTC-6, David Brown wrote:
> On 29/12/2020 07:34, Brian Wood wrote:
> > On Wednesday, December 26, 2018 at 2:56:10 PM UTC-6, Brian Wood wrote:
> >> Shalom Here's my 2019 wish list:
> >>
> >> 1. Clang and Gcc keep supporting #import.
> >>
> > I'm not sure about Clang, but Gcc is still supporting #import.
> It has been marked "obsolete" and "not a well designed feature" in the
> gcc manuals for decades - since at least the oldest conveniently
> available gcc manual on the gcc website (gcc 2.95.3). It should never
> be used in C or C++ code, even if that code is not intended to be portable.
> >
> >> 2. Microsoft makes it so you don't have to
> >> call WSAStartup(). By the grace of G-d, I've
> >> made this:
> >> https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc
> >
> > The link for that program has changed:
> > https://github.com/Ebenezer-group/onwards/blob/master/src/tiers/genz.cc
> >
> >>
> >> into a nice little program. One of few warts
> >> remaining in it is the call to "winStart" that
> >> wraps the call to WSAStartup(). On FreeBSD and
> >> Linux, winStart() is a no-op. 2019 would be a
> >> good time to clean that up!
> >
> > I don't think there's any progress on this one. It would
> > be great to hear otherwise.
> It is not relevant to C++, only one odd (albeit popular) implementation.

It's a blight on a lot of C++ programs.

> >
> >>
> >> 3. A compiler (Gcc?) with support for static exceptions.
> >> I'll be able to start taking advantage of static
> >> exceptions in the closed-source part of my work.
> >
> > I'm not sure if there's any progress with this. If so I'd
> > be happy to hear it.
> >
> The proposed new static exception system is, AFAIK, still at the
> proposal stage and there are no generally available test
> implementations. It will be a while before these are usable for testing
> in code, and a good deal longer before there is sufficient standard
> library support that they can replace normal (old) exceptions. But you
> are not alone in wanting this - it's a feature that I think will be very
> eagerly awaited.
> >>
> >> 4. Std::string_view is back-ported to 2011 C++
> >> and std::span is back-ported to 2017 C++.
> >>
> > I've given up on getting string_view back-ported to 2011 C++.
> You can be very confident that these will not be back-ported - at least
> not as part of the standard library. But you can always implement your
> own similar classes.
> > And I'm thinking about biting the bullet (again) and requiring
> > 2020 C++ of my users:
> How many people will that affect? The advantage of having no users is
> that you can impose any requirements you find convenient. This
> disadvantage is that it makes it less likely that you will get any users
> - no one will use a month-old standard for serious code.

Well, you snipped the part about limiting my use of 2020 C++
to std::span and still being accessible to 2017 C++ users that
bring their own std::span.

There are advantages to not having external users. It gives us
(C++ users) time to improve the design and documentation
of my software. There are some that have been in denial here
about the import of on-line code generation, and a number of
other things, but I keep saying "better late than never" and
welcome the stragglers.(*)

> >
> > I didn't mention it above, but there's also the Linux/sctp
> > stuff that I've mentioned in other threads.
> SCTP has nothing to do with C++. (It seems to be a nice protocol, but
> as long as Windows doesn't support it natively and off-the-shelf routers
> have no support for SCTP connection tracking for NAT, it's mostly useless.)

I'm not trying to support Windows for my middle tier that is
affected by this ifdef. Partly that's because of the WSAStartup
stuff and other things like that. I know it's difficult to get some
organizations to do anything so I decided years ago to drop
Windows support for that program. I'm happy with that decision,
but am frustrated with Linux for this.

(*) “For the scientist who has lived by his faith in the power of
reason, the story ends like a bad dream. He has scaled the
mountains of ignorance, he is about to conquer the highest peak;
as he pulls himself over the final rock, he is greeted by a band
of theologians who have been sitting there for centuries.”
― Robert Jastrow, G-d and the Astronomers


Brian
Ebenezer Enterprises
https://github.com/Ebenezer-group/onwards

[Brian Wood]

I should mention something about Bjarne's quote about
how he needed to "hurry up and fix everything." That's true
of my software also I'm afraid.

[Öö Tiib]

On Tuesday, 29 December 2020 at 17:46:49 UTC+2, daniel...@gmail.com wrote:
> On Tuesday, December 29, 2020 at 7:24:25 AM UTC-5, Öö Tiib wrote:
> > On Tuesday, 29 December 2020 at 12:55:36 UTC+2, David Brown wrote:
> > > You can be very confident that these will not be back-ported - at least
> > > not as part of the standard library. But you can always implement your
> > > own similar classes.
>
> > Why to reinvent a wheel?
> I'm sure you already know this, but for open source libraries, users for
> the most part do not want dependencies on other libraries.

I myself am usually annoyed by wheels reinvented (square as rule)
instead of using standard library, or whatever other library be it
boost, eigen, sdl, rapidjson, ncurses and long list of others I know
that work.

> > Quite decent implementation is available
> But not self-contained in one or two files.

So what? What are you requiring from what you got for free? Do it
yourself. You can extract it and make compile-time option to use your
extracted version as third alternative to std::basic_string_view and
boost::basic_string_view. Does anyone want your reinvented thing?
Who?

The resulting naive garbage is what I've learned to frown at. Anecdotal
history of binary search is most clear example of what I observe from
day to day:

"When Jon Bentley assigned binary search as a problem in a
course for professional programmers, he found that ninety
percent failed to provide a correct solution after several hours
of working on it, mainly because the incorrect implementations
failed to run or returned a wrong answer in rare edge cases. A
study published in 1988 shows that accurate code for it is only
found in five out of twenty textbooks."
<https://en.wikipedia.org/wiki/Binary_search_algorithm>

It all is same about professional programmers of 2021, about
binary search and about lot of other similarly "trivial" things they
reinvent. If I see it then they fail my review with
"Use std::lower_bound here!".

[Jorgen Grahn]

On Sun, 2021-01-03, Öö Tiib wrote:
...

> The resulting naive garbage is what I've learned to frown at. Anecdotal
> history of binary search is most clear example of what I observe from
> day to day:
>
> "When Jon Bentley assigned binary search as a problem in a
> course for professional programmers, he found that ninety
> percent failed to provide a correct solution after several hours
> of working on it, mainly because the incorrect implementations
> failed to run or returned a wrong answer in rare edge cases. A
> study published in 1988 shows that accurate code for it is only
> found in five out of twenty textbooks."
> <https://en.wikipedia.org/wiki/Binary_search_algorithm>

That's weird. I remember the class circa 1991 when we tried to
implement binary search, and I remember who came up with the right
solution (not me). We all knew (or learned) it was hard and, more
importantly, we knew how to prove an implementation was correct (with
invariants and such).

Perhaps our education was better than average, but why bother teaching
binary search if you don't do it properly?

[Öö Tiib]

All people learn. Even the teachers learn. Study published 1988 made
it lot better by 1991. But people forget and old teachers retire. IT has
high salaries so only weak specialists become teachers and at 2021
you can easily find that majority of professional programmers fail
miserably when attempting to implement binary search.

Same with reinventing whatever other thing. Did you see "But [the freely
available implementation is] not self-contained in one or two files."
That talks loudly about Dunning Kruger effect of person not beaten
hard to level of elementary competence needed in our industry.

[daniel...@gmail.com]

On Sunday, January 3, 2021 at 11:36:19 AM UTC-5, Öö Tiib wrote:
> On Tuesday, 29 December 2020 at 17:46:49 UTC+2, daniel...@gmail.com wrote:

> > I'm sure you already know this, but for open source libraries, users for
> > the most part do not want dependencies on other libraries.
> I myself am usually annoyed by wheels reinvented (square as rule)
> instead of using standard library, or whatever other library be it
> boost, eigen, sdl, rapidjson, ncurses and long list of others I know
> that work.

Most of the libraries you mention reinvent quite a few things themselves.
rapidjson reinvents float parsing, and one of the 427 items on its issues
list is a failure of exact float parsing in some cases.

> > > Quite decent implementation is available
> > But not self-contained in one or two files.
> So what? What are you requiring from what you got for free? Do it
> yourself. You can extract it and make compile-time option to use your
> extracted version as third alternative to std::basic_string_view and
> boost::basic_string_view. Does anyone want your reinvented thing?

Apparently. I have implementations of ns::basic_string_view, ns::optional,
and ns::span, which are part of an open source project that has been
described as "popular", and receives nice user feedback. These names
resolve to the standard library equivalents if the appropriate C++
version is detected.

> Who?

Users. But why personalize this? What difference does that make?

Daniel

[Jorgen Grahn]

I might fail too, but at least I wouldn't deliver a broken
implementation.

> Same with reinventing whatever other thing. Did you see "But [the freely
> available implementation is] not self-contained in one or two files."
> That talks loudly about Dunning Kruger effect of person not beaten
> hard to level of elementary competence needed in our industry.

I did, but decided to comment only on the binary search. I'm not sure
I really want to read the OP's explanation of that. Nowaday I try to
avoid crackpot ideas, and try to remember I'm not responsible to fight
them.

[Öö Tiib]

On Monday, 4 January 2021 at 00:00:17 UTC+2, daniel...@gmail.com wrote:
> On Sunday, January 3, 2021 at 11:36:19 AM UTC-5, Öö Tiib wrote:
> > On Tuesday, 29 December 2020 at 17:46:49 UTC+2, daniel...@gmail.com wrote:
>
> > > I'm sure you already know this, but for open source libraries, users for
> > > the most part do not want dependencies on other libraries.
> > I myself am usually annoyed by wheels reinvented (square as rule)
> > instead of using standard library, or whatever other library be it
> > boost, eigen, sdl, rapidjson, ncurses and long list of others I know
> > that work.
> Most of the libraries you mention reinvent quite a few things themselves.
> rapidjson reinvents float parsing, and one of the 427 items on its issues
> list is a failure of exact float parsing in some cases.

Often they do because they need to. For example I can't use <random>
ever as it is not portable; need to use something else that is portable like
Boost.Random that has some portable parts.

The requirements of "number" in JSON and fundamental numeric types
in C++ are so different that those can not be compatible with each other
in generic manner. Rapidjson does provide some alternatives. The
full precision variant was fine in range that mattered to me. The tendency
of each getting their own take on Google's V8 Grisu3 of Florian Loitsch
tinkered in instead of cooperating and adding some decent thing to boost
together is somewhat sad.

> > > > Quite decent implementation is available
> > > But not self-contained in one or two files.
> > So what? What are you requiring from what you got for free? Do it
> > yourself. You can extract it and make compile-time option to use your
> > extracted version as third alternative to std::basic_string_view and
> > boost::basic_string_view. Does anyone want your reinvented thing?
> Apparently. I have implementations of ns::basic_string_view, ns::optional,
> and ns::span, which are part of an open source project that has been
> described as "popular", and receives nice user feedback. These names
> resolve to the standard library equivalents if the appropriate C++
> version is detected.

It is not compatible with boost::basic_string_view? I can't
use it. I have to mostly work with C++14 compiler as it has working
constexpr. For C++17 that broke it one has perhaps to use external code
generators/preprocessors to fix it back. No time for to manufacture
such. So all the guys with alib::string_view, blib::string_view etc. that
do not cooperate with boost::string_view are off for some time.

> > Who?
>
> Users. But why personalize this? What difference does that make?

Uhh? So I assumed some kind of progress ... pride ... or
vanity ... desire to prove that you are the man on something worth
doing. Otherwise people do things but never brag and that is wrong.

You are that Daniel who makes jsoncons? Last I tried it was way
slower than rapidjson. But it was 2018 or so. Performance is not
all there is as It does not matter how quickly we get wrong answers.
But unfortunately it seemed to have more other quirks too than
rapidjson. But ... peace, you have users so you have done something
correctly and as I have all January fully booked of pressing matters
I can't repeat the evaluation anytime soon.

[daniel...@gmail.com]

On Sunday, January 3, 2021 at 3:28:39 PM UTC-5, Öö Tiib wrote:
>
> Same with reinventing whatever other thing. Did you see "But [the freely
> available implementation is] not self-contained in one or two files."
> That talks loudly about Dunning Kruger effect of person not beaten
> hard to level of elementary competence needed in our industry.

I'll reply to this, although I don't think it will do any good.

Let's take an author of an open source library that needs to support
C++11 and later, and wants basic_string_view, partly for internal
implementation, partly as a type in interfaces, and partly to support
traits that recognize std::basic_string_view when available. Such
an author needs a proxy implementation when the availability
std::basic_string_view is not detected.

So our author could look at boost/utility/string_view.hpp as a source.
In it he would find that it includes six boost header files, and many
configuration macros, such as BOOST_NO_CXX11_DEFAULTED_FUNCTIONS,
BOOST_GCC, BOOST_STRING_VIEW_NO_CXX11_DEFAULTED_NOEXCEPT_FUNCTIONS,
BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS,
BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS,
BOOST_CXX14_CONSTEXPR etc. By the time he's sorted through
that, he could just as easily use cppreference as a spec and implement
it. He doesn't care about the BOOST_NO_CXX_ macros, he's only
supporting C++11 and later. He doesn't care about the configurations
for earlier experimental versions of basic_string_view. He may care
about C++14 constexpr support not present in C++11, and conditionally
support that, but frankly that's being pedantic. From the library's
perspective, this class is a proxy implementation until C++ 17 support
arrives. And in terms of level of difficulty, this class is probably
simpler than most things in his library, it is not hard.

Regardless of what choice the author makes, he still needs to
provide all the test cases. He still needs to expose the class to Google
fuzzer, check with PVS Studio, compile with many compilers with -Wall
and -Wpedantic and the sanitizers. The standards in open source are
pretty high.

I've written a lot of sentences, to try and convey that I can have
an informed opinion, but I know it's a waste of time.

Daniel

[Öö Tiib]

On Monday, 4 January 2021 at 02:32:43 UTC+2, daniel...@gmail.com wrote:
> On Sunday, January 3, 2021 at 3:28:39 PM UTC-5, Öö Tiib wrote:
> >
> > Same with reinventing whatever other thing. Did you see "But [the freely
> > available implementation is] not self-contained in one or two files."
> > That talks loudly about Dunning Kruger effect of person not beaten
> > hard to level of elementary competence needed in our industry.
> I'll reply to this, although I don't think it will do any good.
>
> Let's take an author of an open source library that needs to support
> C++11 and later, and wants basic_string_view, partly for internal
> implementation, partly as a type in interfaces, and partly to support
> traits that recognize std::basic_string_view when available. Such
> an author needs a proxy implementation when the availability
> std::basic_string_view is not detected.
>
> So our author could look at boost/utility/string_view.hpp as a source.
> In it he would find that it includes six boost header files, and many
> configuration macros, such as BOOST_NO_CXX11_DEFAULTED_FUNCTIONS,
> BOOST_GCC, BOOST_STRING_VIEW_NO_CXX11_DEFAULTED_NOEXCEPT_FUNCTIONS,
> BOOST_NO_CXX11_EXPLICIT_CONVERSION_OPERATORS,
> BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS,
> BOOST_CXX14_CONSTEXPR etc.

All compilers let you do just preprocessing step. It is still work
but nothing so terrible.

> By the time he's sorted through
> that, he could just as easily use cppreference as a spec and implement
> it. He doesn't care about the BOOST_NO_CXX_ macros, he's only
> supporting C++11 and later. He doesn't care about the configurations
> for earlier experimental versions of basic_string_view. He may care
> about C++14 constexpr support not present in C++11, and conditionally
> support that, but frankly that's being pedantic. From the library's
> perspective, this class is a proxy implementation until C++ 17 support
> arrives. And in terms of level of difficulty, this class is probably
> simpler than most things in his library, it is not hard.

You have valid points but I unfortunately am one whose code really
performs better with C++14 constexpr and boost::string_view (and
some other constexpr classes) combo.
C++17 added major constexpr classes but broke constexpr itself
and so I have to do pile of manual work to make C++17 to compile
into as efficient. It is not like pedantry for me when thing that performs
twice better needs twice less nodes to service same amount of
connections as smoothly. If there is just one node mostly idle then
C++ itself is unneeded ... as C#, PHP or Python are good enough.

> Regardless of what choice the author makes, he still needs to
> provide all the test cases. He still needs to expose the class to Google
> fuzzer, check with PVS Studio, compile with many compilers with -Wall
> and -Wpedantic and the sanitizers. The standards in open source are
> pretty high.
>
> I've written a lot of sentences, to try and convey that I can have
> an informed opinion, but I know it's a waste of time.

Oh. I really hope things get towards better this year.

[daniel...@gmail.com]

On Sunday, January 3, 2021 at 7:19:46 PM UTC-5, Öö Tiib wrote:
> On Monday, 4 January 2021 at 00:00:17 UTC+2, daniel...@gmail.com wrote:
> >
> > Users. But why personalize this? What difference does that make?
> Uhh? So I assumed some kind of progress ... pride ... or
> vanity ... desire to prove that you are the man on something worth
> doing. Otherwise people do things but never brag and that is wrong.
>
> You are that Daniel who makes jsoncons? Last I tried it was way
> slower than rapidjson. But it was 2018 or so.

It's still slower, all the JSON libraries that make parsing performance
the top priority substitute inexact float parsing algorithms for C++
library functions, it makes a big difference, and the popular benchmarks
favour doubles. simdjson may be an exception, it now claims it can
convert without loosing precision, but users still report issues.
But this is a wheel I wouldn't care to reinvent. rapidjson also benefits
from pre-configured allocators, which is also reflected in the
rapidjson issues. Floating point algorithms are hard to get right,
and fast allocators are hard to make robust.

But jsoncons does have its supporters, for instance

https://github.com/danielaparker/jsoncons#what-users-say

I've left them unattributed, but they can all be found in the closed
issues.

Daniel

[Brian Wood]

That's great. These things don't have much to do with my wish
list, but maybe by adding them here someone will see my list
and help me with one of them.

I noticed your library uses std::error_code and that message()
returns a std::string. It seems like that should be a std::string_view,
but error_code was added in 2011 so the choices were char*
or std::string.


Brian
Ebenezer Enterprises
https://webEbenezer.net

[Öö Tiib]

The std::error_code wasn't made constexpr by C++20 (despite
std::string was). So one has to use it only for run-time processing
and static_assert only for compile time processing.

But anyway what was possible in C++14 (by using custom classes or
boost::string_view) that I get custom compile time error messages
from constexpr context and run-time error messages from run-time
context by using same mechanism for both was hopelessly broken
by C++17. I do not know who was behind it Google, Microsoft,
Apple, Oracle? Perhaps all of them ... as their garbage languages
did not have custom compiler error messages but C++14 technically
had.

[daniel...@gmail.com]

A significant number of users of the library compile with
-fno-exceptions. The library tries to follow patterns in the
standard library for allowing an alternative to exceptions,
with the optional ec parameter. But this is not completely
satisfactory either. First, as ec is the last parameter,
you can't cover common cases with default parameters,
so the number of overloads grows. Second, std::error_category
itself has issues, particularly that it requires unique addresses
for the category objects, which doesn't play well with DLL's and
shared libraries, so comparing two ec's can fail. Third,
it's hard to use this approach with functions that return values,
whose types may not support default constructors. I suppose
you could have ec and return optional. But I would have preferred
std::expected, which was proposed for C++17, but rejected.

There have been a number of proposals to fix and improve error
categories.

p1196r0, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1196r0.html,
proposes replacing the requirement of unique addresses with
relying on unique 64 bit identifiers for identity. boost::system::error_category
is now implemented this way.

p1197r0, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1197r0.html,
concerns the issue you mentioned with message returning
a string and thus mandating an allocation, it proposes an
additional overload of message() that returns the message into
a user supplied buffer.

P1195R0, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1195r0.html,
proposes making <system_error> constexpr.

p1196r0 and p1197r0 were rejected for ABI breakage reasons, P1195R0
wasn't accepted for C++20 because of ABI reasons.

Daniel

[Jorgen Grahn]

No, this was useful. But I don't see what's wrong with this alternate
chain of events:

- I want basic_string_view.
- Boost has one implementation.
- All systems I target have a non-broken Boost (or if they don't,
the users have problems already).
- I'll depend on Boost and use boost::string_view (or whatever it's
called) until I can drop support for C++ versions without
std::string_view.
- I'll assume Boost has been tested.

You didn't AFAICT write about that option, although it seems like the
obvious one.

(Disclaimer: I don't always do that, either. I wanted optional<T>
recently, but ended up implementing the parts I needed instead of
requiring Boost or a recent-ish C++. It was the only thing "from the
future" I wanted in that project.)

[daniel...@gmail.com]

[daniel...@gmail.com]

On Wednesday, January 6, 2021 at 3:52:46 AM UTC-5, Jorgen Grahn wrote:

> But I don't see what's wrong with this alternate chain of events:
>
> - I want basic_string_view.
> - Boost has one implementation.
> - All systems I target have a non-broken Boost (or if they don't,
> the users have problems already).
> - I'll depend on Boost and use boost::string_view (or whatever it's
> called) until I can drop support for C++ versions without
> std::string_view.
> - I'll assume Boost has been tested.
>
> You didn't AFAICT write about that option, although it seems like the
> obvious one.

Perspectives differ. But my perspective is that among the biggest
concerns for potential users of a C++ library are dependency management
and integration into other build systems. Both become more difficult
when the library has dependencies on other libraries.

Suppose all users do have boost. And suppose the library also
uses boost. It's still improbable that both were tested with the same
version of boost.

Keep in mind that popular open source libraries typically follow
this pattern: they have a period of great activity and outstanding support
while their creator has energy, followed by a longer period of inactivity
and abandoned issue tracking when their creator gets tired and loses
interest. The library Öö Tiib referred to - rapidjson - is an example of that.
Its last release was five years ago, and one of its 429 open issues is
"Too many open Issues!" Suppose rapidjson had used boost internally
(it doesn't): what are the chances that it would have compiled cleanly
with a recent version of boost? Another popular JSON library from the
time of rapidjson, JSON Spirit, was based on boost spirit. One of its last
unanswered issues, raised in Aug 2018, was: "Trying to rebuild with latest
boost 1.61 I end up with the following errors:"

That said, I'd certainly agree that users, while unlikely to care about
the types a library uses internally, would prefer to use the types
they've standardized on themselves if those types spill over into the
public interface. Libraries can accommodate that in a number of ways.
A common approach is

#if defined(THELIB_HAS_BOOST_OPTIONAL)
#include <boost/optional.hpp>
namespace thelib {
using boost::optional;
}
#elif defined(THELIB_HAS_STD_OPTIONAL)
#include <optional>
namespace thelib {
using std::optional;
}
#else // use internal implementation
#endif // !defined(THELIB_HAS_STD_OPTIONAL)

where there is usually an attempt to detect THELIB_HAS_STD_OPTIONAL,
and the user has the option to set THELIB_HAS_BOOST_OPTIONAL.

Another approach is to support code like

auto sv = j.as<foo::string_view>();

or

auto j = json::parse(sv);

for types foo::string_view that the library doesn't know about, but
that satisfy certain type requirements.

>
> I wanted optional<T> > recently, but ended up implementing the parts
> I needed instead of requiring Boost or a recent-ish C++.

In my opinion, optional<T> is actually interesting as an implementation
exercise, as opposed to basic_string_view, which is mostly trivial. For an
intermediate level course in C++, it would make for an excellent assignment,
being of modest difficulty, and requiring an understanding of sfinae and
ref qualifiers. It's a good entry point into understanding how to implement
types along the lines of types found in standard library or boost headers,
whose code at first (or second) glance may seem somewhat obfuscated.

Daniel

[Jorgen Grahn]

On Mon, 2021-01-04, daniel...@gmail.com wrote:

> On Sunday, January 3, 2021 at 7:19:46 PM UTC-5, Öö Tiib wrote:
>> On Monday, 4 January 2021 at 00:00:17 UTC+2, daniel...@gmail.com wrote:
>> >
>> > Users. But why personalize this? What difference does that make?
>> Uhh? So I assumed some kind of progress ... pride ... or
>> vanity ... desire to prove that you are the man on something worth
>> doing. Otherwise people do things but never brag and that is wrong.
>>
>> You are that Daniel who makes jsoncons? Last I tried it was way
>> slower than rapidjson. But it was 2018 or so.
>
> It's still slower, all the JSON libraries that make parsing performance
> the top priority substitute inexact float parsing algorithms for C++
> library functions, it makes a big difference, and the popular benchmarks
> favour doubles. simdjson may be an exception, it now claims it can
> convert without loosing precision, but users still report issues.
> But this is a wheel I wouldn't care to reinvent.

Sounds sensible.

> rapidjson also benefits
> from pre-configured allocators, which is also reflected in the
> rapidjson issues. Floating point algorithms are hard to get right,
> and fast allocators are hard to make robust.

What is it about JSON which makes parsing speed so essential, anyway?
You'd think the actual I/O, plus the business logic, would dwarf the
parsing work for most use cases.

[Popping Mad]

On 1/3/21 3:28 PM, Öö Tiib wrote:
> IT has
> high salaries so only weak specialists become teachers

umm no. It is usually researchers. It is commercial coders who are
usually weak and specialized.

[spudisno...@grumpysods.com]

Some commercial coders might be weak but in general it probably takes more
skill and intelligence to write commercial systems to a deadline and to keep
clients happy than it does to teach kids some simple Python and HTML coding.

[Öö Tiib]

Lot of projects use directories of json or xml as their
data files. Usually compressed ... say 20 MB of directory
structure of json files compresses to 1.6 MB data file.
Modern SSD tend to perform awesomely, decompression
algorithms are great ... and so the bottle neck can be json
parsing. If file is opened 3 sec or 20 sec makes significant
difference in perceived performance.

[Jorgen Grahn]

Fair enough. That use case (lots of input data from compressed files,
little actual processing) is one I've implemented myself, only the
data was timed samples in a CSV-style file and the languages were Perl
and Pyton. (Nowadays people would probably use a time-series database
like Prometheus).

[daniel...@gmail.com]

On Tuesday, January 12, 2021 at 3:53:27 PM UTC-5, Jorgen Grahn wrote:
> What is it about JSON which makes parsing speed so essential, anyway?
> You'd think the actual I/O, plus the business logic, would dwarf the
> parsing work for most use cases.

Some people need that, to parse gigabytes of JSON per second. But
it's not typical.

The fast JSON parsers have never been the most popular. In its time,
jsoncpp was more popular than rapidjson, and more influential for
a later generation of JSON parsers. Other factors than speed have
been more important, including stability and usability. Currently,
incremental parsing into a user's preferred form, not library specific
tree-like structures, but standard containers of user defined types,
is high on the list.

Of course it would be nice to be fast as well. But there are trade-offs.
As previously noted, all the fast JSON parsers implement their own float
parsing. And that's very easy to get wrong. Correct float parsing
requires arbitrary-precision arithmetic (bigints) and complex error
estimation. String to float requires up to 767 digits in slow path
routines. In contrast, float to string requires only 17 digits to
uniquely determine a double value, and there are good reference
implementations available from Florian Loitsch's PhD dissertation,
https://florian.loitsch.com/publications. Consequently there are
more fast serializers than parsers.

Daniel

[Tim Rentsch]

Jorgen Grahn <grahn...@snipabacken.se> writes:

I had the good fortune to take a course where the material and
textbook was that of Dijkstra's A Discipline of Programming. So
I got used to thinking in terms of invariants and using them to
write programs correctly. I don't remember for sure if it was
part of this course but certainly my recollection associates with
this course learning how to write binary search in a way that is
both simple and verifiably correct.

The discussion suggested to me a programming exercise, two
versions of binary search:

version 1: give the index of the first possible match,
that is, the smallest index value if more
than one element matches

version 2: give the index of the last possible match,
that is, the largest index value if more
than one element matches

I had fun with this exercise (and it didn't go as quickly as I
was expecting). I hope some people here find it fun too.

[Brian Wood]

That's great. Now I wish that my wish list items would
not be forgotten for a year or two.


Brian