Re: Maintenance of general implementations
On Feb 27, 2:52 pm, fredrik.eriksson.storam...@gmail.com wrote:
On 25 Feb, 18:45, "James Kanze" <james.ka...@gmail.com> wrote:
On Feb 24, 1:59 am, fredrik.eriksson.storam...@gmail.com wrote:
Also, of course, client code should statically link with them,
so you don't have the problem of different programs requiring
different versions of the same dynamic library.
Is statically linking a common practice in this kind of scenario? I
highly respect your opinion James, but couldn't there be other
problems when you link statically? Say there is a bug in queue-handler
that is part of the general implementation then "all" products has to
link and deploy, this is not a good scenario for us, or at least it
would be quite expensive to correct that kind of bugs. The memory
footprint could be a problem also, at least on our test machines, of
course I don't know this for a fact, but they are under a lot of
stress at this point.
Do you think it is possible to use dynamic libraries instead? I think
there would only be about 5 libraries that would be provided in
different versions (we are also thinking of merging some of them into
one, so there could be even fever) and if we only have a maximum of 3
concurrent versions for each lib at a single time there should not be
to much of a hassle for dependent products to keep track of which
libraries they build against.
It depends on what you are trying to do. Dynamic linking is
used for cases where you want to be be able to link with
different versions---typically, third party systems which
guarantee an interface. I'd dynamically link the system library
(libc, under Unix), and things like data base libraries. On the
other hand, dynamic linking usually means that you've
effectively never tested the version the client is running, and
once incompatible versions of a library exist, is a nightmare
with regards to keeping things straight. It also creates
problems with deployment; you don't have a single binary file,
but a set of files, including the targeted versions of the
dynamic objects. By default, the standard link model should be
static, with dynamic linking reserved for special cases where
the dynamicism is necessary enough to outweigh the advantages.
Otherwise, it's just one more thing that can go wrong.
There are exceptions, of course. If you have a number of
different applications which communicate, it might be
appropriate to put the communications software in a dynamic
library. In this case, it is probably more important that all
of the programs use the same version of the communications
software (same protocol over the sockets) that that all of the
programs use the version that they were tested with. But you
still must be aware of the risk---in your scenario concerning
the queue-handler, for example, you still want to test every
application with the new library before deploying it, and it's a
lot easier to ensure that no application uses a version with
which it hasn't been tested if you statically link.
I can only see two solutions:
1) We deliver different versions of these libs, and the products can
chose if they want to use the better quality libs and link against
these. There is about 3-10 libs that would be in different versions,
and about 30 header files, so I think that it would be doable to keep
track of the versions of these. Over time we can decrease the total
maintenance of the implementation and have better quality to a cheaper
price.
Keeping track of the versions, and which version each
application sees, is the job of your version control system. If
your version control system isn't doing it, easily, it's time to
learn it better, or change it, if it isn't possible.
2) We develop new classes and such concurrent to the old bad quality
implementation. This is, sort of, the way we are doing today. The
problem is still that if someone is using part of the implementation
we are in trouble if we want to change it. And the maintenance of the
implementation is increasing rapidly!
One possible solution is to include versionning information in
the namespace name. (I got this idea from Nathan Meyers, I
think.) But if the new class (or the class in the new
namespace) derives in fact from an older version, this should be
tracked in the version control system; you don't just start from
scratch.
Yes, this seems like a reasonable plan B. One of the downsides of this
approach, in my view, is that it's harder to get rid of obsolete code.
We have a lot of code that is really, really bad that we would like to
get rid of over time, hence eliminating the chance of usage of this
code.
You can't get rid of it completely until no application uses it.
Regardless of the strategy used to manage it.
--
James Kanze (GABI Software) email:james.kanze@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
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]