Use Inline in class?
Immortal Nephi
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
> 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?
> {
> {
another way is to define func in class.
class A{
public:
void Test(){...};
};
Test is refered as inline.
Sam
> 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.
Andrey Tarasevich
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
> 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
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:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
joseph cook
> 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
> > 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.
Alf P. Steinbach
> On Jul 6, 5:20 pm, joseph cook <joec...@gmail.com> wrote:
>>> 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 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. 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.
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Gennaro Prota
> * 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.
Alf P. Steinbach
> 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. ;-)
> 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.
Cheers, & hth.,
James Kanze
> * James Kanze:
> > On Jul 6, 5:20 pm, joseph cook <joec...@gmail.com> wrote:
> >>> 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.)
Ian Collins
> 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
> * 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.)
Alf P. Steinbach
This sounds very much like arbitrary decisions that have made themselves into
law, and are not being rationalizated is if they were meaningful.
Such rationalizations typically include numerous self-contradictions, such as
the very first response paragraph above -- or the last one.
I'd not know where to begin, it's just utterly void of meaning.
James Kanze
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
> * 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.
Ian Collins
> On Jul 7, 10:11 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> 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.
>
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
> 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>
Alf P. Steinbach
> On Jul 7, 10:11 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> 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.
The day you have to implement what was previously a compiler-generated default
constructor, destructor, copy assignment operator or copy constructor you have
most probably changed your class' invariant, and already changed 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.
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). 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 -- 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".
For if that generalization held, then refactoring and other common techniques
for iterative development, requiring changing headers, would just be ungood. ;-)
Greg Herlihy
About the only programmers who could conceivably think that that Java
classes are somehow "unmaintaintable" - might be those who are still
using 60's-era program editors to write their code. Because, in
practice (that is, with modern tools), there is no question that Java
learned from C++ mistakes in the area of program interfaces - and
(among other improvements) eliminated the pointless redundancy and
needless exposure of class implementation details found in C++.
For one, a Java programmer can simply "collapse" a class' function
bodies - in order to examine the class's pure interface. Moreover,
when distributing the header of a Java "package" (comparable to a C++
library), the package's (automatically-generated) interface file
includes only those class members and methods that are accessible to
clients. Otherwise, all non-accessible class methods (and members) are
simply not present in the package interface file at all. 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.
Greg
James Kanze
> James Kanze wrote:
> > On Jul 7, 10:11 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> 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.
Juha Nieminen
> For one, a Java programmer can simply "collapse" a class' function
> bodies - in order to examine the class's pure interface.
It sounds to me that you are saying that you require rather advanced,
very Java-conscious editors in order to make Java source code readable.
That a regular text editor won't do. That sounds to me like the exact
opposite of what you are attempting to say: Java source code is by
default so complicated that fancy editing programs are needed to make it
readable.
> 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.
Naming conflicts and access violations? What kind of bullshit is this?
Juha Nieminen
>> 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 Jul 7, 1:16 am, James Kanze <james.ka...@gmail.com> wrote:
>> On Jul 6, 9:59 pm, "Alf P. Steinbach" <al...@start.no> 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
Alf P. Steinbach
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...
Ian Collins
> On Jul 7, 10:13 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>>> On Jul 7, 10:11 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>>> 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.
>
non-static inline function? I'm assuming compiler generated functions
fall into this category. Or do they?
--
Ian Collins.
Jerry Coffin
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.
Alf P. Steinbach
> In article <6dgtt6F...@mid.individual.net>, ian-...@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.
I think Ian's comment was more about resulting executable than the source code,
i.e., for the in-practice, about the linker's folding of duplicates.
And yes, the address of an external linkage inline function (the default) is
required to be the same in all translation units.
Presumably that means that a compiler doesn't have much choice about it, unless
it goes out of its way to "anti-optimize" the program (oh, address not taken,
here we can anti-optimize!), and so answer is a qualified yes, at most one copy.
Lionel B
Ok... perhaps my understanding of the phrase "client of the interface"
didn't extend to derivation.
--
Lionel B
James Kanze
> * 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.
Bo Persson
> James Kanze <james...@gmail.com> writes:
>> I've never heard of "waterfall methodology" except as a strawman
>> against which other methodologies can argue.
>
> 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
> On Jul 8, 12:28 am, "Alf P. Steinbach" <al...@start.no> 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.
>
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.
Ian Collins
years later.
--
Ian Collins.
Michael DOUBEZ
> 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.
--
Michael
Bart van Ingen Schenau
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
> James Kanze <james.ka...@gmail.com> writes:
> >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
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
> James Kanze wrote:
> > On Jul 8, 12:28 am, "Alf P. Steinbach" <al...@start.no> 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.
James Kanze
> James Kanze wrote:
> > On Jul 8, 12:28 am, "Alf P. Steinbach" <al...@start.no> 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
> 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.
Ian Collins
> On Jul 8, 6:36 pm, "Bo Persson" <b...@gmb.dk> wrote:
>> Stefan Ram wrote:
>>> James Kanze <james.ka...@gmail.com> writes:
>>>> 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.
>
>> 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.
>
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.
--
Ian Collins.
James Kanze
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 :
> > 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.)
Ian Collins
> On Jul 9, 12:32 pm, Ian Collins <ian-n...@hotmail.com> 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.
>
> 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
> James Kanze wrote:
> > On Jul 9, 12:32 pm, Ian Collins <ian-n...@hotmail.com>
> > 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.
Ian Collins
> On Jul 9, 10:50 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>
>> 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.
>
that grew up in the 90s.
--
Ian Collins.