c code reusability

M

mister catering

I have a doubt... why is so dificult to reuse software developed under
the same language (not only c of course) and under the same compiler?.
It seems the language itself is not enough to build a non trivial
system. Is this right? should I think in use other assets as package
systems, component models etc... to build something complex? did this
assets exist with no cost and no OS dependence? is there an agree on
the use of them in the open source programming comunity?

if the answers are:

1.- C language (or gcc compiler) is not enough. An open, portable and
widely used component model is necesary for non trivial systems
2.- There's no such a model in the open source world

my question is:

what are we waiting for?

thanks...
 
A

Ancient_Hacker

mister said:
I have a doubt... why is so dificult to reuse software developed under
the same language (not only c of course) and under the same compiler?.


Good question. The concept is a good one, but fraught with pitfalls.

It's hard to write code in such a general fashion that it can be widely
adopted and adapted.

Even with compilers that embrace templates and abstraction, it's often
too cumbersome to use canned code. All too often the code does 97% of
the job, but to get the needed last 3% requires digging into the
source code, at which point it's a slippery slope,\... you start seeing
places where you can dump pages of code, or insert a better algorithm,
or make all the strings localizable, and before you know it, there's
almost none of the original code left.

.... or the canned code may make outdated assumptions, like memory is
expensive, or it's tied to some other package that you really don't
want to drag in.

Ideally we'd have all of Knuth's and CACM algorithms typed in using
some meta-language, and have compilers that could generate code from
the meta-language into whatever language we wanted. But we're not
there yet.
 
R

Richard Heathfield

mister catering said:
I have a doubt... why is so dificult to reuse software developed under
the same language (not only c of course) and under the same compiler?.

It's not. Just shove the stuff you want to re-use into its own library.
Shove the public interface (prototypes, any needed type and macro defs,
etc) into a header. Include the header, link the library, and you're done.
This is even easier than rocket science.
 
B

Ben Pfaff

Richard Heathfield said:
mister catering said:


It's not. Just shove the stuff you want to re-use into its own library.
Shove the public interface (prototypes, any needed type and macro defs,
etc) into a header. Include the header, link the library, and you're done.

Application code doesn't usually make a good library so easily,
in my experience. An application and a library often have
different assumptions.
This is even easier than rocket science.

Famous last words...
 
R

Richard Heathfield

Ben Pfaff said:
Application code doesn't usually make a good library so easily,
in my experience. An application and a library often have
different assumptions.

I tend to think of an application as a relatively thin layer of glue that
determines in which order, and how often, library routines are called. :)
Famous last words...

I chose them very carefully.
 
S

Stan Milam

Ben said:
Application code doesn't usually make a good library so easily,
in my experience. An application and a library often have
different assumptions.




Famous last words...

Over the years while writing some non-trival programs I have discovered
functionality that I thought could be used again down the road. When I
see these I pull them out, get rid of the program specifics to make the
function generic and put into my library. As the years go by I find
that my application programs are just code to solve a specific task and
all that library code is doing the heavy lifting. I write the library
code with portability in mind and I have compiled it on DOS (three
different compilers), AIX, HPUX, and Linux. I've pretty much dropped
DOS and "I don't do Windows," but it should not be much of a problem
there, except that it is Windows - The Non Portable OS.

--
Regards,
Stan Milam
=============================================================
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
=============================================================
 
B

Ben Pfaff

Richard Heathfield said:
Ben Pfaff said:


I tend to think of an application as a relatively thin layer of glue that
determines in which order, and how often, library routines are called. :)

Well, if that's the way you write your code, then that's great.
But I don't think most code is up to that level of quality or
abstraction.
 
F

Frederick Gotham

mister catering posted:
I have a doubt... why is so dificult to reuse software developed under
the same language (not only c of course) and under the same compiler?


Because any such software is poorly written by incompetant programmers.

It seems the language itself is not enough to build a non trivial
system. Is this right?


No, the Standard provides us with the means to write portable code.
 
M

mister catering

Richard said:
mister catering said:


It's not. Just shove the stuff you want to re-use into its own library.
Shove the public interface (prototypes, any needed type and macro defs,
etc) into a header. Include the header, link the library, and you're done.
--

OK, it's true... there's really a lot of sofware programmed in this
way... but, what happens with versioning? Imagine that you have
developed a library (YourLibrary) that is widely used by other
library/programs (Client1, Client2 ... ,ClientN). Programmer of Client1
knows about a new version of your library (YourLibrary 2.0) he is
interested in. He develop a new version of his program (Client1 2.0)
based on YourLibrary 2.0. We'll suposse Client2 to ClientN are not
interested in the new functionality of YourLibrary. Imagine a system
with all this clients installed... with the reusability style you
propose (that is the c reusability standard style) is not possible to
have Client1 2.0 and the rest of clients running at the same time. The
user have to wait for the new versions of Client2 to ClientN to run
Client1 2.0

Of course i'm thinking in a evolution of your library that can't be
backward compatible

Perhaps i'm in a mistake... in this case explain me why but... if I'm
not in a mistake please answer this... is not desirable to have a
solution for this problem?
 
R

Richard Heathfield

mister catering said:
Imagine that you have
developed a library (YourLibrary) that is widely used by other
library/programs (Client1, Client2 ... ,ClientN). Programmer of Client1
knows about a new version of your library (YourLibrary 2.0) he is
interested in. He develop a new version of his program (Client1 2.0)
based on YourLibrary 2.0.

Fine, no problem. He can do that.
We'll suposse Client2 to ClientN are not
interested in the new functionality of YourLibrary.

And they don't have to.
Imagine a system
with all this clients installed... with the reusability style you
propose (that is the c reusability standard style) is not possible to
have Client1 2.0 and the rest of clients running at the same time.

Sure it is. Ever heard of static linking?

Dynamic linking has its advantages, but it also has a great many
disadvantages. You have already identified one of them. Another is that it
becomes too easy to introduce fresh bugs into a previously working program.
Unfortunately, on some OSs you don't have much choice but to use dynamic
linking for at least some aspects of the program (e.g. Windows system calls
almost invariably resolve to a DLL call, which is a big shame), but you can
minimise the problems by using static linking as much as possible.
 
M

Michael Wojcik

mister catering said:
Imagine that you have
developed a library (YourLibrary) that is widely used by other
library/programs (Client1, Client2 ... ,ClientN). Programmer of Client1
knows about a new version of your library (YourLibrary 2.0) he is
interested in. He develop a new version of his program (Client1 2.0)
based on YourLibrary 2.0. [...]
Imagine a system
with all this clients installed... with the reusability style you
propose (that is the c reusability standard style) is not possible to
have Client1 2.0 and the rest of clients running at the same time.

Nonsense. If the library is designed with an ounce of sense, the
new version will be backward-compatible with the old. There's no
reason for it to be otherwise. New functionality can be provided by
new functions; old functionality can be left alone, or refactored as
cover routines that call the new functions with flags indicating that
the old behavior should be used. If the library is designed with a
bit more sense, the old functionality would already be forward-
compatible with new functionality thanks to reserved parameters,
behavior flags, and so forth.
Dynamic linking has its advantages, but it also has a great many
disadvantages. You have already identified one of them.

Only if the library author is an idiot.
Another is that it
becomes too easy to introduce fresh bugs into a previously working program.

Since static linking makes it equivalently hard to correct bugs in
an already-buggy program, this is a wash. Indeed, if new functionality
is properly partitioned from old functionality, an update to a dynamic
library is far more likely to fix existing bugs than to introduce new
ones.
Unfortunately, on some OSs you don't have much choice but to use dynamic
linking for at least some aspects of the program (e.g. Windows system calls
almost invariably resolve to a DLL call, which is a big shame), but you can
minimise the problems by using static linking as much as possible.

Unfortunately, there are many things in the world, and most people have
no choice but to occasionally leave home to get some of them, but you
can minimize the problem by having as much stuff as possible right in
your home.

--
Michael Wojcik (e-mail address removed)

I will shoue the world one of the grate Wonders of the world in 15
months if Now man mourders me in Dors or out Dors
-- "Lord" Timothy Dexter, _A Pickle for the Knowing Ones_
 
R

Richard Heathfield

Michael Wojcik said:
Only if the library author is an idiot.

And your point?
Since static linking makes it equivalently hard to correct bugs in
an already-buggy program, this is a wash.

Not so. Just fix the bug and ship the executable, which is no harder than
fixing the bug and shipping the DLL.
Unfortunately, there are many things in the world, and most people have
no choice but to occasionally leave home to get some of them, but you
can minimize the problem by having as much stuff as possible right in
your home.

Yep, that strategy works for me. In any case, the analogy is flawed. In your
home, space is at a premium (unless you are extremely wealthy), whereas
disk space and computer memory are relatively cheap.
 
J

jacob navia

Richard said:
Michael Wojcik said:


Not so. Just fix the bug and ship the executable, which is no harder than
fixing the bug and shipping the DLL.

If your dll is used by several client executables, you can't ship the
executable, they would have to relink with a new version of the
static library you ship to them. This is not always possible since
it supposes a toolset (linker, libraries, etc) that may not be at
available at the client's site. Just shipping a dll makes only a file
copy necessary.


Another points for dlls that has not been mentioned is that (at least
under windows) dlls are called when loaded to initialize themselves.

This is very practical for libraries that need heavy initialization
stuff. Using a static library you are forced to write:

if (!initialized)
DoInit();

at the start of each entry point...

Dynamic linking can be abused (as anything). It is also the source
of hard to find errors. But just to dismiss it is nonsense.
 
R

Richard Heathfield

jacob navia said:
If your dll is used by several client executables, you can't ship the
executable,

Which is a good reason not to use DLLs. That way, the question doesn't
arise.

they would have to relink with a new version of the
static library you ship to them.

No, they wouldn't, because I wouldn't ship them a static library. I'd ship
them an executable program.

Dynamic linking can be abused (as anything). It is also the source
of hard to find errors. But just to dismiss it is nonsense.

I haven't dismissed dynamic linking. I said at the outset of this discussion
that dynamic linking has its advantages.
 
C

Chris Torek

Dynamic linking has its advantages, but it also has a great many
disadvantages. You have already identified one of them ...

.... the "one" being that if you "upgrade" libXYZ from version 1.3 to
version 2.1, a bunch of libXYZ-1.3-dependent applications stop
working because libXYZ-2.1 is not compatible with libXYZ-1.3.
Another is that it becomes too easy to introduce fresh bugs into
a previously working program.

Presumably you mean things break if you change libXYZ-1.3 to
libXYZ-1.4 and introduce a bug in it.
Unfortunately, on some OSs you don't have much choice but to
use dynamic linking for at least some aspects of the program ...

The second-listed problem above has a relatively easy cure: put
libXYZ-1.3 back in place of libXYZ-1.4, fix the problem with 1.4,
and then install libXYZ-1.5.

The first-listed problem is not a problem in a "correctly designed"
system: the fact that the new version of libXYZ is libXYZ-2.0
implies that it is *not* compatible with libXYZ-1.x (for any x),
and therefore applications dynamically linked against 1.x should
continue to link against 1.x (for the latest x), not 2.y (for any
y).

(Another way to look at this -- one which I think is in many ways
superior, except that it would never get past the marketing department
:) -- is that "libXYZ version 1.x" is really "libA version x",
while "libXYZ version 2.x" is really "libB version x". Clearly
libA and libB are entirely different, and libB is not a *replacement*
for libA. Eventually, if nothing remains that uses libA anymore
-- because all the applications have been converted to use libB --
you can remove libA, but not until then. The reason marketing does
not like this approach is that selling "completely different product
libB" is much harder than selling "new, improved version of old
product", even though it is really exactly the same task. This is
because, all too often, people do not make decisions based upon
logic -- using the prefrontal cortex -- but rather upon emotion,
using the amygdala.)
 
M

mister catering

Michael Wojcik ha escrito:
mister catering said:
Imagine that you have
developed a library (YourLibrary) that is widely used by other
library/programs (Client1, Client2 ... ,ClientN). Programmer of Client1
knows about a new version of your library (YourLibrary 2.0) he is
interested in. He develop a new version of his program (Client1 2.0)
based on YourLibrary 2.0. [...]
Imagine a system
with all this clients installed... with the reusability style you
propose (that is the c reusability standard style) is not possible to
have Client1 2.0 and the rest of clients running at the same time.

Nonsense. If the library is designed with an ounce of sense, the
new version will be backward-compatible with the old. There's no
reason for it to be otherwise. New functionality can be provided by
new functions; old functionality can be left alone, or refactored as
cover routines that call the new functions with flags indicating that
the old behavior should be used. If the library is designed with a
bit more sense, the old functionality would already be forward-
compatible with new functionality thanks to reserved parameters,
behavior flags, and so forth.

Of course, you always can qualify the name of the new functions with
the version number... by this way you are backward compatible and the
problem proposed is solved. But i think there's a price to avoid

Think i'm the user of the new version... with your solution I need to
change the names i was using, while the semantics could be the same. If
i was using the function "rotate" of YourLibrary and now i'm going to
use the more powerful "rotate" of YourLibrary 2.0 i'm not more
interested in the old rotate semantics. I don't need to distinguish the
two meanings (only the servers needs it) and I always prefer to see
"rotate" printed in my code than "YourLibrary__v2r0__rotate". Ok these
are only style issues but they are important from my point of view

do you think it would be desirable to preserve the operation names
(when necessary) across versions?
 
M

mister catering

Mr Torek, you've put your finger on the sore spot
... if you "upgrade" libXYZ from version 1.3 to
version 2.1, a bunch of libXYZ-1.3-dependent applications stop
working because libXYZ-2.1 is not compatible with libXYZ-1.3.

OK, i agree
... is not a problem in a "correctly designed"
system: the fact that the new version of libXYZ is libXYZ-2.0
implies that it is *not* compatible with libXYZ-1.x (for any x),
and therefore applications dynamically linked against 1.x should
continue to link against 1.x (for the latest x), not 2.y (for any
y).

does exist known (and open) examples of such a correctly designed
system?
... "libXYZ version 1.x" is really "libA version x",
while "libXYZ version 2.x" is really "libB version x". Clearly
libA and libB are entirely different, and libB is not a *replacement*
for libA.

This is really a solution... but i think it's not enough. If i'm not in
a mistake, you propose that mayor versions doesn't exist and a module
evolution that serves a new interface implies the creation of a new
module (with a new name).
Eventually, if nothing remains that uses libA anymore
-- because all the applications have been converted to use libB --
you can remove libA, but not until then.

Very clean. The system could remove the server when the last client is
uninstalled. But only if we agree that mayor versions haven't sense
... The reason marketing does
not like this approach is that selling "completely different product
libB" is much harder than selling "new, improved version of old
product", even though it is really exactly the same task.

I think there are other reasons, i'm going to look for them
 
C

Chris Torek

does exist known (and open) examples of such a correctly designed
system?

MacOS X, BSD ... well, I might say "almost every non-Microsoft
system" but there are a lot of non-Microsoft systems about which
I know too little. See <http://developer.apple.com/documentation/
MacOSX/Conceptual/BPFrameworks/Concepts/VersionInformation.html>
and said:
This is really a solution... but i think it's not enough. If i'm not in
a mistake, you propose that mayor versions doesn't exist and a module
evolution that serves a new interface implies the creation of a new
module (with a new name).

Well, as I said, "major version" numbers are always going to exist
for "warm fuzzy" reasons.
 
I

Ian Collins

Richard said:
Dynamic linking has its advantages, but it also has a great many
disadvantages. You have already identified one of them. Another is that it
becomes too easy to introduce fresh bugs into a previously working program.

How so? The program can carry on using the library it was built against.
Unfortunately, on some OSs you don't have much choice but to use dynamic
linking for at least some aspects of the program (e.g. Windows system calls
almost invariably resolve to a DLL call, which is a big shame), but you can
minimise the problems by using static linking as much as possible.
At least one OS I use (Solaris) has deprecated static linking for all
system libraries. It's way easier to fix a library bug with a patch
than it is to fix every application on the system that statically links it.
 
R

Richard Heathfield

Ian Collins said:
How so? The program can carry on using the library it was built against.

Program X uses DLL Y. DLL Y is "improved", and a bug is introduced. New
version of DLL Y, with same name as before, is installed on system. Program
X now uses buggy version of DLL Y. Program X is now buggy.

Yes, you can avoid this if you're careful. No, not everyone is careful.

And it might not even be a "bug" - it might just be a change in
functionality that breaks program X. You can find some very relevant war
stories at http://www.heise.de/ct/english/99/01/070/
At least one OS I use (Solaris) has deprecated static linking for all
system libraries. It's way easier to fix a library bug with a patch
than it is to fix every application on the system that statically links
it.

That's fine if the system is well-managed. Indeed, it is the preferred
strategy not only in pizza parlours but also in dinosaur pens. But on
Windows, it's a recipe for disaster.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top