As you may or may not know, Bjarne Stroustrup, Herb Sutter, and others have announced a new set of C++ guidelines[1] and an accompanying library[2] that supports them. For many folks, it would be difficult to incorporate a new library into their organizations, but there is a strong desire to make use of the guidelines. I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change. What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library? -- David Sankel [1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md [2] https://github.com/Microsoft/GSL
On 24 September 2015 at 11:22, David Sankel <camior@gmail.com> wrote:
I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change.
What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?
I'm leaning against it. We aren't peer reviewing the library, and have no ability to reject things we don't like. IMO, it's already bad enough to be under isocpp, as many people mistakenly believe this will be C++ Committee approved, even though in reality this week is the first the committee has heard of it and the committee has never voted on it. And then comes the obvious question: if we are hosting the GDL, then Boost is tacitly approving those new coding guidelines, so shouldn't all new submissions to Boost follow those guidelines? -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On Thu, Sep 24, 2015 at 9:22 AM, David Sankel <camior@gmail.com> wrote:
What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?'
I haven't looked specifically at it, but I don't see why it would be a problem as long as the library goes through review just like anything else. Things may be suggested for change as that's just the nature of review, but if he really doesn't agree with something and it is preventing the library from getting accepted, he could always back out the process at that point. I agree with Nevin, though. If there is no review then there is a serious problem. No library is exempt from initial review. IMO, it also shouldn't be considered authoritative if accepted, but rather, just a set utilities and guidelines suggested by the author. It shouldn't be given special treatment, except maybe that we'd intentionally avoid breaking the library apart even if it were to turn out that certain components might otherwise be a natural fit in existing boost libraries. The library can suggest exact guidelines, but other boost libraries would individually choose to follow them. If and when the library would be accepted, I think at that point we could decide if the boost coding guidelines should be adjusted by way of a separate process. -- -Matt Calabrese
On Thu, Sep 24, 2015 at 12:22 PM, David Sankel <camior@gmail.com> wrote:
As you may or may not know, Bjarne Stroustrup, Herb Sutter, and others have announced a new set of C++ guidelines[1] and an accompanying library[2] that supports them. For many folks, it would be difficult to incorporate a new library into their organizations, but there is a strong desire to make use of the guidelines.
I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change.
What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?
The full talk is available at https://www.youtube.com/watch?v=1OEu9C51K2A Herb Sutter's take the next day is also essential to understanding the whole picture. See https://www.youtube.com/watch?v=hEx5DNLWGgA Because the purpose of the GSL is to use the C++ type system to annotate source code in a portable way so that a static analyzer can detect otherwise undetectable errors, the GSL is closely tied to the static analyzer, the best home for the library is under the direct control of the team (led by Neil MacIntosh) who are developing the static analyzer. And with the library up on GitHub there isn't really a distribution problem. Incidentally, the VC++ version of the analyzer is due to ship next month, with the clang version to follow relatively soon after that. I haven't heard when the GCC version might ship yet. Incidentally, it was also announced that the VC++ implementation of a proposed C++ Modules TS system will ship with Visual Studio 2015 update 1. No official announcement of when that will ship, but the guessing is they are aiming for sometime in October. --Beman
On 24 September 2015 at 15:46, Beman Dawes <bdawes@acm.org> wrote:
Because the purpose of the GSL is to use the C++ type system to annotate source code in a portable way so that a static analyzer can detect otherwise undetectable errors, the GSL is closely tied to the static analyzer, the best home for the library is under the direct control of the team (led by Neil MacIntosh) who are developing the static analyzer.
This scares me a bit as well. Way back when a warning was added to gcc for things that violated Scott Meyer's Effective C++ practices. As time went on, and the collective we got smarter, some of those practices got a bit outdated, but the warning never changed. I applaud the effort, but it's early days, and we just don't know whether it'll be a net positive or a net negative. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Beman Dawes <bdawes <at> acm.org> writes:
The full talk is available at https://www.youtube.com/watch? v=1OEu9C51K2A
Herb Sutter's take the next day is also essential to understanding the whole picture. See https://www.youtube.com/watch?v=hEx5DNLWGgA
I finally got through the second talk. It was really... disappointing. It felt like cheap circus for little kids. We all know that some logic deductions can be made in a trivial cases. I did not see any adult discussion about why they believe these examples are representative. IMO 99.999% of the real use case will not like this branch-less, loop-less code. Real code will look more like: void foo( int i ) { vector<int> v{1}; int& ref = v[0]; if( i%2 ) v.push_back( 2 ); if( i%2 ) i = ref; } What is their local static analysis suggest us to do in this case? If code is wrong, how should we write it in modern C++? I do not want to discourage this effort by no means, and I really believe we can use modern C++ to produce much better code. Yet, this talk did not lift my spirit. Gennadiy
Le 24/09/15 18:22, David Sankel a écrit :
As you may or may not know, Bjarne Stroustrup, Herb Sutter, and others have announced a new set of C++ guidelines[1] and an accompanying library[2] that supports them. In case your are interested, the presentation from Bjarne is public now :)
https://www.youtube.com/watch?v=1OEu9C51K2A
For many folks, it would be difficult to incorporate a new library into their organizations, but there is a strong desire to make use of the guidelines.
I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change.
What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?
While GSL would be welcome to Boost (after review of course) I don't think that it will be so useful without the static analysis tool that will check for the guidelines. If I understand GSL is hosted under Microsoft organization. I don't think they will be interested in moving to Boost. Best, Vicente
On 24.09.2015 19:22, David Sankel wrote:
As you may or may not know, Bjarne Stroustrup, Herb Sutter, and others have announced a new set of C++ guidelines[1] and an accompanying library[2] that supports them. For many folks, it would be difficult to incorporate a new library into their organizations, but there is a strong desire to make use of the guidelines.
I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle, although he is hesitant to having to go through an extensive review process where some of these basic structures would change.
What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?
I didn't take a deep look into it but I'd like a clarification as to what is being proposed. I can see there is a library of different components, some of which are probably useful (again, I didn't take a detailed look). Most of it looks like it could be proposed as an extension of Boost.Utility, but it could be separated into one or multiple libraries. In any case, I think this submission could be interesting. A review is absolutely necessary, and I'm actually surprised that Bjarne is hesitant to pursue a review - after all, the point of the review is to make the library better. I take it he simply doesn't have time for that (I hope that's the actual reason, not misbelief in the community). Please note that for the review to happen, the library components will have to be documented and tested. The second part is the guidelines (i.e. the document with the coding rules). I think Boost is not the right place for it, and neither isocpp is. This is a too controversial document, whoever is writing it, so it should probably be in a book or something that clearly states that this is the author's personal opinion. Personally I disagree with some of the guidelines, so I would probably reject it during the review anyway.
On Thu, Sep 24, 2015 at 5:02 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
...
The second part is the guidelines (i.e. the document with the coding rules). I think Boost is not the right place for it, and neither isocpp is. This is a too controversial document, whoever is writing it, so it should probably be in a book or something that clearly states that this is the author's personal opinion.
One person isn't writing it. It is an MIT licensed open source project, based on work that goes back at least to Herb Sutter and Andrei Alexandrescu's 2004 C++ Coding Standards book. The project's initial editors are Bjarne Strustrup and Herb Sutter, although they are looking for additional editors, contributors, and proof readers. Pull requests are accepted. --Beman
On 25.09.2015 01:59, Beman Dawes wrote:
On Thu, Sep 24, 2015 at 5:02 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
The second part is the guidelines (i.e. the document with the coding rules). I think Boost is not the right place for it, and neither isocpp is. This is a too controversial document, whoever is writing it, so it should probably be in a book or something that clearly states that this is the author's personal opinion.
One person isn't writing it. It is an MIT licensed open source project, based on work that goes back at least to Herb Sutter and Andrei Alexandrescu's 2004 C++ Coding Standards book. The project's initial editors are Bjarne Strustrup and Herb Sutter, although they are looking for additional editors, contributors, and proof readers. Pull requests are accepted.
Ok, so it's a collective authorship. But that still doesn't make isocpp the right place for it.
On Sep 24, 2015 2:03 PM, "Andrey Semashev" <andrey.semashev@gmail.com> wrote:
On 24.09.2015 19:22, David Sankel wrote:
I floated the idea of including GSL in Boost as a distribution mechanism
Bjarne and he said he doesn't have any objection to the idea in
although he is hesitant to having to go through an extensive review
to principle, process
where some of these basic structures would change.
What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?
I didn't take a deep look into it but I'd like a clarification as to what is being proposed.
I am not proposing that the guidelines be included in boost, only the essential libraries. -- David Sankel
On 24 September 2015 at 16:02, Andrey Semashev <andrey.semashev@gmail.com> wrote:
I can see there is a library of different components, some of which are probably useful (again, I didn't take a detailed look). Most of it looks like it could be proposed as an extension of Boost.Utility, but it could be separated into one or multiple libraries.
IMO, they need to be in their own namespace far away from the boost namespace. Concrete example: GSL has its own string_view < https://github.com/Microsoft/GSL/blob/master/include/string_view.h>, which doesn't match the interface of std::experimental::string_view. The domains are similar enough that this name will do nothing but cause endless confusion. Given this is a new project with no obvious historical reason to use the name string_view, I'm a bit wary about such a project that isn't paying attention to what is being standardized. Being in a separate namespace means one *can* name it the same, but that doesn't mean that one *should*. Personally I disagree with some of the guidelines, so I would probably
reject it during the review anyway.
Same here. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-140
Le 25/09/15 08:47, Nevin Liber a écrit :
On 24 September 2015 at 16:02, Andrey Semashev <andrey.semashev@gmail.com> wrote:
I can see there is a library of different components, some of which are probably useful (again, I didn't take a detailed look). Most of it looks like it could be proposed as an extension of Boost.Utility, but it could be separated into one or multiple libraries.
IMO, they need to be in their own namespace far away from the boost namespace.
Gabriel Dos Reis said in a comment that they expect several implementations of this library. I we want to inter-operate with any static analysis tool yes. We need to put it in the same namespace. The main problem is that there is no specification of this library, so it would be very difficult to have another implementation.
Concrete example: GSL has its own string_view < https://github.com/Microsoft/GSL/blob/master/include/string_view.h>, which doesn't match the interface of std::experimental::string_view. The domains are similar enough that this name will do nothing but cause endless confusion.
I don't think that we need to look now at the current implementation, we need a specification.
Given this is a new project with no obvious historical reason to use the name string_view, I'm a bit wary about such a project that isn't paying attention to what is being standardized. I would suggest that the guidelines recommend the use of std::experimental::string_view/variant, .... instead of their own versions of string_view or variant.,
Being in a separate namespace means one *can* name it the same, but that doesn't mean that one *should*.
Personally I disagree with some of the guidelines, so I would probably
reject it during the review anyway.
Same here. We can not all agree with all the guidelines, even the core guidelines.
Vicente
The Guidelines document at https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md has added a FAQ: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md... It addresses several of the issues and questions that had come up in this thread, so is worth a quick read if you care about the C++ Guidelines initiative. --Beman
On 9/24/15 9:22 AM, David Sankel wrote:
I floated the idea of including GSL in Boost as a distribution mechanism to Bjarne and he said he doesn't have any objection to the idea in principle,
I don't think it's a good idea to add distribution of libraries we haven't reviewed to boosts mission. We already have difficulty with the tasks we already have taken on.
although he is hesitant to having to go through an extensive review process where some of these basic structures would change.
And GSL doesn't need the Boost imprimatur to gain visibility or distribution.
What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?
If someone want's to submit their own implementation of GSL, I'm sure that would be fine. But, as others have pointed out, there is no specification, type requirements, etc for this library. So it's hard to see how one could actually do that. If someone want's to submit his own "safe" libraries, we already do that and many have been submitted in the past. Take for example shared_ptr which originally appeared in boost. So I don't think the appearance of GSL has much to do with us other than validating the idea that more high quality libraries are essential to the evolution of C++ and higher quality programming - the core idea behind Boost in the first place! We should see this as further validation of the success and indispensability of Boost, the ideas it promotes, and the vision of it's original founders and continuing collaborators. Robert Ramey.
-- David Sankel
[1] https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md [2] https://github.com/Microsoft/GSL
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 25/09/2015 04:22, David Sankel wrote:
What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?
I think the operative questions here are: 1. Are Boost libraries likely to want to depend on GSL (eg. using owner<T> and other new types / fake keywords)? 2. If #1 occurs, which of the following would Boost prefer to do? a) Include the "real" GSL as part of Boost. b) Introduce an adapter library that provides macros/types that let Boost libraries conditionally compile with "real" GSL provided externally or without any GSL. I think previous responses have already reached consensus that there is little value in including GSL in Boost without any such dependencies. I doubt these questions can be answered until GSL and its static analyser have gained more maturity and library developers have had a chance to try it out and see if it provides benefit to maintaining their own libraries, or are ok with potential API breakage for library consumers. (In theory it shouldn't take them too long, as this seems to be mainly an effort to provide some of Microsoft's SAL [1] in a more cross-platform way, so they've had some practice.) [1] https://msdn.microsoft.com/en-us/library/ms182032.aspx
On 5/10/2015 13:15, Gavin Lambert wrote:
On 25/09/2015 04:22, David Sankel wrote:
What do you all think? Would it be appropriate and/or desirable to have a Boost.GSL library?
I think the operative questions here are:
1. Are Boost libraries likely to want to depend on GSL (eg. using owner<T> and other new types / fake keywords)?
2. If #1 occurs, which of the following would Boost prefer to do?
a) Include the "real" GSL as part of Boost.
b) Introduce an adapter library that provides macros/types that let Boost libraries conditionally compile with "real" GSL provided externally or without any GSL.
Or I suppose: c) Make Boost (or some libraries thereof) require externally provided GSL without including it in Boost or providing wrappers.
participants (9)
-
Andrey Semashev -
Beman Dawes -
David Sankel -
Gavin Lambert -
Gennadiy Rozental -
Matt Calabrese -
Nevin Liber -
Robert Ramey -
Vicente J. Botet Escriba