Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > more portable compile-time assert()

Reply
Thread Tools

more portable compile-time assert()

 
 
Ark Khasin
Guest
Posts: n/a
 
      01-13-2008
Justin Spahr-Summers wrote:
> I recently started using something along these lines (influenced from
> somewhere, but not sure where off-hand):
> #define ASSERT_NAME(name, cond) \
> do { \
> typedef int name ## _assertion_failed[(int)(cond) * 2 - 1]; \
> } while (0)
>
> I personally like using a "name" argument to the macro to avoid
> collisions when using __LINE__.

Suggestions:
1 - Remove spurious "do{" and ";}while(0)". Then you'd be able to use
ASSERT_NAME outside of any block, where "compile-time asserts" ought to be.
2 - There is still a small chance of name collision; to avoid it safely
and forever, replace "typedef" with "extern"
3 - If #2 is done, you no longer need the "name" argument, which fact
simplifies the matters.
Hmmm... After all these are done, what remains is effectively the same
as I posted elsethread.
--
Ark
 
Reply With Quote
 
 
 
 
Laurent Deniau
Guest
Posts: n/a
 
      01-14-2008
On 13 jan, 06:34, Ark Khasin <(E-Mail Removed)> wrote:
> Justin Spahr-Summers wrote:
> > I recently started using something along these lines (influenced from
> > somewhere, but not sure where off-hand):
> > #define ASSERT_NAME(name, cond) \
> > do { \
> > typedef int name ## _assertion_failed[(int)(cond) * 2 - 1]; \
> > } while (0)

>
> > I personally like using a "name" argument to the macro to avoid
> > collisions when using __LINE__.

>
> Suggestions:
> 1 - Remove spurious "do{" and ";}while(0)". Then you'd be able to use
> ASSERT_NAME outside of any block, where "compile-time asserts" ought to be.
> 2 - There is still a small chance of name collision; to avoid it safely
> and forever, replace "typedef" with "extern"


more importantly than name collision, typedef doesn't garantee a
compile-time error:

#define ASSERT_NAME(name, cond) \
typedef int name ## _assertion_failed[(cond)?1:-1]

void f(int n)
{
ASSERT(n > 0); // compile
}

> 3 - If #2 is done, you no longer need the "name" argument, which fact
> simplifies the matters.


providing a tag or a name should trigger some better error message.
And still name collision may happen with extern:

#define LIB_ASSERT(cond) \
extern int dummy_assert_array[(cond)?1:-1]

LIB_ASSERT(sizeof(long) >= sizeof(void*));

#define ASSERT(cond) \
extern char dummy_assert_array[(cond)?1:-1]

ASSERT(sizeof(long) >= sizeof(void*));

while this has little chance to happen, it must still be considered in
case of a third party lib use the same trick and the same name but
with a different type.

> Hmmm... After all these are done, what remains is effectively the same
> as I posted elsethread.


a+, ld.
 
Reply With Quote
 
 
 
 
Ark Khasin
Guest
Posts: n/a
 
      01-17-2008
Laurent Deniau wrote:
>> 3 - If #2 is done, you no longer need the "name" argument, which fact
>> simplifies the matters.

>
> providing a tag or a name should trigger some better error message.
> And still name collision may happen with extern:
>
> #define LIB_ASSERT(cond) \
> extern int dummy_assert_array[(cond)?1:-1]
>
> LIB_ASSERT(sizeof(long) >= sizeof(void*));
>
> #define ASSERT(cond) \
> extern char dummy_assert_array[(cond)?1:-1]
>
> ASSERT(sizeof(long) >= sizeof(void*));
>
> while this has little chance to happen, it must still be considered in
> case of a third party lib use the same trick and the same name but
> with a different type.
>

IMHO, third party lib should not define any of this stuff in its public
header(s).

Anyway, that's simple to deal with:
#define dummy_assert_array my_very_own_assert_array

If you still have a collision with somebody else's names, change the macro.

--
Ark
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Portable Python - free portable development environment ! perica.zivkovic@gmail.com Python 7 01-13-2007 11:19 AM
Kamaelia 0.4.0 RELEASED - Faster! More Tools! More Examples! More Docs! ;-) Michael Python 4 06-26-2006 08:00 AM
What gcc options guarantee more portable C code lovecreatesbeauty C Programming 28 06-17-2006 01:13 AM
portable (VHDL) vs. non-portable (altera LPM) approaches to signed computations Eli Bendersky VHDL 1 03-01-2006 02:43 PM
With a Ruby Yell: more, more more! Robert Klemme Ruby 5 09-29-2005 06:37 AM



Advertisments