|
Boost : |
Subject: Re: [boost] inline specifier within in class definition
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-05-05 00:56:14
Mateusz Loskot wrote:
> Thomas Klimpel wrote:
>> Mateusz Loskot wrote:
>>> However, I've not found clear answer in that thread.
>>
>> Strange. I assume your question is "Why are some static member
>> functions defined within class definitions specified with inline
>> keyword?" and the answer is "The only reasons for this is to try to
>> influence the inlining behavior of the compiler." (+copy&paste from
>> existing code...)
>>
>> This is what I call a clear answer.
>
> I understand it but isn't enough to define such member function
> within class definition? It should be, according to what the C++
> standard states.
>
If, by some strange coincidence, you happen to be implementing a non-template class and leave out the inline keyword when defining a static member function in the header file as part of the class definition, or any other kind of function, for that matter, you end up with a multiple function definition link-time error when the header is included in multiple execution units. Specifying the inline keyword forces the compiler to make the function signature a weak symbol and eliminates the link time error. Since it becomes more painful to forget the inline keyword in the cases where it is needed than to type it in the cases where it is not, people might err on the side of throwing it in even if the class is a template and all its functions are weak symbols regardless. When implementing header file only code there is no harm (in my opinion) in declaring every function inline, and consistently following that policy completely eliminates the chances of multiple definitions link-time error. I don't follow that policy, personally, since I write so few non-template functions these days, but I wouldn't criticize others for doing so. If a programming practice makes programming less error prone and does no harm other than a little extra typing and slightly more verbose code I would consider it a reasonable thing to do.
Regards,
Luke
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk