![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Does anyone know of a book that describes good ways of getting bunches of
different types of software written in inadequate languages[*] to work together?
In other words, I have a bunch of code in C: A web browser, a graphical
toolkit, a video decoder, a XMPP stack, an RTSP stack, an HTTP stack, an XML
parser, etc etc etc. However, each of these things is in C or C++, so each
is using their own memory manager, their own set of defines for things like
eight-bit-unsigned-bytes, their own set of routines for unicode, their own
mechanisms for message catalogs, their own set of routines for logging,
their own set of routines for threading/event handling, etc etc etc.
What's a good way to take the video player that's interfaced into the web
browser and move it to a different web browser, when that video player has
grown tentacles into the web browser for things like receiving events,
typedefs, logging, etc etc?
Basically, I'd expect it looks something like Design Patterns, or Design
Anti-Patterns, only for various pieces of third-party code you need to make
work together.
[*] Obviously, if a language already comes with a good logging library,
unicode strings built in, classes and callback events and locking and
threading and such, you'll find few libraries in that language that have
incompatibilities there. Hence the term "inadequate".
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Does anyone know of a book that describes good ways of getting bunches of
> different types of software written in inadequate languages[*] to work together?
I don't really understand why such books would even exist.
If a program has not been designed to be reusable, then it isn't. End of
story. You could try to hack it to become more reusable, but good luck with
that. And patience.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> If a program has not been designed to be reusable, then it isn't.
Well, it is, of course, if it's just a library exposing an API. The problem
is the pile of things the program depends upon that aren't standardized, and
so each program wants something different there. I guess sort of the
language-level equivalent of DLL Hell.
If you have several different parser libraries, for example (say, XML, HTTP
headers, message catalogs) and they all depend on different implementations
of unicode strings, what's a good way of making it so you don't have to
convert between unicode string representations each time you move data from
the message catalog to an XML record sent over HTTP? That's the kind of
question I'm asking. Or even if it's just bunches of typedefs, considering
the C and C++ languages lack enough parsability or after-compile metadata to
make it easy to actually find the declarations and uses and do a global
replace on type names. (As in, try to correctly rename type "i8" to "int8"
everywhere in the code without manually inspecting each instance.)
Of course, the more powerful the language, the easier it is to do some sort
of translation between types there, up to the point where you have a
language that (gasp) already has unicode strings built in from day one. (Or
at least day N where N < the original authoring date of any code you want to
use.)
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Of course, the more powerful the language, the easier it is to do some sort
> of translation between types there, up to the point where you have a
> language that (gasp) already has unicode strings built in from day one.
You can hardly blame C (developed in 1972) and C++ (developed in 1979) for
not having native support for Unicode (first standardized in 1991).
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> You can hardly blame C (developed in 1972) and C++ (developed in 1979) for
> not having native support for Unicode (first standardized in 1991).
I have no idea why you think I'm blaming inanimate objects for anything at
all. It's an example. I'm sure in 20 years I'll be complaining that the
grammars for my speech recognition library and my natural language deduction
library aren't compatible.
If I asked how to get a program written before graphics displays were common
running on a modern UI, I'd get a whole raft of suggestions, everything from
using a terminal emulator to using a VM to ....
Yet if I mention that there's a lack of information published about solving
a common problem in computer programming, and I happen to mention that it's
affecting my *C* programming, suddenly I'm somehow insulting you or
something? You're upset that I'm programming in C and C++ and asking people
how they solve the sorts of problems I'm encountering? I'm sorry you don't
ever have that sort of problem, but if you haven't anything to add to the
conversation, why not just let it go?
But yes, now that you mention it, I *am* exactly blaming C, first developed
in 1972, for not having standard unicode support first standardized in 1991.
What or who else would I blame for that, if blame must be assigned? Indeed,
the fact that C predates applications where you need logging, unicode,
network protocol stacks, message catalogs, and even standard size integers
for talking to custom hardware is *exactly* the source of the problem I'm
trying to solve. Why wouldn't I blame C for that? I certainly can't blame
the inventors of C, and it's certainly the age of C that's the fault for it
missing many of the features people commonly use 30 years after its invention...
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New schrieb:
> I have no idea why you think I'm blaming inanimate objects for anything
> at all.
You know you've been spending too much time in the Aperture Science
Enrichment Center when... :-P
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka wrote:
> Darren New schrieb:
>> I have no idea why you think I'm blaming inanimate objects for
>> anything at all.
>
> You know you've been spending too much time in the Aperture Science
> Enrichment Center when... :-P
The Enrichment Center reminds you that the C programming language might
threaten to stab you and, in fact, can speak.
--
Tim Cook
http://empyrean.freesitespace.net
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Warp wrote:
> > You can hardly blame C (developed in 1972) and C++ (developed in 1979) for
> > not having native support for Unicode (first standardized in 1991).
> I have no idea why you think I'm blaming inanimate objects for anything at
> all.
I don't. It was just a figure of speech.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> If you have several different parser libraries, for example (say, XML,
> HTTP headers, message catalogs) and they all depend on different
> implementations of unicode strings, what's a good way of making it so
> you don't have to convert between unicode string representations each
> time you move data from the message catalog to an XML record sent over
> HTTP?
I don't know of any books that suggest solutions, but you might consider
writing your own set of bridge classes to go between the different
libraries.
That is, say you'd have a class DN_Unicode_String (or whatever you end
up calling it), you would define casting operations both from and to
every other unicode string type used.
Then, in your code, the only type you use would be the
DN_Unicode_String, and it would work automatically with all the other
libraries.
It's an ugly solution, and in the end it just increases the number of
types being used, but it would work.
...Chambers
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chambers wrote:
> I don't know of any books that suggest solutions, but you might consider
> writing your own set of bridge classes to go between the different
> libraries.
Yeah, I thought of that. Then you have the problem of wedging it between all
the other libraries, including those in C so you don't actually have
classes. Easier to just modify the libraries to use the same types.
I.e., I understand how to brute force it. I was just wondering if there was
something clever, along the lines of "Design Patterns", that would work at a
somewhat higher level than the level of problems that "Design Patterns"
tends to work at.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |