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

Discussion in 'C++' started by hsmit.home@gmail.com, Nov 19, 2007.

  1. Guest

    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::eek:stream & operator<<(std::eek: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>::eek: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::eek:stream & operator<<(std::eek: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
     
    , Nov 19, 2007
    #1
    1. Advertising

  2. David Harmon Guest

    Re: MSVC++ 2005 Express Ed. build error when mixing boost lexical_cast and shared_ptr

    On Mon, 19 Nov 2007 11:14:34 -0800 (PST) in comp.lang.c++,
    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.
     
    David Harmon, Nov 19, 2007
    #2
    1. Advertising

  3. Guest

    Re: MSVC++ 2005 Express Ed. build error when mixing boostlexical_cast and shared_ptr

    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?
     
    , Nov 20, 2007
    #3
  4. James Kanze Guest

    Re: MSVC++ 2005 Express Ed. build error when mixing boostlexical_cast and shared_ptr

    On Nov 19, 8:14 pm, 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.hpp>
    > #include <iostream>
    > #include <vector>
    > #include <string>


    > //--------------------------------------------------------------
    > template<class T>
    > std::eek:stream & operator<<(std::eek: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::eek: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>::eek: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::eek:stream & operator<<(std::eek: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
    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::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.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Nov 20, 2007
    #4
  5. * :
    >
    > 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::eek:stream & operator<<(std::eek: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>::eek: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::eek:stream & operator<<(std::eek: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

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Nov 20, 2007
    #5
  6. Guest

    Re: MSVC++ 2005 Express Ed. build error when mixing boostlexical_cast and shared_ptr

    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::eek:stream & operator<<(std::eek:stream& s, const
    std::vector<T> & d) {
    std::copy(d.begin(), d.end(),
    std::eek: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::eek:stream & operator<<(std::eek:stream& s, const
    std::vector<T> & d) {
    std::copy(d.begin(), d.end(),
    std::eek: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?
     
    , Nov 20, 2007
    #6
  7. Re: MSVC++ 2005 Express Ed. build error when mixing boost lexical_castand shared_ptr

    * :
    > 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?


    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::eek:stream & operator<<(std::eek:stream& s, const
    > std::vector<T> & d) {
    > std::copy(d.begin(), d.end(),
    > std::eek: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

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
     
    Alf P. Steinbach, Nov 20, 2007
    #7
  8. Guest

    Re: MSVC++ 2005 Express Ed. build error when mixing boostlexical_cast and shared_ptr

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

    Cheers, & ydh., (you did help)

    Hans
     
    , Nov 20, 2007
    #8
  9. James Kanze Guest

    Re: MSVC++ 2005 Express Ed. build error when mixing boostlexical_cast and shared_ptr

    On Nov 20, 8:45 pm, "Alf P. Steinbach" <> wrote:
    > * :


    [...]
    > > Here's the code.


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


    > > //--------------------------------------------------------------
    > > template<class T>
    > > std::eek:stream & operator<<(std::eek: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::eek:stream&
    operator<<( std::eek: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::eek:stream_iterator< 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.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>::eek: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.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
     
    James Kanze, Nov 21, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Knight
    Replies:
    2
    Views:
    780
    Steve Knight
    Oct 10, 2003
  2. Toby Bradshaw
    Replies:
    6
    Views:
    1,782
    Kai-Uwe Bux
    Jun 2, 2006
  3. Colin Caughie
    Replies:
    1
    Views:
    738
    Shooting
    Aug 29, 2006
  4. Replies:
    3
    Views:
    549
    Joseph Kesselman
    Sep 21, 2007
  5. Jake Henderson

    Visual Web Developer 2005 Express and SQL 2005 Express

    Jake Henderson, Mar 10, 2006, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    248
    Jake Henderson
    Mar 10, 2006
Loading...

Share This Page