1994.10.21 15:50 "Problems catching write errors in tiff library (v3.3beta021)", by Ben Griffin

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