Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

GCC attributes

<< < (3/6) > >>

Urxae:

--- Quote from: Takeshi Miya on December 17, 2005, 03:59:22 am ---Now back on topic:
Saying that wxDEPRECATED(x) is harder to read is an opinion. In my view, is better because: it's capitalized, and it notes that the entire macro is applied.

--- End quote ---

It's an opinion I agree with though. Wrapping the entire declaration in a macro makes it harder to see what is being declared, or that it is in fact a declaration at all. Not to mention what happens when you want to apply multiple attributes...


--- Quote ---However all of thatisn't that important compared to this:

While your someFunction() cbDEPRECATED works on GCC, it doesn't work on Visual C, because the declaration is inverted cbDEPRECATED someFunction().

So, putting everything into a macro argument like wxDEPRECATED(x) is the only solution.

--- End quote ---

It's not. At least not if MSVC and GCC are your targets, I don't know how other compilers handle attributes.
You forgot an option: just use cbDEPRECATED someFunction(). My g++ accepts attributes in that location:

--- Code: ---D:\Temp>cat test.cpp
void __attribute((deprecated)) f() {}

int main()
{
    f();
}

D:\Temp>g++ test.cpp
test.cpp: In function `int main()':
test.cpp:5: warning: `f' is deprecated (declared at test.cpp:1)
test.cpp:5: warning: `f' is deprecated (declared at test.cpp:1)

--- End code ---

Anyone want to bet why this works, by the way?
My money is in order to support exactly this situation: using macros to apply attributes without having to wrap the entire declaration in them ;).

takeshimiya:
It's ok if GCC supports that then. But are you sure that works on any gcc version?

And you'll certainly will want to hope that no other compiler handles that in a different way.

With the other way however, you don't have to worry about future/other compilers.

thomas:

--- Quote from: Takeshi Miya on December 17, 2005, 07:43:16 am ---It's ok if GCC supports that then. But are you sure that works on any gcc version?

And you'll certainly will want to hope that no other compiler handles that in a different way.

With the other way however, you don't have to worry about future/other compilers.

--- End quote ---
No, some of these attributes only work with gcc version >= 3.

You saw the #if, didn't you :)

Urxae:

--- Quote from: Thomas (SVN rev. 1542 comment) ---Replaced double-underscore macros with triple-underscore due to problems encountered with codestats plugin.

--- End quote ---

While this may solve the immediate problem, it doesn't fix the underlying cause. You're still using names that are reserved to the compiler and standard library. Please reread my post above:

--- Quote from: Urxae on December 17, 2005, 06:25:34 am ---In C, the implementation reserves

* any global-scope name beginning with _
* any name beginning with _ followed by an upper-case letter
* any name beginning with __C++ additionally reserves any name containing __ anywhere in it, not just at the beginning.

--- End quote ---

Triple underscores still contain double underscores, plus they begins with a double underscore, plus they're in the global scope (macros are in every scope :() so even that clause is violated here. In fact, the only clause this doesn't violate is the one about underscore-upper case letter, simply by virtue of not containing any uppercase letters.

How about something like cb_inline_/cb_inline? Or just going back to upper case: cb_INLINE_/cb_INLINE? They're macros, general convention is that they contain a lot of (if not only) uppercase symbols anyway...

Oh, and looking over that patch I noticed something else: The deprecated attribute on Manager::isappShutingDown() is at the end of the line. As mentioned in earlier posts it'll need to be more to the front for MSVC, and GCC accepts it there too. Might be a good idea to move it, though by the time MSVC is supported that method may have been removed completely already ;).

takeshimiya:
I vote for cbEVILMACRO convention.

Navigation

[0] Message Index

[#] Next page

[*] Previous page