From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 10a146,a03ae7f4e53958e1
X-Google-Attributes: gid10a146,public
X-Google-Thread: fac41,a03ae7f4e53958e1
X-Google-Attributes: gidfac41,public
X-Google-Thread: 109fba,a03ae7f4e53958e1
X-Google-Attributes: gid109fba,public
X-Google-Thread: 1014db,a03ae7f4e53958e1
X-Google-Attributes: gid1014db,public
X-Google-Thread: fa0ae,a03ae7f4e53958e1
X-Google-Attributes: gidfa0ae,public
X-Google-Thread: 103376,8775b19e3c68a5dc
X-Google-Attributes: gid103376,public
X-Google-Thread: 114809,a03ae7f4e53958e1
X-Google-Attributes: gid114809,public
X-Google-Thread: 1094ba,a03ae7f4e53958e1
X-Google-Attributes: gid1094ba,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Which language pays most? Smalltalk, not C++ nor Java.
Date: 1998/01/01
Message-ID: <dewar.883703838@merv>#1/1
X-Deja-AN: 312008446
References: <199712121931.LAA25389@sirius.infonex.com> <34A7B45C.403B@min.net>
 <dewar.883418599@merv> <01bd14b4$dc6f6a80$6428b4cf@carla.ici.net>
 <68du36$l10$1@darla.visi.com>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 883704347 26775 (None) 128.122.140.58
Organization: New York University
Newsgroups: 
 comp.lang.fortran,comp.lang.c,comp.lang.c++,comp.lang.eiffel,comp.lang.java.programmer,comp.lang.smalltalk,comp.lang.perl.misc,comp.lang.ada,comp.edu
Date: 1998-01-01T00:00:00+00:00
List-Id: <comp.lang.ada>


David said

<<Think of the standard as what you can count on in the language.  The
actual language a given compiler will accept is different, of course,
and the range of C "dialects" increases with every release with a
new feature or pragma or whatever.  If you are writing a particular
program for use with one version of one compiler on one system
(and I haven't done that in a *long* time), you can go wild with
the extensions.  If you might want to reuse some of your code
sometime, be careful with them.
>>

Even if you are using one particular compiler on one particular system,
you should not go "wild" using extensions. There are definite downsides
to using extensions:

1. They are often ill defined compared to the standardized features

2. There is no guarantee that they will continue to work in the same
	way from one version of the compiler to another

3. Standard tools for the language that might otherwise be usable may not
	be able to handle the extensions.

4. Programmers who know the language well may still not know the 
        extensions, so the resulting program may be less maintainable.

This does not mean that extensions should never be used, just that the
programmer should

(a) be very aware of what is and is not an extension.

(b) use extensions judiciously when they are definitely useful (i.e.
	it would be much harder or impossible to perform the required
	function without using the extensions.

As an example of a worthwhile extension, consider the nested functions
of GNU C. These are quite portable, in that they can be used on any
GCC implementation, are well defined, and are extremely useful (it
continues to amaze me that C and C++ omit this very useful feature, well
known, and well understood to be useful, since the days of Algol-60).
(note that nested functions are particularly valuable in the
context of multi-threaded programs, since they allow the use of non-local
variables that are thread specific.