On Friday, August 29, 2003, at 11:58 PM, Eric Friedman wrote:
I've recently added reference support to variant. For instance, the
following is now supported:
Unfortunately, the addition of this constructor seems to have broken
variant
under Metrowerks in some situations. So far, I have discovered
"Eric Friedman" <[EMAIL PROTECTED]> writes:
> 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
Thanks. Paul
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of John Maddock
| Sent: Friday, August 29, 2003 2:01 PM
| To: Boost mailing list
| Subject: Re: [boost] int64_t with MSVC 7.1 & 'strict' /Za option
|
|
| > Trying to use boost/date-time in MSVC
Gregory Colvin wrote:
> * document whether and how a library allocates memory
The Throws clause is a pretty good estimate for "whether". :-)
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Gregory Colvin wrote:
> On Friday, Aug 29, 2003, at 18:05 America/Denver, David Abrahams
> wrote:
>> Gregory Colvin <[EMAIL PROTECTED]> writes:
>>
>>> * use the standard parameterization mechanisms (Allocator) when
>>>choosing to parameterize
>>
>> I'm not sure about this one. std::allocator a
Hi,
As in subject: first line, first character.
--
Regards,
Janusz
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi all,
I think is unnecessary to test _is_default_param_;
dispatch* functions are
called when there isn't default parameter.
--
Regards,
Janusz
--- edmunds_karp_max_flow.hpp.orig Fri Aug 29 22:15:14 2003
+++ edmunds_karp_max_flow.hpp Sat Aug 30 12:46:40 2003
@@ -164,11 +164,7 @@
I consider single storage vital in my intended uses of variant.
I would slightly prefer option 1 ( void ) over option 2 ( boost::empty )
but not at the expense of availability of the implementation of
Microsoft compilers.
Option 3 would definitely not get my vote.
Keith Burton
[EMAIL PROTECTE
Misha Bergal <[EMAIL PROTECTED]> writes:
> Eric Friedman wrote:
>
>
>> P.S. Has there been any progress in handling BoostBook documentation in CVS?
>> Perhaps Greg or MetaComm can run nightly builds?
>
> We can do that. Is there any info on how to use Boost.Build v2 to
> build BoostBook?
>
> I've
Brian McNamara <[EMAIL PROTECTED]> writes:
> On Thu, Aug 28, 2003 at 03:05:19PM -0400, David Abrahams wrote:
>> Douglas Gregor <[EMAIL PROTECTED]> writes:
>> > On Thursday 28 August 2003 01:23 pm, David Abrahams wrote:
>> >> The other possible option would have been to simply not give the user
>>
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> E. Gladyshev wrote:
>> > * Consider parametrization, especialy if your library is to be available
>> > for embedded or non-traditional (like DSP, etc.) platfroms.
>>
>> I think this item will make you think twice before hiding
>> boost::signal's allo
> Trying to use boost/date-time in MSVC 7.1 in 'strict' mode option /Za
'disable
> language extensions' it seems that
>
> boost::int64_t isn't available.
>
> After a journey through the labryinthine config modules, I have got
compiling
> with
>
> #define BOOST_HAS_MS_INT64 // required if language e
> As suggested by Marco Oman, the problem appears to be caused by
overloading
> the various operators for the enum type, which happens in match_flags.hpp
> (lines 79 to 92). If these are removed for the Borland compiler, then the
> conflict goes away, at the cost of a bunch of "Assigning int to ...
"Eric Friedman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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 dangerous. The
sin
Eric Friedman wrote:
> P.S. Has there been any progress in handling BoostBook documentation in CVS?
> Perhaps Greg or MetaComm can run nightly builds?
We can do that. Is there any info on how to use Boost.Build v2 to
build BoostBook?
I've downloaded Milestone 6 zipball and built bjam. Then I
"Rob & Lori" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> For those of you who are unfamiliar with pluggable factories, I suggest
> reading the following C++ Report article:
> http://www.adtmag.com/joop/crarticle.asp?ID=1520
I have generic implementation of plugable factory in va
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 time ago at
http://aspn.activestate.
--- Aleksey Gurtovoy <[EMAIL PROTECTED]> wrote:
> E. Gladyshev wrote:
> > > * Consider parametrization, especialy if your library is to be available
> > > for embedded or non-traditional (like DSP, etc.) platfroms.
> >
> > I think this item will make you think twice before hiding
> > boost::signa
If your solution is generic i'm interested.
Is it possible to look at code ?
BTW, Your library may correlate with expected serialization library.
regards,
bohdan
"Rob & Lori" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> For those of you who are unfamiliar with pluggable factories
E. Gladyshev wrote:
> > * Consider parametrization, especialy if your library is to be available
> > for embedded or non-traditional (like DSP, etc.) platfroms.
>
> I think this item will make you think twice before hiding
> boost::signal's allocator.
An allocator parameter is not the only way to
Eric Friedman <[EMAIL PROTECTED]> wrote:
> 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).
Cool!
> See below for
Dave Gomboc <[EMAIL PROTECTED]> wrote:
>> Right now I am questioning whether the
>> pointer-like semantics is worth it to me. I would probably prefer that
>> clients type more to test whether a value is initialized so that they
>> can type less to call a function that takes an optional as a paramet
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);
> i = 2;
> BOOST_CHECK( boo
On Thu, Aug 28, 2003 at 03:59:19PM +0400, Vladimir Prus wrote:
> Would it be desirabe to have such class? I'm thinking about
>
> struct do_nothing {
> template
> void operator()(const T&) const {}
>
> template
>void operator()(const T1& t1, const T2& t2) const {}
>
>
On Thu, Aug 28, 2003 at 03:05:19PM -0400, David Abrahams wrote:
> Douglas Gregor <[EMAIL PROTECTED]> writes:
> > On Thursday 28 August 2003 01:23 pm, David Abrahams wrote:
> >> The other possible option would have been to simply not give the user
> >> a readable error message. I'm open to opinions
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
> The point is, that Jan proposed to add something which has a hidden
> overhead and I'm not sure it's a good idea. Instead of nested
> if-else-cascades, the user could also write:
>
> bool operator<( const person& lhs, const person& rhs )
> {
>return
> lhs.lastname != rhs.lastname ? l
--- Gregory Colvin <[EMAIL PROTECTED]> wrote:
> On Friday, Aug 29, 2003, at 18:16 America/Denver, E. Gladyshev wrote:
> There is a tradeoff between possibly better performance and possibly
> unwanted dependancies.
This is why we call them guidelines for now.
It is up to the developer to conside
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
On Friday, Aug 29, 2003, at 18:16 America/Denver, E. Gladyshev wrote:
I'd like to start a new thread with Gregory's suggestion
and my comments.
Gregory Colvin wrote:
...
* use the standard mechanisms (::operator new or std::allocator)
when it is necessary
Boost already has boost::allocator. IMO
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
On Friday, Aug 29, 2003, at 18:05 America/Denver, David Abrahams wrote:
Gregory Colvin <[EMAIL PROTECTED]> writes:
* use the standard parameterization mechanisms (Allocator) when
choosing to parameterize
I'm not sure about this one. std::allocator are a mess, and almost
everyone knows it. The
I'd like to start a new thread with Gregory's suggestion
and my comments.
Gregory Colvin wrote:
>
> At the least, we could add the following bullet
>
>* Discussion of memory management strategy.
>
> to http://www.boost.org/more/lib_guide.htm#Documentation
>
> I'm reluctant to say very much
Dave Gomboc <[EMAIL PROTECTED]> writes:
>> template
>> class nilable {
>
> Was that small enough to be considered not copyrightable, warrantable, etc.
> ?
>
> If so, fine. Otherwise I guess I have to disclaim any warranty, etc. Boost
> Public Licence?
http://www.boost-consulting.com/bo
Gregory Colvin <[EMAIL PROTECTED]> writes:
> * use the standard parameterization mechanisms (Allocator) when
>choosing to parameterize
I'm not sure about this one. std::allocator are a mess, and almost
everyone knows it. They were designed for containers, and they only
barely work there, IM
> 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 rationale
for
> that but I don't r
"Eric Friedman" <[EMAIL PROTECTED]> writes:
> 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
37 matches
Mail list logo
