Re: 'do {} while (0)' replacement

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Harvey,

On Thursday 09 October 2008, Richard Harvey Chapman wrote:
> This is just a philosophical question, right? Because it seems to me
> that there are other ways to accomplish this task which are easier. But
> in the interest of brain teasers...

I wouldn't say that. Actually this statement is part of a bigger
project and I'm searching a universal macro which fits these needs.

> Frank Mehnert wrote:
> > This changes the semantics: The BREAK_ON_ERROR() macro should be
> > handled as one compound statement. The following statement should
> > work as well:
> >
> >   if (bar)
> >     BREAK_ON_ERROR(buzz);
> >   else
> >     BREAK_ON_ERROR(buzz1);
>
> Well, this is different than what you originally stated. In this case,
> your macro will compile without warning. My quick suggestion would then be:
>
>     if (bar)
>       BREAK_ON_ERROR(buzz);
>     else
>       BREAK_ON_ERROR(buzz);
>
>     if (bar)
>       BREAK_ON_ERROR_NO_ELSE(buzz);
>
> where BREAK_ON_ERROR_NO_ELSE is the modified macro without the "else".
> This also has the added benefit that if either macro is used in the
> wrong situation, the compiler will issue an error.

Yes, this is possible but still not convenient enough. Of course I need
both cases, with or without else case.

> However, if we're really trying to find a single macro for this, I do
> not think it is possible. The reasoning follows that the whole point of
> do{ statement(s) }while(0) is to avoid the syntax error about the
> semicolon placed at the end of the macro. The only way in C to construct
> a compound statement is with braces, { and }, which will generate the
> semicolon syntax error that you're trying to avoid (if placed between an
> "if" and an "else").

I was not sure if there are some other special tricks. Did you know

  http://www.steike.com/code/useless/evil-c/

? For instance, Duff's Device for loop unrolling. These tricks are not
related to my problem of course but they show that there is sometimes
unconvential solutions.

Thanks for your help anyway.

Kind regards,

Frank
-- 
## Dept. of Computer Science, Dresden University of Technology, Germany ##
## http://os.inf.tu-dresden.de/~fm3                                     ##

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux