All --
The Variant library by Eric Friedman and Itay Maman has been accepted into boost.
I have summarized the main issues/discussion points below.
[Interface/Design]
-- There was a long discussion about a better name for 'extract' and whether it
should be a member or free function. I'm n
Andreas Huber wrote:
> Hi Aleksey
Hi Andreas,
>
> Sometimes I have to pass an abstract class to mpl::aux::msvc_eti_base.
> On MSVC7.0 the compiler complains with the following error:
>
> d:\Data\boostCvsRoot\boost\boost\mpl\aux_\is_msvc_eti_arg.hpp(48) :
> error C2259: 'boost::mpl::inherit2' : ca
At 06:23 PM 3/9/2003, David Abrahams wrote:
>is ";" legal where a declaration is expected?
>
>class X
>{
> ; // legal?
>};
>
>Comeau says it isn't:
>
>MODE:strict errors C++
>
>"ComeauTest.c", line 3: error: extra ";" ignored,
>In C: A function definition does not end with a semicolon
>
>From: "David Abrahams" <[EMAIL PROTECTED]>
> Terje Slettebø <[EMAIL PROTECTED]> writes:
>
> >>From: "David Abrahams" <[EMAIL PROTECTED]>
> >
> >> I like the basic idea, but are you sure it will work in all the
> >> contexts where BOOST_STATIC_ASSERT works? I think BOOST_STATIC_ASSERT
> >> functi
"Jaap Suter" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [...]
> The proposal doesn't say anything about a compile time release and
> debug mode. I guess one could always define the 'static_assert'
> keyword to be nothing, but perhaps compiler support for disabling
> and enabling
Hi,
I've attached a version of static_assert.hpp that I would find rather
useful. The minimal changes are at the bottom of the file.
It also had me thinking about the static_assert proposal:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1381.htm
The proposal doesn't say anything about
> Then how about simply:
>
> #ifndef STATIC_NDEBUG
> #define BOOST_STATIC_ASSERT2(e) BOOST_STATIC_ASSERT(e)
> #else
> #define BOOST_STATIC_ASSERT2(e)
> #endif
I guess that ';' would work in most cases. I can't think of a case where it
wouldn't, although it can give warnings on some compile
Terje Slettebø <[EMAIL PROTECTED]> writes:
>>From: "David Abrahams" <[EMAIL PROTECTED]>
>
>> Dirk Gerrits <[EMAIL PROTECTED]> writes:
>>
>> > Dirk Gerrits wrote:
>> > >
>> > > I'd say something like:
>> > >
>> > > #ifdef STATIC_NDEBUG
>> > > #define BOOST_STATIC_ASSERT2(e) BOOST_STATIC_AS
>From: "David Abrahams" <[EMAIL PROTECTED]>
> Dirk Gerrits <[EMAIL PROTECTED]> writes:
>
> > Dirk Gerrits wrote:
> > >
> > > I'd say something like:
> > >
> > > #ifdef STATIC_NDEBUG
> > > #define BOOST_STATIC_ASSERT2(e) BOOST_STATIC_ASSERT(e)
> > > #else
> > > #define BOOST_STATIC_A
Dirk Gerrits <[EMAIL PROTECTED]> writes:
> Dirk Gerrits wrote:
> >
> > I'd say something like:
> >
> > #ifdef STATIC_NDEBUG
> > #define BOOST_STATIC_ASSERT2(e) BOOST_STATIC_ASSERT(e)
> > #else
> > #define BOOST_STATIC_ASSERT2(e) (void(e))
> > #endif
> >
> > Analogous to .
>
> Arg
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Sun, 09 Mar 2003 09:11:05 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>Gennaro Prota <[EMAIL PROTECTED]> writes:
>>
>>> On Sat, 08 Mar 2003 15:31:58 -0500, David Abrahams
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
"Make 'em MPL-compatible me
>From: "Jason House" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
> >
> > >From: "Jason House" <[EMAIL PROTECTED]>
> >
> > > Is there even a way to specify/change that?
> >
> > It isn't currently, as the fundamental types aren't handled as composite
> > types, and therefore aren't formatted using
>From: "Vladimir Prus" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
>
> > Right. There was a suggestion for allowing generic formats, though,
using
> > the same format for all instantiations of a template. The question is
how
> > to do it. The current version stores the format for each specific typ
Hi Aleksey
Sometimes I have to pass an abstract class to mpl::aux::msvc_eti_base. On
MSVC7.0 the compiler complains with the following error:
d:\Data\boostCvsRoot\boost\boost\mpl\aux_\is_msvc_eti_arg.hpp(48) : error
C2259: 'boost::mpl::inherit2' : cannot instantiate abstract class ...
The follow
I guess you meant it to be the other way around:
> #ifdef STATIC_NDEBUG
> #define BOOST_STATIC_ASSERT2(e) (void(e))
> #else
> #define BOOST_STATIC_ASSERT2(e) BOOST_STATIC_ASSERT(e)
> #endif
I like the solution, but I'm wondering whether mabye this could be included
in the static_assert he
Dirk Gerrits wrote:
> Jaap Suter wrote:
>
>> Hi,
>>
>> In my own meta-programming I tend to use a lot of static_asserts and
>> concept
>> checks. However, these do have a negative impact on my compile-times.
>> Take,
>> for example, a meta-function that takes a type-list as its parameter.
>> Assume
Jaap Suter wrote:
Hi,
In my own meta-programming I tend to use a lot of static_asserts and concept
checks. However, these do have a negative impact on my compile-times. Take,
for example, a meta-function that takes a type-list as its parameter. Assume
a pre-condition is that the list may not be em
Hi,
In my own meta-programming I tend to use a lot of static_asserts and concept
checks. However, these do have a negative impact on my compile-times. Take,
for example, a meta-function that takes a type-list as its parameter. Assume
a pre-condition is that the list may not be empty. What I can do
Beman Dawes <[EMAIL PROTECTED]> writes:
> At 10:50 AM 3/9/2003, David Abrahams wrote:
> >
> >Just browsing, I noticed:
> >
> > if ( !file )
> >throw fs::filesystem_error( "process_jam_long.cpp",
> > pth, "can't open output file" );
> >
> >But I can't find a catch bloc
On Sun, 09 Mar 2003 09:11:05 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota <[EMAIL PROTECTED]> writes:
>
>> On Sat, 08 Mar 2003 15:31:58 -0500, David Abrahams
>> <[EMAIL PROTECTED]> wrote:
>>
>>
>>>"Make 'em MPL-compatible metafunctions."
>>^^^
>> | which ones
Beman Dawes <[EMAIL PROTECTED]> writes:
> Yes:
>
> int cpp_main( int argc, char ** argv )
>
>
> So execution_monitor will take care of the catch.
Ah, thanks very much.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsub
Hi all,
I have a problem while using the iterator_adaptor templates in
conjunction with a istreambuf_iterator (an input_iterator type).
The problem shows up, because the istreambuf_iterator::operator*()
implementation of the STL I'm using returns a value_type (char), but the
dereference policy me
At 10:50 AM 3/9/2003, David Abrahams wrote:
>
>Just browsing, I noticed:
>
> if ( !file )
>throw fs::filesystem_error( "process_jam_long.cpp",
> pth, "can't open output file" );
>
>But I can't find a catch block anywhere in the program. Am I missing
>something?
Yes:
int cpp_
Just browsing, I noticed:
if ( !file )
throw fs::filesystem_error( "process_jam_long.cpp",
pth, "can't open output file" );
But I can't find a catch block anywhere in the program. Am I missing
something?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
_
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Sat, 08 Mar 2003 15:31:58 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>
>>"Make 'em MPL-compatible metafunctions."
>^^^
> | which ones?
All of the traits. For example:
template
struct const_min
: integral_c
{};
> P
--- Craig Henderson <[EMAIL PROTECTED]> wrote:
[...]
> template
> struct myval2
> {
> BOOST_STATIC_CONSTANT(int, value=T::value);
>
> myval myval_obj; // <-- BCC error E2231
> };
This is a classic for Borland :-/ All the times I've encountered it, it always
went away by qualifying th
Paul Snively wrote:
> Secondly, ast_xml.cpp takes a long time to compile--and no wonder; CW
> Pro 8.3 generates ~14 megabytes for it!
I assume that's debug mode? release mode should be so much smaller.
I've had good results with CW7.2 on Windows and I believe the CW
compiler is very good. For exa
Hi all,
I have stumbled across a problem using the BCC5.5.1 compiler that may
highlight an incompatibility with the BOOST_NO_INCLASS_MEMBER_INITIALIZATION
macro. The problem is best described by way of an example, so I have pasted
a complete repro case below.
The problem comes about using the BOO
It doesn't look like this change was ever made. Would you still like to see
it made? Does anyone have an objection? It would only affect the IBM
compiler.
(I'm trying to make sure that patches haven't fallen on the floor. Please
excuse the bother if the patch was not applied because it was reject
> > Well, I think you're right, but the question remains: what should we
> > do about it? Should we just replace BOOST_DEDUCED_TYPENAME?
>
> That's what I would do. John?
>
> Aleksey
If I remember correcty Dave introduced that macro anyway, so yes go ahead
and change it- can you make sure that t
On Sat, 08 Mar 2003 15:31:58 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>"Make 'em MPL-compatible metafunctions."
^^^
| which ones?
PS: why the quotes? :-)
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mail
31 matches
Mail list logo
