Use Inline in class?

[Immortal Nephi]

I want to know if the practice is the best. Do I need to place inline
keyword inside class definition or outside member function
definition. For example

class A
{
public:
A();
~A();

inline void Test(); // should place inline here?
};

inline void A::Test() // should place inline here?
{
{

[Ian Collins]

James Kanze wrote:

But globally, all of the
coding guidelines I've seen for application code forbid inline
functions---and usually also require user defined
implementations of the functions the compiler will generate by
default as well, since the compiler generated versions are
inline.

Where's the problem with inline compiler generated functions?

--
Ian Collins.

[James Kanze]

On Jul 6, 9:59 pm, "Alf P. Steinbach" <[e-mail] wrote:

* Gennaro Prota:

Alf P. Steinbach wrote:

* James Kanze:
[...]
If you do actually have a performance problem, and the
profiler shows that it is in a tight loop where you do
call a non-inlined function, then inlining it is a simple
and cheap optimization. Using inline before the profiler
says you have to, however, is premature optimization.

Inlining things in headers is a technique that saves
programmer's time both for initial development, for use of
the header, and for maintainance (which reportedly
constitutes about 80% of all programming work).

I think that if this is really your issue (hardly, but I'll
assume you have some measurements) then you (or your users
in the case e.g. of libraries, for which I've often heard
the "header-only is easier" claim) are likely to work with a
severely limited environment and toolset. To me, creating
one more file is just a matter of issuing ":e filename" and
the file contents get initialized automatically with all
that can be written automatically. Similarly for building.

It's also easy to write Perl. ;-)

But we both agree that maintenance is an important issue:-).

As to maintenance I really don't understand: what time do
you save?

For things that are defined in the header file you only need
to look at one file, affecting continuity, and you see the
relevant definition in context.

There are some arguments in favor of "all in the header", in
certain conditions. (If you're distributing a library over
multiple platforms, for example, it certainly makes the
distribution easy.) For the most part, however, code isn't (and
shouldn't be) designed as a monolithic block. Before attacking
the maintenance, you read the documentation, to understand the
basic role of the class in the context of the application. From
the documentation and the test results, you should be able to
determine directly which function is misbehaving (otherwise,
your tests aren't adequately precise), and usually, even, have a
fair idea as to why it is misbehaving. So you don't need
authorization to check out the header; you can just check out
the implementation file for the function, make the correction,
and be done with it. Even in less perfect situations (and I'll
admit, not every organization runs as smoothly as I just
described), you'll generally have to look at several different
classes, in several different headers, before deciding which
implementation file needs working on. And in those classes
which you don't want to modify (usually the majority), you don't
want to have to search through tons of implementation code to
find the relevant declarations; Java without (well written)
Javadoc is unmaintainable, but you can actually produce readable
class definitions in C++. (Even with inline functions---the
inline functions will normally be defined outside of the class
anyway.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 7, 10:11 am, Ian Collins <[e-mail] mwrote:

James Kanze wrote:

But globally, all of the
coding guidelines I've seen for application code forbid inline
functions---and usually also require user defined
implementations of the functions the compiler will generate by
default as well, since the compiler generated versions are
inline.

Where's the problem with inline compiler generated functions?

The day you have to change them (and they cease to become
compiler generated), you have to modify the header.

In the end, implementation details don't belong in the header.
We're stuck with regards to private data and functions (although
the compilation firewall can limit the problems), but for the
rest, you only put what is necessary for the client in the
header. The implementation of a function, or even the fact that
the implementation is compiler generated, is an implementation
detail.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 7, 11:47 am, "Alf P. Steinbach" <[e-mail] wrote:

* James Kanze:

[...]

This sounds very much like arbitrary decisions that have made
themselves into law, and are not being rationalizated is if
they were meaningful.

Actually, it's all based on concrete experience.

If you prefer to ignore concrete experience, that's your
privilege.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ian Collins]

James Kanze wrote:

On Jul 7, 10:11 am, Ian Collins <[e-mail] mwrote:

>James Kanze wrote:

>>But globally, all of the
coding guidelines I've seen for application code forbid inline
functions---and usually also require user defined
implementatio ns of the functions the compiler will generate by
default as well, since the compiler generated versions are
inline.

>Where's the problem with inline compiler generated functions?

The day you have to change them (and they cease to become
compiler generated), you have to modify the header.

I'd expect the reason a class would require an explicit version of a
compiler generated function would be a change to its data members.

I guess it all comes back to the old discussion about build times. I'm
used to an environment where changing headers is a normal part of the
development process.

In the end, implementation details don't belong in the header.

I can't argue with that.

We're stuck with regards to private data and functions (although
the compilation firewall can limit the problems), but for the
rest, you only put what is necessary for the client in the
header. The implementation of a function, or even the fact that
the implementation is compiler generated, is an implementation
detail.

Yes and no - it is a detail, but it's a hidden detail.

--
Ian Collins.

[Gennaro Prota]

James Kanze wrote:

In the end, implementation details don't belong in the header.
We're stuck with regards to private data and functions (although
the compilation firewall can limit the problems), but for the
rest, you only put what is necessary for the client in the
header. The implementation of a function, or even the fact that
the implementation is compiler generated, is an implementation
detail.

Note that in C++0x we should finally be able to require
compiler-generation of special member functions without making them
inline:

<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm>

--
Gennaro Prota | <https://sourceforge.net/projects/breeze/>
Do you need expertise in C++? I'm available.

[James Kanze]

On Jul 7, 10:13 pm, Ian Collins <[e-mail] mwrote:

James Kanze wrote:

On Jul 7, 10:11 am, Ian Collins <[e-mail] mwrote:

James Kanze wrote:
But globally, all of the coding guidelines I've seen for
application code forbid inline functions---and usually
also require user defined implementations of the functions
the compiler will generate by default as well, since the
compiler generated versions are inline.

Where's the problem with inline compiler generated
functions?

The day you have to change them (and they cease to become
compiler generated), you have to modify the header.

I'd expect the reason a class would require an explicit
version of a compiler generated function would be a change to
its data members.

You've never added logging or event notifications?

Typically, of course, you're right, and the compiler generated
inlines are generally less of a problem than user defined ones.
In fact, the main reason given for avoiding them was code bloat;
in the case of constructors and destructors, the apparently
"empty" function can generate a lot of code.

In my own code (i.e. code where I don't have to follow
externally imposed guidelines), I vary somewhat, using common
sense and my knowledge of the class' semantics: I'd certainly
not bother defining the compiler generated defaults for
something like complex, for example, where as if the class has
some real, application level behavior, I probably would.

And of course, if the code is a template, the rules are
definitelyl relaxed, because the source level coupling is
already there anyway.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Juha Nieminen]

James Kanze wrote:

>In-lining functions in a header file can be critical for
performance reasons.

Really? I never use it, and I've not had any performance
problems.

I think you are underestimating the importance of inlining with
respect to speed (and even executable size).

For example, a small program I made to test the speed of a (very
template-heavy) memory allocator library I made, runs in 16 seconds, and
the executable is 10kB (stripped).

If I add the compiling option -fno-inline, which stops gcc from
inlining any function, all the other optimizations being the same, the
program now runs in 1 minute 11 seconds, and the executable is 18kB in size.

Not only does inlining make the program a lot faster, it even makes it
considerably smaller (debunking the common misconception most people
have about inlining making executables bigger).

[Lionel B]

On Mon, 07 Jul 2008 18:26:56 -0700, Greg Herlihy wrote:

On Jul 7, 1:16Â*am, James Kanze <james.ka...@gm ail.comwrote:

>On Jul 6, 9:59 pm, "Alf P. Steinbach" <[e-mail] wrote: Java
without (well written)

[...]

C++, of course
requires that a class interface include protected and private methods
and members. Note that - even though these methods and members are not
"accessible " - they nonetheless are "visible", and can therefore cause
senseless naming conflicts and access violations for clients of the
interface.

Huh? Example?

--
Lionel B

[Ian Collins]

James Kanze wrote:

On Jul 7, 10:13 pm, Ian Collins <[e-mail] mwrote:

>James Kanze wrote:

>>On Jul 7, 10:11 am, Ian Collins <[e-mail] mwrote:
James Kanze wrote:
But globally, all of the coding guidelines I've seen for
applicati on code forbid inline functions---and usually
also require user defined implementations of the functions
the compiler will generate by default as well, since the
compiler generated versions are inline.

>>>Where's the problem with inline compiler generated
functions?

>>The day you have to change them (and they cease to become
compiler generated), you have to modify the header.

>I'd expect the reason a class would require an explicit
version of a compiler generated function would be a change to
its data members.

You've never added logging or event notifications?

Typically, of course, you're right, and the compiler generated
inlines are generally less of a problem than user defined ones.
In fact, the main reason given for avoiding them was code bloat;
in the case of constructors and destructors, the apparently
"empty" function can generate a lot of code.

Doesn't the standard require at most one copy in the entire program of a
non-static inline function? I'm assuming compiler generated functions
fall into this category. Or do they?

--
Ian Collins.