stringstream problems

[Nick Keighley]

Hi,

I'm having problems with stringstream, specifically it won't compile
with Visual C++ 2008 Express. This may be a problem with CPPX, in
which case I'll go elsewhere (suggestions?). But is there an obvious
bug with this code?

#include <iostream>
#include <sstream>

class Lexer
{
public:
explicit Lexer (std::istream&);
~Lexer ();

private:
std::istream stream_;
};


Lexer::Lexer (std::istream& in_stream):
stream_(in_stream)
{
}

Lexer::~Lexer ()
{
}

int main ()
{
std::istringstream in_stream ("purple people eater");
Lexer lex (in_stream);
return 0;
}

The diagnostic is:
c:\program files\microsoft visual studio 9.0\vc\include\istream(846) :
error C2248: 'std::basic_ios<_Elem,_Traits>::basic_ios' : cannot
access private member declared in class
'std::basic_ios<_Elem,_Traits>'
1>

it sems to be claiming a bug in istream, which doesn't sound good...


thanks,
Nick Keighley

 

[Nick Keighley]

std::istream is not copyable. std::istream does not define a copy
constructor, or an assignment operator.



I see no evidence of a bug. This is just one possible manifestation of an
undefined copy constructor or assignment operator.

Redefining your class member as a reference, "std::istream &stream_;" should
work, but keep in mind that your std::istringstream object you're using to
initialize this reference must exist as your Lexer object exists, in order
for this reference to remain valid.

thanks
an older MS compliler actually compiled this

 

[Bo Persson]

thanks
an older MS compliler actually compiled this

Yes, there you have the bug then!


Explicitly making the base class copy constructor private stops
copying for derived classes.


Bo Persson

 

[Juha Nieminen]

I see no evidence of a bug. This is just one possible manifestation of an
undefined copy constructor or assignment operator.

It might be not a bug per se, but it's extremely irritating that VS doesn't
tell you the line where the copying is happening. It only gives you that
obscure message without telling exactly where it's being triggered in *your*
code. Thus in a large piece of code it can be really laborious to find the
exact place where it's happening.

I know this because I have had to do it. I had to search for a really long
time because VS was not telling me where the problem is. It ended up being
a line like this:

std:stream& output = (someOption ? stream1 : stream2);

That seemed innocent enough because there's no copying being done. Not
that I can see. However, for some reason it's triggering the copy
constructor.

 

[Juha Nieminen]

I cannot reproduce the strange behaviour you describe. The line compiles
fine in VC.

Which version? The problem happened with Visual C++ 2005 in my case.
(AFAIK this can be highly version-dependent.)

 

[Vladimir Jovic]

Which version? The problem happened with Visual C++ 2005 in my case.
(AFAIK this can be highly version-dependent.)

Probably not in a line like you posted :
std:stream& output = (someOption ? stream1 : stream2);
there is a reference. The copy would be :
std:stream output = (someOption ? stream1 : stream2);

 

[Juha Nieminen]

Probably not in a line like you posted :
std:stream& output = (someOption ? stream1 : stream2);
there is a reference. The copy would be :
std:stream output = (someOption ? stream1 : stream2);

Which is exactly why I can't understand why VC++2005 is issuing the error
message. If I replace:

std:stream& output = (someOption ? stream1 : stream2);

with:

std:stream& output = stream1;

then it compiles and works ok (but without the possibility of the second
stream being used, of course).

 

[Nick Keighley]

This is one instance where gcc's diagnostics are much superior. gcc's errors
gives you not one, but two dumps (most of the time) for each compilation
error:

* The stack of nested include times at the point that the error occurs, so
you can see the sequence of nested includes files being processed when the
error occured.

* If the error occured when processing a template class or a template
function, the nested sequence of template class or function instantiations
that led up to the point of the compilation error, together with the
original file and line number of each active template class or function.

So if the compilation error occured while expanding some template or
function call in your .C file, you get the file and line number for all the
nested template classes or functions that the compiler was evaluating,
together with all the template parameters that gcc used when expanding the
template definition.

The only negative drawback to this is that this makes gcc's error
diagnostics approach the size of an average Shakespearean novel.

he wrote novels! Who knew?

But, if
you're staring at an error, you know exactly where it occured, even if you
cannot immediately figure out what the problem is.

perhaps time to put Mingw back on my laptop then...

Anyone any opinions on Mingw these days? I used to find it a bit
"odd" (sometimes it wouldn't let me debug code- I don';t like software
that sometimes does things). Is there a better way to run gcc under
windows (no, I'm not going to run Wine)

moving my code between Express and Very Old VCC flushes some
interesting oddities.