In article <86ya28n6le.fsf@gabi-soft.de>, kanze@gabi-soft.de writes
>|>  No (but actually within the EU conformance certifications are trans-
>|>  national) but where-ever you elect to get your product certified you
>|>  will (or should be) required to demonstrate that your implementation
>|>  defined behaviour has been defined in a language appropriate to the NB
>|>  providing the certification.
>
>So my French compiler is conformant if I buy it in France, but not if I
>buy it in GB?

That is exactly NOT the meaning of the quoted paragraph. Unless BSI
elects to issue its own National Standard for X, then an AFNOR certified
X is deemed (legally) to be so certified in the UK.

Francis Glassborow      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              ]

Francis Glassborow <francis@robinton.demon.co.uk> writes:

|>  I think we will just have to disagree. I know that BSI would not
|>  certify a product as conforming to a standard if required
|>  documentation were only available in Chinese, Arabic and
|>  Russian. The only thing that matters about a standard is that part
|>  which is legally enforceable, the rest is just pious wishful
|>  thinking:)

That's fine for the BSI -- your local language is a dialect of English,
I believe.  Most other standards organizations don't certify, but if
they did: AFNOR would require French, DIN German, etc.  Which also puts
an unreasonable burden on the implementors -- there are several thousand
legally recognized languages in the world.

Put another way: suppose I develop a compiler in France, with the
documentation in French.  You buy it on a trip to France.  You take it
back to England.  Does the compiler cease to be conforming somewhere
when crossing the Channel?

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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 <864s4zx3s0.fsf@gabi-soft.de>, kanze@gabi-soft.de writes
>Put another way: suppose I develop a compiler in France, with the
>documentation in French.  You buy it on a trip to France.  You take it
>back to England.  Does the compiler cease to be conforming somewhere
>when crossing the Channel?

No (but actually within the EU conformance certifications are trans-
national) but where-ever you elect to get your product certified you
will (or should be) required to demonstrate that your implementation
defined behaviour has been defined in a language appropriate to the NB
providing the certification.

Actually many ISO Standards become National Standards and your French
documented version would be ISO conforming but, I suspect, would fail to
be conforming to the equivalent UK Standard (and visa versa for AFNOR).

Some, even most, of this is QoI but some is a legal contract in at least
some countries. I wonder how an American court would rule on a trade
claim that X was ANSI C++ if all the documentation was in Hebrew.



Francis Glassborow      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              ]

Francis Glassborow wrote:
....
> Some, even most, of this is QoI but some is a legal contract in at least
> some countries. I wonder how an American court would rule on a trade
> claim that X was ANSI C++ if all the documentation was in Hebrew.

I can't say for sure; but if it was marketed exclusively to the
Hebrew-speaking community in the US, I'd be very upset if they ran into
trouble on that basis. There are laws requiring that various things be
written on the package, including for example the copyright notice.
Those required things are definitely required to be in English. However,
I doubt there's relevant law requiring that the documentation be in
English.

There are cities in the US where laws have been passed requiring that a
commercial establishment's name be displayed in English. The nominal
excuse for these requirements is to aid in the dispatch of emergency
vehicles. These laws have survived court challenges, but are not
widespread. Such laws are felt by many people here to be unfair and
inspired more by nationalistic bigotry than by their nominal safety
concerns. It may be that attitudes are different in countries where
recent immigrants form a much smaller portion of the population.

---
[ 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 Glassborow <francis@robinton.demon.co.uk> writes:

|>  In article <864s4zx3s0.fsf@gabi-soft.de>, kanze@gabi-soft.de writes
|>  >Put another way: suppose I develop a compiler in France, with the
|>  >documentation in French.  You buy it on a trip to France.  You take =
it
|>  >back to England.  Does the compiler cease to be conforming somewhere
|>  >when crossing the Channel?

|>  No (but actually within the EU conformance certifications are trans-
|>  national) but where-ever you elect to get your product certified you
|>  will (or should be) required to demonstrate that your implementation
|>  defined behaviour has been defined in a language appropriate to the N=
B
|>  providing the certification.

So my French compiler is conformant if I buy it in France, but not if I
buy it in GB?

|>  Actually many ISO Standards become National Standards and your
|>  French documented version would be ISO conforming but, I suspect,
|>  would fail to be conforming to the equivalent UK Standard (and visa
|>  versa for AFNOR).

|>  Some, even most, of this is QoI but some is a legal contract in at
|>  least some countries. I wonder how an American court would rule on a
|>  trade claim that X was ANSI C++ if all the documentation was in
|>  Hebrew.

I would hope that it would be the same as that of a French court in
France if all the documentation were in English.  As long as it was
specified at the moment of purchace, where's the problem.  If you don't
want French documentation, buy a different compiler.  (And feel happy
that you probably have the choice of one in your native language.  I'm
willing to bet that speakers of Swahili or Estonian don't have that
choice.)

In no case, however, do I think that the language the documentation is
written in affects conformance.

--=20
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ 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 <39764B7C.76F7899B@wizard.net>, James Kuyper
<kuyper@wizard.net> writes
>The legal system might derive such requirements from other principles,
>such as the idea that anything put up for sale is implicitly being
>claimed to be worth buying. However, it's not in the words of the
>standard itself, not even by implication. Nothing in the standard
>prevents, for instance, an implementation from providing documentation
>in French, and selling the compiler to a user whose only language is
>Chinese. Such documentation is absolutely useless to that particular
>user, but that doesn't prevent it from being a conforming
>implementation.

I think we will just have to disagree. I know that BSI would not certify
a product as conforming to a standard if required documentation were
only available in Chinese, Arabic and Russian. The only thing that
matters about a standard is that part which is legally enforceable, the
rest is just pious wishful thinking:)


Francis Glassborow      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              ]

In article <3973B30D.999EACC3@wizard.net>, James Kuyper
<kuyper@wizard.net> writes
>The only relevant text I could find says only that
>implementation-defined behavior is "behavior ... that each
>implementation shall document." There's a similar comment about
>locale-specific behavior. There's nothing there (or anywhere else that I
>looked) about the appropriateness or comprehensibility of the
>documentation.

I think those words are sufficient, and I guess that the legal systems
of most countries would interpret that at least to the extent that an
intelligent customer with the requisite technical expertise should be
able to understand the documentation. Certain things are always
extraneous to any documents and, certainly in the UK, the burden of
proof would lie with the vendor to show that adequate documentation had
been provided.


Francis Glassborow      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              ]

Francis Glassborow wrote:
>
> In article <3973B30D.999EACC3@wizard.net>, James Kuyper
> <kuyper@wizard.net> writes
> >The only relevant text I could find says only that
> >implementation-defined behavior is "behavior ... that each
> >implementation shall document." There's a similar comment about
> >locale-specific behavior. There's nothing there (or anywhere else that I
> >looked) about the appropriateness or comprehensibility of the
> >documentation.
>
> I think those words are sufficient, and I guess that the legal systems
> of most countries would interpret that at least to the extent that an
> intelligent customer with the requisite technical expertise should be
> able to understand the documentation. Certain things are always

The legal system might derive such requirements from other principles,
such as the idea that anything put up for sale is implicitly being
claimed to be worth buying. However, it's not in the words of the
standard itself, not even by implication. Nothing in the standard
prevents, for instance, an implementation from providing documentation
in French, and selling the compiler to a user whose only language is
Chinese. Such documentation is absolutely useless to that particular
user, but that doesn't prevent it from being a conforming
implementation.

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

David Abrahams wrote:
....
> So, it seems that an implementation is allowed to throw bad_alloc, but is
> required to document it. I think this is a huge burden on implementors when
> spread across all functions in the library, and probably not worth it. In
> this regard I doubt there is an existing implementation which comes close to
> conforming.

You overestimate the standard's requirements. It says nothing about the
level of detail required in the documentation. There's not even a
requirement that the documentation be presented in any language anyone
understands (including the people who wrote it). A global statement that
"Any standard library function that is allowed by the standard to throw
std::bad_alloc, may throw std::bad_alloc under some circumstances" would
meet that requirement. That's perfectly legal even if most of the
functions it refers to happen to be written so they CAN NOT throw
bad_alloc. Quality, detail, and usefulness of documentation is a QoI
issue, not a confomance one.

---
[ 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 <39729AFE.1AA6447D@wizard.net>, James Kuyper
<kuyper@wizard.net> writes
>You overestimate the standard's requirements. It says nothing about the
>level of detail required in the documentation. There's not even a
>requirement that the documentation be presented in any language anyone
>understands (including the people who wrote it).

I disagree, there is a requirement that implementation defined behaviour
be appropriately documented and I think that requires that it be done so
in such a way that it is comprehensible to normal purchasers.


Francis Glassborow      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              ]

David Abrahams wrote:
>
> 17.4.4.8/p3 states:
> No destructor operation defined in the C++ Standard Library will throw an
> exception. Any other functions defined in the C++ Standard Library that do
> not have an exception-specification may throw implementation-defined
> exceptions unless otherwise specified.178)
> <snip>
> 178) In particular, they can report a failure to allocate storage by
> throwing an exception of type bad_alloc, or a class derived from bad_alloc
> (18.4.2.1)...
>
> So, it seems that an implementation is allowed to throw bad_alloc, but is
> required to document it.

I think the first paragraph can have two different meanings. It is not
clear to me weither "implementation-defined" refer to the "throw" or the
"exceptions". That is, does the sentence mean:

"Any other functions defined in the C++ Standard Library that do not
have an exception-specification may *have an implementation-defined
exceptions specification* unless otherwise specified."

Or

"Any other functions defined in the C++ Standard Library that do not
have an exception-specification may throw exceptions*, which can be*
implementation-defined exceptions, unless otherwise specified."

If the former case, then implementors must define which exceptions get
thrown by each function. In the latter case, implementors must define
the exception types they derive from standard ones, but not which
functions throw them.

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

Pierre Baillargeon wrote:
>
> David Abrahams wrote:
> >
> > 17.4.4.8/p3 states:
> > No destructor operation defined in the C++ Standard Library will throw an
> > exception. Any other functions defined in the C++ Standard Library that do
> > not have an exception-specification may throw implementation-defined
> > exceptions unless otherwise specified.178)
> > <snip>
> > 178) In particular, they can report a failure to allocate storage by
> > throwing an exception of type bad_alloc, or a class derived from bad_alloc
> > (18.4.2.1)...
> >
> > So, it seems that an implementation is allowed to throw bad_alloc, but is
> > required to document it.
>
> I think the first paragraph can have two different meanings. It is not
> clear to me weither "implementation-defined" refer to the "throw" or the
> "exceptions". That is, does the sentence mean:
>
> "Any other functions defined in the C++ Standard Library that do not
> have an exception-specification may *have an implementation-defined
> exceptions specification* unless otherwise specified."

That interpretation is internally inconsistent. You can't say "do not
have an exception-specification" and "have an .. exception
specification" about the same functions.

> Or
>
> "Any other functions defined in the C++ Standard Library that do not
> have an exception-specification may throw exceptions*, which can be*
> implementation-defined exceptions, unless otherwise specified."

This is close to what I believe it means, except I would replace "can
be" with "must be". Note that this doesn't mean that the exception must
be defined by the implementation, it could be a standard-defined
implementation like std::bad_alloc. What must be implementation-defined
is the fact that this particular exception can be be thrown by this
particular function.

> If the former case, then implementors must define which exceptions get
> thrown by each function. In the latter case, implementors must define
> the exception types they derive from standard ones, but not which
> functions throw them.

You're mixing up exceptions specifications with documentation of which
exceptions can be thrown. Those are two entirely different things. The
documentation can be somewhere other than the exception specification.

---
[ 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 Glassborow wrote:
>
> In article <39729AFE.1AA6447D@wizard.net>, James Kuyper
> <kuyper@wizard.net> writes
> >You overestimate the standard's requirements. It says nothing about the
> >level of detail required in the documentation. There's not even a
> >requirement that the documentation be presented in any language anyone
> >understands (including the people who wrote it).
>
> I disagree, there is a requirement that implementation defined behaviour
> be appropriately documented and I think that requires that it be done so
> in such a way that it is comprehensible to normal purchasers.

Citation, please?

The only relevant text I could find says only that
implementation-defined behavior is "behavior ... that each
implementation shall document." There's a similar comment about
locale-specific behavior. There's nothing there (or anywhere else that I
looked) about the appropriateness or comprehensibility of the
documentation.

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

Which exceptions can be thrown from operator+(const string&, const
string&) - or

   template<class charT, class traits, class Allocator>
   basic_string<charT,traits,Allocator>
   operator+(const basic_string<charT,traits,Allocator>& lhs, const
basic_string<charT,traits,Allocator>& rhs);

?

When I read    21.3.7.1 I see no exception specification - which according to
   15.4, p11 means that it allows any exception.

When I read the semantic of the operator+, I think that it can thow the same
exceptions as:
  The copy constructor for basic_string (   21.3.1, p3) plus
  The basic_string::append (   21.3.5.2)

which means std::out_of_range. However under the semantic of the operator+,
the conditions for throwing out_of_range are not present.

   21.3, p4 states that the functions is this clause migth throw length_error
and out_of_range.

If std::allocator::allocate fails to allocate memory either during the
copy-construction or during append a std::bad_alloc exception will be thrown
and propagated to the caller.

I also think that on certain platforms (ie. 16 bit Windows, due to segmented
architecture), if it is attempted to append 2 large strings, each of say a
length of 62 kbyte a std::length_error will be thrown, even though the
memory has not been exhausted. This length_error is not mentioned in the
"Throws:" part of append (   21.3.5.2, p3) but in the "Effects:" part
(   23.3.5.2, p4).

I think that it means that the copy-constructor might throw out_of_range and
bad_alloc, and that append might throw out_of_range, bad_alloc and
length_error.

I think that it means that the operator+ might throw bad_alloc or
length_error.

   17.3.1.3, p3 states that the "Throws:" element contains any exception
thrown by the function...

Is the "Throws:" elements for basic_string::append and the copy-constructor
incomplete ?

Are functions allowed (but of course not required) to throw other exceptions
than the mentioned in "Throws:" under any condition without violating the
standard ?

If not, how come the functions does not have an exception specification
like:
   template<class charT, class traits, class Allocator>
   basic_string<charT,traits,Allocator>
   operator+(const basic_string<charT,traits,Allocator>& lhs, const
basic_string<charT,traits,Allocator>& rhs)
   throw (std::bad_alloc, std::length_error);

which according to    15.5.2 would call "unexpected" if any other exception is
thrown  ? (except it would put more work on the comittee - I appreciate the
big job they have made)



Kind regards

Mogens Hansen




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

"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:8klcar$1t2v$1@news.cybercity.dk...
> Which exceptions can be thrown from operator+(const string&, const
> string&) - or
>
>    template<class charT, class traits, class Allocator>
>    basic_string<charT,traits,Allocator>
>    operator+(const basic_string<charT,traits,Allocator>& lhs, const
> basic_string<charT,traits,Allocator>& rhs);
>
> ?

Good question!

> When I read =A721.3.7.1 I see no exception specification - which accord=
ing
to
> =A715.4, p11 means that it allows any exception.

Yes.

> When I read the semantic of the operator+, I think that it can thow the
same
> exceptions as:
>   The copy constructor for basic_string (=A721.3.1, p3) plus
>   The basic_string::append (=A721.3.5.2)
>
> which means std::out_of_range. However under the semantic of the
operator+,
> the conditions for throwing out_of_range are not present.
>
> =A721.3, p4 states that the functions is this clause migth throw
length_error
> and out_of_range.

<investigation of a particular implementation snipped>

The only point in reading the implementation would be to see if the
requirements the standard seems to impose are actually implementable. So,
let's see!

I can't imagine an implementation of basic_string::append (or your
operator+, for that matter) which wasn't capable of throwing a bad_alloc.=
..

17.4.4.8/p3 states:
No destructor operation defined in the C++ Standard Library will throw an
exception. Any other functions defined in the C++ Standard Library that d=
o
not have an exception-specification may throw implementation-defined
exceptions unless otherwise specified.178)
<snip>
178) In particular, they can report a failure to allocate storage by
throwing an exception of type bad_alloc, or a class derived from bad_allo=
c
(18.4.2.1)...

So, it seems that an implementation is allowed to throw bad_alloc, but is
required to document it. I think this is a huge burden on implementors wh=
en
spread across all functions in the library, and probably not worth it. In
this regard I doubt there is an existing implementation which comes close=
 to
conforming.

> Is the "Throws:" elements for basic_string::append and the
copy-constructor
> incomplete ?

It depends how much burden we're willing to saddle library implementors
with. I suppose an implementor could make a blanket statement: "any funct=
ion
not specifically prohibited from throwing exceptions by the C++ standard =
may
throw any exception derived from std::exception", or some such.

> Are functions allowed (but of course not required) to throw other
exceptions
> than the mentioned in "Throws:" under any condition without violating t=
he
> standard ?

Yes, by 17.4.4.8.

> If not, how come the functions does not have an exception specification
> like:

Well, that's another question altogether ;)

don't-get-me-started-on-exception-specifications-ly y'rs,
dave

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