--- Gregory Colvin [EMAIL PROTECTED] 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 think it is a great start.
I'm reluctant to say very much more at this point, as my
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 parameter
when they have a value to pass in. Sorry
template typename T
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?
Dave
___
Unsubscribe other
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
CVS yet though because
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
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, IMO.
Dave Gomboc [EMAIL PROTECTED] writes:
template typename T
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?
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 more
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. They
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
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.
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 to the
--- 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 consider
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 ?
Dear Boosters,
I've recently added reference support to variant. For instance, the
following is now supported:
int i = 3;
boost::variantint, double var(i);
i = 2;
BOOST_CHECK( boost::getint(var) == 2 );
However, such support required the addition of an additional variant
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 that I
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 {
templateclass T
void operator()(const T) const {}
templateclass T1, class T2
void operator()(const T1 t1, const T2
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::variantint, double var(i);
i = 2;
BOOST_CHECK(
Hi,
As in subject: first line, first character.
--
Regards,
Janusz
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
CVS yet though because
20 matches
Mail list logo
