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

[HL]

On 7ÔÂ6ÈÕ, ÉÏÎç8ʱ31·Ö, Immortal Nephi <[e-mail]:

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?

no need

};

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

yes, you need.

another way is to define func in class.
class A{
public:
void Test(){...};
};
Test is refered as inline.

[Sam]

Immortal Nephi writes:

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?

No.

};

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

Yes.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkhwGSoACgkQx9p3GYHlUOI+NQCbBuUnXa7tCU MjpcGCPo9YKvbA
yFwAn271esMxKOBacxrSFw31D46g17m3
=TrHL
-----END PGP SIGNATURE-----

[Andrey Tarasevich]

Immortal Nephi wrote:

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

If you want to define your inline member function outside the class
definition (as in your example above), you only need to specify 'inline'
in the member definition (the second 'inline' in your example)

class A {
...
void Test();
...
};

inline void A::Test()
{
}

--
Best regards,
Andrey Tarasevich

[Juha Nieminen]

Andrey Tarasevich wrote:

If you want to define your inline member function outside the class
definition (as in your example above), you only need to specify 'inline'
in the member definition (the second 'inline' in your example)

If this is the case, why is the keyword 'inline' even supported inside
class definitions? Isn't it completely obsolete and a no-op there?
(Basically there's not even one single case where specifying that
keyword in the class definition makes a difference.)

[James Kanze]

On Jul 6, 10:30 am, Juha Nieminen <[e-mail]:

Andrey Tarasevich wrote:

If you want to define your inline member function outside
the class definition (as in your example above), you only
need to specify 'inline' in the member definition (the
second 'inline' in your example)

If this is the case, why is the keyword 'inline' even
supported inside class definitions? Isn't it completely
obsolete and a no-op there? (Basically there's not even one
single case where specifying that keyword in the class
definition makes a difference.)

You can specify inline on either the definition or any
declaration which precedes it, and the function will be inline.
Current practice is to specify it on the definition, but at
least one earlier compiler I used required it to be specified on
the first declaration that appeared.

Of course, current best pratice is not to use inline at all, so
the problem doesn't occur.

--
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, [phone]

[joseph cook]

Of course, current best practice is not to use inline at all, so

the problem doesn't occur.

Why do you say this? In-lining functions in a header file can be
critical for performance reasons.
Thanks,
Joe Cook

[James Kanze]

On Jul 6, 5:20 pm, joseph cook <[e-mail]:

Of course, current best practice is not to use inline at all, so
the problem doesn't occur.

Why do you say this?

Because it increases coupling.

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.

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.

--
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, [phone]

[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. As to
maintenance I really don't understand: what time do you save?

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

[James Kanze]

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

* James Kanze:

On Jul 6, 5:20 pm, joseph cook <[e-mail]:

>Of course, current best practice is not to use inline at all, so
the problem doesn't occur.

Why do you say this?

Because it increases coupling.

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.

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 don't know where you get that from. It is a nightmare with
regards to maintenance, easily doubling the effort required.
(To begin with, if you don't know if the function is inlined or
not, you don't even know in which file to look for it. And of
course, if you have to modify it, then all of the client code
needs to be recompiled.)

I agree that doing inlining for reasons of performance would
be premature optimization, of the kind that might even
influence runtime in a negative way, and bring in unwanted
coupling and have other undesirable effect.

However, used as a means for programmer productivity, not as
premature optimization, its effect on coupling is generally
negligible.

If it's used in a template, it's negligible, because the
template code has to be included anyway (at least with most
current compilers). If it's not a template, however, the effect
in practice can be quite high.

Obviously, it's only one factor: you can write impossible to
maintain code without a single inline function, and carefully
used, you can minimize the impact. 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. (The rules for library code are somewhat different,
since you often have to guess where the client code's
bottlenecks might occur.)

It can even reduce the number of files that must be opened and
read during a build. I think the programmer who's afraid of
using std::vector just because it's perceived as a large
header & requires full def of element type, is seriously
misguided.

That, certainly. But std::vector is (hopefully) stable code,
which isn't evolving while you're working. So you won't end up
having to recompile everything because there was a small
correction in the implementation somewhere. (If you upgrade
your compiler, of course, you'll get a new version of
std::vector. But if you upgrade your compiler, you have to
recompile everything anyway, since all of the object files
depend in some way on the compiler. On the other hand, you
shouldn't be upgrading the compiler very often---maybe once
every two or three years, at the most.)

--
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, [phone]

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

* 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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

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

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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

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

* 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 objektorientierter Datenverarbeitung
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]:

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

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

James Kanze wrote:

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

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 objektorientierter Datenverarbeitung
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 <[e-mail]:

>On Jul 6, 9:59 pm, "Alf P. Steinbach" <[e-mail]: 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]:

>James Kanze wrote:

>>On Jul 7, 10:11 am, Ian Collins <[e-mail]:
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.

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.

[Jerry Coffin]

In article <6d************@mid.individual.net>, ia******@hotmail.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 <[e-mail]:
On Jul 6, 9:59 pm, "Alf P. Steinbach" <[e-mail]: 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]:

* 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 objektorientierter Datenverarbeitung
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]:

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

James Kanze wrote:

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

James Kanze wrote:
On Jul 7, 10:11 am, Ian Collins <[e-mail]:
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.

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 <[e-mail]:

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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Bart van Ingen Schenau]

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

James Kanze wrote:

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

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

James Kanze wrote:

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

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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 8, 10:27 am, Juha Nieminen <[e-mail]:

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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 9, 9:36 am, Michael DOUBEZ <[e-mail]:

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 objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ian Collins]

James Kanze wrote:

On Jul 9, 12:32 pm, Ian Collins <[e-mail]:

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

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.

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

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.

--
Ian Collins.

[James Kanze]

On Jul 9, 10:50 pm, Ian Collins <[e-mail]:

James Kanze wrote:

On Jul 9, 12:32 pm, Ian Collins <[e-mail]>
wrote:

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.

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!

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.

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.

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.

--
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, [phone]

[Ian Collins]

James Kanze wrote:

On Jul 9, 10:50 pm, Ian Collins <[e-mail]:

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

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

--
Ian Collins.