March 2010 - Boost - lists.boost.org

Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox)
by vicente.botet 07 Mar '10

07 Mar '10

Hi, ----- Original Message ----- From: <strasser(a)uni-bremen.de> To: "vicente.botet" <vicente.botet(a)wanadoo.fr> Sent: Saturday, March 06, 2010 3:55 PM Subject: Re: [boost] [transact] transaction language macros (was: Re: [transact] code in sandbox) > > hi again, > > another thing, are you experienced with the various parsing libraries > of boost? No, I have made only some toy examples with Spirit long time ago. > I know that they're not capable of analyzing C++ code, but it seems to > me that the code transformation required for our little language > extension is fairly simple. > > boost has compliant preprocessor, so macros aren't a problem. > the most complicated thing would be to detect if a transaction is in a > user-loop or not, so the grammar would have to be able to read > for/while/... loops and correctly parse c++ scopes. > does anything like that already exist? To do something like that I will use LLVM that gives already this possibility. Of course starting to use LLVM will be not easy, but will open much more possibilities than a specific parsing. Best, Vicente

1 0

Re: [boost] [Boost-users] [Review] ITL review starts today, February 18th
by Joachim Faulhaber 06 Mar '10

06 Mar '10

Hi John, thank you for reviewing the ITL library! 2010/3/3 John Reid <j.reid(a)mail.cryst.bbk.ac.uk>: > Hartmut Kaiser wrote: >> >> The ITL is available from the boost vault: >> >> http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_2 >> _0.zip&directory=Containers > > I have to say first I have been evaluating the version of ITL called > itl_plus_3_2_1 rather than the version in the boost vault. Perhaps someone > can tell me whether that is a big mistake or not. Using itl_plus_3_2_1 is completely ok. It is a later release than the review version itl_3_2_0. But the differences are marginal. Also itl_plus_3_2_1 contains more than the core library that is submitted for review. But you did not refer to these parts. So everything is fine. >> Please always state in your review, whether you think the library should >> be >> accepted as a Boost library. > > I think it should be accepted subject to the inclusion of an interval tree > implementation. > >> >> - What is your evaluation of the design? > > I suspect that making the open/closedness of an interval a template > parameter would suit more users although I don't have a strong opinion on > this one. There has been a discussion on this point already. http://permalink.gmane.org/gmane.comp.lib.boost.devel/199905 For continuous data types it seems like interval bounds are needed as data member. For intervals of integral types the bound_type can be a static property. I will adapt the design in this point. >> - What is your evaluation of the implementation? > > I would have liked to see interval trees in the implementation. For what > I've needed the library for so far this has not been a problem as most of > the intervals don't overlap. In the future I can see use cases where the > lack of interval trees would make the library impractical. I don't know how > much impact adding an interval tree implementation would have on the > existing interface. I think the current implementation has its value and application. It should not and can not completely be replaced by an implementation based on an interval_tree. This would improve certain use cases but lead to problems in others. I will report on this in more detail. An interval_tree based split_interval_map will be a valuable optimization that should be done as an additional class template. The current implementation is fully functional, correct, useful and efficient in most cases of application. >> - What is your evaluation of the documentation? > > Good. A tutorial would be a welcome addition. Some functions were > undocumented, I'm assuming they're documented in the review version. The "handcrafted" documentation relates to the major interface of overloaded functions and function templates. In order to keep that short, more specific functions are only documented in the part of the documentation that is generated from doxygen comments: http://www.joachim-faulhaber.de/boost_itl/doc/libs/itl/doc/html/interval_te… And yes, there may be few that have been forgotten. Please tell me, which ones you missed specifically. >> - What is your evaluation of the potential usefulness of the library? > > Very useful. It seems to have many applications in several different > domains. > >> - Did you try to use the library? With what compiler? Did you have any >> problems? > > I used gcc 4.4.1 and boost.python to make a python module for most of the > main elements of the library. I used this module successfully in an > application in genomics. However so far I have only had use for the > SplitIntervalMap so I have not used most of the library. > >> - How much effort did you put into your evaluation? A glance? A quick >> reading? In-depth study? > > A reasonable amount - enough to get up to speed and use the library. > >> - Are you knowledgeable about the problem domain? > > Not especially. > Thank you again. Best regards, Joachim

4 24

[BGL] Testing a graph for bipartiteness
by Matthias Walter 06 Mar '10

06 Mar '10

Hi, I'm working on a project where I need to determine whether a given graph is bipartite (possible yielding certificates for the two cases). As such a test can be perfectly implemented via BFS and visitor patterns, I wondered why there is no implementation in the BGL. Is there any reason or am I just to blind to find it? If I'm forced to write my own one, how about submitting it to BGL? best regards Matthias Walter

4 29

[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