By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,017 Members | 1,072 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,017 IT Pros & Developers. It's quick & easy.

inline and ctor

P: n/a
Can a ctor be declared inline ?

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

kindly clarify

Thanks
V.Subramanian
Nov 23 '07 #1
Share this Question
Share on Google+
12 Replies


P: n/a
On Thu, 22 Nov 2007 23:53:29 -0800 (PST), su**************@yahoo.com wrote:
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.

--
Joel Yliluoma - http://iki.fi/bisqwit/
Nov 23 '07 #2

P: n/a
On Nov 23, 8:53 am, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.comwrote:
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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Nov 23 '07 #3

P: n/a
On Nov 23, 10:01 pm, James Kanze <james.ka...@gmail.comwrote:
On Nov 23, 8:53 am, "subramanian10...@yahoo.com, India"

<subramanian10...@yahoo.comwrote:
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.
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?
Nov 23 '07 #4

P: n/a
On Nov 23, 3:53 pm, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.comwrote:
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-lit...s.html#faq-9.3
Nov 23 '07 #5

P: n/a
On Fri, 23 Nov 2007 06:08:02 -0800, alan wrote:
On Nov 23, 10:01 pm, James Kanze <james.ka...@gmail.comwrote:
>On Nov 23, 8:53 am, "subramanian10...@yahoo.com, India"

<subramanian10...@yahoo.comwrote:
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.
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.

--
Tadeusz B. Kopec (tk****@NOSPAMPLEASElife.pl)
Anybody who doesn't cut his speed at the sight of a police car is
probably parked.
Nov 23 '07 #6

P: n/a
On Nov 24, 3:15 am, "Tadeusz B. Kopec" <tko...@NOSPAMPLEASElife.pl>
wrote:
On Fri, 23 Nov 2007 06:08:02 -0800, alan wrote:
On Nov 23, 10:01 pm, James Kanze <james.ka...@gmail.comwrote:
On Nov 23, 8:53 am, "subramanian10...@yahoo.com, India"
<subramanian10...@yahoo.comwrote:
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.
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.
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.
Nov 23 '07 #7

P: n/a
Tadeusz B. Kopec wrote:
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.
Nov 24 '07 #8

P: n/a
On Sat, 24 Nov 2007 08:16:40 -0500, Ron Natalie wrote:
Tadeusz B. Kopec wrote:
>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.
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.

--
Tadeusz B. Kopec (tk****@NOSPAMPLEASElife.pl)
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
stardate unknown.
Nov 24 '07 #9

P: n/a
Tadeusz B. Kopec wrote:
On Sat, 24 Nov 2007 08:16:40 -0500, Ron Natalie wrote:
>Tadeusz B. Kopec wrote:
>>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.

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.
Nov 24 '07 #10

P: n/a
On Nov 24, 2:16 pm, Ron Natalie <r...@spamcop.netwrote:
Tadeusz B. Kopec wrote:
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.
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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Nov 24 '07 #11

P: n/a
On Sat, 24 Nov 2007 10:13:04 -0500, Ron Natalie wrote:
Tadeusz B. Kopec wrote:
>On Sat, 24 Nov 2007 08:16:40 -0500, Ron Natalie wrote:
>>Tadeusz B. Kopec wrote:

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.

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.
Right. I didn't think about inline private members. Putting their code in
the class implementation file might be reasonable.

--
Tadeusz B. Kopec (tk****@NOSPAMPLEASElife.pl)
Wherever you go...There you are.
-- Buckaroo Banzai
Nov 24 '07 #12

P: n/a
Tadeusz B. Kopec wrote:
On Sat, 24 Nov 2007 10:13:04 -0500, Ron Natalie wrote:
>Tadeusz B. Kopec wrote:
>>On Sat, 24 Nov 2007 08:16:40 -0500, Ron Natalie wrote:

Tadeusz B. Kopec wrote:

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.
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.

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).

--
Ian Collins.
Nov 24 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.