Re: [boost] Re: [boost.optional && boost.variant] Why can't weallowreferences?
I've noticed that call_traits doesn't support function references. I'm not sure whether it makes sense to store function references in optionals, though, but in any case. Something like this fails: typedef void (&afuncref)(int); typedef call_traits::reference t; The problem is that the call_traits templates have other typedefs in the same class, e.g. const_reference, which gets instantiated as well, and it adds the const qualifier to a function type. GCC doesn't complain, but e.g. Intel does. Is it still illegal to form a function type with cv-qualifiers, or was there a DR about that? Jaakko In our last exciting episode "Joel de Guzman" wrote: > Joel de Guzman <[EMAIL PROTECTED]> wrote: > > Hi again, > > > Take 2: > > > typedef typename call_traits::param_type > > ctor_param; > > > typedef typename call_traits > remove_reference::type>::param_type assign_param; > > > typedef typename call_traits::reference > > return_type; > > > optional(typename call_traits::param_type arg); > > void reset(assign_param arg); > > return_type operator*(); > Whoops! That should be: > optional(ctor_param arg); > void reset(assign_param arg); > return_type operator*(); > Anyway, it's the same. > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Best Wishes, Jaakko Järvi ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: enable_if formal review ?
In our last exciting episode David Abrahams wrote: > Lines: 21 > User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt) > Cancel-Lock: sha1:xHnNZYZvlhxQjoXn7OJygCVNff4= > Jaakko Jarvi <[EMAIL PROTECTED]> writes: > > Hi Boosters, > > > > We submitted enable_if for formal review in July. The library does > > not seem to be on the review queue, and maybe it is not worth a full > > review. > I would be happy to leave that up to Thomas Witt, the review wizard. > As a matter of fact two different versions of enable_if are currently > being used within Boost already, and it has proven its usefulness and > general quality of design, so I don't think it would be too > unreasonable to simply add it without review. I would hope that upon > formalizing it you would also add the appropriate config symbols > (BOOST_NO_SFINAE) and tests to the config library (see > http://www.boost-consulting.com/boost/boost/iterator/detail/config_def.hpp) Ok. Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: enable_if formal review ?
In our last exciting episode Daniel Frey wrote: > Lines: 21 > User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 > Jaakko Jarvi wrote: > > The submitted version is in the sandbox: > > > boost/utility > > libs/utility > > > and in the Files section at YahooGroups. Note that none of the changes > > discussed above are currently in the code. > I think the current license is unacceptable. Did the boost license discussion lead to a result? Is there now on offical Boost License? Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] enable_if formal review ?
Hi Boosters, We submitted enable_if for formal review in July. The library does not seem to be on the review queue, and maybe it is not worth a full review. There was a kind of unofficial mini review after our submission, which brought up a few issues: 1. Whether to make enable_if MPL-aware or not. In the submitted version, the first parameter of the enable_if template is boolean, whereas some Boosters wanted it to be a type containing a boolean member constant named value. The latter plays better with MPL, and in some cases can avoid instantiating branches of conditional expressions (shortcircuiting). Close to consensus was reached that both versions of enable_if should be supported; naming was not decided on Dave Abrahams's suggestion was to use the name enable_if for the MPL-aware version, and enable_if_c for the version taking the boolean template parameter. We plan to adopt this naming convention. 2. Enable_if_lazy Some comments were against the name enable_if_lazy. We plan to change it to lazy_enable_if, particularly if the enable_if and enable_if_c naming convention is approved. 3. disable_if The submission included the disable_if template. The same functionality can be achieved with enable_if by negating the condition, and so someone asked it to be removed. On the other hand, there was opposition to its removal. We plan to keep disable_if for convenience. 4. Non-SFINAE compilers Dave has an implementation of enable_if which defaults to being always enabled for compilers that do not support SFINAE. We do not think this is the right approach, and believe that attemts to use enable_if on a compiler that does not support SFINAE, should cause an immediate error. 5. Non-partial specialization compilers Are there any compilers that support SFINAE but do not support partial specialization? If not, we plan to use partial specialization in our implementation. Do other Boosters think an official review is necessary, or what will the process be? The submitted version is in the sandbox: boost/utility libs/utility and in the Files section at YahooGroups. Note that none of the changes discussed above are currently in the code. Cheers, Jaakko & Jeremiah ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] arithmetic traits
In our last exciting episode "Neal D. Becker" wrote:
> User-Agent: KMail/1.5.3
> I'm thinking that it would be useful to implement a traits class that would
> give the return type of mixed scalar-complex arithmetic operations. This
> would allow one to write generic algorithms that operate on both scalar and
> complex types, inferring the return type.
> Any opinions?
Good idea.
That code probably exists in many places in boost in slightly
different variations.
I cleaned up a bit the code used in lambda for another project a while
back. I'm including that code + some test cases.
If you're willing to boostify the code, and write some docs, that'd be great.
If you decide not to use the attached code, the code anyway collects the
rules from the standard into one place.
The right place for the code would be the type traits library I guess.
Cheers,
Jaakko Järvi
The code:
--- type_promotion.hpp ---
#include
#include
#include
#include
#include
#include
// complex needs to be forward declared
namespace std {
template class complex;
}
namespace detail {
template struct promote_code;
template struct promotor;
template struct promote_to_int;
// A is guaranteed to have a higher promote code
// we need to do this, since otherwise it would be really hard
// to avoid ambigouous partial specializations for complex number promotion
template
struct ordered_promotor {
typedef A type;
};
// The unsigned int promotion rule is this:
// unsigned int to long if a long can hold all values of unsigned int,
// otherwise go to unsigned long.
template<>
struct ordered_promotor
{
typedef boost::mpl::if_<
boost::mpl::bool_<(sizeof(long) <= sizeof(unsigned int))>,
unsigned long,
long
>::type type;
};
// complex numbers are a special case
// this is not really the way complex type promotion is implemented
// in the standard library. Actually, arithmetic ops for complex numbers
// are only defined between:
// complex op complex
// complex op T
// T op complex
// but it does no harm to be a bit more thorough.
// e.g. complex + double -> complex
template
struct ordered_promotor, B> {
typedef std::complex::type> type;
};
template
struct ordered_promotor, std::complex > {
typedef std::complex::type> type;
// we know that this will be complex as A and B are ordered
};
// gives the two types promoted
template
struct promotor {
private:
// first step is to promote all integral types smaller than int to
// int
typedef typename promote_to_int::type A2;
typedef typename promote_to_int::type B2;
BOOST_STATIC_CONSTANT(int, A_code = promote_code::value);
BOOST_STATIC_CONSTANT(int, B_code = promote_code::value);
// check that our machinery knows about both type A and B
BOOST_STATIC_ASSERT(A_code != -1 || !"Invalid left scalar argument type");
BOOST_STATIC_ASSERT(B_code != -1 || !"Invalid right scalar argument type");
public:
typedef typename ordered_promotor<
typename boost::mpl::if_= B_code)>, A2, B2>::type,
typename boost::mpl::if_, B2, A2>::type
>::type type;
};
template
struct promote_code { static const int value = -1; };
// this means that a code is not defined for A
// For the next 5 types
// the promotion order is not important, but they must have distinct
// values.
template <> struct promote_code { static const int value = 10; };
template <> struct promote_code { static const int value = 20; };
template <>
struct promote_code { static const int value = 30; };
template <>
struct promote_code { static const int value = 40; };
template <>
struct promote_code { static const int value = 50; };
// --
template <> struct promote_code { static const int value = 100; };
template <>
struct promote_code { static const int value = 200; };
template <> struct promote_code { static const int value = 300; };
template <>
struct promote_code { static const int value = 400; };
template <> struct promote_code { static const int value = 500; };
template <> struct promote_code { static const int value = 600; };
template <>
struct promote_code { static const int value = 700; };
// TODO: wchar_t
template <> struct promote_code< std::complex > {
static const int value = 800;
};
template <> struct promote_code< std::complex > {
static const int value = 900;
};
template <> struct promote_code< std::complex > {
static const int value = 1000;
};
// -- int promotion ---
template struct promote_to_int { typedef T ty
[boost] Re: Review request: enable_if
In our last exciting episode Markus Werle wrote:
> Lines: 24
> Mail-Copies-To: [EMAIL PROTECTED]
> User-Agent: KNode/0.6.1
> Jaakko Jarvi wrote code that looks like this:
> template
> struct disable_if: public enable_if< !B, T> {};
> I have a question regarding compile time:
> Do you have experience about whether this elegant solution
> might have some compile time penalty due to inheritance?
> Or is this faster than doubling the code?
We have made no measurements. The use of inheritance is motivated by getting
a miniscule bit of reuse.
If another formulation leads to better compile-time or runtime
performance, it's worth while to change.
Cheers, Jaakko
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review request: enable_if
In our last exciting episode Thomas Witt wrote: > User-Agent: KMail/1.5 > On Wednesday 09 July 2003 21:09, Jaakko Jarvi wrote: > > Where we've used enable_if, it has been very common that the condition > > is not just a single traits lookup, but rather a logical expression, > > e.g.: > > > > template > > typename enable_if::value && is_vector::value,...>::type > > operator*(const T& t, const U& u); > Ok I can see the problem, but what about > template > typename enable_if< mpl::and, is_vector >,...>::type > operator*(const T& t, const U& u); Would work. Requires some knowledge of mpl and a tiny file to be included, though. Our view is still that at least the enable_if version is needed. The mpl-aware enable_if would be good to have too. Jaakko & Jeremiah ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Review request: enable_if
In our last exciting episode Howard Hinnant wrote:
> On Wednesday, July 2, 2003, at 06:06 PM, Jaakko Jarvi wrote:
> > libs/utility/test/enable_if*
> Would it be possible to augment the enable_if_constructors.cpp test
> with a templated container? Maybe something like:
Yes it would be possible. Just committed in.
Breaks in g++ 3.2.
ICC 7 accepts.
Metrowerks? Must works, you wouldn't have asked otherwise, right :)
Jaakko
> template
> struct string
> {
>template
>string(It begin, It end, typename
> enable_if::value>::type* = 0)
> : data(end-begin) {}
>int data;
> };
> #include
> int main (int ,char *[])
> {
> char sa[] = "123456";
> assert(string(sa, sa+6).data == 6);
> }
> Thanks,
> -Howard
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Regards,
Jaakko Järvi
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review request: enable_if
Where we've used enable_if, it has been very common that the condition is not just a single traits lookup, but rather a logical expression, e.g.: template typename enable_if::value && is_vector::value,...>::type operator*(const T& t, const U& u); So definitely, this version of enable_if is needed. Jaakko & Jeremiah In our last exciting episode Thomas Witt wrote: > User-Agent: KMail/1.5 > I doubt that the _c version are needed frequently enough to warrant the extra > types. > Thomas > -- > Dipl.-Ing. Thomas Witt > Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover > voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 > http://www.ive.uni-hannover.de > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Review request: enable_if
In our last exciting episode Markus Werle wrote:
> With enable_if this can be reduced to say it once and for all times:
> Users just have to specialize a traits class
> template struct DaixtroseTraits
> {
> enum { use_default_ops = false };
> };
> and I change my operators to
> template enable_if
> <
> (
> (DaixtroseTraits::use_default_ops == true)
> &&
> (DaixtroseTraits::use_default_ops == true)
> ),
> SomeComplicatedType
> >::type
> operator+(T1 const &, T2 const &);
> and move them from namespace Daixtrose::Defaultops to namespace Daixtrose.
> What do You think? Did I miss any side effects?
I don't think you missed anything. That's the way it works, and it is
what we've been using in an ET-capable library for a while.
Cheers, Jaakko
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Review request: enable_if
Dear Boosters,
The enable_if library defines the enable_if and disable_if templates,
which are tools for controlling which function templates are included
in the overload resolution set based on the properties of the argument
types.
The following example demonstrates their use:
template
typename enable_if::value, void>::type foo(T t) {
std::cout << "An arithmetic type\n";
}
template
typename disable_if::value, void>::type foo(T t) {
std::cout << "Not an arithmetic type\n";
}
foo(1); // outputs "An arithmetic type"
foo("1"); // outputs "Not an arithmetic type"
The first function is only included in the overload resolution set if
the boost::is_arithmetic::value is true, whereas the second
function is only included when boost::is_arithmetic::value is
false.
The enable_if template can also be used to control which partial
specializations are considered when searching for the most specialized
template.
The submission is available in the files section under the enable_if
directory.
The files are also available in the boost-sandbox in:
boost/utility/enable_if.hpp
libs/utility/doc/enable_if.html
libs/utility/test/enable_if*
We ask you to note the following during the review:
No commenting on the license is necessary. The current license is
potentially not Boost compatible, but is permissive enough for this
review, and will be replaced with a Boost compatible (the standard
Boost license?) one if the library is accepted to Boost.
The directory structure in the tar-ball (or zip-ball) does not fully
reflect boost directory structure. The library is intended to be part
of Boost.Utility, and be included as part of including
"boost/utility.hpp".
There's no Jamfile yet, but there is a Makefile that compiles and runs
all the tests. Note that GCC 3.2 fails on the test:
enable_if_no_disambiguation.cpp
Best Regards,
Jaakko Järvi, Jeremiah Willcock and Andrew Lumsdaine
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Draft of new Boost Software License
Hi Beman & others, One thing is slightly confusing. The second paragraph says: The copyright notice in the Software and this entire statement, _including the above license grant_, this restriction and the following disclaimer, must be included ... The author of a derivative work can put in a more restrictive license right? In this case, wording that gives the full Boost permission must still be included according to the draft license. This would lead to a license text like: "Permission is hereby granted, free of charge,..." "No, no, no... I didn't really mean that. You must pay ..." Best, Jaakko Järvi & Jeremiah Willcock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] lambda bugs ?
The bug is in the documentation.
All of the compilers are right. The complier can choose to evaluate
i=2 before _1+i which results in the lambda functor
_1 + 2
or _1+i before i=2 which gives
_1 + 1
Anyway, the point of the documentation was to say that the lambda functor
stores the value of i at the time of creating the lambda functor, and
the actual argument to later replace _1 will be passed by reference.
So no side effects via the stored arguments.
The example in the docs is just badly chosen.
Jaakko
On Fri, 30 May 2003, firingme wrote:
> consider the following code :
>
> test.cpp
> *
> #include
> #include
>
> #include
> #include
> #include
> #include
>
> using namespace std ;
> using namespace boost ;
> using namespace boost::lambda;
>
> int main(){
> int i = 1 ;
> cout << ( _1+i)(i=2) << endl;
> }
> *
>
> Result Table:
> *
> Compiler Result
>
> VC7.14
> GCC3.2.3 ( MingW versiong ) 4
> GCC3.3 (i686-pc-cygwin)3
>
> as in lambda's doc , the result should be 3 .
>
> Any help is welcome
>
>
> thx
>
>
>
>
>
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [lambda] gcc 2.95.2?
I applied the patch. So for gcc < 2.96, lambda now includes deque, and
works as a compensation for this extra dependency.
Jaakko
On Thu, 22 May 2003, Daniel Frey wrote:
> Jaakko Jarvi wrote:
> > I can't now even get the deque error you mention, can you send me
> > the error listing (maybe outside of boost list). Maybe there is a better
> > way to fix it instead of including deque.
>
> The error was exactly what I quoted in the first posting of this thread.
> The gcc uses a non-conformant deque which has a third parameter, thus
> the forward declaration doesn't work.
>
> Here's the patch for boost/lambda/detail/operator_return_type_traits.hpp:
>
> 26a27,37
> > // The GCC 2.95.x uses a non-conformant deque
> > #if BOOST_WORKAROUND(__GNUC__, == 2) && __GNUC_MINOR__ <= 96
> > # include
> > #else
> >
> > namespace std {
> > template class deque;
> > }
> >
> > #endif
> >
> 869d879
> < template class deque;
>
> Please note that I'm not sure about the status of gcc 2.95.3 or other
> sub-versions, so please someone with more experience have a look at
> this, I'm sure it can be improved :)
>
> 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
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [lambda] gcc 2.95.2?
Hi, The problems with 2.95 were in bind overloads and deducing function references, if I remember correctly. However, the bind overloading was changed at some point for other reasons, and that can have fixed the trouble. I can't now even get the deque error you mention, can you send me the error listing (maybe outside of boost list). Maybe there is a better way to fix it instead of including deque. Cheers, Jaakko On Thu, 22 May 2003, Daniel Frey wrote: > I should also mention that I have a patch which solves the problem by > replacing the forward declaration of deque with a real include in > boost/lambda/detail/operator_return_type_traits.hpp. Really > strait-forward. But am interested in the general support of lambda for > this compiler, as the problem I had will most likely occur for anyone > using the gcc 2.95.2 immediately and I haven't found any other problem > after the patch... > > 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 > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Outstanding patches and fixes
On Wed, 12 Mar 2003, Beman Dawes wrote: > Here is my list of outstanding patches and fixes. It would be great if we > could resolve the bulk of these for 1.30.0. > > * tuples::apply >Did this every get resolved? Aleksey? Jaakko? Aleksey's message on Feb 15 had slipped by :( Looking at his proposed addition, it's really great! IMO C++ should really treat an argument list of a function as a tuple, and Aleksey's apply comes really close to that. However, with this schedule, it is up to Aleksey to decide whether to put it in to 1.30. In any case 1.31 will have bigger tuple changes (Doug's iteration mechanisms), so apply can go into 1.31 if not now. Cheers, Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] The Wonder of Tuples
> Aleksey Gurtovoy wrote:
> > David A. Greene wrote:
> >
> >>The fundamental problem is that it's inconvenient to iterate through a
> >>tuple.
> >
> >
> > 'tuple_ext' ("tuple extensions") make it easier -
> > http://groups.yahoo.com/group/Boost-Users/message/704.
>
> Has any discussion taken place about incorporating something like
> this into Boost? Seems like a useful bit of code.
>
There has been some out-of-list discussion about this, and some work is
being done. There's a PP based tuple implementation (mostly written by
Joel) in Spirit's CVS that conforms to the Tuple speicification in the TR.
(Note that the current Boost.Tuples is not one-to-one what was accepted
into the TR. Most notably, the cons-list interface was not standardized.)
The PP based tuples are not complete yet, and what the iteration interface
will be is still undecided.
/Jaakko
--
--
-- Jaakko Järvi email: [EMAIL PROTECTED]
-- Post Doctoral Fellow phone: +1 (812) 855-3608
-- Pervasive Technology Labs fax: +1 (812) 855-4829
-- Indiana University, Bloomington
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost::lambda::call_xxx, right or wrong?
The algorithm.hpp header is badly broken in 1.29 (wrong file
in the wrong place at the wrong time). This is fixed in the cvs main
trunk.
The following program compiles and runs fine (with gcc3.2).
Cheers, Jaakko
// --
#include
#include
#include
#include
#include
using namespace boost::lambda;
int main() {
std::vector b1;
b1.push_back(1); b1.push_back(2);
std::vector b2;
b2.push_back(3); b2.push_back(4); b2.push_back(5);
std::vector > a;
a.push_back(b1);
a.push_back(b2);
int sum = 0;
std::for_each(a.begin(), a.end(),
bind(ll::for_each(),
bind(call_begin(), _1), bind(call_end(), _1),
protect(sum += _1)));
std::cout << "sum = " << sum << "\n";
}
// --
On Tue, 10 Dec 2002, Robin.Hu wrote:
> Hi Boosters:
>
>In the document of boost::lambda (ar01s05.html#sect:nested_stl_algorithms),
> it says:
> -->cited begin<---
>Some aid for common special cases can be provided though. The BLL defines two
>helper function object classes, call_begin and call_end, which wrap a
>call to the begin and, respectively, end functions of a container,
>and return the const_iterator type of the container. With these
>helper templates, the above code becomes:
>
>std::for_each(a.begin(), a.end(),
> bind(ll::for_each(),
> bind(call_begin(), _1), bind(call_end(), _1),
> protect(sum += _1)));
> --->cited end<-
>
>But I failed to compile this example with gcc 3.2 and vc 2003 beta.
> I think the problem is, both struct call_begin and struct call_end dont
> provide a result_type.
>
> [lambda/algorithm.hpp]
> --->cited begin<---
> #define CALL_MEMBER(X) \
> struct call_##X { \
> template \
> struct sig { \
> typedef typename boost::remove_const< \
> typename boost::tuples::element<1, Args>::type \
> >::type::const_iterator type; \
> }; \
>\
> template\
> typename T::const_iterator \
> operator()(const T& t) const \
> {\
> return t.X(); \
> }\
> };
> --->cited end<-
>
> Is there anything I missed? And is there a possibel way to make these
> call_xxx run?
>
>
--
--
-- Jaakko Järvi email: [EMAIL PROTECTED]
-- Post Doctoral Fellow phone: +1 (812) 855-3608
-- Pervasive Technology Labs fax: +1 (812) 855-4829
-- Indiana University, Bloomington
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Lambda and Borland C++
On Sun, 1 Dec 2002, John Maddock wrote: > I'm wondering if it's possible to get Lambda working with Borland's > compiler? I can help the best I can if someone wants to take up the task. Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: strict_weak_ordering
> >> make_tuple(ref(x1), ref(y1), ref(z1)) < ... > > > > Isn't this equivalent to > > > > tie(x1, y1, z1) < tie(x2, y2, z2) > > > > ? > > I think so! It is. /Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] strict_weak_ordering
> > Yes, I agree about the name change. Sorry if the previous post seemed a > bit abrupt, I just dashed it off while waiting for a compile and it didn't > come out exactly as I intended. I was just trying to make the point that a > general comparison function which "does the right thing" is actually a > more basic concept than a tuple library, so that if one were to be > implemented in terms of the other, the tuple library should use the > comparison function (Although this is just speaking hypothetically, I am > not suggesting changing the tuple library). It wouldn't fit with the current implementation of tuples as cons lists. Comparisons are now defined as: comapre heads, recurse to tails if needed. To use these strict_weak_ordering functions, we would first need to unpack the tuple into distinct argument slots. /Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: high order type traits and MPL
> > > Does anybody know how to implement type traits that will allow me to > check > > > whether argument type T is instance od template A. Particularly I am > > > interested in mpl sequences. I.e.: > > > > > > is_instance_of::value > > > > Check out boost/lambda/detail/is_instance_of.hpp > > 1. Could we make it an "official" type trait? Sure. John, do you agree? > 2. Could we make if work with no template template support? > I was thinking about: > is_instance_of >::value > But I do not understand how mpl::lambda is working yet, so it could be > complete nonsense. I'm not aware of a solution without template template parameters. > 3. Why there is no namely is_instance_of version without number of template > parameters explicitly specified. > Could not you deduce it automatically? The second argument is a template template parameter, and I think that type must be spelled out entirely, thus I can't see a way to get rid of the n in is_instance_of_n. I hope someone can prove me wrong. > 4. Why it is limited only to 4 template parameters? Well, 4 met the needs of LL, and it never got extended as it wasn't made to an 'official' type trait. Note that there are other limitations, templates with non-type parameters are not supported. Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] tuples doc problem
> > The advanced features page doesn't say which namespace classes such as > boost::tuples::null_type reside in, AFAICT. If I just missed it, it > needs to be clarified. Hi Dave, It's the first sentence in the document: "The advanced features described in this document are all under namespace ::boost::tuples" Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] high order type traits and MPL
On Fri, 15 Nov 2002, Gennadiy Rozental wrote: > Hi, > > Does anybody know how to implement type traits that will allow me to check > whether argument type T is instance od template A. Particulaly I am > interested in mpl sequences. I.e.: > > is_instance_of::value Check out boost/lambda/detail/is_instance_of.hpp /Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Named Template Parameters implementation
> OK, I read the docs, followed the example and *tried* to use it in the > library. > Unfortunately, I received tons of mysterious compiler errors with BCC55; > apparently as a result of the usage of template template parameters in > ntp::as_named<>. as_named is needed if you allow an argument slot to accept both unnamed and named template parameters. You should be able to go around the need for template template parameters by 'expanding' as_name by hand: instead of typename boost::ntp::as_named::type write: typename boost::mpl::if_c::value, T, Model_is >::type Are there other things that cause trouble with your compiler? /Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Named Template Parameters implementation
> > Don't know about state of the art, but this library tries to do a > > decent job: > > > > libs/named_template_parameters in boost sandbox. > > > Opps! In my previous message (hope it arrives before this one); No it didn't :) I asked you > to give me an example of how to use it... > But I missed the "/lib" part... I just looked at the header file. Yes, the documentation is quite detailed. That's actually what the "library" really is, a set of conventions. The header is really tiny. The intention was to submit named parameters as a separate library. It was already discussed some months ago. There was some controversy, mainly someone wanted even more general mechanism, which was syntactically a bit heavier. I'll look through the code and docs and see if all still makes sense. If so I'll go ahead and request a formal review. And if you need the library now, just go ahead and grab it and use it. It's just a one small include file, the location of which is easy to change, if it becomes a boost library, instead of an internal part of your library. /Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Named Template Parameters implementation
On Fri, 15 Nov 2002, Fernando Cacciola wrote: > As a final touch in the Numeric Conversion library I have almost ready, I > want to add it named template parameters for easier usage. > Were can I borrow the State of the Art implementation of this idiom from? Don't know about state of the art, but this library tries to do a decent job: libs/named_template_parameters in boost sandbox. /Jaakko ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
