I wrote some macros to add OO "support" to C, it took about 1 page of C code. It's really simple stuff that anyone could do if they knew how vtables work, but I think that the vtable aproach is flawed by itself, all you need is just tagged structures and functions to operate on them. More interesting macros would be things like foreach or DOLIST. Too bad C macros are very limited (just text replacement) and can't do the things real macros that Lisp has (you have the full power of the environment when you write a macro, which makes writing compilers quite fun and easy).
Having played with __assume a little (assuming some crazy shit and looking at the assembly listing) I can't begin to imagine disastrous effects this EXPERT PRACTICE would produce in a real code. Truly, this is a sanity destroyer worth being put in the Necronomicon.
>>18
That's why, if you read the comment before that code listing, it explains that you should only use that if failing the assertion would already lead to undefined behaviour. So it's not any more dangerous if you use it correctly.
You could try defining both assert() and assume() which do the same in debug mode, but in release the former disappears and the latter __assume()s.
Name:
Anonymous2010-01-13 16:18
>>18
What kind of assumptions did the compiler make use of? I see their 'default unreachable' example, and I assume you can assume lack of pointer aliasing and the like.
Name:
Anonymous2010-01-13 18:31
>>21
restrict works better for assuming no pointer aliasing. It's well supported as an extension by many compilers, though most don't enable the C99 keyword by default. __restrict works in msvc, __restrict__ in everything else, and gcc supports both. In keeping with the topic, here's a preprocessor macro I use in my own code:
>>26
The 'do while' still needs a semicolon to end the statement, whereas a scope would not. This means that if(foo) swap(int, a, b); else bar(); will work with >24's solution, but not with a simple scope.