Valentin.Bonnard@free.fr (Valentin Bonnard) wrote in message
news:<200110070509.HAA01100@brick.ens.fr>...

    [...]
> > Yet the C++ standard includes features that (AFAIK) no-one has
> > ever implemented,

> You mean export ?

> > and indeed that violate one of Bjarne's suggested criteria for
> > language features (should have a relatively obvious
> > implementation).

> Well, Bjarne probably is the person who insisted the most for
> exported templates.

I'm not sure about that.  Bjarne argued very strongly that we needed
separate compilation for templates; something that seems very obvious
to me, as a user of C++ in large systems, but something that at times
the committee seemed on the point of abolishing.  Even today, separate
compilation is linked with export, and no compiler implements it.

> But he also implemented export, before it became a keyword.

I presume you are talking about CFront.  What CFront implemented is
rather far from what the standard requires.  On the other hand, it
*is* better than what most current compilers offer, at least with
regards to the standard, and many current compilers don't really
support the features of the standard (principally early name binding)
which make separate compilation so difficult.

--
James Kanze                                   mailto:kanze@gabi-soft.de
Beratung in objektorientierer Datenverarbeitung --
                             -- Conseils en informatique oriente objet
Ziegelhttenweg 17a, 60598 Frankfurt, Germany, Tl.: +49 (0)69 19 86 27



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3BC17C45.E277E01@divalsim.it>, Nicola Musatti
<objectway@divalsim.it> writes
>To recap the Ada standardization committee produced a validation test
>suite that practically defines how a compliant compiler should behave
>and a reference compiler which is compliant according to the test suite.
>Wouldn't it be possible to pursue the same route for C++?

If someone will fund the work:) Ada had a certain advantage because only
certified conforming implementations could be used for defence work (in
the US) and so like it or not the compiler implementers more or less
needed the reference compiler.



Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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                ]

Nicola Musatti <objectway@divalsim.it> writes:

> Valentin Bonnard wrote:
> [...]
> > C++, as all non deterministic languages (read: all modern
> > real-world languages, defines an infinite set of possible
> > behaviors for a given C++ program. This set is even more
> > infinite than in safe languages, because it includes the
> > possibility of undefined behavior.
>
> I'm not sure I understand what you mean. Could you give me an example
> that did not involve undefined behaviour?

Certainly.

#include <stdio.h>

int main()
{
  printf("%d\n", sizeof(int));
}

does not does not involve undefined behaviour; this program must print
a number on each conforming implementation. Which number it prints
exactly is implementation-defined. Likewise, what exactly std::stdout
is that I use in this example is implementation-defined: it could be a
line printer, or a CDE terminal window.

Other examples: Running a loop for 1000 times, and measuring the time
before and after it is implementation-defined. Printing the contents
of a POD struct by converting it to char* is
implementation-defined. Whether char has negative values is
implementation-defined. The string returned from typid().name() is
implementation-defined. Etc.

> > (Note: how do you know you have an implementation of C++ ?
> > You don't. You just assume you have one. Until you have a
> > problem -- I won't enter this issue.)
>
> The idea is to have a set of tests that let you check the
> conformance of an implementation.

It is not possible to construct a test suite that reliably determines
whether an implementation conforms to C++.

IOW, for any test suite you construct, I can create a compiler that
passes your all your tests, but still is not conforming. That compiler
is very easy to construct:

  For any given program, determine whether it is part of the test
  suite. If so, generate an executable that produces the expected
  output. For any other input program, generate an executable that
  prints "Hello, World!".

> > What can you do with that implementation ? Obviously you
> > are going to write demos. Then you compile the demos. But
> > ill-formed program can compile fine on conforming compilers
> > (ODR violations, invalid redefinitions of members, non-
> > functionaly equivalent template definitions...). Then you
> > run your demo. Incorrect code (whatever it means) can run
> > just fine when compiled with a conforming compiler.
>
> You can use the reference implementation to complement your commercial
> one with an initial version of features you hadn't implemented yet.

That certainly depends on the licensing of the "reference
implementation". In fact, what you are asking is a "relicensable
implementation". There are several such implementations of C++
available: on the "core" side, you can get licenses for EDG, g++, and
others; for the library, you can get licenses from RogueWave,
Dinkumware, and others. There is no need to declare any of them as a
"reference implementation" - companies already license these
implementations to incorporate them into their products.

Regards,
Martin

---
[ 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 <3BC3CF8A.62E2375A@wizard.net>, James Russell Kuyper Jr.
<kuyper@wizard.net> writes
>The fundamental problem is that the C++ standard says something about
>how a conforming implementation should process an extremely large number
>of different programs. This includes not only all strictly conforming
>programs, but also all programs for which a diagnostic is mandatory. An
>implementation is incorrect if it processes any one of those programs
>incorrectly, even if it processes every other program correctly.
>Therefore, the only test suite that can verify conformance is the
>complete collection of all such programs.

Which isn't to say that test suite's are valueless, just that their
value is limited and requires honest endeavour from those writing the
product to be tested.


Francis Glassborow
I offer my sympathy and prayers to all those who are suffering
as a result of the events of September 11 2001.

---
[ 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                ]

This message is cross-posted between comp.lang.c++.moderated
and comp.std.c++, where this thread really belongs, and where
I have set the followup.

[To mods: I send this article by mail for moderation for
clc++ first. Sorry for the xpost. (Really, moderators of
both groups should be able to accept article for the other
group.) ]

[To mods: are you fine with 8-bits bytes in messages bodies ?]

{ Maybe.  Mailers do strange things.  Judge from the results of
  this one.  clc++m -mod/jep }

I hope this will help csc++ exit the taxonomy black hole in
which it is falling (can you spell reference ?).

"Chris Newton"  wrote:
> Nicola Musatti <objectway@divalsim.it> wrote...
>> I wonder if the C++ community wouldn't profit too from
>> the existence of a freely available standard compliant
>> compiler

Obviously we can only benefit from freely available
quality tools. We would benefit from a freely available
compliant compiler (well, even a non-free compliant
compiler).

The problem is just that no-one has written one, yet.

>> which could act as a reference implementation.

What's that ?

> Am I the only one who finds it ironic that we have standardised on a
> version of C++ that *no-one* has ever implemented? :-)

Yes. (That's the short answer, as you might have guessed.)

I really don't understand what you mean. A ``version of
C++ no-one has implemented'': how can a version of C++ be
implemented ? Where does it drive you  ?

C++, as all non deterministic languages (read: all modern
real-world languages, defines an infinite set of possible
behaviors for a given C++ program. This set is even more
infinite than in safe languages, because it includes the
possibility of undefined behavior.

So an implementation is really a choice among the infinite
set of allowed behaviors. (Actually, if the implementation
is non-deterministic, as all are, it is a choice of an
infinite subset of the set of allowed behavior (power-set
operation).)

In short: standards (specifications) and compilers
(implementations) don't live in the same world.


But let's say you have an implementation of the standard.

(Note: how do you know you have an implementation of C++ ?
You don't. You just assume you have one. Until you have a
problem -- I won't enter this issue.)

What can you do with that implementation ? Obviously you
are going to write demos. Then you compile the demos. But
ill-formed program can compile fine on conforming compilers
(ODR violations, invalid redefinitions of members, non-
functionaly equivalent template definitions...). Then you
run your demo. Incorrect code (whatever it means) can run
just fine when compiled with a conforming compiler.

And the above is just usual C++ trivia we teach to
beginners, so it won't come as a surprise to committee
members.

Even if we had an ``exact'' implementation, that is, a
compiler that would detect every ill-formed program (and
this is provably impossible), and that would at run-time
print things such as ``undefined behaviour invoked''
whenever undefined behaviour really is invoked (at
run-time), what could we do ?

We could check our demo example and see if they _really_
work. But this magical compiler wouldn't help to establish
that a given proposal doesn't break any existing program
(beause we can't enumerate over existing programs).

The moral is that we have to reason, and built logical
arguments to prove that a C++ extension is sensible
(whatever it means), or that a given C++ does what it
has to do. Testing isn't sufficient.

> I've always found the role of the C++ standard slightly unusual.

Hopefully, it has invented new solutions. Sadly,
some are strange, ill-defined, half-baked, hard
to use, difficult to understand, or based on
ideology rather than pragmatism.

> Surely a standard would normally be created as a compromise between
> interested parties,

It is.

> something on which they could agree for mutual benefit. It
> would follow a general trend adopted by multiple parties, but specify
> the exact details unambiguously.

Then go and help the committee: take one of the DR lists, and
find solutions, evaluate proposed solutions... Of course, don't
forget to join your national body.

About the word ``unambiguously'': I assume you refer to the
an unambiguous set of possible behaviour, not to unambiguous
(unique, deterministic) behaviour.

> Yet the C++ standard includes features that (AFAIK) no-one has ever
> implemented,

You mean export ?

> and indeed that violate one of Bjarne's suggested criteria
> for language features (should have a relatively obvious implementation).

Well, Bjarne probably is the person who insisted the most for
exported templates.

But he also implemented export, before it became a keyword.

> In this respect, I think efforts like Boost are a Good Thing(TM). I
> would far rather see the next C++ standard based on what we can do, at
> that point, properly.

Boost is only about library (more precisely, the part of the
library that can be implemented without help for the compiler,
ie not the runtime support library).

And the point of Boost isn't to have an implementation (Boost
will accept a submited library even if it isn't implemented on
system <foo>, even if <foo> is a major system).

So being a Boost library doesn't mean you can be implemented on
all major systems, much less every system on which a conforming
C++ implemented is expected.

The goal of Boost is to propose _useful_ code to people, to
promote the use of a common body of code. Whether this code
becomes standard (well, whether the *specification* becomes
standard) isn't of primary importance to boosters.

(BTW, it means that the criteria for acceptance in Boost
are completely different from the criterias for acceptance
in standard C++.)

For Boost libraries being Good Things: well, are the binder
library, or the lambda library Good Things ? No, but without
changing the language they are the best plugs people have
been able to think of.

So, integrating the whole boost project into a future C++
_language_ standard is a *terrible* idea. A Bad Thing. And
Boost isn't a panacea.

> At least that way there is a chance that compilers
> produced afterwards will actually follow the standard, and reasonably
> quickly. And surely,

I am not sure.

> the best way to demonstrate "what we can do" is to
> have a reference compiler that *actually does it*.

I can be convinced by a logical argument that a proposal is
a sound idea (if you are wondering, yes, my choice of words
is intentional).

I have written some uncompilable code, also. (Not that I
wouldn't have liked to be able to compile it, of course.)

> So yes, I agree with Nicola. Basing the new standard on a compiler that
> demonstrates the features in action would be a major step forward.

This is already the case: the committee prefers to see new features
implemented, for some reasons:

- this shows that the feature really can be implemented (the
  next (political) question: does the implemented use any
  obvious but patended technique ?)

- it lets committee members play with the new feature (sometimes
  running code is more fun that just printing it and saying: it
  does what I want)

Gievn what I said in the beginnign of the message, in
which direction would it be a major step forward ?

> Of course, you next get the interesting question of whether the standard
> must then supercede that reference compiler in the case of
> differences -- is it a bug in the compiler or a defect in the standard?

For some people, a reference implementation is a standard.
Whatever is does is The Truth. If it crash, that it really
is undefined behaviour. (This one is fine.) The reciprocical
holds, too. Well, given what I said at the beginning about
infinite sets, the reciprocical makes no sens.

So ``reference implementation'' (with the above definition)
*does* *not* *make* *sens*.

If you want to use this term, you'll have to give it a new
meaning.

  -- VB

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]