AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

1994.10.21 15:50 "Problems catching write errors in tiff library (v3.3beta021)", by Ben Griffin
1994.10.21 03:20 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Richard Minner
1994.10.21 05:53 "Re: C++ tiff library", by Richard Minner
1994.10.21 23:15 "Re: C++ tiff library", by Yip Chi Lap
1994.10.21 14:38 "Re: C++ tiff library", by Richard Minner
1994.10.25 20:49 "Re: C++ tiff library", by John M Davison
1994.10.31 04:52 "Re: C++ tiff library", by Richard Minner
1994.10.21 17:12 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Dan McCoy
1994.10.21 18:36 "C++ tiff library", by Jim Arnold
1994.10.21 18:53 "Re: Problems catching write errors in tiff library (v3.3beta021)", by John Bradley
1994.10.21 19:16 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Sam Leffler
1994.10.21 19:13 "Re: Problems catching write errors in tiff library (v3.3beta021)", by Sam Leffler

1994.10.31 04:52 "Re: C++ tiff library", by Richard Minner

I would advise against any major attempt at C++-izing libtiff until at least 1996 or 1997. The C++ standard is slated to come out in mid-1996, and it is unlikely that any vendors will have stable C++ compilers out before early 1997.

Depending on your definition of "major" I can agree or disagree. As I reported before, a relatively simple C++ification tool about a week and is working swell. I agree that C++ is not quite ready for the masses, but very nice implementations are available at least on the two platforms I care about most for my work, and I expect others are in similar positions. I don't doubt that the demand for a libtiff++ will be quite a bit smaller than the demand for "C libtiff" for some time, but the libtiff++ demand may be large enough to warrant some sort of joint effort. As I mentioned before, if there is sufficient interest perhaps the ++ gang (all three of us :-) should break off a new list. We'll see.

You probably won't be surprised that my view of the state of C++ is more optimistic than yours, since we have adopted C++ as our Language of Choice. You are correct that some important new features are not yet available at all, and that availability of other features varies by vendor. I neglected to state clearly that the "stable subset" is not just a subset of the language itself but of platforms and implementations. This does make the question of "what is portable C++" quite messy. The picture has a shape something like this:

                        features
                  a b c d e f g h i j k
        p       1 x x x x x   x x x   x
        l       2 x x x x x x x   x x
        a       3 x x x x x x x x
        t       4 x x x x x x 
        f       5 x x x x 
        o       6 x x x
        r       7 x x x
        m       8 x x x
        s       9 x x

That is, the more features you want, the fewer platforms you have to choose from, and vice versa. For my project we have chosen to limit platforms in favor of a better feature set. Others may not be able to make that tradeoff. You may be right that it would be too difficult to reach consensus on what C++ subset to use for a shared libtiff++.

However, if one has faith that C++ will arrive in full one of these days, it can be quite sensible to get going with it now, even lacking things like namespaces and RTTI. (It's not a huge library.)

Anyway, thanks for the counter arguments, well said.

--
Richard Minner rtm@island.com
Island Graphics Corporation
Sacramento, California