- Boost - lists.boost.org

[numeric][ublas] trunk testing broken
by K. Noel Belcourt 06 Mar '10

06 Mar '10

Hi, Trunk testing broke with this commit: https://svn.boost.org/trac/boost/changeset/60156 Here's the error message. error: Unable to find file or target named error: 'test_coordinate_matrix_sort.cpp' error: referred from project at error: '../libs/numeric/ublas/test' Could someone please add this missing file or revert the commit? Thanks. -- Noel

3 3

[propertytree] Own storage
by Adam Badura 06 Mar '10

06 Mar '10

Are end users allowed to provide own parsers to populate property tree? For example for the (not yet available) Windows Registry? Or is this discouraged? If not then maybe adding a simple example to the documentation would be a good idea? Adam Badura

2 3

[log] init methods and named parameters
by Michael Caisse 05 Mar '10

05 Mar '10

I've gotten a head start looking at the boost.log library that will be reviewed in a couple weeks. The utility methods utilize boost.parameter's named parameters. For example, boost::log::init_log_to_file. I would like to decide at runtime (via a config file) which set of parameters will listed. For example, rotation_size or rotation_interval or both. It is my first real use of boost.parameter so I may be missing something that is common knowledge. I don't see an easy way to do this. I thought maybe building a fusion sequence of parameters or something like that was the way to go... Looking for guidance. Thanks. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

3 8

filesystem utf-8 support?
by Jochen Wilhelmy 05 Mar '10

05 Mar '10

Hi! I wonder if boost::filesystem has support for utf-8. especially for windows this means that all path names have to be converted from utf-16 to utf-8 and back internally by boost::filesystem. for unix-like systems this may not be necessary as the locale can be set to utf-8 but auto-conversion for non-utf-8 locales would still be good. -Jochen

1 0

[boost.atomic] linker error with gcc 4.1.2
by Jamie Allsop 05 Mar '10

05 Mar '10

With gcc 4.1.2 (gcc 4.3.x is fine) I am seeing this linker error: .build/debug/working/SourceOne.o: In function `void boost::detail::atomic::platform_atomic_thread_fence<boost::memory_order>(boost::memory_order)': /thirdparty/boost/boost_1_42/boost/smart_ptr/detail/shared_count.hpp:229: multiple definition of `void boost::detail::atomic::platform_atomic_thread_fence<boost::memory_order>(boost::memory_order)' .build/debug/working/SourceTwo.o: /thirdparty/boost/boost_1_42/boost/atomic/detail/gcc-x86.hpp:63: first defined here Which doesn't make a lot of sense at first glance, but on closer inspection I see that: boost/atomic/detail/base.hpp defines platform_atomic_thread_fence as: template<typename T> static inline void platform_atomic_thread_fence(T order) { /* FIXME: this does not provide sequential consistency, need one global variable for that... */ platform_atomic<int> a; a.exchange(0, order); } and then it is defined as a specialisation in: boost/atomic/detail/gcc-x86.hpp as: template<> void platform_atomic_thread_fence(memory_order order) { switch(order) { case memory_order_seq_cst: full_fence(); case memory_order_acquire: case memory_order_consume: case memory_order_acq_rel: case memory_order_release: __asm__ __volatile__ ("" ::: "memory"); default:; } } Is this a compiler error or should the specialisation be declared as: template<> inline void platform_atomic_thread_fence(memory_order order) (which will work) Suggestions? Jamie

3 4

[type traits] add a set of templates to propagate const etc from one type to another?
by Vasilis Vasaitis 04 Mar '10

04 Mar '10

Hello, I've been looking at the Type Traits library recently, and it looks wonderful overall. However, it's lacking a use case that I end up needing quite often, so I thought I'd suggest it in case the authors and/or other users of the library find it useful. Allow me to explain. So Type Traits has the add_const / remove_const / is_const triplet (and similar for a few other type properties). add_const is great when you always know that you want to add the const, but sometimes you only want to do it conditionally to another type being const. So recently I've ended up using something like this from quite a few places in my code: template<class Source, class Target> struct propagate_const { typedef Target type; }; template<class Source, class Target> struct propagate_const<const Source, Target> { typedef const Target type; }; That is, propagate_const<Source, Target> will only add const to Target if Source is const too. What are the use cases for this? Well, for example recently I was writing an iterator class, and I wanted to avoid duplicating the code for the const_iterator case. Not a big deal, as it turned out, as I could just pass a const type as the template argument and have it behave as the const iterator. The only problem was that I was doing some pointer arithmetic with reinterpret_casts from T* to char* and back (where T is the template argument), so the compiler would complain if T was const. So instead of char I defined this: typedef typename propagate_const<T, char>::type char_type; Of course I could also have done this with a combination of is_const and add_const, but this would probably require more code than the propagate_const definition above. So what do people think? Would it be a useful addition alongside add_* and remove_*? Thanks, Vasilis P.S. Please CC me in your replies, as I've set the mailing lists to not send me emails (similar to not being subscribed). -- Vasilis Vasaitis "A man is well or woe as he thinks himself so."

10 18

command line parameters parser
by Denis Shevchenko 04 Mar '10

04 Mar '10

Hi! Sorry for my English, I am from Russia. Is there any interest in a library which parse command line parameters and call correspond functions/functors? Features: - check type of parameter, - check "value semantic" of parameter, - set necessity of parameter, - maybe set default value for parameter, - some other settings. Example: void help() { std::cout << "This is my help info!" << std::endl; ::exit( 0 ); // Exit after printing help info. } struct config_file { void operator()( const std::string& file ) { // Some work with obtaining file path. } }; void limit( const std::string& some_limit_value ) { // int limit = boost::lexical_cast< int >( some_limit_value ); // ... } int main( int argc, char* argv[] ) { typedef command_line_parameter_parser clp_parser; clp_parser parser; parser.add_parameter( "-h", "--help", help ); // Short and full names, in Unix tradition. // In this case we define parameter with one name and value (it is must be valid path); // Without check_value() obtaining path will not be checked. parser.add_parameter( "--config", config_file, clp_parser::with_value ).check_value( clp_parser::path ); parser.add_parameter( "-l", "--limit", limit ).check_type( clp_parser::integer ); // Is integer? parser.set_value_separator( ':' ); // "--config:/home/file.conf" instead default "--config=/home/file.conf" try { parser.parse( argc, argv ); } catch ( const std::exception& exc ) { std::cerr << exc.what() << std::endl; } ... return 0; } Denis

3 7

[1.39][preprocessor] "preprocessor/wstringize.hpp" not included by "preprocessor.hpp"
by Adam Badura 04 Mar '10

04 Mar '10

It seems that "preprocessor.hpp" includes (through "preprocessor/library.hpp") "preprocessor/stringize.hpp" but not "preprocessor/wstringize.hpp". I don't know whether this occurs in 1.42 as well but I guess it may. Adam Badura

1 0

boost::optional<A,B,...>
by Daniel Larimer 04 Mar '10

04 Mar '10

I have a situation where I have a class that stores two mutually exclusive optional values. This results in double overhead of two bools and twice the "reserved" space. I could opt for a boost::optional<boost::variant<A,B> >, but this would incur extra costs associated with the implementation of boost::variant. Considering the fact that boost::variant<> explicitly guarantees to be always "valid", it seems like it would be reasonable to have boost::optional<A,...> that behaves like boost::variant<>, yet is optimized specifically for allowing "empty" states as well. The boolean could then become the type index where 0 is empty, 1 is A, 2 is B etc. Thoughts? Dan

4 3

[rfc] rcpp
by Ivan Sorokin 04 Mar '10

04 Mar '10

Hello! I have a small library that is intended for convenient and declarative resource wrappers creation. Read Documentation: http://rain.ifmo.ru/~sorokin/rcpp/doc/index.html Main Page: http://rain.ifmo.ru/~sorokin/rcpp/ Although this library is small I think it is useful. I think it is possible to use it in implementations of asio, filesystem and thread. **-- Ivan Sorokin

6 16