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.25 20:49 "Re: C++ tiff library", by John M Davison

>C++ 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).

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.

There are so many fundamental areas of the language that are not commonly implemented (e.g. namespaces, subtle template details, the "bool" type, exception handling, run-time dynamic type casting) that it would be extremely difficult to produce a libtiff++ that would be immediately useful yet avoid being cumbersome and archaic three or four years down the road. The "stable subset" of C++ is small and weak enough at this time that, in my opinion, it is a far better idea to custom-write your own C++ interface to libtiff than to prematurely write a libtiff++ that will neither work on all machines nor take full advantage of C++. (In particular, I wouldn't want to use a libtiff++ interface that didn't make extensive use of, at the very least, the "try/catch/throw" and "namespace" facilities.)

The problem of irregular growth is already bad enough in C++ and TIFF. (Consider the inconsistency of declaring automatic objects within "for" headers and "if/else" statements, having two different error-handling schemes for the ios hierarchy, etc. Some of these problems are young enough to patch up without upsetting the C++ community; sadly, many of them are not.) Let's not compound the problem; until the standard comes out, let's hold off on libtiff++.

My $0.02 worth,

--
John Davison
Electronic Mail: davisonj@ecn.purdue.edu
WWW Home Page: <http://en.ecn.purdue.edu:20002/~davisonj/HomePage.html>