Re: [boost] ublas: Cannot use inner_prod with const matrix
Julius Muschaweck wrote:
now that sparse matrix_row's works with Joerg's latest CVS upload
(thanks Joerg), a const parameter that used to work with 1_29_0 doesn't
anymore:
using namespace boost::numeric;
typedef ublas::matrixdouble TM;
double InnerProdConst( const TM A, const ublas::vectordouble x )
{
return ublas::inner_prod( ublas::matrix_row const TM ( A, 2 ),
x );
}
VC++.NET complains that some internal conversion loses qualifiers,
This does compile with a non const matrix reference parameter, the same
is true if I use a sparse_matrix or a compressed_matrix. I didn't try
the other matrix types, but since this breaks with three matrix types,
it looks like it has to do with matrix_row itself.
... or with VC++.NET ;o)
Joerg Walter wrote:
The following code compiles successfully with GCC 3.2.1:
#include boost/numeric/ublas/matrix.hpp
using namespace boost::numeric;
typedef ublas::matrixdouble TM;
double InnerProdConst( const TM A, const ublas::vectordouble x )
{
return ublas::inner_prod( ublas::matrix_row const TM ( A, 2 ), x );
}
int main()
{
ublas::matrix double A( 3, 3 );
ublas::vector double x( 3 );
std::cout InnerProdConst( A, x ) std::endl;
}
... and with Comeau's C++ compiler 4.3.0.1, too.
Also with the following addition to `main()':
ublas::matrix double const CA( A );
std::cout InnerProdConst( CA, x ) std::endl;
fres
___
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: David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] If eating the cake means not having to support unmanaged adoption, I don't think so ;-) Well, I meant support both, of course. How hard would it be to create the generic managed c'tor? Search me! 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. Both highly imprecise notions; I don't know what either means for sure in this context. Substitute 'p' for 'p's resource', and maybe it will make more sense. Not really. - by clean up you mean delete? - by stuff stuff the toothpaste back... you mean move p back into the source pointer? I see that shared_ptr solves this by violating RAII. I don't know what this means either. RAII is not something you can violate. It's a technique or idiom. By violate RAII, I mean, use default construction with a try-catch block rather than the initializer list. The RAII philosophy that you've been preaching for the last week is that you almost never need a catch block if you use RAII properly. I don't think I ever said that. It's usually true, and it's good that you noticed, though. -- 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 Sat, 1 Feb 2003 20:01:15 -0800, Eric Niebler [EMAIL PROTECTED] wrote: Gennaro Prota [EMAIL PROTECTED] wrote Well, then I imagine you would prefer the old semantics. Was there anybody complaining that being not enough? Yes, I was. A while back, I pointed out to Rani that is_base_and_derived was insufficient to implement is_com_ptr, a trait I needed. In COM programming, every interface inherits from IUnknown, and many COM objects implement multiple interfaces. So is_base_and_derivedIUnknown, MyCOMObject was almost always ambiguous. I was content to gripe, but Rani actually did something about it. The new behavior of is_base_and_derived is very welcome, IMO. Yes, Rani pointed out the usage for COM interfaces too, and that's a good one. I'm only a little perplexed about inaccessible bases, because the relevant example looks a little artificial; that doesn't mean that there aren't better examples, or that it is a good example but I have not understood it. As I said in another post, let's see how will this behave in practice. After all, boost is (also) a sort of test-bed for C++ libraries. Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] ublas: Cannot use inner_prod with const matrix
Hi Kresimir,
you wrote:
now that sparse matrix_row's works with Joerg's latest CVS upload
(thanks Joerg), a const parameter that used to work with 1_29_0
doesn't
anymore:
using namespace boost::numeric;
typedef ublas::matrixdouble TM;
double InnerProdConst( const TM A, const ublas::vectordouble x )
{
return ublas::inner_prod( ublas::matrix_row const TM ( A, 2 ),
x );
}
VC++.NET complains that some internal conversion loses qualifiers,
This does compile with a non const matrix reference parameter, the
same
is true if I use a sparse_matrix or a compressed_matrix. I didn't try
the other matrix types, but since this breaks with three matrix types,
it looks like it has to do with matrix_row itself.
... or with VC++.NET ;o)
... or with ublas' perception of MS compilers ;-). I've just upgraded boost
on my old Win98 box from 1_25_1 to 1_29_0 and checked Julius' sample with
MSVC 6.0. He is right that it doesn't compile with the latest ublas
snapshot, but the fix is surprisingly simple. I only had to disable the
definition of
// #define BOOST_UBLAS_NO_SMART_PROXIES
in the MSVC section of config.hpp. This now seems to work due to our
migration to MPL (thanks, Aleksey!). The last compiler which doesn't support
these constructs is Borland.
Joerg Walter wrote:
The following code compiles successfully with GCC 3.2.1:
#include boost/numeric/ublas/matrix.hpp
using namespace boost::numeric;
typedef ublas::matrixdouble TM;
double InnerProdConst( const TM A, const ublas::vectordouble x )
{
return ublas::inner_prod( ublas::matrix_row const TM ( A, 2 ),
x );
}
int main()
{
ublas::matrix double A( 3, 3 );
ublas::vector double x( 3 );
std::cout InnerProdConst( A, x ) std::endl;
}
... and with Comeau's C++ compiler 4.3.0.1, too.
And with MSVC 6.0 now, too.
Also with the following addition to `main()':
ublas::matrix double const CA( A );
std::cout InnerProdConst( CA, x ) std::endl;
Hopefully, too. Didn't check this yet.
Thanks,
Joerg
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regression tests on Cray
96c96 if test $cvs_update == yes ; then --- if test $cvs_update = yes ; then Fixed that one, don't know what to do about the rest though... Thanks, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] compile-time functions interface
This is a simple question; suppose you have a template like this:
template unsigned long x
struct static_log2
{
BOOST_STATIC_CONSTANT( int, value = ...);
};
and that the implementation you use is absolutely general as far as
the argument type is concerned; in other words: if C++0x will make
unsigned long long available you want to replace unsigned long with
that wider type. Specifically, this is the case for the excellent
static_log2 implementation suggested by Vesa Karvonen a while ago on
this list. A first, obvious, way to do this is to typedef the argument
type:
namespace boost {
typedef unsigned long static_log2_argument_type;
template static_log2_argument_type x
struct static_log2 {
...
}
}
This of course works, but the typedef name is quite log specific;
certainly that's worse than having a generic name available at class
scope:
template ...
struct static_log2 {
typedef ... argument_type;// (*)
};
As Terje Slettebø noticed in private mail, this is a general problem
for any 'compile-time function'. A similar issue, for the run-time
counter-part, is solved by std::unary_function and
std::binary_function. What should we do for the compile-time case?
Note that to use argument_type in the above (*) you have to specify an
argument for static_log2, despite the fact that actually the typedef
doesn't depend on the value of which you compute the logarithm. Even
if you introduce, say, an argument_type template, like this:
// specialize this as needed
template typename T struct argument_type;
template static_log2_argument_type x
struct argument_type logx {
typedef static_log2_argument_type type;
};
you still don't solve the problem of the dummy argument: e.g.
argument_type log1 :: type; // why 1?
Unfortunately you can't default x to zero in the argument_type
specialization above. In fact, in this specific case, you could resort
to:
template static_log2_argument_type x = 0
struct log {
static const int value = ...;
};
Since log20 gives an error anyway, this would change nothing for the
normal usage of computing a logarithm (i.e.: he should specify the
argument anyway, as it is now). But, with that default, you could
have:
template
struct argument_type static_log2 {
typedef static_log2_argument_type type;
};
// usage:
argument_type static_log2 :: type
However I don't like too much the idea to have a default argument
(zero) which is a non-sense for the main usage of the template
(calculating an algorithm) and whose only purpose is to use a simpler
template-id in conjunction with argument_type. Also this is quite an
ad-hoc approach, not suitable for other unary compile-time-function
templates for which no unusable default exists. In short: I don't
know what to do :-) Maybe we should simply have the convention that
such templates provide typedefs with standard names, like
argument_type and result_type?
Thoughts?
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] compile-time functions interface
Gennaro Prota [EMAIL PROTECTED] writes:
This is a simple question; suppose you have a template like this:
template unsigned long x
struct static_log2
{
BOOST_STATIC_CONSTANT( int, value = ...);
};
and that the implementation you use is absolutely general as far as
the argument type is concerned; in other words: if C++0x will make
unsigned long long available you want to replace unsigned long with
that wider type. Specifically, this is the case for the excellent
static_log2 implementation suggested by Vesa Karvonen a while ago on
this list. A first, obvious, way to do this is to typedef the argument
type:
namespace boost {
typedef unsigned long static_log2_argument_type;
template static_log2_argument_type x
struct static_log2 {
...
}
}
*This* is precisely why you metafunctions should operate on types, not
numbers. Types are the only fully polymorphic metadata because they
can wrap anything else (well, as soon as we get template typedefs they
will be able to wrap anything else, but they're close enough now).
That's why MPL has integral_cT, value.
This of course works, but the typedef name is quite log specific;
certainly that's worse than having a generic name available at class
scope:
template ...
struct static_log2 {
typedef ... argument_type;// (*)
};
As Terje Slettebø noticed in private mail, this is a general problem
for any 'compile-time function'.
(metafunction)
A similar issue, for the run-time counter-part, is solved by
std::unary_function and std::binary_function. What should we do for
the compile-time case?
I don't think the analogy is a good one. unary_ and binary_function
just supply the typedefs for /specific/ function argument types.
The compile-time case should be handled by passing types instead of
numbers. If you need the other interface for convenience or legacy
reasons you can always write static_log2_cunsigned long.
Note that using types can allow you to compute a static log2 of
extended long values even if the C++ compiler doesn't have them built
in. One just needs an appropriate wrapper type such as:
template unsigned long hi, unsigned long lo
struct long_long
{
typedef long_long type;
unsigned long hi_value;
unsigned long lo_value;
};
and specializations of all of the arithmetic primitive metafunctions
you'll need to use to operate on it.
Note that to use argument_type in the above (*) you have to specify
an argument for static_log2, despite the fact that actually the
typedef doesn't depend on the value of which you compute the
logarithm. Even if you introduce, say, an argument_type template,
like this:
// specialize this as needed
template typename T struct argument_type;
template static_log2_argument_type x
struct argument_type logx {
typedef static_log2_argument_type type;
};
you still don't solve the problem of the dummy argument: e.g.
argument_type log1 :: type; // why 1?
Unfortunately you can't default x to zero in the argument_type
specialization above. In fact, in this specific case, you could resort
to:
template static_log2_argument_type x = 0
struct log {
static const int value = ...;
};
You've completely lost me here. I tried to understand it three times,
and gave up.
--
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] possible tuple_io patch for borland
The following patch will fix the compile time test failure for tuple_io/BCB6 [A similar fix was required for format] tuple_io.hpp (from line 439) #if defined (BOOST_NO_STD_LOCALE) const bool is_delimiter = !isspace(d); #elif defined ( __BORLANDC__ ) const bool is_delimiter = std::use_facet std::ctype char ( is.getloc() ).is( std::ctype_base::space, d); #else const bool is_delimiter = (!std::isspace(d, is.getloc()) ); #endif However, that now gives 4 runtime failures io_test.cpp(81): error in call_test_main: test tmp3.good() failed io_test.cpp(87): error in call_test_main: test tmp3.good() failed io_test.cpp(96): error in call_test_main: test bool(is ti) failed io_test.cpp(97): error in call_test_main: test ti == make_tuple(100, 200, 300) failed I'm not sure if this is progress or not, as compile failures are usually preferred to runtime ones. OTOH, maybe someone more familiar with stream implementations can take it from here and provide the rest of the solution? -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: possible tuple_io patch for borland (patched!)
Alisdair Meredith wrote: OTOH, maybe someone more familiar with stream implementations can take it from here and provide the rest of the solution? Scratch theat, I had missed the '!' when adding the borland case. tuple_io.hpp (from line 439) #if defined (BOOST_NO_STD_LOCALE) const bool is_delimiter = !isspace(d); #elif defined ( __BORLANDC__ ) const bool !is_delimiter = std::use_facet std::ctype char (is.getloc() ).is( std::ctype_base::space, d); #else const bool is_delimiter = (!std::isspace(d, is.getloc()) ); #endif This passes all tests. -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Deadline for the Standard LibraryTechnicalReport
At 09:41 AM 2/1/2003, Alisdair Meredith wrote: Beman Dawes wrote: See http://www.boost.org/more/cpp_committee_meetings.html. While the general public isn't invited to committee meetings, Boost technical experts are welcome. So how would I qualify myself as a Boost technical expert? Just show up and we'll vouch for you. I am hopefully past the 'hump' at work now, and so can spare some long-promised attention for boost-related matters. Currently I'm investigating format, Spirit and threads, but if any-one submitting libraries wants another pair of eyes looking over the submission just ask. [I've been holding back comments on smart-pointers as it has been quite busy without my help g] -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: possible tuple_io patch for borland (patched!)
Alisdair Meredith wrote: Scratch theat, I had missed the '!' when adding the borland case. Oh, and the templating on CharType. I THINK this is the final version g [Lesson number 1: before posting, engage brain] tuple_io.hpp (from line 439) #if defined (BOOST_NO_STD_LOCALE) const bool is_delimiter = !isspace(d); #elif defined ( __BORLANDC__ ) const bool !is_delimiter = std::use_facet std::ctype CharType (is.getloc() ).is( std::ctype_base::space, d); #else const bool is_delimiter = (!std::isspace(d, is.getloc()) ); #endif -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] MutablePropertyGraph questions
On Wed, 2003-01-29 at 15:30, Jeremy Siek wrote: On Wed, 29 Jan 2003, Vladimir Prus wrote: ghost I think the best approach would be to make this concept explicit, and ghost independent from BGL. Something like ghost ghosttype_indexed_container ghost mpl::list ghostpairvertex_name_t, int , ghostpairvertex_distance_t, int c; ghostc[vertex_name_t()] = 10; ghostI wonder if something like this already exists... I vaguely recall ghost someone was doing that. Yes, Emily Winch was working on this, and I thought she was going to submit to boost. The following URL has a paper she wrote about this. http://www.oonumerics.org/tmpw01/schedule.html I would be very happy to submit it to boost, and several people have suggested this. I think it would be a mistake to submit it for a formal review without any prior discussion. I have mentioned this a couple of times now, and the lack of feedback led me to think that nobody was particularly interested in it. That's easy to believe, since when I wrote the paper it was really more from a hey, this is cool perspective than hey, this would be really useful. However, people keep asking about it, or suggesting similar ideas, which suggests that there is some interest. So, I have a question: Why no feedback? a) The library is not something that people think makes sense in Boost. b) The library uses the wrong approach to the problem and someone should submit something else. c) The library is not something that anyone would really use. (Hey, Jeremy. I'm sure you said you would use it). d) People think it's a great idea but just never got round to having a look or making any comments. Emily ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time functions interface
On Sun, 02 Feb 2003 08:35:56 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
This of course works, but the typedef name is quite log specific;
certainly that's worse than having a generic name available at class
scope:
template ...
struct static_log2 {
typedef ... argument_type;// (*)
};
As Terje Slettebø noticed in private mail, this is a general problem
for any 'compile-time function'.
(metafunction)
Well, the term 'compile-time function' was mine, so if it is an error
it is my fault, not Terje's. Maybe I'm not aligned to the standard
terminology, but to me the prefix meta- means that refers to
something of its same nature, thus for instance a meta-sentence is a
sentence that talks about sentences, a metarule is a rule about rules
and a metaprogram is a program that generates a program. Since a class
template doesn't generate a function I don't call it a metafunction,
though of course if you intend 'function' in a wider meaning then you
can do that as well.
A similar issue, for the run-time counter-part, is solved by
std::unary_function and std::binary_function. What should we do for
the compile-time case?
I don't think the analogy is a good one. unary_ and binary_function
just supply the typedefs for /specific/ function argument types.
The compile-time case should be handled by passing types instead of
numbers. If you need the other interface for convenience or legacy
reasons you can always write static_log2_cunsigned long.
Note that using types can allow you to compute a static log2 of
extended long values even if the C++ compiler doesn't have them built
in. One just needs an appropriate wrapper type such as:
template unsigned long hi, unsigned long lo
struct long_long
{
typedef long_long type;
unsigned long hi_value;
unsigned long lo_value;
};
and specializations of all of the arithmetic primitive metafunctions
you'll need to use to operate on it.
Yes, but it's quite overkilling in this case. At a point, you have to
balance the generality with the complexity cost (not to talk, in this
case, about compile times).
Note that to use argument_type in the above (*) you have to specify
an argument for static_log2, despite the fact that actually the
typedef doesn't depend on the value of which you compute the
logarithm. Even if you introduce, say, an argument_type template,
like this:
// specialize this as needed
template typename T struct argument_type;
template static_log2_argument_type x
struct argument_type logx {
typedef static_log2_argument_type type;
};
you still don't solve the problem of the dummy argument: e.g.
argument_type log1 :: type; // why 1?
Unfortunately you can't default x to zero in the argument_type
specialization above. In fact, in this specific case, you could resort
to:
template static_log2_argument_type x = 0
struct log {
static const int value = ...;
};
You've completely lost me here. I tried to understand it three times,
and gave up.
Sorry, I should have been clearer. The idea was to use a non-intrusive
way to gather the argument type of a generic unary 'metafunction'. The
template argument_type, to be specialized as needed, provided a
uniform interface for that; for instance:
template typename T
struct argument_type;
template
struct argument_typeMyMetaFunction {
typedef ... type;
};
For static_log2 you would specialize it as:
template unsigned long x
struct argument_type static_log2x {
typedef unsigned long type;
};
That, however, still requires you to specify a number (whatever it is)
when requiring the argument type:
argument_type static_log216 :: type
whereas I think the intuitive syntax would be:
argument_type static_log2 :: type
To get the intuitive syntax, you can't use a default value in the
specialization of argument_type, simply because that's illegal. But
you could, if you really strive for it at all costs, use a default
(=0) for static_log2 itself. How ugly (and ad-hoc) that would be is
evident to everyone, so I was just, to say, thinking out loud in the
hope that it could suggest other ideas.
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time functions interface
Gennaro Prota [EMAIL PROTECTED] writes:
On Sun, 02 Feb 2003 08:35:56 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
This of course works, but the typedef name is quite log specific;
certainly that's worse than having a generic name available at class
scope:
template ...
struct static_log2 {
typedef ... argument_type;// (*)
};
As Terje Slettebø noticed in private mail, this is a general problem
for any 'compile-time function'.
(metafunction)
Well, the term 'compile-time function' was mine, so if it is an
error
It's not an error; I was just trying to say that they're equivalent
terms, for clarity.
it is my fault, not Terje's. Maybe I'm not aligned to the standard
terminology, but to me the prefix meta- means that refers to
something of its same nature, thus for instance a meta-sentence is a
sentence that talks about sentences, a metarule is a rule about rules
and a metaprogram is a program that generates a program. Since a class
template doesn't generate a function
It can, but not the ones we're discussing.
I don't call it a metafunction, though of course if you intend
'function' in a wider meaning then you can do that as well.
No, I intend meta- in the wider meaning of of or related to
metaprogramming. It's a lot easier to discuss metafunctions and
metadata than compile-time functions, and types, integral constants,
templates, constant pointers and references, pointers and references
to functions, and pointers to members (whew! did I forget anything?)
As long as we're in the domain of metaprogramming, I think it makes
sense to adopt a few linguistic shorthands (i.e. domain-specific
jargon).
Yes, but it's quite overkilling in this case. At a point, you have to
balance the generality with the complexity cost (not to talk, in this
case, about compile times).
You're the one who brought up generality ;-). It's easy enough to get
the speed back by using specializations.
Sorry, I should have been clearer. The idea was to use a non-intrusive
way to gather the argument type of a generic unary 'metafunction'. The
template argument_type, to be specialized as needed, provided a
uniform interface for that; for instance:
template typename T
struct argument_type;
template
struct argument_typeMyMetaFunction {
typedef ... type;
};
Ah. Well, there's no way to do what you want in general. That's just
one among many very good reasons that MPL metafunctions use a truly
polymorphic interface, operating just on types. If metafunctions
aren't themselves polymorphic, you can't do this kind of detection.
For static_log2 you would specialize it as:
template unsigned long x
struct argument_type static_log2x {
typedef unsigned long type;
};
That, however, still requires you to specify a number (whatever it is)
when requiring the argument type:
argument_type static_log216 :: type
I don't even think it works. Throwing this at Comeau online:
template unsigned long N
struct static_log2 {};
template class T
struct argument_type;
template unsigned int x // ***
struct argument_type static_log2x {
typedef unsigned long type;
};
Yeilds:
ComeauTest.c, line 6: error: constant x is not used in template argument list
of class template argument_typestatic_log2x
template unsigned int x
^
But this works again if I change *** to unsigned long. None of my
other compilers agree, but I am inclined to believe EDG. Why should
it be any different from substituting class x at ***?
whereas I think the intuitive syntax would be:
argument_type static_log2 :: type
To get the intuitive syntax, you can't use a default value in the
specialization of argument_type, simply because that's illegal. But
you could, if you really strive for it at all costs, use a default
(=0) for static_log2 itself. How ugly (and ad-hoc) that would be is
evident to everyone, so I was just, to say, thinking out loud in the
hope that it could suggest other ideas.
IMO, unless EDG is wrong you're going to have to use types if you want
to generalize it.
--
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] borland patch for random/graph tests
The following 2 patches in Random will pass both the graph and random_demo tests for BCB6. random_test still fails to compile with the compiler running out of memory. random\uniform_smallint [line 189] #ifndef BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS typedef typename detail::uniform_smallintstd::numeric_limitstypename UniformRandomNumberGenerator::result_type::is_integer::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; #elif defined( __BORLANDC__ ) typedef typename detail::uniform_smallint boost::is_floattypename UniformRandomNumberGenerator::result_type::value == false ::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; #else BOOST_STATIC_CONSTANT(bool, base_float = (boost::is_floattypename UniformRandomNumberGenerator::result_type::value == false)); typedef typename detail::uniform_smallintbase_float::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; #endif random\uniform_int [line 207] #ifndef BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS typedef typename detail::uniform_intstd::numeric_limitstypename UniformRandomNumberGenerator::result_type::is_integer::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; #elif defined( __BORLANDC__ ) typedef typename detail::uniform_int boost::is_floattypename UniformRandomNumberGenerator::result_type::value == false ::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; #else BOOST_STATIC_CONSTANT(bool, base_float = (boost::is_floattypename UniformRandomNumberGenerator::result_type::value == false)); typedef typename detail::uniform_intbase_float::BOOST_NESTED_TEMPLATE implUniformRandomNumberGenerator, IntType::type impl_type; #endif -- AlisdairM Team Thai Kingdom ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time functions interface
From: David Abrahams [EMAIL PROTECTED]
I'm combining a couple of postings here.
Gennaro Prota [EMAIL PROTECTED] writes:
This is a simple question; suppose you have a template like this:
template unsigned long x
struct static_log2
{
BOOST_STATIC_CONSTANT( int, value = ...);
};
and that the implementation you use is absolutely general as far as
the argument type is concerned; in other words: if C++0x will make
unsigned long long available you want to replace unsigned long with
that wider type. Specifically, this is the case for the excellent
static_log2 implementation suggested by Vesa Karvonen a while ago on
this list. A first, obvious, way to do this is to typedef the argument
type:
namespace boost {
typedef unsigned long static_log2_argument_type;
template static_log2_argument_type x
struct static_log2 {
...
}
}
*This* is precisely why you metafunctions should operate on types, not
numbers. Types are the only fully polymorphic metadata because they
can wrap anything else (well, as soon as we get template typedefs they
will be able to wrap anything else, but they're close enough now).
That's why MPL has integral_cT, value.
*This* is precisely why you metafunctions should operate on types, not
numbers. Types are the only fully polymorphic metadata because they
can wrap anything else (well, as soon as we get template typedefs they
will be able to wrap anything else, but they're close enough now).
That's why MPL has integral_cT, value.
Yes, of course. I thought it could be hard to find a way to provide the
types for such a metafunction like static_log2, when it turns out that a
solution to it is to not do it like that in the first place, as you say.
I've even used this polymorphic ability of MPL to write examples of generic
metafunctions like factorial. I just didn't think of of that, as this
metafunction worked in a different way. The answer is to change the way of
doing it, rather than finding a way to do it with the current version of the
metafunction.
As Terje Slettebø noticed in private mail, this is a general problem
for any 'compile-time function'.
Just to clarify here, what I meant was that this wasn't something specific
for this particular metafunction, of course, so it could be good to find a
general solution, such as the above one.
From the next posting:
Gennaro Prota [EMAIL PROTECTED] writes:
From: David Abrahams [EMAIL PROTECTED]
For static_log2 you would specialize it as:
template unsigned long x
struct argument_type static_log2x {
typedef unsigned long type;
};
That, however, still requires you to specify a number (whatever it is)
when requiring the argument type:
argument_type static_log216 :: type
I don't even think it works. Throwing this at Comeau online:
template unsigned long N
struct static_log2 {};
template class T
struct argument_type;
template unsigned int x // ***
struct argument_type static_log2x {
typedef unsigned long type;
};
Yeilds:
ComeauTest.c, line 6: error: constant x is not used in template
argument list
of class template argument_typestatic_log2x
template unsigned int x
^
But this works again if I change *** to unsigned long. None of my
other compilers agree, but I am inclined to believe EDG. Why should
it be any different from substituting class x at ***?
I'm not sure what you mean, here. The error above comes from argument type
mismatch, as the type of x is unsigned int, while static_log2 expects an
unsigned long, so there needs to be a conversion. Therefore, the partial
specialisation doesn't work. As you note, if you change it to match, with
unsigned long, it works. I think EDG is right on this one, that there has to
be an exact match, except top-level cv-qualification.
whereas I think the intuitive syntax would be:
argument_type static_log2 :: type
To get the intuitive syntax, you can't use a default value in the
specialization of argument_type, simply because that's illegal. But
you could, if you really strive for it at all costs, use a default
(=0) for static_log2 itself. How ugly (and ad-hoc) that would be is
evident to everyone, so I was just, to say, thinking out loud in the
hope that it could suggest other ideas.
IMO, unless EDG is wrong you're going to have to use types if you want
to generalize it.
You can use the syntax Genny used: argument_type static_log216 ::
type. However, unless you use an arbitrary default argument for
static_log2, just for this purpose, you need to specify an arbitrary
constant, instead, as shown here, just to get the type.
Regards,
Terje
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time functions interface
Terje Slettebø [EMAIL PROTECTED] writes:
From: David Abrahams [EMAIL PROTECTED]
I don't even think it works. Throwing this at Comeau online:
template unsigned long N
struct static_log2 {};
template class T
struct argument_type;
template unsigned int x // ***
struct argument_type static_log2x {
typedef unsigned long type;
};
Yeilds:
ComeauTest.c, line 6: error: constant x is not used in template
argument list
of class template argument_typestatic_log2x
template unsigned int x
^
But this works again if I change *** to unsigned long. None of my
other compilers agree, but I am inclined to believe EDG. Why should
it be any different from substituting class x at ***?
I'm not sure what you mean, here. The error above comes from argument type
mismatch, as the type of x is unsigned int, while static_log2 expects an
unsigned long, so there needs to be a conversion. Therefore, the partial
specialisation doesn't work.
Exactly. My point is that as far as the template mechanism is
concerned, int, long, and class are all completely disjoint kinds of
metadata -- with one exception: int and long constants are allowed to
inter-convert when you pass one where the other is expected.
As you note, if you change it to match, with unsigned long, it
works. I think EDG is right on this one, that there has to be an
exact match, except top-level cv-qualification.
cv-qualification?? Whoa, the compiler seems to accept them, but
they're also ignored. This compiles:
template const volatile int x struct foo;
template template int x class class bar {};
barfoo x;
whereas I think the intuitive syntax would be:
argument_type static_log2 :: type
To get the intuitive syntax, you can't use a default value in the
specialization of argument_type, simply because that's illegal. But
you could, if you really strive for it at all costs, use a default
(=0) for static_log2 itself. How ugly (and ad-hoc) that would be is
evident to everyone, so I was just, to say, thinking out loud in the
hope that it could suggest other ideas.
IMO, unless EDG is wrong you're going to have to use types if you want
to generalize it.
You can use the syntax Genny used: argument_type static_log216 ::
type. However, unless you use an arbitrary default argument for
static_log2, just for this purpose, you need to specify an arbitrary
constant, instead, as shown here, just to get the type.
You can do that, but IIUC it won't get you where Genny's trying to go:
namely that if static_log2 happens to get adjusted so its parameter is
an unsigned long long constant, you can detect that without causing an
error.
--
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: compile-time functions interface
--- David Abrahams [EMAIL PROTECTED] wrote:
You can do that, but IIUC it won't get you where Genny's trying to go:
namely that if static_log2 happens to get adjusted so its parameter is
an unsigned long long constant, you can detect that without causing an
error.
No. Because in the real code I would have written:
// actually in namespace detail
typedef unsigned long static_log2_arg_type; // (*)
template static_log2_arg_type N
struct static_log2 {};
template class T
struct argument_type;
template static_log2_arg_type x // ***
struct argument_type static_log2x {
typedef static_log2_arg_type type;
};
and the only point subject to modification would have been (*). My problem was
just that I don't like to specify a value when retrieving the argument type.
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] People and pictures?
On Friday 31 January 2003 08:02 pm, Beman Dawes wrote: 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. I like this solution best. No helpful comments from me, though :( Doug ___ 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]... [...] - by clean up you mean delete? Since we were talking about auto_ptr, I guess that's the only valid definition of clean up. - by stuff stuff the toothpaste back... you mean move p back into the source pointer? Yup. But I see that's not necessary. You just don't squeeze it all out to begin with. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr - Exception safety reprise
David Abrahams [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[...]
Borland is particularly strange about layout.
Suprisingly enough, BCB 5 has maintained the optimal size throughout
all the changes.
[...]
Whaaa? A temporary that never gets created?
Well, I'll show you the code, and you tell me if it gets optimized away
or not:
// Inherit first
template class T1, class T2
class optimal_parents1 : public T1
{
// ...
template class U1, class U2
optimal_parents1(optimal_parents1U1, U2 const rhs)
: T1(static_castU1 const(rhs))
{ U2 u2; T2 t2(u2); } // Here
// ...
};
If T2(U2 const) is empty, I would think that it wouldn't bother to
call it in the first place. Am I missing something? Maybe I shouldn't
have called t2 a temporary, since it is an lvalue. I just meant that
it's not really used for anything other than making sure that U2 can
be converted to T2.
[...]
Maybe you should illustrate what you mean, 'cause I'm lost.
assert_check(no_check const)
{ }
This allows you to create a pointer with stricter checking from a
pointer with no checking. But no_check has no such conversion
c'tors, because presumably, one does not want to *reduce* the
level of checking. Since the checking policies generally don't have
any state, the c'tors are all trivial, and hopefully, will get optimized
out of existence. They merely serve as a compile-time check of
compatibility.
[...]
I don't think I can do any better than you. I have the same tools at
my disposal. I'd do a bunch of experiments and look at the
resulting class layouts by checking the size and the relative addresses
of members.
I was afraid it was going to come down to that.
[...]
You could probably figure out the VC++ algorithm by
experimentation, but that still wouldn't help a user trying to write
portable, efficient code, unless you find a workaround for every
other compiler.
Yeah, that's the problem. :( Even more disturbingly, it's not clear if
this is just an MI problem, or a problem with inheritance in general
with VC++. I mean, when I tried the chained policy implementation,
it did provide the right size, but that doesn't mean it won't change if
I update the implementation (and that version would require a lot of
changes to get it up to speed with the MI version).
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time functions interface
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
As you note, if you change it to match, with unsigned long, it
works. I think EDG is right on this one, that there has to be an
exact match, except top-level cv-qualification.
cv-qualification?? Whoa, the compiler seems to accept them, but
they're also ignored. This compiles:
template const volatile int x struct foo;
template template int x class class bar {};
barfoo x;
Yes, that's what I meant: The types have to match, except for any top-level
cv-qualification difference, as it's ignored, as you say.
Regards,
Terje
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] People and pictures?
Douglas Gregor [EMAIL PROTECTED] writes: On Friday 31 January 2003 08:02 pm, Beman Dawes wrote: 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. I like this solution best. No helpful comments from me, though :( Me 2. -- 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: David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] - by clean up you mean delete? Since we were talking about auto_ptr, I guess that's the only valid definition of clean up. - by stuff stuff the toothpaste back... you mean move p back into the source pointer? Yup. But I see that's not necessary. You just don't squeeze it all out to begin with. Dave, I guess I should've just come out and said this before: you might be good at operating in terms of metaphors like toothpaste, but I am not. If I'm going to be of help, I really need to deal with good, solid C++ terms. Even if you're comfortable speaking about programs that way, think it would probably be beneficial for you to try to nail down your terminology and write with precision about the problems you're solving. Remember when I asked you to write down the sequence of operations during construction of smart_ptr, and how it uncovered a bug? -D -- 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] Regression tests on Cray
At 05:37 PM 2/1/2003, Matthias Troyer wrote: On Saturday, February 1, 2003, at 10:49 PM, Beman Dawes wrote: At 12:39 PM 2/1/2003, Matthias Troyer wrote: cat regress.log | $process_jam_log --- cat regress.log | $process_jam_log $boost_root ... Finally, I wonder why I need the sixth change. How does this work on other platforms? Is there an easier fix? I can answer that one. If process_jam_log is given no argument, it assumes it is being run from some directory within the boost directory tree, and starts recursing upward looking for boost-root. (It assumes any directory with a sub-directory named libs is the boost-root.) That mechanism is probably at play in the script. Specifying a directory argument is particularly useful if ALL_LOCATE_TARGET is being used to place the test targets someplace outside of the boost-root tree, which is a good idea. Since I run it from within the boost directory tree, it probably fails to find it automatically on the Cray. Is that a bug I should investigate further? Maybe. First tell me what the output is from the messages that process_jam_log outputs soon after it starts. The lines that create the messages begin about line 366 in the source file: std::cout boost_root: boost_root.string() '\n' locate_root: locate_root.string() '\n'; Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Array support [was SmartPtr (Loki) - auto_ptr/move c'torissue]
At 07:49 PM 1/30/2003, David B. Held wrote: Beman Dawes [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] The use case I was interested in was an array being managed, and the conversion to T* also being present. Ouch! I haven't worked through the details, but I have a gut level feeling that it's going to be nasty. The difficulty, of course, is that the public interface has to change based on the interaction between two policies. The problem didn't arise in the original Loki::smart_ptr because it didn't allow arrays. Well, since array support has been mandated, I will face this issue eventually. When it crops up, rest assured you will probably hear from me. ;) Because the solution affects how you structure a PBSP's inheritance, it probably needs to be dealt with early in the design. Here is the problem: If T is not an array, the interface must supply: T operator*() const; T* operator-() const; If T is an array conversion to T* is not desired, the interface must supply: T operator[](size_t i) const; If conversion to T* is desired, the interface must supply: operator T*() const; In other words, there are four interface combinations: When T is not an array conversion to T* is not desired: T operator*() const; T* operator-() const; When T is not an array conversion to T* is desired: T operator*() const; T* operator-() const; operator T*() const; When T is an array conversion to T* is not desired: T operator[](size_t i) const; When T is an array conversion to T* is desired: operator T*() const; HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Array support [was SmartPtr (Loki) - auto_ptr/movec'tor issue]
Beman Dawes [EMAIL PROTECTED] writes: Here is the problem: If T is not an array, the interface must supply: T operator*() const; T* operator-() const; If T is an array conversion to T* is not desired, the interface must supply: T operator[](size_t i) const; If conversion to T* is desired, the interface must supply: operator T*() const; In other words, there are four interface combinations: When T is not an array conversion to T* is not desired: T operator*() const; T* operator-() const; When T is not an array conversion to T* is desired: T operator*() const; T* operator-() const; operator T*() const; When T is an array conversion to T* is not desired: T operator[](size_t i) const; When T is an array conversion to T* is desired: operator T*() const; Why can't operator T*() and operator[](size_t) coexist? -- 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] borland patch for random/graph tests
At 01:18 PM 2/2/2003, Alisdair Meredith wrote: The following 2 patches in Random will pass both the graph and random_demo tests for BCB6. random_test still fails to compile with the compiler running out of memory. random\uniform_smallint [line 189] ... #elif defined( __BORLANDC__ ) ... random\uniform_int [line 207] ... #elif defined( __BORLANDC__ ) ... Alisdair, While I (and probably others!) would very much like to get fixes for random, there are a couple of issues: * Patches really are best to be supplied as diff output; that cuts errors applying them. The -c switch helps make them more readable. It may be better to attach the diff output as a file, if long lines would be wrapped by pasting it inline. * Testing for defined( __BORLANDC__ ) is usually discouraged because it will fail when the compiler changes to a new version which behaves differently. Also, there may be a Boost config macro which applies, and is the preferred way to detect a compiler deficiency. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time functions interface
On Sun, 02 Feb 2003 15:02:23 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
[...]
My point is this: the only thing that would make argument_type
worthwhile, i.e. the ability to do higher-order functional
programming, really requires that metafunctions have a consistent
polymorphic interface (i.e. type arguments and results). So if you
really insist that static_log2 will not take a type argument, that's
fine, but don't waste your time trying to get argument_type to work.
You're not operating in a generic world, because there's no way to
generalize the neccessary default argument to arbitrary metafunctions
with that form. You might as well settle for static_log2_arg_type
instead.
Yes, your point is very clear and you are undoubtedly right. I've done
some quick tests with the current implementation of static_log2 and it
turns out that, even with the most optimistic assumptions, compile
times increase remarkably as soon as you use a type argument. And
there are problems with broken compilers as well. Just to clarify it:
the core of the current implementation is the following template
// Core algorithm
//
templateunsigned long x, int n = initial_value
struct static_log2_impl {
enum {cn = (1uln = x) * n};
BOOST_STATIC_CONSTANT(int,
value = cn + (static_log2_impl(xcn),n/2::value));
};
template
struct static_log2_impl1ul,0 {
BOOST_STATIC_CONSTANT(int, value = 0);
};
I've left out the definition of initial_value, for simplicity.
Basically the core is a binary search: for instance, if you have 32
bits unsigned longs you start from n = 16, then you see whether your
number x is = 65536. If so, then the logarithm is 16 + the logarithm
of x/65536, otherwise you simply go on. This is repeated for n=8, n=4,
etc. up to n = 0. It's easy to prove that, if you choose the initial n
correctly, you always end up with the first argument = 1 and the
second one = 0; thus to terminate recursion you don't need a partial
specialization
template unsigned long x
struct static_log2_implx, 0 {
BOOST_STATIC_CONSTANT(int, value = 0);
};
That's of course important for our faithful broken compilers. If I
understand you correctly, having a type argument requires PTS instead.
Regardless of that consideration, I tried quickly changing the code to
this:
template typename T, T v
struct integral_c
{
BOOST_STATIC_CONSTANT(T, value = v);
typedef integral_cT, v type;
typedef T value_type;
};
// Core algorithm
//
templatetypename x, int n = initial_value
struct static_log2_impl {
enum { cn = (( x::value n) 0) * n };
enum { value = cn + static_log2_impl
integral_ctypename x::value_type, (x::value cn),
n/2
::value
};
// terminates recursion (uses PTS)
templatetypename T
struct static_log2_implintegral_cT, 1, 0 {
BOOST_STATIC_CONSTANT(int, value = 0);
};
// User interface: simply forwards to static_log2_impl
//
templateunsigned long x
struct static_log2 {
BOOST_STATIC_CONSTANT(int,
value = (detail::static_log2_impl
integral_cunsigned long, x ::value));
};
template
struct static_log20ul {};
Note that I haven't included any of the pachydermic boost headers, I
have just defined integral_c myself. Also, note that this is just a
hacked up implementation and that I operated on the argument only, the
result is still *not* a type. In other words I have made just a part
of the changes that are needed, so the timings I will have with this
are likely to be lower than the real ones. Well, the attached test
yielded:
// original version:
$ ./bash_test.sh
real0m34.672s
user0m10.610s
sys 0m22.601s
// new version, with type argument
$ ./bash_test.sh
real0m39.096s
user0m14.970s
sys 0m22.720s
Of course, defining integral_c yourself is not enough because it needs
compiler workarounds, so in practice you should include the boost
header. Doing that, timings go to:
$ ./bash_test.sh
real0m42.624s
user0m15.710s
sys 0m22.921s
Also, if you have to cope with simulating PTS the amount of code to
include increases. Well, this was enough to discourage me to do the
complete transformation :-/ So I agree that your arguments are very
well put, and that from a meta-programming perspective the value-based
approach is weak, but abandoning it, in this case, would mean
incurring in other problems and give up both simplicity and speed.
However, it's likely that I'm missing something, and that there are
ways to make the good way as efficient as the naive one. You are by
far more expert than me with template metaprogramming, so I'll leave
to you the last word.
Genny.
begin 644 bash_test.sh
M(R$@+V)I;B]B87-H#0H-F9U;F-T:6]N('1EW0@PT*(`@(!G*RL@+B]T
[boost] Re: SmartPtr - Exception safety reprise
David B. Held wrote: Optimally_inherit is a device that is the dual of compressed_pair. Andrei suggested it when this issue first came up. Whilst compressed_pair aggregates when a type is non-empty, and inherits when it's empty, optimally_inherit inherits when the type is non-empty, and just calls c'tors on temporaries when the type is empty. This way, empty bases don't actually enter the inheritance tree. A little bit of synchronicity for you. I was just taking a refresher read through More Exceptional C++ today, and Item 4 on concept checking base classes jumped right off the page after reading this post but 1/2 hour previously :¬ ) -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] named template parameters using mpl
At 16:48 2003-02-01 -0500, you wrote:
What do you mean by a single framework could be used to handle both
approaches?
I mean a library which would allow you to extract optional types
parameters based on either their wrapper templates (Color_is...)
or on a predicate (e.g. pick the one for which is_classT::value is
true).
Perhaps this can be done with the interface for
parameter extraction i posted earlier.. Something like:
template typename T struct Model_is;
template typename T struct Color_is;
template typename T struct Seats_is;
template typename T struct Transmission_is;
template class Model = unspecified,
class Color = unspecified,
class Seats = unspecified,
class Transmission = unspecified
class car {
typedef extract_policies
mpl::vector4Model, Color, Seats, Transmission
, mpl::vector4
named_parameterModel_is
, named_parameterColor_is
, named_parameterSeats_is
, named_parameterTransmission_is
, mpl::vector4
Model_isgl, Color_isred, Seats_isleather,
Transmission_isautomatic
policies_t;
typedef typename policies_t::policy0 model;
typedef typename policies_t::policy1 color;
typedef typename policies_t::policy2 seats;
typedef typename policies_t::policy3 transmission;
};
Where named_parameter... is sugar for is_same_ttModel_isvoid, _1
(from Jonathan's code). Obviously 'extract_policy' would be the wrong
name for this.. 'extract_parameters' would be more appropriate.
Daniel Wallin, [EMAIL PROTECTED]
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]
At 04:18 PM 2/2/2003, David Abrahams wrote: In other words, there are four interface combinations: When T is not an array conversion to T* is not desired: T operator*() const; T* operator-() const; When T is not an array conversion to T* is desired: T operator*() const; T* operator-() const; operator T*() const; When T is an array conversion to T* is not desired: T operator[](size_t i) const; When T is an array conversion to T* is desired: operator T*() const; Why can't operator T*() and operator[](size_t) coexist? They are ambiguous, or at least GCC, Intel, and Microsoft compilers think so, although Borland only warns and Metrowerks accepts. The Intel error message says: test.cpp(15): error: more than one operator [] matches these operands: built-in operator pointer-to-object[integer] function fooT::operator[](unsigned int) [with T=int] operand types are: fooint [ int ] That being said, if size_t is changed to int, all of the above compilers accept the code and select the correct overload. However, both VC++ 6.0 and 7.0 fail if the argument to [] happens to be size_t. The only way to get it to work with both VC++ 6.0 and 7.0 is to remove the operator T*(). So, yes, you can get operator[] and operatorT* to co-exist, but you have to be very careful with parameter types. Plus you can't use operator[] and operatorT* together with VC++ 6.0 or 7.0. Hopefully that is fixed in 7.1, but I haven't tried it. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread library with BOOST_HAS_PTHREAD
Alexander Terekhov writes: 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. So, if upgrading Solaris is not an option, I should patch boost.threads each time a new version is out? Isn't it easier to add a couple of #ifdefs? :) Best regards, Shuki. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Array support [was SmartPtr (Loki) - auto_ptr/move c'tor issue]
Beman Dawes [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
At 04:18 PM 2/2/2003, David Abrahams wrote:
[...]
Why can't operator T*() and operator[](size_t) coexist?
They are ambiguous, or at least GCC, Intel, and Microsoft compilers
think so, although Borland only warns and Metrowerks accepts.
I see. That's what Comeau says too. I was testing it with an int
parameter, in which case it compiles.
[...]
The only way to get it to work with both VC++ 6.0 and 7.0 is to
remove the operator T*().
Ok. I think this is possible without changing the inheritance hierarchy,
though. We can disable operator T* using the disallow_conversion
policy, and I suspect we can disable operator[] by tweaking the
argument type like so (pseudocode):
class smart_ptr
{
private:
class disable_index { };
typedef if_
array_policy disallow_conversion,
std::size_t,
disable_index const
::type index_arg;
// ...
public:
T operator[](index_arg)
{ ... }
// ...
};
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr - Exception safety reprise
David Abrahams [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[...]
If T2(U2 const) is empty, I would think that it wouldn't bother to
call it in the first place. Am I missing something?
Sigh. We can't detect the presence of trivial constructors,
But the compiler can, right?
especially taking arbitrary arguments.
If the arguments are all references, there are no data members, and there
is no body, I'd say that's pretty trivial.
What is_empty does is detect classes which the EBO can potentially
optimize away, i.e. those with no data members. T2 may have a non-
trivial destructor to boot.
But the compiler knows this too. So if the c'tor and d'tor are both
trivial,
why not just optimize them away?
[...]
If that's all you care about you could just do
BOOST_STATIC_ASSERT((is_convertibleU2,T2::value));
Does this work reliably on all platforms? If so, that is a better solution.
[you snipped the context for my question]
Sorry, sometimes I am overzealous in my snipping.
since their sole purpose is to verify policy compatibility. In
the majority of cases, they will simply call an appropriate
copy c'tor, which will be trivial or generated, because the
class has no state.
[...]
Maybe you should illustrate what you mean, 'cause I'm lost.
assert_check(no_check const)
{ }
This allows you to create a pointer with stricter checking from a
pointer with no checking.
You're not showing much. I'll take your word for it.
Well, the idea is that when you construct a pointer with one checking
policy from a pointer with a different checking policy, you enable
convertibility by writing the appropriate c'tor in your checking policy.
But no_check has no such conversion c'tors, because presumably,
one does not want to *reduce* the level of checking. Since the
checking policies generally don't have any state, the c'tors are all
trivial, and hopefully, will get optimized out of existence. They
merely serve as a compile-time check of compatibility.
I've been concerned about optimizing storage, not code. The EBO
issue has nothing to do with inlining constructors.
Right. I was just explaining why I was creating temporaries in the first.
place. You said:
If you don't care about ctors and dtors, it sounds plausible,
which I took to mean that you thought having extra c'tor/d'tor calls for
optimally_inherit would make things fatter/slower. I was just trying to
argue that I expected most of it to get optimized away.
[...]
Yeah, that's the problem. :( Even more disturbingly, it's not clear if
this is just an MI problem, or a problem with inheritance in general
with VC++. I mean, when I tried the chained policy implementation,
it did provide the right size, but that doesn't mean it won't change if
I update the implementation (and that version would require a lot of
changes to get it up to speed with the MI version).
I've been saying this over and over: yes it does, for all practical
purposes. Vendors are VERY reluctant to break object code
compatibility. If they ever do break it intentionally, it will only
be to do *more* optimizations, not fewer.
Maybe I wasn't clear. At one point, the MI implementation reported
sizeof(smart_ptr) == 8 on VC++. Changing around the policy code,
I somehow made VC++ inflate the size to 12. What I'm saying is that
I don't know if that occurred *just because of MI*, or if the same type
of thing might occur with a chained policy implementation. That is, it
seems conceivable to me that there might exist some configurations of
the chained policy setup in which the sizeof(smart_ptr) gets inflated for
some inexplicable reason (unless you know for sure this won't happen).
So the fact that the first version of the chained policy gave sizeof == 8
doesn't give me confidence that *every* version of the chained policy
will have the desired property. For all I know, adding a certain number
of member functions to some policy will cause VC++ to decide that
now it's going to make sizeof(smart_ptr) == 12 or 16 or whatever
number it likes. It would be nice to have some assurance that this
won't happen, but the current state of affairs with the MI setup doesn't
exactly involve EBO, and so I'm afraid that the chained policy
configuration might be susceptible to the same fate.
Dave
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time functions interface
Gennaro Prota [EMAIL PROTECTED] writes: On Sun, 02 Feb 2003 15:02:23 -0500, David Abrahams [EMAIL PROTECTED] wrote: [...] My point is this: the only thing that would make argument_type worthwhile, i.e. the ability to do higher-order functional programming, really requires that metafunctions have a consistent polymorphic interface (i.e. type arguments and results). So if you really insist that static_log2 will not take a type argument, that's fine, but don't waste your time trying to get argument_type to work. You're not operating in a generic world, because there's no way to generalize the neccessary default argument to arbitrary metafunctions with that form. You might as well settle for static_log2_arg_type instead. Yes, your point is very clear and you are undoubtedly right. I've done some quick tests with the current implementation of static_log2 and it turns out that, even with the most optimistic assumptions, compile times increase remarkably as soon as you use a type argument. And there are problems with broken compilers as well. Just to clarify it: the core of the current implementation is the following template snip That's of course important for our faithful broken compilers. If I understand you correctly, having a type argument requires PTS instead. No. Regardless of that consideration, I tried quickly changing the code to this: snip That isn't the approach I'd take if I cared about the speed of a type-based version. But no time to write the answer up this minute... Note that I haven't included any of the pachydermic boost headers, I have just defined integral_c myself. Also, note that this is just a hacked up implementation and that I operated on the argument only, the result is still *not* a type. In other words I have made just a part of the changes that are needed, so the timings I will have with this are likely to be lower than the real ones. Well, the attached test yielded: // original version: $ ./bash_test.sh real0m34.672s user0m10.610s sys 0m22.601s // new version, with type argument $ ./bash_test.sh real0m39.096s user0m14.970s sys 0m22.720s Of course, defining integral_c yourself is not enough because it needs compiler workarounds, so in practice you should include the boost header. Doing that, timings go to: $ ./bash_test.sh real0m42.624s user0m15.710s sys 0m22.921s I think you obviously missed my point altogether, which was: If you just care about speed, use the tiny and simple implementation you have, and give up on introspecting about the argument type of the metafunction. If you just care about generality, build an implementation around types. Then you don't have introspect about the argument type, because the metafunction will work for any argument type that fits the concept requirements for integral arithmetic. If you care about both speed and generality, provide both of the above interfaces. There are of course various ways you can optimize, for example specializing the second version so that integral_cT,x where T fits in an unsigned long just dispatches to the first one. -- 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 - Exception safety reprise
-Original Message- From: David Abrahams [mailto:[EMAIL PROTECTED]] David B. Held [EMAIL PROTECTED] writes: Well, I want to at least give the VC++ guys a few days to see if they say anything. I posted a question on a M$ newsgroup. I think I did the first time around, too, and they didn't. It would be really cool if, say, Jason Shirk offered some insight, or at least knocked some skulls so we got *some* kind of answer, even if it's there's no way in heck we will give out that kind of information. If you aren't getting reasonably prompt responses to questions like this on MS newsgroups, send me a private email and I'll definitely follow up. As a team, VC++ is significantly more responsive to NG posts now, but some still slip through the cracks. What question are you asking? I think all NDAs on the vc7.1 betas are expired, so I can just run a test... However, you obviously missed my point: there _is_ no way in heck they're going to change the object layout, thus making vc7.1 object code incompatible with vc7 object code. Objects with multiple empty bases have to have the same size in both versions and their members have to live at the same offsets. BTW, VC++ is not the only kid on the block, and the same argument applies to all the other players. As usual, you are absolutely correct. Backwards compatibility in our object model is critical. I seriously doubt we'll ever do the ZBO by default. I do plan on implementing it in the next few months, and it will definitely be under a switch. I can't possibly predict when anyone outside MS will see such a compiler though, sorry. -- Jason Shirk VC++ Compiler Team ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr - Exception safety reprise
David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] The problem arises if the user passes an empty policy class with non-trivial ctor or dtor: then the fact that it's being constructed/destructed at different times from the rest of the bases will have visible effects. Ok, now I see the problem, and one conceivable scenario for this is an intrusive ownership policy. It would most likely be empty, yet the cleanup would occur in the d'tor under my latest model, so that it has proper exception safety. Ouch. On the other hand, I just saw a reference to Josuttis Vandevoorde that I recalled reading whereby they refer to a BaseAndMember idiom in which they aggregate the non-empty parameter and derive from the emtpy one, relying on EBO to give optimal size. Once again, I might be able to reverse the logic and aggregate the empty member and derive from the non- empty one. I guess that depends on how well VC++ friends perform empty member optimization. [...] It's possible, but you don't yet have a single case of that you can point at, whereas you have quite a few cases of EBO failure in the MI case. I would be going with an organization that has never failed to be tight rather than trying to trick the compiler into tightening an organization that commonly bloats. That's true, but we're no longer talking about EBO failure. Even after the empty bases have been eliminated, we still get bloating. So it's just random size adjustment. But you're right that some testing might increase the confidence that the size won't go up. [...] It would be nice to have some assurance that this won't happen, but the current state of affairs with the MI setup doesn't exactly involve EBO I don't know what you mean by that. I mean, the optimally_inherit eliminates the empty bases, and yet there is size bloat. So VC++ makes the class bigger for some other reason than that it has empty bases. I will try to write some tests to see why that is, or at least how. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: SmartPtr - Exception safety reprise
Jason Shirk [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] oft.com... [...] If you aren't getting reasonably prompt responses to questions like this on MS newsgroups, send me a private email and I'll definitely follow up. Thanks for the offer. [...] As usual, you are absolutely correct. Backwards compatibility in our object model is critical. I seriously doubt we'll ever do the ZBO by default. [...] What can you say about empty member optimization in VC6.5 and later? Also, do you have any idea why an empty class that inherits from non-empty bases would be bigger than the sum of the size of the bases? Obviously, trivial test cases do not show this behaviour, but the policy_ptr in the sandbox does (though you'll probably have to wait till Monday afternoon for me to check in the latest version). Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [BGL] MutablePropertyGraph questions
Chris Russell wrote: Let me first describe my heterogeneous container hack and perhaps you could point why it's poor (your feel better on a quick read of your paper and this is a good way to help us all understand this a bit better). My goal was to be able to use standard STL containers and iterators with heterogeneous collections of objects. My hack was to declare a class CMoniker that takes a pointer to some CMonikerBase-derived class through a templated constructor. This constructor does two things: it casts the pointer to a void * and stores it in a private member. Additionally it uses RTTI to record the type. CMonikerBase is invasive; it provides reference counting for the object and operator overloads for STL containers. Any class that derives from CMonikerBase can then be stuffed into a CMoniker, and I then use the standard STL containers/iterators to work with homogenous collections. A CMoniker has a templated operator: template typename Type operator Type() that internally uses RTTI to test Type and throw an exception if it doesn't match the internal type squirreled away in the constructor. Ugly - yes. The filtering operation you propose in your paper is similar to little helper classes I write to enumerate elements in my some_stl_containerCMoniker to produce another container full of objects of a given type - again this is inelegant but it does seem to work. I'm probably wrong, but it looks like boost::any. I can't tell a difference, at least. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MetaMap (was: [BGL] MutablePropertyGraph questions)
Emily Winch [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... [...] b) The library uses the wrong approach to the problem and someone should submit something else. Where can we see the actual library? c) The library is not something that anyone would really use. (Hey, Jeremy. I'm sure you said you would use it). I would use it in my policy adaptor, if I could figure it out. Also, it would save me from having to reinvent it. And Aleksey said it would make a nice addition to MPL, if we're talking about the same thing. d) People think it's a great idea but just never got round to having a look or making any comments. I suspect this is most likely. Give it another shot. Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: associate_list( Was: [BGL] MutablePropertyGraphquestions)
Vladimir Prus wrote: ghost I think the best approach would be to make this concept explicit, and ghost independent from BGL. Something like ghost ghosttype_indexed_container ghost mpl::list ghost pairvertex_name_t, int , ghost pairvertex_distance_t, int c; ghostc[vertex_name_t()] = 10; ghost I wonder if something like this already exists... I vaguely recall ghost someone was doing that. Yes, Emily Winch was working on this, and I thought she was going to submit to boost. The following URL has a paper she wrote about this. http://www.oonumerics.org/tmpw01/schedule.html Personally, I did not really notice your announcements. Some time ago I wanted a dynamic type-indexed container, in which you specify the required type, and it's either returned, or created. After quite look on some email of yours I decided it's something different and stopped reading. i needed that (or maybe something similar) for the filesystem attributes in the sandbox. i tried to make it compatible to the property map concept. the output can be used as follows (taken from boost-sandbox/libs/filesystem/test/type_pm_test.cpp) boost::filesystem::detail:: type_property_map char pm; put int (pm, 'i'); put char (pm, 'c'); BOOST_TEST (get char (pm) == 'c'); BOOST_TEST (get int (pm) == 'i'); BOOST_TEST (get long (pm) == long ()); it is implemented using Lokis TypeInfo and a std::map TypeInfo, T where T is the type to store. it is possible to add another layer which sets T to boost::any and converts everything in overloaded get/put functions. the current attribute cache is (nearly) an example for that. boost::fs::cache c (path); std::cout get size (c); jan -- jan langer ... [EMAIL PROTECTED] pi ist genau drei ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
