Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!jacksun!dcj From: dcj%jacksun@Sun.COM (Donald Clark Jackson) Newsgroups: comp.windows.x Subject: Re: GNU C++ for toolkits Message-ID: <39720@sun.uucp> Date: 22 Jan 88 18:39:30 GMT References: <802@rlgvax.UUCP> Sender: news@sun.uucp Reply-To: dcj@sun.UUCP (Donald Clark Jackson) Organization: Sun Microsystems, Mountain View Lines: 38 Regarding the use/non-use of C++ for toolkits, I think there are more options for developers than I have seen discussed so far. 1) If you developing an object oriented toolkit today, and you wish to use C++, you could use one if the commercially available (& supported?) C++ translators, or you could use the 'alpha' version of GNU C++. 2) Regardless of the C++ translator used to develop the toolkit, users of the toolkit ought to be able to use any C++ translator that want. Developers should be able to switch translators as new (better, and/or cheaper) become available. Just because GNU C++ may not be stable today, doesn't mean that it won't be of production quality in the future. (This is a judgement each developer must make for him/her self) People developing object oriented toolkits have a decision to make 1) Does C++ have the features I want/need, versus the cost in time, effort, support, and non-standardness to re-invent my own object system. * I can start using C++ today using a commercial C++ translator, and bet that GNU C++ will be a viable option in the future. * I think toolkit developers should think hard before commiting themselves to re-inventing an object system just because GNU C++ isn't stable right now. You could start with a 'stable' commercial C++ translator, and switch to GNU C++ later. (The only problem is if you can't afford a commercial C++ translator to get started) * Availability of GNU C++ may not be an issue for developers of commercial products.