Re: J3's workings

Beliavsky <beliavsky@xxxxxxx> wrote:

Maybe after Fortran 2003, the language should evolve
by having compiler writers, both commercial and volunteer, (gfortran
and g95) add extensions that they think are important based on user
requests. If those features are adopted by several compilers, they
could later be standardized.

I think that approach is completely unacceptable.

1. As a user, I avoid using vendor extensions even when they are
features that I highly desire. While I make exceptions, they are darned
rare. And features supported by only a single vendor are even more rare
(as in I can't think of a single one that I use). This wasn't always the
case, but it is now. I'm not the only user like this. Thus you get a
biased picture by looking only at things that users have pushed
compilers developers into doing as extensions. You don't get the kind of
features that people like me want; I tend to view that as a negative.
:-)

2. When compiler vendors independently develop a feature independent of
standardization, it is almost inevitable that the different versions of
the feature won't be identical. This causes difficulty in the
standardization. A common approach recently has been to deliberately do
the feature in a way that is different from any of the existing
implementations in a way that allows support of both the vendor-specific
and the newly standardized versions to coexist. That approach works fine
for things like intrinsic procedures, where using a different name is
enoug hto avoid conflict. That approach wouldn't work so well for more
basic things in the language.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: howto get rid of pointer arguments differ in signedness
    ... conforming C source code' and incorporate both machine-specific ... Even if the compiler has machine-specific features and extensions, ...
    (comp.os.linux.development.apps)
  • Re: Porting C software
    ... C99 contains a few features that look particularly problematic (dynamic ... GCC is a particular implementation. ... nice currently left void by gcc, that of being an at-runtime compiler (IMO, ... and quaternion math using my extensions, well, then, it is not portable. ...
    (comp.lang.c)
  • Re: Porting C software
    ... C99 contains a few features that look particularly problematic (dynamic ... GCC is a particular implementation. ... my case, I have a compiler, it supports a subset of C (and also has a few ... and quaternion math using my extensions, well, then, it is not portable. ...
    (comp.lang.c)
  • Re: Why not add namespace feature into standard C?
    ... features, I can't understand why not add this feature into standard C. ... Because the standards people were more concerned with adding arbitrary ... All the compiler vendors have balked. ...
    (comp.lang.c)
  • Re: C++ danger to break due to its weight, fragmentation danger - C++0x
    ... Also not all of the new features will be ... libraries for the standard on the way which are optional. ... extensions to the C++ compiler. ...
    (comp.lang.cpp)