[boost] Boost.GSL?
116 views
Skip to first unread message
David Sankel
Sep 24, 2015, 12:23:32 PM9/24/15
to bo...@lists.boost.org
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Nevin Liber
Sep 24, 2015, 2:38:13 PM9/24/15
to Renee Silverman
On 24 September 2015 at 11:22, David Sankel <cam...@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.
> 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?
>
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:ne...@eviloverlord.com> (847) 691-1404
Matt Calabrese
Sep 24, 2015, 3:05:59 PM9/24/15
to bo...@lists.boost.org
On Thu, Sep 24, 2015 at 9:22 AM, David Sankel <cam...@gmail.com> wrote:
>
> What do you all think? Would it be appropriate and/or desirable to have a
> Boost.GSL library?'
>
> What do you all think? Would it be appropriate and/or desirable to have a
>
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
Beman Dawes
Sep 24, 2015, 4:47:08 PM9/24/15
to Boost Developers List
On Thu, Sep 24, 2015 at 12:22 PM, David Sankel <cam...@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
> 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?
>
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
Vicente J. Botet Escriba
Sep 24, 2015, 4:56:30 PM9/24/15
to bo...@lists.boost.org
Le 24/09/15 18:22, David Sankel a écrit :
https://www.youtube.com/watch?v=1OEu9C51K2A
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
> 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 :)
> announced a new set of C++ guidelines[1] and an accompanying library[2]
> that supports them.
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
> 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?
>
>
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
Andrey Semashev
Sep 24, 2015, 5:03:05 PM9/24/15
to bo...@lists.boost.org
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
> 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?
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.
Beman Dawes
Sep 24, 2015, 6:59:39 PM9/24/15
to Boost Developers List
On Thu, Sep 24, 2015 at 5:02 PM, Andrey Semashev <andrey....@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
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.
>
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
Andrey Semashev
Sep 24, 2015, 7:17:09 PM9/24/15
to bo...@lists.boost.org
On 25.09.2015 01:59, Beman Dawes wrote:
> On Thu, Sep 24, 2015 at 5:02 PM, Andrey Semashev <andrey....@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
> On Thu, Sep 24, 2015 at 5:02 PM, Andrey Semashev <andrey....@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.
the right place for it.
David Sankel
Sep 24, 2015, 8:21:15 PM9/24/15
to bo...@lists.boost.org
On Sep 24, 2015 2:03 PM, "Andrey Semashev" <andrey....@gmail.com>
wrote:
essential libraries.
-- David Sankel
wrote:
>
> On 24.09.2015 19:22, 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,
>> 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 am not proposing that the guidelines be included in boost, only the
> On 24.09.2015 19:22, 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,
>> 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.
essential libraries.
-- David Sankel
Nevin Liber
Sep 25, 2015, 2:31:30 AM9/25/15
to Renee Silverman
On 24 September 2015 at 15:46, Beman Dawes <bda...@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
> 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.
>
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
Sep 25, 2015, 2:47:59 AM9/25/15
to Renee Silverman
On 24 September 2015 at 16:02, Andrey Semashev <andrey....@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.
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.
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.
Vicente J. Botet Escriba
Sep 25, 2015, 1:40:17 PM9/25/15
to bo...@lists.boost.org
Le 25/09/15 08:47, Nevin Liber a écrit :
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.
need a specification.
std::experimental::string_view/variant, .... instead of their own
versions of string_view or variant.,
Vicente
> On 24 September 2015 at 16:02, Andrey Semashev <andrey....@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
> 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.
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
> 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.
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
> 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.
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.
> 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.
Vicente
Beman Dawes
Sep 30, 2015, 8:43:39 AM9/30/15
to Boost Developers List
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#S-faq
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
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md
has added a FAQ:
https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#S-faq
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
Gennadiy Rozental
Oct 1, 2015, 3:14:37 AM10/1/15
to bo...@lists.boost.org
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
> 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
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
Robert Ramey
Oct 1, 2015, 12:33:47 PM10/1/15
to bo...@lists.boost.org
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
> 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,
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.
distribution.
> What do you all think? Would it be appropriate and/or desirable to have a
> Boost.GSL library?
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.
Gavin Lambert
Oct 4, 2015, 8:16:29 PM10/4/15
to bo...@lists.boost.org
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:
> What do you all think? Would it be appropriate and/or desirable to have a
> Boost.GSL library?
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
Gavin Lambert
Oct 4, 2015, 9:10:30 PM10/4/15
to bo...@lists.boost.org
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:
> 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.
c) Make Boost (or some libraries thereof) require externally
provided GSL without including it in Boost or providing wrappers.
Reply all
Reply to author
Forward
0 new messages