inline and ctor

[subramanian100in]

Can a ctor be declared inline ?

Is it not declared inline to avoid executable code size becoming
huge ?

kindly clarify

Thanks
V.Subramanian

 

[Joel Yliluoma]

Can a ctor be declared inline ?
Yes.


Is it not declared inline to avoid executable
code size becoming huge ?

That may be a motive for someone.

 

[James Kanze]

Can a ctor be declared inline ?

Of course.

Is it not declared inline to avoid executable code size
becoming huge ?

Usually, it's not declared inline to avoid unnecessary coupling.

 

[alan]

Of course.


Usually, it's not declared inline to avoid unnecessary coupling.

Just curious, but coupling to what? I don't quite understand this.
Isn't the compiler obligated with ensuring that an inlined and non-
inlined function call are for the most part equivalent? To what
degree can an inlined function digress from a non-inlined version?

Or is it because that inline functions must be declared somehow in
each source file that uses the function (in this case a ctor), and
will typically be placed in a header, which arguably is the "wrong"
place to put the details of the code?

 

[alan]

Can a ctor be declared inline ?

Is it not declared inline to avoid executable code size becoming
huge ?

Note that inlining does not *always* increase executable code size.
It *may* reduce code size; it may increase code size. Please see:
http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.3

 

[Tadeusz B. Kopec]

Just curious, but coupling to what? I don't quite understand this.
Isn't the compiler obligated with ensuring that an inlined and non-
inlined function call are for the most part equivalent? To what degree
can an inlined function digress from a non-inlined version?

All code which needs to 'see' a class definition has also to 'see' all
inline members. Changing any of them forces recompilation which wouldn't
be necessary if they weren't inline.

 

[alan]

All code which needs to 'see' a class definition has also to 'see' all
inline members. Changing any of them forces recompilation which wouldn't
be necessary if they weren't inline.

I see; I suppose I haven't actually been on anything like a big C++
project (possibly involving library-in-binary-format), so I personally
don't care about recompilation; but I suppose this is a good idea, if
ever I get into one.

 

[Ron Natalie]

All code which needs to 'see' a class definition has also to 'see' all
inline members. Changing any of them forces recompilation which wouldn't
be necessary if they weren't inline.

It doesn't have to. While defining the function inside the class
definition makes it inline, you can still just use the regular
"inline" keyword and define it elsewhere.

 

[Tadeusz B. Kopec]

It doesn't have to. While defining the function inside the class
definition makes it inline, you can still just use the regular "inline"
keyword and define it elsewhere.

3.2.3 An inline function shall be defined in every translation unit in
which it is used.

So that 'elsewhere' usually is in the same header. Other places are hard
to maintain.

 

[Ron Natalie]

3.2.3 An inline function shall be defined in every translation unit in
which it is used.

So that 'elsewhere' usually is in the same header. Other places are hard
to maintain.

Nope. Only the places where it is used. Public methods are one
thing, but you said "all inline members" and there's no necessity to
expose them all if they can't be called everywhere the class
definition appears.

 

[James Kanze]

It doesn't have to. While defining the function inside the class
definition makes it inline, you can still just use the regular
"inline" keyword and define it elsewhere.

Good point. I do occasionally make private functions inline,
for the obvious performance reasons, and when they are only
defined in the implementation source file, it doesn't introduce
any coupling either.

I'd never make a public or protected function inline, however,
unless the profiler said I had to.

 

[Tadeusz B. Kopec]

Nope. Only the places where it is used. Public methods are one
thing, but you said "all inline members" and there's no necessity to
expose them all if they can't be called everywhere the class definition
appears.

Right. I didn't think about inline private members. Putting their code in
the class implementation file might be reasonable.

 

[Ian Collins]

Right. I didn't think about inline private members. Putting their code in
the class implementation file might be reasonable.

Reasonable and sensible, there is absolutely nothing to be gained by
defining private members in the header (with the possible exception of a
class with its member definitions spread over several compilation units).