| Home | Forums | Reviews | Guides | Newsgroups | Register | Search |
![]() |
| Thread Tools |
| hsmit.home@gmail.com |
|
|
|
| |
|
David Harmon
Guest
Posts: n/a
|
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 |
|
|
|
| |
|
hsmit.home@gmail.com
Guest
Posts: n/a
|
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? |
|
|
|
|
|||
|
|||
| hsmit.home@gmail.com |
|
James Kanze
Guest
Posts: n/a
|
On Nov 19, 8:14 pm, hsmit.h...@gmail.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.hpp> > #include <iostream> > #include <vector> > #include <string> > //-------------------------------------------------------------- > template<class T> > std: > 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: "\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>: > 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(3 > '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: > 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 |
|
Alf P. Steinbach
Guest
Posts: n/a
|
* :
> > 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: > 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>: > 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(3 > '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: > 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 |
|
hsmit.home@gmail.com
Guest
Posts: n/a
|
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: std::vector<T> & d) { std::copy(d.begin(), d.end(), std: 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: std::vector<T> & d) { std::copy(d.begin(), d.end(), std: 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? |
|
|
|
|
|||
|
|||
| hsmit.home@gmail.com |
|
Alf P. Steinbach
Guest
Posts: n/a
|
* :
> 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: > std::vector<T> & d) { > std::copy(d.begin(), d.end(), > std: > 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 |
|
hsmit.home@gmail.com
Guest
Posts: n/a
|
Once again, thanks. You have shed a lot of light on this subject.
Cheers, & ydh., (you did help) Hans |
|
|
|
|
|||
|
|||
| hsmit.home@gmail.com |
|
James Kanze
Guest
Posts: n/a
|
On Nov 20, 8:45 pm, "Alf P. Steinbach" <al...@start.no> wrote:
> * hsmit.h...@gmail.com: [...] > > Here's the code. > > #include <boost/lexical_cast.hpp> > > #include <iostream> > > #include <vector> > > #include <string> > > //-------------------------------------------------------------- > > template<class T> > > std: > > 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: operator<<( std: { 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: >( 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>: > > 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(3 > > '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 |
|
|
|
| |
![]() |
| Thread Tools | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| #include <boost/shared_ptr.hpp> or #include "boost/shared_ptr.hpp"? | Colin Caughie | C++ | 1 | 08-29-2006 02:19 PM |
| Problems mixing boost::lambda::bind and boost::shared_ptr.. | Toby Bradshaw | C++ | 6 | 06-02-2006 04:12 PM |
| SWsoft Acronis Disk Director Suite 9.0 Build 508, Acronis OS Selector 8.0 Build 917, Acronis Partition Expert 2003 Build 292, Acronis Power Utilities 2004 Build 502, F-SECURE.ANTI vIRUS.PROXY v1.10.17.WINALL, F-SECURE.ANTI vIRUS v5.50.10260 for CITRI | vvcd | Computer Support | 0 | 09-25-2004 01:38 AM |
| Boost + Python C/API: Mixing python return types with boost return types | Steve Knight | Python | 2 | 10-10-2003 10:11 AM |
| error with boost::shared_ptr<T> with incomplete T, VC7.1 ? | Philippe Guglielmetti | C++ | 4 | 10-09-2003 05:30 PM |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc..
SEO by vBSEO ©2010, Crawlability, Inc. |




