Use Inline in class?

[Jerry Coffin]

[ ... ]

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.

 

[Lionel B]

* Lionel B:

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.

 

[James Kanze]

* James Kanze:

[...]

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.

 

[Stefan Ram]

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.

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.

 

[Bo Persson]

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.

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.

About the same, except the contract is only valid for 2-4 weeks. After
that, the customer is free to order what he now realized he really
wanted the most.



Bo Persson

 

[Ian Collins]

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!

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

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]

About the same, except the contract is only valid for 2-4 weeks. After
that, the customer is free to order what he now realized he really
wanted the most.

That's typical for agile projects I've done. One is still rolling on 5
years later.

 

[Michael DOUBEZ]

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 ?

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.

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.

 

[Bart van Ingen Schenau]

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.

Bart v Ingen Schenau

 

[James Kanze]

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]

About the same, except the contract is only valid for 2-4
weeks. After that, the customer is free to order what he now
realized he really wanted the most.

In other words: a new name for the same old game. Except that
in the old days, you'd usually establish a basic hourly rate
(and in Germany, a Stammvertrag), with just a simple technical
estimate which the customer signed off (sometimes as often as
every two or three days) for the final details.

 

[Bart van Ingen Schenau]

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.

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.

Bart v Ingen Schenau

 

[James Kanze]

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

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.

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]

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.

 

[Ian Collins]

In other words: a new name for the same old game. Except that
in the old days, you'd usually establish a basic hourly rate
(and in Germany, a Stammvertrag), with just a simple technical
estimate which the customer signed off (sometimes as often as
every two or three days) for the final details.

Not really. On an agile project, what gets delivered every couple of
weeks is a working system. Each set of features adds more business
value than is costs to implement. Once there is no more value to add,
the project stops.

 

[James Kanze]

Not really. On an agile project, what gets delivered every couple of
weeks is a working system.

If that's what the customer needs and wants. It usually is, but
I've encountered exceptions.

Each set of features adds more business value than is costs to
implement.

And you guarantee that to the customer before hand.

In my experience, especially at the beginning, sometimes, the
set of features reduces business value---but the customer
couldn't or didn't realize that until we implemented them. The
important point, however, was that the customer knew in advance
what he was paying for; a set of features known to be needed, or
some experiemental system for evaluation.

Once there is no more value to add, the project stops.

There's always something more that you could add. The question
isn't whether there is potentially more value, but whether the
additional value is worth more than the cost to implement it.

Note (and I think you agree, but it hasn't been said) that
knowledge has a real value. Knowing that something won't
actually improve your productivity has business value as well.

 

[James Kanze]

James Kanze a écrit :

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

 

[Ian Collins]

If that's what the customer needs and wants. It usually is, but
I've encountered exceptions.


And you guarantee that to the customer before hand.

Yes, hence the short iterations and accurate estimation.

In my experience, especially at the beginning, sometimes, the
set of features reduces business value---but the customer
couldn't or didn't realize that until we implemented them.

That's where short iterations and rapid customer feedback helps.
Getting the customer to focus on the core requirements first is a very
important and often overlooked part of the process. I had one client
who'd been convinced by a nameless large consultancy they wanted a 6
month project. After an hour or two whittling this down to what they
really wanted, there as about 4 weeks work to give them 80% of the value!

The
important point, however, was that the customer knew in advance
what he was paying for; a set of features known to be needed, or
some experiemental system for evaluation.

Often an XP project starts of as both. They know what they want, but
not how they want it. The first few iterations act as the seed for
their requirements, they see what the application can do and grow it
from there.

There's always something more that you could add. The question
isn't whether there is potentially more value, but whether the
additional value is worth more than the cost to implement it.

Which is what I said earlier.

Note (and I think you agree, but it hasn't been said) that
knowledge has a real value. Knowing that something won't
actually improve your productivity has business value as well.

Agreed and by focusing the client on the features that are most
important to them at each iteration (and this priority often changes)
helps then do this.

 

[James Kanze]

Yes, hence the short iterations and accurate estimation.

That's where short iterations and rapid customer feedback
helps. Getting the customer to focus on the core requirements
first is a very important and often overlooked part of the
process. I had one client who'd been convinced by a nameless
large consultancy they wanted a 6 month project. After an
hour or two whittling this down to what they really wanted,
there as about 4 weeks work to give them 80% of the value!

Yes. Getting the customer to understand what he's asking for,
what he really needs, and what we can do, at what price, is an
important part of the process.

Often an XP project starts of as both. They know what they
want, but not how they want it. The first few iterations act
as the seed for their requirements, they see what the
application can do and grow it from there.

I'm not sure where the XP is involved. This was the way we
worked 20 years ago, before I'd even started using C++, or was
aware of the SEI.

 

[Ian Collins]

I'm not sure where the XP is involved. This was the way we
worked 20 years ago, before I'd even started using C++, or was
aware of the SEI.

Indeed it was. XP was partly an reaction to the bloated methodologies
that grew up in the 90s.