LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
October 1994
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
1994.10.21 05:53 "Re: C++ tiff library", by Richard Minner
>On another subject, there was some talk earlier about rewriting
>the tiff library in C++. Any progress on this? Want any help ?
To all those concerned about the possibility of libtiff-C being
_replaced_ by a libtiff++, it won't happen any time soon, if ever
(as Sam just noted). C++ may be growing, but the C community is huge
and well established. However, there is a rationale for a libtiff++
for some of us. I know that Sam has at least twice done a ++ification
of libtiff, but he said it wasn't worth the bother to him to keep
the C and C++ flavors in synch (or to maintain two separate libraries)
and the C flavor is by far the more used.
We here recently did a transmutation of libtiff to C++, because:
1. Our project is C++ based (not a trivial decision, incidentally)
2. We needed to make substantial changes to libtiff, not the
least of which involved writing multiple subfiles simultaneously
(a non-trivial change to libtiff).
3. We wanted a C++ API (we _like_ C++ :-)
It took one of our sharper engineers about a week to mutate the thing
and it works swell (it doesn't yet do _everything_ libtiff does, but
it does what we need). I have no doubt that it would have taken at
least as long to make our changes directly to libtiff in C. The
tradeoffs are now:
pro: We have a C++ interface that we consider easier
and safer to use.
The internals are easier to work on and extend
(for a C++ programmer).
con: We lose the direct benefit of further work on
libtiff. This is a potentially substantial
loss, but we believe we can port such work
fairly easily onto our libtiff++.
I don't want to start a religious war, but let me note that C++
is in fact a "more powerful" tool than C. That does not mean
"better" in any general sense, but it can be a better tool for
certain situations _if_ (BIG IF) used well. As with many things,
C++ requires a substantial investment to be effective -- it is
simply a larger language and much more complex and subtle than C.
It is also notably less stable than C, but there is a large stable
subset (part of the investment is learning what that subset is :-).
Lacking the investment C++ is probably a bad move -- I've heard
several horror stories along the lines or "more rope" (i.e. give
them enough rope and they'll hang themselves).
For many the investment is not appropriate or possible. But others
have decided to take the gamble and go with C++. We are doing things
in C++ that I personally wouldn't even attempt in C. (But maybe I'm
just not a good enough C programmer :-) We want tiff support in C++
for the same reasons we have adopted C++ in general. I expect there
are some others in the same situation, and we might like to explore
a public domain libtiff++ for our use. As noted above there is the
downside of fragmenting the vast pool of shared engineering between
the two efforts, but perhaps the pool is vast enough that such a split
would not be too great a loss.
We are not in a position to be primary maintainers of a public
domain libtiff++, but I believe we could contribute to such an
effort if there is interest. When I posted a note about a year
ago suggesting as much there was no (none, nada) response, but
maybe things have changed? If there is sufficient interest it
may be appropriate to set up a separate list.
--
Richard Minner rtm@island.com
Island Graphics Corporation
Sacramento, California