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

[Ian Collins]

James Kanze wrote:

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

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

James Kanze wrote:

On Jul 9, 12:32 pm, Ian Collins <[e-mail] m>
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 objektorientier ter Datenverarbeitu ng
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] mwrote:

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