July 2011 - Boost - lists.boost.org

[filesystem] home_directory_path
by Jeff Flinn 24 Jul '11

24 Jul '11

In looking at implementing a portable home_directory_path function a few questions arise. Based on http://en.wikipedia.org/wiki/Home_directory, POSIX and other UNIX flavors 'appear' to be a straight forward use of the "HOME" environment variable. Does anyone have any experience where the "HOME" variable is not the proper source of the user's home directory? Windows NT and above have the "USERPROFILE" environment variable. Using this would be the easiest to use. But I've seen discussion that this may not always be properly defined, in particular if the user has reset their home directory to a non-system drive. I haven't tracked down it's availability on WinCE. Does anyone have experience with this platform? There is the windows GetUserProfileDirectory api function also available since NT4. This is in the Userenv.lib/dll, obviously adding a link dependancy. How are these sorts of system link dependencies handled? Through bjam? Or is it acceptable/better to use #pragma comment(lib,"Userenv.lib")? In looking at some client code using home_directory_path, I see that they generally are looking for the user's Desktop directory(Mac & Windows). Obviously this only makes sense on GUI platforms. The issue with merely getting this path via home_directory_path() / "Desktop" is IIRC, that at least on windows "Desktop" is localized and may not exist with that name on non-english localized systems. Windows has the SHGetFolderPath api. I need to look into Mac's native support. Any thoughts on the general usefulness of a portable desktop_directory_path? Thanks, Jeff

16 60

[Geometry] Problem with assign
by Hartmut Kaiser 24 Jul '11

24 Jul '11

The following fails to compile: #include <boost/geometry.hpp> #include <boost/geometry/geometries/point_xy.hpp> #include <boost/geometry/geometries/polygon.hpp> int main() { typedef boost::geometry::model::d2::point_xy<int> int_point_type; typedef boost::geometry::model::polygon<int_point_type> int_polygon_type; typedef boost::geometry::model::d2::point_xy<double> double_point_type; typedef boost::geometry::model::polygon<double_point_type> double_polygon_type; int_polygon_type ip; double_polygon_type dp; boost::geometry::assign(dp, ip); return 0; } Shouldn't it actually compile? Regards Hartmut --------------- http://boost-spirit.com

2 5

[graph] gcc visibility support patch
by Jürgen Hunold 23 Jul '11

23 Jul '11

Hi, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.Graph For more information, please see http://gcc.gnu.org/wiki/Visibility Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

[General] Treat narrow strings as UTF-8 (compilation flag)
by Yakov Galka 23 Jul '11

23 Jul '11

Hello All, About half a year ago there was a long discussion titled "Always treat std::strings as UTF-8". The only objection to the proposal was that making an instant switch by assuming UTF-8 by default will give surprising results to those who're unaware of the convention (or prefer using legacy encodings instead of UTF-8). This applies almost only to Windows developers. However, there are already many projects and organizations that switched to UTF-8 even for Windows programming. The company I work in is one of them. Nowadays: ========== All the libraries that accept narrow strings assume the system encoding by default. * filesystem::path — Can be configured through static imbue() function. * system_error_category (windows error description), interprocess (object names)... more? — Don't support Unicode at all. They use the narrow API on Windows. * program_options — Assumes UTF-8 for internal data (Good!), but uses system encoding for paths (parse_config_file) and for environment variables (Bad...) . Note that, e.g. path::imbue(), is a painful solution for two reasons: Any global state initialization is problematic in dynamically-linked, multi-threaded systems (like the one I'm maintaining now). In such cases a compile time configuration is more attractive. I really don't want to have such a function in each boost library (can be solved by having a global boost::imbue though). Proposal: ======== Add a compile-time configuration flag that causes boost to treat all narrow strings as UTF-8. The flag will be off by default. For example, in filesystem it's a matter of setting `codepage` to CP_UTF8 in just two places. Rationale: ========== Those who are ready to move to the UTF-8 future, they can do it by simply setting a compilation flag.. Those who don't care about Unicode correctness are not affected by the addition. There won't be any complaints to boost, like: "Hey! I use boost with these libraries and it doesn't work. Your encoding is wrong!". -- Yakov Galka

4 5

[Config] Cray compiler
by Marshall Galbraith 23 Jul '11

23 Jul '11

Hello, I am using a few boost libraries for a research code that I am developing. I currently have access to a Cray XE6 machine (http://www.cray.com/Products/XE/Specifications.aspx) along with the Cray Compiler Environment. I would like to compile my code with the Cray compiler so I can use their Cray PAT utilities for performance testing. I was able to generate a user.hpp file for the Cray compiler, but it is automatically generated and I am not verse enough with the compilation of boost to ensure that it is correct. If there is any interest in developing a Cray configuration for compiling boost, I am more than interested in helping. I can also get in touch with the Cray compiler developers for assistance with any compiler issues. Looking through the history of this mail list there was an initiative to do this back in 2003, but it did not seem to come to fruition. Thank you for all your help, Marshall Galbraith

2 1

[TTI] Why add to boost namespace?
by Noah Roberts 23 Jul '11

23 Jul '11

Why do the macros add templates to the boost::tti namespace rather than the current one? One thing I get from the way MPL create the has_xxx metafunctions is that I can do this: template < typename T > struct obeys_xxx_concept { BOOST_MPL_HAS_XXX_TRAIT_DEF(some_trait) ... etc... enum { value = etc_checks<T>(0).... && has_some_trait<T>::value }; typedef boost::mpl::bool_<value> type; }; That wouldn't work with the TTI library it appears. What does putting the templates in the boost::tti namespace do for me to make up for this loss?

3 2

Can't check out from sandbox
by Noah Roberts 22 Jul '11

22 Jul '11

I want to do some review or at least experimenting with TTI but I can't get it. Every time I try I get this message: Checkout from http://svn.boost.org/svn/boost/sandbox/tti, revision HEAD, Fully recursive, Externals included REPORT of '/svn/boost/!svn/vcc/default': Could not parse chunk size (http://svn.boost.org) There a workaround?

2 2

Boost 1.44.0 - Problem with optional matching
by programmer1 22 Jul '11

22 Jul '11

I'm attempting to match a floating point literal which can contain several optional tokens. Even though the rule succeeds, it doesn't return all the symbols which make up the token. Example Consider the following. Even though the parser succeeds, it returns only "Km" in the match string. Why is that? I expect "-666.0e-45km". std::string phrase = "-666.0e-45km"; std::string val; std::cout << "res: " << parse_number(phrase.begin(), phrase.end(), val) << std::endl; /* prints "1" */ std::cout << val << std::endl; /* prints "km" */ grammar Here is the grammar which I'm trying to express in Spirit. Notice how it is slightly different from the built-in rule "double_" <number> := <decimal> | "INF" | "-INF" | "NaN" <decimal> := ["-"] <digits> ["." <digits>] [<exp>] [<unit>] <exp> := ("e"|"E") ["+"|"-"] <digits> <digits> := <digit> (<digit> | "_")* <digit> := ('0' - '9') <unit> := <unitChar>* <unitChar> := <alpha> | "%" | "_" | "/" | "$" | any char > 128 // see sys::Unit Code namespace qi = boost::spirit::qi; namespace ascii = boost::spirit::ascii; namespace phoenix = boost::phoenix; template <typename Iterator> struct number_grammar : qi::grammar<Iterator, std::string(), ascii::space_type> { number_grammar() : number_grammar::base_type(number, "number") { using qi::lit; using ascii::char_; using qi::digit; using ascii::string; using qi::alpha; using qi::on_error; using qi::fail; using phoenix::construct; using phoenix::val; unitChar = alpha | char_('%') | char_('_') | char_('/') | char_('$') ; // | any char > 128 // see sys::Unit unit = *unitChar ; digits = digit > *( digit | lit('_') ) ; exp = ( char_('e') | char_('E') ) > -( char_('+') | char_('-') ) > digits ; decimal = -char_('-') > digits > -( char_('.') > digits ) > -exp > -unit ; number = string("INF") | string("-INF") | string("NaN") | decimal ; on_error<fail> ( number, std::cout << val("Error! Expecting ") << qi::_4 // what failed? << val(" here: \"") << construct<std::string>(qi::_3, qi::_2) // iterators to error-pos, end << val("\"") << std::endl ); } qi::rule< Iterator, std::string(), ascii::space_type > number; qi::rule< Iterator, std::string() > decimal; qi::rule< Iterator, std::string() > exp; qi::rule< Iterator, std::string() > digits; qi::rule< Iterator, std::string() > unit; qi::rule< Iterator, char() > unitChar; }; template <typename Iterator> bool parse_number(Iterator first, Iterator last, const std::string& val) { using qi::phrase_parse; using ascii::space; number_grammar<Iterator> grammar; bool r = phrase_parse ( first, /*< start iterator >*/ last, /*< end iterator >*/ grammar, /*< the parser >*/ space, /*< the skip-parser >*/ val ); std::cout << val << std::endl; if (first != last) // fail if we did not get a full match return false; return r; } -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-44-0-Problem-with-optional-match… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

[TR1] clang patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi John, the current clang (version 3.0 (trunk 135764)) is still emulating gcc-4.2.1 which leads to a lot of the tr1-tests failing with: boost/boost/tr1/detail/config_all.hpp:158:12: fatal error: '../4.2.1/utility' file not found # include BOOST_TR1_STD_HEADER(utility) ^ boost/boost/tr1/detail/config_all.hpp:100:44: note: expanded from: # define BOOST_TR1_STD_HEADER(name) <../__GNUC__.__GNUC_MINOR__.__GNUC_PATCHLEVEL__/name> ^ 1 error generated. if your installed gcc is not 4.2.1. The attached patch fixes this by introducing a special case for clang. This fixes all but eight tr1-tests for clang trunk. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 3

[iostreams] gcc visibility support patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.IOStreams For more information, please see http://gcc.gnu.org/wiki/Visibility Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0