- Boost - lists.preview.boost.org

RE: [boost] Re: FORMAL Review of "Output Formatter" library - 7 daysleft
by Reece Dunn 17 Sep '04

17 Sep '04

Jonathan Turkanis wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> wrote in message >news:BAY24-F288Jecd92bXC000d4659@hotmail.com... > > Although my library is still under review, I am re-architecturing it >based > > on the feedback thus far. This post is the code associated with what was >the > > delimiters/formatters part of the library. They are now given the better > > name of "decorators". > >Hi Reece, > > I'm planning to post a review [ favorable, presumably ;-) ], but >haven't >started to read the thread yet. Great. > I'm sorry I was never able to follow through on my ideas for your >library -- >I just got too busy with other things. No worries. >If there you feel there are some major >architectural changes that need to be made, I'm still interested in >collaborating. My main ideas were a introducing cascading style sheets and >inline formatters using expression templates. Formatters are dead! Long live decorators! ;) I am intrigued by the idea of cascading style sheets (CSS), but have a question regarding inlined formatters/decorators: What can you do with inlined decorators that you can't do with the format/decorate function? For example: namespace io = boost::io; namespace fmt = boost::io::format; std::cout << io::object( ob, fmt::container( fmt::pair().decorate( "( ", " )" )).decorate( "[{ ", " }]" ) ).decorate( " - " ); // output: [{ ( a, 5 ), ( b, -1 ) }] How do you envision CSS working? The way I see it is that you are viewing the format objects as HTML tags that have a style attribute associated with them that contains a set of ( attribute, value ) pairs (a std::map< std::string, std::string >?) This way, the decorate function would be the equivalent of setting the style attribute: fmt::pair().decorate( "( ", " )" ); // <pair style = "open: '( '; close: ' )';"/> You can also set CSS properties within script code, e.g. tag.style.fontFamily = "Times New Roman"; This style behaviour is available in the new decorators, for example: io::wrapper_decorators< char > wrap; wrap.open = "<< "; wrap.close = " >>"; If you save a format object for use later, e.g.: fmt::container_t< char, fmt::pair_t< char > > my_fo = fmt::container( fmt::pair()); The library should support decorating nested format objects, e.g.: my_fo.elem.open = "<< "; my_ob.elem.close = " >>"; my_ob.separator = " | "; std::cout << io::object( ob, my_ob ); // output: [ << a, 5 >> | << b, -1 >> ] HTML allows you to associate a stylesheet file with the HTML markup that sets how certain tags are displayed, e.g.: body{ color: red; } This will set the font colour of the body element to red. I suppose the equivalent here would be the various format objects (each having a "tag" name) and the style being saved on a stream. This would allow something like: std::cout << ( io::css[ "container" ].separator = " : " ) << io::object( ob ); // output: [ [ a, 5 ] : [ b, -1 ] ] std::wcout << ( io::css[ L"pair" ].separator = L" = " ) << io::object( ob ); // output: [ [ a = 5 ], [ b = -1 ] ] With the "body{ color: red; }" example, the CSS attribute is inherited to all its child tags. The question here would be: should styling be inherited? Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

RE: [boost] problem with intersection test_tools and mpl/list.hpp and borland
by Aleksey Gurtovoy 17 Sep '04

17 Sep '04

Robert Ramey writes: > OK - I've followed this farther down a very long chain > > Here is as deep as I'm in a position to go: > > Anytime this pair of headers is included either directly or indirectly, > and the compiler is borland, you'll get a syntax error: > > #include <boost/mpl/list.hpp> > #include <boost/next_prior.hpp> Robert, Thanks for the reduced test case. Fixed in the CVS now. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

program_options: informative exceptions
by Llew Sion Goodstadt 17 Sep '04

17 Sep '04

Dear Volodya, The version of Boost.program_options I am using throws lots of informative exceptions to indicate precisely what has gone wrong. The exception is where an incorrect argument to an option has been supplied e.g. --some_arg "abc" where --some_arg 0.6 is expected. The error message is annoyingly non-descript and it can be difficult to figure out which particular optional argument has been mis-specified. This imprecision is because when program_options::validation_error is being thrown, it is not clear which option is being parsed. Could I suggest that this particular exception is caught in: void store(const parsed_options& options, variables_map& xm, bool utf8) and the option context added back in (and the same exception type re-thrown): void store(const parsed_options& options, variables_map& xm, bool utf8) { ... // First, convert/store all given options for ( size_t i = 0; i < options.options.size(); ++i ) { const string& name = options.options[i].string_key; try { ... } catch ( validation_error& e ) { throw validation_error("[--" + name + "]: " + e.what()); } } ... } What do you think? Leo Goodstadt MRC Functional Genetics Unit University of Oxford

2 4

problem with intersection test_tools and mpl/list.hpp and borland
by Robert Ramey 17 Sep '04

17 Sep '04

OK - I've followed this farther down a very long chain Here is as deep as I'm in a position to go: Anytime this pair of headers is included either directly or indirectly, and the compiler is borland, you'll get a syntax error: #include <boost/mpl/list.hpp> #include <boost/next_prior.hpp> Robert Ramey

1 0

[serialization 1.32]: vc7.1 : link error with free_saver
by Francis ANDRE 16 Sep '04

16 Sep '04

Hi There is a link error with boost::serialization::free_saver in the serialization 1.32 lib under vc7.1. The workaround put in place for vc7.0 (BOOST_MSVC 1300) should also apply to vc7.1 (BOOST_MSVC 1310) Index: split_free.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/serialization/split_free.hpp,v retrieving revision 1.4 diff -u -r1.4 split_free.hpp --- split_free.hpp 4 Aug 2004 05:23:40 -0000 1.4 +++ split_free.hpp 16 Sep 2004 22:17:23 -0000 @@ -34,7 +34,7 @@ namespace serialization { -#if ! BOOST_WORKAROUND(BOOST_MSVC, <= 1300) +#if ! BOOST_WORKAROUND(BOOST_MSVC, <= 1310) template<class Archive, class T> void save(Archive &ar, const T & t, const unsigned int); template<class Archive, class T> Regards. Francis ANDRE

1 0

RE: [boost] Re: problem with intersection test_tools and mpl/list .hpp andborland
by Rozental, Gennadiy 16 Sep '04

16 Sep '04

How do I manage to step in all these compiler bugs??;)) I am quite sure I do not have nor function nor class template named next. How does it happened? Gennadiy > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Pavel Vozenilek > Sent: Thursday, September 16, 2004 2:42 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: problem with intersection test_tools and > mpl/list.hpp andborland > > > > "Robert Ramey" wrote: > > > The following program: > > > > > > #include <boost/mpl/list.hpp> > > #include <boost/test/test_tools.hpp> > > > > fails to compile with borland compilers with the messages: > > > > c:\BoostMainCVS\libs\serialization\test\test_zmisc.cpp: > > Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 30: Cannot > have both > > a template class and function named 'next' > > > > > Old BCB bug, e.g. > http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&c2coff=1&th readm=3BDD798D.130E38F8%40divalsim.it&rnum=1&prev=/groups%3Fnum%3D100%26hl%3 Den%26lr%3D%26ie%3DUTF-8%26c2coff%3D1%26q%3DE2479%2BBorland%2BOR%2BBCB%2BOR% 2Bcompiler%26btnG%3DSearch (http://tinyurl.com/5ltk9) It won't be fixed, ever. One ugly way is to use macro: #include <boost/mpl/list.hpp> #define next xyz #include <boost/test/test_tools.hpp> #undef next other is to separate code into two TUs. /Pavel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: problem with intersection test_tools and mpl/list.hpp andborland
by Robert Ramey 16 Sep '04

16 Sep '04

Pavel Vozenilekwrote: >> The following program: >> >> >> #include <boost/mpl/list.hpp> >> #include <boost/test/test_tools.hpp> >> >> fails to compile with borland compilers with the messages: >> >> c:\BoostMainCVS\libs\serialization\test\test_zmisc.cpp: >> Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 30: Cannot have both >> a template class and function named 'next' >> >> >Old BCB bug, e.g. > (http://tinyurl.com/5ltk9) >It won't be fixed, ever. >One ugly way is to use macro: >#include <boost/mpl/list.hpp> >#define next xyz >#include <boost/test/test_tools.hpp> >#undef next >other is to separate code into two TUs. I don't think this will work for me as it shows up due to file header inclusion about 7 levels deep. Note that this is a new phenomenon that I believed was introduced with the latest MPL update. I realize that's it's a lot, but would it possible for the authors of the two libraries to agree that the name be changed in one of them just so I that us users don't have to resort to a hack such as the above? Robert Ramey

1 0

Re:[boost] Serializing bitsets and tuples
by Robert Ramey 16 Sep '04

16 Sep '04

>Again, Robert, I have to thank you immensely for the Serialization >library. It has made my life much easier. >Anyway, I was wondering, since you state in the manual that all STL >containers are supported, why I can't seem to find std::bitset in that. >I realize that it is probably not the most common container to >serialize, but still. Also, considering the is Boost library now, I'm >wondering about the apparent absence of serialization for boost::tuple. >It's not the end of the world (I can write them myself rather easily, I >suppose), but for completeness I'd think at least Boost.Tuple should be >supported. LOL - I never heard of std::bitset until you mentioned it. Also I think I overlooked vector<bool> as well. Feel free to implement serialization for them and put your name on it. Make a test and we'll add it in. Robert Ramey

3 3

bug in recursive_mutex
by James Ahlborn 16 Sep '04

16 Sep '04

I previously posted about issues when using a recursive_mutex and a condition. after some more inspection, it turns out it is a minor bug in the recursive_mutex implementation (the pthread version). I've included the patch below, which was generated against the 1.31.0 version of boost (but the bug is still in the latest cvs as well). Would be great if someone could integrate this into the latest code, or possibly a bug fix release for 1.31 (this is a major bug for anyone using recursive_mutex with condition). thanks, -james *** boost_1_31_0/libs/thread/src/recursive_mutex.cpp Fri Dec 26 18:22:00 2003 --- boost_1_31_0.jta/libs/thread/src/recursive_mutex.cpp Thu Sep 16 10:01:10 2004 *************** *** 412,417 **** --- 412,418 ---- state.pmutex = &m_mutex; state.count = m_count; + m_count = 0; } recursive_try_mutex::recursive_try_mutex() *************** *** 608,613 **** --- 609,615 ---- state.pmutex = &m_mutex; state.count = m_count; + m_count = 0; } recursive_timed_mutex::recursive_timed_mutex() *************** *** 787,792 **** --- 789,795 ---- state.pmutex = &m_mutex; state.count = m_count; + m_count = 0; } #elif defined(BOOST_HAS_MPTASKS)

3 3

problem with intersection test_tools and mpl/list.hpp and borland
by Robert Ramey 16 Sep '04

16 Sep '04

The following program: #include <boost/mpl/list.hpp> #include <boost/test/test_tools.hpp> fails to compile with borland compilers with the messages: c:\BoostMainCVS\libs\serialization\test\test_zmisc.cpp: Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 30: Cannot have both a template class and function named 'next' Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 34: Cannot have both a template class and function named 'next' Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 40: Cannot have both a template class and function named 'prior' Error E2479 C:\BoostMainCVS\boost/next_prior.hpp 44: Cannot have both a template class and function named 'prior' *** 4 errors in Compile *** Could someone shed some light on this? Robert Ramey

2 1