November 2006 - Boost-users

Re: [Boost-users] [filesystem] unable to parse file path
by Nat Goodspeed 06 Nov '06

06 Nov '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Küppers, Ben > Sent: Monday, November 06, 2006 2:59 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [filesystem] unable to parse file path > > Ongoing development now warrants that we interact with the Windows > apps from Linux and vice versa. In the midst of all this it becomes > inevitable to run into the occasional Windows file path on Linux (or Linux > path on Windows)(usually through file IO). I use portable paths wherever I > can but I don't have control over all the input. [Nat] I see. But it should work to convert to forward-slashes everywhere. Sorry for being terse earlier. When I said a character-substitution pass is "cheaper" than reimplementing any significant part of boost::filesystem, I was really thinking of coding/maintenance time. > I am disappointed that the library eliminates the code to treat > backslashes as directory separators at compile-time on non-Windows systems > and doesn't provide me with an option to explicitly enable this code for > the few file paths that I know will have a Windows syntax. [Nat] That could be a useful enhancement. If you're interested enough, you might submit a code and documentation patch. Until then, maybe you could introduce a path subclass for your own use that replaces all '\' with '/' before passing the input path string to the base class.

1 0

[mpl::map] generating map for 150 types
by Ovanes Markarian 06 Nov '06

06 Nov '06

Hi! I need to define a map with int_<1...150>->Type1...150 pairs. Im source file I define: #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #define BOOST_MPL_LIMIT_MAP_SIZE 150 #include <boost/mpl/map.hpp> When compiling I get an error in the file: ...\boost\include\boost-1_33_1\boost\mpl\map.hpp on line: 36 fatal error C1083: Cannot open include file: 'boost/mpl/map/map150.hpp': No such file or directory Development environment is Visual C++ 8 Express Edition The help states: BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS is an boolean configuration macro regulating library's internal use of preprocessed headers. When defined, it instructs the MPL to discard the pre-generated headers found in boost/mpl/aux_/preprocessed directory and use preprocessor metaprogramming techniques to generate the necessary versions of the library components on the fly. In this implementation of the library, the macro is not defined by default. To change the default configuration, define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS before including any library header. I did what is written here and get this compiler error. Can someone suggest smth? With Kind Regards, Ovanes Markarian

3 6

Re: [Boost-users] [filesystem] unable to parse file path
by Küppers, Ben 06 Nov '06

06 Nov '06

> [Nat] I guess I have a couple of comments. > > One is that a character substitution pass is still cheaper than the > directory parsing and other goodies that boost::filesystem gets you. Speed is not a concern. > The other is to ask why your *nix requirements include backslashes as > directory separators? Backslashes have other significance everywhere but > Windows, which is presumably why boost::filesystem::path wasn't written to > treat '\' and '/' interchangeably on all platforms. Backslashes (and > forward slashes) work on Windows, forward slashes work elsewhere, all per > convention. I work on a large application that runs on Windows and Linux and interacts with various 3rd party applications on either platform, all of them designed with only the dedicated platform in mind and thus using native syntax. Ongoing development now warrants that we interact with the Windows apps from Linux and vice versa. In the midst of all this it becomes inevitable to run into the occasional Windows file path on Linux (or Linux path on Windows)(usually through file IO). I use portable paths wherever I can but I don't have control over all the input. > You seem disappointed that boost::filesystem::path doesn't treat > backslashes as directory separators on non-Windows systems. Not quite, I am disappointed that the library eliminates the code to treat backslashes as directory separators at compile-time on non-Windows systems and doesn't provide me with an option to explicitly enable this code for the few file paths that I know will have a Windows syntax. Note that because Windows supports either directory separator it is possible to parse a Linux relative file path on Windows (with minimal limitations). This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

[variant] trouble using recursive_variant with MSVC ...
by Andy Wu 06 Nov '06

06 Nov '06

Hi all, I'm trying to use the recursive variant as following: typedef boost::make_recursive_variant< int, std::vector<boost::recursive_variant_>, std::map<std::string, boost::recursive_variant_> >::type var_t; ... var_t var(34); ... VC 8.0 can not compile with error C2079: 'std::pair<_Ty1,_Ty2>::second' uses undefined struct 'boost::recursive_variant_' Struct recursive_variant_ is declared but not implement at all. But GCC works well. I'm confused how to solve the problem. Here is the whole program: #include "boost/variant.hpp" #include <iostream> #include <sstream> #include <vector> #include <map> struct vector_printer : boost::static_visitor<std::string> { template <typename T> std::string *operator*()(const std::vector<T>& vec) const { std::ostringstream ost; ost << "( "; typename std::vector<T>::const_iterator it = vec.begin(); *for* (; it != vec.end(); ++it) ost << boost::apply_visitor( vector_printer(), *it ); ost << ") "; *return* ost.str(); } template <typename T> std::string *operator*()(const std::map<std::string, T>& m) const { std::ostringstream ost; ost << "( "; typename std::map<std::string, T>::const_iterator it = m.begin(); *for* (; it != m.end(); ++it) ost << it->first << '\t' << boost::apply_visitor( vector_printer(), it->second ); ost << ") "; *return* ost.str(); } template <typename T> std::string *operator*()(const T& operand) const { std::ostringstream ost; ost << operand << ' '; *return* ost.str(); } }; int main(int , char* []) { typedef boost::make_recursive_variant< int, std::vector<boost::recursive_variant_>, std::map<std::string, boost::recursive_variant_> >::type var_t; std::vector<var_t> vec; vec.push_back(3); vec.push_back(5); vec.push_back(vec); vec.push_back(7); var_t var(vec); std::string result( boost::apply_visitor( vector_printer(), var ) ); std::cout << "result: " << result << '\n'; *return* 0; } And the compile error from VC8 is : test_map_variant.cpp D:\Program\boost\boost_1_33_1\boost/type_traits/is_base_and_derived.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss D:\Program\boost\boost_1_33_1\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss D:\Program\boost\boost_1_33_1\boost/type_traits/is_base_and_derived.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss D:\Program\boost\boost_1_33_1\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss D:\Program\boost\boost_1_33_1\boost/utility/enable_if.hpp : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss D:\Program\vs8\VC\INCLUDE\utility(54) : error C2079: 'std::pair<_Ty1,_Ty2>::second' uses undefined struct 'boost::recursive_variant_' with [ _Ty1=const std::string, _Ty2=boost::recursive_variant_ ] D:\Program\vs8\VC\INCLUDE\vector(1083) : see reference to class template instantiation 'std::pair<_Ty1,_Ty2>' being compiled with [ _Ty1=const std::string, _Ty2=boost::recursive_variant_ ] D:\Program\vs8\VC\INCLUDE\vector(1082) : while compiling class template member function 'void std::vector<_Ty>::_Destroy(boost::variant<T0_,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16,T17,T18,T19> *,boost::variant<T0_,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16,T17,T18,T19> *)' with [ _Ty=var_t, T0_=boost::detail::variant::recursive_flag<int>, T1=std::vector<boost::recursive_variant_>, T2=std::map<std::string,boost::recursive_variant_>, T3=boost::detail::variant::void_, T4=boost::detail::variant::void_, T5=boost::detail::variant::void_, T6=boost::detail::variant::void_, T7=boost::detail::variant::void_, T8=boost::detail::variant::void_, T9=boost::detail::variant::void_, T10=boost::detail::variant::void_, T11=boost::detail::variant::void_, T12=boost::detail::variant::void_, T13=boost::detail::variant::void_, T14=boost::detail::variant::void_, T15=boost::detail::variant::void_, T16=boost::detail::variant::void_, T17=boost::detail::variant::void_, T18=boost::detail::variant::void_, T19=boost::detail::variant::void_ ] test_map_variant.cpp(63) : see reference to class template instantiation 'std::vector<_Ty>' being compiled with [ _Ty=var_t ] -- B. R. Andy

1 0

[asio] doc directory not present in cvs?
by Andrew Schweitzer 05 Nov '06

05 Nov '06

I assume this is on purpose? Because doc isn't updated to latest changes? Doc is included if I download 0.3.7

2 2

Any interest in a separate Boost.TR1 release/download?
by John Maddock 05 Nov '06

05 Nov '06

I wonder if people would find a separate download for the Boost TR1 components useful ? At present this is vapourware: I'm not sure how easy it will be to sort out documentation and build issues when extracting the TR1 subset, but I'm prepared to put together a preliminary (alpha) release of such a beast if there's demand, and from there we can at least see how viable releasing such a Boost subset would be. Thought? Thanks, John.

4 3

Re: [Boost-users] [mpl::map] generating map for 150 types
by Ovanes Markarian 05 Nov '06

05 Nov '06

Dave, Sorry for my misleading words, the meaning was: As more as I can pre-calculate code at compile time (means slower compilation times) and substitute runtime calculation the more speed I get at runtime. Hope that was what you were meaning in the MPL book. I also understand, that I can bloat compiler with unnecessary calculations without any gain in speed, but my initial sentence was a thank to you an Aleksey for such a nice lib, which can boost the runtime speed if used properly ;) Thanks, Ovanes. -----Original Message----- From: David Abrahams [mailto:dave@boost-consulting.com] Sent: Saturday, November 04, 2006 7:18 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [mpl::map] generating map for 150 types "Ovanes Markarian" <om_boost(a)keywallet.com> writes: > Aleksey, > > Many thanks for your detailed reply. I think the second scenario with > pre-generated headers convinces me more, since our compilation times > are not optimal at all :(. But as you stated in the book: more work > for compiler means less work at runtime. In this case you won't get any runtime speedups by using the method that's slower at compile time. > These were not exactly the words, but I can remember the meaning. I'm not sure you got the meaning exactly right either ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

[Boost.python] Converting python file object to std::istream.
by Dan 04 Nov '06

04 Nov '06

I am exposing a C++ class to python that takes a reference to a std::istream object and operates on it. It looks something like this: class StreamReader { public: StreamReader(std::istream& strm); private: std::istream& strm_; } I would like to expose this class to python allowing a python client to pass in any python file type object (regular file object, StringIO object, stdin, etc.), as a C++ client would be able to pass any std::istream derived object. Now it seems to me that someone must have encountered this problem before, but I haven't seen any references as to how to make this work. Any ideas on the best way to proceed would be appreciated. thanks, Dan

2 1

[mpl::map & mpl::transform] Problems using mpl::map in mpl::for_each
by Ovanes Markarian 04 Nov '06

04 Nov '06

Hello, I have some slightly different code, which is presented in C++ Template Metaprogramming book to use the mpl::for_each function: mpl::for_each< mpl::transform<seq, wrap<_1> >::type >(dispatcher_type()); The deviation from the book is that my seq it not mpl::vector<...>, but mpl::map<...> In the docs is written, that mpl::transform operates on Forward Sequence. In the doc of forward sequence is stated that mpl::map is a model of it. Unfortunately this code does not compile. I could transform the map to vector, but I would not like doing it, since that would cost compile time and slow down the compilation. Is it a known issue or should not I expect map to work with transform? I also tried using itertors on seq, but that did not help. With Kind Regards, Ovanes Markarian

2 6

Re: [Boost-users] Building boost with icl 9
by Sohail Somani 03 Nov '06

03 Nov '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org] On Behalf Of John Maddock > Actually you can ignore that message as it happens: it's a > compiler message > and the lib's should still build OK. It was inserted in > because we hadn't > tested the last release with Intel 9 (it didn't exist then), > however there > are no configuration changes required compared to previous > Intel versions, > so you can just ignor the message if you want. If it's > annoying, then > comment out the line in boost/config/compiler/intel.hpp that > generates it. Ok, I did ignore it and it seemed to work fine. Thanks.

1 0