std::ios_base copy constructor
in [C++]
|
Next: Exceptions
From: James Daughtry on 27 May 2005 04:47 The standard doesn't prohibit copying of streams, but because there isn't a clear and unambiguous way to copy the stream buffer object contained in a stream object, the standard leaves the functionality of the copy constructor and assignment operator up to the implementation. It's perfectly reasonable to declare them both private and sidestep the issue entirely. You can portably copy a stream object with a little more work, if you really want to do it: #include <iostream> void copy_stream(std::ostream &dst, const std::ostream& src) { dst.copyfmt(src); dst.clear(src.rdstate()); dst.rdbuf(src.rdbuf()); } int main() { std::ostream s(0); copy_stream(s, std::cout); s << "Test\n"; } [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: James Kanze on 27 May 2005 06:56 Chris Croughton wrote: > Is it legal in C++ STL to assign or copy streams? For > instance, if I have: > #include <iostream> > int main() > { > std::ostream s(std::cout); > s << "Hello" << std::endl; > return 0; > } > is that valid? No. It never has been, although in some earlier implementations, it worked by accident. > I'm using gcc versions 2.95 and 3.4.3, and both of them give > an error on the definition of s saying that the copy > constructor for ios_base is private (the same if I define s > and then say s = std:cout). Which is what the standard requires. (But I'm very surprised at 2.95 mentionning ios_base, and not simply ios.) > Looking at the headers for both versions, the copy constructor > and operator=() are both explicitly private. Required by the standard, Generallly the case) for pre-standard implementations as well. > I can't find anything about this in the ISO spec., though, nor > any reason for it. Is this correct, or is it a bug (or > misfeature) in the GCC implementation? The reason for it is simple: what does it mean? -- James Kanze mailto: james.kanze(a)free.fr Conseils en informatique orientýe objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sýmard, 78210 St.-Cyr-l'ýcole, France +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Seungbeom Kim on 27 May 2005 07:08 Chris Croughton wrote: > Is it legal in C++ STL to assign or copy streams? For instance, > > std::ostream s(std::cout); > > is that valid? I'm using gcc versions 2.95 and 3.4.3, and both of them > give an error on the definition of s saying that the copy constructor > for ios_base is private (the same if I define s and then say s = > std:cout). Looking at the headers for both versions, the copy > constructor and operator=() are both explicitly private. I can't find > anything about this in the ISO spec., though, nor any reason for it. Is > this correct, or is it a bug (or misfeature) in the GCC implementation? std::cout has type std::ostream, i.e. std::basic_ostream<char>, std::basic_ostream<> inherits from std::basic_ios<>, and std::basic_ios<> has private copy constructors and assignment operators. Further, std::basic_ios<> inherits from std::ios_base, and std::ios_base has private copy constructors and assignment operators, too. -- Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: P.J. Plauger on 27 May 2005 08:16 "Francis Glassborow" <francis(a)robinton.demon.co.uk> wrote in message news:8pvAk8VHvalCFweI(a)robinton.demon.co.uk... > In article <slrnd98scp.d71.chris(a)ccserver.keris.net>, Chris Croughton > <chris(a)keristor.net> writes >>Is it legal in C++ STL to assign or copy streams? For instance, if I >>have: >> >> #include <iostream> >> >> int main() >> { >> std::ostream s(std::cout); >> s << "Hello" << std::endl; >> return 0; >> } >> >>is that valid? I'm using gcc versions 2.95 and 3.4.3, and both of them >>give an error on the definition of s saying that the copy constructor >>for ios_base is private (the same if I define s and then say s = >>std:cout). > > And they are both correct. Having more than one object trying to handle > the same data source/sink is a recipe for trouble. You mean like cout and cerr? There's no show stopper here -- the committee simply decided to disallow copying of certain objects in the Standard C++ library, including iostreams. P.J. Plauger Dinkumware, Ltd. http://www.dinkumware.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Chris Croughton on 28 May 2005 07:05
On 27 May 2005 04:27:44 -0400, TonyO <guinness_tony(a)hotmail.com> wrote: > Chris Croughton wrote: >> Is it legal in C++ STL to assign or copy streams? > > No. All stream classes ultimately derive from class std::ios_base, > which is defined in section 27.4.2 to have both a private > copy-constructor and a private copy-assignment operator. In my copy of ISO/IEC 14882:1998 it doesn't have them at all, that's the problem I found. Is it in one of the later corrections? > These compilers are both correctly identifying the error. Look again > at section 27.4.2 of The Holy Standard. Yup, have done. No copy constructor or assignment operator. The only things declared private in ios_base are (as comments) a few variables "for exposition only". > But fear not, you have an alternative: stream classes can be > constructed that use an existing stream-buffer. This strategy can be > adopted to allow different streams to share the same I/O mechanism. I > guess you want this: > >| #include <ostream> >| #include <iostream> >| >| int main() >| { >| std::ostream s(std::cout.rdbuf()); >| s << "Hello" << std::endl; >| return 0; >| } That probably does solve what the original code meant to do, thanks. As to /why/ it did it, that's probably unknowable (the author isn't even identified!)... Thanks, Chris C [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |