Re: unit testing and G_INLINE_FUNC - breakage moving from 2.4 to 2.6



Ian Zimmerman wrote:
Brandon> I've gotten a few tests to build by G_INLINE_FUNC to be empty
Brandon> before including the .c file. Another approach would be moving the
Brandon> include of the .c file up to the top of the test, so G_IMPLEMENT_INLINES
Brandon> is set from the beginning, but that's not entirely foolproof either
Brandon> because it might break if we need to link a test together from a few
Brandon> source files that all try this trick.

Brandon> Another option would be redefining G_INLINE_FUNC to pick up the value of
Brandon> G_IMPLEMENT_INLINES at the point of use rather than where glib is first
Brandon> included. Something like this seems to behave, as long as you
Brandon> only define G_IMPLEMENT_INLINES to be 1 or empty

Brandon> #define G_INLINE_FUNC GIF_DELAY(G_IMPLEMENT_INLINES)
Brandon> #define GIF_DELAY(X) GIF_TEST(X)
Brandon> #define GIF_TEST(X) GIF_##X
Brandon> #define GIF_1 extern inline
Brandon> #define GIF_ extern inline
Brandon> #define GIF_G_IMPLEMENT_INLINES
Brandon> (GIF_DELAY is to get around some wierdness in the behaviour of ##).

Sorry I don't get it.  Why must you use these obscure glib macros at all?
Why can't you simply declare your functions hard "static inline"?


Mostly I'm hoping it's safer to use extern inline plus one non-inline version, as in easier to understand what the code is doing. I thought things like using a static variable in the inline function would work better that way, but it looks like gcc screws that up even when using extern inline.

Another reason is that we have a lot of code already written that uses the G_INLINE_FUNC macros, so it would be a lot of work to rip that stuff out, if somebody knows a way to work with them.

Writing static inline sounds like a reasonable approach, if extern inline can't save you from thinking of the implementation when tricky stuff breaks.

Brandon

> "It's not true or not."  A reality show producer (real quote)
Sounds like he's a constructivist




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