Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements)

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements)

Nevin Liber
On 2 April 2015 at 08:13, Niall Douglas <[hidden email]> wrote:

> I
> was recently working with eggs.variant for example, and that is Boost
> quality written to Boost guidelines and yet I understand there is
> zero interest in it entering Boost, despite it being superior to
> Boost.Variant in almost every way.


I don't remember anyone asking if they'd like to see this in Boost.  Could
you point to a thread?

Even though you claim it is superior in almost every way, if I'm reading it
correctly it has one fundamental difference in that it models
"at-most-one-of" vs. Boost.Variant which models "exactly-one-of".

And yes, I would like to see it in Boost, because as variant gets proposed
for the standard, it would be better to have a lot more user experience to
help us decide that fundamental question.

That certainly fits the current mission in that "We aim to establish
'existing practice' and provide reference implementations so that Boost
libraries are suitable for eventual standardization."
--
 Nevin ":-)" Liber  <mailto:[hidden email]>  (847) 691-1404

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Niall Douglas
On 2 Apr 2015 at 10:38, Nevin Liber wrote:

> > I
> > was recently working with eggs.variant for example, and that is Boost
> > quality written to Boost guidelines and yet I understand there is
> > zero interest in it entering Boost, despite it being superior to
> > Boost.Variant in almost every way.
>
>
> I don't remember anyone asking if they'd like to see this in Boost.  Could
> you point to a thread?

I don't think any such request has emerged. I base my understanding
on the fact eggs.variant is written by an old timer Booster, yet as
is obvious from the source code it is not intended to enter Boost.

Why its author does not intend this, or if I am wrong in my
understanding from examining the source code, I'd imagine its author
is the right person to ask. I am merely inferring from a detailed
examination of its source code (I helped get VS2013 support in
there).

> Even though you claim it is superior in almost every way, if I'm reading it
> correctly it has one fundamental difference in that it models
> "at-most-one-of" vs. Boost.Variant which models "exactly-one-of".

eggs.variant is pleasant to use. Boost.Variant is not.

eggs.variant makes full use of C++ 11 and constexpr's into zero
overhead where possible. Boost.Variant does not.

eggs.variant is implemented by a true master of the language, and it
shows throughout. It's very well designed and thought through, so
stuff like map keying just works naturally as does a ton of other C++
idioms. I haven't studied Boost.Variant's implementation enough to
say one way or another, but it has never struck me personally as
being as well designed and thought through. It is of course over a
decade old, and was written when C++ 98 conforming compilers were
just arriving.

Just constexpr support alone makes for a whole new class of variant
implementation.

> And yes, I would like to see it in Boost, because as variant gets proposed
> for the standard, it would be better to have a lot more user experience to
> help us decide that fundamental question.
>
> That certainly fits the current mission in that "We aim to establish
> 'existing practice' and provide reference implementations so that Boost
> libraries are suitable for eventual standardization."

These endless discussions about how best to implement Boost's future
wouldn't be happening if every top tier new C++ library was always
assumed de facto by its author to eventually be destined for Boost.
The fact that so many top tier authors, including so many formerly
with a big presence here, no longer bother with Boost I think speaks
volumes about what's gone wrong here with how library quality is
assessed here.

I think Boost needs to very substantially increase the value add on
offer to library authors over what is on offer at present.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/




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

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Gonzalo BG
I'll briefly chime in to state that I have been using Eric Niebler's
tagged_variant for a couple of months now and am very happy with it, it
comes with range-v3:

https://github.com/ericniebler/range-v3/blob/master/include/range/v3/utility/variant.hpp

(note: the utility folder of range-v3 is full of true gems)

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Vinícius dos Santos Oliveira
In reply to this post by Niall Douglas
2015-04-02 15:06 GMT-03:00 Niall Douglas <[hidden email]>:

> I think Boost needs to very substantially increase the value add on
> offer to library authors over what is on offer at present.
>

The only troubles I got trying to write a Boost-like libraries is the
excessive NIH syndrome. Tools like btool and quickdoc, which are a pain to
use and are no better than the competitors. If these tools were designed
without the assumption that you have a Boost tree lying around just to use
them, the barrier would be lower.

But that's just my opinion. Better collect the opinion from current Boost
authors.


--
Vinícius dos Santos Oliveira
https://about.me/vinipsmaker

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Eric Niebler-4
In reply to this post by Gonzalo BG
On 4/2/2015 2:17 PM, Gonzalo BG wrote:
> I'll briefly chime in to state that I have been using Eric Niebler's
> tagged_variant for a couple of months now and am very happy with it, it
> comes with range-v3:
>
> https://github.com/ericniebler/range-v3/blob/master/include/range/v3/utility/variant.hpp
>
> (note: the utility folder of range-v3 is full of true gems)

FWIW, I consider it usable, but not fully baked.

I'd like to respond to this:

On 4/2/2015 11:06 AM, Niall Douglas wrote:
> These endless discussions about how best to implement Boost's future
> wouldn't be happening if every top tier new C++ library was always
> assumed de facto by its author to eventually be destined for Boost.
> The fact that so many top tier authors, including so many formerly
> with a big presence here, no longer bother with Boost I think speaks
> volumes about what's gone wrong here with how library quality is
> assessed here.

Speaking strictly for myself here: the reason I haven't pushed to get my
recent open source contributions into Boost is not because I consider my
code of higher quality. If anything it's quite the opposite. Getting a
library into Boost is so daunting and time-consuming that -- at least
for the work I'm doing these days -- I just don't have the time. It
pains me to say that. I don't have the time to produce Boost-quality
documentation and to exhaustively test everything. Concepts are coming.
It's not hard to see that the STL will need a ground-up rewrite. I
needed to get on the Concepts train, and it was going to pull out of the
station with or without me. It would take half a year to make range-v3
Boost-worthy. By that time, I'd have missed my chance to get ranges
baked in from day 1.

Maybe that speaks to Boost's review process, but it doesn't speak to the
quality of Boost's code, which I consider very high.

I realize that doing an end-run around Boost to get ranges in the
standard is deflating for everybody who has worked to make Boost what it
is. That includes me.

FWIW, if someone were to volunteer to polish the docs and tests and run
it through a review, I'd be overjoyed to see range-v3 in Boost. Ditto
for Meta.

--
Eric Niebler
Boost.org
http://www.boost.org

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Rob Stewart
In reply to this post by Vinícius dos Santos Oliveira
On April 2, 2015 8:17:48 PM EDT, "Vinícius dos Santos Oliveira" <[hidden email]> wrote:
> 2015-04-02 15:06 GMT-03:00 Niall Douglas <[hidden email]>:
>
> > I think Boost needs to very substantially increase the value add on
> > offer to library authors over what is on offer at present.
>
> The only troubles I got trying to write a Boost-like libraries is the
> excessive NIH syndrome. Tools like btool and quickdoc, which are a
> pain to
> use and are no better than the competitors.

Those tools were created long before there were true competitors. Whether there are viable alternatives now is not really the issue. To switch to something new requires proving that the new tool does what the old one does and that it improves on the old tool significantly. Otherwise, there's no incentive to switch.

___
Rob

(Sent from my portable computation engine)

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Niall Douglas
In reply to this post by Vinícius dos Santos Oliveira
On 2 Apr 2015 at 21:17, Vinícius dos Santos Oliveira wrote:

> > I think Boost needs to very substantially increase the value add on
> > offer to library authors over what is on offer at present.
> >
>
> The only troubles I got trying to write a Boost-like libraries is the
> excessive NIH syndrome. Tools like btool and quickdoc, which are a pain to
> use and are no better than the competitors. If these tools were designed
> without the assumption that you have a Boost tree lying around just to use
> them, the barrier would be lower.

It's looking like the upcoming crop of new Boost libraries are all
not requiring Boost, so I think you're going to get what you want.
Most are header only too.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/
http://ie.linkedin.com/in/nialldouglas/




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

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Niall Douglas
In reply to this post by Eric Niebler-4
On 2 Apr 2015 at 17:33, Eric Niebler wrote:

> On 4/2/2015 11:06 AM, Niall Douglas wrote:
> > These endless discussions about how best to implement Boost's future
> > wouldn't be happening if every top tier new C++ library was always
> > assumed de facto by its author to eventually be destined for Boost.
> > The fact that so many top tier authors, including so many formerly
> > with a big presence here, no longer bother with Boost I think speaks
> > volumes about what's gone wrong here with how library quality is
> > assessed here.
>
> Speaking strictly for myself here: the reason I haven't pushed to get my
> recent open source contributions into Boost is not because I consider my
> code of higher quality. If anything it's quite the opposite. Getting a
> library into Boost is so daunting and time-consuming that -- at least
> for the work I'm doing these days -- I just don't have the time. It
> pains me to say that. I don't have the time to produce Boost-quality
> documentation and to exhaustively test everything. Concepts are coming.
> It's not hard to see that the STL will need a ground-up rewrite. I
> needed to get on the Concepts train, and it was going to pull out of the
> station with or without me. It would take half a year to make range-v3
> Boost-worthy. By that time, I'd have missed my chance to get ranges
> baked in from day 1.
I absolutely agree. I'm just out of six weeks of staying up till 5am
each night after the family went to bed to get AFIO v1.3 out the
door. That's because it had to be Boost peer review quality as it's
in the review queue. I ended up dumping perhaps 200 hours in getting
a feature complete and what I would have called "finished" library
into a Boost peer review quality library. That's 200 hours I did not
bill hourly to clients for, and as a consequence my earnings have
taken a big hit for the past two months.

If I were still working at BlackBerry, I am highly unsure if
regularly releasing a Boost library is compatible with not getting
divorced and/or not fired.

> Maybe that speaks to Boost's review process, but it doesn't speak to the
> quality of Boost's code, which I consider very high.
>
> I realize that doing an end-run around Boost to get ranges in the
> standard is deflating for everybody who has worked to make Boost what it
> is. That includes me.

And this is where the nub lies in where my vision of Boost 2.0
differs from Robert's. I want to see an incrementing score
automatically generated such that when you Eric throw caution to the
wind and accidentally dump three days of work into your potential
Boost library because something in it bugged you, you immediately see
a jump in your library's rank. If Boost programmers are like any
other type of human being, that immediate gratification has highly
positive effects on you repeating that misallocation of your time
sooner rather than later. Especially as most of the 200 hours
invested in getting a library release Boost ready is drudge work -
soak unit testing for 24h, writing yet more unit testing, spending
three nights consecutively in the debugger tracking down some rare
unrepeatable segfault, writing yet more tutorial toy use examples.
That sort of thing. All stuff which needs to be rapidly rewarded
psychologically, else you'll avoid it even more.

That tight feedback loop spurring people on psychologically to
accidentally do better can't happen when human review is involved.
Especially when people are waiting *three* *years* to get a review -
though I am very glad Emil finally has a review manager as a result
of this thread.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/




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

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements)

Antony Polukhin
In reply to this post by Nevin Liber
2015-04-02 18:38 GMT+03:00 Nevin Liber <[hidden email]>:

> On 2 April 2015 at 08:13, Niall Douglas <[hidden email]> wrote:
>
> > I
> > was recently working with eggs.variant for example, and that is Boost
> > quality written to Boost guidelines and yet I understand there is
> > zero interest in it entering Boost, despite it being superior to
> > Boost.Variant in almost every way.
>
>
> I don't remember anyone asking if they'd like to see this in Boost.  Could
> you point to a thread?
>
> Even though you claim it is superior in almost every way, if I'm reading it
> correctly it has one fundamental difference in that it models
> "at-most-one-of" vs. Boost.Variant which models "exactly-one-of".
>
> And yes, I would like to see it in Boost, because as variant gets proposed
> for the standard, it would be better to have a lot more user experience to
> help us decide that fundamental question.
>
> That certainly fits the current mission in that "We aim to establish
> 'existing practice' and provide reference implementations so that Boost
> libraries are suitable for eventual standardization."
>

I've been slowly improving Boost.Variant for two last years to achieve
result close to egg.variant. It is good that egg.variant exist and I'd like
to see it in Boost. Two things disturb me:
* egg.variant it requires a modern C++11 compiler in C+11 mode (Boost tries
to stick to C++98)
* egg.variant has some doubtfull places (all the comparisons of variant
with T, by index inplace constructors). This will be probably fixed during
review!

--
Best regards,
Antony Polukhin

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements)

Edward Diener-3
On 4/3/2015 4:33 PM, Antony Polukhin wrote:

> 2015-04-02 18:38 GMT+03:00 Nevin Liber <[hidden email]>:
>
>> On 2 April 2015 at 08:13, Niall Douglas <[hidden email]> wrote:
>>
>>> I
>>> was recently working with eggs.variant for example, and that is Boost
>>> quality written to Boost guidelines and yet I understand there is
>>> zero interest in it entering Boost, despite it being superior to
>>> Boost.Variant in almost every way.
>>
>>
>> I don't remember anyone asking if they'd like to see this in Boost.  Could
>> you point to a thread?
>>
>> Even though you claim it is superior in almost every way, if I'm reading it
>> correctly it has one fundamental difference in that it models
>> "at-most-one-of" vs. Boost.Variant which models "exactly-one-of".
>>
>> And yes, I would like to see it in Boost, because as variant gets proposed
>> for the standard, it would be better to have a lot more user experience to
>> help us decide that fundamental question.
>>
>> That certainly fits the current mission in that "We aim to establish
>> 'existing practice' and provide reference implementations so that Boost
>> libraries are suitable for eventual standardization."
>>
>
> I've been slowly improving Boost.Variant for two last years to achieve
> result close to egg.variant. It is good that egg.variant exist and I'd like
> to see it in Boost. Two things disturb me:
> * egg.variant it requires a modern C++11 compiler in C+11 mode (Boost tries
> to stick to C++98)

This should not bother you. Boost should encourage programmers to write
a library using the C++11 or C++14 standard if the domain of the library
requires such use. It is always nice to have a library work with C++98
compilers but nothing should stand in the way of Boost libraries
requiring C++11/C++14 compilers.

> * egg.variant has some doubtfull places (all the comparisons of variant
> with T, by index inplace constructors). This will be probably fixed during
> review!
>



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

[Developing for Boost saves time]( was Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem)

Robert Ramey
In reply to this post by Eric Niebler-4
Eric Niebler-4 wrote
Speaking strictly for myself here: the reason I haven't pushed to get my
recent open source contributions into Boost is not because I consider my
code of higher quality. If anything it's quite the opposite. Getting a
library into Boost is so daunting and time-consuming that -- at least
for the work I'm doing these days -- I just don't have the time.
My view is that if developing for Boost is taking extra time, you're
doing it wrong.
I don't have the time to produce Boost-quality documentation.
If producing Boost quality documentation is taking extra time, you're
doing it wrong.

I'm not being facetious here.  I think that one can't really verify
that his library is correctly conceived and design until he tries
to document it.  In our world that means as clearly specified
set of type requirements along with any other pre-conditions.
The problem is that if you leave this until you're done, you
discover that you've wasted a huge amount of time developing
something that you don't really use - or could have been
simpler.
and to exhaustively test everything.
If you're not writing the test as soon as you write a component
how do you debug it? - or if your code doesn't need debugging
(because its Eric Niebler I'm addressing here) How is anyone
else sure it doesn't need debugging?  You can't really progress
without a test.

So my suggestion is:
a) start coding
b) discover that something like "another variant type" is needed
c) code "another variant type"
d) code a test ofr "another variant type"
e) debug at least part of it
f) make the documentation for it - refine the type requirements
g) go back and clean up the code and rerun the tests
h) by this time you should have boost build or make scripts
in order to test the damn thing.
i) submit it to the boost incubator and see if anyone else
can find complaints with "another variant type".  This
get's to free testers, comments, corrections and critiques.

So far - you haven't done anything you won't have to do
pretty soon anyway - an now you've got some free outsourcing

j) pick he next piece and loop back to b)

The only thing missing is the Boost Review process. It's
hugely time consuming.  It's useful - but not strictly
necessary.  What IS necessary to get your library considered
for the standard is a concrete implementation with real
world experience.  All of the above steps are un-avoidable.

So just submit it to the incubator and move on.  If Boost want's to
review it - great.  If not - you'll still get most of the
benefits. If you look at the library Safe Numerics in the
incubator it has ONE review.  For whatever reason, the
author of that review put in some real effort.  On the basis
of his review I made a lot of small changes which will make
a huge improvement in the safe numerics library.  I don't
really need Boost, I need the help and infrastructure that
Boost members provide.  They are not quite the same thing.

I've skipped over one critical piece here.  That is picking the
right tools.  Picking the wrong tools can consume a
huge amount of time which doesn't contribute to the
project.  I spent a lot of time evaluating options for
development tools and made my recommendations in
the "Simple Tools" section of the incubator.  The set
I use and recommend aren't for everyone - but they do
work well for me.  Documentation in particular boils down to
following a template for requirements and pre-conditions.
Naturally Tutorial and Introduction can be added later.

[note - off topic detour]

Concepts are coming.
dream on. The current versions looks to be captured in the "concepts lite"
paper which is quite ill-conceived in my view.  I have a huge problem
with what I presume to be the canonical example they've chose
"sortable".  I talked about that at CPPCon.  But besides that,
we've had a simpler and "good enough" implementation of type
requirements checking in the Boost Concept Checking library for
over ten years - and hardly anyone uses it.  A more elaborate version
of something that isn't used is going to be used even less - not likely
a success in my book.

But then we never take any kind of poll about which features/libraries
are actually used by C++ programmers.  So we don't really have any
idea what's really successful.  This is perhaps a good thing.

[end detour]

I needed to get on the Concepts train, and it was going to pull out of the
station with or without me.
LOL - no way - it's guys like who are actually driving the train!
It would take half a year to make range-v3
Boost-worthy. By that time, I'd have missed my chance to get ranges
baked in from day 1.
at the risk of repeating myself, you won't save any time by trying to
shortcut the process.
Maybe that speaks to Boost's review process,
Factor the Boost review process out of the discussion.  Make a boost
quality library and let the Review process take care of itself.

The main motivation for getting a library reviewed and accepted by boost
is to get a certification of one's competence and accomplishment.  You
don't need any more of this from Boost.  It wouldn't hurt, but you don't
need it like the rest  of us.
but it doesn't speak to the quality of Boost's code, which I consider very high.
It's variable.  Considering the whole library - not just the code - In many case
it needs to be higher - a lot higher.
I realize that doing an end-run around Boost to get ranges in the
standard is deflating for everybody who has worked to make Boost what it
is. That includes me.
I understand why people would look at it this way.  And I think they're drawing
on the wrong lesson.  By skipping the Boost Review process, you're making
a rational decision under the circumstances.  It's a sign that boost has to
evolve to stay current and relevant.  How it has to evolve is something under
active discussion. To me it's not deflating - it's inspiring!
FWIW, if someone were to volunteer to polish the docs and tests and run
it through a review, I'd be overjoyed to see range-v3 in Boost. Ditto
for Meta.
well finish them off and submit them to the incubator.  Meta in particular
would be interesting for a few reasons
a) looks like you have it mostly done
b) it's small interesting component of current interest - C++11+ and MPL replacement discussion
c) it would let you demonstrate/test and lend credibility to the incubator
d) it's the most likely way you might get someone to take over this part of the project - see free outsourcing above.
e) Under "suggestions for libraries" there are two suggestions.  Seems that Meta would fit in typlists - which I would prefer as library name as it dovetails better with A's book(s).  I would like a separate smaller library for metafunctions - but I'm not sure if you've got that factored out or not.

Robert Ramey
Reply | Threaded
Open this post in threaded view
|

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements)

Rob Stewart
In reply to this post by Edward Diener-3
On April 3, 2015 6:32:48 PM EDT, Edward Diener <[hidden email]> wrote:

> On 4/3/2015 4:33 PM, Antony Polukhin wrote:
>
> > I've been slowly improving Boost.Variant for two last years to
> achieve
> > result close to egg.variant. It is good that egg.variant exist and
> I'd like
> > to see it in Boost. Two things disturb me:
> > * egg.variant it requires a modern C++11 compiler in C+11 mode
> (Boost tries
> > to stick to C++98)
>
> This should not bother you. Boost should encourage programmers to
> write
> a library using the C++11 or C++14 standard if the domain of the
> library
> requires such use. It is always nice to have a library work with C++98
> compilers but nothing should stand in the way of Boost libraries
> requiring C++11/C++14 compilers.

Boost does not try "to stick to C++98". If there's no hardship, we encourage _continued_ C++98/03 compatibility, but new libraries need not consider the older language.

___
Rob

(Sent from my portable computation engine)

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

cppljevans
In reply to this post by Eric Niebler-4
On 04/02/2015 07:33 PM, Eric Niebler wrote:

> On 4/2/2015 2:17 PM, Gonzalo BG wrote:
>> I'll briefly chime in to state that I have been using Eric Niebler's
>> tagged_variant for a couple of months now and am very happy with it, it
>> comes with range-v3:
>>
>> https://github.com/ericniebler/range-v3/blob/master/include/range/v3/utility/variant.hpp
>>
>> (note: the utility folder of range-v3 is full of true gems)
>
> FWIW, I consider it usable, but not fully baked.
>
Hi Eric.

The code at:

https://github.com/ericniebler/range-v3/blob/master/include/range/v3/utility/variant.hpp#L97

shows variant_data<T,Ts...> is defined recursively.
Wouldn't this cause large compile times?
The reason I say this is because, IIRC, one of the
reasons for the some of the preprocessor use in the current mpl
is to reduce compile times by "chunking" a number
of the T's into a single component in the recursive
inheritance chain.  IIRC, the chunk size in mpl was 10.

Have you seen any compile time problems with this
recursive variant_data?

-regards,
Larry



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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Gonzalo BG
FYI, the eggs.variant discussed above also uses a recursive union, e.g. see:

https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/detail/storage.hpp#L88

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Matt Calabrese
You need to use a recursive union if you are to get some constexpr support.

On Sat, Apr 4, 2015 at 8:15 AM, Gonzalo BG <[hidden email]> wrote:

> FYI, the eggs.variant discussed above also uses a recursive union, e.g.
> see:
>
>
> https://github.com/eggs-cpp/variant/blob/master/include/eggs/variant/detail/storage.hpp#L88
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>



--
-Matt Calabrese

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Matt Calabrese
On Sat, Apr 4, 2015 at 3:06 PM, Matt Calabrese <[hidden email]> wrote:

> You need to use a recursive union if you are to get some constexpr support.
>

Well, let me rephrase, you can expand it out by preprocessor to a certain
limit and get that too, but you can't just use aligned storage. At some
point you need to hit a recursive case.

--
-Matt Calabrese

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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

cppljevans
On 04/04/2015 05:08 PM, Matt Calabrese wrote:
> On Sat, Apr 4, 2015 at 3:06 PM, Matt Calabrese <[hidden email]> wrote:
>
>> You need to use a recursive union if you are to get some constexpr support.
>>
>
> Well, let me rephrase, you can expand it out by preprocessor to a certain
> limit and get that too, but you can't just use aligned storage. At some
> point you need to hit a recursive case.
>
Could you please elaborate on why recursion cannot be avoided?



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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Steven Watanabe-4
AMDG

On 04/04/2015 04:33 PM, Larry Evans wrote:

> On 04/04/2015 05:08 PM, Matt Calabrese wrote:
>> On Sat, Apr 4, 2015 at 3:06 PM, Matt Calabrese <[hidden email]> wrote:
>>
>>> You need to use a recursive union if you are to get some constexpr support.
>>>
>>
>> Well, let me rephrase, you can expand it out by preprocessor to a certain
>> limit and get that too, but you can't just use aligned storage. At some
>> point you need to hit a recursive case.
>>
> Could you please elaborate on why recursion cannot be avoided?
>

Variadic parameter packs can't be expanded on
class (or in this case union) members.

template<class... T>
union variant_storage {
    T t;... // illegal
};

In Christ,
Steven Watanabe


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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

cppljevans
On 04/04/2015 05:49 PM, Steven Watanabe wrote:

> AMDG
>
> On 04/04/2015 04:33 PM, Larry Evans wrote:
>> On 04/04/2015 05:08 PM, Matt Calabrese wrote:
>>> On Sat, Apr 4, 2015 at 3:06 PM, Matt Calabrese <[hidden email]> wrote:
>>>
>>>> You need to use a recursive union if you are to get some constexpr support.
>>>>
>>>
>>> Well, let me rephrase, you can expand it out by preprocessor to a certain
>>> limit and get that too, but you can't just use aligned storage. At some
>>> point you need to hit a recursive case.
>>>
>> Could you please elaborate on why recursion cannot be avoided?
>>
>
> Variadic parameter packs can't be expanded on
> class (or in this case union) members.
>
> template<class... T>
> union variant_storage {
>     T t;... // illegal
> };
>
> In Christ,
> Steven Watanabe
>

Matt said aligned storage can't be used; hence, I assume
he meant that the required alignment for the aligned storage
would require recursion, but that would be constexpr
template *function* recursion not template struct or
union recursion.  Hence, I suppose Matt meant the recursion
requirement was for functions not commposites (e.g. struct or union).

Matt?




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

Re: Another variant type (was: [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue mem

Steven Watanabe-4
AMDG

On 04/04/2015 05:07 PM, Larry Evans wrote:
>
> Matt said aligned storage can't be used; hence, I assume
> he meant that the required alignment for the aligned storage
> would require recursion, but that would be constexpr
> template *function* recursion not template struct or
> union recursion.

This doesn't make any sense to me.  The reason
that aligned storage doesn't work has nothing
to do with calculating the alignment.

>  Hence, I suppose Matt meant the recursion
> requirement was for functions not commposites (e.g. struct or union).
>

In Christ,
Steven Watanabe



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