I see that the basic_string section of the fcd has been restructured
quite a bit. Probably a good thing, but I am a bit confused about the
difference between the uses of "Effects: Calls..." in some places and
"Effects: Equivalent to..." in other places.

Are these "Calls" to be taken literally?

For example, does

basic_string& operator+=(charT c);

  Effects: Calls append(1, c);
  Returns; *this

mean that all implementations of this operator must call append(1, c)
instead of the "more obvious" push_back(c) ?

If so, why?



Bo Persson



--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Jun 4, 12:13 am, "Bo Persson" <b...@gmb.dk> wrote:
> I see that the basic_string section of the fcd has been restructured
> quite a bit. Probably a good thing, but I am a bit confused about the
> difference between the uses of "Effects: Calls..." in some places and
> "Effects: Equivalent to..." in other places.
>
> Are these "Calls" to be taken literally?

No.

First, let me point to the proposal document that became accepted
and that lead to the recent wording changes:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3072.pdf

The rationale provided explains the intent of the wording such that
using the term "call" when any differences should not be observable
and using "equivalent of" when e.g. the effects clause describes
a semantics that potentially creates string temporaries but an
implementation is allowed to prevent the creation of these (Page 2,
"Overview of Changes").

Now let's look how the normative wording supports (or doesn't
support) this intention:

The relevant location in the FCD is 17.5.1.4
[structure.specifications],
mainly p.3 and p. 4. IMO the wording allows us to conclude that a
requirement like:

Effects: Calls foo()

requires an implementation to either directly call foo() or to perform
anything else where a difference is not user-observable of such a
call.
E.g. if foo() is some non-replacement function provided by the
implementation,
the actual implementation may simply replace that by a corresponding
inline code of that function and it may even rewrite that code as long
as
the whole call does not have visible effects for the user that are
different
(freedom of as-if).

Referring to your example

basic_string& operator+=(charT c);

 Effects: Calls append(1, c);

an implementation may call the member function append directly or some
internal function __append(1, c, otherargs) or some variation of this
because
append is a non-virtual member function and the remaining requirements
of
clause 17 prevent a user from observing any differences. "Calls foo()"
in a
general context can be very strong requirement, when a user may
override,
replace, or specialize functions.
In the case discussed here I see no way in which a user-code could
require
the literal function call, because [namespace.std]/2 adds special
constraints
regarding specializations of member functions of library components.

In regard to the meaning of "Equivalent to": This is quite well
defined in
[structure.specifications]/4 and I doubt that the rationale provided
in N3072
does properly reflect this meaning, because this wording form used
within
an effects clause is even stronger than a pure effects clause. While a
"normal" effects clause does not make it 100% clear, which further
semantic elements (of [structure.specifications]) can be deduced from
such
an effect, this lack of clarification does much less exist for the
"equivalent to"
wording.

In other words: I'm not very happy about the current specification of
the
string members (and of some other components), but N3072 is
definitively
an improvement over the previous one. I don't expect further changes
unless either user complain about seemingly violating implementations
in an observable way or implementation vendors complain about too
strict or underspecified member specifications.

HTH & Greetings from Bremen,

Daniel Kr=FCgler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]