September 2004 - Boost - lists.boost.org

dynamic scoping emulation - was Re: Lexical cast suggestion
by Jonathan Graehl 21 Sep '04

21 Sep '04

> > >Nope, there's only one global locale, it's not per-thread. If it's >per-thread, you can do > > std::locale::tss_global(std::locale("koi8-r")); > // do some work with program_options > std::locale::tss_global(std::locale("")); > I do this all the time (but using a scope guard), for globals I've declared thread-local. This essentially simulates dynamic scoping (which I'd prefer to see supported directly by the language, as an alternative to lexical scoping). Perhaps a Boost library for dynamically scoped properties would be nice? -Jonathan

1 0

RE: [boost] Avoiding warning on the do{...}while(0) macroimplementation trick
by Ben Hutchings 21 Sep '04

21 Sep '04

Ivan Vecerina wrote: > I've noticed discussions about this a couple of years ago. > For assert-style macros that include multiple statements, > a common idiom is to enclose the statements in a do{...}while(0) > dummy loop. This makes the macro behave like a single statement. > > A problem with some compilers (notably VC7.x) is that this > triggers a warning (C4127: conditional expression is constant). > > The workaround adopted by boost is to automatically disable > this warning -- which however can be legitimate and useful > in user code. > > I think I have found a better 'always-false' condition which > does not trigger a warning, and works at least in VC7.1: > do{ }while(__LINE__==-1) > > Do you see a problem with this approach? <snip> It works in VC++ 7.1 if you enable "edit and continue", because this results in non-standard expansion of the __LINE__ macro to an expression that isn't a compile-time constant. In general it doesn't work.

3 2

[assign] MSVC support?
by Aleksey Gurtovoy 21 Sep '04

21 Sep '04

Is assign library unusable on MSVC < 7.1? If so, could the maintainer please mark it up as such in "boost/status/explicit-failures-markup.xml"? Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Puverle, Tomas (IT) 21 Sep '04

21 Sep '04

> Also, why not including windows.h directly, like this: > #define WIN32_LEAN_AND_MEAN > #include <windows.h> I believe WIN32_EXTRA_LEAN may be even better. > <side-note> > From my tests it seems your version as is now fails to link > for gcc (unresolved external > _InterlockedIncrement/_InterlockedDecrement). > However, if #including <windows.h> and use > InterlockedIncrement/Decrement - they work. > </side-note> That is not suprising - Interlocked* are parts of the Win32 API. In fact, it has been a complete mistery to me as to why boost doesn't use atomic operations for its ref counting. The mutex on the counter was one of the big reasons why people here decided not to use shared_ptr. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

2 1

RE: [boost] OutFmt library implementation questions
by Rozental, Gennadiy 21 Sep '04

21 Sep '04

> >2. Why doesn't insert_iterator is implemented using iterator_facade? > > [1] I am not that familiar with using iterator_facade > [2] Is it worth the abstraction penalties? Compring to output operations? > >4. How does this all machinery will work with wchar_t? > > std::wcout << formatob( vec, containerfmtex< wchar_t * > >()).format( L" - > " ); > > Use the ex< DelimiterType > variant on the innermost construct. This is inacceptable and does not follow standard practice. > >5. Why do you need static_cast< const base_type * > to cast > to the base > >type > >in container.hpp? > > This is a VC 6.x workaround. But you don't list this compiler amoung supported. > >6. Why the same entity you sometime call format_type and sometime > >DelimeterType? > > format_type is the typedefed version (should be delimiter_type) and > DelimiterType is the template parameter. So is it delimeter type or forat type - it can't be both. > >7. What deducer is supposed to deduce? I couldn't get > through all the > >details, but couldn't the same be achieved using partial > specialization > >and/or partial ordering. Cause it look way too complex and > unnecessary. > > The deduction mechanism is used to evaluate what type T is > (e.g. std::pair< > char, int >), what format object is needed to render it > (including nested > format objects) and to construct the appropriate format object. > > It could be possible to use partial specialization, but the > type traits are > used elsewhere to redirect formatting behaviour (e.g. when > reading in a > container do diffreent things if it is a sequential, > associative or set > container). IMO all that you needed is function overloading. I don't see a place for all these deduce/trats staff. > >9. What is RT2 stands for? > > ReturnType2. Do not abbreviate. > >11. Need for all this hierarchies: > >Formatter->formater_t->openclose_formatter_t > > This is to ensure that the return type of 'format' in Formatter > [FormatObject] is Formatter and not openclose_formatter_t. Thus: > formatob( vec, containerfmt().format( " / " )); > will work as intended without overriding 'format' in > containerfmt_t (created > by containerfmt()) to return the correct type. > > >openclose_formatter->openclose_formatter_t > > > >are completely unclear. Explanations presented in docs does not help > >since format methods seems to be returning *this anyway. > > They return: > *static_cast< ReturnType * >( this ) > to allow 'format' to return the correct type when inherited > in the format > objects. Formatob_t::format return *this. You did not answer my question. I still believe it's all unnecessary. > >Why couldn't we just use something trivial like > > > >template<char Ch> > >struct formatter > >{ > > std::basic_string<Ch> m_open; > > std::basic_string<Ch> m_close; > > std::basic_string<Ch> m_sep; > >}; > > > >Is beyond me. If any member is empty it means it missing. > > This is the direction I am going in the development version. The only > difference is that I am using io::decoration< CharT, int id > > instead of > std::basic_string< CharT >. The decoration class uses > std::basic_string to > store the values, while providing support for looking up the > default value > on a stream and an external function for checking for a match > on an input > stream. You presented library call *Output* formatter. Why do we talk about input at all. > >14. list_object -> formatter_t inheritance look wrong. > Where is IS A > >relationship? > > list_object *isa* formatter_t *isa* openclose_formatter_t > > using the new design: > > list_object *isa* sequence_decorators_t *isa* > wrapper_decorators_t *hasa* > decoration List_object IS A formatter ???? Something really worng with naming here. > Regards, > Reece Gennadiy.

1 0

immutable string
by Maxim Yegorushkin 21 Sep '04

21 Sep '04

Hello all, I've been working on a small library - an immutable C++ string. Now it is in usable state and has been put in use in a couple of real projects. Although it needs further polishing, I would like to know is there any interest in such a library? Here is the link: http://conststring.sourceforge.net/ -- Maxim Yegorushkin

10 21

RE: [boost] OutFrmt lib design questions
by Reece Dunn 21 Sep '04

21 Sep '04

Rozental, Gennadiy wrote: >Here some question I've got while reading submitted library. > >1. What is an advantage if using this library for scalar types (vs. >defining >operator<<) Do you mean for things like int, Person, etc. If that is the case, the default behaviour of the library is to delegate output of these types to operator<<, so it doesn't do much. However, with support for a fmt::serialize formatter that calls 'serialize' instead of <<, you can register a particular class as being serializable so my type deduction system knows to associate instances of that type with fmt::serialize, so you can then do: // new design std::cout << io::object( my_serializable_object ) << '\n'; std::cout << io::object( vec_of_serializable_objects ) << '\n'; // [ ..., ..., ... ] The advantage of using this for things like std::complex or boost::math::quaternion that already supply << and >> operators is if you want to have control over how a type is rendered, e.g.: // new design std::cout << io::object( complex_val ).decorate( "", "", " + i" ) << " = " << io::object( complex_val ).decorate( "( ", " )" ) << '\n'; >2. If primary target is collection formatting wouldn't it be better to name >library "collection formats something"? This is a good idea. The name is from when the library just had output support, thus the "outfmt" directory in the sandbox. I am thinking about moving to a "formatter" directory. What do other people think? >3. If there is a way to assign format to collection/type combination >permanently (through global operator <<), why would I want to do it in >every >instance of output operation? Do you mean: std::vector< int > vec; std::cout << "vector = " << vec << '\n'; // [1] std::cout << "vector = " << io::formatob( vec ) << '\n'; // [2] using [1] vs using [2]? If so, these are the same, but the second allows you to customize the decoration around the sequence, for example: std::cout << io::formatob( vec ).format( " : " ); // [ 1 : 2 : 3 : 4 ] >4. What is an advantage of using this library to assign format to >collection/type combination permanently vs. explicit implementation (using >FOREACH construct for example) Using a foreach construct you would need to hand-code the surrounding decoration, e.g.: // output: { a + b + c } std::cout << "{ "; foreach( char ch : vec ) { std::cout << ch; if( !atend ) std::cout << " + "; } std::cout << " }"; vs: std::cout << io::formatob( vec ).format( "{ ", " }", " + " ); // output: { a + b + c } If you have a nested construct, such as int tictactoe[ 3 ][ 3 ], std::list< std::list< float > > or math::matrix4x4< float > then outputting/inputting it manually would be more complex, whereas my library has all the machinery to handle this simply. >5. Why do we need boost::io::range? Couldn't we use boost::range instead? I suppose it would be possible to use boost::range::make_iterator_range instead. The only thing I have against this is its length. Consider: // new design using boost::range::make_iterator_range; namespace range = boost::range; namespace io = boost::io; std::cout << io::object( range::make_iterator_range( i, i + 7 )); // [1] std::cout << io::object( make_iterator_range( i, i + 7 )); // [2] std::cout << io::object( io::range( i, i + 7 )); // [3] If only you could alias functions, e.g.: namespace io{ alias range = boost::range::make_iterator_range; } >6. In a formatter usage how would I guess what is what? > boost::io::formatter< char * > fmt( "\ ", " /", " | " ); > boost::io::formatob( vec, boost::io::containerfmt()).format( fmt ); I have revised the names, so that is now: namespace fmt = boost::io::format; io::sequence_decorators< char > seq( "\\ ", " /", " | " ); io::object( vec, fmt::container()).decorate( seq ); >7. Who come format calls order dependent? > boost::io::formatob( vec, boost::io::containerfmt()).format( fmt >).format( >" : " ); format( fmt ) is called first, then format( " : " ). Thus, you will have "\ a : b : c /" as the formatting. >8. If I got vector<vector<int> >. How do I supply separators for both >internal and external vectors? You apply the 'format' function to containerfmt(). For example: boost::io::formatob( vec, containerfmt( containerfmt().format( " : " )).format( " + " )); // output: [ [ a : b : c ] + [ x : y : z ] + ... ] >9. Let say I print vector<char>. Is there way to print it like this: { 'a', >'b', '0x01', ' ' } Yes. You need to provide a wrappedfmt() format object. For example: formatob( vec, containerfmt( wrappedfmt().format( "'", "'" ))).format( "{ ", " }" ); // output: { 'a', 'b', 'c' } With the 0x01 character, special treatment needs to be applied. You will need to supply a custom format object to see if the character is printable, e.g.: class char_escape { public: typedef void traits_type; typedef const char * format_type; typedef boost::io::seq_type< -1 > formatter_type; public: template< typename CharT, typename TraitsT > static std::basic_ostream< CharT, TraitsT > & write( std::basic_ostream< CharT, TraitsT > & os, CharT value ) const { if( isprintable( value )) return( os << value ); return( os << "0x" << int( value )); } }; formatob( vec, containerfmt( wrappedfmt( char_escape()).format( "'", "'" ))).format( "{ ", " }" ); // output: { 'a', 'b', 'c' } Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

3 2

Outdated GCC versions checks with BOOST_TESTED_AT()
by Jonathan Wakely 21 Sep '04

21 Sep '04

There's an out-of-date workaround in dynamic_bitset/config.hpp, which tests the compiler version to see if a GCC bug is still present. The bug is still present in GCC 3.4, so BOOST_TESTED_AT should test 30400. Also, boost/variant/detail/move.hpp contains this: #if defined(BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP) \ || BOOST_WORKAROUND(__GNUC__, BOOST_TESTED_AT(2)) Should that be changed? IIUC that means that GCC 3.x uses the workaround for non-ADL compilers. Since GCC 3.x has pretty good (not perfect) ADL, and since the BOOST_TESTED_AT is outdated, that test should be changed. Finally, boost/iterator/detail/config_def.hpp tests # if BOOST_WORKAROUND(__GNUC__, == 2) && BOOST_WORKAROUND(__GNUC_MINOR__, BOOST_TESTED_AT(95)) \ This looks outdated - there will be no more GCC 2.x releases and I would be surprised if vendor-specific releases such as RedHat's GCC 2.96 fixed that issue, but GCC 3 probably did. I can check this assumption if someone can provide a testcase but I would expect the test can be changed to simply: # if BOOST_WORKAROUND(__GNUC__, == 2) \ since it applies to all known version of GCC 2.x, and there will not be any more 2.x releases. The attached patches make the first two changes. I have left the third, since it doesn't affect GCC 3.x so is doing no harm, and because I'm not sure the bug has been fixed. jon -- I listen a lot and talk less. You can't learn anything when you're talking. - Bing Crosby

1 0

Boost.Python/vc6 regressions
by David Abrahams 21 Sep '04

21 Sep '04

Due to what appears to be an MPL problem, neither libs/python/test/polymorphism.cpp nor libs/python/test/polymorphism2.cpp are compiling on vc6. This fact is reflected only strangely by the posted regression log, as white cells. Here is the error output: ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** ***************************************************************************** -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

RE: [boost] OutFmt library implementation questions
by Reece Dunn 21 Sep '04

21 Sep '04

Rozental, Gennadiy wrote: >Here some implementation questions I've got: > >1. Why does the library brake const correctness. FWIV I could write: > > const vector<int>& v = ...; > > std::cin >> io::formatob( v ); > > and it would compile without questions. I'll try to resolve this issue. >2. Why doesn't insert_iterator is implemented using iterator_facade? [1] I am not that familiar with using iterator_facade [2] Is it worth the abstraction penalties? >3. Why do you need 2 different functions containerfmtex and containerfmt? This was so that older compilers (e.g. VC 7.0) could resolve the arguments correctly. The new implementation just uses the single function name. >4. How does this all machinery will work with wchar_t? std::wcout << formatob( vec, containerfmtex< wchar_t * >()).format( L" - " ); Use the ex< DelimiterType > variant on the innermost construct. >5. Why do you need static_cast< const base_type * > to cast to the base >type >in container.hpp? This is a VC 6.x workaround. >6. Why the same entity you sometime call format_type and sometime >DelimeterType? format_type is the typedefed version (should be delimiter_type) and DelimiterType is the template parameter. >7. What deducer is supposed to deduce? I couldn't get through all the >details, but couldn't the same be achieved using partial specialization >and/or partial ordering. Cause it look way too complex and unnecessary. The deduction mechanism is used to evaluate what type T is (e.g. std::pair< char, int >), what format object is needed to render it (including nested format objects) and to construct the appropriate format object. It could be possible to use partial specialization, but the type traits are used elsewhere to redirect formatting behaviour (e.g. when reading in a container do diffreent things if it is a sequential, associative or set container). >8. Why class formatter, formatter_t is defined in namespace io, while it >reside among details headers? It is included in the <boost/outfmt/formatter.hpp> header. In the new version, these are in an "impl" directory, i.e. are part of the implementation and should not be included directly. >9. What is RT2 stands for? ReturnType2. >10. detail/formatter.hpp refer to openclose_formatter_t, but does not >include no headers. See question [8]. >11. Need for all this hierarchies: >Formatter->formater_t->openclose_formatter_t This is to ensure that the return type of 'format' in Formatter [FormatObject] is Formatter and not openclose_formatter_t. Thus: formatob( vec, containerfmt().format( " / " )); will work as intended without overriding 'format' in containerfmt_t (created by containerfmt()) to return the correct type. >openclose_formatter->openclose_formatter_t > >are completely unclear. Explanations presented in docs does not help since >format methods seems to be returning *this anyway. They return: *static_cast< ReturnType * >( this ) to allow 'format' to return the correct type when inherited in the format objects. >Why couldn't we just use something trivial like > >template<char Ch> >struct formatter >{ > std::basic_string<Ch> m_open; > std::basic_string<Ch> m_close; > std::basic_string<Ch> m_sep; >}; > >Is beyond me. If any member is empty it means it missing. This is the direction I am going in the development version. The only difference is that I am using io::decoration< CharT, int id > instead of std::basic_string< CharT >. The decoration class uses std::basic_string to store the values, while providing support for looking up the default value on a stream and an external function for checking for a match on an input stream. >12. select and switch templates seems useful. Why doesn't MPL provide >these? I don't know. Dave? >13. Doesn't MPL provide eq_int, lt_int? I think so. I am not an MPL expert. I should really fix this. >13. struct selector needs to be PP generated Again, I am not a PP expert. I will look into this. >14. list_object -> formatter_t inheritance look wrong. Where is IS A >relationship? list_object *isa* formatter_t *isa* openclose_formatter_t using the new design: list_object *isa* sequence_decorators_t *isa* wrapper_decorators_t *hasa* decoration >15. You couldn't do this: typename InputStream::char_type ch = '\0'; Since the new version takes template< typename CharT > across the board, this is now: CharT ch = CharT(); So I have fixed the problem. Regards, Reece _________________________________________________________________ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx

1 0