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.hpp>
#include <iostream>
#include <vector>
#include <string>

//--------------------------------------------------------------
template<class T>
std:stream & operator<<(std:stream& 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::string> vecstr1;
vecstr1.push_back("hi");
vecstr1.push_back("there");
std::string str = boost::lexical_cast<std::string>(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.hpp>
#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.hpp(150) : while compiling class template member function
'bool boost::detail::lexical_stream<Target,Source>:perator <<(const
Source &)'
with
[
Target=std::string,
Source=NewSource
]
lexical_cast.hpp(219) : see reference to class template instantiation
'boost::detail::lexical_stream<Target,Source>' being compiled
with
[
Target=std::string,
Source=NewSource
]
main.cpp(38) : see reference to function template instantiation
'Target boost::lexical_cast<std::string,std::vector<_Ty>>(const Source
&)' being compiled
with
[
Target=std::string,
_Ty=std::string,
Source=std::vector<std::string>
]
lexical_cast.hpp(151) : error C2228: left of '.fail' must have class/
struct/union



Now, for a really stupid solution:

#include <boost/lexical_cast.hpp>
#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:stream & operator<<(std:stream& 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<T> with stringvector
vecstr1.push_back("hi");
vecstr1.push_back("there");
std::string str = boost::lexical_cast<std::string>(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::string, std::vector> declaration?
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++,
(e-mail address removed) wrote,

There are basically 2 questions I have:
1) why does the boost/shared_ptr.hpp inclusion effect a
boost::lexical_cast<std::string, std::vector> declaration?

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]

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.hpp>
#include <iostream>
#include <vector>
#include <string>

//--------------------------------------------------------------
template<class T>
std:stream & operator<<(std:stream& 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:stream_iterator( 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.hpp>
#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.hpp(150) : while compiling class template member function
'bool boost::detail::lexical_stream<Target,Source>:perator <<(const
Source &)'
with
[
Target=std::string,
Source=NewSource
]
lexical_cast.hpp(219) : see reference to class template instantiation
'boost::detail::lexical_stream<Target,Source>' being compiled
with
[
Target=std::string,
Source=NewSource
]
main.cpp(38) : see reference to function template instantiation
'Target boost::lexical_cast<std::string,std::vector<_Ty>>(const Source
&)' being compiled
with
[
Target=std::string,
_Ty=std::string,
Source=std::vector<std::string>
]
lexical_cast.hpp(151) : error C2228: left of '.fail' must have class/
struct/union

Now, for a really stupid solution:

#include <boost/lexical_cast.hpp>
#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:stream & operator<<(std:stream& 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

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::string, std::vector> declaration?

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.

 

[Alf P. Steinbach]

* (e-mail address removed):

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.hpp>
#include <iostream>
#include <vector>
#include <string>

//--------------------------------------------------------------
template<class T>
std:stream & operator<<(std:stream& 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::string> vecstr1;
vecstr1.push_back("hi");
vecstr1.push_back("there");
std::string str = boost::lexical_cast<std::string>(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).

Now for the problem:

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

#include <boost/lexical_cast.hpp>
#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.hpp(150) : while compiling class template member function
'bool boost::detail::lexical_stream<Target,Source>:perator <<(const
Source &)'
with
[
Target=std::string,
Source=NewSource
]
lexical_cast.hpp(219) : see reference to class template instantiation
'boost::detail::lexical_stream<Target,Source>' being compiled
with
[
Target=std::string,
Source=NewSource
]
main.cpp(38) : see reference to function template instantiation
'Target boost::lexical_cast<std::string,std::vector<_Ty>>(const Source
&)' being compiled
with
[
Target=std::string,
_Ty=std::string,
Source=std::vector<std::string>
]
lexical_cast.hpp(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_ostream<E, T>& operator<<(
std::basic_ostream<E, T> & os, shared_ptr<Y> const & 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), 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.

Now, for a really stupid solution:

#include <boost/lexical_cast.hpp>
#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:stream & operator<<(std:stream& 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<T> with stringvector
vecstr1.push_back("hi");
vecstr1.push_back("there");
std::string str = boost::lexical_cast<std::string>(vecstr1);
std::cout << str << std::endl;

return 0;
}

Here ADL kicks in. Class defined in global namespace, lookup finds
operator>> in global namespace. Try with all in namespace trallala and
that works OK too, same reason.

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

Bah, if it works it works.

However, if you don't like it, you can (A) use containment instead of
inheritance, or (B) you can ignore the standard's silly restrictions and
simply place your operator<< in namespace std, making ADL work for you
instead of against you.

So what's going on here?

See above.

There are basically 2 questions I have:
1) why does the boost/shared_ptr.hpp inclusion effect a
boost::lexical_cast<std::string, std::vector> declaration?

See above.

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

See above.


Cheers, & hth.,

- Alf

 

[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.hpp>
#include <iostream>
#include <vector>
#include <string>

namespace mytest {

//--------------------------------------------------------------
//THIS DOES NOT COMPILE (it's commented out)
//typedef std::vector<std::string> stringvector;

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

//--------------------------------------------------------------
template<class T> std:stream & operator<<(std:stream& s, const
std::vector<T> & d) {
std::copy(d.begin(), d.end(),
std:stream_iterator<std::string>(s, "\n"));
return s;
}
//--------------------------------------------------------------
template<class T> std::istream & operator>>(std::istream& s,
std::vector<T> & d) {
std::string line;
while (std::getline(s, line)) {
d.push_back(line);
}
return s;
}
}; // end mytest namespace

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

mytest::stringvector vecstr1;
vecstr1.push_back("hi");
vecstr1.push_back("there");
std::string str = boost::lexical_cast<std::string>(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.hpp>
#include <iostream>
#include <vector>
#include <string>

namespace mytest {

// IF I PLACE: using namespace mytest; - THIS WORKS
typedef std::vector<std::string> stringvector;

//--------------------------------------------------------------
template<class T> std:stream & operator<<(std:stream& s, const
std::vector<T> & d) {
std::copy(d.begin(), d.end(),
std:stream_iterator<std::string>(s, "\n"));
return s;
}
//--------------------------------------------------------------
template<class T> std::istream & operator>>(std::istream& s,
std::vector<T> & d) {
std::string line;
while (std::getline(s, line)) {
d.push_back(line);
}
return s;
}
}; // end mytest namespace

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

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

mytest::stringvector vecstr1;
vecstr1.push_back("hi");
vecstr1.push_back("there");
std::string str = boost::lexical_cast<std::string>(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?

 

[Alf P. Steinbach]

* (e-mail address removed):

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:

what does ADL stand for?

Argument Dependent Lookup, also known as Koenig lookup (after Andrew
Koenig). It essentially causes lookup in the namespaces of the actual
arguments to a function or operator call. This is how << usually works:
the definition is found in namespace std, because left arg is in std.

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.

[snip]

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.hpp>
#include <iostream>
#include <vector>
#include <string>

namespace mytest {

// IF I PLACE: using namespace mytest; - THIS WORKS
typedef std::vector<std::string> stringvector;

//--------------------------------------------------------------
template<class T> std:stream & operator<<(std:stream& s, const
std::vector<T> & d) {
std::copy(d.begin(), d.end(),
std:stream_iterator<std::string>(s, "\n"));
return s;
}
//--------------------------------------------------------------
template<class T> std::istream & operator>>(std::istream& s,
std::vector<T> & d) {
std::string line;
while (std::getline(s, line)) {
d.push_back(line);
}
return s;
}
}; // end mytest namespace

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

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

mytest::stringvector vecstr1;
vecstr1.push_back("hi");
vecstr1.push_back("there");
std::string str = boost::lexical_cast<std::string>(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?

Because the typedef doesn't define a type that causes ADL: it doesn't
define a type, only an alternate name for an existing type. Ordinary
lookup finds the global definitions of << (brought there by your "using"
directive), but not those hidden down in your namespace. See my reply
to your original post.

Cheers, & hth.,

- Alf

 

[hsmit.home]

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

Cheers, & ydh., (you did help)

Hans

 

[James Kanze]

* (e-mail address removed):

[...]

Here's the code.
#include <boost/lexical_cast.hpp>
#include <iostream>
#include <vector>
#include <string>
//--------------------------------------------------------------
template<class T>
std:stream & operator<<(std:stream& 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::string> vecstr1;
vecstr1.push_back("hi");
vecstr1.push_back("there");
std::string str = boost::lexical_cast<std::string>(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.hpp). 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:stream&
operator<<( std:stream& dest, std::vector< int > const& src )
{
dest << '[' ;
for ( std::vector< int >::const_iterator 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_back( 10* i + j ) ;
}
}
std::copy( v.begin(), v.end(),

( 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.hpp>
#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.hpp(150) : while compiling class template member function
'bool boost::detail::lexical_stream<Target,Source>:perator <<(const
Source &)'
with
[
Target=std::string,
Source=NewSource
]
lexical_cast.hpp(219) : see reference to class template instantiation
'boost::detail::lexical_stream<Target,Source>' being compiled
with
[
Target=std::string,
Source=NewSource
]
main.cpp(38) : see reference to function template instantiation
'Target boost::lexical_cast<std::string,std::vector<_Ty>>(const Source
&)' being compiled
with
[
Target=std::string,
_Ty=std::string,
Source=std::vector<std::string>
]
lexical_cast.hpp(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_ostream<E, T>& operator<<(
std::basic_ostream<E, T> & os, shared_ptr<Y> const & 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_stringstream<>. Neither of which are in namespace
boost!

In the end, boost::lexical_cast<std::string>(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.