I
Ian Collins
Ah, we are talking windows, I was thinking real shared librariesRichard said:
I thought they added the appropriate 70s technology to fix DLL hell?
R
Richard Heathfield
Ian Collins said:
That's fine if the system is well-managed...
That's fine if the system is well-managed...
S
Skarmander
I'm not sure that's so sensible. I've seen multiple instances of thisMichael said:
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.
R
Richard Bos
Chris Torek said:
It would indeed be nice if all dynamically linked libraries worked that
way. Unfortunately, IME, not all do.
Richard
M
mister catering
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...
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...
M
mister catering
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...
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...
R
Richard Heathfield
mister catering said:
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>
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>
M
Malcolm
That sort of thing caught me out yesteday.Richard Heathfield said:Ian Collins said:
That's fine if the system is well-managed...
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.
M
Michael Wojcik
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.
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.
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 (e-mail address removed)
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
M
Michael Wojcik
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.
What's that? A programming technique that is a tradeoff?
Remarkable!
No you don't. I don't know where you got this idea.
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.
This naming convention is a straw man of your own invention.
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 (e-mail address removed)
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)
M
Michael Wojcik
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 (e-mail address removed)
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
R
Richard Heathfield
Michael Wojcik said:
Certainly true, and indeed there are certain environments where DLLs are
customarily handled very well indeed - mainframe environments, for example.
Planning ahead.
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>
Certainly true, and indeed there are certain environments where DLLs are
customarily handled very well indeed - mainframe environments, for example.
Planning ahead.
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>
J
Joe Wright
Richard said:Michael Wojcik said:
Certainly true, and indeed there are certain environments where DLLs are
customarily handled very well indeed - mainframe environments, for example.
Planning ahead.
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.
M
mister catering
... If they're new versions of existing functions, then they
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?
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?
M
mister catering
1.- As Jacob Navia (13) said clients need to relink with a new version
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.
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.
P
Philip Potter
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
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
S
Skarmander
Yes, I'm complaining about backward compatibility. I'm very much against it;Michael said:
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.
C
CBFalconer
mister said:
No, it is not possible. You create a new function with a different
name.
--
Some informative links:
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
J
jacob navia
CBFalconer a écrit :
Unless you change ALL signatures to:
int myFn(int NbOfParameters,...);
// ... reserved for future use
But that would be quite an overkill
Unless you change ALL signatures to:
int myFn(int NbOfParameters,...);
// ... reserved for future use
But that would be quite an overkill
R
Richard Heathfield
mister catering said:
All solutions limit reusability.
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.
Typical users think of "the computer" as being a single component, alas.
More clueful users do exist, but they are relatively rare.
That's the user's decision to make.
All solutions limit reusability.
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.
Typical users think of "the computer" as being a single component, alas.
More clueful users do exist, but they are relatively rare.
That's the user's decision to make.