473,322 Members | 1,538 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

c code reusability

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

Aug 29 '06 #1
47 3055

mister catering wrote:
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.

Aug 29 '06 #2
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Aug 29 '06 #3
Richard Heathfield <in*****@invalid.invalidwrites:
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.
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...
--
Ben Pfaff
email: bl*@cs.stanford.edu
web: http://benpfaff.org
Aug 30 '06 #4
Ben Pfaff said:
Richard Heathfield <in*****@invalid.invalidwrites:
>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.

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. :-)
>This is even easier than rocket science.

Famous last words...
I chose them very carefully.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Aug 30 '06 #5
Ben Pfaff wrote:
Richard Heathfield <in*****@invalid.invalidwrites:

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


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...
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.
================================================== ===========
Aug 30 '06 #6
Richard Heathfield <in*****@invalid.invalidwrites:
Ben Pfaff said:
>Richard Heathfield <in*****@invalid.invalidwrites:
>>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.

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.
--
"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery
Aug 30 '06 #7
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.

--

Frederick Gotham
Aug 30 '06 #8

Richard Heathfield wrote:
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.
--
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?

Aug 31 '06 #9
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Aug 31 '06 #10

In article <Pf********************@bt.com>, Richard Heathfield <in*****@invalid.invalidwrites:
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 mi************@microfocus.com

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_
Aug 31 '06 #11
Michael Wojcik said:
>
In article <Pf********************@bt.com>, Richard Heathfield
<in*****@invalid.invalidwrites:
<snip>
>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.
And your point?
>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.
Not so. Just fix the bug and ship the executable, which is no harder than
fixing the bug and shipping the DLL.
>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.
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Aug 31 '06 #12
Richard Heathfield wrote:
Michael Wojcik said:
>>>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.


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.
Aug 31 '06 #13
jacob navia said:
Richard Heathfield wrote:
>Michael Wojcik said:
>>>>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.


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

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Aug 31 '06 #14

Michael Wojcik ha escrito:
In article <Pf********************@bt.com>, Richard Heathfield <in*****@invalid.invalidwrites:
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?

Aug 31 '06 #15
In article <Pf********************@bt.com>
Richard Heathfield <in*****@invalid.invalidwrote:
>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.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Aug 31 '06 #16
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

Aug 31 '06 #17
In article <ed*********@news1.newsguy.comI wrote:
>... 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.
... 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).
In article <11*********************@m73g2000cwd.googlegroups. com>
mister catering <hi****@hotmail.comwrote:
>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 <http://www.iecc.com/linker/linker10.html>.
>... "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).
Well, as I said, "major version" numbers are always going to exist
for "warm fuzzy" reasons.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Aug 31 '06 #18
Richard Heathfield wrote:
>
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.

--
Ian Collins.
Aug 31 '06 #19
Ian Collins said:
Richard Heathfield wrote:
>>
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.
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/
>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.
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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Aug 31 '06 #20
Richard Heathfield wrote:
Ian Collins said:

>>Richard Heathfield wrote:
>>>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.


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/
Ah, we are talking windows, I was thinking real shared libraries :)
>
>>>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.


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.
I thought they added the appropriate 70s technology to fix DLL hell?

--
Ian Collins.
Aug 31 '06 #21
Ian Collins said:
Richard Heathfield wrote:
>>
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.
I thought they added the appropriate 70s technology to fix DLL hell?
That's fine if the system is well-managed... :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Aug 31 '06 #22
Michael Wojcik wrote:
In article <Pf********************@bt.com>, Richard Heathfield <in*****@invalid.invalidwrites:
>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.
I'm not sure that's so sensible. I've seen multiple instances of this
approach and they invariably blew up. Buggy old code that (accidentally or
otherwise) uses "do not use" parameters, functions that suddenly need a
pointer to a structure with an arbitrary additional amount of parameters,
structures with version or size fields (with potential for memory
corruption), functions that run out of flags and need to arbitrarily be
split up anyway, type overloading of reserved parameters (this one is
particularly nasty and a guarantee for maintenance headaches), mass
hysteria, rivers running red.

Forward compatibility is a very cuspy thing to have -- for things like file
formats. For library functions, it's not half as hot. Having to export a new
function may be inconvenient ("Oh, however shall we name it?" "What, surely
we're not up to twiddle_foo_bit5 already?") but trying to shove the old and
the new through the same interface has far more potential for inconvenience.

A library should provide hooks for its applications, not its internals,
which is basically what reserved parameters are.

S.
Aug 31 '06 #23
Chris Torek <no****@torek.netwrote:
Richard Heathfield <in*****@invalid.invalidwrote:
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).
It would indeed be nice if all dynamically linked libraries worked that
way. Unfortunately, IME, not all do.

Richard
Sep 1 '06 #24
Well... there's a lot of material. I think we may stop and look at our
discussion (i think is more a contruction than a discussion).

The numbers in brackets correspond to the related message order number
(by date)

The original question was about c language... is or not enough the
language "as is" for programming fully reusable code?

We begin having a discussion about versioning. I said that it would be
desirable to be backward compatible (not forever) to allow gradual
migration. I think all we agree in this point. Chris Torek (16) and
Richard Heathfield (10) propossed two ways to do it with the c language
as is:

1.- Use static linking as much as possible (Richard)
2.- Use a diferent module for each mayor version change (Chris)

Michael Wojcik (11) propossed another way (the thirth) that implies a
programming discipline: Keep new functionality separate by means of new
function and variable names.

The three options are good solutions in my view but all of them, also
in my view, have problems that, if possible, must be avoided:

1.- As Jacob Navia (13) said clients need to relink with a new version
(mayor or minor) of a static library and this is not always possible
since it supposes a toolset that may not be available at cilent's site.
2.- To mantain a unique module name across mayor versions have
advantages. A new interface implementation can use code that is part of
the implementation of the "previous" interface. Furthermore, is very
easy to keep track with a "one file" component. You only need to know
the last change's date, inspect the metadata and decide if you are
interested in his new interfaces/implementations
3.- As i said (15) to have more than one name for the same semantics is
not desirable from the client's point of view. Furthermore, this
solution opens new questions: how many versions are you going to
mantain? and, if the answar is not "endless"... how to establish the
client dependencies?

To be continued...

Sep 1 '06 #25
Well... there's a lot of material. I think we may stop and look at our
discussion (i think is more a contruction than a discussion).

The numbers in brackets correspond to the related message order number
(by date)

The original question was about c language... is or not enough the
language "as is" for programming fully reusable code?

We begin having a discussion about versioning. I said that it would be
desirable to be backward compatible (not forever) to allow gradual
migration. I think all we agree in this point. Chris Torek (16) and
Richard Heathfield (10) propossed two ways to do it with the c language
as is:

1.- Use static linking as much as possible (Richard)
2.- Use a diferent module for each mayor version change (Chris)

Michael Wojcik (11) propossed another way (the thirth) that implies a
programming discipline: Keep new functionality separate by means of new
function and variable names.

The three options are good solutions in my view but all of them, also
in my view, have problems that, if possible, must be avoided:

1.- As Jacob Navia (13) said clients need to relink with a new version
(mayor or minor) of a static library and this is not always possible
since it supposes a toolset that may not be available at cilent's site.
2.- To mantain a unique module name across mayor versions have
advantages. A new interface implementation can use code that is part of
the implementation of the "previous" interface. Furthermore, is very
easy to keep track with a "one file" component. You only need to know
the last change's date, inspect the metadata and decide if you are
interested in his new interfaces/implementations
3.- As i said (15) to have more than one name for the same semantics is
not desirable from the client's point of view. Furthermore, this
solution opens new questions: how many versions are you going to
mantain? and, if the answar is not "endless"... how to establish the
client dependencies?

To be continued...

Sep 1 '06 #26
mister catering said:

<snip>
1.- As Jacob Navia (13) said clients need to relink with a new version
(mayor or minor) of a static library and this is not always possible
since it supposes a toolset that may not be available at cilent's site.
As I explained earlier, typically an application vendor would do the linking
back at base, and ship the resulting executable rather than the static
library. This is no more disadvantageous than shipping a new DLL. In each
case:

* one file must be shipped
* the customer must stop running his program
* the file must be copied to the system by the user
* the program must be re-started

So it makes no odds either way from that perspective.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 1 '06 #27

"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:kq********************@bt.com...
Ian Collins said:
>Richard Heathfield wrote:
>>>
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.
I thought they added the appropriate 70s technology to fix DLL hell?

That's fine if the system is well-managed... :-)
That sort of thing caught me out yesteday.
I knocked up a program to demonstrate a concept. The function took streams
as parameters to I simply called tmpfile() and set them up. Worked fine on
my desktop. Wored fine on a mate's laptop. Took it in, and of course the
university computers won't give write permission to temporary files, so the
thign fell over.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.
Sep 1 '06 #28

In article <Rc********************@bt.com>, Richard Heathfield <in*****@invalid.invalidwrites:
Michael Wojcik said:
<in*****@invalid.invalidwrites:
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.

And your point?
My point is that a good programmer should not refuse to use a
perfectly useful OS facility on the grounds that poor programmers
misuse that facility. Dynamic linking is not somehow contaminated by
others' misuse of it. Idiots should avoid it, but then they should
avoid creating programs for others' consumption at all. There is no
need for non-idiots to avoid it.
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.

Not so. Just fix the bug and ship the executable, which is no harder than
fixing the bug and shipping the DLL.
I am tempted to quote Dan Pop.

If a library is used by only one executable, why make it a library?
If it is used by more than one executable, then a fix to the library
requires shipping fixed versions of all executables, if it's
statically linked.
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.
This argument is common (indeed, nearly universal) among the opponents
of dynamic linking, but it is entirely specious. On a typical modern
general-purpose OS, replacing all the dynamically-linked code with
statically-linked code would present a resource cost far in excess of
the "relative cheapness" of disk space and memory.

On one machine here in front of me, running Windows XP Pro, I
currently have 68 userspace processes running. 2192 DLLs are loaded
by them, from 358 distinct images, so on average an image is reused 6
times. The Windows loader isn't particularly smart, and is unable to
share an in- memory image if it's relocated; but I have only 58
relocations among those 2192, so the relocation rate is less than 3%.
The average size of a loaded DLL is 558 KB. So if we assume an even
distribution[1], the memory cost for DLLs on this system right now is
something like 358 * 1.03 * 558 KB = 200 MB. If they were statically
linked instead, the cost would be something like 2192 * 558 KB = 1194
MB, or about six times as much. I don't care to buy six times as
much RAM as I currently have installed, thank you very much. And the
disk space cost is worse.

There may be good arguments against dynamic linking, but I haven't
heard any yet from the proponents of static linking. I argued this
in the letters column of DDJ some years ago, and I've argued it since
on Usenet, and all I ever hear from the anti-dynamic camp is
"versioning is hard!" and "many dynamic libraries are bad!". The
latter is true, and the former is debatable; but they say nothing
about dynamic linking as a technology. Using them as an excuse to
reject dynamic linking is to succumb to guilt by association.
Ironically, it's the same logic that motivates most tirades against C
itself.
[1] That assumption is obviously unwarranted, but the point of this
simplistic analysis is that even a back-of-the-envelope estimate
suggests the "cheap memory" argument doesn't hold, which puts the
burden of more sophisticated analysis on those who advance such an
argument.

--
Michael Wojcik mi************@microfocus.com

However, we maintain that our mission is more than creating high-tech
amusement--rather, we must endeavor to provide high-tech, high-touch
entertainment with an emphasis on enkindling human warmth.
-- "The Ultimate in Entertainment", from the president of video game
producer Namco
Sep 3 '06 #29

In article <11**********************@h48g2000cwc.googlegroups .com>, "mister catering" <hi****@hotmail.comwrites:
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...
You can, but that would be stupid. If they're *new functions*, they
have new names, which are not used by any previous users of the
library. If they're new versions of existing functions, then they
should be backward-compatible. There are a number of ways to achieve
such backward compatibility; some of them involve a bit of forethought,
but they are not unique in that respect, in the realm of programming.
by this way you are backward compatible and the
problem proposed is solved. But i think there's a price to avoid
What's that? A programming technique that is a tradeoff?
Remarkable!
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.
No you don't. I don't know where you got this idea.
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'm not entirely sure what this sentence is supposed to mean, but if
it's my library, then the version 2.0 "rotate" will be backward-
compatible with the version 1.0 "rotate", unless there are
extraordinary and compelling reasons to remove the 1.0 "rotate".
That would be a very rare case; I can't immediately think of any
justification for making such a change.
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".
This naming convention is a straw man of your own invention.
do you think it would be desirable to preserve the operation names
(when necessary) across versions?
First, an aside: C doesn't have "operation names". It has operators,
which are predefined by the language and not affected by library
versions, and it has function names. Function names should be
descriptive, of course, and what they describe should refer in some
fashion to the operation they perform, but that does not mean that
functions should be named solely for the operation they perform (what
is "rotate" in this context anyway?).

Second, I don't believe you understood my description of the library-
versioning process. When a new version of a library is released, it
should be backward compatible with the previous version; that means
maintaining syntax and (aside from corrections) semantics of the
previous version, for all the functions supplied by the previous
version. Some of those functions may have a larger domain in the the
new release - for example, "reserved" parameters may now have useful
values. And there may be new functions. Neither of these things will
affect correctly-written programs that use the documented interface
of the previous version.

Correctly-written programs written to the documented interface of the
new version may use the old version's functions, if those suit its
needs, or they may use the new functions.

Really, I fail to see what's so difficult about this concept.

--
Michael Wojcik mi************@microfocus.com

There are many definitions of what art is, but what I am convinced art is not
is self-expression. If I have an experience, it is not important because it
is mine. It is important because it's worth writing about for other people,
worth sharing with other people. That is what gives it validity. (Auden)
Sep 3 '06 #30

In article <44**********************@news.xs4all.nl>, Skarmander <in*****@dontmailme.comwrites:
Michael Wojcik wrote:

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.
I'm not sure that's so sensible.
I wrote a fairly lengthy response to this, then decided I wasn't
sure what you're talking about. What's the antecedent of "that"?
Are you complaining about dynamic-library backward compatibility, or
about the techniques I mention for forward-compatibility?

--
Michael Wojcik mi************@microfocus.com

Some there are, brave, high-souled fellows, who could borrow the world to
play at ball, and never feel the responsibility, whereas others are uneasy
and not themselves with a single shilling that does not belong to them.
-- Arthur Ransome
Sep 3 '06 #31
Michael Wojcik said:
>
In article <Rc********************@bt.com>, Richard Heathfield
<in*****@invalid.invalidwrites:
>Michael Wojcik said:
<in*****@invalid.invalidwrites:
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.

And your point?

My point is that a good programmer should not refuse to use a
perfectly useful OS facility on the grounds that poor programmers
misuse that facility.
Certainly true, and indeed there are certain environments where DLLs are
customarily handled very well indeed - mainframe environments, for example.
>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.

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

I am tempted to quote Dan Pop.

If a library is used by only one executable, why make it a library?
Planning ahead. :-)
If it is used by more than one executable, then a fix to the library
requires shipping fixed versions of all executables, if it's
statically linked.
Indeed. In other words, each executable carries all its code with it, so
that it can't be messed up just by someone using the "wrong" DLL with it
(whether it's "wrong" because it's buggy, or because it's an old version,
or because it's a too-new version, or whatever). This can be seen as an
advantage or a disadvantage - it depends on your point of view.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 3 '06 #32
Richard Heathfield wrote:
Michael Wojcik said:
>In article <Rc********************@bt.com>, Richard Heathfield
<in*****@invalid.invalidwrites:
>>Michael Wojcik said:
<in*****@invalid.invalidwrites:
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.
And your point?
My point is that a good programmer should not refuse to use a
perfectly useful OS facility on the grounds that poor programmers
misuse that facility.

Certainly true, and indeed there are certain environments where DLLs are
customarily handled very well indeed - mainframe environments, for example.
>>>>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.
Not so. Just fix the bug and ship the executable, which is no harder than
fixing the bug and shipping the DLL.
I am tempted to quote Dan Pop.

If a library is used by only one executable, why make it a library?

Planning ahead. :-)
>If it is used by more than one executable, then a fix to the library
requires shipping fixed versions of all executables, if it's
statically linked.

Indeed. In other words, each executable carries all its code with it, so
that it can't be messed up just by someone using the "wrong" DLL with it
(whether it's "wrong" because it's buggy, or because it's an old version,
or because it's a too-new version, or whatever). This can be seen as an
advantage or a disadvantage - it depends on your point of view.
If I understand you Richard, I agree completely. Shared libraries and
especially Dynamically Linked Libraries (DLL's) leave me cold.
Frightened actually.

On my particular Windows XP install there are 2,228 dll files in the
system32 directory (folder ?).

Twenty or more of them have been written or refreshed in the last 60
days. I didn't do it! I wouldn't trust a .dll as far as I could throw it.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Sep 4 '06 #33
... If they're new versions of existing functions, then they
should be backward-compatible. There are a number of ways to achieve
such backward compatibility; some of them involve a bit of forethought,
but they are not unique in that respect, in the realm of programming.
I think is possible (and frequent) to have a new version of a existing
function with a
new parameter in his signature. what way you propose to achieve such
change mantaining
backward compatibility?

Sep 4 '06 #34
1.- As Jacob Navia (13) said clients need to relink with a new version
(mayor or minor) of a static library and this is not always possible
since it supposes a toolset that may not be available at cilent's site.

As I explained earlier, typically an application vendor would do the linking
back at base, and ship the resulting executable rather than the static
library.
I think this solution limits reusability because the only clients you
can have are application vendor (not final users). Think your library
is a grammar checker and the application is a word processor... they
may be different components (from the user's point of view).
Application vendor uses your library but only if the user decides to
pay the grammar checker's price.

Sep 4 '06 #35
"mister catering" <hi****@hotmail.comwrote in message
news:11**********************@i3g2000cwc.googlegro ups.com...
1.- As Jacob Navia (13) said clients need to relink with a new version
(mayor or minor) of a static library and this is not always possible
since it supposes a toolset that may not be available at cilent's
site.

As I explained earlier, typically an application vendor would do the
linking
back at base, and ship the resulting executable rather than the static
library.
Who wrote the above lines? Your post references straight back to the OP, and
I'm not searching the entire thread to find these lines.

Please do not omit attribution lines in future. In addition, if your post
clearly follows-on from one other post, make sure it references that post.

<snip rest of post>

Philip

Sep 4 '06 #36
Michael Wojcik wrote:
In article <44**********************@news.xs4all.nl>, Skarmander <in*****@dontmailme.comwrites:
>Michael Wojcik wrote:
>>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.
I'm not sure that's so sensible.

I wrote a fairly lengthy response to this, then decided I wasn't
sure what you're talking about. What's the antecedent of "that"?
Are you complaining about dynamic-library backward compatibility, or
about the techniques I mention for forward-compatibility?
Yes, I'm complaining about backward compatibility. I'm very much against it;
out with the old, in with the new.

But seriously, "that" referred to "[designing] libraries with a bit more
sense [...] thanks to reserved parameters, behavior flags, and so forth"; in
other words, forward compatibility on the function level. This technique is
rather brittle, and solves a problem (naming) that ought to have a cleaner
solution than changing around the semantics of existing code.

From an executable code point of view, the name of a function is its least
relevant part, and the reserved parameter technique makes no sense. Of
course, as programmers we know that how things are named makes a great deal
of difference, and it's not entirely reasonable to suggest everyone use
'defenestrate_foo4' and forget about the three deprecated predecessors, but
still.

S.
Sep 4 '06 #37
mister catering wrote:
>
>... If they're new versions of existing functions, then they
should be backward-compatible. There are a number of ways to
achieve such backward compatibility; some of them involve a bit
of forethought, but they are not unique in that respect, in the
realm of programming.

I think is possible (and frequent) to have a new version of a
existing function with a new parameter in his signature. what
way you propose to achieve such change mantaining backward
compatibility?
No, it is not possible. You create a new function with a different
name.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
Sep 4 '06 #38
CBFalconer a écrit :
mister catering wrote:
>>>... If they're new versions of existing functions, then they
should be backward-compatible. There are a number of ways to
achieve such backward compatibility; some of them involve a bit
of forethought, but they are not unique in that respect, in the
realm of programming.

I think is possible (and frequent) to have a new version of a
existing function with a new parameter in his signature. what
way you propose to achieve such change mantaining backward
compatibility?


No, it is not possible. You create a new function with a different
name.
Unless you change ALL signatures to:

int myFn(int NbOfParameters,...);
// ... reserved for future use :-)

But that would be quite an overkill :-)
Sep 4 '06 #39
mister catering said:
1.- As Jacob Navia (13) said clients need to relink with a new version
(mayor or minor) of a static library and this is not always possible
since it supposes a toolset that may not be available at cilent's site.

As I explained earlier, typically an application vendor would do the
linking back at base, and ship the resulting executable rather than the
static library.

I think this solution limits reusability
All solutions limit reusability.
because the only clients you
can have are application vendor (not final users).
The responsibility for an program's functionality lies with the writer(s) of
the program. They must decide whether or not to incorporate the changed
library into their program. It is not the library writer's decision to
make.
Think your library
is a grammar checker and the application is a word processor... they
may be different components (from the user's point of view).
Typical users think of "the computer" as being a single component, alas.
More clueful users do exist, but they are relatively rare.
Application vendor uses your library but only if the user decides to
pay the grammar checker's price.
That's the user's decision to make.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Sep 4 '06 #40

In article <11**********************@i3g2000cwc.googlegroups. com>, "mister catering" <hi****@hotmail.comwrites:

Please use proper attribution lines (like the one above). I wrote the
twice-quoted text below.
... If they're new versions of existing functions, then they
should be backward-compatible. There are a number of ways to achieve
such backward compatibility; some of them involve a bit of forethought,
but they are not unique in that respect, in the realm of programming.

I think is possible (and frequent) to have a new version of a existing
function with a new parameter in his signature.
An aside: the C language specification does not use the term
"signature", and I would recommend avoiding it when discussing C,
as it has a specific meaning in some languages (particularly ones
that support overloading) that is not applicable to C.
what way you propose to achieve such change mantaining
backward compatibility?
It depends on the function in question and the design of the library
interface, but in general I create a new function with one or more
additional parameters, and refactor the old function to call the
new function, with appropriate values for the new parameter(s) to
indicate that the old behavior should be used.

For example, say the first version of the library includes a
factory-pattern function for an ADT used by the library. The
interface might be something like:

struct XxxThing;
struct XxxThing *XxxCreateThing(void);

In the next version, I find it useful to have an enhanced factory
that performs some optional processing. The new interface is:

struct XxxThing;
enum XxxCTOption
{
XxxOPT_NONE = 0,
XxxOPT_SOMETHING,
XxxOPT_ANOTHER
};
struct XxxThing *XxxCreateThing(void);
struct XxxThing *XxxCreateThingEx(enum XxxCTOption Opt);

and in the implementation:

struct XxxThing *XxxCreateThing(void)
{
return XxxCreateThingEx(XxxOPT_NONE);
}

That's certainly not ideal - for one thing, it'd be better if the
name "XxxCreateThingEx" were more descriptive, but since this is
hypothetical I don't know what a "Thing" is or what the options
actually do - but it's a start. It'd be better if the original
XxxCreateThing had taken, say, a "void *Reserved" parameter which
could be used for other purposes in future versions.

--
Michael Wojcik mi************@microfocus.com

Maybe, but it can't compete with _SNA Formats_ for intricate plot
twists. "This format is used only when byte 5, bit 1 is set to 1
(i.e., when generalized PIU trace data is included)" - brilliant!
Sep 5 '06 #41

In article <44**********************@news.xs4all.nl>, Skarmander <in*****@dontmailme.comwrites:
Michael Wojcik wrote:
In article <44**********************@news.xs4all.nl>, Skarmander <in*****@dontmailme.comwrites:
Michael Wojcik wrote:
... 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.

I'm not sure that's so sensible.
I wrote a fairly lengthy response to this, then decided I wasn't
sure what you're talking about. What's the antecedent of "that"?

But seriously, "that" referred to "[designing] libraries with a bit more
sense [...] thanks to reserved parameters, behavior flags, and so forth"; in
other words, forward compatibility on the function level. This technique is
rather brittle, and solves a problem (naming) that ought to have a cleaner
solution than changing around the semantics of existing code.
Perhaps it's been brittle in your experience. I've seen it used to
good effect in dozens of projects, and when used properly it does not
"chang[e] around the semantics of existing code". Indeed, that's
rather the point.

--
Michael Wojcik mi************@microfocus.com

Unfortunately, as a software professional, tradition requires me to spend New
Years Eve drinking alone, playing video games and sobbing uncontrollably.
-- Peter Johnson
Sep 5 '06 #42

CBFalconer wrote:
mister catering wrote:
... If they're new versions of existing functions, then they
should be backward-compatible. There are a number of ways to
achieve such backward compatibility; some of them involve a bit
of forethought, but they are not unique in that respect, in the
realm of programming.
I think is possible (and frequent) to have a new version of a
existing function with a new parameter in his signature. what
way you propose to achieve such change mantaining backward
compatibility?

No, it is not possible. You create a new function with a different
name.
>From the client's point is an evolution, not a new function. I think
the client will prefer to use the same name (of course, it won't be the
same implementation) because he is no more interested in the old
function. do you agree?

Another question is how to do it

Sep 5 '06 #43
Michael Wojcik wrote:
In article <11**********************@i3g2000cwc.googlegroups. com>, "mister catering" <hi****@hotmail.comwrites:

Please use proper attribution lines (like the one above). I wrote the
twice-quoted text below.
>
... If they're new versions of existing functions, then they
should be backward-compatible. There are a number of ways to achieve
such backward compatibility; some of them involve a bit of forethought,
but they are not unique in that respect, in the realm of programming.
I think is possible (and frequent) to have a new version of a existing
function with a new parameter in his signature.

An aside: the C language specification does not use the term
"signature", and I would recommend avoiding it when discussing C,
as it has a specific meaning in some languages (particularly ones
that support overloading) that is not applicable to C.
what way you propose to achieve such change mantaining
backward compatibility?

It depends on the function in question and the design of the library
interface, but in general I create a new function with one or more
additional parameters, and refactor the old function to call the
new function, with appropriate values for the new parameter(s) to
indicate that the old behavior should be used.

For example, say the first version of the library includes a
factory-pattern function for an ADT used by the library. The
interface might be something like:

struct XxxThing;
struct XxxThing *XxxCreateThing(void);

In the next version, I find it useful to have an enhanced factory
that performs some optional processing. The new interface is:

struct XxxThing;
enum XxxCTOption
{
XxxOPT_NONE = 0,
XxxOPT_SOMETHING,
XxxOPT_ANOTHER
};
struct XxxThing *XxxCreateThing(void);
struct XxxThing *XxxCreateThingEx(enum XxxCTOption Opt);

and in the implementation:

struct XxxThing *XxxCreateThing(void)
{
return XxxCreateThingEx(XxxOPT_NONE);
}

That's certainly not ideal - for one thing, it'd be better if the
name "XxxCreateThingEx" were more descriptive, but since this is
hypothetical I don't know what a "Thing" is or what the options
actually do - but it's a start. It'd be better if the original
XxxCreateThing had taken, say, a "void *Reserved" parameter which
could be used for other purposes in future versions.
I think it'd be better to use a generic "void* import(char* function,
short version);" to get the desired function version (the returned
valud would need to be casted to the apropiate function pointer). OK,
is less efficient but think most times libraries "export" several
functions. One only import could get all the functions involved in a
new library version.

what do you think about this solution?

Sep 5 '06 #44

In article <11********************@h48g2000cwc.googlegroups.c om>, "mister catering" <hi****@hotmail.comwrites:
>
I think it'd be better to use a generic "void* import(char* function,
short version);" to get the desired function version (the returned
valud would need to be casted to the apropiate function pointer).
The result of casting an object pointer to a function pointer type is
undefined. There is no generic function-pointer type; pointers to
functions with different parameter types are incompatible. So this
approach is not portable (though it will work on many implementations).

In any event, I don't care for it. I've yet to run across a case where
I had to create a new function similar to an existing one, and did not
want to give it a new name.

--
Michael Wojcik mi************@microfocus.com

Be sure to push the button of the bottom, and push the button of the
settlement page indicated next only once, there is fear of the bottom
rhinoceros multiplex lesson money. -- Sukebe Net
Sep 6 '06 #45
mw*****@newsguy.com (Michael Wojcik) writes:
In article <11********************@h48g2000cwc.googlegroups.c om>, "mister catering" <hi****@hotmail.comwrites:
>>
I think it'd be better to use a generic "void* import(char* function,
short version);" to get the desired function version (the returned
valud would need to be casted to the apropiate function pointer).

The result of casting an object pointer to a function pointer type is
undefined. There is no generic function-pointer type; pointers to
functions with different parameter types are incompatible. So this
approach is not portable (though it will work on many implementations).
But you can freely cast any function pointer to any other
function pointer type, so any function pointer type may be used
as a "generic" function pointer type. (You do need to invoke a
function through a compatible type.)
--
"Some people *are* arrogant, and others read the FAQ."
--Chris Dollin
Sep 6 '06 #46

In article <87************@benpfaff.org>, Ben Pfaff <bl*@cs.stanford.eduwrites:
mw*****@newsguy.com (Michael Wojcik) writes:
In article <11********************@h48g2000cwc.googlegroups.c om>, "mister catering" <hi****@hotmail.comwrites:
>
I think it'd be better to use a generic "void* import(char* function,
short version);" to get the desired function version (the returned
valud would need to be casted to the apropiate function pointer).
The result of casting an object pointer to a function pointer type is
undefined. There is no generic function-pointer type; pointers to
functions with different parameter types are incompatible. So this
approach is not portable (though it will work on many implementations).

But you can freely cast any function pointer to any other
function pointer type, so any function pointer type may be used
as a "generic" function pointer type. (You do need to invoke a
function through a compatible type.)
Argh. Right - I should have checked the standard before posting
that. I was thinking that the result of casting function pointers
wasn't defined, but per 9899-1999 6.3.2.3 #8 it is, just as you say.

So ignore my "not portable" comment above.

--
Michael Wojcik mi************@microfocus.com

Advertising Copy in a Second Language Dept.:
Tapestry of the encounting and the farewell, the birth and the death.
You can hear the human being's song running through the 100 years.
-- Squaresoft
Sep 7 '06 #47
On 3 Sep 2006 16:35:24 GMT, mw*****@newsguy.com (Michael Wojcik)
wrote:
<snip: dynamic-linked libraries can be Good or at least OK>
This argument is common (indeed, nearly universal) among the opponents
of dynamic linking, but it is entirely specious. On a typical modern
general-purpose OS, replacing all the dynamically-linked code with
statically-linked code would present a resource cost far in excess of
the "relative cheapness" of disk space and memory.

On one machine here in front of me, running Windows XP Pro, I
currently have 68 userspace processes running. 2192 DLLs are loaded
by them, from 358 distinct images, so on average an image is reused 6
times. The Windows loader isn't particularly smart, and is unable to
share an in- memory image if it's relocated; but I have only 58
relocations among those 2192, so the relocation rate is less than 3%.
The average size of a loaded DLL is 558 KB. So if we assume an even
distribution[1], the memory cost for DLLs on this system right now is
something like 358 * 1.03 * 558 KB = 200 MB. If they were statically
linked instead, the cost would be something like 2192 * 558 KB = 1194
MB, or about six times as much. I don't care to buy six times as
much RAM as I currently have installed, thank you very much. And the
disk space cost is worse.
Although (non-stupid) static linking only needs to include that
part(s) of a given library actually referenced by the given program,
which fraction would vary pretty widely but I would guess, totally off
the top of my head, might average something like 1/4 to 1/2 over a
largish population of programs like this. Plus on some targets, though
not I think x86, runtime-relocatable code aka PIC is larger though not
by anywhere near a factor of 2 and/or slower.

FWIW, my XP Home system32 has 1374 .dll files totalling ~280MB,
although probably most of them are never used, and progra~1 has about
twice as much of stuff installed with particular programs that are
almost certainly never shared -- if used at all, which many of my
OEM-installed alleged goodies aren't. But I consider this to reflect
M$Win and its culture much more than the linking method.

- David.Thompson1 at worldnet.att.net
Sep 10 '06 #48

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

9
by: bigoxygen | last post by:
Hi. I'm using a 3 tier FrontController Design for my web application right now. The problem is that I'm finding to have to duplicate a lot of code for similar functions; for example, listing...
3
by: Erik De Keyser | last post by:
Hi group, I have a couple of projects with up to 8 forms. On most projects I write the code on each form with no modules. The last project I use 1 module and minimal code on each form , in fact...
3
by: popsovy | last post by:
Hi, This is a code reusability question. I want to include a function that sends an email message from my site. I want to include the code for the function only once and then be able to call this...
17
by: tshad | last post by:
Many (if not most) have said that code-behind is best if working in teams - which does seem logical. How do you deal with the flow of the work? I have someone who is good at designing, but...
29
by: John Rivers | last post by:
Hello, What good reason there is for not allowing methods in ASPX pages I can't imagine, but here is how to get around that limitation: (START) <body MS_POSITIONING="FlowLayout"> <form...
8
by: neilmcguigan | last post by:
I just wanted to list some reasons why I prefer inline code to code-behind. 1. you can fix some bugs more quickly. remote desktop into server, change the aspx file, and she's good to go. I'd say...
42
by: gt8887b | last post by:
Hello! In his recent newsletter embedded expert Jack Ganssle says that programming students, as well as professional developers should readh "great code" (hight quality/well-crafted code that...
0
by: Jerry Mcnealy | last post by:
There is an interesting article on java.net about SOA reusability, Shrinking the Lag between Business and IT: http://today.java.net/pub/a/today/2007/07/24/soa-reusability-shrinking-lag-time.html...
2
by: Jeff Dege | last post by:
I'm working with a group that's been doing C++ coding for quite a long time, now, and in that environment we've pretty much worked out development practices that serve us well. We've been doing...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.