Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Use Inline in class?

Reply
Thread Tools

Use Inline in class?

 
 
James Kanze
Guest
Posts: n/a
 
      07-09-2008
On Jul 8, 6:36 pm, "Bo Persson" <(E-Mail Removed)> wrote:
> Stefan Ram wrote:
> > James Kanze <(E-Mail Removed)> 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.

--
James Kanze (GABI Software) email:(E-Mail Removed)
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
 
Reply With Quote
 
 
 
 
Bart van Ingen Schenau
Guest
Posts: n/a
 
      07-09-2008
On 8 jul, 22:00, Ian Collins <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > On Jul 8, 12:28 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:

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

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

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


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

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

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

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


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

>
> --
> Ian Collins.


Bart v Ingen Schenau
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      07-09-2008
On Jul 8, 10:00 pm, Ian Collins <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > On Jul 8, 12:28 am, "Alf P. Steinbach" <(E-Mail Removed)> wrote:


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


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


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


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

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


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


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


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

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

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


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


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


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

--
James Kanze (GABI Software) email:(E-Mail Removed)
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
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-09-2008
On Jul 8, 10:27 am, Juha Nieminen <(E-Mail Removed)> wrote:
> 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:(E-Mail Removed)
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
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      07-09-2008
James Kanze wrote:
> On Jul 8, 6:36 pm, "Bo Persson" <(E-Mail Removed)> wrote:
>> Stefan Ram wrote:
>>> James Kanze <(E-Mail Removed)> 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.
>

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

--
Ian Collins.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-09-2008
On Jul 9, 12:32 pm, Ian Collins <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > On Jul 8, 6:36 pm, "Bo Persson" <(E-Mail Removed)> wrote:
> >> Stefan Ram wrote:
> >>> James Kanze <(E-Mail Removed)> 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.


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


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

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


And you guarantee that to the customer before hand.

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

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


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

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

--
James Kanze (GABI Software) email:(E-Mail Removed)
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
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-09-2008
On Jul 9, 9:36 am, Michael DOUBEZ <(E-Mail Removed)> wrote:
> 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:(E-Mail Removed)
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
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      07-09-2008
James Kanze wrote:
> On Jul 9, 12:32 pm, Ian Collins <(E-Mail Removed)> 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!

> 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.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-10-2008
On Jul 9, 10:50 pm, Ian Collins <(E-Mail Removed)> wrote:
> James Kanze wrote:
> > On Jul 9, 12:32 pm, Ian Collins <(E-Mail Removed)>
> > 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:(E-Mail Removed)
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
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      07-10-2008
James Kanze wrote:
> On Jul 9, 10:50 pm, Ian Collins <(E-Mail Removed)> 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.
>

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

--
Ian Collins.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Tool which expands implicitly inline inline functions tthunder@gmx.de C++ 3 06-16-2005 12:54 AM
To inline or not to inline? Alvin C++ 7 05-06-2005 03:04 PM
Use of inline function in inline function - is it allowed? TGOS C Programming 3 02-28-2005 10:49 AM
External inline functions calling internal inline functions Daniel Vallstrom C Programming 2 11-21-2003 01:57 PM
inline or not to inline in C++ Abhi C++ 2 07-03-2003 12:07 AM



Advertisments