David A. Greene wrote:
> [Posted to boost because MPL is not yet released. At what
> point should these questions go to boost-users?]
It's mainly the content of the message that determines whether it should be
posted here or to the Boost Users list; the status of the library - is it in
developm
David B. Held wrote:
> > In "C++ Templates: The Complete Guide" (Recommended), they give
> > this example on pages 106-107:
> >
> > typedef char RT1;
> > typedef struct {char a[2];} RT2;
> > template RT1 test(typename T::X const*);
> > template RT2 test(...);
> >
> > #define type_has_member_ty
On Thu, 05 Dec 2002 15:43:27 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Hmm. Well, if it's non-conforming we probably shouldn't use it. If
>it's just a vc bug, we could do something like
>
> #ifndef BOOST_STRICT_CONFIG
> # ifdef BOOST_MSVC
> # define BOOST_WORKAROUND(symbol, te
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> David B. Held wrote:
>> > In "C++ Templates: The Complete Guide" (Recommended), they give
>> > this example on pages 106-107:
>> >
>> > typedef char RT1;
>> > typedef struct {char a[2];} RT2;
>> > template RT1 test(typename T::X const*);
>> > temp
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Thu, 05 Dec 2002 15:43:27 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>Hmm. Well, if it's non-conforming we probably shouldn't use it. If
>>it's just a vc bug, we could do something like
>>
>> #ifndef BOOST_STRICT_CONFIG
>> # ifdef B
David Abrahams wrote:
I suppose not. What I really wanted was the ability to take a
regular old template class and create a generator out of it:
template
struct my_type { ... } // Note: no ::type member
typedef SHAZAM > generator;
typedef generator::template apply::type my_type_inst;
I want
Aleksey Gurtovoy wrote:
my_type is not a metafunction so maybe it just
can't be used conveniently with mpl.
Not now. However, I constantly keep finding more and more use cases to be
inclined to provide a built-in library support for this particular
metafunction's form - in particular, so that
Is my previous statement only valid if placement new used a reinterpret_cast
on it's implementation? Or if h.storage was reinterpret_cast-ed to a void*
when it was passed in? Well, if reinterpret_cast remembered the type, it
would know it wasn't what we were trying to cast it to.
Also, instead of
On Fri, 06 Dec 2002 09:05:38 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>You may be right. How about this approach instead?
>[...]
>
Sorry for the late reply. I'm certainly missing something here because
I thought the solution was just to replace "defined(symbol)" with "(0
< (symbol))". No?
I've just checked in boost/detail/workaround.hpp, which defines the
BOOST_WORKAROUND macro.
This macro can and should be used in place of explicit tests for
particular compiler/library/platform versions.
I've also gone through and replaced all the explicit tests in
boost/iterator_adaptors.hpp wi
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Fri, 06 Dec 2002 09:05:38 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>You may be right. How about this approach instead?
>>[...]
>>
>
> Sorry for the late reply. I'm certainly missing something here because
> I thought the solution was just
Hello Boosters
I am currently developing some template algorithm and had some trouble
using BCCL. I have an algorithm using a unary function as one of its
template parameter but I don't care about the result type of this unary
function (like the for_each standard algo). I can't use the
Una
François Wanadoo <[EMAIL PROTECTED]> writes:
> Hello Boosters
>
> I am currently developing some template algorithm and had some trouble
> using BCCL. I have an algorithm using a unary function as one of its
> template parameter but I don't care about the result type of this unary
> function
"Johan Nilsson" <[EMAIL PROTECTED]> writes:
> [cross-posted, but it seemed appropriate]
>
> Hi,
>
> just wanted to bring this one up: I've come across some problems putting
> boost source to an OpenVMS system: Filenames cannot include more than one
> dot ('.') - i.e. names like .cpp.html aren't al
le Vendredi 6 Décembre 2002 20:16, [EMAIL PROTECTED] écrivit :
> non-workaround code should appear first,
[...]
> So I suggest that we give in
> to reality and put the workaround code at the bottom of the chain of
> #if directives.
errr, I guess you meant the *non*-workaround code at the bottom
Hi,
Usually, we write regression tests that must compile and pass.
A compile failure is typically flagged as, ummm, failure.
There are times however when we explicitly want the compiler
to fail on some code to check for API conformance. Here's an
example from tuples:
tuple a;
#ifdef E11
a
"Joel de Guzman" <[EMAIL PROTECTED]> writes:
> Hi,
>
> Usually, we write regression tests that must compile and pass.
> A compile failure is typically flagged as, ummm, failure.
> There are times however when we explicitly want the compiler
> to fail on some code to check for API conformance. Her
Samuel Krempp <[EMAIL PROTECTED]> writes:
> le Vendredi 6 Décembre 2002 20:16, [EMAIL PROTECTED] écrivit :
>
>> non-workaround code should appear first,
>
> [...]
>
>> So I suggest that we give in
>> to reality and put the workaround code at the bottom of the chain of
>> #if directives.
>
> errr,
18 matches
Mail list logo
