>>>>> Bill Wade <bill.wade@stoner.com> writes:

> A good point.  Insofar as templates are similar in flavor to macro
> languages, many of the same problems are visible in current C++
> compilers. If I write

>   template<class A, class B> void foo(A& a, B b)
>   {
>     line1: a = b;
>   }
>   ...
>   int* x;
>   int y;
>   line2: foo(x,y);

> I'd really appreciate it if my compiler's error message pointed me at
> both line1 and line2.  Does anyone have a compiler that does this?

Watcom, for x86.

--

Ciao,
Paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7499eo$jom$1@uuneo.neosoft.com>,
  "Bill Wade" <bill.wade@stoner.com> wrote:
>
> AllanW@my-dejanews.com wrote in message <744bl5$cp2$1@nnrp1.dejanews.com>...
> >Can anyone remember a case before C++, where some language FOO was
> >directly derived from (and not merely influenced by) some other
> >language BAR, to the point of remaining upwards-compatible with
> >most real (but not neccesarily all theoretical) BAR programs --
> >and yet BAR also remained as a distinct, evolving language?
> >If so, what happened when BAR continued to evolve -- did FOO
> >accept most of the changes as well, or did the languages grow
> >in different directions?
>
> Ratfor ("Software Tools", Kernighan & Plauger, Addison-Wesley, 1976) might
> fit the bill.  It extended what I call Fortran 66 to include compound
> statements and many other features which are in C.  For instance

I've heard of Ratfor, and I believe that it was in wide-enough use to
set precedents, if both of the following are also true (I don't know
enough about it to say myself):

    1) There is such a thing as ANSI or ISO Standard Ratfor.

I am, after all, asking about what happened to the language after
they each had standards.

    2) Substantially all Fortran 66 programs work in Ratfor.

Remember, one design goal of C++ was to remain source-compatible with
most real C programs (although not neccesarily all theoretically-
possible C programs).

If both of these are true, can you tell us what happened over time?
I.e. when Fortran 90 rolled around, did Ratfor adopt all or most of
the changes in Fortran? Or did they grow independantly?

Or perhaps Fortran 90 adopted most of Ratfor's advantages? If so,
does it use the same syntax that Ratfor did? Or do we now have a
new incompatible way of achieving Ratfor's goals?

Or did Ratfor freeze and/or die? I personally haven't heard much
about it lately, which I suppose doesn't mean much.

Please tell us.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7499eo$jom$1@uuneo.neosoft.com> "Bill Wade" <bill.wade@stoner.com> writes:
>Some would correctly argue that Ratfor was merely a preprocessing language.

Wow, been a very long time since I used RATFOR, but I think I would
agree with that, thought somewhat smartish preprocessor as I recall it.

>Of course for most of its life C++ has been merely a preprocessing language
>(cfront).

And so when did that change and more to the point, what made it change?
Seriously, C++ was never considered a preprocessing language, and if cfront
is considered a preprocessor, than indeed, all compilers in all languages
are preprocessors, which IMO would be pushing the definition of the word
(surely it fits the English dictionary description, but not the technical
one at hand).  C++'s typing et al prescribes a more intense analysis
on many facets.  "Dumb text substitution", ok even with some smarts,
simply cannot suffice for C++. Do not be led atray because cfront generated C.
The C DID NOT come from the input C++, but from intermediate form that
could only be generated upon syntax/error/semantics/etc analysis.
That cfront generated C was strictly a code generation decision.
Nothing by the name of C++ was ever a preprocessed language.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bjarne Stroustrup wrote in message ...
>"Bill Wade" <bill.wade@stoner.com> writes:
>> Some would correctly argue that Ratfor was merely a preprocessing
language.
>> Of course for most of its life C++ has been merely a preprocessing
language
>> (cfront).
>
>Oldtimers here will know that I I object to statements like "for most of
>its life C++ has been merely a preprocessing language." I object politely,
>but firmly.


Let me apologize.  I had intended a smiley at the end of the paragraph, but
I probably destroyed the smiley when I added "(cfront)."

I had intended to show that "preprocessor" was a term with widely varying
meanings.  As such, merely calling a language a preprocessor is a weak means
of disparaging it.  I had considered using any version of C which outputs
assembly as my example of another preprocessor, but decided that a C++
example was more on topic.

A suppose Bjarne might argue that a preprocessor is a language which is
incomplete, in the sense that its grammar contains an "other" production
which generates output with little or no semantic analysis of its input.

For the most part I use languages more than I design or implement them.  As
a user, rather than implementor, I suppose I've always considered a
preprocessor to be any translator (convert this program from one language to
another) along the path towards execution.  By this definition compilers are
preprocessors.  Interpreters (including CPU's) are processors.  Although I
would rarely bother to call a compiler a preprocessor (what is the point?)
there were exceptions.  When using f2c to move Fortran code to a machine
where I wished to avoid the native fortran compiler, I considered f2c to be
a preprocessor.

Applying the term "preprocessor" to the language, rather than the tool, is
probably a better use.  If nothing else it gives preprocessor a meaning
which is distinct from translator.  With this definition it is clear that
C++, as opposed to C with classes, is no preprocessor.

>Users of traditional preprocessors, such as Ratfor and my C with Classes
>preprocessor, invariably have problems with two different programs
>detecting and reporting errors (rather than one), with symbolic
>debugging, etc. My implementation of C++ avoided these problems by
>having Cfront do a complete syntax and semantics analysis of the
>source code and using C as an output language, "an assembler", only.


A good point.  Insofar as templates are similar in flavor to macro
languages, many of the same problems are visible in current C++ compilers.
If I write

  template<class A, class B> void foo(A& a, B b)
  {
    line1: a = b;
  }
  ...
  int* x;
  int y;
  line2: foo(x,y);

I'd really appreciate it if my compiler's error message pointed me at both
line1 and line2.  Does anyone have a compiler that does this?

>(The standard C/C++ preprocessor, cpp, is yet another problem).


Well you didn't slay this particular dragon, but you did put a nice loud
bell around its neck (ok so my metaphors are mixed up).  For that I thank
you.

Best regards.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>>>>> Bill Wade <bill.wade@stoner.com> writes:

 > A good point.  Insofar as templates are similar in flavor to macro
 > languages, many of the same problems are visible in current C++ compilers.
 > If I write

 >   template<class A, class B> void foo(A& a, B b)
 >   {
 >     line1: a = b;
 >   }
 >   ...
 >   int* x;
 >   int y;
 >   line2: foo(x,y);

 > I'd really appreciate it if my compiler's error message pointed me at both
 > line1 and line2.  Does anyone have a compiler that does this?

The current egcs development tree walks up the instantiation stack when it
hits an error, printing what line triggered each instantiation.  I think
other compilers do that, too.

Jason


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote in message <744bl5$cp2$1@nnrp1.dejanews.com>...
>Can anyone remember a case before C++, where some language FOO was
>directly derived from (and not merely influenced by) some other
>language BAR, to the point of remaining upwards-compatible with
>most real (but not neccesarily all theoretical) BAR programs --
>and yet BAR also remained as a distinct, evolving language?
>If so, what happened when BAR continued to evolve -- did FOO
>accept most of the changes as well, or did the languages grow
>in different directions?


Ratfor ("Software Tools", Kernighan & Plauger, Addison-Wesley, 1976) might
fit the bill.  It extended what I call Fortran 66 to include compound
statements and many other features which are in C.  For instance

for(i = 3; i < 20; i = i + 1){
   if(foo(i))
     break
   j = j + 3 * i
}

is valid Ratfor, even though that version of fortran did not have any of
  for, <, break, {, }

Fortan source could often be processed by ratfor, without modification, as
long as it didn't use obscure features (like comments ;-).

The source for ratfor was small (at most a few k lines) and inexpensive (the
price of the book) so it was never widely marketed.  It was delivered, in
executable form, with some versions of Unix.

When f77 came around with better control structures, we saw and used
enhanced versions of ratfor which generated "cleaner" fortran.

Before f90 rolled around, the macro processor in our version of ratfor
allowed us to declare and use UDT's (which are also in f90, I believe).
Before we ever used an f90 compiler, we had converted all of our ratfor
source to C++.

Some would correctly argue that Ratfor was merely a preprocessing language.
Of course for most of its life C++ has been merely a preprocessing language
(cfront).




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Bill Wade" <bill.wade@stoner.com> writes:

> AllanW@my-dejanews.com wrote in message <744bl5$cp2$1@nnrp1.dejanews.com>...
> >Can anyone remember a case before C++, where some language FOO was
> >directly derived from (and not merely influenced by) some other
> >language BAR, to the point of remaining upwards-compatible with
> >most real (but not neccesarily all theoretical) BAR programs --
> >and yet BAR also remained as a distinct, evolving language?
> >If so, what happened when BAR continued to evolve -- did FOO
> >accept most of the changes as well, or did the languages grow
> >in different directions?


> Ratfor ("Software Tools", Kernighan & Plauger, Addison-Wesley, 1976) might
> fit the bill. ...
>
> When f77 came around with better control structures, we saw and used
> enhanced versions of ratfor which generated "cleaner" fortran.
>
> Before f90 rolled around, the macro processor in our version of ratfor
> allowed us to declare and use UDT's (which are also in f90, I believe).
> Before we ever used an f90 compiler, we had converted all of our ratfor
> source to C++.

:-)


<digression>

> Some would correctly argue that Ratfor was merely a preprocessing language.
> Of course for most of its life C++ has been merely a preprocessing language
> (cfront).

Oldtimers here will know that I I object to statements like "for most of
its life C++ has been merely a preprocessing language." I object politely,
but firmly.

Before C++, I designed and implemented a preprocessor language in the
tradition of Ratfor (I worked in the research center where Ratfor originated).
This language, C with Classes, convinced me that only a traditional compiler
front end could cope with the syntax, the type checking, and the semantic
transformations needed by C++. So I built such a traditional front end,
named Cfront.

Users of traditional preprocessors, such as Ratfor and my C with Classes
preprocessor, invariably have problems with two different programs
detecting and reporting errors (rather than one), with symbolic
debugging, etc. My implementation of C++ avoided these problems by
having Cfront do a complete syntax and semantics analysis of the
source code and using C as an output language, "an assembler", only.

By using C as an assembler, I achieved one of the most valuable aspects
of a preprocessor - easy portability - without the problems of a
preprocessor.

(The standard C/C++ preprocessor, cpp, is yet another problem).

See "The Design and Evolution of C++" for details.

</digression>


I think the C/C++ situation is unique in the history of formal standards.
It is a bit as if the Fortran77 and Fortran90 committees had parted ways
and simultaneously worked on standards - which inevitably would compete.

The situation resembles the situation in the Lisp world where many reject
the official standard and the Unix world where dialects continuously feud
for primacy. In both cases, the lack of a single standard (fatally?)
weakened the community leaving the field open for (inferior?) alternatives.

I had hoped that C++ would one day become C, or C become C++, - and worked
hard to ensure an unprecedented degree of compatibility between C and C++.
However, so far this convergence has not happened. A significant fraction
of the C community didn't/don't share my ideal of convergence - and with
the new C standard coming up the next chance won't be for another 5 to 10
years.

 - Bjarne
Bjarne Stroustrup - http://www.research.att.com/~bs




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3664CB28.1DD75041@wizard.net>, kuyper@wizard.net says...

[ ... I wrote: ]

> > PL/I was derived from FORTRAN and COBOL, but both FORTRAN and COBOL
> > remain in wide use -- almost certainly much wider use than PL/I.
>
> I don't know as much about the other cases that you mentioned as I do
> about this one. I doubt that this relationship is a good analog to the
> C/C++ relationship. Could a PL/I compiler compile unmodified FORTRAN or
> COBOL code?

Not normally, no.  There is, of course, a hello-world program around
that manages to be legal source code in quite a few language by clever
use of things that look like code to one language but a comment to
another, but it's clearly the exception.

If source code compatibility is the level of "derivation" being
discussed, then most of the examples I gave don't apply, though Scheme
being derived from LISP would follow fairly closely.  Some well-
written LISP will work as Scheme, though (much like C/C++) there's
also code that won't.  I'm not sure, but I believe most Modula II will
also compile as Modula III.

Most older C code (that used function declarations instead of
prototypes) won't compile as C++ without at least some modification
either.

It wouldn't surprise me if a Pascal->Modula  II or Ada translation is
about as simple as adding prototypes to older C code.  Translating
most FORTRAN to PL/I would be pretty trivial as well, though a program
that really did so dependably would be difficult -- parsing FORTRAN is
notoriously difficult.

However, these still have one fundamental difference: while the
translation is often easy in these cases, there's no question that
after the translation, the result is no longer compatible with the
original language, while C code that has had prototypes added is still
C code, at least as the language is currently defined.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3664CB28.1DD75041@wizard.net>,
James Kuyper  <kuyper@wizard.net> wrote:
>
>I don't know as much about the other cases that you mentioned as I do
>about this one. I doubt that this relationship is a good analog to the
>C/C++ relationship. Could a PL/I compiler compile unmodified FORTRAN or
>COBOL code?

Good point, although I once used a COBOL compiler (WATBOL from University of
Waterloo) that tried real hard to compile FORTRAN programs.  Given a trivial
program:

      I = 1
      PRINT I
      END

WATBOL would pump out errors like:

  IDENTIFICATION DIVISION missing, default assumed
  DATA DIVISION missing, default assumed
  PROGRAM DIVISION missing, default assumed
  statement in wrong margin, assumed margin A
  COMPUTE assumed before assignment
  ...

and then compile and execute the program anyway.
--
Jim Cobban   |  jcobban@nortel.ca                   |  Phone: (613) 763-8013
Nortel Networks (MED)                               |  FAX:   (613) 763-5199


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote in message <744bl5$cp2$1@nnrp1.dejanews.com>...

>Can anyone remember a case before C++, where some language FOO was
>directly derived from (and not merely influenced by) some other
>language BAR, to the point of remaining upwards-compatible with
>most real (but not neccesarily all theoretical) BAR programs --
>and yet BAR also remained as a distinct, evolving language?
>If so, what happened when BAR continued to evolve -- did FOO
>accept most of the changes as well, or did the languages grow
>in different directions?

I think Common Lisp vs. earlier Lisps may be the closest example. Common
Lisp was designed as an as-compatible-as-possible superset of the existing
Lisps of the day (BBN's Lisp, MACLisp, the two Lisp Machine Lisps, Franz
Lisp, even Scheme and T, and maybe some west coasts Lisps I've forgotten).
The difference is that none of the base languages (except Scheme) had
standards. Except for Scheme, the Lisps that survived essentially turned
into Common Lisp (I think, to the best of my knowledge, etc.).

This is getting dense of "as I remember it"s, but it is my impression that
the Scheme and Common Lisp standards pretty much ignored  one another, since
they spoke to such different needs. All in all rather different than the
C/C++ relationship.

David J. Littleboy <davidjl@gol.nonspam.com>





[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <73vfs1$8ud$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
says...

[ ... ]

> I'd like to refer to precedents, if there is such a thing. Can anyone
> remember a case before C++ where language FOO was derived from BAR,
> and yet BAR also remained as a distinct language?

Many of them, as a matter of fact.

PL/I was derived from FORTRAN and COBOL, but both FORTRAN and COBOL
remain in wide use -- almost certainly much wider use than PL/I.

Pascal was derived to some extent from Algol 60, and as a reaction to
Algol 68.  All three remain distinct, though I doubt either Algol 60
or 68 is used much anymore.

Ada and Modula II derived from Pascal, but Pascal remained a distinct
language.

I'm not sure if Bertrand Meyer has ever explicitly stated it, but
Eiffel certainly looks like it was derived from Pascal to a degree as
well.

Oberon and Modula III were both derived from Modula II, which is
probably not used particularly heavily anymore, but certainly remains
distinct.

ML and Scheme were derived to at least some concepts from LISP, but
Common Lisp (for one example) remains distinct in probably even in
wider use than either.

Of course, many of these cases (e.g. FORTRAN, COBOL and Common Lisp)
would be cited by many as distinctly inferior choices remaining in use
due to purely to misguided souls, managerial inertia, etc., all of
them remain, regardless of how poor the reasons may be.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jerry Coffin wrote:

> In article <73vfs1$8ud$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
> says...

> [ ... ]

> > I'd like to refer to precedents, if there is such a thing. Can anyone
> > remember a case before C++ where language FOO was derived from BAR,
> > and yet BAR also remained as a distinct language?

> Many of them, as a matter of fact.

> PL/I was derived from FORTRAN and COBOL, but both FORTRAN and COBOL
> remain in wide use -- almost certainly much wider use than PL/I.

I don't know as much about the other cases that you mentioned as I do
about this one. I doubt that this relationship is a good analog to the
C/C++ relationship. Could a PL/I compiler compile unmodified FORTRAN or
COBOL code?


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jerry Coffin wrote in message ...
>
>In article <73vfs1$8ud$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com says...
>
>> I'd like to refer to precedents, if there is such a thing. Can anyone
>> remember a case before C++ where language FOO was derived from BAR,
>> and yet BAR also remained as a distinct language?
>
>Many of them, as a matter of fact.
>
> [ Summarising your examples:
>    Fortran + Cobol -> PL/I
>    Algol 60 -> Algol 68, Pascal
>    Pascal -> Ada, Modula II, Eiffel
>    Modula II -> Oberon, Modula III
>    Lisp -> ML, Scheme ]

Some of these are stretching a bit. I'd say the only examples that are
closely analogous to C->C++ are Algol 60->68, Pascal->Ada, and maybe
Lisp->Scheme (I'm not familiar enough with that last pair to be sure).
As far as I know, in none of those cases did the formal standard for
the new language explicitly include the standard for the old language.
C++ seems to be unique in that respect.

>Of course, many of these cases (e.g. FORTRAN, COBOL and Common Lisp)
>would be cited by many as distinctly inferior choices remaining in use
>due to purely to misguided souls, managerial inertia, etc., all of
>them remain, regardless of how poor the reasons may be.

Of course, some of us would say the same about C.

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
                               * * * * *
    To err is human. To really screw up requires the root password.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> In article <73vfs1$8ud$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
> says...
>
> [ ... ]
>
> > I'd like to refer to precedents, if there is such a thing. Can anyone
> > remember a case before C++ where language FOO was derived from BAR,
> > and yet BAR also remained as a distinct language?

In article <MPG.10ce2066fa0b0e9a98973f@news.rmi.net>,
  jcoffin@taeus.com (Jerry Coffin) wrote:
> Many of them, as a matter of fact.
[Goes on to list PL/I, Pascal, Ada, Eiffel, Oberon and Modula III,
 ML and Scheme]
> Of course, many of these cases (e.g. FORTRAN, COBOL and Common Lisp)
> would be cited by many as distinctly inferior choices remaining in use
> due to purely to misguided souls, managerial inertia, etc., all of
> them remain, regardless of how poor the reasons may be.

Sorry if I wasn't clear. Here's what I should have asked:

Can anyone remember a case before C++, where some language FOO was
directly derived from (and not merely influenced by) some other
language BAR, to the point of remaining upwards-compatible with
most real (but not neccesarily all theoretical) BAR programs --
and yet BAR also remained as a distinct, evolving language?
If so, what happened when BAR continued to evolve -- did FOO
accept most of the changes as well, or did the languages grow
in different directions?

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.10ca711486cdf8c198a33a@news.concentric.net>,
  brownsta@concentric.net (Stan Brown) wrote:

> francis@robinton.demon.co.uk (Francis Glassborow) wrote:
> >One purpose behind a standard is to provide stability, that does not
> >mean that people cannot explore extensions but it does mean that SC22 is
> >not going to consider changes other than repairs for ten years.

> Something I wonder about in this process:

> As we know, the C++ committee made lots of decisions with a very strong
> view toward maintaining C compatibility. But the C language and library
> will be changing in very much less than that 10-year time frame. Then we
> have C++ compatible with a formerly-but-no-longer-standard C.

> Given that the C++ standard refers to much of the C standard, rather than
> actually copying its text, how will compatibility be maintained with C9X?
> Will some sort of correction bulletin be adopted on an expedited track?
> Or will C++ continue to refer to the 1989 vintage C?

I'd like to refer to precedents, if there is such a thing. Can anyone
remember a case before C++ where language FOO was derived from BAR,
and yet BAR also remained as a distinct language?

(I can think of one utility that borrowed COBOL's DATA DIVISION, but
that hardly qualifies as distinct languages -- and besides, I doubt
that the IEBGENER utility ever had an ANSI standard.)

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage<stephen.clamage@sun.com> wrote:
>
>The C committee, as far as I know, has made very few changes in
>C9X that make it incompatible with C++. Some features of C were
>tightened up, but no tighter than C++ requires. C9X has extensive
>additions, few of which create problems for C++.

Many, perhaps most, members of the C committee (including those
I talked to in Santa Cruz) really don't care if C9x ends up
incompatible with C++, and might indeed prefer it.

The only active incompatibility I know of is C9x's definition
of the function-or-macro "clog" (complex log), which collides with
the C++ object std::clog (the logging stream) as exported to the
global namespace in the universal vendor extension <iostream.h>.

The C committee person I spoke with about it expressed the opinion
that for C++ (or anybody else, it seems) to have defined _any_ names
starting with the letter "c" was foolish, as the C people had always
intended to extend their support for the complex types and might
define some names that would collide.

I suspect we will see C and C++ diverge, simply because as much as we
in the C++ community want them to remain compatible, it does not appear
that many of those entrusted with C's evolution agree.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
....
> tightened up, but no tighter than C++ requires. C9X has extensive
> additions, few of which create problems for C++.

I suspect that VLA's, compound literals, and intializers with
designators may cause some compatibility problems. The interaction of
VLA's with C++ exceptions should be interesting ;-)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.10ca711486cdf8c198a33a@news.concentric.net>,
Stan Brown <brownsta@concentric.net> wrote:

> Given that the C++ standard refers to much of the C standard, rather than
> actually copying its text, how will compatibility be maintained with C9X?

It won't be.  The C++ committee officially asked the C committee
their opinion as to which C9X features would cause compatibility problems
with C++; the C committee's response was that their schedule did not
allow them time to answer the question.

What I think will happen, therefore, is that C++ compiler vendors will
adopt those C9X features that turn out to be useful for C++ programmers
as extensions, and when the time comes for the revised C++ standard,
the C++ committee will revisit the compatibility issue.

Not much else to be done, as far as I can see.
--
    Andrew Koenig
    ark@research.att.com
    http://www.research.att.com/info/ark



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

francis@robinton.demon.co.uk (Francis Glassborow) wrote:
>One purpose behind a standard is to provide stability, that does not
>mean that people cannot explore extensions but it does mean that SC22 is
>not going to consider changes other than repairs for ten years.

Something I wonder about in this process:

As we know, the C++ committee made lots of decisions with a very strong
view toward maintaining C compatibility. But the C language and library
will be changing in very much less than that 10-year time frame. Then we
have C++ compatible with a formerly-but-no-longer-standard C.

Given that the C++ standard refers to much of the C standard, rather than
actually copying its text, how will compatibility be maintained with C9X?
Will some sort of correction bulletin be adopted on an expedited track?
Or will C++ continue to refer to the 1989 vintage C?

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                      http://www.concentric.net/%7eBrownsta/
"I'm not even supposed to BE here!"  -- the mantra from /Clerks/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

brownsta@concentric.net (Stan Brown) writes:

>As we know, the C++ committee made lots of decisions with a very strong
>view toward maintaining C compatibility. But the C language and library
>will be changing in very much less than that 10-year time frame. Then we
>have C++ compatible with a formerly-but-no-longer-standard C.

>Given that the C++ standard refers to much of the C standard, rather than
>actually copying its text, how will compatibility be maintained with C9X?
>Will some sort of correction bulletin be adopted on an expedited track?
>Or will C++ continue to refer to the 1989 vintage C?

The C++ standard was on a schedule incompatible with the schedule for
C9X. It would have been nice to have made C++ compatible with C9X,
but that would have meant delaying the C++ standard for still more
years. (Assuming the C++ standard is published in 1999, which might
happen, the C++ standard could not have been published before 2001.)

Accordingly, the C++ standard incorporates the 1990 ISO C standard
(which was equivalent to the 1989 ANSI standard) and its 1995
amendment explicitly by reference.

The C committee, as far as I know, has made very few changes in
C9X that make it incompatible with C++. Some features of C were
tightened up, but no tighter than C++ requires. C9X has extensive
additions, few of which create problems for C++.

The C and C++ committees have several active members in common,
as well as a lot of overlap in the general membership. Most
members of both committees are very interested in maintaining
the maximum amount of compatibility.

I would expect to see C++ vendors augmenting their implementations
with C9X features. By the time the C++ standard comes up for
review, it should be pretty obvious how to amend the C++ standard
to make it as compatible as possible with the new C standard.

Of course, the C standard might be modified after that ...

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.10ca711486cdf8c198a33a@news.concentric.net>, Stan Brown
<brownsta@concentric.net> writes
>As we know, the C++ committee made lots of decisions with a very strong
>view toward maintaining C compatibility. But the C language and library
>will be changing in very much less than that 10-year time frame. Then we
>have C++ compatible with a formerly-but-no-longer-standard C.

C++ does exactly what it was intended to do here, avoided gratuitous
incompatibilities with C89 (which remained stable throughout the
standardisation of C++, not something that would have happened if
standards were for less than 10 years.

>Given that the C++ standard refers to much of the C standard, rather than
>actually copying its text, how will compatibility be maintained with C9X?
>Will some sort of correction bulletin be adopted on an expedited track?
>Or will C++ continue to refer to the 1989 vintage C?

Just as C9X avoids gratuitous incompatibilities with C++, but if you
tried to keep both in sinc the job would be impossible.  The languages
start from a common base (inherited with some overriders) but that does
not (and IMHO should not) require that either derived language should
dominate the other.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]