- Boost - lists.boost.org

[locale] UTF Iteration and conversion
by Artyom Beilis 25 Jul '11

25 Jul '11

Hello All, Following this discussion: [regex] How robust are the <boost/regex/pending/unicode_iterator.hpp> adapters? http://thread.gmane.org/gmane.comp.lib.boost.devel/221643 Boost.Locale will ship **header-only** utf_to_utf conversion functions and provide operations that would allow implementing iteration over UTF-XX sequences. This was one of the review requests and it will be integrated in few days into trunk. Functions: namespace boost { namespace locale { namespace conv { template<typename CharOut,typename CharIn> std::basic_string<CharOut> conv::utf_to_utf(CharIn const *begin,CharIn const *end,method_type how=skip); template<typename CharOut,typename CharIn> std::basic_string<CharOut> conv::utf_to_utf(CharIn const *str,method_type how=skip); template<typename CharOut,typename CharIn> std::basic_string<CharOut> conv::utf_to_utf(std::basic_string<CharIn> const &str,method_type how=skip); }}} // boost::locale::conv Also it would provide basic utf encoding/decoding operations that would allow to create iterators over generic streams namespace boost { namespace locale { namespace utf { typedef uint32_t code_point; static const code_point illegal = ... ; static const code_point incomplete = ... ; // Get one code point from UTF stream template<typename InputIterator> code_point decode(InputIterator &p,InputIterator e); // Write one code point to UTF stream template<typename OutputIterator> Iterator encode(code_point u,OutputIterator e); // Get size of code point in basic unit template<typename CharType> int units_in_code_point(code_point u); }}} // boost::locale::utf It should be ready very soon... Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

1 0

[asio] gcc visibility support patch
by Jürgen Hunold 25 Jul '11

25 Jul '11

Hi, I've found some missing patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.Asio For more information, please see http://gcc.gnu.org/wiki/Visibility 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 5

[lockfree review] rfc: naming and interface
by Tim Blechmann 25 Jul '11

25 Jul '11

hi all, i am starting a new thread, because i want to start a new discussion on one aspect of boost.lockfree: the naming of the data structure and the interface naming: the current names of the data structures are fifo, stack and ringbuffer. during the pre-review some people suggested to use different names, lifo instead of stack or queue instead of fifo. in general i think it is a good idea to use a consistent naming (probably fifo should be renamed to queue), but how does the ringbuffer come in? it is a queue as well, but with different characteristics (spsc and wait-free). data structure configuration: stack and fifo currently use 3 template arguments: T for the managed type, freelist_t as a tag to select the underlying freelist and Alloc as the allocator which is used for the internal nodes: template<typename T, typename freelist_t = caching_freelist_t, typename Alloc = std::allocator<T> > class fifo/stack; however i have been thinking about replacing it with a boost.parameter interface, something like: template<typename T, ... Options> class fifo/stack; with the options: boost::lockfree::freelist_can_allocate<true/false> to disable memory allocation during enqueue/push boost::lockfree::allocator<> to specify the allocator ringbuffer size: the ringbuffer currently has the signature: template<typename T, size_t max_size> class ringbuffer; if max_size is 0, the size of the ringbuffer can be configured at run-time with a constructor. this is not really the cleanest interface, but i would like to provide an interface, which supports both compile-time and run-time setting of the size. i would apprechiate a discussion about these points during the review. thanks, tim

7 10

Re: [boost] Bugs in regression/library_status.cpp on Windows
by Robert Kawulak 24 Jul '11

24 Jul '11

Hi, Could anybody please apply that patch or suggest what can I do (or whom to contact directly) to get this fixed? BTW, I wonder how it's possible that most of the bugs were introduced in one commit half a year ago and nobody even noticed - it would suffice to run this app on any platform to get obvious errors while on Windows it wouldn't even compile. Am I really the only person using this tool? :P I've also found another minor problems: - when building it, "$(BOOST_ROOT)\tools\regression\build\bin" directory is created but it's not marked with "ignore" in SVN; - char_xlate functor only translates '/' character in URLs while on Windows the character used is '\' (and it also causes problems in some browsers). The solution is very simple - add "|| c = '\\'" in line 75. I'm attaching a patch file combining the previous fixes and the '\' translation. Best regards, Robert > -----Original Message----- > From: Robert Kawulak [mailto:Robert.Kawulak@gmail.com] > Sent: Saturday, July 09, 2011 11:35 PM > To: 'boost(a)lists.boost.org' > Cc: 'bdawes(a)acm.org'; 'blelbach(a)cct.lsu.edu' > Subject: Bugs in regression/library_status.cpp on Windows > > Hello, > > I've stumbled upon several bugs in > tools/regression/src/library_status.cpp when compiling on Windows with > gcc 4.5 and msvc 10.0. I'm attaching a patch file with all necessary > fixes. The bugs are: > > - using path::native() instead of path::string() - the former is > wstring on Windows, > - calling path::string() twice to obtain begin() and end() iterators - > on Windows path::string() returns a temporary, so the iterators point > to different objects, > - using whole path for each node in build_node_tree() instead of only > the directory name, > - using whole path instead of only the test name in do_table_body(), > - the link to links file is relative to test directory, not to the > results output directory, > - generation of closing "</a>" without opening "<a>". > > Best regards, > Robert

1 0

[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