Hello,
I promised to get back with some timings for the compiletime debug and
release discussion.
I've tested it with my own projets which makes heavy use of
BOOST_STATIC_ASSERTS in many places, particularly in the meta equivalent of
tight inner-loops. Here are some examples of static asserts I'm
On Wed, 12 Mar 2003 11:13:51 -0700, Greg Colvin
<[EMAIL PROTECTED]> wrote:
>>Exactly. And if the time it takes is different then the effect is not
>>the same to me :-)
>
>Measurements, please?
Be patient :-) I asked for empirics too and Jaap said he will do some
benchmark. Also, I said *if* the t
At 06:06 AM 3/12/2003, Gennaro Prota wrote:
>On Wed, 12 Mar 2003 02:15:48 -0800, "Jaap Suter"
><[EMAIL PROTECTED]> wrote:
>
>>> The effect is the same.
>>> However, (a) or BOOST_STATIC_ASSERT_IMPL( true ) avoids all of the
>>> (potential?) problems you are worrying about. So why do you prefer
>>> (
On Wed, 12 Mar 2003 02:15:48 -0800, "Jaap Suter"
<[EMAIL PROTECTED]> wrote:
>> The effect is the same.
>> However, (a) or BOOST_STATIC_ASSERT_IMPL( true ) avoids all of the
>> (potential?) problems you are worrying about. So why do you prefer
>> (b)?
>
>Because if we do this to save time, we might
>> Well, considering that what we want is just a no-op, which do you
>> prefer?
>>
>> a) typedef ::boost::static_assert_test<
>> sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( true ) >)>
>> BOOST_JOIN(boost_static_assert_typedef_, _LINE_);
>>
>> (I've just picked up one of the im
Gennaro Prota wrote:
On Tue, 11 Mar 2003 17:46:17 +0100, Dirk Gerrits
<[EMAIL PROTECTED]> wrote:
Perhaps I missed a part of the discussion, but what is wrong with Jaap's
suggestion:
#ifdef BOOST_STATIC_NDEBUG
#define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true )
#else
#define
On Tue, 11 Mar 2003 17:46:17 +0100, Dirk Gerrits
<[EMAIL PROTECTED]> wrote:
>> In effect I would prefer the one without __LINE__. But if any compiler
>> warns about duplicate typedefs than it's better having a single
>> version, with __LINE__, than #ifs.
>>
>> Also I have a slight preference for
Gennaro Prota wrote:
On Mon, 10 Mar 2003 20:41:26 -0800, "Jaap Suter"
<[EMAIL PROTECTED]> wrote:
#define BOOST_STATIC_ASSERT(c) \
typedef char boost_static_assert_typedef
When using several asserts in the same context some compilers could
complain about the duplicate typedef; if so past
On Mon, 10 Mar 2003 20:41:26 -0800, "Jaap Suter"
<[EMAIL PROTECTED]> wrote:
>> #define BOOST_STATIC_ASSERT(c) \
>>typedef char boost_static_assert_typedef
>>
>> When using several asserts in the same context some compilers could
>> complain about the duplicate typedef; if so pasting t
> Anyway, as Terje says, if the compile-time cost of the static
> assertion is mainly in the evaluation of the condition then the
> 'release mode' definition could simply be
>
> #define BOOST_STATIC_ASSERT(c) \
>typedef char boost_static_assert_typedef
>
> When using several asserts in
On Sun, 09 Mar 2003 20:23:39 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>is ";" legal where a declaration is expected?
>
>class X
>{
> ; // legal?
>};
No. C++ has a "null statement" (expression-statement without the
expression part) but not no "null declaration". The grammar seems to
allo
#define BOOST_STATIC_ASSERT( B ) \
typedef void BOOST_JOIN(boost_static_assert_typedef_, __LINE__)
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sun, 09 Mar 2003 20:23:39 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Comeau says [...]
> In C++: A function definition ... does not end with a semicolon
A function definition appearing within a class definition may end with
a semicolon though:
class X {
void foo() {}; // see
Jaap Suter wrote:
[snip]
#ifdef BOOST_STATIC_NDEBUG
#define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( true )
#else
#define BOOST_STATIC_ASSERT( B ) BOOST_STATIC_ASSERT_IMPL( B )
#endif
Yes much better. I don't see any problems with this, does anyone?
Regards,
Dirk Gerrits
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
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
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
23 matches
Mail list logo
