[Boost] [Describe] Summary Review Summary

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
Boost Describe Review Summary

Boost Describe was submitted by Peter Dimov. The review period lasted from
1st March 2021 until 10th March 2021, inclusive.
Overall Verdict

Boost.Describe has been accepted into Boost.
Detailed Results

In all, 13 people submitted reviews.

Of these 13, 11 reviews were an unconditional ACCEPT.

The remaining two reviews were marked CONDITIONAL ACCEPT.

This seems to be common practice, as committing firmly to accept or reject
can seem like a bold position either way. However the Boost review process
has no provision for attaching conditions to library acceptance. The
verdict must be either that the library is sufficiently well written and
documented, as well as providing sufficient utility, to be included in the
Boost offering, or it is not.
Conditional Acceptances

In this review I counted the two remaining conditional acceptances as
ACCEPT, and decided to pass the conditions as comments/suggestions on to
the author for consideration, as well as enumerate them in this report in
the hope that further study/debate is stimulated.

Libraries evolve over time, and the comments will no doubt be useful to
Peter when making future decisions about Boost.Describe.

I will deal with the conditions mentioned by Julain Blanc first.

Julian’s concerns centered around the fact that the bitfield supplied to
the describe_members macro is not additive. I will quote his example here.

Given the following code:

struct C {

        int a;

        std::string b;

        double c;

        void f(float a, int b) {

        }

        void g() {

        }

        static void s() {}

private:

        int p_;

        void h_(std::string const& s) {}

BOOST_DESCRIBE_CLASS(C, (), (a, b, c, f, g, s), (), (p_, h_))

};


I would expect the following:

static_assert(mp_size<describe_members<C, mod_public>>::value == 6);

static_assert(mp_size<describe_members<C, mod_private>>::value == 2);

That's not the case. Instead, the results are resp 3 and 1. By default,

only data members are returned, not member functions.

So, let's try another one. I want all my member functions:

static_assert(mp_size<describe_members<C, mod_function | mod_public |

mod_protected | mod_private >>::value == 4)

--> fails. By default, it only returns non-static functions.

So, let's try to include static function as well:

static_assert(mp_size<describe_members<C, mod_static | mod_function |

mod_public | mod_protected | mod_private >>::value == 4)

That also fails. The result is one, now i only get the static

functions.

It looks that there's a mix of apples and orange in this enum. Some

values acts as they will include more data in the results, some on the

contrary will filter, and some will change completely the type of the

members enumerated.

This concern resonates with me, as I raised a similar (but less well
written) query with Peter in the same area.

Barrett Adair was the author of the second conditional accept. His
reasoning was along the same lines as Julian’s, quoted:

I don't like that I need to call describe_members multiple times to get

static, non-static, data, and functions. I would appreciate the addition of

mod_data and mod_nonstatic to keep the flags consistent. This is my only

acceptance condition.

Peter took time to respond to this concern:

The reason the static/nonstatic and data/function members are returned

separately is that the type of `pointer` changes. For nonstatic data, it's

M T::*. For static data, it's M*. For nonstatic function, it's R
(T::*)(A...).

For static function, it's R (*)(A...).

Since one typically does things with `pointer` in the loop over members,

it's rarely the case that you want all of these at once, because the
syntactic

form of the code manipulating them changes. So I've found it in practice

more convenient to separate them by default.

It is fair to say that in less recent variants of C++, iterating over
different pointer types would be problematic, although arguably less so
with later variants of C++ if some accessor function template overloads or
CPOs were made available in the library.

The decision on whether this should be explored rests with Peter.
Documentation and Examples

Reviewers almost universally commented on the quality and completeness of
the documentation.

Particular attention was drawn to the numerous examples that clearly
represent common real-world use cases.
Features Requested

Rainer Deyke requested the ability to annotate members with further
attributes. Peter responded that he would look into whether this was
possible while retaining compatibility with likely future standards
adoptions of reflection, which is a design goal of the library.

Maximilian Riemensberger wondered whether it would be possible to support
reference members and overloaded functions. Peter’s response was that alas,
no. The language itself is a limiting factor there.

Maximilian also requested the ability to annotate enums with associated
data. For example, representing an enum value as text when the text cannot
be reasonably computed from the value’s symbolic name. Peter agreed to
consider this further.

Maximilian also touched on the single-pass iteration issue, which brings
the number of observers who feel there is good grounds for future evolution
to four.
Overall Usefulness of the Library

The reviewers were unanimous in calling out the need for this kind of
library. From reading the reviews it is apparent that a great deal of
developer effort is duplicated in writing custom reflection mechanisms.

It struck me that (any kind of) language-level compile-time reflection
would be welcomed with open arms by the developer community. Perhaps we can
hope that the acceptance of Describe into Boost and its subsequent use can
inform and encourage the C++ language group to bring something to the
community sooner than later.

Please join me in extending gratitude to Peter, who has taken time and
painstaking effort to present us with such a useful, succinct and well
documented library.

Please also join me in thanking the reviewers, who can be sure that the
detailed analysis included has been read and in for the most part, already
elicited a response/bug-fix from Peter.

Sincerely,

Richard Hodges

--
Richard Hodges
[hidden email]
office: +442032898513
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
Richard Hodges wrote:
> Maximilian Riemensberger wondered whether it would be possible to support
> reference members and overloaded functions. Peter’s response was that alas,
> no. The language itself is a limiting factor there.

I'm looking into adding support for overloaded functions.

I also already made the following changes in response to review feedback:

* Increased internal limit of PP_FOR_EACH, which applied to the number of
  enumerators, bases, and members, from 24 to 52;

* Added detection of protected bases;

* Removed BOOST_DESCRIBE_ENUM_CLASS;

* Added internal (undocumented) macros BOOST_DESCRIBE_ENUM_BEGIN,
  BOOST_DESCRIBE_ENUM_ENTRY, BOOST_DESCRIBE_ENUM_END;

* Added a `boost` prefix to internal descriptor functions;

* Fixed error with classes named `D`;

* Fixed handling of empty enums;

* Allowed a trailing comma in the enumerator list;

* g++ 5/6/7 with -std=c++14 are now supported;

* Documentation code snippets are now syntax-highlighted.

Thanks to everyone involved.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, Mar 15, 2021 at 9:49 AM Richard Hodges via Boost
<[hidden email]> wrote:
> ...the Boost review process has no provision for attaching
> conditions to library acceptance.

The review manager is free to impose conditions for acceptance. I'm
not saying that it is called for in this particular case, merely
pointing out that it is possible.

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/15/21 9:48 AM, Richard Hodges via Boost wrote:
> Boost Describe Review Summary

Very good summary.  Thanks for investing the effort to be review
manager.  This job is the backbone of Boost and I'm sure a lot more
effort that it would first appear.

I do have a minor nit to point out.

>
> The remaining two reviews were marked CONDITIONAL ACCEPT.
>
> This seems to be common practice, as committing firmly to accept or reject
> can seem like a bold position either way. However the Boost review process
> has no provision for attaching conditions to library acceptance. The
> verdict must be either that the library is sufficiently well written and
> documented, as well as providing sufficient utility, to be included in the
> Boost offering, or it is not.
> Conditional Acceptances

I see the review manager's job as having wide latitude.  That is, I see
the review manager having the authority to do any of the following.

a) consider CONDITIONAL as "reject"
b) consider CONDITIONAL as "accept"
c) consider CONDITIONAL as "accept" if the author agrees to make
changes, "reject" otherwise.

The actual number of "votes" is not relevant.  The review manager treats
these as recommendations - but the final decision is his and his alone.
So he can interpret each "CONDITIONAL" in any way he things is most
useful and/or appropriate.  I see him having the authority to
"negotiate" with the author to implement changes in exchange for
acceptance.

To me, this is a fascinating thing about Boost.  It's blatantly
undemocratic. There is no one man/one vote here!  It is the essence
meritocracy. There is not reverence for democracy for it's own sake. But
still it attempts to cast a wide net in getting varied input for library
acceptance. It's out of sync with the times - and I think that is the
(not so) secret to it's success.

Exercise for the reader:Contrast the Boost procedures for achieving
approval with that of the C++ committee.  What does this teach us - if
anything?

Robert Ramey

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le lundi 15 mars 2021 à 19:50 +0200, Peter Dimov via Boost a écrit :
> I'm looking into adding support for overloaded functions.
>
> I also already made the following changes in response to review
> feedback:
>
> * Removed BOOST_DESCRIBE_ENUM_CLASS;

I'd rather you did *not* make that specific change. I find it useful
and convenient (i will end up copying it into an own header, and i
expect a lot of users to do the same).

There is maybe some room for an "extra" header, which would contain
additional features that a lot of users will find useful, but which are
not strictly speaking part of the core library. String to enum and enum
to string conversion could also fit this (i failed to notice it during
the review, but i later realized they can be provided in terms of c++17
to_chars / from_chars API – i wrote a working POC that i'll happily PR
once polished a bit).

Regards,

Julien


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
Julien Blanc wrote:
> > * Removed BOOST_DESCRIBE_ENUM_CLASS;
>
> I'd rather you did *not* make that specific change. I find it useful and
> convenient (i will end up copying it into an own header, and i expect a lot of
> users to do the same).

Not sure if we understand one another here; the reason I removed
BOOST_DESCRIBE_ENUM_CLASS was that, as pointed out by reviewers,
the same macro can work for both scoped and unscoped enums. So I
made BOOST_DESCRIBE_ENUM work for both, and removed the other
one, which was now redundant.

BOOST_DEFINE_ENUM_CLASS is still there.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, 15 Mar 2021 at 19:54, Robert Ramey via Boost
<[hidden email]> wrote:
>
> On 3/15/21 9:48 AM, Richard Hodges via Boost wrote:
> > Boost Describe Review Summary
>
>
> Exercise for the reader:Contrast the Boost procedures for achieving
> approval with that of the C++ committee.  What does this teach us - if
> anything?


Thank you Robert. I have taken your clarification to heart. It will no
doubt be useful in the upcoming review of Boost.MySQL, which is likely
to be _a lot more controversial_.

I do understand that not all votes have equal weight. I was careful to
judge the reasoning behind the stated conditions, and took note of the
back-and-forth on the list during the ten days.

I fully agree with regard to the committee. It has been nothing but a
cause of frustration and anger for the community of developers who
actually use C++ to get work done. I have the strong impression that
very few on the committee ever produce anything of strategic value for
their employers.

>
>
> Robert Ramey
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost



--
Richard Hodges
[hidden email]
office: +442032898513
home: +376841522
mobile: +376380212

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
On 3/15/21 12:01 PM, Richard Hodges via Boost wrote:
> I fully agree with regard to the committee. It has been nothing but a
> cause of frustration and anger for the community of developers who
> actually use C++ to get work done. I have the strong impression that
> very few on the committee ever produce anything of strategic value for
> their employers.

LOL - I didn't mean to be critical of the committee.  I merely wanted to
encourage people to think about the differences between how the commitee
address their problem with how boost address a somewhat similar problem.
  It's very interesting to me that such similar problems have such
differing approaches to their solution.  It's also fascinating to me how
approaches other than the default - consensus via majority rule - often
leads to better results.

I'm very curious about the genesis of the Boost review process.  I'd
like to see someone who knows about this write something up (naming
names!) for the web site documenting this for posterity.  Where are the
boost equivalent of "federalist papers"?

As to the committee, I've been critical of the process to the point of
snarkyness.  I'm trying to diminish that as I get older.  But I think a
lot of people feel that the Committee needs to evolve in some way to be
more effective.  Of course we have to agree on what that way is - and ...

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le lundi 15 mars 2021 à 20:11 +0200, Peter Dimov a écrit :

> Julien Blanc wrote:
> > > * Removed BOOST_DESCRIBE_ENUM_CLASS;
> >
> > I'd rather you did *not* make that specific change. I find it
> > useful and
> > convenient (i will end up copying it into an own header, and i
> > expect a lot of
> > users to do the same).
>
> Not sure if we understand one another here; the reason I removed
> BOOST_DESCRIBE_ENUM_CLASS was that, as pointed out by reviewers,
> the same macro can work for both scoped and unscoped enums. So I
> made BOOST_DESCRIBE_ENUM work for both, and removed the other
> one, which was now redundant.
>
> BOOST_DEFINE_ENUM_CLASS is still there.

Yes, definitely misunderstood you. Sorry for the noise, thanks for the
clarification.

Regards,

Julien



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 15/03/2021 19:01, Richard Hodges via Boost wrote:

> I fully agree with regard to the committee. It has been nothing but a
> cause of frustration and anger for the community of developers who
> actually use C++ to get work done. I have the strong impression that
> very few on the committee ever produce anything of strategic value for
> their employers.

This is about as categorically untrue as any statement could be.

As a general rule, those who regularly attend WG21 meetings are
responsible for enterprise level software, having in large part
contributed to the design, implementation, and maintenance of those
mission critical systems. Think the libraries and services which
underpin the whole functioning and being of Facebook, Google, Apple,
Microsoft and so on, which hundreds of thousands of developers in those
orgs use daily, and which generate billions of dollars annually in
profits, either through cost reductions/efficiency savings, or by direct
generation of value.

There are large variations in opinion, yes, and reaching consensus
always leaves everybody unsatisfied by definition. There is also often
frustration that what is being standardised is very far from what
everybody would prefer, but the committee standardises what is
presented, not what it would have if there were infinite resources.

Most of the perceived shortcomings with how the sausage is minced is
mainly due to lack of funding of ecosystemic and public goods and
services such as a package manager. That WG21 literally does not have
the power to change, yet is typically blamed for, which is unfair.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
On Mon, Mar 15, 2021 at 1:21 PM Niall Douglas via Boost <
[hidden email]> wrote:

>
> On 15/03/2021 19:01, Richard Hodges via Boost wrote:
>
> > I fully agree with regard to the committee. It has been nothing but a
> > cause of frustration and anger for the community of developers who
> > actually use C++ to get work done. I have the strong impression that
> > very few on the committee ever produce anything of strategic value for
> > their employers.
>
> This is about as categorically untrue as any statement could be.
>
> As a general rule, those who regularly attend WG21 meetings are
> responsible for enterprise level software, having in large part
> contributed to the design, implementation, and maintenance of those
> mission critical systems.

The committee seems to be concerned more with internal and external
politics than with serving the community. If that wasn't true there would
be ZERO library additions that haven't been battle hardened by being
deployed and established themselves as the defacto standard already.

The only thing they should be doing is rubber-stamping libraries that are
already the standard for doing something. Instead, it's like a giant tube
for force feeding us what we don't want (or else we would have adopted it
already). For our own good of course.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> I also already made the following changes in response to review feedback:
Thanks a lot for taking the suggestions to heart
> * Increased internal limit of PP_FOR_EACH, which applied to the number of
>    enumerators, bases, and members, from 24 to 52;
Just did a quick check on a codebase where I'd use this: The largest
enum has about 65 enumerators -.-
I checked Boost.Preprocessor and there the default limit for
BOOST_PP_FOR seems to be 256 (BTW: Why wasn't Boost.PP used?). Maybe 128
would be a good value for Describe?
> * Added internal (undocumented) macros BOOST_DESCRIBE_ENUM_BEGIN,
>    BOOST_DESCRIBE_ENUM_ENTRY, BOOST_DESCRIBE_ENUM_END;
Any chance for naming them a bit differently and/or adding
inline-documentation to the non-internal macros? I see people like me
checking the header instead of reading the docs and wondering about those.
Besides that I like the change, looks much clearer now


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 15.03.21 22:37, Emil Dotchevski via Boost wrote:
> The committee seems to be concerned more with internal and external
> politics than with serving the community. If that wasn't true there would
> be ZERO library additions that haven't been battle hardened by being
> deployed and established themselves as the defacto standard already.

That's just bullshit.  Right or wrong, good or bad, there are plenty of
reasons for pushing for a library addition without waiting for a
third-party library to establish itself as a de facto standard that have
nothing to do with politics.  For example:
   - There is a profusion of different libraries solving this problem,
none of them individually popular enough individually to become a de
facto standard.  These libraries cannot talk to each other, splintering
the community.
   - To proactively prevent the situation outlined above before it happens.
   - There is a clear need for a library, but the community has not yet
produced such a library.
   - There is a clear need for a library, but the community /cannot/
produce such a library because it requires compiler support.

Even if you think that all of these reasons are bad reasons, you should
still acknowledge that they may have good intentions behind them and
that they are not necessarily politically motivated.

> The only thing they should be doing is rubber-stamping libraries that are
> already the standard for doing something. Instead, it's like a giant tube
> for force feeding us what we don't want (or else we would have adopted it
> already). For our own good of course.

If a library is already an established de facto standard, then there's
little point in adding it to the C++ Standard, and a good reason for not
doing so: it splinters the community, which is the opposite of what a
standard should do.

Example: I use Boost.Filesystem.  I like Boost.Filesystem.  Then
std::filesystem shows up.  Now I have to choose between Boost.Filesystem
and std::filesystem.  Boost.Filesystem is probably ahead in terms of
features, but std::filesystem is the standard.  Regardless of which one
I pick, I may run into problems interfacing with third-party libraries
that use the other one.


--
Rainer Deyke ([hidden email])


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 15/03/2021 21:37, Emil Dotchevski wrote:

> On Mon, Mar 15, 2021 at 1:21 PM Niall Douglas via Boost
> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>> On 15/03/2021 19:01, Richard Hodges via Boost wrote:
>>
>> > I fully agree with regard to the committee. It has been nothing but a
>> > cause of frustration and anger for the community of developers who
>> > actually use C++ to get work done. I have the strong impression that
>> > very few on the committee ever produce anything of strategic value for
>> > their employers.
>>
>> This is about as categorically untrue as any statement could be.
>>
>> As a general rule, those who regularly attend WG21 meetings are
>> responsible for enterprise level software, having in large part
>> contributed to the design, implementation, and maintenance of those
>> mission critical systems.
>
> The committee seems to be concerned more with internal and external
> politics than with serving the community. If that wasn't true there
> would be ZERO library additions that haven't been battle hardened by
> being deployed and established themselves as the defacto standard already.
>
> The only thing they should be doing is rubber-stamping libraries that
> are already the standard for doing something. Instead, it's like a giant
> tube for force feeding us what we don't want (or else we would have
> adopted it already). For our own good of course.

Most libraries presented for standardisation ARE battle hardened
libraries. However they were typically written for preceding C++
standards, and in outdated idioms and design patterns, and require
modernisation which can involve substantial refactoring.

Something not appreciated outside the committee is that both the library
proposer(s), and their experienced users, often also want substantial
refactoring after their empirical experience. It makes sense to make use
of that experience rather than ignoring it.

I speak here of the typical case, which are all those libraries which
get standardised with little fanfare nor notice, which is the vast
majority. Only for a small, though highly visible, subset has there been
substantial design by committee. A lot of that is due to my
aforementioned explanations, which are not due to politics, but rather
resourcing (or lack thereof).

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
On Tue, Mar 16, 2021 at 6:17 AM Niall Douglas wrote:
> Something not appreciated outside the committee is that both the library
> proposer(s), and their experienced users, often also want substantial
> refactoring after their empirical experience.

Note that Richard Hodges is inside the committee (just in case that
wasn't clear to anyone else).


Glen

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
On 16/03/2021 12:52, Glen Fernandes wrote:
> On Tue, Mar 16, 2021 at 6:17 AM Niall Douglas wrote:
>> Something not appreciated outside the committee is that both the library
>> proposer(s), and their experienced users, often also want substantial
>> refactoring after their empirical experience.
>
> Note that Richard Hodges is inside the committee (just in case that
> wasn't clear to anyone else).

This is news to me.

I don't recall reading any WG21 papers by him, nor seeing him at any
WG21 committee meeting. I have only been attending myself for a few
years, however, so maybe he predates me.

I would be highly surprised if anybody who had regularly attended and
contributed to other people's papers would have the opinions he has,
most of which seem to duplicate the echo chambers in certain parts of
Slack and Reddit and other self selecting engineering groups on the
internet. Well informed criticism of WG21 is perfectly valid, and
probably shared by most WG21 participants in fact. But uninformed
criticism based on grievances is not.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
On Tue, Mar 16, 2021 at 10:53 AM Niall Douglas wrote:

>
> On 16/03/2021 12:52, Glen Fernandes wrote:
> > On Tue, Mar 16, 2021 at 6:17 AM Niall Douglas wrote:
> >> Something not appreciated outside the committee is that both the library
> >> proposer(s), and their experienced users, often also want substantial
> >> refactoring after their empirical experience.
> >
> > Note that Richard Hodges is inside the committee (just in case that
> > wasn't clear to anyone else).
>
> This is news to me.
>
> I don't recall reading any WG21 papers by him, nor seeing him at any
> WG21 committee meeting. I have only been attending myself for a few
> years, however, so maybe he predates me.
>
> I would be highly surprised if anybody who had regularly attended and
> contributed to other people's papers would have the opinions he has,
> most of which seem to duplicate the echo chambers in certain parts of
> Slack and Reddit and other self selecting engineering groups on the
> internet. Well informed criticism of WG21 is perfectly valid, and
> probably shared by most WG21 participants in fact. But uninformed
> criticism based on grievances is not.

I'm not so surprised. I predate both of you and I have a different
opinion to both of you.

(Which I won't share here, because there's no value in censuring or
praising the committee here).

Glen

Glen

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Niall Douglas wrote:
> Most libraries presented for standardisation ARE battle hardened libraries.
> However they were typically written for preceding C++ standards, and in
> outdated idioms and design patterns, and require modernisation which can
> involve substantial refactoring.

Maybe not most.

It's no longer easy to give a single reason as to why the committee's
output is what it is, as the submissions are of varying quality, philosophy, and
origin; there's no single universal problem with them.

Some of them come from big companies, are indeed totally battle-hardened,
but reflect the monoculture of the company which does not correspond
very well to the environment in which the median C++ programmer operates.

Others are useful facilities in use in more than one relatively smaller company,
battle-hardened, but pragmatic, prioritizing problem-solving over design
elegance or avoidance of undefined behavior.

And then we still have the "direct to video" libraries that haven't actually
seen much practical use.

In theory the committee should be that great place where people who value
design elegance and lack of undefined behavior and specification imprecision
meet the people who need to get their work done yesterday and the people
who have a lot of experience with large scale deployment, but in a company
culture that's not representative of the C++ community as a whole, and the
end result is supposed to be the best of these worlds.

But it isn't.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
On Tue, Mar 16, 2021 at 9:50 AM Peter Dimov via Boost
<[hidden email]> wrote:
>...

Thank you for your thoughtful analysis.

Regards

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Boost] [Describe] Summary Review Summary

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 3/16/21 9:49 AM, Peter Dimov via Boost wrote:

> Niall Douglas wrote:
>> Most libraries presented for standardisation ARE battle hardened libraries.
>> However they were typically written for preceding C++ standards, and in
>> outdated idioms and design patterns, and require modernisation which can
>> involve substantial refactoring.
>
> Maybe not most.
>
> It's no longer easy to give a single reason as to why the committee's
> output is what it is, as the submissions are of varying quality, philosophy, and
> origin; there's no single universal problem with them.
>
> Some of them come from big companies, are indeed totally battle-hardened,
> but reflect the monoculture of the company which does not correspond
> very well to the environment in which the median C++ programmer operates.
>
> Others are useful facilities in use in more than one relatively smaller company,
> battle-hardened, but pragmatic, prioritizing problem-solving over design
> elegance or avoidance of undefined behavior.
>
> And then we still have the "direct to video" libraries that haven't actually
> seen much practical use.
>
> In theory the committee should be that great place where people who value
> design elegance and lack of undefined behavior and specification imprecision
> meet the people who need to get their work done yesterday and the people
> who have a lot of experience with large scale deployment, but in a company
> culture that's not representative of the C++ community as a whole, and the
> end result is supposed to be the best of these worlds.
>
> But it isn't.

The idea that disappointment with the standards process more than one
cause and different libraries disappoint for different reasons goes a
long way to explain why we're having so much trouble suggesting
improvements to the process.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12