James Kanze schrieb:

>
>
> > Not everyone here is writing library code with thousands of users.  In
> > fact, most of us don't write library code at all; and many libraries
> > are used only by a handful of projects. In other words, sometimes we
> > can consider code to be decoupled based on the fact that source won't
> > change, even if we do need a recompile.

How do you define "library code"?

In fact, I think most of us write code intended for use or just used by
others(or even by yourself at a time you you are actively working on
something different and use your low-level packages.
They are all affected by changes of your code.

>
>
> > Certainly we want to minimize situations where a one-line change to a
> > header file requires most or all of a project to rebuild. But it isn't
> > an all-or-nothing proposition. I think it's okay to put an inline
> > function in a library that (for instance) implements business rules,
> > recognizing that business rules do change from time to time -- but not
> > every week!

I suggest to read "Large Scale C++ Software Design" by John Lakos.
This discusses implementations, pros and cons and performance measurements of
those techniques.


best regards,

Thomas

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]

allan_w@my-dejanews.com (Allan W) wrote in message
news:<7f2735a5.0212261414.5a9de2fd@posting.google.com>...
> kanze@gabi-soft.de (James Kanze) wrote
> > If the only issue were optimization, I'd agree with you.  But IMHO,
> > source code coupling is at least as an important an issue.  What
> > happens when the pure forwarding function ceases to be a pure
> > forwarding function?  Whether you take the function out of line, or
> > modify the inline version, you still have to recompile all of the
> > client code.

> > On the other hand, I've gotten into the habit of providing explicit
> > constructors, assignment and destructors, even when the compiler
> > generated defaults will do.  Because the compiler generated defaults
> > are inline, and if I change anything which means they won't do, all
> > of the client code will be recompiled.

> Not everyone here is writing library code with thousands of users.  In
> fact, most of us don't write library code at all; and many libraries
> are used only by a handful of projects. In other words, sometimes we
> can consider code to be decoupled based on the fact that source won't
> change, even if we do need a recompile.

My concern is actually more with application level code.  I'm not too
worried about source code coupling in <vector>; I certainly don't expect
its implementation to change on a daily basis (at least not in the
version I'm using).  And if I were implementing a version of the
standard library, I probably would make std::vector<>::operator[]
inline.  Even before my clients complained that it was too slow
otherwise:-).

> Certainly we want to minimize situations where a one-line change to a
> header file requires most or all of a project to rebuild. But it isn't
> an all-or-nothing proposition. I think it's okay to put an inline
> function in a library that (for instance) implements business rules,
> recognizing that business rules do change from time to time -- but not
> every week!

It's not just whether the business rules change.  It's also the fact
that you probably have bugs in them.  I'm willing to bet that your
business rules have a lot less users than, say the implementation of
std::vector in VC++.  Less users mean less tests, and more likelyhood of
error.

Since the moderators have complained about subject drift (correctly,
since we certainly aren't discussing what the standard says, or should
say, but rather general C++ development techniques), I've cross-posted
to comp.lang.c++.moderated, and suggest that any further discussion take
place there.  (I'd also set followup-to, but I'm posting through Google,
and don't have this possibility.)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]