"Clive D. W. Feather" <clive@on-the-train.demon.co.uk> wrote in message news:<Pn7B6Zt$3kn7EwO0@romana.davros.org>...
> In article <8fbd32b9.0109100030.61ec1d34@posting.google.com>, Michael
> Andres <cizarre@gmx.net> writes
> >It would be helpful to have a standardized form to
> >mark source files with the version of the language
> >standard for which they were compiled.
> >
> ...
>
> You do realize that C89 *is no longer a standard* ?

Yes, I know. I would like to see this as a
contribution to a migration concept.

Other revisions of the language(s) will
follow and it might make sense to think
about standardized mechanisms to handle
this.


 - Michael

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

news_comp.std.c_expires-2001-11-01@nmhq.net (Niklas Matthies) wrote in message news:<slrn9ptvva.sc.news_comp.std.c_expires-2001-11-01@nightrunner.nmhq.net>...
> On Tue, 11 Sep 2001 17:05:45 GMT, Michael Andres <cizarre@gmx.net> wrote:
> >  Konrad Schwarz <konradDOTschwarz@mchpDOTsiemens.de> wrote in message news:<3B9CC8B4.41489A86@mchpDOTsiemens.de>...
> > > Michael Andres schrieb:
> > > >
> > > > It would be helpful to have a standardized form to
> > > > mark source files with the version of the language
> > > > standard for which they were compiled.
> > >
> > > # if 199901l > __STDC_VERSION__
> > > # error "This program requires C9x"
> > > # endif
> >
> >  Would work but looks ugly.
>
> It would not work, at least if you want more complex behaviour than
> just having compilation aborted for some particular set of versions.
>
> Maybe the simplest thing to do is to name the file extension
> accordingly, i.e. "file1.c90", "file2.c++98", "file3.c99".
> Then makefiles and compilers can choose to act in some
> appropriate fashion.
>
> Such a (optional) naming scheme could even reasonably be included
> into the standard, along with any behavioral requirements that
> might be deemed sensible.

A file naming scheme would be another possibility. Some compilers
already do this according to the file extension .c or .cpp.


 - Michael

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

"Konrad Schwarz" <konradDOTschwarz@mchpDOTsiemens.de> wrote in message
news:3B9CC8B4.41489A86@mchpDOTsiemens.de...
>
>
> Michael Andres schrieb:
> >
> > It would be helpful to have a standardized form to
> > mark source files with the version of the language
> > standard for which they were compiled.
>
> # if 199901l > __STDC_VERSION__
> # error "This program requires C9x"
> # endif
>

What about introducing macros for particular features in the language; for
example, a compiler that does not support, say, partial specialisation
wouldn't define the macro __STDC_PARTIAL_SPECIALISATION__.
(I'm sure that there are similar examples in C, but I'm less familar with
that standard.)   This might be more useful than just testing a version of
the standard.  If would also allow a compiler that is not fully conformant
to tell users in a standard way that they support a part of the language.
And given how few C++ compilers are currently conformant (the export keyword
for example), this would be very handy.

--
Richard Smith


---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

It would be helpful to have a standardized form to
mark source files with the version of the language
standard for which they were compiled.

Benefits:

- Such a version info would allow to mix source files
  that conform to different language standards.

- A compiler might provide options for issuing warnings
  depending on the version info.

- Syntax highlighting could be made dependant on the
  version info.

- The version info could be used by conversion
  tools.

- Discussions about modifications to language standards
  could be simplified.



How could such a version info look like?

Should it be required or optional in source files?

Should it be applied to future revisions of the language only?



 - Michael

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

On Mon, 10 Sep 2001 10:14:40 GMT, Michael Andres <cizarre@gmx.net> wrote:
>  It would be helpful to have a standardized form to
>  mark source files with the version of the language
>  standard for which they were compiled.

You mean "for which they were written", I suppose.

[=B7=B7=B7]
>  How could such a version info look like?

   using NUMERICAL_VERSION_NUMBER;

(cf. Perl's "use")
=20
>  Should it be required or optional in source files?

It must be optional in the sense that it cannot be required for source
code written for a version of a standard that didn't require (or not
even know about) such version info.
Apart from that, compiler vendors will make it optional anyway (if only
in some not 100% conforming mode), so it doesn't really matter much.
Maybe a compromise is to require a diagnostic if version info is missing.

>  Should it be applied to future revisions of the language only?

It cannot be "applied" to existing "revisions", since the respective
standards do not know about such a facility.

-- Niklas Matthies
--=20
If all you have is a hammer, everything looks like a nail.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres schrieb:
>
> It would be helpful to have a standardized form to
> mark source files with the version of the language
> standard for which they were compiled.

# if 199901l > __STDC_VERSION__
# error "This program requires C9x"
# endif

POSIX has similar things.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Konrad Schwarz <konradDOTschwarz@mchpDOTsiemens.de> wrote in message news:<3B9CC8B4.41489A86@mchpDOTsiemens.de>...
> Michael Andres schrieb:
> >
> > It would be helpful to have a standardized form to
> > mark source files with the version of the language
> > standard for which they were compiled.
>
> # if 199901l > __STDC_VERSION__
> # error "This program requires C9x"
> # endif

Would work but looks ugly. If it should be a requirement for
future standards only then it wouldn't be necessary to make
use of existing facilities anyway.


 - Michael

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

news comp.std.c++ expires-2001-11-01@nmhq.net (Niklas Matthies) wrote in message news:<slrn9pp6gh.ajm.news comp.std.c++ expires-2001-11-01@nightrunner.nmhq.net>...
> On Mon, 10 Sep 2001 10:14:40 GMT, Michael Andres <cizarre@gmx.net> wrote:
> >  It would be helpful to have a standardized form to
> >  mark source files with the version of the language
> >  standard for which they were compiled.
>
> You mean "for which they were written", I suppose.

Yes. But I also thought of the following:

- As an option the compiler could enter the version info
  into a file after a successful compilation.
- Another option could be: After a successful compilation the
  compiler could modify the version info of a source file that
  was originally written for an older language standard.


> [         ]
> >  How could such a version info look like?
>
>    using NUMERICAL VERSION NUMBER;
>
> (cf. Perl's "use")
>
> >  Should it be required or optional in source files?
>
> It must be optional in the sense that it cannot be required for source
> code written for a version of a standard that didn't require (or not
> even know about) such version info.
> Apart from that, compiler vendors will make it optional anyway (if only
> in some not 100% conforming mode), so it doesn't really matter much.
> Maybe a compromise is to require a diagnostic if version info is missing.
>
> >  Should it be applied to future revisions of the language only?
>
> It cannot be "applied" to existing "revisions", since the respective
> standards do not know about such a facility.

If the version info would look like
#pragma using NUMERICAL VERSION NUMBER
then it could be an optional entry for existing standards too.
(The version info would be evaluated by future standards.)


 - Michael

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres schrieb:
>
> Konrad Schwarz wrote in message
> > Michael Andres schrieb:
> > >
> > > It would be helpful to have a standardized form to
> > > mark source files with the version of the language
> > > standard for which they were compiled.
> >
> > # if 199901l > __STDC_VERSION__
> > # error "This program requires C9x"
> > # endif
>
> Would work but looks ugly. If it should be a requirement for
> future standards only then it wouldn't be necessary to make
> use of existing facilities anyway.

Hmm, it looks like you don't value qualities such as "flexibility"
or "minimality".

What do you think __STDC_VERSION__ was introduced for?

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

According to Michael Andres <cizarre@gmx.net>:
> news comp.std.c++ expires-2001-11-01@nmhq.net (Niklas Matthies) wrote in
> message news:<slrn9pp6gh.ajm.news comp.std.c++
> expires-2001-11-01@nightrunner.nmhq.net>...
> > On Mon, 10 Sep 2001 10:14:40 GMT, Michael Andres <cizarre@gmx.net> wrote:
> > >  It would be helpful to have a standardized form to
> > >  mark source files with the version of the language
> > >  standard for which they were compiled.
> >
> > You mean "for which they were written", I suppose.
>
> Yes. But I also thought of the following:
>
> - As an option the compiler could enter the version info
>   into a file after a successful compilation.
> - Another option could be: After a successful compilation the
>   compiler could modify the version info of a source file that
>   was originally written for an older language standard.

If all that you are doing is verifying that the code compiles without
compile-time errors in a given version, that info is not very useful -
you can quickly determine that for yourself by attempting to compile
the code with a version XYZ compiler in conforming mode.  The more useful
concept would be to flag which interpretation of various semantic
differences from version to version was intended, such as code that
assumes that long is the longest integer type (valid in C90 but not C99).
But that, I think, must generally be done by the programmer, not the compiler.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

In article <8fbd32b9.0109100030.61ec1d34@posting.google.com>, Michael
Andres <cizarre@gmx.net> writes
>It would be helpful to have a standardized form to
>mark source files with the version of the language
>standard for which they were compiled.
>
>Benefits:
>
>- Such a version info would allow to mix source files
>  that conform to different language standards.

Only if the compiler understands all the different versions.

>- A compiler might provide options for issuing warnings
>  depending on the version info.

I'm not sure of the point, here.

>- Syntax highlighting could be made dependant on the
>  version info.

Are there any differences significant enough to matter ?

>- Discussions about modifications to language standards
>  could be simplified.

Unlikely.

You do realize that C89 *is no longer a standard* ?

--
Clive D.W. Feather, writing for himself  | Home: <clive@davros.org>
Tel: +44 20 8371 1138 (work)             | Web:  <http://www.davros.org>
Fax: +44 20 8371 4037 (D-fax)            | Work: <clive@demon.net>
Written on my laptop; please observe the Reply-To address

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

On Tue, 11 Sep 2001 17:05:45 GMT, Michael Andres <cizarre@gmx.net> wrote:
>  Konrad Schwarz <konradDOTschwarz@mchpDOTsiemens.de> wrote in message news:<3B9CC8B4.41489A86@mchpDOTsiemens.de>...
> > Michael Andres schrieb:
> > >
> > > It would be helpful to have a standardized form to
> > > mark source files with the version of the language
> > > standard for which they were compiled.
> >
> > # if 199901l > __STDC_VERSION__
> > # error "This program requires C9x"
> > # endif
>
>  Would work but looks ugly.

It would not work, at least if you want more complex behaviour than
just having compilation aborted for some particular set of versions.

Maybe the simplest thing to do is to name the file extension
accordingly, i.e. "file1.c90", "file2.c++98", "file3.c99".
Then makefiles and compilers can choose to act in some
appropriate fashion.

Such a (optional) naming scheme could even reasonably be included
into the standard, along with any behavioral requirements that
might be deemed sensible.

-- Niklas Matthies
--
If two people agree with each other all the time, then one of those
people is unnecessary.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

> It would not work, at least if you want more complex behaviour than
> just having compilation aborted for some particular set of versions.
>
In most cases you'd find out if you have the wrong version because
the code that requires the newer compiler wouldn't even be accepted
by the older one.

Really, the best solution is to adopt the (new) standard compilers
as fast as possible and not make use of the new featuers until you
have a reasoanble expectation of their availability.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

On Wed, 12 Sep 2001 19:05:04 GMT, Ron Natalie <ron@sensor.com> wrote:
> > It would not work, at least if you want more complex behaviour than
> > just having compilation aborted for some particular set of versions.
> >
>  In most cases you'd find out if you have the wrong version because
>  the code that requires the newer compiler wouldn't even be accepted
>  by the older one.

I think a main purpose of the facility is to let compilers that support
more than one standard/language variant (like it is already the case
with K&R-C, C90, C++, C99) know which variant the code is meant for, and
not having to specify it in an implementation-dependent way via compiler
switches or similar (often out-of-band) means.

-- Niklas Matthies
--
The problem about having an open mind, of course, is that people will
insist on coming along and trying to put things in it.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

> It would be helpful to have a standardized form to
> mark source files with the version of the language
> standard for which they were compiled.

I don't think so. Explanation follows:

>
> How could such a version info look like?

This kind of information is not within the scope of a programming language.
Rather, it would be a natural fit for "meta data" to store about the
programs
you write. If you don't know what meta data is, think about it as entries in
some external database. Something you know about your code but should
not bloat up your sources.

The specific kind of information you have been asking for is more in the
scope of a configuration and build managment system.

>
> Should it be required or optional in source files?

It should not be in the source file, because that would introduce
"coupling".
The same piece of code may compile under many versions / implementations
of the language. You will not want to change the code to reflect this.




---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres wrote:
>=20
> It would be helpful to have a standardized form to
> mark source files with the version of the language
> standard for which they were compiled.

Although this idea looks very nice in the first moment, I have some
doubts it could be done in the real world. Having a look at boost.org, I
think the problem is not just a language standard or version of the
standard, but also broken features. Whatever is defined by the standard,
the compiler vendors will state compatibility as soon as possible, even
if some features are broken. Therefore, this decision cannot be left to
the vendors, it has to be some external resource that can mark compiler
versions as having or not having a feature. This is certainly not the
best theoretical approach, but in practice, I can't see how to improve
it by adding stuff to the standard.

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]

On Thu, 13 Sep 2001 16:43:09 GMT, Daniel Frey <daniel.frey@aixigo.de> wrote:
>  Michael Andres wrote:
> >
> > It would be helpful to have a standardized form to
> > mark source files with the version of the language
> > standard for which they were compiled.
>
>  Although this idea looks very nice in the first moment, I have some
>  doubts it could be done in the real world. Having a look at boost.org, I
>  think the problem is not just a language standard or version of the
>  standard, but also broken features. Whatever is defined by the standard,
>  the compiler vendors will state compatibility as soon as possible, even
>  if some features are broken.

At least it helps distinguishing a broken compiler from one doing
compilation using the wrong standard/version.

-- Niklas Matthies
--
Nothing is fool-proof to a sufficiently talented fool.

---
[ 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://www.research.att.com/~austern/csc/faq.html                ]