GCC attributes

[sethjackson]

I vote for cbEVILMACRO convention.

I'll second. :lol:

[rickg22]

I third. I believe that's the way it should be.

[thomas]

Lest someone pronouces fo(u)rth, I removed gcc attributes.

[Urxae]

Lest someone pronouces fo(u)rth, I removed gcc attributes.

Nobody said they had to go entirely, just that the following spelling was preferred to the one with all the underscores:

Code

// Attributes and builtins used when compiling Code::Blocks with gcc
// No effect (short of being documentary) with other compilers
//
// $Id$

#ifndef GCC_ATTRIBS
#define GCC_ATTRIBS

#if __GNUC__ >= 3   // ----------------------------------

#define likely(x)               __builtin_expect(!!(x),1)
#define unlikely(x)             __builtin_expect(!!(x),0)
#define compiler_constant(x)    __builtin_constant_p(x)
#define cpu_prefetch(x)         __builtin_prefetch(x)

#define cbINLINE                __attribute__ ((always_inline))
#define cbNOINLINE              __attribute__ ((noinline))
#define cbNOTHROW               __attribute__ ((nothrow))
#define cbDEPRECATED            __attribute__ ((deprecated))
#define cbCONST                 __attribute__ ((const))
#define cbPURE                  __attribute__ ((pure))
#define cbCHECKRESULT           __attribute__ ((warn_unused_result))
#define cbMALLOC                __attribute__ ((malloc))

#ifdef __WIN32__
  #define cbFASTCALL            __attribute__ ((fastcall))
  #define cbFASTESTCALL         __attribute__ ((regparm(3)))
#else
  #define cbFASTCALL
  #define cbFASTCALL
#endif

#else               // ----------------------------------

#define likely(x)               (x)
#define unlikely(x)             (x)
#define compiler_constant(x)    false
#define cpu_prefetch(x)

#define cbINLINE                inline
#define cbNOINLINE
#define cbNOTHROW
#define cbDEPRECATED
#define cbCONST
#define cbPURE
#define cbCHECKRESULT
#define cbMALLOC

#define cbFASTCALL
#define cbFASTCALL


#endif              // ----------------------------------


#endif

[killerbot]

I just looked at 1 file that Thomas changed, tokenizer.h
I see some methods being defined within the class body, add also the keyword inline specified.

The keyword inline is not that interesting, since it is just a hint to the compiler !!!

Secondly, methods being implemented within the class definition/body are , according to the standard, to be inlined !!!


Lieven

[thomas]

The keyword inline is not that interesting, since it is just a hint to the compiler !!!
Secondly, methods being implemented within the class definition/body are , according to the standard, to be inlined !!!

So what do you want to tell me? Functions defined inside the class scope are only inlined in optimized build.
Code::Blocks is currently being built and distributed non-optimized. In the special case of the code completion parser, this makes a difference of nearly 100% in execution time. This was one reason for using function attributes (in particular always_inline).

The inline keyword gives an additional hint to the compiler that I wish these functions to be inlined, optimized build or not. Maybe the compiler will ignore the hint, maybe not. There is not much harm in using it. However, if that makes you feel that I don't know C++, then I'll remove it.

[killerbot]

Thomas,

Methods implemented in the class body are ALWAYS inlined  (I think this is guranteed by the standard) !!!

class MyClass
{
  void MyFunction1() const {return something;}  // <<---- always inlined
  inline void MyFunction2(); //<<-- implemented somewhere else (90% chance this inline suggestion will be ignored)
}


I don't doubt your C++ knowledge !! That sounded very negative, I hope it did not give you this impression.

[thomas]

Methods implemented in the class body are ALWAYS inlined  (I think this is guranteed by the standard) !!!

[...] Otherwise, when you specify -O, member functions defined inside class scope are compiled inline by default

[me22]

Methods implemented in the class body are ALWAYS inlined  (I think this is guranteed by the standard) !!!

class MyClass
{
  void MyFunction1() const {return something;}  // <<---- always inlined
  inline void MyFunction2(); //<<-- implemented somewhere else (90% chance this inline suggestion will be ignored)
}

Correction: functions defined inside a class definition are inline-qualified.

Note, however, that that does NOT mean "always inlined."  inline is a request, not an order.  Compilers are permitted to completely ignore the request, and many do.

GOTW #33: Inline covers this nicely:

Inline Difficulty: 4 / 10
Contrary to popular opinion, the keyword inline is not some sort of magic bullet. It is, however, a useful tool when employed properly. The question is, When should you use it?

It's also mentioned in GOTW #27:

This one is a matter of judgment. In short, prefer to write all functions out-of-line by default, and then selectively inline individual functions as necessary only after you know that the performance gain from inlining is actually needed.

If you inline the function, the positive side is that you avoid the overhead of the extra function call to f.

The negative side is that inlining f exposes f's implementation and make client code depend on it, so that if f changes all client code must recompile. Worse, client code now also needs at least the prototype for function g(), which is a bit of a shame since client code never actually calls g directly and probably never needed g's prototype before (at least, not as far as we can tell from our example). And if g() itself were changed to take other parameters of still other types, client code would now depend on those classes' declarations, too.

Both inlining or not inlining can be valid choices. It's a judgment call where the benefits and drawbacks depend on what you know about how (and how widely) f is used today, and how (and how often) it's likely to change in the future.

From the GotW coding standards:
    - prefer passing parameters of class type by const& rather than passing them by value
    - avoid inlining functions until profiling tells you it's justified (programmers are notoriously bad at guessing which parts of their code are performance bottlenecks)

( Also, void functions can't return something :lol: )

[killerbot]

Yes, me22 I have read this also in the bookd of Herb Sutter, and those of Scott Meyers.
Last month I was in a workshop of Scott Meyers about the preformance of STL, and using it the smart way. There was a topic about sorting and using functors, and if I recall correctly he mentioned that functors are better then regular functions, since many functors are small classes or structs, where the operator() is implemented directly in the class/struct defintion and therefor is inlined (I think he said the standard guarantees that). I will browse through the printed slides to see if I can find it black on white.

If my statement from above is correct, then maybe we might have a compiler behaving differently. I'll look for some more documentation on the subject.

kind regards,
Lieven

[killerbot]

From the slides of Scott Meyers workshop :

class Widget
{
public:
  int weight() const;
};


std::vector<Widget> vw;
std::sort(vw.begin(), vw.end(), );

What's best way for the sorting criterion ?
  - a function ?
  - function object ?

Function object might be like this :
struct WidgetLess : public std::binary_function<Widget, Widget, bool>
{
  bool operator()(const Widget& lhs, const Widget& rhs) const
 {return lhs.weight() < rhs.weight();}
}


stuff mentioned about the function object :
 * it's a class with an (implicitly) inline operator() function
 * compilers routinely inline calls to such functions

So does that first note state that it is guaranteed to be inlined ?? I am not sure (anymore?) ?
I am still convinced that if also in this case it is still a suggestion, it is as strong as specifying inline, or they are just the same.
In the c++ conference last month in Vegas, several speakers have 'said' that implementation in the class body == inline.

Though I'dd like to see this in black on white in printing, will browse through my books some evening.

[killerbot]

Scott Meyer's : Effective STL (item 46) : page 202
If a function object's operator() function has been declared inline (either explicitly via 'inline' or implicitly by defining it in its class definition), ....