On Wed, 17 Nov 2004 18:25:29 +0000, kanz wrote:


>> Defect ?
>
> Probably.  For two reasons:
>
>   - The first is the one you clearly raise.  Which can be very subtle:
>     suppose I open a filebuf, and write three characters to it.  Is this
>     observable behavior?  I don't think so --

The fact that some observables aren't always going to produce
visible evidence doesn't make this a defect.

I think it is the other way around. The point is that
if you add one to a variable, and examine it with a debugger
and find it hasn't changed .. is the compiler conforming?

You can't say because adding values to a (non-volatile) variable
is not *allowed* as an observable.

[Maybe the compiler doesn't bother adding 1 to the
variable because it knows the variable isn't used ..]

So if a conformance tester sees output that indicates
a compiler is non-conforming, they can form a judgement.

What if they don't? Then they will just have to say

"We are unable to test this compiler"

The fact is that people will see 'passed 10,000
rigorous conformance checks' as meaning
'this compiler is probably OK!'.

So I don't think it's a defect: to be a defect it
would have to prevent the above scenario...
we can judge *quality* from the successful failure
of a compiler to be caught out by conformance tests.. :)


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

""John Max Skaller"" <skaller@nospam.com.au> schrieb im Newsbeitrag
news:pan.2004.11.17.00.53.33.847631@nospam.com.au...
> On Tue, 16 Nov 2004 19:57:02 +0000, Thomas Mang wrote:
>
> >
> > int main()
> > {
> > std::ostringstream OStream;
> > OStream << "Hello, World";
> > }
> >
> >
> > Is this considered to be observable behaviour or not?
> > I mean there happens output, doesn't it? But can we observe it?
>
> There's no output, it's writing into memory, right?


Well, unfortunately I chose a namespace-scope operator<< where the Standard
does not comment at much.

But take "OStream << 67;" as example.
By reading 27.6.2, this involves an output (maybe flush it, as James Kanze
noted). [I think the operator<< taking the char const* also involves output.
But the wording concerning the member functions is clearer.]


> So, the above program is of no use to a conformance tester --
> unless it actually does do some output (which would show the
> compiler is non-conforming).


It does output. Still I don't know how a conformance tester can evaluate it.


>
> > But frankly, this behaviour is described in somewhat wishy-washy-style.
IMHO
> > clarification is needed.
>
> Yes, I'd a agree it's somewhat wishy-washy. There are two reasons
> for this I think:
>
> (a) It's dang hard to describe the highest level abstraction,>
> (b) The Standard is written in English:

It is a problem, although quite philosophical (What is English? What does
"This is a machine" mean? [Focus not only on the word 'machine', focus also
on the meaning/exact definition of the other three words]. Playing this
further, I am sure it's impossible to define anything clearly without some
preassumptions).


But I didn't mean this.

I meant precisely 1.9/6


Thomas


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

<kanze@gabi-soft.fr> schrieb im Newsbeitrag
news:d6652001.0411170937.ba83d35@posting.google.com...
> nospam@nospam.ucar.edu ("Thomas Mang") wrote in message
> news:<419a49c0$0$31502$3b214f66@usenet.univie.ac.at>...
> > <kanze@gabi-soft.fr> schrieb im Newsbeitrag
> > news:d6652001.0411160522.e868bac@posting.google.com...
> > > nospam@nospam.ucar.edu ("Thomas Mang") wrote in message
> > > news:<41976b5e$0$11872$3b214f66@usenet.univie.ac.at>...
>
> > > > Standard says in 1.9/2:
> > > > "The observable behavior of the abstract machine is its sequence
> > > > of reads and writes to volatile data and calls to library I/O
> > > > functions."
>
> > > > But what exactly is a libary I/O function?
>
> > > > Calling any function described in clause 27?
>
> > > Presumably.  Or maybe any non-const function.  Or maybe just the
> > > functions described as doing input or output.  Who knows?
>
> > Defect ?
>
> Probably.  For two reasons:

OK, agreed.

Who takes it over?


>
>   - John Skaller's posting mentionned assert.  This brings up another
>     important aspect which seems to be forgotten -- I would hope that
>     terminate, exit et al. are also observable behavior.


Maybe they should. Don't know. The people in the committee shall decide it.


Thomas


>


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

""John Max Skaller"" <skaller@nospam.com.au> schrieb im Newsbeitrag
news:pan.2004.11.17.01.34.34.490059@nospam.com.au...
> On Tue, 16 Nov 2004 19:56:51 +0000, Thomas Mang wrote:
>
> >>
> >> Presumably.  Or maybe any non-const function.  Or maybe just the
> >> functions described as doing input or output.  Who knows?
> >
> > Defect ?
>
> Just as there is an 'as if' rule for ordinary rules
> in the Standard, there is an 'as if' rule for
> conformance modelling.
>
> There are some functions that clearly generate output,
> such as printf(), and cout << .., and these can be
> taken to define program behaviour.
>
> This allows a conformance tester to say 'when I feed
> X into this program, the output is Y, and I judge
> that output to be wrong, so compiler CXX is not
> conformaning'.
>
> So, the exact meaning of behviour is not needed,
> what's needed is enough description of the intent
> to allow a single word 'behaviour' to be used
> in the main body of the standard to facilitate
> brevity whilst still allowing the rules to be
> checked by a conformance tester.
>
> There's more though: it isn't enough for a single
> tester to be able to validate a compiler, it should
> be possible for another tester to repeat the experiment.
>
> So I'd say there is a defect in the conformance model
> if and only if it isn't clear enough to actually permit
> repeatable and reliable conformance testing.
>
> Note that 'conformance tester' doesn't mean just
> a company that validates compilers -- it includes
> all C++ programmers. When you report a bug in your
> compiler, you're wearing a conformance tester hat:
>
> "CXX does not parse YYY correctly, here's a simplified
> example to add to the bug tracker"
>
> Well, diagnostic error messages are also output,
> and issuing them is observable behaviour of the translator,
> and rather easily you can also observe the failure
> of a translator to issue a diagnostic when it should.
>
> But there is no call to an I/O function of the library
> here. Nor does C++ rigidly separate the time
> of compilation from execution (the phases of
> translation are 'as if' .. :)
>
> So there may be a defect in this area.
> Also 'main' returns an observable value,
> so that should be counted as behaviour,
> if it isn't, that's definitely a defect.
>
> However there probably isn't one in respect
> of the imprecision in specifying which functions
> constitute I/O, because what actually matters is
> the pragmatic measurement of behaviour by printing output.
>
> In your 'strstream' example --- it doesn't matter,
> whether the write to memory is behaviour or not,
> the program doesn't do anything useful which can
> be measured, so there are no consequences, whether
> the I/O is 'behaviour' or not.


What you have written is nice, but still I don't see the point.

IMHO, Standard does not clearly say what observable behaviour is, because in
its definition it uses unclear terms. So everything else is guessing.


>
> Here's an example that does matter:
>
> #include <iostream>
> int main() { cout << 1/0 << endl; }
>
> What do you predict? A compiler diagnostic,
> a run time error, or 'undefined'? What about:

undefined behaviour


>
> int main() {
>   int y = 0;
>   cout << y/y << endl;
> }


Undefined behaviour


>
> Is the compiler entitled to reject the first program?
> What about the second? HOw about if the RHS of the
> initialisation of y is a complicated expression?
>
> I think the right thing as a QOI issue is to
> issue a diagnostic whenever a potential error is
> found .. and in this case:
>
> int a[1/0];
>
> the compiler must reject the program because there's
> a divide by zero in a constant expression .. but
> wait! What if 'a' is not used in the program??

Still undefined behaviour (is there anything overruling 5.6/4 ?)

Quality of implementation is IMHO important for users, but not for the
Standard.


Thomas




---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <419ba5b0$0$8024$3b214f66@usenet.univie.ac.at>, Thomas Mang
<nospam@nospam.ucar.edu> writes
>>   - John Skaller's posting mentionned assert.  This brings up another
>>     important aspect which seems to be forgotten -- I would hope that
>>     terminate, exit et al. are also observable behavior.
>
>
>Maybe they should. Don't know. The people in the committee shall decide it.

Think very carefully. Anytime you can tell that something happened
because the output is different you have observable behaviour. However
if there are two possible places at which a program could exit and no
observable behaviour occurs between them then you cannot tell which one
was used in order to exit the program.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

nospam@nospam.ucar.edu ("Thomas Mang") wrote in message
news:<419ba5b0$0$8024$3b214f66@usenet.univie.ac.at>...
> <kanze@gabi-soft.fr> schrieb im Newsbeitrag
> news:d6652001.0411170937.ba83d35@posting.google.com...
> > nospam@nospam.ucar.edu ("Thomas Mang") wrote in message
> > news:<419a49c0$0$31502$3b214f66@usenet.univie.ac.at>...
> > > <kanze@gabi-soft.fr> schrieb im Newsbeitrag
> > > news:d6652001.0411160522.e868bac@posting.google.com...
> > > > nospam@nospam.ucar.edu ("Thomas Mang") wrote in message
> > > > news:<41976b5e$0$11872$3b214f66@usenet.univie.ac.at>...

> > > > > Standard says in 1.9/2:
> > > > > "The observable behavior of the abstract machine is its
> > > > > sequence of reads and writes to volatile data and calls to
> > > > > library I/O functions."

> > > > > But what exactly is a libary I/O function?

> > > > > Calling any function described in clause 27?

> > > > Presumably.  Or maybe any non-const function.  Or maybe just the
> > > > functions described as doing input or output.  Who knows?

> > > Defect ?

> > Probably.  For two reasons:

> OK, agreed.

> Who takes it over?

The committee.  Neither you nor I have the right to correct anything.  I
suppose that you could write up a formal defect report if you wanted; I
don't know if it will help, but it certainly couldn't hurt.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <419a4ca5$0$8024$3b214f66@usenet.univie.ac.at>,
 nospam@pop.ucsd.edu ("Thomas Mang") wrote:

> The whole Standard exists to define C++, and this in turn boils down to more
> or less the observable behaviour of the abstract machine.
> But frankly, this behaviour is described in somewhat wishy-washy-style. IMHO
> clarification is needed.

Eventually a standard has to resort to some generally-accepted knowledge
about computing -- it's not feasible for it to define everything
completely and unambiguously in terms of basic principles.  Even if the
standard were written in the form of a computer program, rather than
English prose, it would depend on understanding the language that this
program is written in, and the behavior of the computer upon which that
program is run.

Furthermore, the standard needs to allow leeway for optimizers and
extensions.  The clause that says that only I/O functions contribute to
observable behavior is what allows implementations to do constant
folding at compile time, or perform flow analysis to optimize away
computations that don't contribute to the output.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis@robinton.demon.co.uk> schrieb im Newsbeitrag
news:UIoacxCX0+mBFwtG@robinton.demon.co.uk...
> In article <419ba5b0$0$8024$3b214f66@usenet.univie.ac.at>, Thomas Mang
> <nospam@nospam.ucar.edu> writes
> >>   - John Skaller's posting mentionned assert.  This brings up another
> >>     important aspect which seems to be forgotten -- I would hope that
> >>     terminate, exit et al. are also observable behavior.
> >
> >
> >Maybe they should. Don't know. The people in the committee shall decide
it.
>
> Think very carefully. Anytime you can tell that something happened
> because the output is different you have observable behaviour. However
> if there are two possible places at which a program could exit and no
> observable behaviour occurs between them then you cannot tell which one
> was used in order to exit the program.

Francis,

I tried to think carefully. What you have written is clearly true for the
current wording of the Standard (lets forget what 'output' is). If I
understand James Kanze and John Max Scaller correctly (which I am well not
sure about), they meant that exiting the program should be considered to be
observable behaviour too.

Take these two snippets for example:

int main()
{
std::exit(0);
};


int main()
{
while(1);
}


No volatile data involved, no I/O. Does it mean these 2 are equivalent
regarding observable behaviour?


What about the return-value from main? Would you like to be this observable
behaviour or not?


Thomas



---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <41a065d7$0$25116$3b214f66@usenet.univie.ac.at>, Thomas Mang
<nospam@nospam.ucar.edu> writes
>I tried to think carefully. What you have written is clearly true for the
>current wording of the Standard (lets forget what 'output' is). If I
>understand James Kanze and John Max Scaller correctly (which I am well not
>sure about), they meant that exiting the program should be considered to be
>observable behaviour too.

That is an interesting comment.
>
>Take these two snippets for example:
>
>int main()
>{
>std::exit(0);
>};
>
>
>int main()
>{
>while(1);
>}
>
>
>No volatile data involved, no I/O. Does it mean these 2 are equivalent
>regarding observable behaviour?

As you correctly suggest below, the only observable difference between
those programs is their behaviour on program termination The first
returns 0 and the second does not even if forcibly ended). However how
does the user tell the difference between the second one and the first
one running at extremely low priority on a multi-tasking system that
never gets a time slice after program start-up?
>
>
>What about the return-value from main? Would you like to be this observable
>behaviour or not?

I think it should be. Note that we have to clearly distinguish between
the observable behaviour provided by the program on the abstract machine
(and I think that is what distinguishes your two programs above) and
that provided by real hardware (where the above programs could appear to
behave identically).
>

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis@robinton.demon.co.uk> schrieb im Newsbeitrag
news:XqR6EHBLKcoBFw+y@robinton.demon.co.uk...
> In article <41a065d7$0$25116$3b214f66@usenet.univie.ac.at>, Thomas Mang
> <nospam@nospam.ucar.edu> writes
> >I tried to think carefully. What you have written is clearly true for the
> >current wording of the Standard (lets forget what 'output' is). If I
> >understand James Kanze and John Max Scaller correctly (which I am well
not
> >sure about), they meant that exiting the program should be considered to
be
> >observable behaviour too.
>
> That is an interesting comment.
> >
> >Take these two snippets for example:
> >
> >int main()
> >{
> >std::exit(0);
> >};
> >
> >
> >int main()
> >{
> >while(1);
> >}
> >
> >
> >No volatile data involved, no I/O. Does it mean these 2 are equivalent
> >regarding observable behaviour?
>
> As you correctly suggest below, the only observable difference between
> those programs is their behaviour on program termination The first
> returns 0 and the second does not even if forcibly ended). However how
> does the user tell the difference between the second one and the first
> one running at extremely low priority on a multi-tasking system that
> never gets a time slice after program start-up?
> >
> >
> >What about the return-value from main? Would you like to be this
observable
> >behaviour or not?
>
> I think it should be. Note that we have to clearly distinguish between
> the observable behaviour provided by the program on the abstract machine
> (and I think that is what distinguishes your two programs above) and
> that provided by real hardware (where the above programs could appear to
> behave identically).

Thanks for your comments.

I definitely think it's time for a Defect :-)
I'll write one whenever I have the ressources for it, but hopefully quite
soon.

Anybody providing further suggestion regarding this issue?


Thomas


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hello,


Standard says in 1.9/2:
"The observable behavior of the abstract machine is its sequence of reads
and writes to volatile data and calls to library I/O functions."


But what exactly is a libary I/O function?


Calling any function described in clause 27?

What about the input/output functionality provided by C-headers (<cstdio>)?


Thomas



---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

nospam@nospam.ucar.edu ("Thomas Mang") wrote in message
news:<41976b5e$0$11872$3b214f66@usenet.univie.ac.at>...

> Standard says in 1.9/2:
> "The observable behavior of the abstract machine is its sequence of reads
> and writes to volatile data and calls to library I/O functions."

> But what exactly is a libary I/O function?

> Calling any function described in clause 27?

Presumably.  Or maybe any non-const function.  Or maybe just the
functions described as doing input or output.  Who knows?

> What about the input/output functionality provided by C-headers
> (<cstdio>)?

They're described indirectly (by reference to the C standard) in clause
27.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 15 Nov 2004 17:14:33 +0000, Thomas Mang wrote:

> Standard says in 1.9/2:
> "The observable behavior of the abstract machine is its sequence of reads
> and writes to volatile data and calls to library I/O functions."

> But what exactly is a libary I/O function?

Any call which causes either input or output .. probably
these should be listed. Modifying volatile is counted,
in case a validator can use a memory mapped I/O port
for measurement.

> Calling any function described in clause 27?

No. Only functions which actually either generate output,
or read input. Note this includes in particular the assert()
macro.

> What about the input/output functionality provided by C-headers (<cstdio>)?

Yes.

The idea is this: the Standard cannot specify requirements
in any other terms that observables. If you can't measure
the effects of a clause, the clause is automatically non-normative,
which is a polite way of saying 'rubbish'.

This does not mean requirements, such as, for example,
the rules of addition or complexity of an algorithm,
or the value returned by a mathematical function,
are not normative because the result cannot be measured
directly. What it means is that if, as a result of the
measurement of an observable, it can be established
that the requirement could not have been met, then
the compiler isn't conforming.

So technically, the 'rules' for addition or algorithmic
complexity are NOT normative requirements per se,
but rather 'as if' rules by which a validator can
set up an experiment and use the rules to predict an
observable outcome. However, they're often considered
normative requirements because they have behavioural
consequences, even if they have no behaviour themselves.

For example, calling 'sin(x)' has no behaviour, it isn't
observable, so you can't have a normative rule specifying
the result -- but you can certainly measure the behaviour of
cout << sin(x) ..

Of course, you can't tell what value sin(x) *actually* produces,
not ever. But it matters not -- what counts is what gets printed.

For example it is perfectly possible that 'sin(x)' simply creates
a closure and calculates nothing .. and the output method <<
actually does the evaluation. There's no way to find out,
and this is as it should be. Who cares, as long as the right
answer is printed?


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

""John Max Skaller"" <skaller@nospam.com.au> schrieb im Newsbeitrag
news:pan.2004.11.16.14.10.45.568934@nospam.com.au...
> On Mon, 15 Nov 2004 17:14:33 +0000, Thomas Mang wrote:
>
> > Standard says in 1.9/2:
> > "The observable behavior of the abstract machine is its sequence of
reads
> > and writes to volatile data and calls to library I/O functions."
>
> > But what exactly is a libary I/O function?
>
> Any call which causes either input or output .. probably
> these should be listed. Modifying volatile is counted,
> in case a validator can use a memory mapped I/O port
> for measurement.
>
> > Calling any function described in clause 27?
>
> No. Only functions which actually either generate output,
> or read input. Note this includes in particular the assert()
> macro.


Hmm.

What about this code snippet:

#include <sstream>
#include <ostream>


int main()
{
std::ostringstream OStream;
OStream << "Hello, World";
}


Is this considered to be observable behaviour or not?
I mean there happens output, doesn't it? But can we observe it?


The point is quite interesting:

The whole Standard exists to define C++, and this in turn boils down to more
or less the observable behaviour of the abstract machine.
But frankly, this behaviour is described in somewhat wishy-washy-style. IMHO
clarification is needed.


Thomas


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

<kanze@gabi-soft.fr> schrieb im Newsbeitrag
news:d6652001.0411160522.e868bac@posting.google.com...
> nospam@nospam.ucar.edu ("Thomas Mang") wrote in message
> news:<41976b5e$0$11872$3b214f66@usenet.univie.ac.at>...
>
> > Standard says in 1.9/2:
> > "The observable behavior of the abstract machine is its sequence of
reads
> > and writes to volatile data and calls to library I/O functions."
>
> > But what exactly is a libary I/O function?
>
> > Calling any function described in clause 27?
>
> Presumably.  Or maybe any non-const function.  Or maybe just the
> functions described as doing input or output.  Who knows?


Defect ?


Thomas


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

nospam@nospam.ucar.edu ("Thomas Mang") wrote in message
news:<419a49c0$0$31502$3b214f66@usenet.univie.ac.at>...
> <kanze@gabi-soft.fr> schrieb im Newsbeitrag
> news:d6652001.0411160522.e868bac@posting.google.com...
> > nospam@nospam.ucar.edu ("Thomas Mang") wrote in message
> > news:<41976b5e$0$11872$3b214f66@usenet.univie.ac.at>...

> > > Standard says in 1.9/2:
> > > "The observable behavior of the abstract machine is its sequence
> > > of reads and writes to volatile data and calls to library I/O
> > > functions."

> > > But what exactly is a libary I/O function?

> > > Calling any function described in clause 27?

> > Presumably.  Or maybe any non-const function.  Or maybe just the
> > functions described as doing input or output.  Who knows?

> Defect ?

Probably.  For two reasons:

  - The first is the one you clearly raise.  Which can be very subtle:
    suppose I open a filebuf, and write three characters to it.  Is this
    observable behavior?  I don't think so -- in the absense of a flush,
    I can't observe it, and it is certainly the intent of the standard
    to allow bufferization, and that the actual write to the file system
    occur after an access to a volatile variable which occurs between
    the write and the flush.

    Offhand, about the only functions I'd expect to involve observable
    behavior here are basic_filebuf::open, basic_filebuf::close
    basic_filebuf::sync, remove, rename, fopen, freopen, fclose, and
    fflush.  But you would have to be careful about the wording, because
    the ordering of observable behavior is visible, and of course,
    basic_streambuf::sputc should be allowed to trigger an otherwise
    invisible call to basic_filebuf::flush (or some equivalent) if the
    derived class is actually a basic_filebuf.

  - John Skaller's posting mentionned assert.  This brings up another
    important aspect which seems to be forgotten -- I would hope that
    terminate, exit et al. are also observable behavior.

--
James Kanze           GABI Software         http://www.gabi-soft.fr
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 16 Nov 2004 19:57:02 +0000, Thomas Mang wrote:

>
> int main()
> {
> std::ostringstream OStream;
> OStream << "Hello, World";
> }
>
>
> Is this considered to be observable behaviour or not?
> I mean there happens output, doesn't it? But can we observe it?

There's no output, it's writing into memory, right?
So, the above program is of no use to a conformance tester --
unless it actually does do some output (which would show the
compiler is non-conforming).

>
> The point is quite interesting:
>
> The whole Standard exists to define C++, and this in turn boils down to more
> or less the observable behaviour of the abstract machine.

Technically, the C++ Standard defines C++ translators, not
the C++ language. In fact this was a major editorial problem --
the text was lifted from Stroustrup's ARM originally,
and it describes the language, addressing programmers, but it
needed to describe compilers, and address conformance testers.

The legacy of using the ARM as a base document is still
evident: there's some front matter that tries to say
'when the Standard says X it really means Y' to get
around this without the editor needing to rewrite the
whole thing. The problem with a rewrite is just as in
software -- not so much the huge effort involved,
but that in doing so the semantics might be changed,
and votes taken by WG21 no longer properly reflected
in the text.

> But frankly, this behaviour is described in somewhat wishy-washy-style. IMHO
> clarification is needed.

Yes, I'd a agree it's somewhat wishy-washy. There are two reasons
for this I think:

(a) It's dang hard to describe the highest level abstraction,
without a terminological framework. To some extent, this
is a problem for ISO/IEC SC22 to address, rather than WG21.

There are standards for standards. The most well known is
probably LIA (Language Inependent Arithmetic) which allows
other standards like C++ to specify numerical semantics
within a terminological framework. Another is ISO10646
for character sets.

Of course reference to other standards also creates
issues itself -- for C++ reference to the C Standard
is the most obvious example (there's an Appendix
listing detail issues, but there are some interesting
conformance issues, since C doesn't use the same
conformance model as C++).

(b) The Standard is written in English: natural language isn't
very good for describing formalisms, and English is particularly
bad in many respects: there's lots of ambiguity -- which is great
for writing poetry :)

The decision was taken to use natural language, not a
mathematical formalism. I personally would have liked
to see a bit more use of formalisms: mathematics,
the grammar, and perhaps the most important, C++ itself.

[Some of the simpler library components could just have
been specified with a few lines of C++ template 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 16 Nov 2004 19:56:51 +0000, Thomas Mang wrote:

>>
>> Presumably.  Or maybe any non-const function.  Or maybe just the
>> functions described as doing input or output.  Who knows?
>
> Defect ?

Just as there is an 'as if' rule for ordinary rules
in the Standard, there is an 'as if' rule for
conformance modelling.

There are some functions that clearly generate output,
such as printf(), and cout << .., and these can be
taken to define program behaviour.

This allows a conformance tester to say 'when I feed
X into this program, the output is Y, and I judge
that output to be wrong, so compiler CXX is not
conformaning'.

So, the exact meaning of behviour is not needed,
what's needed is enough description of the intent
to allow a single word 'behaviour' to be used
in the main body of the standard to facilitate
brevity whilst still allowing the rules to be
checked by a conformance tester.

There's more though: it isn't enough for a single
tester to be able to validate a compiler, it should
be possible for another tester to repeat the experiment.

So I'd say there is a defect in the conformance model
if and only if it isn't clear enough to actually permit
repeatable and reliable conformance testing.

Note that 'conformance tester' doesn't mean just
a company that validates compilers -- it includes
all C++ programmers. When you report a bug in your
compiler, you're wearing a conformance tester hat:

"CXX does not parse YYY correctly, here's a simplified
example to add to the bug tracker"

Well, diagnostic error messages are also output,
and issuing them is observable behaviour of the translator,
and rather easily you can also observe the failure
of a translator to issue a diagnostic when it should.

But there is no call to an I/O function of the library
here. Nor does C++ rigidly separate the time
of compilation from execution (the phases of
translation are 'as if' .. :)

So there may be a defect in this area.
Also 'main' returns an observable value,
so that should be counted as behaviour,
if it isn't, that's definitely a defect.

However there probably isn't one in respect
of the imprecision in specifying which functions
constitute I/O, because what actually matters is
the pragmatic measurement of behaviour by printing output.

In your 'strstream' example --- it doesn't matter,
whether the write to memory is behaviour or not,
the program doesn't do anything useful which can
be measured, so there are no consequences, whether
the I/O is 'behaviour' or not.

Here's an example that does matter:

#include <iostream>
int main() { cout << 1/0 << endl; }

What do you predict? A compiler diagnostic,
a run time error, or 'undefined'? What about:

int main() {
  int y = 0;
  cout << y/y << endl;
}

Is the compiler entitled to reject the first program?
What about the second? HOw about if the RHS of the
initialisation of y is a complicated expression?

I think the right thing as a QOI issue is to
issue a diagnostic whenever a potential error is
found .. and in this case:

 int a[1/0];

the compiler must reject the program because there's
a divide by zero in a constant expression .. but
wait! What if 'a' is not used in the program??

[Example just to illustrate how dang hard it is
to specify exactly what should be mandated]

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]