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

Inline Constructor

P: n/a
Hi Guys,

1. As we know usually we should not define a constructor as inline. I also
learned if we define a member function inside the class this member function
will be automatically be inline'ed. My question is:
If I define a constructor (including its body) or another large member
function inside the class, the constructor or the member function is inline
or not? why?

2. I learned that if the member function is big we should not define it as
inline. Can anyone tell me how large that a member function should not be
inline? I suppose it depends on different compiler. I want to know clearly
when I should use inline and when should not.

Thanks in advance!

Sincerely
Wu
Apr 18 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
* Wu Shaohua:

1. As we know usually we should not define a constructor as inline.
I don't know that; it must be something new that I'm not aware of...

I also
learned if we define a member function inside the class this member function
will be automatically be inline'ed.
No, it won't. It's the same as declaring it 'inline'. Which does not
guarantee inlining.

My question is:
If I define a constructor (including its body) or another large member
function inside the class, the constructor or the member function is inline
or not? why?
Any member function definition inside the class definition is equivalent
to an 'inline'-declared definition outside the class. One possible
reason it is like that is the usual physical packaging of C++ code,
where class definitions are provided in header files that are physically
included by other files. So without the rule you'd violate the one
definition rule; what 'inline' tells the compiler is that you have
ensured that all definitions (which come from including that header) are
identical, not in conflict with each other.

2. I learned that if the member function is big we should not define it as
inline. Can anyone tell me how large that a member function should not be
inline? I suppose it depends on different compiler. I want to know clearly
when I should use inline and when should not.


You should use member function definitions inside the class definition
when that makes the code more clear.

You should provide an 'inline' external definition when that makes the
code (or e.g. the build process) more clear.

To influence actual /inlining of the machine code/, which is something
else entirely, you have to use compiler-specific means, and anyway, as a
novice you shouldn't even think about it: "premature optimization is the
root of all evil", and regarding inlining it will be pure chance if you
manage to do better than the compiler would without interference.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Apr 18 '06 #2

P: n/a
"Wu Shaohua" <fl****@gmail.com> wrote in message
news:e2**********@news.cn99.com
Hi Guys,

1. As we know usually we should not define a constructor as inline.
I don't know that.
I also learned if we define a member function inside the class this
member function will be automatically be inline'ed. My question is:
If I define a constructor (including its body) or another large member
function inside the class, the constructor or the member function is
inline or not? why?
Yes. Because the language says so. Note that the function is inline in the
same sense as a function is inline when you explicitly use the inline
keyword. This is a hint to the compiler which may or may not actually inline
the function. Further, some compilers will inline functions even when they
are defined outside the class declaration and even though the inline keyword
is not used.
2. I learned that if the member function is big we should not define
it as inline. Can anyone tell me how large that a member function
should not be inline? I suppose it depends on different compiler. I
want to know clearly when I should use inline and when should not.


I think you hope for too much.
--
John Carson

Apr 18 '06 #3

P: n/a
Wu Shaohua wrote:
1. As we know usually we should not define a constructor as inline.
Why?
I
also learned if we define a member function inside the class this member
function
will be automatically be inline'ed. My question is:
If I define a constructor (including its body) or another large member
function inside the class, the constructor or the member function is
inline or not? why?
"inline" means two things. It means the 'inline' keyword, which instructs
the compiler to neglect the "one definition rule" for a function body, and
to permit that function body (or constructor or destructor) to appear in
more than one translation unit. That's generally the sum of one .cpp file
and all its #included .h files (under common naming conventions).

Programmers say "inline" to also mean "inlined opcodes". A function's
opcodes get inserted into the calling function's opcodes, without a
hardware function call between them.

Blocks of code (functions, constructors, and destructors) inside classes (or
structs) automatically get an implied 'inline' keyword.

The keyword is only a hint to the compiler to inline a function's opcodes.
The compiler can inline the opcodes of functions not declared inline, and
can out-of-line functions declared inline.

Neither situation is automatically faster, and you will do better to write
clean code and let the compiler sort such issues out.
2. I learned that if the member function is big we should not define it
as
inline. Can anyone tell me how large that a member function should not be
inline? I suppose it depends on different compiler. I want to know
clearly when I should use inline and when should not.


Functions should not be large.

Now to answer my "Why?" up above. If you write "lots of stuff" into a .h
file, such as long function bodies, or extra #include statements, then the
odds increase that you will change those contents as your program grows.
This will cause cascading recompiles as clients of your .h file recompile,
even when you change things they don't use.

..h file should be as lean as possible, with all function bodies moved out
to .cpp files. The .h file should #include the fewest possible other .h
files, and it should forward-declare classes that it uses, if possible:

class Foo;

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
Apr 18 '06 #4

P: n/a
"Wu Shaohua" writes:
1. As we know usually we should not define a constructor as inline.


Nonsense.
Apr 18 '06 #5

P: n/a

"osmium" <r1********@comcast.net> wrote in message
news:4a************@individual.net...
| "Wu Shaohua" writes:
|
| > 1. As we know usually we should not define a constructor as inline.
|
| Nonsense.
|
|

Sorry, I didn't make it clear. I meant usually a contructor has lots of
things to do such as invoking the base class's contructor, initializing
member data etc. In this case, the constructor will be complex. So we
should not use inline for such a constructor. Is it correct?

Actually, what I am interested in is how the compiler control the inline
stuff.

And thank all you guys for answering my question.
Apr 18 '06 #6

P: n/a
Wu Shaohua wrote:
"osmium" <r1********@comcast.net> wrote in message
news:4a************@individual.net...
| "Wu Shaohua" writes:
|
| > 1. As we know usually we should not define a constructor as inline.
|
| Nonsense.
|
|

Sorry, I didn't make it clear. I meant usually a contructor has lots of
things to do such as invoking the base class's contructor, initializing
member data etc. In this case, the constructor will be complex. So we
should not use inline for such a constructor. Is it correct?
Not necessarily. Write the code so that it is clear, and let the
compiler sort out what to do with the machine level stuff (like whether
the function is actually inlined or not). Only when you determine that
there actually is some sort of performance issue (by _measuring_, not
guessing), then worry about forcing the compiler to go one way or another.
Actually, what I am interested in is how the compiler control the inline
stuff.


That's compiler and platform specific stuff. If you check your
documentation, it probably has some mention of when a function will and
won't be inlined (and probably compiler switches and stuff to control it).
Apr 18 '06 #7

P: n/a

Wu Shaohua wrote:
"osmium" <r1********@comcast.net> wrote in message
news:4a************@individual.net...
| "Wu Shaohua" writes:
|
| > 1. As we know usually we should not define a constructor as inline.
|
| Nonsense.
|
|

Sorry, I didn't make it clear. I meant usually a contructor has lots of
things to do such as invoking the base class's contructor, initializing
member data etc. In this case, the constructor will be complex. So we
should not use inline for such a constructor. Is it correct?
The answer depends, your compiler will make the choice.
Actually, what I am interested in is how the compiler control the inline
stuff.

the keyword 'inline' is only a hint to a compiler, the compiler can
choose either to honor it or ignore it depending on compiler
heuristics. Some compiler vendor has vendor specific keyword to force
function inline but this practice is not standard.
And thank all you guys for answering my question.


no problem. You may want to find a good book that systematically
explains these things to you instead of relying on tid-bit information
gathered from a news group.

Apr 20 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.