MSVC++ 2005 Express Ed. build error when mixing boost lexical_castand shared_ptr

[hsmit.home]

Hello,

I came across a strange error and it's really been bugging me. Maybe
someone else has come across this and any insight would be
appreciated.

What I'm trying to accomplish is using boost::lexical_ cast to cast a
vector of strings to a string.

The compiler I'm using is MSVC++ 2005 Express Edition. The gc++
compiler does not have the same complaint, this is strictly a MSVC++
2005 issue. I don't think it matters, but I'm running on a WinXP 32
bit machine. I'm also using boost v1.34.0.
Here's the code.

#include <boost/lexical_cast.hp p>
#include <iostream>
#include <vector>
#include <string>

//--------------------------------------------------------------
template<class T>
std::ostream & operator<<(std: :ostream& s, const std::vector<T& d) {
typedef typename std::vector<T>: :const_iterator iter;
iter it;
for (it = d.begin() ; it != d.end() ; ++it) {
s << *it;
s << "\n";
}
return s;
}
//--------------------------------------------------------------
template<class T>
std::istream & operator>>(std: :istream& s, std::vector<T& d) {
while (!s.eof()) {
char buf[500];
s.getline(buf, sizeof(buf));
d.push_back(buf );
}
return s;
}

//--------------------------------------------------------------
int main (int argc, char ** argv) {

std::vector<std ::stringvecstr1 ;
vecstr1.push_ba ck("hi");
vecstr1.push_ba ck("there");
std::string str = boost::lexical_ cast<std::strin g>(vecstr1);
std::cout << str << std::endl;

return 0;
}
This compiles quite nicely and even spits out the correct output. Now
for the problem:

If I change the include #includes at the top to:

#include <boost/lexical_cast.hp p>
#include <boost/shared_ptr.hpp>
#include <iostream>
#include <vector>
#include <string>

I get the following compilation error (only the last few lines are
provided for clarity):

lexical_cast.hp p(150) : while compiling class template member function
'bool boost::detail:: lexical_stream< Target,Source>: :operator <<(const
Source &)'
with
[
Target=std::str ing,
Source=NewSourc e
]
lexical_cast.hp p(219) : see reference to class template instantiation
'boost::detail: :lexical_stream <Target,Source> ' being compiled
with
[
Target=std::str ing,
Source=NewSourc e
]
main.cpp(38) : see reference to function template instantiation
'Target boost::lexical_ cast<std::strin g,std::vector<_ Ty>>(const Source
&)' being compiled
with
[
Target=std::str ing,
_Ty=std::string ,
Source=std::vec tor<std::string >
]
lexical_cast.hp p(151) : error C2228: left of '.fail' must have class/
struct/union

Now, for a really stupid solution:

#include <boost/lexical_cast.hp p>
#include <boost/shared_ptr.hpp>
#include <iostream>
#include <vector>
#include <string>

//--------------------------------------------------------------
// inheriting from an STL container - asking for trouble!
// But it does solve the compilation problem. WHY????
class stringvector : public std::vector<std ::string{
};

//--------------------------------------------------------------
template<class T>
std::ostream & operator<<(std: :ostream& s, const std::vector<T& d) {
typedef typename std::vector<T>: :const_iterator iter;
iter it;
for (it = d.begin() ; it != d.end() ; ++it) {
s << *it;
s << "\n";
}
return s;
}
//--------------------------------------------------------------
template<class T>
std::istream & operator>>(std: :istream& s, std::vector<T& d) {
while (!s.eof()) {
char buf[500];
s.getline(buf, sizeof(buf));
d.push_back(buf );
}
return s;
}

//--------------------------------------------------------------
int main (int argc, char ** argv) {

stringvector vecstr1; // replaced std::vector<Twi th stringvector
vecstr1.push_ba ck("hi");
vecstr1.push_ba ck("there");
std::string str = boost::lexical_ cast<std::strin g>(vecstr1);
std::cout << str << std::endl;

return 0;
}

This code compiles, but inheriting from an STL container is not my
idea...of a good idea...

So what's going on here?

There are basically 2 questions I have:
1) why does the boost/shared_ptr.hpp inclusion effect a
boost::lexical_ cast<std::strin g, std::vectordecl aration?
2) How does inheriting from the std::vector class solve this problem?

Thanks in advance.

Hans Smit

[David Harmon]

On Mon, 19 Nov 2007 11:14:34 -0800 (PST) in comp.lang.c++,
hs********@gmai l.com wrote,

>There are basically 2 questions I have:
1) why does the boost/shared_ptr.hpp inclusion effect a
boost::lexical _cast<std::stri ng, std::vectordecl aration?

I don't know, but I presume in general that shared_ptr.hpp introduces
some more data types and some more default conversions to/from other
types, that take precedence because they are more direct than the other
conversions available, but which ultimately don't work.

>2) How does inheriting from the std::vector class solve this problem?

By making it a new type that doesn't appear to participate in the
half-baked type conversion tree. That's my guess.

[hsmit.home]

Thanks for your response. I would have to agree with your guess. I
just wonder why it would compile with gc++ and not with MSVC++ 8.0.
This latest MS compiler has been brilliant so far and has seemed (to
me) to be very compiliant with the standards. Mind you, I have come
across a few other quirks between gc++ and msvc++ 8.0, but that's
another topic.

So, the only solution to this problem thus far is to inherit from an
STL container. Inheriting from a class without virtual methods is a
bad thing and can lead to undefined behavior in the destruction phase
(I have yet to come across this scenario, but how could hundreds of
expert C++'ers be wrong). Inheriting from an STL container makes me
feel dirty and cheap. Of course, I could wrap all the std::vector
functions in a vector_wrapper class that does have a virtual
destructor, but this feels like a "canon killing a s bug" solution.

Another solution, would be to develop my own share_ptr class... so
much for standards. NO, not a good solution either.

Any other solutions or thoughts, anyone?

[James Kanze]

On Nov 19, 8:14 pm, hsmit.h...@gmai l.com wrote:

I came across a strange error and it's really been bugging me. Maybe
someone else has come across this and any insight would be
appreciated.

What I'm trying to accomplish is using boost::lexical_ cast to cast a
vector of strings to a string.

I don't think it's possible, at least not with a standards
conformant compiler, which does dependent name lookup correctly.
(Strangely enough, it does compile with g++, although I can't
figure out how.) Unless I've misunderstood something
completely, boost::lexical_ cast uses << and >on the
instantiation types. The expression is dependent, so §14.6.4
should apply.

I've found this to be the case in other constructs with g++, so
something else is occuring which I don't understand.

The compiler I'm using is MSVC++ 2005 Express Edition. The
gc++ compiler does not have the same complaint, this is
strictly a MSVC++ 2005 issue. I don't think it matters, but
I'm running on a WinXP 32 bit machine. I'm also using boost
v1.34.0.

Here's the code.

#include <boost/lexical_cast.hp p>
#include <iostream>
#include <vector>
#include <string>

//--------------------------------------------------------------
template<class T>
std::ostream & operator<<(std: :ostream& s, const std::vector<T& d) {
typedef typename std::vector<T>: :const_iterator iter;
iter it;
for (it = d.begin() ; it != d.end() ; ++it) {
s << *it;
s << "\n";

Why not just:
s << *it << '\n' ;
?

Or even replacing the entire loop by:

std::copy( d.begin(), d.end(), std::ostream_it erator( s,
"\n" ) ) ;

}
return s;}

Normally, this function should not be found during dependent
name lookup, at least as I understand the standard.

//--------------------------------------------------------------
template<class T>
std::istream & operator>>(std: :istream& s, std::vector<T& d) {
while (!s.eof()) {
char buf[500];

Why not std::string?

s.getline(buf, sizeof(buf));

You'd best check the success of the getline before using the
value read.

d.push_back(buf );
}

The standard idiom here is:

std::string line ;
while ( std::getline( s, line ) ) {
d.push_back( line ) ;
}

return s;
}

This compiles quite nicely and even spits out the correct output.

Which is what I don't understand. As far as I can see, it
shouldn't compile.

Now for the problem:

If I change the include #includes at the top to:

#include <boost/lexical_cast.hp p>
#include <boost/shared_ptr.hpp>
#include <iostream>
#include <vector>
#include <string>

I get the following compilation error (only the last few lines are
provided for clarity):

lexical_cast.hp p(150) : while compiling class template member function
'bool boost::detail:: lexical_stream< Target,Source>: :operator <<(const
Source &)'
with
[
Target=std::str ing,
Source=NewSourc e
]
lexical_cast.hp p(219) : see reference to class template instantiation
'boost::detail: :lexical_stream <Target,Source> ' being compiled
with
[
Target=std::str ing,
Source=NewSourc e
]
main.cpp(38) : see reference to function template instantiation
'Target boost::lexical_ cast<std::strin g,std::vector<_ Ty>>(const Source
&)' being compiled
with
[
Target=std::str ing,
_Ty=std::string ,
Source=std::vec tor<std::string >
]
lexical_cast.hp p(151) : error C2228: left of '.fail' must have class/
struct/union

Now, for a really stupid solution:

#include <boost/lexical_cast.hp p>
#include <boost/shared_ptr.hpp>
#include <iostream>
#include <vector>
#include <string>

//--------------------------------------------------------------
// inheriting from an STL container - asking for trouble!
// But it does solve the compilation problem. WHY????

Because you then use a class defined in the global namespace.
Which means that the global namespace is drawn into ADL.

class stringvector : public std::vector<std ::string{

};

//--------------------------------------------------------------
template<class T>
std::ostream & operator<<(std: :ostream& s, const std::vector<T& d) {
typedef typename std::vector<T>: :const_iterator iter;
iter it;
for (it = d.begin() ; it != d.end() ; ++it) {
s << *it;
s << "\n";
}
return s;}

//--------------------------------------------------------------
template<class T>
std::istream & operator>>(std: :istream& s, std::vector<T& d) {
while (!s.eof()) {
char buf[500];
s.getline(buf, sizeof(buf));
d.push_back(buf );
}
return s;
}

This is tricky, of course. But basically, as some point, you
have a << or a >with a ::stringvector as an argument. So ::
is pulled in, and the compiler finds the above functions.

>
This code compiles, but inheriting from an STL container is not my
idea...of a good idea...

So what's going on here?

There are basically 2 questions I have:
1) why does the boost/shared_ptr.hpp inclusion effect a
boost::lexical_ cast<std::strin g, std::vectordecl aration?

That I don't know. IMHO, without the inheritance, the code
should never compile.

2) How does inheriting from the std::vector class solve this problem?

Because you're now using a class declared in the global
namespace.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[hsmit.home]

Thank you for the standard idiom:

std::string line ;
while ( std::getline( s, line ) ) {
d.push_back( line ) ;
}

It's very useful to know, and will help make a few areas of my code
more clear and STL like. My old mentor, Mr Wil Evers always taught me
to stay away from raw character pointers (char *). And now you've
shown me how - thank you. Tells you how little I still know about
STL...

You also write:

>Because you then use a class defined in the global namespace.
Which means that the global namespace is drawn into ADL.

what does ADL stand for?

C++ is IMHO the most beautiful language out there. It's my favorite
and has taught me a great deal about programming well. But these type
of compiler errors whilst using standard libraries really scare me.
The following doubts enter my mind:
1) am I using a compliant compiler?
2) does the boost library have limitations?
3) am I writing inappropriate code?

These doubts are not a good thing.

Here's the code rewritten in a more proper way (this version
compiles):

#include <boost/lexical_cast.hp p>
#include <iostream>
#include <vector>
#include <string>

namespace mytest {

//--------------------------------------------------------------
//THIS DOES NOT COMPILE (it's commented out)
//typedef std::vector<std ::stringstringv ector;

//--------------------------------------------------------------
//BUT THIS DOES COMPILE! Yikes, inheriting from STL container!
class stringvector : public std::vector<std ::string{ };

//--------------------------------------------------------------
template<class Tstd::ostream & operator<<(std: :ostream& s, const
std::vector<T& d) {
std::copy(d.beg in(), d.end(),
std::ostream_it erator<std::str ing>(s, "\n"));
return s;
}
//--------------------------------------------------------------
template<class Tstd::istream & operator>>(std: :istream& s,
std::vector<T& d) {
std::string line;
while (std::getline(s , line)) {
d.push_back(lin e);
}
return s;
}
}; // end mytest namespace

//--------------------------------------------------------------
int main (int argc, char ** argv) {

mytest::stringv ector vecstr1;
vecstr1.push_ba ck("hi");
vecstr1.push_ba ck("there");
std::string str = boost::lexical_ cast<std::strin g>(vecstr1);
std::cout << str << std::endl;

return 0;
}
My previous post included the share_ptr.hpp, however, I just
discovered that the problem can be reproduced without including this
header.

I have now modified the code slightly. This compiles:

#include <boost/lexical_cast.hp p>
#include <iostream>
#include <vector>
#include <string>

namespace mytest {

// IF I PLACE: using namespace mytest; - THIS WORKS
typedef std::vector<std ::stringstringv ector;

//--------------------------------------------------------------
template<class Tstd::ostream & operator<<(std: :ostream& s, const
std::vector<T& d) {
std::copy(d.beg in(), d.end(),
std::ostream_it erator<std::str ing>(s, "\n"));
return s;
}
//--------------------------------------------------------------
template<class Tstd::istream & operator>>(std: :istream& s,
std::vector<T& d) {
std::string line;
while (std::getline(s , line)) {
d.push_back(lin e);
}
return s;
}
}; // end mytest namespace

// THE TRICK TO GET THIS CODE TO COMPILE
using namespace mytest;

//--------------------------------------------------------------
int main (int argc, char ** argv) {

mytest::stringv ector vecstr1;
vecstr1.push_ba ck("hi");
vecstr1.push_ba ck("there");
std::string str = boost::lexical_ cast<std::strin g>(vecstr1);
std::cout << str << std::endl;

return 0;
}
However, if I remove the,

using namespace mytest;

It fails to compile. I have not tried to compile this in gc++ yet.

So, my next question is:
- why does placing the "mytest" namespace into the global namespace
solve this problem?

[hsmit.home]

Once again, thanks. You have shed a lot of light on this subject.

Cheers, & ydh., (you did help)

Hans

[James Kanze]

On Nov 20, 8:45 pm, "Alf P. Steinbach" <[e-mail] wrote:

* hsmit.h...@gmai l.com:

[...]

Here's the code.

#include <boost/lexical_cast.hp p>
#include <iostream>
#include <vector>
#include <string>

//--------------------------------------------------------------
template<class T>
std::ostream & operator<<(std: :ostream& s, const std::vector<T& d) {
typedef typename std::vector<T>: :const_iterator iter;
iter it;
for (it = d.begin() ; it != d.end() ; ++it) {
s << *it;
s << "\n";
}
return s;
}
//--------------------------------------------------------------
template<class T>
std::istream & operator>>(std: :istream& s, std::vector<T& d) {
while (!s.eof()) {
char buf[500];
s.getline(buf, sizeof(buf));
d.push_back(buf );
}
return s;
}

//--------------------------------------------------------------
int main (int argc, char ** argv) {

std::vector<std ::stringvecstr1 ;
vecstr1.push_ba ck("hi");
vecstr1.push_ba ck("there");
std::string str = boost::lexical_ cast<std::strin g>(vecstr1);
std::cout << str << std::endl;

return 0;
}

This compiles quite nicely and even spits out the correct output.

This version seems to use just ordinary lookup, not
argument-dependent lookup (ADL).

That's the impression I get, but why? According to §14.6.4:

In resolving dependent names, names from the following
sources are considered:

-- Declarations that are visible at the point of
definition of the template.

-- Declarations from namespaces associated with the
types of the function arguments both from the
instantiation context (14.6.4.1) and from the
definition context.

The operator<< is obviously dependent (or?). The one he's
interested in is not visible at the point of definition of the
template (in boost/lexical_cast.hp p). And the only namespace
associated with any of the types that I can see is std::, and
the operator he's looking for isn't in that either.

There's definitely something I'm missing here, because his code
compiles with g++ 4.1.0. It's not related to the fact that his
operators are templates, because it compiles even if I modify
the code to use the concrete type std::vector<std ::string>. But
I know that g++ implements the above rule, because I've run into
cases where the code wouldn't compile because of it. So what's
different here, compared to, say:

#include <algorithm>
#include <iostream>
#include <iterator>
#include <vector>

std::ostream&
operator<<( std::ostream& dest, std::vector< int const& src )
{
dest << '[' ;
for ( std::vector< int >::const_iterat or it = src.begin() ;
it != src.end() ;
++ it ) {
if ( it != src.begin() ) {
dest << ',' ;
}
dest << *it ;
}
dest << ']' ;
return dest ;
}

int
main()
{
std::vector< std::vector< int v ;
for ( int i = 0 ; i < 10 ; ++ i ) {
v.push_back( std::vector< int >() ) ;
for ( int j = 0 ; j < 10 ; ++ j ) {
v.back().push_b ack( 10* i + j ) ;
}
}
std::copy( v.begin(), v.end(),
std::ostream_it erator< std::vector< int >

>( std::cout, "\n" ) ) ;

return 0 ;
}

(which doesn't compile with either g++ or VC++, unless I put the
operator<< in namespace std, which is formally illegal.)

Now for the problem:

If I change the include #includes at the top to:

#include <boost/lexical_cast.hp p>
#include <boost/shared_ptr.hpp>
#include <iostream>
#include <vector>
#include <string>

I get the following compilation error (only the last few lines are
provided for clarity):

lexical_cast.hp p(150) : while compiling class template member function
'bool boost::detail:: lexical_stream< Target,Source>: :operator <<(const
Source &)'
with
[
Target=std::str ing,
Source=NewSourc e
]
lexical_cast.hp p(219) : see reference to class template instantiation
'boost::detail: :lexical_stream <Target,Source> ' being compiled
with
[
Target=std::str ing,
Source=NewSourc e
]
main.cpp(38) : see reference to function template instantiation
'Target boost::lexical_ cast<std::strin g,std::vector<_ Ty>>(const Source
&)' being compiled
with
[
Target=std::str ing,
_Ty=std::string ,
Source=std::vec tor<std::string >
]
lexical_cast.hp p(151) : error C2228: left of '.fail' must have class/
struct/union

[shared_ptr.hpp] brings into play

template<class E, class T, class Y>
std::basic_ostr eam<E, T>& operator<<(
std::basic_ostr eam<E, T& os, shared_ptr<Ycon st & p
)
{
os << p.get();
return os;
}

in namespace boost.

I don't know why it's critical that it's in namespace boost (possibly
because the stream used in lexical cast is of a class defined in
namespace boost, engaging ADL in boost),

In the version of Boost I have here (1.33.0), lexical_cast uses
a boost::detail:: lexical_stream< >, which in turn uses an
std::basic_stri ngstream<>. Neither of which are in namespace
boost!

In the end, boost::lexical_ cast<std::strin g>(vecstr1), in his
code, must find his template operator<<. According to my
reading of the standard, it shouldn't, since it should only do
the look-up in the definition context, and in associated
namespaces (std, boost and boost::detail) at the point of
instantiation. Since his operator isn't available at the point
of definition, and isn't in one of the associated namespaces, it
shouldn't be found.

So what am I overlooking. Why is the behavior in his cas
different than that in my sample program, above?

but anyway, with this definition in boost you get the above
error, and with same definition in global namespace it
compiles OK. So it looks like it makes the operator<< call in
lexical_cast ambigious, via ADL. Which is difficult to
understand because SFINAE should throw it out of
consideration?

But even though I can't give you exact answer (is there some
language lawyer present?) I think you get the general drift.

Well, I'd like to hear too from someone who knows how name
lookup in templates really works.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]