paul@dy4.uucp (Paul Burry) (01/17/90)
While we're on the subject of useful extensions to C
(like "typeof"), I was wondering if any of the other GNU C
extensions were proposed as new features in ANSI C.
Some of GNU C's more useful extensions (IMHO) are:
o the addition of the "typeof" keyword
o the addition of the "inline" keyword
o the addition of the "alignof" keyword
o statements and declarations inside of expressions
ie.
#define max(a,b) \
({ \
int _a = (a); \
int _b = (b); \
_a > _b ? _a : _b; \
})
(on a side note, why didn't ANSI C define a way to avoid
shadowing external variables in a macro defining?)
o generalized lvalues
ie.
allowing expressions, compound expressions and casts as lvalues.
o arrays of zero length
o arrays of variable length
ie.
some_function(int n)
{
char array[n];
:
}
o non-constant initializers allowed for aggregates
ie.
foo(float f, float g)
{
float array[2] = { f-g, f+g };
:
}
o application of volatile and const to functions
ie.
volatile functions do not return (like exit(), abort()).
const functions produce no side effects (like sin()).
There are a number of other extensions, but I think that these are the
most useful.
If these extensions were proposed, what was the justification for denying
their inclusion in the standard?
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Paul Burry PHONE: (613)-596-9911
UUCP: ...!cognos!dy4!paul POST: Dy4 Systems Inc., 21 Fitzgerald Road,
or ...!cognos!dy4!seu13!paul Nepean, Ontario, Canada K2H 9J4karl@haddock.ima.isc.com (Karl Heuer) (01/22/90)
In article <153@dy4.UUCP> paul@dy4.UUCP (Paul Burry) writes: >I was wondering if any of the other GNU C extensions were proposed as new >features in ANSI C. Yes, I'm pretty sure that several-to-most of those you list were proposed. >If these extensions were proposed, what was the justification for denying >their inclusion in the standard? They haven't been tested yet. The right way to standardize these experimental features is to make them non-standard extensions to a compiler, let them get good exposure, and then submit them as proposals for the *next* standard. Their presence in gcc makes them candidates for C99, not C89. >[e.g.] allowing expressions, compound expressions and casts as lvalues. I can't think of any useful semantics for |(a+b)=c|, and I don't believe that the feature exploited by |*((int *)charptr)++| is well-defined when you get away from vaxlike architectures (even assuming that |charptr| is known to be properly aligned). >(on a side note, why didn't ANSI C define a way to avoid shadowing external >variables in a macro defining?) I believe the Committee thought (as I do) that extending the preprocessor in that direction is a dead end, since inline functions provide a much cleaner and more powerful way to do most of the same tasks. Karl W. Z. Heuer (karl@haddock.isc.com or ima!haddock!karl), The Walking Lint
peter@ficc.uu.net (Peter da Silva) (01/22/90)
> >(on a side note, why didn't ANSI C define a way to avoid shadowing external > >variables in a macro defining?) > I believe the Committee thought (as I do) that extending the preprocessor in > that direction is a dead end, since inline functions provide a much cleaner > and more powerful way to do most of the same tasks. Is this really a reasonable argument, given that inline functions aren't in the standard? -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'
meissner@curley.osf.org (Michael Meissner) (01/22/90)
I will try to highlight which things acutally got proposed, and why it might have been rejected. In article <153@dy4.UUCP> paul@dy4.UUCP (Paul Burry) writes: | | While we're on the subject of useful extensions to C | (like "typeof"), I was wondering if any of the other GNU C | extensions were proposed as new features in ANSI C. | | Some of GNU C's more useful extensions (IMHO) are: | | o the addition of the "typeof" keyword It was proposed, and rejected on the grounds no new features and limited utility. | o the addition of the "inline" keyword It was proposed, and rejected on the grounds of qualitity of implementation (ie, the compiler should be smart enough to figure out when to inline). | o the addition of the "alignof" keyword It was debated, but never proposed, since there was no meeting of the minds of the precise details of alignment. It also came up, at a time when the committee was trying to not add new features. | o statements and declarations inside of expressions | ie. | #define max(a,b) \ | ({ \ | int _a = (a); \ | int _b = (b); \ | _a > _b ? _a : _b; \ | }) | (on a side note, why didn't ANSI C define a way to avoid | shadowing external variables in a macro defining?) Never proposed. | o generalized lvalues | ie. | allowing expressions, compound expressions and casts as lvalues. Brought up and definitely rejected on the grounds that this was a bug in PCC (K&R-1 I believe also outlaws it), and it is incredibly non-portable, particularly on some machines (like the DG & PR1ME machines with different pointer formats). | o arrays of zero length The whole area of zero sized items was debated over two meetings, and eventually tabled for various reasons. | o arrays of variable length | ie. | some_function(int n) | { | char array[n]; | : | } This was not proposed, but it looks like the numerical extension committee will go with it, and it will be a likely canidate for the next standard. | o non-constant initializers allowed for aggregates | ie. | foo(float f, float g) | { | float array[2] = { f-g, f+g }; | : | } This was proposed when the committee decided to allow initializing automatic aggregates. There were some problems pointed out in how to nail down all of the details, also many people thought it was too complex to satisfy the need (particularly those who would have to implement it). | o application of volatile and const to functions | ie. | volatile functions do not return (like exit(), abort()). | const functions produce no side effects (like sin()). These were not proposed. I think that towards the end the committee became more gunshy of overloading keywords (void having three different meanings). | There are a number of other extensions, but I think that these are the | most useful. Scanning the GCC texinfo file, the other extensions are: o Pointer arithmetic on pointers to void and/or functions This may have been brought up, and shot down because this is non-portable, and the semantics of doing it are questable. o Constructors (creating runtime aggregate expressions) I remember some discussion, but I think it was dropped due to inadequate support. o Dollar signs in identifiers This was rejected, because some systems cannot support $ in identifiers, and $ is only of the national characters in ISO 646, and would need a trigraph to use (yech). o Extended asm, asm labels, & global register variables These were never considered, since the committee did not bless the 'asm' (or 'fortran' for that matter) extension. | If these extensions were proposed, what was the justification for denying | their inclusion in the standard? | | -- | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Paul Burry PHONE: (613)-596-9911 | UUCP: ...!cognos!dy4!paul POST: Dy4 Systems Inc., 21 Fitzgerald Road, | or ...!cognos!dy4!seu13!paul Nepean, Ontario, Canada K2H 9J4 Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so
chuckp@ncr-fc.FtCollins.NCR.com (Chuck Phillips) (01/25/90)
In article <2909@paperboy.OSF.ORG> meissner@curley.osf.org (Michael Meissner) writes: > | o the addition of the "inline" keyword > It was proposed, and rejected on the grounds of qualitity of > implementation (ie, the compiler should be smart enough to > figure out when to inline). Apples and oranges. What about "inline" keyword as a less kludgey alternative to macros? That is, the inline function would be in a _header_ file like a macro. The idea of the inline _keyword_, IMHO, is a macro-like facility that preserves the _semantics_ of C, _unlike cpp macros_. This is _not_ the same as automatically inlining small functions which, I agree, the compiler should do if optimization is enabled. I submit for discussion: Consider the difficulty of automatic inlining of separately compiled functions. I'm no compiler expert, but this _seems_ like an expensive optimization to implement. By having an inline (keyword) definition in the header file normally used when accessing the function (e.g. string.h), this type of optimization can be had much cheaper. Ideas? Opinions? -- Chuck Phillips -- chuckp%ncr-fc.FtCollins.NCR.COM uunet!ncr-sd!chuckp%ncr-fc ccncsu.ColoState.EDU!chuckp%ncr-fc
bright@Data-IO.COM (Walter Bright) (01/25/90)
In article <IJ81DV3ggpc2@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
<< I believe the Committee thought (as I do) that extending the preprocessor in
<< that direction is a dead end, since inline functions provide a much cleaner
<< and more powerful way to do most of the same tasks.
<Is this really a reasonable argument, given that inline functions aren't in
<the standard?
Yes. Inline functions are a standard part of C++. Since Ansi C has already
borrowed a lot of features from C++ (prototyping, const), and the use and
implementation of inline functions is proven, there is no point to inventing
preprocessor kludges to do the same thing.
Since the ANSI standardization of C++ is under way, there is not much point
in a subsequent standard for C that is not C++.
It comes down to, if you want inline functions, use C++. It really ain't that
bad, and C++ compilers are more available than ANSI C compilers!brnstnd@stealth.acf.nyu.edu (01/25/90)
In article <CHUCKP.90Jan24094828@halley.ncr-fc.FtCollins.NCR.com> chuckp@ncr-fc.FtCollins.NCR.com (Chuck Phillips) writes: > Consider the difficulty of automatic inlining of separately compiled > functions. I'm no compiler expert, but this _seems_ like an expensive > optimization to implement. By having an inline (keyword) definition in the > header file normally used when accessing the function (e.g. string.h), this > type of optimization can be had much cheaper. Correct. It's simply impossible to do that inlining under the current compile-link model, and worse than impossible for the compiler to figure out when that inlining should happen. (After all, there's no excuse for the compiler to look at the code in another file, and the linker can't perform this optimization.) GNU did a good job with inline. ---Dan
shankar@hpclisp.HP.COM (Shankar Unni) (02/17/90)
> > Since the ANSI standardization of C++ is under way, there is not much point > > in a subsequent standard for C that is not C++. > > Why not? C is not C++. It's not certain that C++ is even the best way to > add object-oriented features to C, particularly given the existence of > a competing implementation, Objective-C, and languages like Eiffel that > compile to C. Well, since C++ gives you almost everything you ever wanted in C, why not use it in a C-like fashion and simply take advantage of the nifty new features (instead of dragging in the object-oriented paradigm)? No one mandates that all C++ programmers *must* program in an O-O fashion. C++ also makes wonderful sense as simply a "nicer C". ------ Shankar Unni. Hewlett-Packard Company.
peter@ficc.uu.net (Peter da Silva) (02/20/90)
> > > Since the ANSI standardization of C++ is under way, there is not much > > > point in a subsequent standard for C that is not C++. > > Why not? C is not C++.... > Well, since C++ gives you almost everything you ever wanted in C, why not [ use it without the object-oriented stuff ] Because I might prefer the way Co2 or Objective C handles object oriented stuff, and it's awfully silly to add two sets of O-O overhead to the language. Besides, there's lots of stuff I'm missing from C that's not in C++. Coroutines, for example... -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ \_.--._/ Xenix Support -- it's not just a job, it's an adventure! v "Have you hugged your wolf today?" `-_-'