Re: [boost] any_cast issues
Greg Dehaas wrote: Hi All, boost::any test = Test Me; [...] And the error message is: c:\dev\boost\boost\any.hpp(105) : error C2536: 'boost::any::holderchar [8]::held' : cannot specify explicit initializer for arrays c:\dev\boost\boost\any.hpp(122) : see declaration of 'held' c:\dev\boost\boost\any.hpp(103) : while compiling class-template member function '__thiscall boost::any::holderchar [8]::boost::any::holderchar [8](const char ()[8])' Hmm... the same problem can be seen if you try std::make_pair(1, 2); the template parameters are deduces as char[1] and char[1], and there's no much you can do with that type, not even copy it. That's the way template argument deduction works, IIRC. I suggest that you change ctors of any and any::holder to take value instead of reference, and tell what you got. Of course, you should be able to say boost::any test = static_castconst char*(Test me); HTH, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: any_cast issues
On Fri, 31 Jan 2003 10:12:42 +0200, Greg Dehaas [EMAIL PROTECTED] wrote:
Hi All,
I'm probably being stoopid, but if someone could point me in the right
direction, thanks :)
I've got this:
boost::any test = Test Me;
boost::any test = std::string(Test Me);
int nTest=0;
try
{
nTest = boost::any_castint(test);
}
catch(const boost::bad_any_cast )
{
MessageBox(NULL,Bad Cast,Bad Cast,0);
}
And the error message is:
c:\dev\boost\boost\any.hpp(105) : error C2536: 'boost::any::holderchar
[8]::held' : cannot specify explicit initializer for arrays
c:\dev\boost\boost\any.hpp(122) : see declaration of 'held'
c:\dev\boost\boost\any.hpp(103) : while compiling class-template
member function '__thiscall boost::any::holderchar
[8]::boost::any::holderchar [8](const char ()[8])'
HTH,
--Remy
Remove anti-spam sequence in reply address for a timely response.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_convertible: rationale and wording
On Thu, 30 Jan 2003 20:29:18 +0100, Terje Slettebø
[EMAIL PROTECTED] wrote:
You don't need expressions (if by that you mean an object of the type to
test, or pointer/reference to it) to check for convertibility, as it may be
done with sizeof, so no object of any kind need to be created. However, you
may need an object, or pointer/reference to it, to use function templates.
Also, that won't make it a compile-time expression, so why use function
templates for this?
The issue is not about creating objects or not but about what does it
mean for a type to be convertible to another. Personally I have no
idea what the meaning can be. Instead, the standard specifies what it
means for an expression to be implicitly convertible to another:
4/3: An expression e can be implicitly converted to a type T
if and only if the declaration ``T t=e;'' is wellformed,
for some invented temporary variable t (8.5).
[Incidentally: this is one of the few places in which the standard
uses if and only if where if and only if is intended; in other
places it just uses if :-( ]
I brought up this problem in reply to the initial post of the thread
is_convertible corner case thinking, however, that the documentation
of boost::is_convertible clarified that (the type_traits library is
one of the library I almost know nothing about). It turned out,
instead, that not only the documentation doesn't, but the ISO proposal
doesn't either. This one, together with the access-checking problem:
class X {
operator int(); // private
friend class Y;
};
class Y {
void f() {
is_convertibleX, int::value; // true or false??
// or error?
}
};
are the two main issues. You can find more details in the above
mentioned thread.
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] any_cast issues
- Original Message -
From: Vladimir Prus [EMAIL PROTECTED]
Greg Dehaas wrote:
Hi All,
boost::any test = Test Me;
[...]
And the error message is:
c:\dev\boost\boost\any.hpp(105) : error C2536: 'boost::any::holderchar
[8]::held' : cannot specify explicit initializer for arrays
c:\dev\boost\boost\any.hpp(122) : see declaration of 'held'
c:\dev\boost\boost\any.hpp(103) : while compiling class-template
member function '__thiscall boost::any::holderchar
[8]::boost::any::holderchar [8](const char ()[8])'
Hmm... the same problem can be seen if you try
std::make_pair(1, 2);
the template parameters are deduces as char[1] and char[1], and there's no
much you can do with that type, not even copy it. That's the way template
argument deduction works, IIRC. I suggest that you change ctors of any and
any::holder to take value instead of reference, and tell what you got. Of
course, you should be able to say
boost::any test = static_castconst char*(Test me);
Yes, but a library can make it work. For instance, make_tuple(hello, , world)
works as expected. QOI matter?
// Arrays can't be stored as plain types; convert them to references.
templateclass T, int n
struct make_tuple_traits T[n] {
typedef const T (type)[n];
};
Cheers,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] any_cast issues
Thanks guys :) -Original Message- From: Vladimir Prus [mailto:[EMAIL PROTECTED]] Sent: Friday, January 31, 2003 11:02 AM To: Boost mailing list Subject: Re: [boost] any_cast issues Greg Dehaas wrote: Hi All, boost::any test = Test Me; [...] And the error message is: c:\dev\boost\boost\any.hpp(105) : error C2536: 'boost::any::holderchar [8]::held' : cannot specify explicit initializer for arrays c:\dev\boost\boost\any.hpp(122) : see declaration of 'held' c:\dev\boost\boost\any.hpp(103) : while compiling class-template member function '__thiscall boost::any::holderchar [8]::boost::any::holderchar [8](const char ()[8])' Hmm... the same problem can be seen if you try std::make_pair(1, 2); the template parameters are deduces as char[1] and char[1], and there's no much you can do with that type, not even copy it. That's the way template argument deduction works, IIRC. I suggest that you change ctors of any and any::holder to take value instead of reference, and tell what you got. Of course, you should be able to say boost::any test = static_castconst char*(Test me); HTH, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost.thread / link error
Hi, I compiled boost_1_29_0 libraries with gcc-3.2.1 , copied the libboost_thread.a library to HOME and tried to compile a small thread test program: with: g++ -I/opt/boost_1_29_0 -L/home/pberg -lboost_thread -lpthread tt.cc I get: /tmp/ccjTcBBI.o: In function `main': /tmp/ccjTcBBI.o(.text+0x44): undefined reference to `boost::thread::thread[in-charge](boost::function0void, boost::empty_function_policy, boost::empty_function_mixin, std::allocatorboost::function_base const)' /tmp/ccjTcBBI.o(.text+0xca): undefined reference to `boost::thread::thread[in-charge](boost::function0void, boost::empty_function_policy, boost::empty_function_mixin, std::allocatorboost::function_base const)' /tmp/ccjTcBBI.o(.text+0x11b): undefined reference to `boost::thread::join()' /tmp/ccjTcBBI.o(.text+0x126): undefined reference to `boost::thread::join()' /tmp/ccjTcBBI.o(.text+0x139): undefined reference to `boost::thread::~thread [in-charge]()' /tmp/ccjTcBBI.o(.text+0x149): undefined reference to `boost::thread::~thread [in-charge]()' /tmp/ccjTcBBI.o(.text+0x15c): undefined reference to `boost::thread::~thread [in-charge]()' /tmp/ccjTcBBI.o(.text+0x175): undefined reference to `boost::thread::~thread [in-charge]()' collect2: ld returned 1 exit status The library is located in /home/pberg. Whats wrong here? Please give a hint, Thomas -- If the map and the terrain disagree, trust the terrain. Swiss army aphorism ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread library with BOOST_HAS_PTHREAD
Shimshon Duvdevan wrote: [ ... Solaris - PTHREAD_SCOPE_SYSTEM ... ] Can anyone verify the supposed boost threads library behavior on a multi-processor Solaris machine? Is this behavior the intended one? Perhaps a bug fix is necessary. That's Solaris' bug and actually, they've already kinda-fixed it recently. More info on this can be found in the c.p.t.(*) archive on google. regards, alexander. (*) http://groups.google.com/groups?q=comp.programming.threads ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
From: David B. Held [EMAIL PROTECTED]
smart_ptr(P p)
: storage(p), ownership(p), checking(), conversion()
{ checking::on_init(p) }
smart_ptr(P p)
: storage(p), ownership(p), checking(p), conversion()
{}
is nicer. Maybe even conversion(p), for consistency. :-)
But that's not what I have in mind. There are a number of pitfalls awaiting
you.
Consider the converting move constructor:
smart_ptr(smart_ptr rhs)
: storage(rhs), ownership(rhs), checking(rhs), conversion(rhs)
{}
(template parameters omitted for brevity)
Its purpose is to take ownership away from the auto_ptr-like rhs (you wanted
to support that) and construct a counted_ptr. As storage is constructed
first, it needs to move from rhs.storage; now when ownership throws,
rhs.storage will be left empty, and the object is gone. This is not that big
of a problem... provided that the other rhs policies can handle storage
being zeroed.
Weak pointers are another interesting case, assuming you want to support
them. A weak_ptr storage can't be copied safely, as the pointer may have
been deleted. If you look at shared_ptr::shared_ptr(weak_ptr const ),
you'll see that it copies the count first (its ownership policy), and then
proceeds to copy px (its storage policy). weak_ptr's converting
constructor does something similar.
Also:
smart_ptr::~smart_ptr()
{
if (!ownership_policy::release(get_impl(*this)))
{
storage_policy::release();
}
}
It's difficult to supply a get_impl for a weak pointer, since the returned
pointer can be invalidated at any time by a different thread. That's why
weak_ptr doesn't have (no longer has) one.
In short, trying to support auto_ptr, shared_ptr, and weak_ptr will either
destroy the design, or make it stronger. :-)
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Thu, 30 Jan 2003 18:43:19 +0100, Daniel Frey [EMAIL PROTECTED] wrote: Gennaro Prota wrote: to avoid changes not forced by compiler bugs. Incidentally, I noticed that if you add a default argument templatetypename T static yes check(D const volatile *, T = 0); static no check(B const volatile *, int = 0); and write: sizeof(checkerB,D::check( (C()) /*, 0*/ )) then ambiguity problems arise, even with Comeau 4.3.0.1. Defect in the standard? What should the compiler deduce for T? Argument type deduction doesn't work well with default parameters. You are right. I was too heedless when looking at the compiler output: the word ambiguous was in `B' is an ambiguous base of `D' while I thought it was in some message referring to the function call. There were just too warning messages to distinguish the errors! :-) For the records, the warnings were about choosing C::operator const volatile D*() over C::operator const volatile B*() const for the call of no check(B const volatile *, int); There is already a DR (IIRC) that would allow: templatetypename T = int static yes check(D const volatile *, T = 0); but I don't know if any compilers implement it yet. Yes, it's the very same DR that requires introduction of default template arguments for function templates: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#226 Thanks, Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
From: David B. Held [EMAIL PROTECTED] David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... That is a very clean approach, and assuming it's OK to keep the the sole copy of p in storage_policy, even efficient. I'm not sure anyone would use a pointer that kept multiple copies of p. Wouldn't that make it pretty fat? shared_ptr keeps a copy of p in the ownership policy (the count structure.) Its storage policy (px) doesn't own the pointer. But I may be misunderstanding the context. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] auto_ptr/move issue
From: Howard Hinnant [EMAIL PROTECTED] Imho, standardized move syntax/semantics is very close to the top of important issues for C++. I guess that's why I'm pushing for current smart pointers to get the right syntax for move semantics. But can they get the right syntax without ? With , it's trivial. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
Peter Dimov [EMAIL PROTECTED] writes: In short, trying to support auto_ptr, shared_ptr, and weak_ptr will either destroy the design, or make it stronger. :-) Didn't we decide weak_ptr isn't a _ptr after all? If so, doesn't that get Dave off the hook for trying to support it using the smart_ptr facade? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible: rationale and wording
The technique I know relies on detecting whether the template argument
is *derived* from some policy, and that's doable with expressions.
That's why I asked you what was the exact technique you were using.
Also, if you have any (other) example where convertibility of a type
is needed I would be glad to see it, because this is IMHO a crucial
point.
Yes, it's really a derived from test, so is_base_and_derived would do I
guess. Which brings us back to things like:
template class I
struct is_bidirectional_iterator
{
private:
typedef typename std::iterator_traitsI::iterator_category cat;
public:
BOOST_STATIC_CONSTANT(bool, value = (::boost::is_convertiblecat*,
std::bidirectional_iterator_tag*::value));
};
BTW, in any case, you can always invent a variable in order to make the
test, likewise I don't think there are any situations where you have a
variable and not a type. Perhaps my main argument is philosophical: I
think that the current solution is well understood and easy to use, and it
*conceptually* fits in well with the other type traits. IMO a free function
is more like a code snippet that a packaged solution: but that is very much
a personal preference.
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
Maybe you had the following variation on Terje's code in mind. The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1: Hey, now that one really does work well, I'm still testing here (doesn't work with Borland, but I have a fallback position for that), but if there are no objections then you should expect to see the boost code updated soon. One question though - a lot of people seem to have worked on this: which people deserve the copyright/credit listing? Many thanks, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
--- John Maddock [EMAIL PROTECTED] wrote: One question though - a lot of people seem to have worked on this: which people deserve the copyright/credit listing? Rani only, IMO. Genny. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] A functional bind-ing exercice...
Somewhere in the E.U., le 31/01/2003
Bonjour
Given my recent (and now solved, thanks!) problems with the
Boost.Test framework and bind, I felt I needed some exercice. As I
believe this may be of interest to others, and do not know where to put
it where it can be found (perhaps included in bind's doc?), I will
reproduce it below (hoping this will not be a waste of bandwidth).
Encore merci!
HH
-- 8 8 --
// A simple exercice using funtional, function and bind...
#include iostream
#include functional
#include boost/bind.hpp
#include boost/function.hpp
void eater(::boost::function0void const snack)
{
::std::cout Eating a ;
snack();
}
void f()
{
::std::cout function of no parameters. ::std::endl;
}
void fn(int)
{
::std::cout normal function of one parameter. ::std::endl;
}
templatetypename T
void ft(int)
{
::std::cout templated function of one parameter. ::std::endl;
}
class A
{
public:
A(char const * blurb)
: wit(blurb)
{
}
void operator ()() const
{
::std::cout member function of no parameters of
wit . ::std::endl;
}
::std::string wit;
};
class AN
{
public:
AN(char const * blurb)
: wit(blurb)
{
}
void operator ()(int) const
{
::std::cout member function of one parameter of
wit (normal). ::std::endl;
}
::std::string wit;
};
templatetypename T
class AT
{
public:
AT(char const * blurb)
: wit(blurb)
{
}
void operator ()(int) const
{
::std::cout member function of one parameter of
wit (templated). ::std::endl;
}
::std::string wit;
};
int main(int argc, char * argv[])
{
eater(f);
eater(::boost::bind(fn, 1));
eater(::boost::bind(static_cast void (*) (int) (ftint), 1));
A a(a named instance of a class);
eater(::boost::bind(std::mem_fun_ref((A::operator ())), a));
eater(::boost::bind(std::mem_fun_ref((A::operator ())), A(an
anonymous instance of a class)));
ANan(a named instance of a class);
eater(::boost::bind(std::mem_fun_ref((AN::operator ())), an, 1));
eater(::boost::bind(std::mem_fun_ref((AN::operator ())), AN(an
anonymous instance of a class), 1));
ATint at(a named instance of a class);
eater(::boost::bind(std::mem_fun_ref((ATint::operator ())), at,
1));
eater(::boost::bind(std::mem_fun_ref((ATint::operator ())),
ATint(an anonymous instance of a class), 1));
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible: rationale and wording
The issue is not about creating objects or not but about what does it mean for a type to be convertible to another. Personally I have no idea what the meaning can be. Instead, the standard specifies what it means for an expression to be implicitly convertible to another: 4/3: An expression e can be implicitly converted to a type T if and only if the declaration ``T t=e;'' is wellformed, for some invented temporary variable t (8.5). [Incidentally: this is one of the few places in which the standard uses if and only if where if and only if is intended; in other places it just uses if :-( ] ~~~ Were, going round in circles here: the whole point of this thread was to clarify the wording, the suggested change was: value: defined to be true only if an imaginary lvalue of type From is implicitly-convertible to type To (4.0). Special conversions involving string-literals and null-pointer constants are not considered (4.2, 4.10 and 4.11). No function-parameter adjustments (8.3.5) are made to type To when determining whether From is convertible to To: this implies that a program is ill formed if type To is a function type, and that if type To is an array type, then value must necessarily evaluate to false. The expression is_convertibleFrom,To::value is ill-formed if: Type From, is a void or incomplete type (3.9). Type To, is not an object or reference type (3.9). The conversion is ambiguous, for example if type From has multiple base classes of type To (10.2). Type To is of class type and the conversion would invoke a non-public constructor of To (11.0 and 12.3.1). Type From is of class type and the conversion would invoke a non-public conversion operator of From (11.0 and 12.3.2). Which should pin it down IMO. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] any_cast issues
Joel de Guzman wrote:
Hmm... the same problem can be seen if you try
std::make_pair(1, 2);
the template parameters are deduces as char[1] and char[1], and there's no
much you can do with that type, not even copy it. That's the way template
argument deduction works, IIRC. I suggest that you change ctors of any and
any::holder to take value instead of reference, and tell what you got. Of
course, you should be able to say
boost::any test = static_castconst char*(Test me);
Yes, but a library can make it work. For instance, make_tuple(hello, , world)
works as expected. QOI matter?
I guess so. (Hmm.. I recall that the proposes solution for std::pair is to
make it accept value, not reference, and don't know the motivation, except
that this solution is the simplest)
// Arrays can't be stored as plain types; convert them to references.
templateclass T, int n
struct make_tuple_traits T[n] {
typedef const T (type)[n];
};
Wait a minute! If T[n] is converted to T[n], then it would mean
make_tuple(1, 2) and make_tuple(1, 23) will generate different
template specializations? I'd rather convert T[n] to T*, but probably I
miss something.
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible: rationale and wording
--- John Maddock [EMAIL PROTECTED] wrote:
The technique I know relies on detecting whether the template argument
is *derived* from some policy, and that's doable with expressions.
That's why I asked you what was the exact technique you were using.
Also, if you have any (other) example where convertibility of a type
is needed I would be glad to see it, because this is IMHO a crucial
point.
Yes, it's really a derived from test, so is_base_and_derived would do I
guess. Which brings us back to things like:
template class I
struct is_bidirectional_iterator
{
private:
typedef typename std::iterator_traitsI::iterator_category cat;
public:
BOOST_STATIC_CONSTANT(bool, value = (::boost::is_convertiblecat*,
std::bidirectional_iterator_tag*::value));
};
And I've already showed how to do this with expressions. With pointers you have
no problem at all: to see if T* is convertible to U* you see whether the
expression ((T*)(0)) is implictly convertible to U*.
Perhaps my main argument is philosophical
Frankly, and with no offense intended, I think it's just clutching at straws
:-)
I
think that the current solution is well understood
Uh?? Well understood??
and easy to use, and it
*conceptually*
Conceptually? Or formally?
fits in well with the other type traits. IMO a free function
is more like a code snippet that a packaged solution: but that is very much
a personal preference.
:-)
Genny.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] A functional bind-ing exercice...
From: Hubert Holin [EMAIL PROTECTED] eater(::boost::bind(std::mem_fun_ref((A::operator ())), a)); eater(a) is much simpler, I think. eater(::boost::bind(std::mem_fun_ref((AN::operator ())), an, 1)); eater(bind(an, 1)); ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
John Maddock [EMAIL PROTECTED] writes: Maybe you had the following variation on Terje's code in mind. The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1: Hey, now that one really does work well, I'm still testing here (doesn't work with Borland, but I have a fallback position for that), but if there are no objections then you should expect to see the boost code updated soon. One question though - a lot of people seem to have worked on this: which people deserve the copyright/credit listing? When you check it in, John, might I suggest you add an extensive comment about how it works? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
John Maddock [EMAIL PROTECTED] writes: Maybe you had the following variation on Terje's code in mind. The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1: Hey, now that one really does work well, I'm still testing here (doesn't work with Borland, but I have a fallback position for that), but if there are no objections then you should expect to see the boost code updated soon. One question though - a lot of people seem to have worked on this: which people deserve the copyright/credit listing? S... Somewhere back in this thread Peter Dimov raised a serious question about whether this implements the semantics we want. Was there ever agreement on that? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] gcc3.2, mpl::integral_c and enums
Hi, I'm having the following problem (?) with mpl::integral_c.
Since it is intended to encapsulate an Integral Constant,
I thought that it somewhat superseded BOOST_STATIC_CONSTANT.
IOWs, I figured that if I have something of the form:
struct X
{
BOOST_STATIC_CONSTANT( Type, ID = Val ) ;
} ;
it could be rewritten as:
struct X
{
mpl::integral_cType,Val ID ;
} ;
The benefit is that X::ID becomes a lot more usable on those compilers with
poor
non-type template parameter support.
Specifically, I designed the traits class of the Numeric Conversion Library
to expose mpl::integral_c and mpl::bool_c in place of BOOST_STATIC_CONSTANT
for its different value fields.
So, first of all, do you agree that the mpl form is better?
Unfortunately, while I was just about to release the library for formal
review,
I tested it with gcc3.2 and stumped into the following:
The conversion traits class exposes integral constant expressions of
_enumeration_ type;
however, according to my attempts, mpl::integral_c cannot be used with
enumeration types
on gcc3.2 as the following short test shows:
#includeiostream
#include boost/mpl/integral_c.hpp
enum LETTERS { a,b,c } ;
int main()
{
typedef boost::mpl::integral_cLETTERS,a A ;
LETTERS v = A::value ;
}
/cygdrive/c/boost/boost/boost/mpl/integral_c.hpp: In instantiation of
`boost::mpl::integral_cLETTERS, a':
/cygdrive/c/boost/boost/libs/numeric/conversion/test/short_test1.cpp:60:
instantiated from here
/cygdrive/c/boost/boost/boost/mpl/integral_c.hpp:56: invalid conversion from
`
int' to `LETTERS'
/cygdrive/c/boost/boost/boost/mpl/integral_c.hpp: In instantiation of
`boost::mpl::integral_cLETTERS, a':
/cygdrive/c/boost/boost/libs/numeric/conversion/test/short_test1.cpp:60:
instantiated from here
/cygdrive/c/boost/boost/boost/mpl/integral_c.hpp:57: invalid conversion from
`
int' to `LETTERS'
The errors show that the problem is related to the definition of next,prior:
typedef integral_cT, (value + 1) next;
typedef integral_cT, (value - 1) prior;
Solution:
There are two possibilities AFAICT:
(a) since there is int_c already, remove next/prior from integral_c
altoghether.
(b) add a special enum_c.
What do you think?
--
Fernando Cacciola
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
From: Gennaro Prota [EMAIL PROTECTED] --- John Maddock [EMAIL PROTECTED] wrote: One question though - a lot of people seem to have worked on this: which people deserve the copyright/credit listing? Rani only, IMO. I think so, too. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
From: Gennaro Prota [EMAIL PROTECTED] On Thu, 30 Jan 2003 15:13:19 +0100, Terje Slettebø [EMAIL PROTECTED] wrote: [...] Roughly speaking B is a base of D if and only if the base-specifier-list of D contains a class name for B or for a class of which B is a base. Of course you can see if that's the case by knowing the definition of D and examining an inheritance graph. And since that's what a compiler does all the time, is_base_and_derived is another thing that could be (ahehm) easily implemented as a built-in operator. True. But it's also detectable using C++98, as shown by Rani's proposal. One must be *extremely careful* when making such an assertion. In the following part of the posting, I said that if it turns out it doesn't work correctly, then... We may understand how it works and have a few test cases, but that's not a big guarantee. C++ is a _very_ complex language, and all sorts of conversions can appear wherever you expect them the less. The fact that we don't see any leak in Rani's code doesn't mean that it there isn't. Probably, a week ago we were all enough convinced that it wasn't possible to detect a private base without causing an access error. No. You can't prove a negative, an impossibility. You can't prove that something can't be done. You can, however, prove that something can be done. You use an analogy later here, and I can come with one, as well: No matter how many black crows you find, you can't prove that there can never be a white crow. Only one white crow is enough to prove that there can be a white crow. And if we were convinced about that and were wrong, then we could be wrong now by thinking that the code works. Like I said, I've never said that this has been _proven_. You seem to be jumping the gun a little, here. Like I said in the posting, I'm not arguing whether or not there should be built-in language support for this. I've just pointed out some consequences of either approach. Let me make a little digression: the great Adrien Marie Legendre once proved that there doesn't exist any couple of rational numbers x and y such that: x**3 + y**3 = 6 It then happened that Henry Ernest Dudeney published a solution with only two digits in the numerator and the denominator of both fractions: 17/21 and 37/21 My point exactly: Adrien Marie Legendre tried to prove a negative. Now, you will agree with me that Legendre was all but a dumb. And he even had a proof. As was shown with your example, this was not a logically valid proof. If you want another example: when Whiles published his first demonstration of the last theorem of Fermat he was sure the proof was right, but an error was found by the reviewers. Then he made some changes and no error has been found so far. Now, the point of this rigmarole is not that we must proof any assertion concerning C++ (we are programmers not mathematician) but that we must be careful and modest; everybody makes error and the fact that experts are less likely to make errors is just an illusion: They may be less likely to make obvious mistakes. This goes for any field. This is analogous to the advantages of a four-wheel drive car: It lets you get stuck in inaccessible places. :) You may drive where normal cars can't go, but if you get stuck, you may need a helicopter to get out. :) You make this point in the following, as well. the complexity limit of what you get right is just shifted a little further on: you are more exercised but there's a limit (higher than the limit of a beginner) after you are, to say, in foggy land too. In the case of Whiles, the demonstration is so complex that not even an expert can state, with a reasonable certainty, that it is correct. As to C++, a number of experts certainly thought, with reasonable certainty, that the specification was correct but then we have a list of hundreds of defects. And some of those defects are on *fundamental* aspects of the language. Also some of them, e.g. issue 200, are simply incredible for their simplicity. The fact that after 2 years it hasn't been solved yet means that it is *too* complex, even for the committee experts. There's no offense intended in my words. I think everybody should be fair enough to admit that. Sometimes the committee likes to venture out to sea, probably because they are fun of the language just like me and you (more on this later) Genny, have I ever said that Rani's proposal has been _proven_ to work? I have not. I _explicitly_ said that it could be hard to do that, but it might be possible. What I said is that it works, i.e. we haven't found a case where it doesn't work. I have _not_ stated that this has been _proven_ to work. I know about mathematical and logical formalisms, as well, and I know there may be a long way from empirical evidence, to actual proof. This doesn't mean that, as you say yourself here, that if something turns out to work, even if it may not have
Re: [boost] auto_ptr/move issue
On Friday, January 31, 2003, at 07:26 AM, Peter Dimov wrote: From: Howard Hinnant [EMAIL PROTECTED] Imho, standardized move syntax/semantics is very close to the top of important issues for C++. I guess that's why I'm pushing for current smart pointers to get the right syntax for move semantics. But can they get the right syntax without ? Close. With , it's trivial. Agreed. The right syntax for move, imho, is anything but copy syntax if the source is an lvalue. If the source is an rvalue, then copy syntax for move is not only ok, it is actually desirable. move_ptrint source(); ... move_ptrint i(source()); // move with copy syntax from rvalue, ok. move_ptrint j(i); // error, move with copy syntax from lvalue, bad! move_ptrint k(move(i)); // move with move syntax from lvalue, ok. This much can be achieved in C++98. It is not trivial, indeed it is a pita compared to how easy it should be. All you have to do is follow the auto_ptr design. Doing so does not get you all of the nice things that a language driven move would get you (like movable objects in general, containers that can hold non-copyable but movable objects, etc.). But you *can* get away from moving with copy syntax from lvalues! I presented code under the thread SmartPtr (Loki) - auto_ptr/move c'tor issue on Jan. 28 which does this. For easy reference, here is the code again, slightly improved: http://home.twcny.rr.com/hinnant/Utilities/move_ptr This move_ptr example also provides array support, but names it move_ptrT[] instead of move_ptr_array. This is a separate issue and has nothing to do with getting the right syntax for a move ptr. So you can just ignore that part if your platform doesn't support pts. -Howard PS: There are no copyrights on this code sample, that is intentional. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] Didn't we decide weak_ptr isn't a _ptr after all? If so, doesn't that get Dave off the hook for trying to support it using the smart_ptr facade? That will be my excuse, anyway. I'll just say that weak_ptr ought to be a separate type altogether. ;) Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
From: David Abrahams [EMAIL PROTECTED] John Maddock [EMAIL PROTECTED] writes: Maybe you had the following variation on Terje's code in mind. The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1: Hey, now that one really does work well, I'm still testing here (doesn't work with Borland, but I have a fallback position for that), but if there are no objections then you should expect to see the boost code updated soon. One question though - a lot of people seem to have worked on this: which people deserve the copyright/credit listing? S... Somewhere back in this thread Peter Dimov raised a serious question about whether this implements the semantics we want. Was there ever agreement on that? As I mentioned in an earlier posting, Rani's proposal does what the current docs on is_base_and_derived says. It doesn't mandate public, unambiguous base class. If one wants that semantic, then perhaps another trait could be useful for it. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
From: Terje Slettebø [EMAIL PROTECTED] From: David Abrahams [EMAIL PROTECTED] S... Somewhere back in this thread Peter Dimov raised a serious question about whether this implements the semantics we want. Was there ever agreement on that? As I mentioned in an earlier posting, Rani's proposal does what the current docs on is_base_and_derived says. It doesn't mandate public, unambiguous base class. If one wants that semantic, then perhaps another trait could be useful for it. Or, change the description in the docs to reflect the semantics of the current version. Either one or the other needs to be done, I think, because as it stands, the description doesn't match the current implementation. So either we change the map, or change the terrain. :) Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
Peter Dimov [EMAIL PROTECTED] wrote in message 009501c2c923$b4de48a0$1d00a8c0@pdimov2">news:009501c2c923$b4de48a0$1d00a8c0@pdimov2... [...] shared_ptr keeps a copy of p in the ownership policy (the count structure.) Its storage policy (px) doesn't own the pointer. But I may be misunderstanding the context. Well, if *I* understand correctly, you have a fat count. But since it is shared among pointers, it's a constant cost per object. I thought Dave A was talking about storing p multiple times *per pointer*. That's what I thought was really fat. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
Terje Slettebø wrote: You can't prove a negative, an impossibility. Can you prove that? ;) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
Peter Dimov [EMAIL PROTECTED] wrote in message
004f01c2c921$aae010b0$1d00a8c0@pdimov2">news:004f01c2c921$aae010b0$1d00a8c0@pdimov2...
From: David B. Held [EMAIL PROTECTED]
smart_ptr(P p)
: storage(p), ownership(p), checking(), conversion()
{ checking::on_init(p) }
smart_ptr(P p)
: storage(p), ownership(p), checking(p), conversion()
{}
is nicer. Maybe even conversion(p), for consistency. :-)
Well, if you want consistency, on_init(p) is better. ;) Technically,
one could argue that you might want checking to occur *after* the
other policy c'tors have completed.
But that's not what I have in mind. There are a number of pitfalls
awaiting you.
Tell me something new. :(
Consider the converting move constructor:
smart_ptr(smart_ptr rhs)
: storage(rhs), ownership(rhs), checking(rhs), conversion(rhs)
{}
Its purpose is to take ownership away from the auto_ptr-like rhs
(you wanted to support that) and construct a counted_ptr.
Hmm...I'm not so sure about constructing a ref-counted pointer from
a move pointer. That's an interesting idea that I hadn't really
considered. I'm not sure whether it's a good idea to allow that or
not. It might encourage indiscriminate mixing of pointer types.
As storage is constructed first, it needs to move from rhs.storage;
now when ownership throws, rhs.storage will be left empty, and the
object is gone. This is not that big of a problem... provided that the
other rhs policies can handle storage being zeroed.
They'd better be able to handle this, since is this is what would
happen in the *non-exceptional* case as well. However, the other
policies had better not be able to tell whether or not storage is zeroed,
or we have lost orthogonality.
A more interesting related problem involves what to do when
transferring a managed resource. When tranferring an unmanaged
resource, you have to clean it up on an exception, just to get the
basic guarantee. However, when moving from a managed pointer,
cleaning up will only *get* you the basic guarantee. To get the
strong guarantee, you need to *move the resource back*. This is a
tricky situation that might be a good argument to not support move
semantics. ;) Or maybe the strong guarantee isn't important for this.
I dunno. Comments?
[...]
In short, trying to support auto_ptr, shared_ptr, and weak_ptr will
either destroy the design, or make it stronger. :-)
Well, considering there isn't a configuration of the runtime Borg for
weak_ptr, I wouldn't feel too bad not supporting it internally.
Besides, weak_ptr isn't even smart to begin with. ;) We'll cover
that with a policy-based DumbPtr. ;
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: auto_ptr/move issue
Howard Hinnant [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] I presented code under the thread SmartPtr (Loki) - auto_ptr/move c'tor issue on Jan. 28 which does this. For easy reference, here is the code again, slightly improved: http://home.twcny.rr.com/hinnant/Utilities/move_ptr [...] This looks suspiciously like Mojo. Could you describe the differences? Or would you say that Mojo also achieves the same goals? I would like to support Mojo in SmartPtr, but I think we would all like to help people not abuse it. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: A functional bind-ing exercice...
From: Hubert Holin [EMAIL PROTECTED] Somewhere in the E.U., le 31/01/2003 In article 00d801c2c927$8d06dd20$1d00a8c0@pdimov2, Peter Dimov [EMAIL PROTECTED] wrote: From: Hubert Holin [EMAIL PROTECTED] eater(::boost::bind(std::mem_fun_ref((A::operator ())), a)); eater(a) is much simpler, I think. Indeed! eater(::boost::bind(std::mem_fun_ref((AN::operator ())), an, 1)); eater(bind(an, 1)); Doesn't work (with MWCWPro 8.3, at least), giving me the error: Error : 'result_type' is not a member of class 'AN' My mistake. bind needs a result_type typedef in AN to determine the return type of its operator(). The alternative is to supply it explicitly: bindvoid(an, 1)). ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Fri, 31 Jan 2003 08:27:25 -0500, David Abrahams [EMAIL PROTECTED] wrote: S... Somewhere back in this thread Peter Dimov raised a serious question about whether this implements the semantics we want. Was there ever agreement on that? Who cares? The new toy is so cool! :-) Seriously, Peter is a wise man. Personally I would go with his suggestion about having two (or more) separate metafunctions, at least for the sake of generality, and to allow people to experiment with the new semantics. I hope nobody will then come out asking for is_ambiguous_and_anyway_protected_base_class is_ambiguous_with_at_least_one_private_base_class is_ambiguous_with_one_private_and_three_indirect_protected_... ... sigh... :-) Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
Terje Slettebø [EMAIL PROTECTED] writes: No. You can't prove a negative, an impossibility. I think that's wrong, and here's my one white crow to prove it ;-) I can prove that there can never exist a positive integral multiple of 2 which is both greater than 2 and prime. It's the same as saying that *every* positive integral multiple of 2 which is greater than 2 is a non-prime (now it's not a negative statement anymore, but it is logically equivalent). The positive integral multiples of 2 which are not greater than 2 are: 2. Since every other positive integral multiple of 2 is divisible by both 2 and itself, it must be non-prime. QED, or whatever it is you say while gleefully dancing on the logical grave of your vanquished opponent wink. But anyway, isn't this straying a little bit far from being on-topic? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: auto_ptr/move issue
David B. Held [EMAIL PROTECTED] writes: Howard Hinnant [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] I presented code under the thread SmartPtr (Loki) - auto_ptr/move c'tor issue on Jan. 28 which does this. For easy reference, here is the code again, slightly improved: http://home.twcny.rr.com/hinnant/Utilities/move_ptr [...] This looks suspiciously like Mojo. Why suspiciously? Both Mojo and Howard's move_ptr followed the design of std::auto_ptr. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
David B. Held [EMAIL PROTECTED] writes: Peter Dimov [EMAIL PROTECTED] wrote in message 009501c2c923$b4de48a0$1d00a8c0@pdimov2">news:009501c2c923$b4de48a0$1d00a8c0@pdimov2... [...] shared_ptr keeps a copy of p in the ownership policy (the count structure.) Its storage policy (px) doesn't own the pointer. But I may be misunderstanding the context. Well, if *I* understand correctly, you have a fat count. But since it is shared among pointers, it's a constant cost per object. I thought Dave A was talking about storing p multiple times *per pointer*. That's what I thought was really fat. Yes, that's what I meant, and I wasn't suggesting that you do it. I meant that if your other design choices weren't forcing you to do it, you probably had a pretty efficient smart_ptr. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
David B. Held [EMAIL PROTECTED] writes:
smart_ptr(smart_ptr rhs)
: storage(rhs), ownership(rhs), checking(rhs), conversion(rhs)
{}
Its purpose is to take ownership away from the auto_ptr-like rhs
(you wanted to support that) and construct a counted_ptr.
Hmm...I'm not so sure about constructing a ref-counted pointer from
a move pointer. That's an interesting idea that I hadn't really
considered. I'm not sure whether it's a good idea to allow that or
not. It might encourage indiscriminate mixing of pointer types.
If you want to subsume the current shared_ptr and auto_ptr you'd
better handle it.
There are other ways to prevent indiscriminate mixing (an orthogonal
interoperability policy, perhaps?)
As storage is constructed first, it needs to move from rhs.storage;
now when ownership throws, rhs.storage will be left empty, and the
object is gone. This is not that big of a problem... provided that the
other rhs policies can handle storage being zeroed.
They'd better be able to handle this, since is this is what would
happen in the *non-exceptional* case as well. However, the other
policies had better not be able to tell whether or not storage is zeroed,
or we have lost orthogonality.
A more interesting related problem involves what to do when
transferring a managed resource. When tranferring an unmanaged
resource, you have to clean it up on an exception, just to get the
basic guarantee.
Not quite. You have to clean it up on exception in order to be
usable, or for certain expressions outside the constructor itself to
give the basic guarantee, e.g.:
smart_ptrT x(new T);
If you leak the T in that case, the constructor still gives the basic
guarantee. Allow me to demonstrate:
std::auto_ptrT x(new T);
smart_ptrT y(x.get());
x.release();
smart_ptrT's constructor gives the basic (and strong) guarantee in
both cases. In principle you don't have to promise to delete the
unmanaged resource if your constructor throws; it's just your desire
to be usable with new T that makes it neccessary.
In fact, I have been arguing for years that our smart pointers should
never have had a public interface which adopts unmanaged resources on
construction. Instead, we should write:
std::auto_ptrT = std::auto_ptr_newT(arg1, arg2, arg3);
Voila, a managed T straight out of the box.
However, the desire to subsume existing smart pointers means you have
to support the unsafe unmanaged adoption interface.
However, when moving from a managed pointer, cleaning up will only
*get* you the basic guarantee. To get the strong guarantee, you
need to *move the resource back*. This is a tricky situation that
might be a good argument to not support move semantics. ;) Or maybe
the strong guarantee isn't important for this. I dunno. Comments?
The move proposal says that standard components will require the move
construct/assign of their UDT parameters, if any, to be nothrow. In
practice that would be needed by any generic components. That's
enough to make the move undo-able.
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
Gennaro Prota [EMAIL PROTECTED] writes: On Fri, 31 Jan 2003 08:27:25 -0500, David Abrahams [EMAIL PROTECTED] wrote: S... Somewhere back in this thread Peter Dimov raised a serious question about whether this implements the semantics we want. Was there ever agreement on that? Who cares? The new toy is so cool! :-) Seriously, Peter is a wise man. Personally I would go with his suggestion about having two (or more) separate metafunctions, at least for the sake of generality I'd rather settle on one for the sake of simplicity and see if it's enough for people. Once you provide two interfaces, you're sort of stuck supporting them both. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
At 09:53 AM 1/31/2003, David Abrahams wrote: ... In fact, I have been arguing for years that our smart pointers should never have had a public interface which adopts unmanaged resources on construction. Instead, we should write: std::auto_ptrT = std::auto_ptr_newT(arg1, arg2, arg3); Voila, a managed T straight out of the box. And I proposed something like this years before that, but foundered on not being able to declare a type-safe variadic function in C++. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
From: David Abrahams [EMAIL PROTECTED] Terje Slettebø [EMAIL PROTECTED] writes: No. You can't prove a negative, an impossibility. I think that's wrong, and here's my one white crow to prove it ;-) I can prove that there can never exist a positive integral multiple of 2 which is both greater than 2 and prime. It's the same as saying that *every* positive integral multiple of 2 which is greater than 2 is a non-prime (now it's not a negative statement anymore, but it is logically equivalent). The positive integral multiples of 2 which are not greater than 2 are: 2. Since every other positive integral multiple of 2 is divisible by both 2 and itself, it must be non-prime. Ok, so you can do it in a field where you decide on all the rules, such as maths. I was more thinking in terms of if you don't have all the facts. For example, many thought it was impossible to fly, and perhaps constructed proofs for it, using their available knowledge. However, it turned out to be possible, anyway, in a way they may not have known about. However, since the topic was whether it was possible to prove that you could not detect inheritance without an access violation, I guess that might be provable, as well, since you may decide on the logic used in the implementation. So it seems you're right. But anyway, isn't this straying a little bit far from being on-topic? It is. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
David Abrahams wrote: Who cares? The new toy is so cool! :-) Seriously, Peter is a wise man. Personally I would go with his suggestion about having two (or more) separate metafunctions, at least for the sake of generality I'd rather settle on one for the sake of simplicity and see if it's enough for people. Once you provide two interfaces, you're sort of stuck supporting them both. I agree. And we should keep in mind that people can use trivial combination anyway, so we needn't offer them all with separate names/interfaces, e.g. is_base_and_derived B, D ::value || is_void B ::value is easy enough for users, so if they want to use void as a base for all classes, they can do it that way. All we need to do is to provide very good documentation. Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
Greg Colvin [EMAIL PROTECTED] writes: At 09:53 AM 1/31/2003, David Abrahams wrote: ... In fact, I have been arguing for years that our smart pointers should never have had a public interface which adopts unmanaged resources on construction. Instead, we should write: std::auto_ptrT = std::auto_ptr_newT(arg1, arg2, arg3); Voila, a managed T straight out of the box. And I proposed something like this years before that, but foundered on not being able to declare a type-safe variadic function in C++. The move/forwarding proposals will fix that. In the meantime we have boost::ref(x)... ugly but effective. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: auto_ptr/move issue
Howard Hinnant [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] *** * * * Do not move from an lvalue with copy syntax. * * * *** Howard, I'd appreciate it if you stopped beating around the bush, and just say what you're trying to say. All these subtle games are too much for me. ; [...] To implement the sample C++98 move_ptr, I literally started with auto_ptr source and just disabled the copy from lvalue by making it private, and then shook what was left around until it passed a few simple unit tests. It is just a proof of concept that you don't have to move with copy syntax in C++98. So, if I understand you correctly, the relevant translation of Howard's Principle for move_ptr is: *** * * Do not allow move_ptr(move_ptr) or operator=(move_ptr) * *** If so, that is the important piece of info I needed. I suppose that declaring move_ptr(move_ptr const) private, and not declaring move_ptr(move_ptr) at all has the same effect. So it seems that Mojo observes Howard's Principle. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] named template parameters using mpl
Hi,
There's an nice implementation of the NTP in boost-sandbox, which follows the idea in
the book C++ Templates. But we have to repeat the definitions the feature_is
classes with virtual inheritance and some typedefs all the time. I wonder if we can
make it eaiser.
Taking the test car class in the boost-sandbox.ntp as an example, I'd like just to
write:
// requires no definitions
template typename T struct Model_is;
template typename T struct Color_is;
template typename T struct Seats_is;
template typename T struct Transmission_is;
then we can easily implement the car class like this:
template class Model = ntp::nil,
class Color = ntp::nil,
class Seats = ntp::nil,
class Transmission = ntp::nil
class car {
// the default template arguments
typedef typename boost::mpl::vector4
Model_isgl, Color_isred, Seats_isleather, Transmission_isautomatic
default_features;
// all setters
typedef typename boost::mpl::vector4Model, Color, Seats, Transmission setters;
// update the default arguments
typedef typename ntp::updatedefault_features, setters::type features;
// the named parameters are accessible through the 'features' type
typedef typename ntp::extractfeatures, Model_is::type model;
typedef typename ntp::extractfeatures, Color_is::type color;
typedef typename ntp::extractfeatures, Seats_is::type seats;
typedef typename ntp::extractfeatures, Transmission_is::type transmission;
//...
};
The default features(types) are stored in a type-vector, and we can use boost.mpl to
update the default features into use-defined ones, and to extract the updated
paramters from type-vector. Then we can use NTPs later. And even can we mix the NTPs
and the ordinary paramters, just to use ntp::update2 instead of ntp::update.
The problems I've come across mainly on the lambda support of mpl. I tried to use
boost::mpl::fold to implement the update template, but failed to compile with bcc
5.6(all is ok with gcc 3.2). And as the template template parameters are used, I
wonder if any workaround for VC6. The alternative should be more convenient, but might
take more time to compile, and less portable.
I've tried an implementation, and have uploaded it to http://www.c-view.org/ntp.zip.
It's beeen tested with Borland C++ Compiler 5.6 and gcc 3.2. The files in the zip
package are:
test.cppexample of NTPs
test2.cpp example of mixed use of NTPs and ordinary paramters
ntp.hpp NTP
ntp2.hppfor mixed use of NTPs and ordinary paramters
Thanks very much for review.
The Chinese Spring Festival is coming. I wish every booster well and happy in the new
year. And a Chinese congratulatory saying:
Lucky Money!
Jonathan Wang
[EMAIL PROTECTED]
2003-02-01
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
Greg Colvin [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] And I proposed something like this years before that, but foundered on not being able to declare a type-safe variadic function in C++. Do you suppose that with the PP lib, we should try something like this now? If I understand correctly, we should be able to offer both unmanaged and managed construction, right? That way, we retain legacy compatibility, while offering users a safer way to use smart pointers. I'll bet this is just the type of challenge that Paul Mensonides would like to take on. ; Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Fri, 31 Jan 2003 16:15:49 +0100, Terje Slettebø [EMAIL PROTECTED] wrote: From: Gennaro Prota [EMAIL PROTECTED] On Thu, 30 Jan 2003 15:13:19 +0100, Terje Slettebø [EMAIL PROTECTED] wrote: [...] Roughly speaking B is a base of D if and only if the base-specifier-list of D contains a class name for B or for a class of which B is a base. Of course you can see if that's the case by knowing the definition of D and examining an inheritance graph. And since that's what a compiler does all the time, is_base_and_derived is another thing that could be (ahehm) easily implemented as a built-in operator. True. But it's also detectable using C++98, as shown by Rani's proposal. One must be *extremely careful* when making such an assertion. In the following part of the posting, I said that if it turns out it doesn't work correctly, then... Ok. But in the text above you say that it is detectable, and that Rani's proposal shows that. Then you say: if it turns out that it isn't detectable... :-) (I hope you don't mind if I joke a bit about the issue...) We may understand how it works and have a few test cases, but that's not a big guarantee. C++ is a _very_ complex language, and all sorts of conversions can appear wherever you expect them the less. The fact that we don't see any leak in Rani's code doesn't mean that it there isn't. Probably, a week ago we were all enough convinced that it wasn't possible to detect a private base without causing an access error. No. You can't prove a negative, an impossibility. Out of context this is a meaningless sentence. Taking it easy however, that's more-or-less what I wanted to say with the sentence that starts with We may 'understand' how it works and have a few test cases You have simply repeated that and objected to the less strict part, the one that starts with maybe..., which is rather a light comment intended, to say, to get a moral from the story. I'm used to say that if you find an error (or a flaw, or a defect) in something you can usually be reasonably sure that an error effectively exists; if you find none, than you can't say that it is error free. Note the words usually and reasonably; the first part isn't certain either (you may find an error and then realize that it isn't). That's, after all, common knowledge in scienze; as A. Einstein said with a hyperbole: No amount of experimentation can ever prove me right; a single experiment can prove me wrong You can't prove that something can't be done. You can, however, prove that something can be done. What you have proved that can be done? That on compiler xyz, kfg and xmn, the provided test cases give the expected result. Nothing ensures e.g. that in a more complex case it works as well. Now my last sentence is a little exaggerated, of course, but it's there to object your dangerous sentence prove that something can be done. Such general meaning sentences are typical when one tries to argue his position, and all in all aren't wrong. But then the interlocutor immediately applies them to the case at hand (in this code, the code we are talking about) and cheats on the meaning of some words: in this case you could have cheated (or someone could have been) about the word something, saying then that you have proved that detection of any base, accessible or not, can be done. What you have proved, instead, is that detection with the tested compilers, and with the tested cases, is possible. You use an analogy later here, and I can come with one, as well: No matter how many black crows you find, you can't prove that there can never be a white crow. Only one white crow is enough to prove that there can be a white crow. Out of curiosity: did you read Martin Gardner's books, or his Scientific American articles? And if we were convinced about that and were wrong, then we could be wrong now by thinking that the code works. Like I said, I've never said that this has been _proven_. You seem to be jumping the gun a little, here. Eheheheh... nice idiom :-) No, I wasn't jumping the gun. If you read a little back, you will see that everything started from your assertion that detecting if B is a base of D is doable using C++98, as shown by Rani's proposal. Had you put, for instance, a maybe in that sentence I wouldn't have even replied. Furthermore the objection was just to that sentence; I didn't say you were arguing against built-in support. I said that the C++ 98 solution, *the one detecting ambiguous and private bases too* (if that's what we want), is almost a miracle, a latest news discovery which we still don't know well, where as the built-in solution is something so trivial to implement that it will probably take less time to the committee to specify and less time to the compiler writer to implement. Like I said in the posting, I'm not arguing whether or not there should be built-in language support for this. I've just pointed out some consequences of either approach. Yes, I
Re: [boost] Re: is_base_and_derived question
From: Daniel Frey [EMAIL PROTECTED] David Abrahams wrote: Who cares? The new toy is so cool! :-) Seriously, Peter is a wise man. Personally I would go with his suggestion about having two (or more) separate metafunctions, at least for the sake of generality I'd rather settle on one for the sake of simplicity and see if it's enough for people. Once you provide two interfaces, you're sort of stuck supporting them both. I agree. And we should keep in mind that people can use trivial combination anyway, so we needn't offer them all with separate names/interfaces, e.g. is_base_and_derived B, D ::value || is_void B ::value is easy enough for users, so if they want to use void as a base for all classes, they can do it that way. All we need to do is to provide very good documentation. This may solve the issue of how or whether to support the semantics of the current implementation. That may be something like: is_base_and_derivedB, D::value is_convertibleD, B::value Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Fri, 31 Jan 2003 12:14:09 -0500, David Abrahams [EMAIL PROTECTED] wrote: I'd rather settle on one for the sake of simplicity and see if it's enough for people. Once you provide two interfaces, you're sort of stuck supporting them both. Well, then I imagine you would prefer the old semantics. Was there anybody complaining that being not enough? Maybe however it would be nice to see if we find an use for the new semantics. I don't know what it could be but probably knowing that private or ambiguous base classes are detectable without errors will encourage someone to find an use for that. This wouldn't certainly be a new experience for C++, since it has happened with templates or e.g. with function call expressions as operand of sizeof. Similarly knowing widely unknown rules about conversion ranking allowed Rani to find their application. In fact, the 'old' version is implementable in terms of the new one, but not with compilers that can't digest the latter, of course. The maintenance/supporting burden you refer to seems mainly due to broken compilers :-/ Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] gcc3.2, mpl::integral_c and enums
Fernando Cacciola [EMAIL PROTECTED] writes:
Hi, I'm having the following problem (?) with mpl::integral_c.
Since it is intended to encapsulate an Integral Constant,
I thought that it somewhat superseded BOOST_STATIC_CONSTANT.
IOWs, I figured that if I have something of the form:
struct X
{
BOOST_STATIC_CONSTANT( Type, ID = Val ) ;
} ;
it could be rewritten as:
struct X
{
mpl::integral_cType,Val ID ;
} ;
struct X
{
typedef mpl::integral_cType,Val ID ;
} ;
, maybe.
The benefit is that X::ID becomes a lot more usable on those
compilers with poor non-type template parameter support.
Specifically, I designed the traits class of the Numeric Conversion Library
to expose mpl::integral_c and mpl::bool_c in place of BOOST_STATIC_CONSTANT
for its different value fields.
So, first of all, do you agree that the mpl form is better?
It's better, but maybe not for the reasons you think ;-). [It has
to do with metafunction/metadata polymorphism]
Unfortunately, while I was just about to release the library for
formal review, I tested it with gcc3.2 and stumped into the
following:
snip
The errors show that the problem is related to the definition of next,prior:
typedef integral_cT, (value + 1) next;
typedef integral_cT, (value - 1) prior;
Solution:
There are two possibilities AFAICT:
(a) since there is int_c already, remove next/prior from integral_c
altoghether.
(b) add a special enum_c.
I think the fix is much easier than either of those:
typedef integral_cT, static_castT(value + 1) next;
typedef integral_cT, static_castT(value - 1) prior;
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] named template parameters using mpl
[Please allow me to suggest that you turn on line wrapping in your
mailer. Most of your paragraphs were just one line]
Jonathan Wang [EMAIL PROTECTED] writes:
Hi,
There's an nice implementation of the NTP in boost-sandbox, which
follows the idea in the book C++ Templates. But we have to repeat
the definitions the feature_is classes with virtual inheritance
and some typedefs all the time. I wonder if we can make it eaiser.
Taking the test car class in the boost-sandbox.ntp as an example,
I'd like just to write:
// requires no definitions
template typename T struct Model_is;
template typename T struct Color_is;
template typename T struct Seats_is;
template typename T struct Transmission_is;
then we can easily implement the car class like this:
template class Model = ntp::nil,
class Color = ntp::nil,
class Seats = ntp::nil,
class Transmission = ntp::nil
class car {
// the default template arguments
typedef typename boost::mpl::vector4
Model_isgl, Color_isred, Seats_isleather, Transmission_isautomatic
default_features;
// all setters
typedef typename boost::mpl::vector4Model, Color, Seats, Transmission
setters;
// update the default arguments
typedef typename ntp::updatedefault_features, setters::type features;
// the named parameters are accessible through the 'features' type
typedef typename ntp::extractfeatures, Model_is::type model;
typedef typename ntp::extractfeatures, Color_is::type color;
typedef typename ntp::extractfeatures, Seats_is::type seats;
typedef typename ntp::extractfeatures, Transmission_is::type transmission;
//...
};
The default features(types) are stored in a type-vector, and we can
use boost.mpl to update the default features into use-defined ones,
and to extract the updated paramters from type-vector. Then we can
use NTPs later. And even can we mix the NTPs and the ordinary
paramters, just to use ntp::update2 instead of ntp::update.
Nifty, Nifty, Nifty!!!
The problems I've come across mainly on the lambda support of mpl. I
tried to use boost::mpl::fold to implement the update template,
but failed to compile with bcc 5.6(all is ok with gcc 3.2). And as
the template template parameters are used, I wonder if any
workaround for VC6. The alternative should be more convenient, but
might take more time to compile, and less portable.
Broken compilers like VC and Borland require a little bit of help in
user-defined metafunctions.
See
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/boost/python/detail/indirect_traits.hpp?rev=HEADcontent-type=text/plain
and look for uses of BOOST_MPL_AUX_LAMBDA_SUPPORT.
I've tried an implementation, and have uploaded it to http://www.c-view.org/ntp.zip.
It's beeen tested with Borland C++ Compiler 5.6 and gcc 3.2. The files in the zip
package are:
test.cpp example of NTPs
test2.cpp example of mixed use of NTPs and ordinary paramters
ntp.hpp NTP
ntp2.hppfor mixed use of NTPs and ordinary paramters
Very exciting!
Thanks very much for review.
The Chinese Spring Festival is coming. I wish every booster well and
happy in the new year. And a Chinese congratulatory saying:
Lucky Money!
Thank you very much!
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Fri, 31 Jan 2003 19:30:09 +0100, Gennaro Prota [EMAIL PROTECTED] wrote: This wouldn't certainly be a new experience for C++, since it has happened with templates or e.g. with function call expressions as operand of sizeof. Well, I meant that 'additional' usages for templates were found, beyond the purpose they were invented for. Not that their use was found late :-) Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] gcc3.2, mpl::integral_c and enums
David Abrahams [EMAIL PROTECTED] writes: I think the fix is much easier than either of those: typedef integral_cT, static_castT(value + 1) next; typedef integral_cT, static_castT(value - 1) prior; Could you try that and see if it works? Thanks, Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Tue, 28 Jan 2003 19:41:09 +0200, Peter Dimov [EMAIL PROTECTED] wrote: I've always felt that is_base_and_derived is a funny name. Just to have a moment of recreation before resuming work... it looks funny to me too, but for another reason. To an Italian it creates a strange effect to have is (singular) and the conjunction and between the names; off-hand one wonders: How *is* ? Maybe they meant *are* base and derived? :-) However after the initial shock, I've mentally mapped it to something along the lines of is the couple (B, D) of the form (base, derived)? Not that one can really put down in words a mental association, but it's more or less something like that :-) Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: gcc3.2, mpl::integral_c and enums
David Abrahams [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Fernando Cacciola [EMAIL PROTECTED] writes:
Hi, I'm having the following problem (?) with mpl::integral_c.
Since it is intended to encapsulate an Integral Constant,
I thought that it somewhat superseded BOOST_STATIC_CONSTANT.
IOWs, I figured that if I have something of the form:
struct X
{
BOOST_STATIC_CONSTANT( Type, ID = Val ) ;
} ;
it could be rewritten as:
struct X
{
mpl::integral_cType,Val ID ;
} ;
struct X
{
typedef mpl::integral_cType,Val ID ;
} ;
, maybe.
Yes, :-)
The benefit is that X::ID becomes a lot more usable on those
compilers with poor non-type template parameter support.
Specifically, I designed the traits class of the Numeric Conversion
Library
to expose mpl::integral_c and mpl::bool_c in place of
BOOST_STATIC_CONSTANT
for its different value fields.
So, first of all, do you agree that the mpl form is better?
It's better, but maybe not for the reasons you think ;-). [It has
to do with metafunction/metadata polymorphism]
Also...
It is a burden to deal with X::value in bcc5.5.1 because you need to fully
qualify X,
but not for X::type, do given that many metafunctions accept mpl's forms
already,
it is better if only for this reason.
I think the fix is much easier than either of those:
typedef integral_cT, static_castT(value + 1) next;
typedef integral_cT, static_castT(value - 1) prior;
Of course! I've tried many _other_ casts (for 'value' and '1' individually),
but not this one...
It works now!
--
Fernando Cacciola
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
David Abrahams [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[...]
If you want to subsume the current shared_ptr and auto_ptr you'd
better handle it.
Ok, point taken.
There are other ways to prevent indiscriminate mixing (an orthogonal
interoperability policy, perhaps?)
Actually, you can control mixing by determining which policies can be
constructed from which other policies. I just didn't know if it was a
good idea to let users freely mix auto_ptr with shared_ptr. But I
suppose if they get an auto_ptr from legacy code, and they want it to be
managed by shared_ptr, that is a legitimate use.
[...]
In principle you don't have to promise to delete the unmanaged
resource if your constructor throws; it's just your desire to be
usable with new T that makes it neccessary.
Ok, I think I get it. Whereas, if a policy were to throw, and leak an
internally allocated count, then the c'tor does not even provide the
basic guarantee?
In fact, I have been arguing for years that our smart pointers should
never have had a public interface which adopts unmanaged resources
on construction. Instead, we should write:
std::auto_ptrT = std::auto_ptr_newT(arg1, arg2, arg3);
Voila, a managed T straight out of the box.
It might be nice if you assigned it to a variable. ;
However, the desire to subsume existing smart pointers means you
have to support the unsafe unmanaged adoption interface.
Maybe we can eat our cake and have it too.
[...]
The move proposal says that standard components will require
the move construct/assign of their UDT parameters, if any, to be
nothrow. In practice that would be needed by any generic
components. That's enough to make the move undo-able.
Ok, but that still leaves smart_ptr with a few tricks to pull off. Let's
look at smart_ptr(std::auto_ptr p) for a minute:
smart_ptr(std::auto_ptrU p)
: storage(p), ownership(p), checking(), conversion()
{ checking::on_init(p); }
Now, the first that happens is that storage(p) attempts to take
ownership of p. For default storage, this is a no-throw operation.
Let's say we're moving p into a counted pointer. Now ownership
has to allocate a count, and might throw in the process. If it does,
we either have to clean up p, or we have to stuff the toothpaste
back into the tube.
I see that shared_ptr solves this by violating RAII. I don't think
Andrei included this case in the original Loki::SmartPtr, but I
think this new design will solve the problem. We simply must
insist that for some policy configurations, storage(p) is no-throw.
I don't think that's a burden, because in the vast majority of cases
where it matters, the implementation will already be no-throw.
Given that, we have seen that there are policy configurations
where we need the ownership policy to tell us how to clean up
in the event of an exception. This is my proposed solution:
template class StoragePolicy
ref_counted(std::auto_ptrT p, StoragePolicy storage)
try
: count_(new unsigned(1))
{
p.release();
}
catch (...)
{
storage.release();
}
Unfortunately, it requires a function try block. :( However, we
might be able to apply Dave's Initializer ScopeGuard(TM) to
this problem, by converting a function try block into an RAII
functoid. Let's see what happens:
template class StoragePolicy
class InitializerScopeGuard
{
public:
InitializerScopeGuard(StoragePolicy storage)
: execute_(true), storage_(storage)
{ }
~InitializerScopeGuard()
{ if (execute_) storage::release(); }
void cancel()
{ execute_ = false; }
private:
bool execute_;
StoragePolicy storage;
};
template typename P
class ref_counted_impl
{
public:
template typename U
ref_counted_impl(std::auto_ptrU p, InitializerScopeGuard guard)
: count_(new unsigned(1))
{
guard.cancel();
p.release();
}
// ...
private:
unsigned* count_;
};
template typename P
class ref_counted : ref_counted_implP
{
public:
template typename U, class StoragePolicy
ref_counted(std::auto_ptrU p, StoragePolicy storage)
: ref_counted_impl(p, InitializerScopeGuard(storage))
{ }
// ...
};
smart_ptr(std::auto_ptrU p)
: storage(p), ownership(p, static_castStoragePolicy(*this)),
checking(), conversion()
{ checking::on_init(p); }
Now, we insist that for this configuration, storage(p) is no-throw.
1) Thus, it will successfully acquire p, but both storage and auto_ptr
will own p.
2) For this c'tor, we insist that ownership follow the protocol
established for ref_counted. That means the following:
a) If ownership(...) throws, it must call storage_policy::release(),
so that storage does not attempt to clean up the resource.
b) If ownership(...) does not throw, it must call auto_ptr::release(),
so that possession is fully transferred.
3) We must insist that checking and conversion be no-throw unless
p is null.
Note that we are using the default storage policy from
Re: [boost] Re: gcc3.2, mpl::integral_c and enums
Fernando Cacciola [EMAIL PROTECTED] writes: So, first of all, do you agree that the mpl form is better? It's better, but maybe not for the reasons you think ;-). [It has to do with metafunction/metadata polymorphism] Also... It is a burden to deal with X::value in bcc5.5.1 because you need to fully qualify X, but not for X::type, do given that many metafunctions accept mpl's forms already, it is better if only for this reason. Granted. Note though: why do you think it is that many (MPL) metafunctions accept mpl's forms already? metafunction/metadata polymorphism again ;-) I think the fix is much easier than either of those: typedef integral_cT, static_castT(value + 1) next; typedef integral_cT, static_castT(value - 1) prior; Of course! I've tried many _other_ casts (for 'value' and '1' individually), but not this one... It works now! Great, I'll apply the patch to CVS. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Deadline for the Standard Library TechnicalReport
The first part of this is probably a stupid question Terje Slettebø wrote: What makes the template typedef proposal different from the template alias proposal, is that the former may be specialised, and the latter may be deduced. What do you mean by deduced? I saw it in the proposal too... Here's a copy of text from the proposal: *** templateclass T, class P class smart_ptr; templateclass T typedef smart_ptrT, SharedPolicy shared_ptr; templateclass T void f(smart_ptrT, SharedPolicy); templateclass T void f(shared_ptrT); In this proposal, the last two lines declare different templates. *** That is the kind of stuff that concerns me. There is a deviation in the usage of smart_ptrT, SharedPolicy and shared_ptrT even though they are typedef'd to be the same. Also, where should such discussion be going? Someone mentioned that this is not the place, but I'm not familiar with the various other mailing lists. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] named template parameters using mpl
On Friday, January 31, 2003, at 12:54 PM, Jonathan Wang wrote: The default features(types) are stored in a type-vector, and we can use boost.mpl to update the default features into use-defined ones, and to extract the updated paramters from type-vector. Then we can use NTPs later. And even can we mix the NTPs and the ordinary paramters, just to use ntp::update2 instead of ntp::update. I've also looked at ntp implementation similar to this (but used Loki type lists), and agree that this is a neat way to go. Essentially you just stick the defaults onto the end of the type list. Then if the user specifies anything, either by a default tag, a named parameter, or a positional parameter, you prepend it to the type list. Then the extraction routine simply searches the type list for the first appropriate parameter. Another thing this approach affords is relatively easy error checking. It is possible the user may accidently specify a parameter more than once (especially when you mix positional and named parameters). It is easy to search the type list and make sure that a parameter is not specified more than twice (once for the default, and not more than once for a user-supplied input). -Howard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Win32 Cygwin GCC w/Unix Newlines regex_timer problems
I was seeing something which looked like the regex_timer test ran forever on my system. Then I looked at the output file, which said (in Emacs): Enter expression (or quit to exit): abc^M Enter string to search (or quit to exit): aaab^M regex time: 5.7051us regex time (search over std::dequechar): 9.02554us POSIX regexec time: 4.63947us Enter string to search (or quit to exit): quit^M regex time: 2.5351us regex time (search over std::dequechar): 4.56523us POSIX regexec time: 2.91474us Enter string to search (or quit to exit): ^([0-9]+)(\-| |$)(.*)$^M regex time: 4.37793us regex time (search over std::dequechar): 6.29326us POSIX regexec time: 3.95737us Enter string to search (or quit to exit): 100- this is a line of ftp response which contains a message string^M regex time: 9.04538us regex time (search over std::dequechar): 10.7455us POSIX regexec time: 6.41666us Enter string to search (or quit to exit): quit^M regex time: 2.59545us regex time (search over std::dequechar): 4.60837us POSIX regexec time: 2.90528us Enter string to search (or quit to exit): quit^M regex time: 2.52727us regex time (search over std::dequechar): 4.48034us POSIX regexec time: 2.82985us Enter string to search (or quit to exit): regex time: 1.84228us regex time (search over std::dequechar): 3.67966us POSIX regexec time: 2.2491us Enter string to search (or quit to exit): regex time: 1.88509us regex time (search over std::dequechar): 3.73977us POSIX regexec time: 2.264us Enter string to search (or quit to exit): ... I realized that this is because I have a Cygwin installation that uses Unix newlines, but the input test file gets checked out by my CVS with Windows newlines. I changed the input test file to use Unix newlines unconditionally, which seems to fix it for all my compilers. This is my heads-up to you all. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
At 10:48 AM 1/31/2003, David Abrahams wrote: Greg Colvin [EMAIL PROTECTED] writes: At 09:53 AM 1/31/2003, David Abrahams wrote: ... In fact, I have been arguing for years that our smart pointers should never have had a public interface which adopts unmanaged resources on construction. Instead, we should write: std::auto_ptrT = std::auto_ptr_newT(arg1, arg2, arg3); Voila, a managed T straight out of the box. And I proposed something like this years before that, but foundered on not being able to declare a type-safe variadic function in C++. The move/forwarding proposals will fix that. In the meantime we have boost::ref(x)... ugly but effective. Can you give us link to that proposal? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
Greg Colvin [EMAIL PROTECTED] writes: At 10:48 AM 1/31/2003, David Abrahams wrote: Greg Colvin [EMAIL PROTECTED] writes: At 09:53 AM 1/31/2003, David Abrahams wrote: ... In fact, I have been arguing for years that our smart pointers should never have had a public interface which adopts unmanaged resources on construction. Instead, we should write: std::auto_ptrT = std::auto_ptr_newT(arg1, arg2, arg3); Voila, a managed T straight out of the box. And I proposed something like this years before that, but foundered on not being able to declare a type-safe variadic function in C++. The move/forwarding proposals will fix that. In the meantime we have boost::ref(x)... ugly but effective. Can you give us link to that proposal? You can find it in http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/mailings/papers/2002/pre_santacruz.zip Sorry, it's not truly varadic, it's up to N args. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] named template parameters using mpl
Howard Hinnant [EMAIL PROTECTED] writes: On Friday, January 31, 2003, at 12:54 PM, Jonathan Wang wrote: The default features(types) are stored in a type-vector, and we can use boost.mpl to update the default features into use-defined ones, and to extract the updated paramters from type-vector. Then we can use NTPs later. And even can we mix the NTPs and the ordinary paramters, just to use ntp::update2 instead of ntp::update. I've also looked at ntp implementation similar to this (but used Loki type lists), and agree that this is a neat way to go. Essentially you just stick the defaults onto the end of the type list. Then if the user specifies anything, either by a default tag, a named parameter, or a positional parameter, you prepend it to the type list. Then the extraction routine simply searches the type list for the first appropriate parameter. That's how my defaults by type properties thing works as well. I wonder if a single framework could be used to handle both approaches? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Deadline for the Standard Library TechnicalReport
[Note to moderators: This is just to reply, including giving possible alternative places to discuss this] From: Jason House [EMAIL PROTECTED] The first part of this is probably a stupid question Not at all. :) Terje Slettebø wrote: What makes the template typedef proposal different from the template alias proposal, is that the former may be specialised, and the latter may be deduced. What do you mean by deduced? The paper says: 2. A typedef template is itself an alias; it cannot be specialized. This choice would allow: . deduction on typedef template function parameters (see 2.4) The paper doesn't propose that model. However, that has been suggested as an alternative, mentioned in this thread, in the form of template alias (i.e. not using typedef at all). I saw it in the proposal too... Here's a copy of text from the proposal: *** templateclass T, class P class smart_ptr; templateclass T typedef smart_ptrT, SharedPolicy shared_ptr; templateclass T void f(smart_ptrT, SharedPolicy); templateclass T void f(shared_ptrT); In this proposal, the last two lines declare different templates. *** That is the kind of stuff that concerns me. There is a deviation in the usage of smart_ptrT, SharedPolicy and shared_ptrT even though they are typedef'd to be the same. I think what is meant is that the templates are not aliases (i.e. the templateclass T void(...) templates). Otherwise, the last two lines would declare identical templates. However, as I understand it, the template function parameters express the same type, i.e. typeof(smart_ptrT, SharedPtr) == typeof(shared_ptrT), for a given T. Also, where should such discussion be going? Someone mentioned that this is not the place, but I'm not familiar with the various other mailing lists. Hm, there's the C++ standards committee mailing lists (reflectors) which have been mentioned, but as I understand, these are not open to the public. Another alternative is the newsgroups, such as comp.std.c++, which is discussion about the standard, itself, which this is about. They may also be accessed from the web (http://groups.google.com/groups?hl=enlr=ie=UTF-8group=comp.std.c%2B%2B). Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
At 01:44 PM 1/31/2003, David Abrahams wrote: The move/forwarding proposals will fix that. In the meantime we have boost::ref(x)... ugly but effective. Can you give us link to that proposal? You can find it in http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/mailings/papers/2002/pre_santacruz.zip Sorry, it's not truly varadic, it's up to N args. Oh well. I hate arbitrary limits, and really do want a syntax for truly variadic functions. But this isn't the place for that discussion -- I'll have more to say at ACCU. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] People and pictures?
The People section of the web site currently has capsule biographies and pictures for 30 people. There should probably be two or three times that many people represented; there are 54 developers with write access to CVS, and beyond those there are lots of people who make important contributions to Boost without actually ever touching the CVS. While I very much want to continue the Boost tradition of capsule biographies and pictures, we need to deal with some problems of the current organization: * The size of the pictures (20-30K for the big pictures, 3K for the thumbnails) is a serious problem when we think of doubling or tripling the number of people represented. The problem isn't an individual picture, but rather the impact of all the pictures on the distribution .zip and .gz files. The picture files also slow backups of the CVS tarball. * Because getting the pictures ready is tricky, I've been the only one doing it. That creates a bottleneck. Like so many other Boost activities, we need to broaden this so any of the CVS regulars can add people. It seems to me one solution is to move the pictures to some location other than CVS. Probably the Boost SourceForge disk allotment. The capsule biographies would stay on the CVS, and thus would continue to be part of the web site and distribution files. Because adding a new biography will be much simpler, anyone with CVS write access would be able to do it. We'd have to write up a little guideline, but that shouldn't be a problem. A second solution would be to change to a smaller, lower-res picture. But that just makes it all the harder to prepare nice pictures. Comments? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost/mpl/integral_c.hpp and Borland
Beman Dawes [EMAIL PROTECTED] writes: Dave, Your change to boost/mpl/integral_c.hpp broke a lot of Borland 5.61 compiles. I thought something like that might happen on the broken compilers. I don't really know what the best approach here might be, other than to take out casts for those compilers. I'm not even sure if integral_csome_enum,... (which is what the change accomodates) is appropriate. Perhaps we should have enum_c with no next,prior for this purpose. See the Win32 tests just posted. --Beman -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: shifted_ptr w/ lock mechanism
Larry Evans [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Philippe A. Bouchard wrote: [snip] I guess it would also be possible to allocate a shifted object into some specific memory page, so operator delete will be able to quickly detect weither the object is shifted or not. This way it would be possible to overload the main operator new. I think this is what BW does to distinguish between pointers produced by GC_malloc_uncollectable and gc_malloc. Also, I think cmm does something similar (see ftp://ftp.di.unipi.it/pub/Papers/attardi/SPE.ps.gz ). Yeah, this is exactly how it works. It can create different heaps and the pointer can be identified quickly to which heap it belongs. Their example uses placement operator new also. In fact, if you want to share any pointer generated by any placement new between any smart pointer, this would be the best way IMO. Some BOOST_DISPLACE_NEW_GC macro could be defined to displace the main operator new also. Philippe A. Bouchard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] In-memory databases
At 04:10 PM 1/31/2003, David B. Held wrote: I've seen some talk of fully in-memory databases, and have a few questions: 1) Does anyone have any experience with them? Yes. 2) Would people use them if there were a nice library available? Yes. It seems that such a library could benefit from the serialization/ persistence library. A reference for a Java database is here: http://www.prevayler.org/wiki.jsp?topic=ObjectPrevalenceSkepticalFAQ The list of C++ databases seems pretty small, judging by Google. You should check out the relational template library that Arkadiy Vertleyb [EMAIL PROTECTED] and Dmitriy Arapov [EMAIL PROTECTED] are working on. Search the Boost archives for threads with relational in the subject. Maybe such a thing is too ambitious to be a Boost library? Nothing is too ambitious to be a Boost library ;- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
David B. Held [EMAIL PROTECTED] wrote in message b1ehpj$j1n$[EMAIL PROTECTED]">news:b1ehpj$j1n$[EMAIL PROTECTED]... Actually, you can control mixing by determining which policies can be constructed from which other policies. I just didn't know if it was a good idea to let users freely mix auto_ptr with shared_ptr. But I suppose if they get an auto_ptr from legacy code, and they want it to be managed by shared_ptr, that is a legitimate use. Indeed. Having policies decide which way, if at all, they plan to interoperate, is imho a key strenght of pbd. Most ownership policies should accept the destructive copy policy. Andrei ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue
Andrei Alexandrescu [EMAIL PROTECTED] writes: David B. Held [EMAIL PROTECTED] wrote in message b1ehpj$j1n$[EMAIL PROTECTED]">news:b1ehpj$j1n$[EMAIL PROTECTED]... Actually, you can control mixing by determining which policies can be constructed from which other policies. I just didn't know if it was a good idea to let users freely mix auto_ptr with shared_ptr. But I suppose if they get an auto_ptr from legacy code, and they want it to be managed by shared_ptr, that is a legitimate use. Indeed. Having policies decide which way, if at all, they plan to interoperate, is imho a key strenght of pbd. I keep forgetting how nicely that works. Thanks for the reminder, Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
