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?
{
{

[Jerry Coffin]

In article <6d************ @mid.individual .net>, ia******@hotmai l.com
says...

[ ... ]

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?

($3.2/3): An inline function shall be defined in every translation unit
in which it is used.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Lionel B]

On Tue, 08 Jul 2008 12:17:45 +0200, Alf P. Steinbach wrote:

* 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?

Greg was possibly thinking of something like

void foo() {}

class A
{
private:
//void foo() {}
};

class B: public A
{
public:
void bar()
{
foo();
}
};

int main()
{}

If you uncomment the very private member function foo, which in a
Java-like mindset shouldn't influence anything (it's private, right?),
then in C++ it doesn't compile. Mostly this goes to
counter-intuitive'ness: it's easy to fix technically. But
counter-intuitive'ness can waste much time...

Ok... perhaps my understanding of the phrase "client of the interface"
didn't extend to derivation.

--
Lionel B

[James Kanze]

On Jul 8, 12:28 am, "Alf P. Steinbach" <[e-mail] wrote:

* James Kanze:

[...]

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.

I think that argument is relative to methodology, and only
makes sense with relative pure waterfall (analyse -design
(write headers, cast in stone) -implement -test).

I've never heard of "waterfall methodology" except as a strawman
against which other methodologies can argue.

But whether the methodology is pure waterfall or not the
argument seems to be essentially that static headers make
sense for the kind of work that you do

Not necessarily static, but the version seen by other developers
shouldn't be changing on a day to day basis either. The key is
probably that there are other developers; that I'm not the only
client of my code.

-- which, as you have earlier reported, is atypical in
several respects, for example astoundingly extreme low error
rates, indicating to me, at least, that in some sense it's
about producing variations on the same kind of solution to the
same general kind of problem, again and again, implementing a
fixed pattern. I think it is too far-reaching to generalize
observed properties of a limited domain to "it makes sense in
general".

Just the opposite: in most cases, it's cutting edge. (In the
application domain, not necessarily in the C++ we're using. In
fact, we tend to be rather conservative in our C++, because we
have so many unknowns elsewhere.)

For if that generalization held, then refactoring and other
common techniques for iterative development, requiring
changing headers, would just be ungood. ;-)

Breaking the build has always been a major sin, regardless of
the place I've been working. Any time you check out a header,
you take that risk. Obviously, if the changes justify it, fine.
But you don't go out of your way to make modifying headers
necessary, either.

--
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 8, 12:28 am, "Alf P. Steinbach" <[e-mail] wrote:

>I think that argument is relative to methodology, and only
makes sense with relative pure waterfall (analyse -design
(write headers, cast in stone) -implement -test).

I've never heard of "waterfall methodology" except as a strawman
against which other methodologies can argue.

Really? I've only had to suffer it once and only until the project got
into trouble!

>But whether the methodology is pure waterfall or not the
argument seems to be essentially that static headers make
sense for the kind of work that you do

Not necessarily static, but the version seen by other developers
shouldn't be changing on a day to day basis either. The key is
probably that there are other developers; that I'm not the only
client of my code.

Those last two words are the key - on projects I run, we don't have "my
code", only "our code".

>For if that generalization held, then refactoring and other
common techniques for iterative development, requiring
changing headers, would just be ungood. ;-)

Breaking the build has always been a major sin, regardless of
the place I've been working. Any time you check out a header,
you take that risk.

But you don't check it back in until or the tests pass, do you?

--
Ian Collins.

[Bart van Ingen Schenau]

On 8 jul, 12:29, Ian Collins <[e-mail] mwrote:

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
applicatio n 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?

You are right with one exception.
If the function call has actually been expanded inline, then there
will effectively be multiple copies of the function body.
There is still only one copy that also has the function name attached
to it.

>
--
Ian Collins.

Bart v Ingen Schenau

[James Kanze]

On Jul 8, 5:37 pm, [e-mail] (Stefan Ram) wrote:

James Kanze <james.ka...@gm ail.comwrites:

I've never heard of "waterfall methodology" except as a strawman
against which other methodologies can argue.

A complete requirement specification is needed to write a
contract document for a customer specifying what program is to
be created for a certain payment, so there seems to be a
sequence point between completing the requirement
specification and starting the next phase.

There's always a sequence point between phases. There are
always several phases occurring in parallel, however; while
you're implementing one set of requirements, the customer is
busy specifying the next. I've never seen a development process
that didn't use some sort of spiral. (I've also never seen one
that worked that didn't have some sort of sequence points
between phases, so that at any given time, you knew where you
were in the spiral.)

I don't know how the contracts for »agile developement« are.
Maybe the developer is paid by the hour as long as the
customer wants him to work on a project.

Which doesn't really change anything. No matter how you're
paid, the customer doesn't give you an open checkbook. If he
wants a new feature, you have to tell him how much it will cost.
If you don't really know, you may offer to find out, but then,
you'll have to give him some idea of how much it will cost to
find out.

The solution is to discuss things with the customer. Often,
he's as unsure of what he wants as you are of how much it will
cost. (In fact, the two are related. Whether he wants
something will usually depend on the price.) The usual practice
in such cases, or at least, the usual practice 25 years ago, was
to do an exploritory contract; you implement something that
might be part of what he wants, for a fairly limited price, and
decide where to go from there as a result of what you've done.
Usually, you can get some feedback even before this exploritory
contract is finished, and modify the contract in consequence.
The important point is that at any given time, the customer
knows what he will get, and how much it will cost him.

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

[Bart van Ingen Schenau]

On 8 jul, 22:00, Ian Collins <[e-mail] mwrote:

James Kanze wrote:

On Jul 8, 12:28 am, "Alf P. Steinbach" <[e-mail] wrote:

But whether the methodology is pure waterfall or not the
argument seems to be essentially that static headers make
sense for the kind of work that you do

Not necessarily static, but the version seen by other developers
shouldn't be changing on a day to day basis either. The key is
probably that there are other developers; that I'm not the only
client of my code.

Those last two words are the key - on projects I run, we don't have "my
code", only "our code".

That is likely to be the key in the disagreement.
I have worked on projects where it was impossible to have everything
as "our code". The number of developers (close to 100, located around
the globe) and the configuration-management setup (several
repositories that were not in perfect sync) just made it impractical.
You could refer to the module you were working on as "out code", but
not the entire application.

>

For if that generalization held, then refactoring and other
common techniques for iterative development, requiring
changing headers, would just be ungood. ;-)

Breaking the build has always been a major sin, regardless of
the place I've been working. Any time you check out a header,
you take that risk.

But you don't check it back in until or the tests pass, do you?

Yes, but if it is an external interface, the fact that the tests pass
on your copy of the source code (repository) does not mean it won't
break for other developers working on a different repository.
For example, while you were changing the interface, they were writing
a new module that uses the interface.

>
--
Ian Collins.

Bart v Ingen Schenau

[James Kanze]

On Jul 8, 10:00 pm, Ian Collins <[e-mail] mwrote:

James Kanze wrote:

On Jul 8, 12:28 am, "Alf P. Steinbach" <[e-mail] wrote:

I think that argument is relative to methodology, and only
makes sense with relative pure waterfall (analyse -design
(write headers, cast in stone) -implement -test).

I've never heard of "waterfall methodology" except as a strawman
against which other methodologies can argue.

Really? I've only had to suffer it once and only until the
project got into trouble!

I've never seen a methodology which defined such a way of
working. Maybe it's something new that I've missed. But the
classical methodology 25-30 years ago was the spiral, with the
next set of specifications being developed while you were
working on the previous. (Depending on the application domain,
the loop time in the spiral could be as short as one or two
days, or as long as a month. I can only remember one project
where it was longer---and it got into trouble.)

But whether the methodology is pure waterfall or not the
argument seems to be essentially that static headers make
sense for the kind of work that you do

Not necessarily static, but the version seen by other
developers shouldn't be changing on a day to day basis
either. The key is probably that there are other
developers; that I'm not the only client of my code.

Those last two words are the key - on projects I run, we don't
have "my code", only "our code".

That's true up to a point, but at any given moment, one person
has the code checked out, and in the editor, and other people
are using it as a client.

More generally, I'm not sure that you want to go too far in
either direction. The "this is my code, you can't modify it",
or "this is my code, you don't have to understand it" attitudes
are certainly counter productive, but the "this is my code, and
I'm proud of it, and want to make it the best possible" is
probably an attitude to encourage. When I encounter the first
attitude, I'll insist on the "it's our code, not my code" too.
When I find people getting slipshod and careless, however, I'll
work on the "pride in your work" theme.

For if that generalization held, then refactoring and other
common techniques for iterative development, requiring
changing headers, would just be ungood. ;-)

Breaking the build has always been a major sin, regardless of
the place I've been working. Any time you check out a header,
you take that risk.

But you don't check it back in until or the tests pass, do you?

Of course not. But you're never sure that the tests cover
everything.

--
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 8, 10:27 am, Juha Nieminen <nos...@thanks. invalidwrote:

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

No. I just recognize that 90% of the time is spent in 10% of
the code, or whatever. As I've said elsewhere, if the profiler
says a speed up is necessary in a particular part of the code,
inlining is one of the simplest and safest optimizations you can
do (other than just turning up compiler optimization). In
practice, however, I've never had to do so. (I have no problem
imagining that there are cases where it would be necessary,
however.)

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

So in one special case...

As a general rule, don't inline until the profiler says you have
to. Most of the time, it will have no significant effect on
either speed nor size (unless you force the inlining of very
large functions). If you have a performance problem, it's ONE
of the things to consider. One of the first, since it is so
simple.

--
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 9, 9:36 am, Michael DOUBEZ <michael.dou... @free.frwrote:

James Kanze a écrit :

I've never heard of "waterfall methodology" except as a
strawman against which other methodologies can argue.

What do you mean by that ?

That the only times I've ever heard the term used, or a
process described that would correspond to it, is as a strawman,
put forward by people advocating some other process. It's
easier to make your process look good if you invent something
unrealistically bad to compare it to.

I have worked in a waterfall environment, we used to make 4
docs before actual implementation: general, functional,
detailed, test. And each doc was reviewed and signed by one
peer, one expert and one quality guy. The project failed when
the director decided (to be fair, he didn't have much of a
choice) to shift the solution space the code was designed to
solve.

I'm not saying that methodogies are never misunderstood or
misused. I've seen some pretty bad management myself, for a
variety of different reasons. The worst case I can remember was
more or less what I would call the "million monkeys"
methodology. You know the theory: a million monkeys, typing
away at random on typewriters, will eventually produce all of
the works of Shakespeare. Or, in a software context, hire more
and more people, and get them coding immediately, without any
design, nor even any idea of what the real requirements are.

A friend of mine is working at the bank of France and they
have an even more long cycle regarding any change but I guess
the requirements are pretty stables.

The more stable the requirements, the longer the cycle times can
be. Several times, I've implemented transmission protocols
defined by a standard---in those cases, I could at least be sure
that one part of the requirements wasn't going to change. (But
only one part.)

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