Received: by cthulhu.engr.sgi.com (940816.SGI.8.6.9/911001.SGI)
	for tiff-list id NAA07841; Tue, 25 Oct 1994 13:49:34 -0700
Return-Path: <owner-tiff>
Received: from sgi.sgi.com by cthulhu.engr.sgi.com via ESMTP (940816.SGI.8.6.9/911001.SGI)
	for <tiff-relay@cthulhu.engr.sgi.com> id NAA07834; Tue, 25 Oct 1994 13:49:28 -0700
Received: from en.ecn.purdue.edu by sgi.sgi.com via ESMTP (940627.SGI.8.6.9/910110.SGI)
	for <tiff@sgi.com> id NAA16899; Tue, 25 Oct 1994 13:49:26 -0700
Received: from en.ecn.purdue.edu (davisonj@localhost)
	by en.ecn.purdue.edu (8.6.9/3.5davy)
	id PAA21664; Tue, 25 Oct 1994 15:49:20 -0500
Message-Id: <199410252049.PAA21664@en.ecn.purdue.edu>
From: John M Davison <davisonj@ecn.purdue.edu>
Subject: Re: C++ tiff library
To: tiff@sgi.sgi.com
Date: Tue, 25 Oct 1994 15:49:19 -0500 (EST)
In-Reply-To: <9410212053.AA10216@kismet.> from "Richard Minner" at Oct 21, 94 01:53:19 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
Content-Length: 2031      
Sender: owner-tiff@sgi.sgi.com
Precedence: bulk

        Richard Minner (rtm@island.com) writes:

>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>

