Re: Private Member Access failed through Friend function
On May 3, 3:46 am, Craig Scott <audiofana...@gmail.com> wrote:
On May 1, 3:58 am, Richard Smith <rich...@ex-parrot.com> wrote:
Craig Scott wrote:
You are correct to say that <ostream> is required, but it is *not*
required to overload operator<<. The reason that it is required is that
there is no requirement for <iostream> to define the std::ostream
typedef;
<iostream> defines cout, cerr and clog, which according to 27.3.1 of
the standard are all defined in terms of ostream. Therefore, one can
conclude that including <iostream> must guarantee that std::ostream
will be defined
Not at all. First there's no reason why cout should be declaring using
the ostream typedef: it could be defined as basic_ostream<char>.
Second, it is a declaration not a definition, and as such doesn't need
its type to be complete. So it's entirely possible that <iostream>
would just include <iosfwd> (or equivalent), std::ostream wouldn't be
declared.
Well, my version of the standard says this for 27.3:
namespace std {
extern istream cin;
extern ostream cout;
extern ostream cerr;
extern ostream clog;
// Wide streams omitted....
}
Note that these are not *references* to ostream, but actual ostream
objects, so ostream must be fully defined.
No, you are wrong. This is not the case because these are only
declarations, not definitions, of objects. A declaration that is not
also a definition does *not* require a complete type.
For chapter and verse, see:
[3.1/2] "A declaration is a definition unless it declares a function
without specifying the function's body (8.4), it contains the extern
specifier (7.1.1) or a linkage-specification24) (7.5) and neither an
initializer nor a function-body, it declares a static data member in a
class declaration (9.4), it is a class name declaration (9.1), or it
is a typedef declaration (7.1.3), a using-declaration (7.3.3), or a
using-directive (7.3.4)."
-- i.e. "extern ostream cout;" is a declaration but not a definition.
[3.1/6] "A program is ill-formed if the definition of any object
gives the object an incomplete type (3.9)."
-- note this does not make a progam ill-formed if a declaration uses
an incomplete type.
And most importantly, [3.2/4], which gives a complete list of contexts
in which a type is required to be complete; one of these (the first
one) is when an object is defined, but the declaration of an object is
not listed.
As the standard doesn't require the type to be complete, it isn't
required to be complete. If you don't believe, try the following
complete translation unit in any modern compiler:
template <class C>
class char_traits;
template <class C, class Tr = char_traits<C> >
class basic_ostream; // incomplete
typedef basic_ostream<char> ostream;
extern ostream cout;
void foo( ostream& );
int main() { foo( cout ); }
I've tried comeau 4.3.9-alpha, gcc 4.1.1, and conceptgcc 4.3.0-
alpha-6, all of which compile it without error.
defines cout etc. in terms of ostream, not basic_ostream<char>, so
although compilers *could* define them using basic_ostream, they are
*required* by the standard to define them as above, or at least
equivalently. Here, equivalently also means that ostream must be
defined.
Again, no. The header is *only* required to define nine names: the
namespace name (std) and the eight stream objects. It's required to
give cout the same type as is represented by the ostream typedef, but
there is no requirement for the name of this type to be in scope after
including <iostream>. There's not even a requirement for the name
basic_ostream to be in scope -- although hiding this name would
require the <iostream> header to be implemented with extra compiler
support. But implementations are permitted to use compiler magic to
implement the headers -- indeed, there's no requirement for the
standard headers even to exist as files.
The main reason why implementation don't do this is because
implementations never have and it would mean that a lot of "hello world"
programs in introductory books on C++ would suddenly stop compiling.
That aside, it would seem a good strategy: I find that in real world
programs (as opposed to short 'toy' examples), those translation units
in which I use cout (et al.) rarely require basic_ostream to be a
complete type. (Generally, they're high level translation units passing
an ostream down to some lower-level module.)
Passing an ostream by reference doesn't require its definition (ie
including <iosfwd> is enough). Once you try to actually use the
ostream for something other than taking its address, you need at least
<ostream>.
That is precisely my point. In my experience, in large real-world
projects, the top level translation units often just pass an ostream
object down to lower level translation units. Passing them by
reference is all they do, so they don't require basic_ostream to be
complete.
--
Richard Smith
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]