All-
Jeff Garland wrote:
[snip]
> You can obtain the latest version of the library from the
> boost-sandbox or from:
>
> http://groups.yahoo.com/group/boost/files/variant.zip
Please note that the version in the sandbox differs (sometimes
significantly) from the .zip in the files section. (The san
mplement and document such factory as another utility and just
> use it on optional<> interface.
Let me know when you get this working for optional<>. I personally would be
quite interested in seeing how it might fit into variant<>. (I won't be
making any changes, however,
Ed Brey wrote:
>
> I vote that variant be accepted into boost. I read all the
> documentation, and tried out the code in a simple test under
> VC7. I am very pleased with this library. Following are a
> comments I have that can help make it even better:
Thanks for the favorable review. I'll t
Fernando Cacciola wrote:
> I'm trying the variant library, by currently it doesn't
> compile with bcc551.
> I'd like to be able to compile it with my compiler so I can base my
> vote (tentatively to accept it) on more than the documentation
> and interpretation of the code.
Thanks for the tentativ
David B. Held wrote:
[snip]
> I realize that the operator ought to be const. But should the reference
> be? I guess I don't know if you should be able to call a d'tor on a
> const& or not.
My understanding is that since the following is legal...
const T* p = ...;
delete p;
...so is what yo
David Abrahams wrote:
[snip]
> BTW, I just realized that a conversion from variant to optional
> could be used to do extraction as well. Maybe it would be better to
> ditch extract altogether and just use optional?
I had thought about this before, but I dismissed it (perhaps too quickly)
because
Peter Dimov wrote:
> Eric Friedman wrote:
> >
> > In the past we sought to support the following...
> >
> > variant<...> var;
> > T* p = extract(&var);
> > T& r = extract(var);
> >
> > ...but it had to be dropped
Ed Brey wrote:
[snip]
> The documentation in reference.html shows that which() returns int. (I
didn't check whether the code matched up.)
OK, I didn't realize you were talking about the docs. I'll note this to fix.
> >> The copyright notice doesn't make clear that the copyright
> >> notice need
Gennadiy Rozental wrote:
> > Eric Friedman wrote:
> > >
> > >> The area would be helped by renaming extract to access.
> > >
> > > I tend to agree the name is confusing. So shall we call it
> > > boost::access<>? Input?
>
> what abo
Peter Dimov wrote:
> Eric Friedman wrote:
> > Peter Dimov wrote:
> [...]
> >> template T & extract(variant<...> & operand);
> >> template T const & extract(variant<...> const &
> >> operand); template T * extract(variant<...
David Abrahams wrote:
> "Joel de Guzman" <[EMAIL PROTECTED]> writes:
>
> > In fact, come to think of it, why not just:
> >
> > get(v)
>
> That settles it; Joel is now my official name-meister!
Seems OK to me, too.
Some questions though:
1) Semantics of get<> are to fail at compile-time for t
Peter Dimov wrote:
[snip]
> Destroying a const object is fine, but there is no reason to have a const
in
> the argument.
>
> template void call_destructor(T & t) { t.~T(); }
>
> X const x;
>
> f(x); // OK, T = X const
>
> f(5); // compile-time fail
Good point. Even though the class is in the detai
Ronald Garcia wrote:
> I am attempting to use GCC 3.2 to review the variant library, but I am
> getting compile-time errors:
>
> boost/variant.hpp:569: no class template named `mpl' in
> `boost::detail::variant
>'
> boost/variant.hpp:569: parse error before `,' token
> boost/variant.hpp:569: te
Ronald Garcia wrote:
> Correct me if I'm wrong, but it looks like your library is adding names
> (like guarded_size) to the boost::mpl namespace. Is that your intention?
> For that matter, is the mpl namespace for all metaprograms, or just those
> associated with the MPL library? Would your addit
Peter Dimov wrote:
> > Problem is that I was trying to design a general boost::extract<>
> > facility, one that needs not be specialized for each type. (Indeed,
> > with my design, visitable types need not be cognizant of the facility
> > at all.)
>
> I missed that part. ;-)
>
> Still, I consider t
Ronald Garcia wrote:
> I have been testing out some example programs from the variant tutorial.
> First, I ran across some errors in the code shown in the documentation
> for the "first variant program."
Thanks. We are aware there are problems with some of the example programs.
We'll make sure to
Ronald Garcia wrote:
> In reading through the variant docs, I noticed a requirement that at least
> two types must be supported by the variant. Is this meant for ease of
> library implementation, or is this a means of protecting programmers from
> themselves? :-)
[snip]
In addition to the comment
Gennadiy,
I actually began a lengthy reply but my mail program crashed. I'm am too
busy with other work right now to start over, I'll have to reply later in
the week.
However, please know that I have carefully read your review and plan to
reply soon.
Thanks,
Eric
Gennadiy Rozental wrote:
> Hi,
Andrei Alexandrescu wrote:
> By the way, any chance to tweak the acknowledgments a bit. They mention
> "Generic: Discriminated Unions" Part 1, Part 2, Part 3. C/C++
> Users Journal. 2002", but the text doesn't mention the earlier
publication,
> which is
> http://oonumerics.org/tmpw01/alexandrescu.p
Eric Friedman wrote:
> As I said above, this was the result of a typo and certainly not intended
to
> acknowledge your prior work. (Indeed, the sandbox CVS history shows this.)
Speaking of typos, what I *meant* to say...
As I said above, this was the result of a typo and certainly not in
Quoting Gennadiy Rozental:
> Here is my a bit late review for the variant library. In spite of
> several
> concerns that I have, I incline to vote to ACCEPT this submission.
Hi Gennadiy, thanks for the comments. I apologize for my late response.
[snip]
> Design
> __
Allen Bierbaum wrote:
> I have been very impressed with the Variant library and started using it
> with Boost 1.29.
Good to hear. I'd be interested in your experience using the library in a
real-world (?) application.
> I now need to start to using Boost 1.30.0 though and I don't think the
> var
Gennadiy Rozental wrote:
> > > Also I think we need free function form of value
> > > extraction. In other case it would be difficult to place extract
> > > in context where template parameter is deduced. And check function
> > > is not that important in most cases.
> >
> > While I am again conside
Gennadiy Rozental wrote:
> > > 8. Visitation algorithm
> > > In sketch presented visitation algorithm look like this:
> > >
> > > void foo1( which, visitor )
> > > {
> > > if( n = 1 )
> > >visitor(...)
> > >else
> > > foo2( which, visitor );
> > > }
> > >
> > > void foo2( whic
Gennadiy Rozental wrote:
> > > 2. Top level const requirement on bounded types.
> > > It's unreasonable. I should be able to define variant with const
> > > types. It will be as usable as usual constant types are. The only
> > > requirements that we may incur is that if one types is const,
> > > re
Gennadiy Rozental wrote:
> > > 3. Copy Constructible/Assignable requirements on bounded types
> > > This only need to be required if variant should have appropriate
> > > feature.
> >
> > I disagree. As-is, every variant object requires CopyConstructible
> > bounded types, as it is the only way to
Gennadiy Rozental wrote:
> > > 5. Usage std::type_info for reflection
> > > I don't think we should enforce RTTI for the variant users. We should
> > > be able to postpone the decision on what kind of reflection
> > > information user want till instantiation time.
> >
> > Please elaborate on this p
Gennadiy Rozental wrote:
> > > 7. Variant size
> > > Unfortunately I was not able to follow exact logic behind usage of 2
> > > different storages. But one thing I know:
> > > sizeof(boost::variant) could not be 28.
> > > >From what I view it seems that types that are used to construct
> > > storag
Gennadiy Rozental wrote:
> > > mpl/contain.hpp
> > > I think this is in Alexey direction: it may worth generalizing this
> > > function so that if the second argument is the sequence it will
> > > check that one sequence contain another.
>
> Alexey,
>
> What do you think about this proposition?
In
Eric Friedman wrote:
> 1) In addition to its role in enabling recursive variants,
> boost::incomplete provides a convenient way to increase space
efficiency
> (though at the expense of speed efficiency due to heap allocation). Note
> though that this is only because incomplete wraps a
Gennadiy Rozental:
> > > template
> > > void foo( T const& )
> > > {
> > >
> > > }
> > >
> > > int main()
> > > {
> > > boost::variant v = 5;
> > >
> > >// Here I want to pass const reference to integer value of variant
to
> > > function foo
> > > // foo( get( v ) ); - type T is inc
Gennadiy Rozental wrote:
> > While I do agree O(1) is better than O(N), I would like to point out
that
> > it is usable only when the pseudo-variadic template interface is used
(i.e.,
> > variant as opposed to variant).
>
> Why? And to be absolutely clear: what do you mean by "it"?
By "it" I mean
Gennadiy Rozental wrote:
> > > So what I want is
> > >
> > > typedef boost::variant GlobalParameter;
> > >
> > > GlobalParameter input_socket( 12345 ); // localhost::12345
> > > GlobalParameter output_socket( "MultiplexorSocket" );
[snip]
>
> What if variant is the member of the class template,
Gennadiy Rozental wrote:
> > > > overview.) This technique is necessary to provide a general
guarantee
> > > > of strong exception-safety, which in turn is necessary to maintain
> > > > a "never empty" invariant for variant.
> > >
> > > What is this invariant? And why is it that important.
> >
> >
Gennadiy Rozental wrote:
> "Eric Friedman" <[EMAIL PROTECTED]> wrote:
[snip]
> > If variant is given types as a MPL-sequence (e.g., variant<
mpl::list > T2, ..., TN> instead of variant), then technique you
> > propose will not work. Please prove me
Allen Bierbaum wrote:
> Eric Friedman wrote:
> > Allen Bierbaum wrote:
> >
> >>I have been very impressed with the Variant library and started using it
> >>with Boost 1.29.
> >
> >
> > Good to hear. I'd be interested in your experience using
Gennadiy Rozental wrote:
> > I argue that top-level const type arguments are meaningless in the
context
> > of variant. Given the example you provide:
> >
> > typedef boost::variant GlobalParameter;
> >
> > GlobalParameter input_socket(12345);
> > input_socket = 54321; // no way to prevent th
Gennadiy Rozental wrote:
> 1. There is "theoretical" limits for the size of MPL sequences. See MPL
docs
> (BOOST_MPL_LIMIT_LIST_SIZE for list)
> 2. You could limit variant support only for lists that does not exceed
your
> own limit BOOST_VARIANT_LIMIT_TYPES.
Not true. There is absolutely no limit
Gennadiy Rozental wrote:
> > > 2. Could type that implements swap() method somehow follow the second
> case
> > > road also? For example, could you somehow deduce T* from buffer and
swap
> > it
> > > with local copy of the argument?
> >
> > Yes, I can look into such optimizations. But as I noted in
I apologize if this has already been asked, but why aren't the libs/mpl/test
sources included in regresssion testing? I know some tests are missing and
some are perhaps as robust as they might be, but it seems some testing is
better than no testing.
I'd like to write an appropriate jamfile and inc
David Abrahams wrote:
> > I'd like to write an appropriate jamfile and include it in CVS, unless
there
> > are objections.
>
> There's already a Jamfile in libs/mpl/test. It's at version 1.9.
Oops, I missed this. Thanks.
Anyhow, my concern related more to the regression tables. But with Beman's
David Abrahams wrote:
> That's not (I think) what Alexander had in mind: IIUC he was talking
> about a wrapper over tuples such that:
>
> tuple_sequence
>
> is an MPL sequence. Of course, a better solution would be to
> specialize begin/end so that any Boost tuple is *itself* an MPL
> sequen
I've found that mpl::is_sequence fails to operate correctly on certain types
under MSVC7. I haven't tested extensively, but there certainly seems to be
some problem with class templates from namespace std. (The problem likely
extends to other types in other namespaces, and perhaps other compilers,
David Abrahams writes:
> "Eric Friedman" <[EMAIL PROTECTED]> writes:
>
> > I've found that mpl::is_sequence fails to operate correctly on certain
types
> > under MSVC7. I haven't tested extensively, but there certainly seems to
be
> > some pro
Aleksey (and all),
In working on porting boost::variant to Borland, I've come across some
trouble with a bug in the compiler.
Specfically, I'm getting "Cannot have both a template class and
function named 'bind1st'" and similarly for bind2nd. I know other MPL
headers use BOOST_MPL_AUX_COMMON_N
Aleksey (and others),
I'm working on getting variant to compile under MSVC 6, but I've come
across what seems to be an ETI problem that needs a workaround.
However, I'm not sure what is the most appropriate way to make the fix.
Below is the error output from the regression tests (variant_test1)
With the addition of the variant library has come several closely-related
components such as boost::get, boost::apply_visitor,
boost::static_visitor, and boost::visitor_ptr. While I do plan to submit a
more general-purpose visitation library for review in the near feature,
currently these component
David Abrahams wrote:
>
> Hi,
>
> BOOST_EXPLICIT_TEMPLATE_TYPE is great!
>
> However:
[snip]
> // specialization
> template <>
> int f( /*what goes here?*/ )
> {
>
> }
>
> we have no mechanism for handling these. Any ideas?
Wouldn't BOOST_EXPLICIT_TEMPLATE_TYPE(void) work?
Er
In adding output streaming support for variant, I've realized the
standard library packaged with gcc 2.9.7 and below does not support the
templated stream classes. I've also realized that Boost.Tuple features a
workaround addressing this same problem, with a comment to add a defect
macro to boost/c
John Maddock wrote:
> > In adding output streaming support for variant, I've realized the
> > standard library packaged with gcc 2.9.7 and below does not support the
> > templated stream classes. I've also realized that Boost.Tuple features a
> > workaround addressing this same problem, with a comm
Brian,
Brian Simpson wrote:
> A fundamental problem encountered by boost::variant is that of invoking an
> overloaded function for the correct type, where the type is not known
until
> runtime. As near as I can tell, all proposed solutions to this problem
have
> involved uncomfortable space or ti
David Abrahams wrote:
> Matthias Troyer writes:
>
> > Dear Boosters,
> >
> > Since some of the applications and libraries we plan on releasing soon
> > rely on Boost features and bugfixes that are in the CVS but not in
> > Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0
> > releas
Hi Petr,
Petr Koèmíd wrote:
> Hi,
>
> There is a problem with variant library simply including boost/variant,
for
> current anonymous cvs.
>
> Can be demonstrated by compiling a binary tree example from the doc page.
Both
> gcc 3.2 and 3.2.2 says:
>
> * In file included from boost/boost/variant/va
John,
John Maddock wrote:
[snip]
> Everything in suffix.hpp is generic macro workarounds - it's not dependent
> upon specific compilers just whether the appropriate macro is defined.
>
> I think you are going to have to use a dirty workaround here: check for
gcc
> before using BOOST_EXPLICIT_TEMPL
Brian Simpson wrote:
> Eric,
>
[snip]
> Heavily qualified explanation to follow... :)
>
> [snip]
> Oops! I saw the typedef'd names, observed their similarity to the names
of
> the template parameters, and immediately assumed that the switch was based
> on those parameters. Therefore, the value I
Hartmut,
Hartmut Kaiser wrote:
> Eric Friedman wrote:
[snip]
> > I believe the problem should now be fixed. Let me know if it
> > still doesn't work.
>
> I've checked a new CVS snapshot just right now, but the problem
> persists. Sorry.
I hadn't actually
Dave (and others):
Eric Friedman wrote:
> David Abrahams wrote:
> >
> > Hi,
> >
> > BOOST_EXPLICIT_TEMPLATE_TYPE is great!
> >
> > However:
> [snip]
> > // specialization
> > template <>
> > int f( /*what goes here?*/ )
Hartmut,
Hartmut Kaiser wrote:
> Beman Dawes wrote:
>
> > The variant library developers were checking in changes
> > almost daily until a week or two ago, so you might want to make sure
> > you have the latest from CVS.
>
> Thanks for your response.
> Yes, I have the latest CVS (Boost::HEAD) snap
Allen Bierbaum wrote:
> I just tried to use boost::variant with the HEAD version of boost and I
> am getting multiply defined symbols in empty.hpp. (gcc 3.2 on Linux)
>
> I fixed it by adding "inline" to the two non-template methods (see below):
>
> inline bool operator==(const empty&, const empty
Dave,
Please see the BoostBook reference documentation for variant. The HTML is
quite out of sync with the current implementation. I haven't removed it from
CVS yet though because I am still in the process of porting the examples,
etc. to BoostBook.
Sorry for the confusion.
Thanks,
Eric
_
Joel,
Joel de Guzman wrote:
[snip]
> Also, is there a reason why we can't allow:
>
> variant var;
Nothing fundamental no, just some additional metaprogramming ;) It's
supported now (see variant_reference_test).
See below for a note on the semantics of the resultant variant type, though.
>
David Abrahams wrote:
[snip]
> 2.
>
>"All members of variant satisfy the strong guarantee of
>exception-safety."
>
> Seriously? What if an underlying type's assignment operator gives
> only the basic guarantee? Surely, if you in fact use the
> underlying type's assignm
David Abrahams wrote:
> "Eric Friedman" <[EMAIL PROTECTED]> writes:
>
> > Dave,
> >
> > Please see the BoostBook reference documentation for variant. The HTML
is
> > quite out of sync with the current implementation. I haven't removed it
from
>
Gennadiy Rozental wrote:
> > BTW, after looking at the implementation I was a bit disappointed to
> > see two copies of the storage. It seems to nullify one
> > important reason for using variants (space savings), and it generates
> > more code than a single-storage version. I know you had some r
Dave,
David Abrahams wrote:
[snip]
> > If you'd
> > like to see relatively recently-generated HTML, check out
> > http://www.cs.rpi.edu/~gregod/boost/doc/html/variant.html.
>
> Suggestion: check an index page into the CVS which redirects to this
> page.
The link I provided above will not be home
Dear Boosters,
I've recently added reference support to variant. For instance, the
following is now supported:
int i = 3;
boost::variant var(i);
i = 2;
BOOST_CHECK( boost::get(var) == 2 );
However, such support required the addition of an additional variant
constructor
templa
Oops! I forgot to attach the test file!
It's now attached.
Thanks,
Eric
Eric Friedman wrote:
> Dear Boosters,
>
> I've recently added reference support to variant. For instance, the
> following is now supported:
>
> int i = 3;
> boost::variant var(i);
Eric Friedman wrote:
[snip]
> ...there are alternative (albeit less elegant) options.
[snip]
I'd like to present what are IMO the most viable options for manually
disabling variant's double storage.
Option #1:
(I presented a very similar strategy to this some tim
Peter Dimov wrote:
> When there is one and only one strict weak ordering (equality) for a
> type, not using operator< and operator== because some users might have
> different expectations is misguided. It is pretty clear what set
or
> find(first, last, v) is supposed to do; variant_less or variant_
Dave Gomboc wrote:
[snip]
> I don't like get() because I cannot write x.get() when x is a POD. This
> would mean I have to support nilable and T with different code,
> which is exactly what I'm trying to avoid.
Why not overload boost::get again for optional? This would certainly improve
consisten
Howard,
Howard Hinnant wrote:
[snip]
> If you will mail me a complete condensed demo, I'll take a look. I
> downloaded boost 1.30.2 but was unable to find boost/variant.
>
> -Howard
Thanks for offering your assistance. Variant will make its debut in 1.31.
Thus, you'll need to work from Boost CVS
Alexander Nasonov
> Eric Friedman wrote:
> > But suppose I have a variant v3, with content of a different type (call
it
> > T3). Then the assignment v1 = v3 is far more complicated (we can't use
> > T1::operator=) and, without double storage, far more dangero
Alexander Nasonov wrote:
> Eric Friedman wrote:
> > If I understand you correctly, earlier versions of variant did precisely
> > what you describe. Unfortunately, the "assumption" you make is false in
> > general. See
http://aspn.activestate.com/ASPN/Mail/Mess
Peter Dimov wrote:
[snip]
> Provide operator<. Wait six months. Collect feedback. If there is evidence
> that operator< is evil, remove it and document why it is not supplied.
OK, I'm willing to go along with this. I'll probably also include
operator==, with a similar plan for future evaluation.
74 matches
Mail list logo
