- Boost - lists.preview.boost.org

Re: Formal review of "Output Formatters" library begins today
by Robert Ramey 21 Sep '04

21 Sep '04

Vladimir Prus wrote: >A particularly interesting question is how the proposed library overlaps >with serialization. When outputting vector<Function> I'd prefer the content >of 'Function' to be outputted too, preferably by describing the members >with the 'serialize' method. And the question is if I can use outfmt >library, or have to use the serialization library? The serialization >library is pretty large, so, I'd like outfmt to be able to output UDT which >have 'serialize' defined. IMO, vector<some_UDT> is a very common case, >maybe even more common than vector<pair<int, int> >. If one had nothing else to do, he could make a derivation of one of the existing archives (e.g. text_archive) that would "annotate" the serialization. This might be useful for debugging or other purposes. On the other hand, I just use the xml_archive for that purpose now and its fine (although a little verbose). It also plays nice with XML browsing tools. So that's handy. My real observation is that I see this as orthogonal to serialization and that it should remain that way. I don't seen any real overlap now except that there might be a couple of instances where either one might do. I think even these would be rare cases. I would resist any idea to intertwine these concepts. Robert Ramey

3 3

explicite failures question
by Robert Ramey 21 Sep '04

21 Sep '04

I'm struggling with the explicit-failures XML. About 40% of the serialization tests will fail on platforms which do not include support from wchar_t streams. As Understand the current schema (XML is not all that clear to me) I would have to specify one line for each pair of toolset-test that fails on this scenario. I my case this means 100 test * 6? Toolsets = ? 600 lines of xml added to this file. Robert Ramey

3 8

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 21 Sep '04

21 Sep '04

Vladimir Prus wrote: >There are some things I don't like. First, as many mentioned, the naming is >not optimal. >[snip] >or maybe even > > ("[" + io(v)/"," + "]") > >for nested formats, something like > > ("[" > + io::format( > "(" + io::format()/":" + ")" > )/"," > + > "]" > ) > >These are just ideas, though. In my development version, I now have this working! That is, you can do: std::cout << io::object ( std::make_pair( 'a', 5 ), "{ " + fmt::pair()/" == " + " }" ) << '\n'; // output: { a == 5 } and: std::cout << io::object ( std::make_pair( std::make_pair( 'a', 1 ), std::make_pair( 'b', 2 )), "{ " + fmt::pair ( "< " + fmt::pair()/" + " + " >", "( " + fmt::pair()/" | " + " )" )/" = " + " }" ) << '\n'; // output: { < a + 1 > = ( b | 2 ) } I have tested with VC 7.x and 8.0. VC7.0 has some problems, but the others build it fine. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

[concept_check] failures in release cfg
by Stefan Slapeta 20 Sep '04

20 Sep '04

see http://tinyurl.com/3t3tc It seems that the concept_checks are inactive in release cfg, at least the lines template <class Concept> inline void function_requires(mpl::identity<Concept>* = 0) { #if !defined(NDEBUG) void (Concept::*x)() = BOOST_FPTR Concept::constraints; ignore_unused_variable_warning(x); #endif } make me think so. If there is no better way to instantiate Concept::constraints (without creating a local variable, which seems to be the reason to avoid the check in release mode), the cf-tests must be disabled for all release configurations. Stefan

6 9

OutFmt library implementation questions
by Rozental, Gennadiy 20 Sep '04

20 Sep '04

Hi, 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. 2. Why doesn't insert_iterator is implemented using iterator_facade? 3. Why do you need 2 different functions containerfmtex and containerfmt? 4. How does this all machinery will work with wchar_t? 5. Why do you need static_cast< const base_type * > to cast to the base type in container.hpp? 6. Why the same entity you sometime call format_type and sometime DelimeterType? 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. 8. Why class formatter, formatter_t is defined in namespace io, while it reside among details headers? 9. What is RT2 stands for? 10. detail/formatter.hpp refer to openclose_formatter_t, but does not include no headers. 11. Need for all this hierarchies: Formatter->formater_t->openclose_formatter_t openclose_formatter->openclose_formatter_t are completely unclear. Explanations presented in docs does not help since format methods seems to be returning *this anyway. 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. 12. select and switch templates seems useful. Why doesn't MPL provide these? 13. Doesn't MPL provide eq_int, lt_int? 13. struct selector needs to be PP generated 14. list_object -> formatter_t inheritance look wrong. Where is IS A relationship? 15. You couldn't do this: typename InputStream::char_type ch = '\0'; I think It all for now. Please comment. Gennadiy.

1 0

OutFrmt lib design questions
by Rozental, Gennadiy 20 Sep '04

20 Sep '04

Hi, 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<<) 2. If primary target is collection formatting wouldn't it be better to name library "collection formats something"? 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? 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) 5. Why do we need boost::io::range? Couldn't we use boost::range instead? 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 ); 7. Who come format calls order dependent? boost::io::formatob( vec, boost::io::containerfmt()).format( fmt ).format( " : " ); 8. If I got vector<vector<int> >. How do I supply separators for both internal and external vectors? 9. Let say I print vector<char>. Is there way to print it like this: { 'a', 'b', '0x01', ' ' } That's enough for now. Please comment. Gennadiy.

1 0

[boost.range] late addition, votes needed
by Thorsten Ottosen 20 Sep '04

20 Sep '04

Dear All, In the pre-redmond mailing Walter Brown discusses the possibility of adding these members to standard container classes: const_iterator cbegin(); const_iterator cend(); const_reverse_iterator crbegin(); const_reverse_iterator crbegin(); The motiviation is that we want to be able to say explicitly "give me a const iterator" without doing ugly casts. IMO a sound idea. Given the framework in boost.range these would be absolutely *trivial* to add. 1st vote: for or against adding these? 2nd vote: which naming scheme to use: a: cbegin(), cr_begin() b: const_begin(); const_rbegin(); The motivation for chosing the latter could be that "cr" contracttions become harder to read. Let me know what ya think. best regards Thorsten

14 39

Re:[boost] Re: python/detail/config.hpp bug?
by Robert Ramey 20 Sep '04

20 Sep '04

"Aleksey Gurtovoy" <agurtovoy(a)meta-comm.com> writes: >> Boost.Python fails to build with MSVC 6.x/STLPort (see >> http://tinyurl.com/4nl7l) due to the following (incorrect) >> configuration logic in >> "boost/python/detail/config.hpp": >> >> // The STLport puts all of the standard 'C' library names in std (as >> far as the // user is concerned), but without it you need a fix if >> you're using MSVC or // Intel C++ # if >> defined(BOOST_MSVC_STD_ITERATOR) # define BOOST_CSTD_ # else # >> define BOOST_CSTD_ std # endif >> >> The issue, as explained in "boost/config/stdlib/stlport.hpp" is that: >> >> // STLport does a good job of importing names into namespace std::, // >> but doesn't always get them all, define BOOST_NO_STDC_NAMESPACE, since >> our // workaround does not conflict with STLports: >> >> Is there a reason why we are not using BOOST_NO_STDC_NAMESPACE here? I had similar problems in my setup. I fixed them by close looking at the release notes for stlport 4.5.3 and found that stlport 4.5.3 puts an altered copy of stlport directory into the msvc include directory. I set environmental variables export STLPORT_PATH="c:/" export STLPORT_VERSION=4.5.3 export STLPORT_INCLUDE_DIRECTORY="c:/program files/Microsoft Visual Studio/vc98/include/stlport" This permitted compile link and test with msvc-stlport toolset. I believe it would also help intel-7.1-v6-stlport-4.5.3 toolset builds. Robert Ramey

1 0

RE: [boost] Re: Re:Re: [static_assert] Regression with gcc 3.4.2?
by Ben Hutchings 20 Sep '04

20 Sep '04

Jonathan Turkanis <technews(a)kangaroologic.com> wrote: > "Robert Ramey" <ramey(a)rrsd.com> wrote in message > news:20040919040443.D18A931132@acme.west.net... > > "David B. Held" <dheld(a)codelogicconsulting.com> wrote in message > > news:cihmvu$3ik$1@sea.gmane.org... > > > #include <boost/static_assert.hpp> > > > > > > template <typename T> > > > struct foo > > > { > > > void bar(void) > > > { > > > BOOST_STATIC_ASSERT(false); > > > } > > > }; > > > > I use > > > > .... > > BOOST_STATIC_ASSERT(sizeof(T) == 0); > > The expression 'always_false<T>::value' can't be evaluated until > the point of instantiation, since always_false could be > specialized for T. OTOH, the compiler can tell immediately that > 'sizeof(T) == 0' is false, so might it not replace > 'sizeof(T) == 0' with 'false', and then issue the same error as > in the quoted case? sizeof(T) isn't always false, because for some types T it isn't even well-formed. As a value-dependent expression I think it must not be evaluated until the template is instantiated.

2 1

RE: [boost] Re: [Output Formatter]: Cascading Style Sheets (CSS)proposal
by Reece Dunn 20 Sep '04

20 Sep '04

Vladimir Prus wrote: Hi Volodya, > >>Do you provide the ability to use different separators for sequences, >sets > >>and maps? > > > > In the review version of the library, there are two sets of default > > values: one for n-ary types formatting as "( a, b )" and one for the >other > > sequence types, formatting as "[ a, b, c ]". In the version I am > > rewriting, I only have one set of default formatting: "[ a, b, c ]". > >That's bad, I'd rather prefer different formatting styles for sets and >vectors. Hmm. Note that this is for the default values, i.e. you can set the formatting you want when constructing a format object construct. > >>Then I don't understand why you can > >>set different default style for those kinds of object, and cannot > >>selectively > >>override the style > > > > Because the way I am storing it on the stream is based on decoration >type > > (open; close; separator) and not on the format object type. > >Why? Is there any specific difficulty with using format object type (or >"kind") as key? The current implementation in the post-review version that I am developing uses a simplified approach in dealing with pword -- it assumes that the type is const CharT * and is not allocated (i.e. is a string literal). It would be possible to do based on format object type, but that would increase the complexity of the code. > > A wrapper_decorator is one that only has open and close decoration >values. > > Thus, it wraps the object associated with it (via a format object): > > > > template< class OutStream, typename T > > > OutStream & write( OutStream & os, const T & elem ) > > { > > return( os << open << elem << close ); > > } > >Is this a method of 'wrapper_decorators'? It is a method of the format object used when writing to a stream. > >>I agree that you might want to store and then restore STL container from >a > >>file, and the library addresses this need to. But I don't understand why > >>you would want to customize the formatting style. Basically, you either > >>should > >>the data to user, or not. In first case, you need a single usable style. > >>For > >>the second case, you might need another "compact" style. I don't see the > >>point of customization. > > > > It is currently possible to state what style formatting an object takes > > using the decorate function (format in the review implementation). Thus: > > > > // review implementation: > > std::cout << io::formatob( vec ).format( "( ", " )" ); // ( a, b, c, >d > > ) > > > > Here, the separator is not set and thus takes the default value (the one > > provided by one of the mechanisms outlined above). > >Ok, aside from naming, the above is fine. The naming issue has been discussed earlier in the review. In the post-review version, the above example is: std::cout << io::object( vec ).decorate( "( ", " )" ); // ( a, b, c, d ) (I know the review is still in process, but I have been working to address the issues in the review version of my library.) > > You might want to customize formatting for various reasons. One example >is > > if you have: > > std::list< std::string > names; > > and want to write that out as a HTML ordered list. You can do the > > following: > > > > std::cout << io::formatob( names ).format( "<ol><li>", "</li></ol>", > > "</li><li>" ); > >Is this a practical use case? Reviewers have requested the ability to generate XML/HTML. This is to show that it is possible to do that within the existing framework. >Well, you can print 'names' this way, but if >you want to print 'Person', you'll need much more powerfull tools. Anyway, >if the overhead is small, no problem. If Person supports << on a stream, you can do: std::list< Person > people; std::cout << io::formatob( people ).format( "<ol><li>", "</li></ol>", "</li><li>" ); > > It is also > > possible to provide a basic form of message localization, reading a > > std::map< std::string, std::string > in from a file. E.g.: > > [snip] >That's more like an artificial example, I think. For practical uses, the >message catalog would have to contain comments, at least, and that again >requires much more complex parser. This is true. Although, you could write a custom state object to skip comments and then bind that to the formatter. >I'll try to write a complete review soon, >so stay tuned ;-) :) (What frequency are you broadcasting at ;)) Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

RE: [boost] [thread] Build failures for CW, found the xtime problem...
by Ben Hutchings 20 Sep '04

20 Sep '04

Rene Rivera <grafik.list(a)redshift-software.com> wrote: > After some investigation I found the problem with the build failures > for xtime.cpp on CW platforms: http://tinyurl.com/5nwxo [1] > > The issue is the placement of the definition of > __STDC_CONSTANT_MACROS to bring in the *INT*_C() constant macros > from cstdint. <snip> > Moving the definition above the <boost/thread/xtime.hpp> included > fixes that problem: <snip> > OK to commit?? <snip> The fix deserves at least a comment. I would move the inclusion of cstdint.hpp along with the macro definition as well.

1 0

RE: [boost] Thread/intel-8.0-linux regressions
by Ben Hutchings 20 Sep '04

20 Sep '04

John Maddock <john(a)johnmaddock.co.uk> wrote: > > Linker output []: > > Chmod1 > > > > ../bin/boost/libs/thread/test/test_tss.test/intel-8.0-linux/debug/ > > threading-multi/test_tss > > > > > > Run output []: > > > > EXIT STATUS: 139 > > > > ? > > > > All thread tests are failing in the similar manner. This is really > > unpleasant given that the library worked on Intel 8.0/Linux in 1.31. > > There are two issues here: > > 1) Intel 8.1 currently crashes on all tests that use the unit test > suite, Intel tell me this will be fixed soon. > 2) Intel 8.0 and 8.1: Martin Wille's tests are run on a Linux version > that unsupported by Intel, as a result all tests that use > <threading>multi fail during program startup, see for example > http://tinyurl.com/4kvja. I don't see a solution to this unless we > can either get someone else to run Intel on Linux, or else persuade > Martin to use a different Linux vendor :-( Are they assuming that later 2.4 kernels have NPTL when that's really only true of certain vendors' patched kernels? If that's the problem then it might be possible to work around it by pointing LD_PRELOAD at a library that makes uname() return an earlier version. That's possibly something of a drastic solution though!

1 0

RE: [boost] Thread/intel-8.0-linux regressions
by Ben Hutchings 20 Sep '04

20 Sep '04

Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> wrote: > Does anybody have any ideas what's up with this > (http://tinyurl.com/6vecl) > > Linker output []: > Chmod1 > ../bin/boost/libs/thread/test/test_tss.test/intel-8.0-linux/debug/ > threading-multi/test_tss > > > Run output []: > > EXIT STATUS: 139 > > ? > > All thread tests are failing in the similar manner. This is really > unpleasant given that the library worked on Intel 8.0/Linux in 1.31. Bits 0-6 are set to 11, indicating termination due to segment violation. Bit 7 is set to 1, indicating that a core dump was saved. Bits 8-15 (normally the exit code) are set to 0 since the program didn't exit.

1 0

RE: [boost] Re: immutable string
by Ben Hutchings 20 Sep '04

20 Sep '04

David B. Held <dheld(a)codelogicconsulting.com> wrote: > Maxim Yegorushkin wrote: > > > 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/ > > First, I'll say that yes, I am very interested in a library such as > this. Second, let me say that "const_string<>" and "immutable string" > don't seem like the right terms to me. The fact that you can call > operator?=() and append() on it tell me that there is little that is > "const" or "immutable" about it. It seems to me that "cow_string<>" > would be more appropriate, but perhaps others have different opinions. I once wrote a string template class similar to this, though without the clever storage policy. Unfortunately this was done in the course of my employment and I left that job without having got permission to make it public. Anyway, I think the name I settled on was atomic_string. > I suppose its not completely a COW string, since you don't support the > full set of mutating operations. <snip> It never modifies buffers once they've been initialised, so it has no use for COW. Ben.

1 0

Re: [boost] [Output Formatter]: Cascading Style Sheets (CSS) proposal
by Reece Dunn 20 Sep '04

20 Sep '04

Vladimir Prus wrote: >Hi Reece, > > > io::sequence_decorators< char > seq( "; " ); > > std::cout << '"' << seq.open( std::cout ) << "\"\n" // "[ " > > << '"' << seq.close( std::cout ) << "\"\n" // " ]" > > << '"' << seq.separator( std::cout ) << "\"\n"; // "; " > > > > where separator( std::cout ) uses the separator value specified by seq >and > > the others use the values set on the std::cout stream. > >I don't understand this phrase, could you clarify. What does it mean to >"use >the separator". "use the separator value": the io::sequence_decorators< char > (io::formatter in the review implementation of the library) type holds 3 io::decoration< char > properties -- open; close; and separator. These are used when performing input/output using my library to render a given type. In the example above, the seq object provides a custom value for the separator decoration. The io::decoration< char >::operator()( StreamType & ) method will look up the default value of the decoration using the stream passed to it unless a custom value is provided. Thus, when accessing the separator value using this method, the custom one is chosen instead of the default one. > > To change these > > defaults, you can use: > > > > std::cout << io::cdecorate( "[{ ", " }]" ); // [{ a, b, c }] > > > > The problem with this is that it changes the defaults for all the > > formatting used, thus you cannot have different defaults for sequences >and > > n-ary types. > >I don't undestand this, either. Probably I've missed something in earlier >messages. What's "n-ary" type? An n-ary type is a type that has a fixed number of elements. std::pair is a 2-ary type, boost::math::quaternion is a 4-ary type, and so on. >Do you provide the ability to use different separators for sequences, sets >and maps? In the review version of the library, there are two sets of default values: one for n-ary types formatting as "( a, b )" and one for the other sequence types, formatting as "[ a, b, c ]". In the version I am rewriting, I only have one set of default formatting: "[ a, b, c ]". >Then I don't understand why you can >set different default style for those kinds of object, and cannot >selectively >override the style Because the way I am storing it on the stream is based on decoration type (open; close; separator) and not on the format object type. > > == Dynamic Styles > > > > 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 = " >>"; > >What does this decorator "wrap"? A wrapper_decorator is one that only has open and close decoration values. Thus, it wraps the object associated with it (via a format object): template< class OutStream, typename T > OutStream & write( OutStream & os, const T & elem ) { return( os << open << elem << close ); } The sequence_decorators< char > type extends the wrapper_decorator< char > type, adding the separator property. > > == Cascading Style Sheets > > > > HTML provides a <style> tag to specify styling across the document >without > > linking to an external file, e.g.: > > <style>h1{ color: orange; font-size: 2pc; }</style> > > > > The equivalent within my library would be to define the styling on a > > stream, e.g.: > > > > std::cout > > << css::element( "pair" ) > > [ > > ( css::attribute( "open" ) = "<< " ) > > + ( css::attribute( "close" ) = " >>" ) > > ] > > << css::element( "container" ) > > [ > > css::attribute( "separator" ) = " | " > > ] > > << io::object( ob ) // output: [ << a, 5 >> | << b, -1 >> ] > > << css::element( "pair" ) > > [ > > css::attribute( "separator" ) = " = " > > ] > > << io::object( ob ); // output: [ << a = 5 >> | << b = -1 >> ] > >I'm sorry, but I'm worried of the direction you took. For me, the primary >utility of this library is debugging output. For that, I'd be happy with a >single style, as long as it's something usable, like YAML >(http://www.yaml.org/) I haven't implemented CSS functionality yet. It is my thoughts based on the comments by Jonathan. >I agree that you might want to store and then restore STL container from a >file, and the library addresses this need to. But I don't understand why >you would want to customize the formatting style. Basically, you either >should >the data to user, or not. In first case, you need a single usable style. >For >the second case, you might need another "compact" style. I don't see the >point of customization. It is currently possible to state what style formatting an object takes using the decorate function (format in the review implementation). Thus: // review implementation: std::cout << io::formatob( vec ).format( "( ", " )" ); // ( a, b, c, d ) Here, the separator is not set and thus takes the default value (the one provided by one of the mechanisms outlined above). You might want to customize formatting for various reasons. One example is if you have: std::list< std::string > names; and want to write that out as a HTML ordered list. You can do the following: std::cout << io::formatob( names ).format( "<ol><li>", "</li></ol>", "</li><li>" ); The examples provided in the library show some advanced formatting that can be achieved. >Finally, is this library going to be used for producing generic text files? >E.g. code generation. I think no, to generate text you need some text >template system, and that's way beyond the scope of the library. It is possible to do this to a limited degree, for example, outputting 4, 7, 10, -5 27, 11, 5, 17 ... so the data can be read in by a spreadsheet, for example. It is also possible to provide a basic form of message localization, reading a std::map< std::string, std::string > in from a file. E.g.: english.loc "goodnight" = "Good night. Sweet dreams." "..." = "..." german.loc "goodnight" = "Gute nacht. Sussen Schlafen." "..." = "..." spanish.loc "goodnight" = "Buenos noches." "..." = "..." portuguese.loc "goodnight" = "Boa noite." "..." = "..." int main( ... ) { std::ifstream loc( argv[ 1 ]); std::map< std::string, std::string > messages; loc >> io::formatob( messages, io::containerfmt( io::pairfmt ( io::containerfmt().format( "\"", "\"", "" ), // currently unsupported io::containerfmt().format( "\"", "\"", "" ) // currently unsupported ).format( " = " )) ).format( "", "\n[end]", "\n" ); std::cout << "goodnight = " << messages[ "goodnight" ] << '\n'; } >So, I'm not convinced custom style gives you anything. On the other hand, >it >will cost a lot. At the very least, even documenting the above will be >considerable effort. And given that the library is header-only, this >features >will cost everyone extra compile time. Even is 'css' stuff is in separate >header, you'd need the hooks for customization. Custom styling is currently implemented and is relatively cheap. The CSS design proposal is - I agree - complex in nature and would give a performance penalty. I was discussing a possible implementation to Jonathan's proposal. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

[bind] Intel/Linux failures
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

Peter, Could you please comment on "bind_cv_test" and "bind_stateful_test" tests' failures on all Intel compilers on Linux -- http://tinyurl.com/5p3or? Should we mark these up as expected? -- Aleksey Gurtovoy MetaCommunications Engineering

2 4

RE: [boost] platform specific structures
by Puverle, Tomas (IT) 20 Sep '04

20 Sep '04

> The Win32 API provides InterlockedXXX for atomic operations > on long data types, e.g. InterlockedIncrement. I am not sure > about other OS's, but it should be possible to define an > atomic_long class: > > class atomic_long > { > private: long val; > public: > inline atomic_long & operator++() > { > InterlockedIncrement( &val ); > return( *this ); > } > // ... > }; I think this design could cause problems - presumably, there would need to be a way to test the value of the atomic_long, such as operator==(long), but that could lead to problematic code: if (++myAtomicLong == someValue) //... else //... An easy fix would be to make the return type void. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

2 1

Thread/intel-8.0-linux regressions
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

Does anybody have any ideas what's up with this (http://tinyurl.com/6vecl) Linker output []: Chmod1 ../bin/boost/libs/thread/test/test_tss.test/intel-8.0-linux/debug/threading-multi/test_tss Run output []: EXIT STATUS: 139 ? All thread tests are failing in the similar manner. This is really unpleasant given that the library worked on Intel 8.0/Linux in 1.31. -- Aleksey Gurtovoy MetaCommunications Engineering

3 5

[thread] Build failures for CW, found the xtime problem...
by Rene Rivera 20 Sep '04

20 Sep '04

After some investigation I found the problem with the build failures for xtime.cpp on CW platforms: http://tinyurl.com/5nwxo [1] The issue is the placement of the definition of __STDC_CONSTANT_MACROS to bring in the *INT*_C() constant macros from cstdint. Currently the top of xtime.cpp looks like so: =================================================================== #include <boost/thread/detail/config.hpp> #include <boost/thread/xtime.hpp> #if defined(BOOST_HAS_FTIME) # include <windows.h> # define __STDC_CONSTANT_MACROS # include <boost/cstdint.hpp> #elif defined(BOOST_HAS_GETTIMEOFDAY) # include <sys/time.h> #elif defined(BOOST_HAS_MPTASKS) # include <DriverServices.h> # include <boost/thread/detail/force_cast.hpp> #endif =================================================================== But that placement is not early enough as the <boost/cstdint.hpp> is included from <boost/thread/xtime.hpp>. Moving the definition above the <boost/thread/xtime.hpp> included fixes that problem: =================================================================== RCS file: /cvsroot/boost/boost/libs/thread/src/xtime.cpp,v retrieving revision 1.12 diff -u -r1.12 xtime.cpp --- xtime.cpp 16 Sep 2004 20:39:49 -0000 1.12 +++ xtime.cpp 17 Sep 2004 16:51:04 -0000 @@ -11,11 +11,14 @@ #include <boost/thread/detail/config.hpp> +#if defined(BOOST_HAS_FTIME) +# define __STDC_CONSTANT_MACROS +#endif + #include <boost/thread/xtime.hpp> #if defined(BOOST_HAS_FTIME) # include <windows.h> -# define __STDC_CONSTANT_MACROS # include <boost/cstdint.hpp> #elif defined(BOOST_HAS_GETTIMEOFDAY) # include <sys/time.h> =================================================================== OK to commit?? [1] http://www.meta-comm.com/engineering/boost-regression/developer/output/RSI-… -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 2

Re: [boost] platform specific structures
by Reece Dunn 20 Sep '04

20 Sep '04

Peter Dimov wrote: >John Maddock wrote: >>>I'm interested in getting something like "needs_lock" below into the >>>normal traits, perhaps as part of boost thread. It informs you >>>whether of not an operation on such a contiguous block needs a lock >>>to be atomic. >>> >>>For example, on ia32 32 bit aligned ops are atomic, on ia64 it is 64 >>>bit. doubles on ia32 need locking to be atomic, on ia64 they don't. >>>sizeof(void*) works generically for these two platforms as is >>>included in the code below. A default, safety first implementation >>>might return true always for needs lock, or perhaps, true for all >>>sizeof's greater than a byte. >> >>Is it the case that we could actually rely on this? I thought for >>example that on IA32 operations were only atomic and thread safe when >>the assembly is prefixed by LOCK? > >AFAIK reads and ordinary writes are atomic without LOCK. Read-modify-write >operations need LOCK. The Win32 API provides InterlockedXXX for atomic operations on long data types, e.g. InterlockedIncrement. I am not sure about other OS's, but it should be possible to define an atomic_long class: class atomic_long { private: long val; public: inline atomic_long & operator++() { InterlockedIncrement( &val ); return( *this ); } // ... }; Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

RE: [boost] platform specific structures
by Puverle, Tomas (IT) 20 Sep '04

20 Sep '04

(first post to this forum, so be nice guys! :) > For example, on ia32 32 bit aligned ops are atomic But you will also need to express the constraint that the data be aligned? > , on ia64 > it is 64 bit. However, remember that the fact that a given data type can be written in a single operation != visibility across all processors in an MP system. > doubles on ia32 need locking to be atomic, on > ia64 they don't. I think that the later models of ia32 can write up to 8 bytes at a time. > Any suggestions on best practice for this? I think you might want to send this post to comp.programming.threads too - you may get some interesting feedback. I think Alexander Therekhov has some class wrapper for atomic types that I am sure he'd be keen to discuss, but unfortunately I've never had the time to review it. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

2 1

[Output Formatter]: Cascading Style Sheets (CSS) proposal
by Reece Dunn 20 Sep '04

20 Sep '04

Throughout this e-mail, I assume the following aliases: namespace io = boost::io; namespace fmt = boost::io::format; namespace css = boost::io::css; NOTE: This is a design outline for features in a future version of the library. David Abrahams has suggested the ability to specify default formatting on a stream. I have implemented a simple version of this so that you can do: io::sequence_decorators< char > seq( "; " ); std::cout << '"' << seq.open( std::cout ) << "\"\n" // "[ " << '"' << seq.close( std::cout ) << "\"\n" // " ]" << '"' << seq.separator( std::cout ) << "\"\n"; // "; " where separator( std::cout ) uses the separator value specified by seq and the others use the values set on the std::cout stream. To change these defaults, you can use: std::cout << io::cdecorate( "[{ ", " }]" ); // [{ a, b, c }] The problem with this is that it changes the defaults for all the formatting used, thus you cannot have different defaults for sequences and n-ary types. Cascading Style Sheets (CSS) are a web standard [http://www.w3.org/Style/CSS/] used for controlling how HTML tags are displayed to different devices (screen, printer and speech). == Inlined Styles In HTML you can specify "inlined" styles using a style attribute, e.g.: <div style = "color: red;">Red Text</div> My library equivalent is to use the decorate() function, e.g.: fmt::range().decorate( "<-- ", " -->" ); == Dynamic Styles 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 = " >>"; A more complex example that uses nested format objects: fmt::container_t< char, fmt::pair_t< char > > my_fo = fmt::container( fmt::pair()); my_fo.elem.open = "<< "; my_ob.elem.close = " >>"; my_ob.separator = " | "; std::cout << io::object( ob, my_ob ); // output: [ << a, 5 >> | << b, -1 >> ] == Cascading Style Sheets HTML provides a <style> tag to specify styling across the document without linking to an external file, e.g.: <style>h1{ color: orange; font-size: 2pc; }</style> The equivalent within my library would be to define the styling on a stream, e.g.: std::cout << css::element( "pair" ) [ ( css::attribute( "open" ) = "<< " ) + ( css::attribute( "close" ) = " >>" ) ] << css::element( "container" ) [ css::attribute( "separator" ) = " | " ] << io::object( ob ) // output: [ << a, 5 >> | << b, -1 >> ] << css::element( "pair" ) [ css::attribute( "separator" ) = " = " ] << io::object( ob ); // output: [ << a = 5 >> | << b = -1 >> ] HTML can import styling from an external CSS file. The equivalent would be to use an object to hold the styling, e.g.: css::stylesheet< char > style = css::element( "pair" ) [ css::attribute( "separator" ) = " = " ] + css::element( "container" ) [ ( css::attribute( "open" ) = "{ " ) + ( css::attribute( "close" ) = " }" ) ] ; std::cout << style << io::object( ob ); // output: { [ a = 5 ], [ b = -1 ] } It should be possible to provide the ability to save/load styling to/from a file and allow copying of style objects, e.g.: css::stylesheet< char > style2( "mystyles.style" ); // load styling style.load( "newstyles.style" ); style = style2; style.save( "stylings.sty" ); NOTE: The css::stylesheet class will store the styles using something like: std::map< std::string, std::map< std::string, std::string > > therefore it will be possible to use my library to implement the load and save facilities! Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

5 4

Thread/intel-win32-8.1 failures
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

As shown in http://tinyurl.com/6ukqm, _all_ thread library tests fail on Intel 8.1 with memory access violation (!). That's especially weird because Intel 8.0 shows quite the opposite results -- it passes all the tests. Could somebody with local access to this compiler please take a look at this? -- Aleksey Gurtovoy MetaCommunications Engineering

3 6

Re: Lexical cast suggestion
by Martin Adrian 20 Sep '04

20 Sep '04

>From: Terje Slettebø <tslettebo <at> broadpark.no> >Subject: Re: Lexical cast suggestion >Newsgroups: gmane.comp.lib.boost.devel >Date: Sat, 18 Sep 2004 14:23:50 +0200 >>From: "Martin" <adrianm <at> touchdown.se> >> I have tried to use lexical_cast many times but I always run into problems >> sooner or later due to the lack of locale support. >This issue has come up with quite regular intervals. The current docs says a >little bit about this: >"Where a higher degree of control is required over conversions, >std::stringstream and std::wstringstream offer a more appropriate path." My concern is that the current implementation gives you a false sense of portability. The documentation says nothing nothing about locales. Even the test cases for lexical_cast assumes the default "C" locale. E.g. BOOST_CHECK_EQUAL("1.23", lexical_cast<std::string>(1.23)); I think there should be a big warning about using lexcial_cast for convering numbers to/from text. The only safe place I see is when the resulting string is used to create user messages. A quick scan shows that at least "program options" uses lexical_cast for other things than user messages. lexical_cast is used to validate entries and to create default values. This means that the options must be specified in the locale the application uses (which might not be the same as the computer is running). This might be intentional but it is not documented so I have no idea how program options works in my locale.

2 1

Linux regressions
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

A clarification for developers monitoring regression reports: a significant number of Linux regressions showing up in the current reports (http://www.meta-comm.com/engineering/boost-regression/developer/summary.html) is NOT a result of some recent checkin. Most of these failures were there for some time, but weren't highlighted as regressions because the report generation tools didn't have the data for this platform to compare against. This was fixed yesterday. Similarly, new regressions for "cw-8.3" toolset are only a result of updating the old toolset name ("cwpro83") in the 1.30.2 results. I hope we can take care of these new issues quickly, although "gcc-2.95.3-stlport-4.5.3-linux" in particular doesn't look that good. Is it still a widely-used configuration? -- Aleksey Gurtovoy MetaCommunications Engineering

4 6

[Function] GCC 3.4.1 failure
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

Doug, Could you please take a look at this one (from http://tinyurl.com/7yyu5) "C:\MinGW341\bin\g++" -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mno-cygwin -I"C:\MinGW\Bronek\boost\results\bin\boost\libs\function\test" -I "C:\MinGW\Bronek\boost\boost" -o "C:\MinGW\Bronek\boost\results\bin\boost\libs\function\test\lambda_test.test\mingw-3.4.1\debug\lambda_test.obj" "C:\MinGW\Bronek\boost\boost\libs/function/test/lambda_test.cpp" C:\MinGW\Bronek\boost\boost\libs/function/test/lambda_test.cpp: In function `int test_main(int, char**)': C:\MinGW\Bronek\boost\boost\libs/function/test/lambda_test.cpp:30: error: call of overloaded `bind(unsigned int (&)(int, bool, double), int, const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >&, const boost::lambda::lambda_functor<boost::lambda::placeholder<2> >&)' is ambiguous C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:500: note: candidates are: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<4, boost::lambda::function_action<4, T> >, typename boost::lambda::detail::bind_tuple_mapper<Result (&)(Par1, Par2, Par3), const Arg2, const Arg3, const Arg4, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(Result (&)(Par1, Par2, Par3), const Arg2&, const Arg3&, const Arg4&) [with Result = unsigned int, Par1 = int, Par2 = bool, Par3 = double, Arg2 = int, Arg3 = boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Arg4 = boost::lambda::lambda_functor<boost::lambda::placeholder<2> >] C:/MinGW/Bronek/boost/boost/boost/lambda/detail/bind_functions.hpp:528: note: const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<4, boost::lambda::function_action<4, boost::lambda::detail::unspecified> >, typename boost::lambda::detail::bind_tuple_mapper<const Arg1, const Arg2, const Arg3, const Arg4, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type>::type> > boost::lambda::bind(const Arg1&, const Arg2&, const Arg3&, const Arg4&) [with Arg1 = unsigned int ()(int, bool, double), Arg2 = int, Arg3 = boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, Arg4 = boost::lambda::lambda_functor<boost::lambda::placeholder<2> >] ? -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Python/indirect_traits_test fails on all platforms
by Aleksey Gurtovoy 20 Sep '04

20 Sep '04

For instance (from http://tinyurl.com/5qne8) call "c:\Programme\Metrowerks\Codewarrior\Other Metrowerks Tools\Command Line Tools\cwenv.bat" -quiet mwcc -c -lang c++ -maxerrors 5 -warn on -maxwarnings 20 -nowraplines -g -O0 -inline off -cwd include -warn nounusedexpr,nounused -runtime dmd -DNOMINMAX -RTTI on -iso_templates on "-IC:\boost_regression\results\bin\boost\libs\python\test" -I- "-IC:\boost_regression\boost" -o "C:\boost_regression\results\bin\boost\libs\python\test\indirect_traits_test.test\cw-9.3\debug\threading-multi\indirect_traits_test.obj" "..\libs\python\test\indirect_traits_test.cpp" ### mwcc Compiler: # File: ..\libs\python\test\indirect_traits_test.cpp # ----------------------------------------------------- # 15: using namespace boost::python::detail; # Error: ^^^^^^ # undefined identifier 'detail' ### mwcc Compiler: # 19: ((is_reference_to_function<int (&)()>::value) ? ((void) 0) : __msl_assertion_failed("is_ref; # Error: ^ # undefined identifier 'is_reference_to_function' ### mwcc Compiler: # 20: ((!is_reference_to_function<int (*)()>::value) ? ((void) 0) : __msl_assertion_failed("!is_re; # Error: ^ # undefined identifier 'is_reference_to_function' ### mwcc Compiler: # 21: ((!is_reference_to_function<int&>::value) ? ((void) 0) : __msl_assertion_failed("!is_referen; # Error: ^ # undefined identifier 'is_reference_to_function' ### mwcc Compiler: # 24: ((!is_pointer_to_function<int (&)()>::value) ? ((void) 0) : __msl_assertion_failed("!is_po; # Error: ^ # undefined identifier 'is_pointer_to_function' # Too many errors printed, aborting program User break, cancelled... -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

[all/build] Build change that affects testers...
by Rene Rivera 19 Sep '04

19 Sep '04

All, Some time ago the following problem surfaced: Robert Ramey wrote: > Almost all the tests for the serialization system fail to link with the > following message: > > ### mwld Linker Error: > # Undefined symbol: '_errno' > # referenced from 'void > boost::unit_test::hrf_report_formatter::report_assertions_stat(class > std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, > unsigned long, unsigned long, unsigned long) > (?report_assertions_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$basi > c_ostream@DU?$char_traits@D@std@@@std@@IKKK@Z)' in unit_test_result.obj > (libboost_test_exec_monitor.lib) > ### mwld Linker Error: > # Undefined symbol: '_errno' > # referenced from 'void > boost::unit_test::hrf_report_formatter::report_sub_test_cases_stat(class > std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, > unsigned long, unsigned long) > (?report_sub_test_cases_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$ > basic_ostream@DU?$char_traits@D@std@@@std@@IKK@Z)' in unit_test_result.obj > (libboost_test_exec_monitor.lib) > > Errors caused tool to abort. > > To me, this suggests some issue regarding libboost_test_exec_monitor.lib . > > Anyone care to comment? I spent most of yesterday and today trying to figure this problem out. What it boiled down to was the "errno" use in the std::log10 function. But that wasn't the real problem... The reason it gives the above error is that when building certain tests like serialization and threads the library was using the multi-threaded runtime while the Boost.Test was using single-threaded runtime. Which needles to say is a very bad thing of the build system to do. Much time later I managed to track down the problem in the build system and fix. Now, the *important* part... This change will affect all platforms that use multiple runtimes. As far as I know this includes all Win32 compilers. So don't be surprised if the next run of regression tests take a long time and more disk space, because different variants of things will get compiled now. And if you are really paranoid about testing, you might be advised to delete the "bin/boost" build directory to start fresh. Enjoy -- the corrected functionality ;-) PS. I'm starting a fresh run of the CW-8.3/release tests now. Which should show a large number of fixed failures. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

4 6

old regression results question
by Reece Dunn 19 Sep '04

19 Sep '04

On the regression summary page (http://www.meta-comm.com/engineering/boost-regression/developer/summary.html) there are several instances where a toolset is duplicated (win32+cw-8.3, win32+vcX.X). I was wondering if it was possible to display only the most recent results for the toolset in that instance. This would help to see where the regressions are and shorten the width of the table. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

3 3

Re: [boost] Where are they now? (needed license permissions)
by JOAQUIN LOPEZ MU?Z 19 Sep '04

19 Sep '04

----- Mensaje original ----- De: John Maddock <john(a)johnmaddock.co.uk> Fecha: Jueves, Septiembre 16, 2004 2:20 pm Asunto: [boost] Where are they now? (needed license permissions) > Here are the people we still need to contact, in order to move the > rest of > Boost over to the BSL, if anyone has a more up to date email > address for > these folks than the ones shown here, please let me know, as at > present > they're not responding :-( > > Joaquín M López Muñoz joaquin(a)tid.es Hi John, this is Joaquín. I'm afraid my name appears in the list due to the occurrence of the SGI text in some of my files which are, otherwise, under the BSL license. This thread will probably refresh your mind, as we already discussed the issue: http://lists.boost.org/MailArchives/boost/msg69520.php I case you still need my permission in the blanket tile (which I don't think it's the case) please tell me so. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

stlport.jam patch
by Aleksey Gurtovoy 19 Sep '04

19 Sep '04

I just commited the following patch to "stlport.jam": =================================================================== RCS file: /cvsroot/boost/boost/tools/build/v1/stlport.jam,v retrieving revision 1.7 diff -r1.7 stlport.jam 103,104c103,106 < flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug : $(STLPORT_LIB_BASE_NAME)_stldebug ; < flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release : $(STLPORT_LIB_BASE_NAME) ; --- > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)_stldebug_static ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)_stldebug ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)_static ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; That should take care of a number of failures with all STLPort-based toolsets; for instance, like this one -- http://tinyurl.com/5djsj. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Avoiding warning on the do{...}while(0) macro implementation trick
by Ivan Vecerina 19 Sep '04

19 Sep '04

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? Could this approach be used to stop disabling warning 4127 when boost is compiled? Do other compilers have similar warnings and workarounds? Should a boost macro that expands to a warning-free always-false (or always-true) compile-time constant be considered? This would also allow statements such as BOOST_ASSERT(BOOST_FALSE), while(BOOST_TRUE), or do{...}while(BOOST_FALSE) to compile without warning... Regards, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

2 1

Concept_check.hpp question
by Aleksey Gurtovoy 19 Sep '04

19 Sep '04

Is there a good reason for the following #ifdef in "concept_check.hpp": template <class Concept> inline void function_requires(mpl::identity<Concept>* = 0) { #if !defined(NDEBUG) void (Concept::*x)() = BOOST_FPTR Concept::constraints; ignore_unused_variable_warning(x); #endif } ? It causes "concept_check_fail_expected" test to fail if compiled in "release mode"; see http://tinyurl.com/6u286. Any objections to removing it? -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re:[boost] Re: [static_assert] Regression with gcc 3.4.2?
by Robert Ramey 19 Sep '04

19 Sep '04

"David B. Held" <dheld(a)codelogicconsulting.com> wrote in message news:cihmvu$3ik$1@sea.gmane.org... > #include <boost/static_assert.hpp> > > template <typename T> > struct foo > { > void bar(void) > { > BOOST_STATIC_ASSERT(false); > } > }; I use .... BOOST_STATIC_ASSERT(sizeof(T) == 0); .... Robert Ramey

2 1

RE: [boost] Re: [Output Formatter]: Cascading Style Sheets (CSS)proposal
by Robert Ramey 19 Sep '04

19 Sep '04

Reece Dunn wrote: >I agree that Boost.Spirit, Boost.Serialization and my library overlap to >certain degrees. >IOW, CSS would be unnecessary complication for Output Formatter at this >stage. I like it this way:simple to understand and use. Formatting options >are reasonably limited. >This is the direction I am currently taking. Possibly, at some point in the >future, this library could become the output complement to Spirit (allowing >advanced code generation), as well as Spirit simplifying the binding of data >to the parser. But then again, I don't know how feasible that would be. Personally, I don't see much overlap at all between, serialization, io streams, spirit and output formatting. I see them a more complementary. Of course serialization uses streams so might work with io streams library. Serialization uses spirit to implement xml archives and it is possible someone might want to make an "annotated" archive and so want to exploit output formatting facilities. But in general these are orthogonal functions that can be composed at will. So I would be careful about making the output formatter library bigger. Bigger isn't necessarily better. I think its better if it focuses on doing one thing better than any other library does it and presents a minimal interface so that can be easily composed with related but different concepts. Robert Ramey

1 0

[static_assert] Regression with gcc 3.4.2?
by David B. Held 18 Sep '04

18 Sep '04

#include <boost/static_assert.hpp> template <typename T> struct foo { void bar(void) { BOOST_STATIC_ASSERT(false); } }; int main(void) { } --------------------------------------------------------------------- toot.cpp: In member function `void foo<T>::bar()': toot.cpp:8: error: invalid application of `sizeof' to incomplete type `boost::STATIC_ASSERTION_FAILURE< false>' --------------------------------------------------------------------- Is gcc wrong, or am I missing something really obvious? This used to work. And yes, I have the latest boost CVS snapshot. Dave

2 4

RE: [boost] Re: [Output Formatter]: Cascading Style Sheets (CSS)proposal
by Reece Dunn 18 Sep '04

18 Sep '04

Tony Juricic wrote: >My few cents: >Serialization, iostreams, Spirit (great piece of code!) and new Output >Formatter overlap enough in certain segments that, IMO, serious thought >should be given to combining them in the best possible way; i.e. maintain >the simplicity and specific target of each module while, eventually, >promoting overlap areas into the new libraries. The iostreams library simplifies creating custom stream types. This will interact with the others since it provides the C++ I/O stream interface. I am not overly familiar with the Serialization library, but IIUC, the archive objects use stream objects to perform the back-end I/O. It provieds support for circular data structures. Spirit is a generic parser creator. This is focused on input only. Also, I have found it needs quite a bit of code to bind a data type to the parser (e.g. reading in a pair of values). I agree that Boost.Spirit, Boost.Serialization and my library overlap to certain degrees. >IOW, CSS would be unnecessary complication for Output Formatter at this >stage. I like it this way:simple to understand and use. Formatting options >are reasonably limited. This is the direction I am currently taking. Possibly, at some point in the future, this library could become the output complement to Spirit (allowing advanced code generation), as well as Spirit simplifying the binding of data to the parser. But then again, I don't know how feasible that would be. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Re:[boost] [serialization] one MSVC build fix
by Robert Ramey 18 Sep '04

18 Sep '04

> 1) Hard-coded paths should be avoided. >Example: test_exported project contains path >c:/boost/lib/libboost_test_exec_monitor-vc71-sgd.lib. >Instead it should contain: >"$(ProjectDir)../../../bin/boost/libs/test/build/libboost_test_exec_monitor . >lib/vc7.1/$(OutDir)/runtime-link-static/libboost_test_exec_monitor-vc71-sgd - >1_32.lib" >2) Notice quotes around the new path above. It is recommended to use quotes >for paths that may contain spaces. For example if ProjectDir variable was >C:\My Tests you will get confusing build error message. >The above applies to many other serialization test projects. I've struggled with this on and off. On one hand ,I like to use the VC IDE and for that I need the test projects - 50 of them ! On the other hand, I like bjam also for buiding testing everything in batch mode for all the compiler combinations I use. So my main problem is having it both ways. The IDE "likes" to place to the intermediate objects, libraries, etc in certain places in the directory tree while bjam "likes" to put them in an entirely different place. What I would like is to have the VC IDE projects setup so that they use the same places as bjam. Without this I end up with two copies of intermediate objects in different places and this can sometimes create confusion which wastes a lot of time. However, implementing this has a couple of issues. a) it's a pain to setup up 50 the vc projects to use the bjam locations. . I've changed the type of build, threading, use dll vs static lib, etc a couple of times and it's a huge pain each time. b) it requires that bjam already have been run once in order to create the required directories >If anybody wants me, I'll be more than happy to test and suggest fixes for >MSVC builds, versions 6,7.1 or 8.0 Express. IOW, so much I dislike bjam. If you want to fix up the whole set of projects for vc 7.1 and vc 6 ide consistent with the above I would be appreciative. Let me know if you want to do this and I'll send you my most recent copies. Then you can send it back and I can test it and check it in. >Nothing specific for bjam, though: there is not a single cross-platform >build tool that I liked, like or will ever like. LOL - Build systems and issues in general drive me crazy. So do variations in compiler function re arcane corners of C++. So does rap music. Robert Ramey

3 2

Regression Tests, Boost.Serialization
by Martin Wille 18 Sep '04

18 Sep '04

Hi, Houston, we have a problem. The 209 recently added B.S tests apparently result in ~20MB binaries each for gcc-3.x compilers. For me this means that the nests will need ~20GB more disk space. All the other tests with all compilers I'm testing for together take ~10GB. This is not only slightly unbalanced, it also came as a surprise to me when I suddenly saw the unexpected disk full errors. Why does this kind of things always happen so short before a release? Please, everyone, if you do something that will have serious impact on the tests being run, please, notify the testers in advance. (I still think we should have a separate list for regression test related stuff, btw.) I had a few GB of disk space left a few days ago. Now, I'm unable to run all the tests. I could drop one of the gcc-3.4 versions. However, I'd still be short by ~10GB after that. Is there a way of reducing the number of tests in Boost.Serialization? Would it be viable to strip the test binaries (thereby losing debug information)? Any other suggestions? Compilers do drop? Regards, m PS: Yes, I'm already trying to clean my disks ;-)

7 21

Lexical cast suggestion
by Martin 18 Sep '04

18 Sep '04

I have tried to use lexical_cast many times but I always run into problems sooner or later due to the lack of locale support. Why not add a locale overload (or default argument) to lexical_cast. std::string x = lexical_cast<std::string>(1234); // "1 234" on my PC std::string y = lexical_cast<std::string>(1234, std::locale::classic ()); // "1234" on my PC double xmlDbl1 = lexcal_cast<double>("1.23"); // bad_cast on my PC double xmlDbl2 = lexcal_cast<double>("1.23", std::locale::classic()); The change would be minimal lexical_stream() { becomes lexical_stream(const std::locale& loc) { stream.imbue(loc); and template<typename Target, typename Source> Target lexical_cast(Source arg) { detail::lexical_stream<Target, Source> interpreter; becomes template<typename Target, typename Source> Target lexical_cast(Source arg, const std::locale& loc = std::locale()) { detail::lexical_stream<Target, Source> interpreter(loc);

2 1

RE: [boost] Re: [Output Formatter]: Cascading Style Sheets (CSS)proposal
by Reece Dunn 18 Sep '04

18 Sep '04

Pavel Vozenilek wrote: >"Reece Dunn" wrote: > > > Cascading Style Sheets (CSS) are a web standard > > [http://www.w3.org/Style/CSS/] used for controlling how HTML tags are > > displayed to different devices (screen, printer and speech). > > > > It should be possible to provide the ability to save/load styling >to/from >a > > file and allow copying of style objects, e.g.: >Wouldn't it be easier (for user) to specify >template-like file (HTML + some marks) >and the library would fill in marked areas with data? The question is how to process this file to extract the default formatting information. >HTML-like templates would be easy to create >and verify. The C++ code won't need to contain >complex embedded CCS. Mistakes in template >could be handled gracefully. Missing template >could be handled too. Sure. However, you would probably need a Spirit grammar to process it, adding a dependancy and making the code more complex. >When I want debug dump the last thing I need >is playing with subtlety of another language. If you want a debug dump, you can output the STL container directly: std::cout << "vector = " << vec << '\n'; The CSS stuff would only be relevant for the default formatting. Custom formatting works in pretty much the same way as described in the docs (with the name changes). The proposed CSS syntax behaves like Phoenix/Fusion in Boost.Spirit, using expression templates, e.g.: std::cout << css::element( "pair" ) [ css::attribute( "separator" ) = " = " ] << io::object( _pair ) << '\n'; so this isn't another language. I was using HTML+CSS as a model for implementing the styling here, showing how the concepts cross over. That said, getting this working would be developer investment, compile time, run-time and memory intensive, especially for more complex styling, whereas I already have a version up and running that allows you to control default styling for global decorators on a stream. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

Proposal for 'is_dereferenceable' and other template metafunctions
by Alex Chovanec 18 Sep '04

18 Sep '04

Hello, A while back, I proposed a template metafunction called 'is_iterator', but the consensus seemed to be that it was not feasible from an implementation standpoint. At Jonathan Turkanis' suggestion, I went ahead and implemented the less ambitions 'is_dereferenceable', along with two other metafunctions: Requirements: Given t of type T &, if the expression *t is not well-formed, then it must neither be ambiguous nor violate access. Description: is_lvalue_dereferenceable<T> - true if *t is well-formed and an lvalue is_value_dereferenceable<T> - true if *t is well-formed and non-void is_dereferenceable<T> - true if *t is well-formed I would like to offer these up for inclusion in boost, whether in namespace boost or in boost::detail. (presumably the latter, since that's where the similar 'is_incrementable' is found). I have posted the source for these metafunctions along with a unit test in the YahooGroups Files section in a folder called 'is_dereferenceable'. Please let me know if these are of interest to anyone. Alex Chovanec

8 29

[serialization] one MSVC build fix
by Tony Juricic 18 Sep '04

18 Sep '04

I was using serialization MSVC solution file to build modules and found some problems. 1) Hard-coded paths should be avoided. Example: test_exported project contains path c:/boost/lib/libboost_test_exec_monitor-vc71-sgd.lib. Instead it should contain: "$(ProjectDir)../../../bin/boost/libs/test/build/libboost_test_exec_monitor. lib/vc7.1/$(OutDir)/runtime-link-static/libboost_test_exec_monitor-vc71-sgd- 1_32.lib" 2) Notice quotes around the new path above. It is recommended to use quotes for paths that may contain spaces. For example if ProjectDir variable was C:\My Tests you will get confusing build error message. The above applies to many other serialization test projects. If anybody wants me, I'll be more than happy to test and suggest fixes for MSVC builds, versions 6,7.1 or 8.0 Express. IOW, so much I dislike bjam. Nothing specific for bjam, though: there is not a single cross-platform build tool that I liked, like or will ever like. Tony

1 0

Random Library
by Andy Tompkins 18 Sep '04

18 Sep '04

Hi, I have a question about the random library. I'm using vc7.1 and I'm getting a warning when I include the random library. The warning I get when I, #include <boost\random.hpp> is: d:\includes\boost_1_31_0\boost\random\linear_congruential.hpp(233) : warning C4244: 'return' : conversion from 'boost::uint64_t' to 'boost::int32_t', possible loss of data When I look at the file, rand48::operator() returns an int32_t, but lcf is defined with uint64_t. Thanks in advance for any help. Andy.

2 1

Re: program_options bool_switch usage string
by Jonathan Graehl 18 Sep '04

18 Sep '04

> > >here's another possibility: > > value<type>(&variable, "filename")->...... > >something like that was in the pre-review version, with the difference that >the value name was also used to specify flags, e.g "filename?" would mean >the value is optional. > > > Yes ... I like this best. >> Also, I'm not sure why 0-argument items couldn't appear in a config >> file. I declare the number of arguments used by options before I parse >> the config file, after all. > >Because the current config parser, systantically, requires that everything >specified there has a value. If you specify that an option accepts no >explicit value, it can't be present in config file. > OK, your statement was with reference to the current config parser ;) A newer parser could recognize the end of an option name first, then interrogate the option to see if it takes an argument, then if it does, expect to parse a "= value".

2 3

Dot in Boost Library Names?
by David Abrahams 18 Sep '04

18 Sep '04

[Background for those who don't know: a. when you write a book, the publisher sicks (or is it sics?) a copyeditor on your manuscript to clean up all the bad grammar, stylistic fauxes pas, and so on. To reject a change you mark it with "stet". b. Boost decided long ago, for reasons I don't recall, on a convention of writing library names with a period after Boost, as in: Boost.Python ] When the copyeditor went over the manuscript for C++ Template Metaprogramming, she very consistently took out the periods in library names like Boost.Python, Boost.Bind, etc. Her changes didn't seem to hurt the book seriously so rather than laboriously "stet" them all, I just let it go. I'm writing a foreword for Bjorn's book soon, so he sent me his manuscript. Bjorn consistently uses a different notation. I thought it made sense for us to get our story straight on how these names will be represented in publications. These were my ideas: - The names will be set in roman type - The library name will be capitalized - The period will only be used when the library name is not followed by the word "library": The great thing about Boost.Bind is that you can use it with member functions and function objects. The Boost Bind library was written by Peter Dimov. - The word "library" is not part of the library name and is therefore lowercased. Among the moderators and authors everyone agreed with the ideas, except that there was some discussion of whether and how the dot should be used. Some argued for never using the dot; some for always using it. An informal -1,0,1 poll was inconclusive: -1 votes +1 votes -------- -------- Never | 1 3 Always Except Before Library | 2 3 Always | 1 2 We all thought it would be a good idea to get feedback from the whole Boost community, **but I don't want this to suck up a lot of list bandwidth**, so I'm going to close voting at the end of 9/16 (my time). If you care how this comes out, please post your -1,0,+1 votes on the three options above. Please copy this part of the message into your reply and vote there: Never: Always Except Before Library: Always: This is a seemingly trivial issue that hardly deserves as much attention as we've already given it, so I'm crossing my fingers that we won't enter a bike shed with it ;-) Thanks, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

12 39

[type_traits] function_traits and functors
by Thorsten Ottosen 18 Sep '04

18 Sep '04

Hi, What is the reason that function_traits is not defined for function objects? Is it impossible? br Thorsten

4 4

[optional] In-Place Factories
by David Abrahams 17 Sep '04

17 Sep '04

I'm finding the documentation for in-place factories highly frustrating. There's no formal documentation for TypedInPlaceFactory, and almost no description whatsoever for InPlaceFactory. None of what's there describes how these things interact with optional; it isn't even mentioned in the corresponding section! Also, what is the rationale for CamelCase in these classes? The only thing we use CamelCase for in Boost is the names of concepts. Can we clear this stuff up? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 7

typeof
by Arkadiy Vertleyb 17 Sep '04

17 Sep '04

Hi all, The new version of typeof library can be found at: http://groups.yahoo.com/group/boost/files/typeof.zip This version contains the following improvements: 1) The compilation speed is significantly improved for simple types by not instantiating unnecessary templates; 2) Support for integral template parameters has been added so that, for example, a template: template<class T, unsigned int ui, bool b, short s> class foo; can be registered like this: BOOST_REGISTER_TEMPLATE_X(foo, (class)(unsigned int)(bool)(short)); (_X stands for "extra" or "extended". Any naming improvement suggestions are welcome) A template parameter can be described as: class typename [unsigned] char [unsigned] short [unsigned] int [unsigned] long unsigned bool 3) The vector size limit is now controled by BOOST_TYPEOF_LIMIT_SIZE. If it is bigger than BOOST_MPL_LIMIT_VECTOR_SIZE, the additional vector definitions are generated automatically (using the method suggested and explained by Aleksey Gurtovoy). (There appears to be one more limitation that I wasn't aware of. It is related to the max number of template parameters allowed by the compiler. For example, VC7.1 appears to have a limit of 64) 4) All is compiled against current Boost CVS. Any comments are most welcome. Regards, Arkadiy

4 32

IOStreams formal review -- extended
by Jeff Garland 17 Sep '04

17 Sep '04

All - We are extending the IOStreams review for one week until 9/11/04. While we have had many good reviews, the library is quite large and we would like to see addtional discussion and review. I've included the library information for your reference. Thanks, Jeff ----- Today (August 28th, 2004) is the start of the formal review of the Iostreams library by Jonathan Turkanis. I will be serving as review manager. Note that this is a somewhat unusual situation in that we have several libraries that overlap in the same area, so comments related to the MoreIo overlap are needed. As usual, please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments ********************************************** Library Synopsis ********************************************** The Iostreams Library serves two main purposes: * To allow the easy creation of standard C++ stream and stream buffer classes for new data sources and sinks. * To provide a convenient interface for defining i/o filters and attaching them to standard streams and stream buffers. The library focuses on freeing users from writing boiler plate code and allowing them instead to create highly reusable components. In addition to providing an abstract framework the library provides a number of concrete filters, sources and sinks which serve as example applications of the library but are also useful in their own right. These include components for accessing memory-mapped files, for file access via operating system file descriptors, for code conversion, for text filtering with regular expressions, for line-ending conversion and for compression and decompression in the zlib, gzip and bzip2 formats. The latest package can be found at the following locations: http://home.comcast.net/~jturkanis/iostreams/

7 22

Re:RE: [boost] Re: FORMAL Review of "Output Formatter" library -
by Robert Ramey 17 Sep '04

17 Sep '04

> 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". > If your making changes in the library already, maybe you might want to consider withdrawing it from the formal review and re-submitting it after you've made all the changes you want to make. It might be easier (for you as well as for reviewers) than going through the whole process more than once. Robert Ramey

1 0

lvalue_cast
by Neal D. Becker 17 Sep '04

17 Sep '04

This handy little item, lvalue_cast, would make a useful addition to boost. I didn't write it, and I don't recall who did. template<class T> inline T& lvalue_cast (const T& rvalue) { return const_cast<T&> (rvalue); } Example usage: #include <vector> #include <boost/range.hpp> template<class T> inline T& lvalue_cast (const T& rvalue) { return const_cast<T&> (rvalue); } template<typename in_cont_t> int F (in_cont_t & in) { return 2; } int main() { std::vector<int> v (4); F (lvalue_cast (boost::make_iterator_range (v.begin(), v.end()))); << OK F (boost::make_iterator_range (v.begin(), v.end())); << error! } -- Please AVOID sending me WORD, EXCEL or POWERPOINT attachments. See http://www.fsf.org/philosophy/no-word-attachments.html

5 9

RE: [boost] spirit 1.8 / vc 8.0 test results
by Ben Hutchings 17 Sep '04

17 Sep '04

Paul A Bristow <pbristow(a)hetp.u-net.com> wrote: <snip> > PS The query was about an item which failed to compile using 8.0 > (OK with 7.1) > > template<typename T, typename BigT> > out_sqr(ostream& os, T x, BigT temp) > { > temp = x * x; > os << temp; > } > > Bray says that this is because the implicit function return type is > int, This is a non-standard extension for compatibility with a predecessor of C that was replaced over 30 years ago. It appals me that any current C++ compiler still supports it. > I assumed that the implicit function return type was void, > and indeed if void is added, it works as expected. C++ does not allow the return type to be implicit, and when it was allowed in C (prior to the 1999 standard) it was int. > Can anyone who has digested the Standard quote chapter and verse on > this? You're kidding, right?

2 1

Demultiplexor Glossary WIKI page.
by Carlo Wood 17 Sep '04

17 Sep '04

Hiya, I added a new page to the WIKI with a glossary. A glossary should be alphabetical, but I decided to add the terms in an order that reflects their dependencies instead (least dependend first). http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Multiplexing… This page also contains two .pdf 'literature' links that I think everyone involved in this discussion should REALLY read. Mandatory ;) Namely: http://www.cs.wustl.edu/~schmidt/PDF/Reactor.pdf http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf Without thoughrough understanding of these two patterns, it will be near impossible to continue the discussion about the API that we have to design imho. Please read! -- Carlo Wood <carlo(a)alinoe.com>

1 1

making bind and mem_fn results default constructible?
by Fredrik Blomqvist 17 Sep '04

17 Sep '04

Hi Consider this example of mem_fn usage: struct X { int bar; }; std::vector<X> vec; .... boost::make_transform_iterator(vec.begin(), boost::mem_fn(&X::bar)); The above is, strictly speaking, _not_ a Random Access Traversal Iterator, or even a Forward Traversal Iterator, and would fail in otherwise concept conforming code (or in a potential concept-check). The problems lies in the function objects returned by boost::mem_fn and boost::bind not being default constructible, thus making the resulting iterator not default constructible which is required by the Forward Traversal concept. http://boost.org/libs/iterator/doc/new-iter-concepts.html#forward-traversal… (The problem is even more pronounced if using the "old" Iterator Concepts.) I found an old (2002) mail by David Abrahams where he also noted the problem: http://lists.boost.org/MailArchives/boost/msg30420.php But it didn't seem to have resulted in any change of the codebase. I think use-cases similar to the one above are good motivation and hope this could be considered an acceptable improvement. Regards // Fredrik Blomqvist P.S. I realize it is very close to the branch for release and don't expect this to be added before that.

3 4

[archive] Add libs/archive/index.html ?
by Jonathan Wakely 17 Sep '04

17 Sep '04

I'm not sure if this has been suggested before and rejected, but would it make sense to have a libs/archive/ directory, with an index.html that simply redirects to libs/serialization/doc/ ? There is a boost/archive/ directory of headers, but it's not obvious where to find the docs for them if you don't know they're used by the serialization lib. jon -- "If you can't say anything good about someone, sit right here by me." - Alice Roosevelt Longworth

1 0

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

17 Sep '04

John Torjo wrote: >Hi Reece, > >Maybe you can show more about this after the review is over. >It's good that boosters now know you've already started to improve the lib >based on feedback, but for now, I think it's better for them to focus >feedback on the existing lib: >http://www.torjo.com/code/outfmt.zip > >Or maybe I'm just plain wrong ;) Sure. There has been some great feedback thus far. I just wanted to let boosters know the direction I am taking, WRT naming and other areas (like adding support for setting decorators on the stream like Dave suggested). Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

License Permission
by Jaap Suter 17 Sep '04

17 Sep '04

> Here are the people we still need to contact, in order to move the rest of > Boost over to the BSL, if anyone has a more up to date email address for > these folks than the ones shown here, please let me know, as at present > they're not responding > ...snip... > Jaap Suter j.suter <at> student.utwente.nl I give permission for all my contributions to Boost to be moved to the Boost Software License Version 1. I think my only contributions to Boost were in a few MPL files, and I thought those were already converted. Either way, you can add me to the blanket permission file. Jaap Suter

2 1

RE: [boost] Re: xtime_get unsafe on Windows for IA64
by Ben Hutchings 17 Sep '04

17 Sep '04

Michael Glassford <glassfordm(a)hotmail.com> wrote: > Ben Hutchings wrote: > > The implementation of the boost::xtime_get() function in > > libs/thread/src/xtime.cpp includes the following code for Windows: <snip> > > The pointer casts are not safe because although the representations > > of FILETIME and __int64 are compatible, FILETIME is only 32-bit- > > aligned whereas __int64 must be 64-bit-aligned on IA64 (in some > > processor modes). > > > > One can instead use union { FILETIME ft; __int64 i64; } and read out > > i64, though I'm not sure this code should be unconditionally using > > __int64 anyway. There is a longer explanation at > > <http://weblogs.asp.net/oldnewthing/archive/2004/08/25/220195.aspx>. > > How about this instead: > > const boost::uint64_t TIMESPEC_TO_FILETIME_OFFSET = > (static_cast<boost::uint64_t>(27111902UL) << 32) > + 3577643008UL; I think this should use the UINT64_C macro instead of messing about with casts. > const boost::uint64_t ft64 = > (static_cast<boost::uint64_t>(ft.dwHighDateTime) << 32) > + ft.dwLowDateTime; > > xtp->sec = static_cast<int>( > (ft64 - TIMESPEC_TO_FILETIME_OFFSET) / 10000000 > ); The cast should be to int_fast64_t rather than to int. > xtp->nsec = static_cast<int>(( > ft64 - TIMESPEC_TO_FILETIME_OFFSET > - (static_cast<boost::uint64_t>(xtp->sec) * 10000000) > ) * 100 > ); > > ? The cast should be to int_fast32_t. Also the use of multiplication and subtraction to calculate the remainder seems to be a premature optimisation that obscures what's really going on. A smart compiler can combine the division and remainder operations, and I have confirmed that Visual C++ 7.1 does so when generating optimised i386 code (even for 64-bit division where it uses a subroutine rather than a single instruction). So I would suggest: static const boost::uint64_t TIMESPEC_TO_FILETIME_OFFSET = UINT64_C(116444736000000000); const boost::uint64_t ft64 = (static_cast<boost::uint64_t>(ft.dwHighDateTime) << 32) + ft.dwLowDateTime; // or use the union trick which MS appears to have blessed xtp->sec = static_cast<int_fast64_t>( (ft64 - TIMESPEC_TO_FILETIME_OFFSET) / 10000000 ); xtp->nsec = static_cast<int_fast32_t>( ((ft64 - TIMESPEC_TO_FILETIME_OFFSET) % 10000000) * 100 ); Ben.

3 3

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

17 Sep '04

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". io::decoration< CharT, id > [formatter/impl/decoration.hpp] -- a decoration is a property-like object that provides the value (as a std::basic_string< CharT > object) associated with a particular decorator id. The id dictates the decoration type. Currently there are three types: open ( 0 ); close ( 1 ); and separator ( 2 ). You can use a decoration like this: io::decoration< char, 0 > decor; // empty decorator std::cout << decor(); // get value: decor == std::string(); std::cout << decor( std::cout ); // get value associated with the stream == "[ " decor = "[{ "; // provide a custom decoration value io::decorate< CharT > [formatter/impl/decorate.hpp] -- controls the open, close and separator values on a stream. There are typedefs for char and wchar_t streams: std::cout << io::cdecorate( "<< ", " >>" ); // override stream decorator defaults NOTE: io::decorate will only accept const CharT * types. This is because pword (used to implement the stream decorator defaults) is not dependant on CharT, so it is complex (if not impossible) to allocate an object based on the CharT value of a templated stream object. io::wrapper_decorators< CharT > [formatter/impl/wrapper_decorators.hpp] -- stores open/close decoration values allowing you to control their values using the decorate() function. io::sequence_decorators< CharT > [formatter/impl/sequence_decorators.hpp] -- stores open/close/separator decoration values allowing you to control their values using the decorate() function. Derives from io::wrapper_decorators< CharT >. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/ ***************************************************************************** ** ** ** 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. ** *****************************************************************************

4 4

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

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

16 Sep '04

>> I'll see if I can get a test case thrown together for std::bitset. >> I'll take a look at boost::tuple as well (but that should be big time >> trivial, so... :) ) >Erh... trivial, but tedious. Seeing as I have to redo the serialize >funtion for all possible lengths of a tuple (0 to 10 contained >elements). Unless I missed something obvious? (again) >Anyway, is serialization for tuples supposed to be a Boost.Serialization >add-on or a Boost.Tuples add-on? As Jeff Garland mentioned, generally >std::* should be in Serialization, and anything else in the respective >library. However, Boost.Serialization already provides support for e.g. >shared_ptr<> and Boost.Optional. So...? This question has come up before without being explicitly/publicly agreed upon. Jeff Garland and I have come to the following consensus: Serialization for standard containers and objects, ie members of namespace std:: will go into the boost::serialization namespace and their corresponding test will go into the serialization test library. Other serialization implementations will go into the namespace/test set of their respective libraries. All maintainence of serialization modules will be responsibility of their respective authors. There are a few boost classes in the serialization library which ended up there during development of the library. shared_ptr is and example. These are anomalous cases and not a pattern that will be continued. Obviously, its my desire to keep the serialization library as task of O(1000) rather than O(1000 + N). So that's our policy. Robert Ramey

1 0

State of giallo, (sockets and demultiplexing)
by Hugo Duncan 16 Sep '04

16 Sep '04

Spend a few days off line and you suddenly miss a whole conversation :-( It's going to take a while to catch up... Recent IOstreams discussion has indeed been very interesting, espescially as I am finally getting round to implementing buffers and filters for giallo (boost.sockets). At the moment I am leaning towards ACE style message buffer, using the apache filter idea of flush/eos/eoc control (but trying to avoid any knowledge of the underlying resource). So where is giallo today (apart from being temporarily broken on gcc due to mpl changes)? i) Low level, platform header hiding, object based wrappers of sockets, named pipes, select, and completion ports (and a POSIX aio wrapper on linux that I have tried to get to work in many different ways and failed so far). ii) proactor and reactor interfaces, with policy based implementation, provided by bridge classes to the low level completion port and select wrappers above. iii) 'event completion notification' style connector, acceptor and connection classes for sockets and named pipes. These classes combine a demultiplexer with a resource (socket, pipe, etc), and can use a proactor or reactor demultiplexer interchangeably (via template parameter). The connection selects the synchronisation mode (block, non-blocking, asynchronous) of the socket based the demultiplexer. The library is thread aware (can run multithreaded, will create threads if asked to, uses threads to do asynchronous connect if not natively supported, etc) There is a streambuf implementation, but I have not found a way to implement this without it degenerating to a thread per connection model. I feel quite strongly that the decision to implement connection, connector and acceptor concepts with a single (in this case 'event completion' style) notification interface, regardless of the demultiplexer mechanism used, is very important, and can lead to a stream/filter concept that is independent of demultiplexer, of blocking/non-blocking/asynch mode and thus independent of the resource used.

5 12

RE: [boost] State of giallo, (sockets and demultiplexing)
by Hurd, Matthew 16 Sep '04

16 Sep '04

> The only exception I can think of is if the data is to be 'multicast' down 2 > TCP connections... Another exception for you: In place messaging with a "fast message" format would be nice for support. Some network hardware, including TCP via TOE cards and infiniband and the like, support very low latency messaging, e.g. < 10 microseconds. You don't want to copy, but also you don't want to serialize. In fact, for many applications you are prepared to sacrifice architecture portability on the altar of speed and you might send a contiguous c++ object, padding from alignment and all, directly as a message block. The CPU never has to see the whole object. A diminutive $0.02, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

[mpl] gcc problem with include order dependency
by Hugo Duncan 16 Sep '04

16 Sep '04

Aleksey, With gcc (GCC) 3.3.3 (cygwin special) there is a include order dependency. Including boost/bind.hpp before boost/mpl/transform.hpp causes a compile error type named `type' in `struct boost::mpl::apply_wrap2<boost::mpl::push_front<mpl_::na, mpl_::na>, mpl_::arg<1>, wrapper<mpl_::arg<2> > >' I have not been able to test with other gcc versions. Regards, Hugo #include "boost/bind.hpp" #include "boost/mpl/transform.hpp" #include <boost/mpl/apply.hpp> #include <boost/mpl/list.hpp> #include <boost/mpl/equal.hpp> #include <boost/mpl/assert.hpp> // computed type template <typename T> struct wrapper{}; // metafunction class to compute type struct wrapped_type { template <typename T> struct apply { typedef wrapper<T> type; }; }; void test_transform() { typedef boost::mpl::list<int, char> typelist; typedef boost::mpl::list< wrapper<int>, wrapper<char> > wrapped_typelist; typedef boost::mpl::transform< typelist, wrapped_type >::type result; BOOST_MPL_ASSERT(( boost::mpl::equal<wrapped_typelist, result> )); }

3 3

RE: [boost] spirit 1.8 / vc 8.0 test results
by Reece Dunn 16 Sep '04

16 Sep '04

Paul A Bristow wrote: >I was under this impression from the MS docs, but a recent reply to my >query >by Brandon Bray at MS cites a 40901 release (perhaps an internal beta 2?), >whereas I have says 8.0.40607.16 but I am not sure if the compiler release >has changed. >(cl.exe file is 8.00.40607.16 too) I have beta 1 installed with the first tool refresh and have: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.40809 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. I think 40607.16 refers to the initial beta1 release, 40809 refers to the first tool refresh and I assume that 40901 would be the second (upcoming) tool refresh. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 2

RE: [boost] Where are they now? (needed license permissions)
by Ben Hutchings 16 Sep '04

16 Sep '04

John Maddock wrote: > Here are the people we still need to contact, in order to move the > rest of Boost over to the BSL, if anyone has a more up to date email > address for these folks than the ones shown here, please let me > know, as at present they're not responding :-( Where you've written "??" does that mean that you have no email address or that mail to it is bouncing? <snip> > Gennadiy Rozental ?? Subscribed as <gennadiy.rozental(a)thomson.com>. <snip> > Mathias Koch ?? Subscribed as <mail(a)mathias-koch.de>. <snip> > Stephen Silver ?? Possibly subscribed as <silver(a)gsc-game.kiev.ua>? > Terje Slettebø tslettebo(a)chello.no <snip> Subscribed and posted on Tuesday as <tslettebo(a)broadpark.no>. Ben.

1 0

[test] problems with new intel-win32-8.1 toolset
by Joaquín Mª López Muñoz 16 Sep '04

16 Sep '04

Just in case nobody noticed, seems like Boost.Test is failing with Intel 8.1. This error appears at run-time in plenty of tests: Exception in "call_test_main": memory access violation C:/boost_regression/boost/libs/test/src/unit_test_suite.cpp(127): fatal error in "call_test_main": Test case initialization has failed *** errors detected in test case "call_test_main"; see standard output for details Test case "call_test_main" was aborted due to uncaught exception, user assert or system error EXIT STATUS: 200 I'm quite sure the problem is in Boost.Test, since the crash happens at several different libraries, all of which use this Boost.Test. Maybe someone with local access to this compiler can debug some of the failing tests and narrow down the locus of the problem. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

Serializing bitsets and tuples
by Brian Riis 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. -- /Brian Riis

2 2

Boost Software License: Summary
by John Maddock 16 Sep '04

16 Sep '04

I've made a set of summaries for BSL conformance available at http://freespace.virgin.net/boost.regex/index.html There's one summary per library + one for all of Boost, I'd encourage everyone to take a look to see whether their work can be used under the BSL alone, or if there are non-BSL dependencies that they rely upon. Note that there are one or two cases where dependencies are found that are not real: filesystem for example ends up being shown as dependent upon the Graph lib (not under the BSL), but this is an illusion, based on iterator_adapters pulling in some python headers, which leads to a presumed dependence upon the python source. In most cases though the information shown should be accurate. Regards, John.

4 6

Howto track changes?
by Neal D. Becker 16 Sep '04

16 Sep '04

I did cvs update recently on boost-cvs, and found lots of changes - probably anticipation 1.32. I don't see a way to get a summary of changes. Does boost have such a mechanism? At mimimum, a ChangeLog for each lib. As an example of best-of-class, http://cvs-digest.org/?issue=aug202004

1 0

It seems that boost.random doesn't work under vc6.0?
by huangliang 16 Sep '04

16 Sep '04

When I tried to compile the random_demo.cpp using vc6.0 and stlport5.0, there were many errors and warnings. Does boost.random correctly work under vc6.0? I use boost1.31.0.

1 0

Regression tests for Tru64 are back.
by Markus Schöpflin 16 Sep '04

16 Sep '04

Hello, the regular regression runs for Tru64 / cxx 6.5 are back. They are run once a day by a cron job. I will be out of office for the next week, therefore I won't be able to switch to the release branch next week. This is scheduled for Monday, Semptember 27th. Markus

1 0

program_options bool_switch usage string ... how to prettify?
by Jonathan Graehl 16 Sep '04

16 Sep '04

I used to do this: >>bool help_flag; >>options.add_options() >> ("help,h","produce help message"); >>help_flag=vm.count("help") >> >>But it's possible to make a typo and everything isn't in one place (I >>prefer not to create a preprocessor macro to make "help" only occur once). >> >> > > > Now this is better: >bool help_flag; >options.add_options() > ("help,h", bool_switch(&help_flag),"produce help message"); > > > I tried it, and it works, but the usage string is a little odd: -h [ --help ] arg (=0) : produce help message -v [ --version ] arg (=0) : print the version number I would have hoped that the "arg (=0)" part would not be displayed at all for bool_switches. What would be the easiest way to suppress this? Similarly, is there some easy to use hook for customizing the "arg" to indicate the type of the data (similar to how the textual representation of the default argument can be changed, e.g. value<Infile>(&forests_file)->default_value(default_in,"STDIN"), so that I could get something like: "-f filename (=STDIN) :" instead of "-f arg (=STDIN) :"? -Jon p.s. should I post this sort of question in boost-users? I'd have to subscribe to it in order to post, so I didn't this time ...

3 6

program_options options description output
by Leo Goodstadt 16 Sep '04

16 Sep '04

Dear Volodya, Have you also given any consideration to how the descriptions wrap around if they are too long? For long descriptions, they can be quite ugly if left as is. At the moment, I output the description to a stringstream and wrap and indent everything post factum using the ": " in the output (I supply an optional line length for wrapping). This is fine and produces really nice output including embedded \n in the description text, but I wouldn't mind a more general solution. A minor nit pick, with option groups (chained options_description), the colons for the same group align but not across groups. Perhaps it might be possible to also dump the various fields of the output to some vector or even a templated callback object for greater flexibility of output. Llew Leo Goodstadt MRC Functional Genetics Unit Department of Human Anatomy and Genetics South Parks Road Oxford OX1 3QX United Kingdom leo.goodstadt(a)anatomy.oxford.ac.uk

2 1

FORMAL Review of "Output Formatter" library - 7 days left
by John Torjo 16 Sep '04

16 Sep '04

Dear boosters, For the FORMAL Review of "Output Formatter" - there are 7 days left. <side-note> There are quite a few hot topics at boost. So people might forget that there's a review going on ;) I would like to send a notification like this every 3 days. Boosters, please let me know if you find this ok or not. As I know, it hasn't been done before (announcing a format review multiple times) </side-note> Author: Reece Dunn Description: The outfmt library provides means to write and read containers/ arrays/ ranges (pairs of iterators) to/from STL streams. It also provides means to customize formatting as your write to/read from a stream: std::list<int> l; // { 1, 4, 10 } std::cout << formatob(l); // output: [ 1, 4, 10 ] std::cout << formatob(l).format("<",">"); // output: <1, 4, 10> Download: You can get it from the boost sandbox: http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/libs/outf… http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/out… As a convenience (only for the period of the review), you can also get it from http://www.torjo.com/code/outfmt.zip (153Kb) Review process: Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. When doing the formal review, please answer the following questions: 1. What is your evaluation of the design? 2. What is your evaluation of the implementation? 3. What is your evaluation of the documentation? 4. What is your evaluation of the potential usefulness of the library? 5. Did you try to use the library? With what compiler? Did you have any problems? 6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 7. Are you knowledgeable about the problem domain? And most important, 8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. More on the formal review process: http://www.boost.org/more/formal_review_process.htm The Review Manager is: John Torjo john.lists(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/

3 3

Still problems with current cvs (libs/python/src/converter/type_id.cpp)
by Neal Becker 16 Sep '04

16 Sep '04

gcc-3.3.3 (linux): In file included from /usr/local/src/boost.cvs/libs/python/src/converter/type_id.cpp:7: /usr/local/src/boost.cvs/boost/python/detail/decorated_type_id.hpp: In function `boost::python::detail::decorated_type_info boost::python::detail::decorated_type_id(boost::type<T>*)': /usr/local/src/boost.cvs/boost/python/detail/decorated_type_id.hpp:40: error: syntax error before `>' token /usr/local/src/boost.cvs/boost/python/detail/decorated_type_id.hpp:42: error: syntax error before `>' token

2 1

IOStreams endianness filter
by Tony Juricic 15 Sep '04

15 Sep '04

Just a thought. My tests so far were too limited to write a review (maybe reviews could last a little longer?), but in the process I stumbled on one image file in big-endian format and thought it may deserve to be mentioned here. Tony

2 4

Aaron's Informal Proposal for a Universal Demultiplexor for Boost
by Aaron W. LaFramboise 15 Sep '04

15 Sep '04

Well here it is. This is a very sketchy "brain dump" of the general form of demultiplexor I have been referring to. I think that it might be a basis for something eventually acceptable as a general demultiplexor for Boost. The general concept comes from a demultiplexor library that I have implemented privately (perhaps it could now be considered a prototype). I've tried to introduce the library design from a standpoint of rationale. This description is quite vague, but hopefully it will be a sufficient starting point. As always, comments of all kinds are appreciated. Aaron's Informal Proposal for a Universal Demultiplexor for Boost <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Multiplexing…> Aaron W. LaFramboise

6 18

behond IOStreams
by Carlo Wood 15 Sep '04

15 Sep '04

Hiya all. I already briefly discussed this with Jonathan Turkan and I understood he is interested to continue on a new project when IOStreams is accepted. I'd like to work together with him in this new project. In the past week I've done some "research" (between quotes because I still very new to this, can't call myself knowledgable yet). I'd start an early kick-off with this post ;). IOStreams can be seen as a library that allows one to define the following: Source --> filter --> filter --> Sink The relationship between the types involved can be delayed till runtime, but each individual type above has to be coded before that. It makes most sense to look at the above as instances instead of classes therefore (cause I did draw in the relationships between the different types already): Source_instance --> filter_instance --> filter_instance --> Sink_instance But for brevity I will not type the '_instance' part anymore. Obviously, we can have multiple Sources and Sinks at the same time: Source --> Sink Source --> filter --> filter --> Sink Source --> filter --> filter --> filter --> Sink Source --> filter --> Sink ... Each of these Sources will need to be handled by the Operating System; for example if they are sockets. In order to make an application work one will need "event demultiplexing" like forinstance is provided by select() or poll(). In order to write a framework that can "connect" the Sources and Sinks to this event demultiplexor in a flexible, portable and efficient way - a lot of design decisions need to be taken. Below I have made a list of a few topics that we can discuss, one by one - in order to make progress with these decisions. I am aware that there has been made a beginning with a design for such a framework already with boost in mind (see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket) This design mainly considers sockets, but I think that a much wider approach is necessary (as we can discuss by following the points below). But of course we will use anything of this project that is useful. Another important source of experience is libACE. Although libACE provides everything we might need, it doesn't 'connect' well to boost; it has a lot of interfaces that are already done in boost but in another way. Also, I think that libACE is doing more than we need and not everything that we might want. If it were possible to write a more 'native' event demultiplexing library for boost then that will definitely add useful and additional functionality for the open source community. Apart from that, there is the license issue. I believe that the boost libraries are more 'free' then ACE, so in some cases ACE might not even be an option. ========================================================== Follows: Topics that can be discussed. I'd like to urge to stick to one Topic per thread. 1. Is there a need for this library? Should be a new effort like proposed or do we have to revive 'boost Sockets' and only build upon that without throwing things away? If "yes - there is a need for it and we might as well start with a clean plate": For the below I have chosen to phrase the topics as statements that I believe I can give sufficient argumentation for (if needed). 2. It is unavoidable that this library uses threads. 3. User programs compiled for platform A, and linking with a shared versions of this library - do not need to be able to run on platform B (with same architecture) without recompilation. 4. It is unacceptable that we would depend on other libraries (libevent, libACE) for this, except standard libraries (libc, libstdc++, socket, ws2_32, etc). 5. We should heavily lean on the expertise that is condensed in libACE for things like the following: There must be a concept "Event Handler" (the 'call back'). There must be a concept "Acceptor", "Connector" and "Handle" types. 6. The ideas about I/O filtering as discussed for Apache (see http://www.serverwatch.com/tutorials/article.php/1129721) need to be analyzed and probably implemented in IOStreams before we can really design the demultiplexor library. I will start a thread for each of these topics. Please reply to the first subject that you do not agree with (yet) only: it makes no sense to participate in discussions with a higher number if you disagree with the statement of one with a lower number :) Regards, -- Carlo Wood <carlo(a)alinoe.com>

10 54

Re:Re: [boost] serialization tests with intel 8.0 on linux
by Robert Ramey 15 Sep '04

15 Sep '04

Matthias Troyer wrote: >Shall I get you an account on a machine with that compiler? Latest test results seem to show this to be resolved. Thanks to whomever addressed. I'm sure it wasn't me. Robert Ramey

1 0

Re: Re: Re: IOStreams formal review -- extended
by Jonathan Turkanis 15 Sep '04

15 Sep '04

"Jonathan Turkanis" <technews(a)kangaroologic.com> wrote in message news:... > (i) buffering will be omitted, since it's hard to do correctly. > (ii) buffering will be provided, but mistakes in pointer arithmetic will cause > subtle errors > (iii) sub-optimal algorithms will be used. > > Note that two of Daryle's stream buffers suffer from defect (i). I didn't mean to imply that Daryle omitted buffering because it was hard -- I assume he had some other reason. Jonathan

1 0

Current cvs build broken (/boost/python/detail/signature.hpp)
by Neal D. Becker 15 Sep '04

15 Sep '04

/usr/local/src/boost.cvs/boost/python/detail/signature.hpp: In static member function `static const boost::python::detail::signature_element* boost::python::detail::signature_arity<11>::impl<Sig>::elements()': /usr/local/src/boost.cvs/boost/python/detail/signature.hpp:34: error: syntax error before `;' token...interrupted .

2 1

serialization tests with intel 8.0 on linux
by Robert Ramey 15 Sep '04

15 Sep '04

There are a group of test failures of the serialization library on intel 8.0 on linux. See http://www.meta-comm.com/engineering/boost-regression/developer/serializatio n.html These are all associated with serialization of collections. I would guess that these are probably all variant manifestations of the same problem. Other interesting facts are: a) intel 7.1 passes on linux and win32 b) intel 8.0 passes on win32 Is there someone who has an interest in this platform would like to look into this? It would be very helpful. Robert Ramey

2 1

spirit 1.8 / vc 8.0 test results
by Robert Ramey 15 Sep '04

15 Sep '04

Spirit 1.8 with vc 8.0 is showing some test failures which impact the serialization library. In particular, the chest test is failing. Is this going to be addressed? Perhaps the vc 8.0 compiler being used for the test should be updated to the latest version if it hasn't been already. I think this would be very useful. Robert Ramey

3 2

problems with serialization regression tests
by Bronek Kozicki 15 Sep '04

15 Sep '04

I have a problem when running regression tests on Comeau compiler (toolset como- win32- 4.3.3- vc7.1) . Three tests: test_set_text_archive test_set_binary_archive test_set_xml_archive are taking above 1.5GB memory when running, thus my machine is slowing to crawl due to memory trashing (I have only 1GB RAM). I think there's something wrong with these tests? B.

1 0

Boost License Permission
by Kevlin Henney 15 Sep '04

15 Sep '04

I give permission for all my contributions to Boost to be moved to the Boost Software License Version 1. Kevlin Henney -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

1 0

[filesystem]: bug and patch in path_posix_windows.cpp
by Angus Leeming 15 Sep '04

15 Sep '04

There are lots of "#ifdef BOOST_WINDOWS ... #endif" blocks wrapping code to handle the ':' in libs/filesystem/path_posix_windows.cpp. In one place only is the preprocessor block missing, which I believe is a bug. Patch attached. Silly test case. Without the patch, this: #include <boost/filesystem/path.hpp> #include <iostream> #include <string> namespace fs = boost::filesystem; int main() { std::string const PATH="/usr/local/bin:/usr/bin:/bin"; fs::path const path(PATH, fs::no_check); std::cout << PATH << '\n' << path.native_file_string() << std::endl; return 0; } Produces /usr/local/bin:/usr/bin:/bin /usr/local/bin:usr/bin:bin under *nix. Regards, Angus

2 1

recursive mutex and condition
by James Ahlborn 15 Sep '04

15 Sep '04

hey, I was wondering if any of the boost developers could tell me if recursive mutexes are supposed to work with conditions? From the code, it would seem to be the case, however in reality things aren't so happy. I have a fairly small test case which shows that the locking doesn't work if you recursively lock a mutex and then try to do a condition wait/notify. I'm testing this on red hat 7.3 and fedora core 2. My guess as to why it's broken is because the boost condition uses posix recursive mutexes internally, which also seem to fail the recursive mutex/condition test (at least on the OS's mentioned above). Anyone have any thoughts on this? I'll include my test case below. The error (for me) happens that when Thread2 releases the "inner" lock, Thread1 proceeds, even though Thread2 should still be holding the lock. (ps- i'm aware that there are some mem leaks in the program, i just simplified it for testing). thanks, -james ------------------------------------------------------- #include <string> #include <iostream.h> #include <boost/thread.hpp> #include <boost/smart_ptr.hpp> #include <boost/bind.hpp> using namespace boost; using namespace boost::detail::thread; class ThreadBase : private boost::noncopyable { public: void start() { m_thread.reset(new boost::thread(boost::bind(&ThreadBase::run, m_weakThis.lock()))); } void join() { m_thread->join(); } protected: virtual void run() = 0; ThreadBase() : m_thread(), m_weakThis() {} virtual ~ThreadBase() {} void initWeakThis(boost::weak_ptr<ThreadBase> weakThis) { m_weakThis = weakThis; } boost::shared_ptr<boost::thread> m_thread; boost::weak_ptr<ThreadBase> m_weakThis; private: }; class Thread2 : public ThreadBase { recursive_mutex* _mutex; condition* _cond; protected: Thread2(recursive_mutex* mutex, condition* cond) : ThreadBase(), _mutex(mutex), _cond(cond) {} public: static shared_ptr<Thread2> create(recursive_mutex* mutex, condition* cond) { shared_ptr<Thread2> tmp(new Thread2(mutex, cond)); tmp->initWeakThis(tmp); return tmp; } virtual ~Thread2() { cerr << "Thread2 dying\n"; } virtual void run() { cerr << "Thread2 acquiring lock(1)\n"; recursive_mutex::scoped_lock sl1(*_mutex); cerr << "Thread2 acquiring lock(2)\n"; { recursive_mutex::scoped_lock sl2(*_mutex); cerr << "Thread2 sleeping...\n"; ::sleep(5); cerr << "Thread2 signalling...\n"; _cond->notify_all(); cerr << "Thread2 releasing lock(2)\n"; } cerr << "Thread2 sleeping (again)...\n"; ::sleep(5); cerr << "Thread2 releasing lock(1)\n"; } }; class Thread1 : public ThreadBase { recursive_mutex _mutex; condition _cond; protected: Thread1() : ThreadBase() {} public: static shared_ptr<Thread1> create() { shared_ptr<Thread1> tmp(new Thread1()); tmp->initWeakThis(tmp); return tmp; } virtual ~Thread1() { cerr << "Thread1 dying\n"; } virtual void run() { cerr << "Thread1 acquiring lock(1)\n"; scoped_lock<recursive_mutex> sl1(_mutex); cerr << "Thread1 acquiring lock(2)\n"; { scoped_lock<recursive_mutex> sl2(_mutex); cerr << "Thread1 starting Thread2\n"; shared_ptr<Thread2> t2 = Thread2::create(&_mutex, &_cond); t2->start(); t2.reset(); cerr << "Thread1 waiting\n"; _cond.wait(sl2); cerr << "Thread1 releasing lock(2)\n"; } cerr << "Thread1 releasing lock(1)\n"; } }; int main(int argc, char** argv) { cerr << "Main Starting...\n"; shared_ptr<Thread1> t1 = Thread1::create(); t1->start(); t1->join(); cerr << "Main First Run\n"; // run it again t1->start(); t1->join(); t1.reset(); cerr << "Main Done\n"; return 0; }

1 0

Re:Re: [boost] Re: mpl apply_if.hpp question
by Robert Ramey 15 Sep '04

15 Sep '04

Aleksey wrote >> But, really, how hard can a global search/replace be? Or is Spirit >> 1.6.1 archived? >No, it's not. Or, to be exact, the latest 1.6.x version which we are >supposed to compile against is not -- >http://article.gmane.org/gmane.comp.parsers.spirit.devel/1964. >I'd _much_ prefer to have this fixed by search & replace, more so because >it'd have to be done eventually sooner or later anyway, if Spirit 1.6.x is >meant to live past this release. I'm agnostic on this - I just want to be able to run the serialization library on all the platforms its designed to run on. If spirit 1.6.x gets fixed to use eval_if - the issue disappears. I don't have the access to fix it and wouldn't do so anyway. I'm afraid to touch it - If I break it then I have to buy it. So, I've checked in apply_if pending fixup in spirit 1.6.x at which point the apply_if can be removed (again). This is just a spirit issue - no changes in the serialization library itself are indicated. Robert Ramey

4 3

Explicit test markup problems
by Vladimir Prus 15 Sep '04

15 Sep '04

Hello, the colors on http://www.meta-comm.com/engineering/boost-regression/developer/program_opt… seems to be incorrect: 1. I've tried to mark all *dll tests on como as failing, but they are still yellow. 2. I never marked vc7 as failing, but still it's deep green (unexpected pass). Any ideas what's wrong? - Volodya

2 1

program_options problem on platforms with incomplete wchar_t
by Harri Pasanen 15 Sep '04

15 Sep '04

Hello, Looking at program_options headers, it does not appear to guard against BOOST_NO_STD_WSTRING being defined? This poses a problem when using gcc on platforms such as Solaris, HP-UX, as functions like std::codecvt<wchar_t, char, __mbstate_t>::do_length(...) are not defined in the libstdc++. Is this a know problem, should I come up with a patch, or what? Regards, Harri Pasanen This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code. This message, including any attachments, is intended only for the person(s) to whom it is addressed. If you received it in error, please let us know and delete the message from your system. This message may be confidential and may fall under the duty of non-disclosure. Any use by others than the intended addressee is prohibited. Trema shall not be liable for any damage related to the electronic transmission of this message, such as failure or delay of its delivery, interception or manipulation by third parties, or transmission of viruses or other malicious code.

2 1

bjam help...
by John Torjo 15 Sep '04

15 Sep '04

How do I set bjam to print (eventually to a file) all the commands it executes? I'm trying to configure gcc, and I don't know what I do wrong:( Best, John -- John Torjo -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4.0 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

4 4

RE: [boost] Formal review of "Output Formatters" library begins today
by Reece Dunn 14 Sep '04

14 Sep '04

Paul A Bristow wrote: >| [mailto:boost-bounces@lists.boost.org] On Behalf Of Reece Dunn >| > "Boost prefers clarity to curtness". >| >| I have been giving this some thought. What I am looking at at >| the moment is >| something like: >| >| std::pair >| < >| std::pair< int, std::vector< char > >, >| std::list< boost::math::quaternion< float > > >| > mct; > >Which leaves me puzzling what on earth mct can be short for ! >myVeryContrivedContainerType? > >Is this a complex demo assemblage? Yes. It was to give an example of the new (planned) naming scheme to output mct [my_complex_type]. >| namespace io = boost::io; >| namespace fmt = boost::io::format; > >using boost::io::format; > >would allow you to replace fmt with format? Which is much easier to >understand, >especially for those for whom english is not their first language? I would prefer to use a namespace alias where possible as I dislike unnecessarily polluting the global namespace. As to namespace format = boost::io::format; vs namespace fmt = boost::io::format; you can see that these are aliases for "boost::io::format", just like namespace fs = boost::filesystem; As long as it is put at the top of the code examples/tests and put in the documentation introdution at the beginning, clearly stating that "fmt" is a namespace alias for "boost::io::format" I don't see it being a problem. The problem with the current implementation naming scheme is that it uses Xfmt consistently and most importantly, *the user has no control over this*. Feel free in your code to use: namespace format = boost::io::format; or equivalent. Is there a concensus for/against the use of the shorter fmt::basic(), etc. in the docs and code? Dave? John? >Have I commented this correctly (and informatively)? Yes. Although I am not sure of the behaviour of using on a namespace name (don't you need a using namespace or a namespace alias?) >| std::cout << io::object( mct, >| fmt::pair >| ( >| fmt::pair( fmt::basic(), fmt::container()), // basic used for >int, container is a vector. >| fmt::container( fmt::nary()) // container is list, and n in the >nary is 4 for a quaternion. >| ) >| ); > > >| With io::delimiter holding one of the delimiter values. >| io::wrapped_delimiter will replace io::openclose_formatter in holding >open/close delimiter pairs > >why wrappED? io::wrapper? ({} [] ... The io::wrapped_delimiter above is a holder for open and closing pairs, so io::wrapper_delimiter doesn't seem syntactically correct. Maybe io::wrapp*ing*_delimiters? >| and io::sequence_delimiter replaces io::formatter. > >io::separator? , | ... Maybe io::sequence_delimiters. This is because it contains open/close *and* separator delimiters, since it is controlling how a sequence type is rendered. >(Of course, if English spelling made any sense whatever, it would be >separater - but it hasn't got to be the premier language by being phonetic, >consistent and logical, has it?) Causing me a great deal of confusion (even being a native English speaker!) >Paul > >PS >/rubbing_it_in_mode on > >some filenames have the spelling mistake too ;-) >This may confuse some using search later. Doh! >/rubbing_it_in_mode off >and finally > > std::cout << boost::io::formatob( vec ).format( "{ ", " }" ); ><<<<<<<<<<< >isn't this missing a ':' separator??? > // output: { 1 : 2 : 3 } Thorsten spotted this as well. I have updated the docs to: // output: { 1, 2, 3 } Thanks, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

bgl question: in which namespace to put the functions
by Andreas Fabri 14 Sep '04

14 Sep '04

Hello, Developping code so that BGL algorithms can run on the vertices and edges of CGAL triangulations, I am wondering if there are rules or recommendations for in which namespace the functions source, target, vertices, out_edges ... shall go. In boost, because it is boostish code, or in CGAL, because that is the namespace where the triangulation lives in? thank's in advance, andreas

2 1

any interest in Boost Unification and Backtracking library (UBL)?
by G. Wang 14 Sep '04

14 Sep '04

Hi, all, Unification and backtracking are the two key concepts of Prolog language. Prolog language is one of the preferred ways to develop "intelligent" software. I am wondering how many people here are interested in a Boost Unification and Backtracking Library (UBL). UBL will implement the unification and backtracking feature with the help of both preprocessor meta-programming (Boost Preprocessor library) and template meta-programming (MPL). With UBL, you will define Prolog-like predicates right inside your C++ code. ========== Why do we need it? =========================== 1. a C++ and Prolog combined solution may not be convenient. You need to write a lot of wrapper code to allow bi-directional communications between Prolog code and C++ code. Standard Prolog is not an Object Oriented Programming Language. As such, you need to write even more code to allow Prolog to access C++ class instances. Worse yet, each prolog implementation has its own way to interface with foreign languages. So your wrapper code most likely would not be portable to other Prolog implementations. 2. Unlike C++, Prolog is not strong-typed. Folks in the C++ land too long may not like anything that is not strong-typed. 3. C++ is a multi-paradigm language. At beginning, it was procedure oriented. Then it's object oriented. During the past few years, functional oriented programming in C++ and even aspect oriented programming in C++ become hot topics and real possibility. Now why don't we give C++ a logic programming flavor? 4. UBL allows the programmer to switch back and forth among the multi-paradigm seamlessly, therefore make it easier to combine the right features of each paradigm to solve a given problem. Better yet, you do not need to lean a new language (Prolog). =========== Is UBL feasible?=================== The short answer is yes. I already have the prototype up and running in VC++ 7.1. The 8-queen problem takes less than 28 seconds on my Athlon 2200+ to find all answers. The prototype does have its fair share of shortcomings: 1. template based metaprogramming in general, and the prototype of UBL in particular, takes too long to compile any non-trivial code. Or may not be able to compile at all. 2. syntax wise UBL predicates are not as straight-forward or visually appealing as the equivalent predicates in Prolog. Here is a predicate in UBL: BOOST_UBL_PREDICATE_2_( is_grandfather_of, Person, Person ) { BOOST_UBL_VARIABLES_3 ( Person, X , Person, Y , Person, Z ); typedef clause< LHS<X, Y> , is_father_of< X, Z > , is_father_of< Z, Y > > type; }; Here is the equivalent predicates in Prolog: is_grandfather_of(X, Y) :- is_father_of(X, Z), is_father_of( Z, Y). 3. In my plan, the Lambda library will provide the "fast-lane" between UBL and your C++ instances, member functions and member variables. Of course, that is not done yet.

5 6

Intel compiler
by Andreas Fabri 14 Sep '04

14 Sep '04

Do I have to do something particular for the Intel 8 compiler for Windows. I get error messages like: boost/type_traits/is_integral.hpp(38): error: class "boost::is_integral<unsigned short>" has already been defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) ^ thanks in advance, andreas

2 1

Re: broken links and web site feedback...
by Aleksey Gurtovoy 14 Sep '04

14 Sep '04

William McDonald writes: > While trying to send the following message to boost(a)yahoogroups.com, > it bounced back. It's been a while since we switched to Mailman -- http://lists.boost.org/mailman/listinfo.cgi/boost. Does it still say 'boost(a)yahoogroups.com' somewhere on the website (besides http://www.boost.org/more/faq.htm -- just fixed this one)? > I'm not sure who handles broken links (i.e. who your web master is), > but this link only redirects if it doesn't have the 'index.htm' after > it. It is off the main library page > (http://www.boost.org/libs/smart_ptr/index.htm) Hmm, a search of "smart_ptr/index.htm" through all the docs/HTML pages didn't turn up anything. Are you sure the link came from the Boost website? > Broken link: http://www.boost.org/libs/smart_ptr/index.htm This one indeed doesn't work (should be "index.html"), but then it doesn't seem to be present anywhere on the website. > I recommend putting the web master's feedback link on the bottom of > every page. We don't have a single webmaster, but some address that doesn't require one to join a mailing list in order to report a typo or broken link indeed would be nice. Folks, do we have one already? > TIA, Thanks for your comments! -- Aleksey Gurtovoy MetaCommunications Engineering

2 1

RE: [boost] Formal review of "Output Formatters" library begins today
by Reece Dunn 14 Sep '04

14 Sep '04

Paul A Bristow wrote: >* There is a terribly central spelling mistake which nobody seems to noted >so far: > > A _delimiter_ does de-limit things and has nothing to do with deli_s or >meter_s! > A global search in replace in code and docs is vital. <blush> >* I strongly dislike abbreviations and concatenations. It is MUCH easier to >read/understand and consistent with STL styling to use full words and _s, >if >a bit longer to type. naryfmt really must qualify for some prize. >nary_format or n_ary_format. > "Boost prefers clarity to curtness". I have been giving this some thought. What I am looking at at the moment is something like: std::pair < std::pair< int, std::vector< char > >, std::list< boost::math::quaternion< float > > > mct; namespace io = boost::io; namespace fmt = boost::io::format; std::cout << io::object( mct, fmt::pair ( fmt::pair( fmt::basic(), fmt::container()), fmt::container( fmt::nary()) ) ); With io::delimiter holding one of the delimiter values. io::wrapped_delimiter will replace io::openclose_formatter in holding open/close delimiter pairs and io::sequence_delimiter replaces io::formatter. >| 3. What is your evaluation of the documentation? OK - > > Though I am not a fan of background coloured boxes for code - I think >the >font change is enough. > > One thing I would REALLY REALLY like is a Boost 'Standard' way of >colouring and indenting code similar to Visual Studio IDE - though I don't >feel their colour scheme is quite as good mine! What do you think about the new Boost.quickdoc? The docs for quickbook are available at http://tinyurl.com/64el7, and the source is at http://tinyurl.com/4tdjj. Thanks to Eric and Joel for this great tool. >| 8. Do you think the library should be accepted as a Boost library? Yes >- >but with some name changes. See above. >And I would like to see active work by all authors to ensure that this >interacts with the filtering, range, more_io libraries before the first >actual full release (in 1.33?) so that the documentation cross-references >too, including examples of combinations of these techniques. I am willing to co-operate. >I can understand that authors are unwilling/unable to work together until >they are sure which other libraries can be assumed a part of Boost, and I >think we must accept (and flag up) that there will probably be changes, >perhaps major, while interworking is perfected. The three recent IO >contributions, with serialisation, are prime candidates for mutual >refinement. Sure. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

4 6

RE: [boost] 2. It is unavoidable to use threads
by Ben Hutchings 14 Sep '04

14 Sep '04

Carlo Wood <carlo(a)alinoe.com> wrote: <snip> > No, I am confused. You do as if it trivial. But where is the answer > to my question? How can I implement an interface that allows one to > wait for events on 100 sockets, a timer, a few named pipes, a fifo > and some large diskfile I/O at the same time? > Is your answer WaitForMultipleObjects ? Then 1) what about the limit > of 64? That limit may well be a problem. (As may the limit on the size of an FD_SET on POSIX systems with nothing better than select().) > And 2) How can I use that to wait for events on SOCKET's? The only > thing I can find for that is WSAWaitForMultipleEvents. > But obviously you can call WSAWaitForMultipleEvents *and* ^ not, presumably > WaitForMultipleObjects at the same time (without using threads). The WSAEVENT type alias and associated functions appear to have been defined as an attempt to allow for implementation on other operating systems; in reality a WSAEVENT is a HANDLE to a Win32 event and you can use it with WaitForMultipleObjects (this is documented in the Platform SDK).

1 0

Legacy for compose?
by Daryle Walker 14 Sep '04

14 Sep '04

Looking at the main index.html file in CVS, it looks like the old Compose library will be going away. However at least one book, _The C++ Standard Library: A Tutorial and Reference_ by Nicolai M. Josuttis in 1999, assumes that Compose will still be there (and improved over what's in the book). Shouldn't our library list page permanently keep a note over what happened to the Compose library (and what should replace it)? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

4 8

Fw: Housemarque Oy Copyright in the Boost.Preprocessor Library
by John Maddock 14 Sep '04

14 Sep '04

Another needed license permission: ----- Original Message ----- From: "Ilari Kuittinen" <ilari.kuittinen(a)housemarque.fi> To: <john(a)johnmaddock.co.uk> Cc: <vesa_karvonen(a)hotmail.com> Sent: Monday, September 13, 2004 9:14 AM Subject: FW: Housemarque Oy Copyright in the Boost.Preprocessor Library > Dear John, > I am CEO of Housemarque and I am contacting you regarding your inquiry a > while ago concerning Boost licensing. We accept the new license terms as > described below. > > Boost Software License - Version 1.0 - August 17th, 2003 > > Permission is hereby granted, free of charge, to any person or > organization > obtaining a copy of the software and accompanying documentation covered by > this license (the "Software") to use, reproduce, display, distribute, > execute, and transmit the Software, and to prepare derivative works of the > Software, and to permit third-parties to whom the Software is furnished to > do so, all subject to the following: > > The copyright notices in the Software and this entire statement, including > the above license grant, this restriction and the following disclaimer, > must be included in all copies of the Software, in whole or in part, and > all derivative works of the Software, unless such copies or derivative > works are solely in the form of machine-executable object code generated > by > a source language processor. > > THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT > SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE > FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR > OTHERWISE, > ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > OTHER > DEALINGS IN THE SOFTWARE. > > Vesa, would you please add "Housemarque Oy" to > more/blanket_permission.txt? > > > Kind regards, > Ilari Kuittinen > CEO, Housemarque > Mobile:+358 40 554 2586 > Ilari.Kuittinen(a)housemarque.fi > > COMPANY INFORMATION > > Company name: Housemarque Oy > > Business ID: Y1002012-8 > > Country of incorporation: Finland > > Company form: Limited liability company > > Headquarters at Helsinki, Finland. > > Address and contact information: > > Kaisaniemenkatu 1 D > > FIN-00100 HELSINKI > > FINLAND, EUROPE > > Tel:+358-9-637 586 > > Fax:+358-9-637 890 > http://www.housemarque.com > > > > > > >>From: "John Maddock" <john(a)johnmaddock.co.uk> >>To: <vesa_karvonen(a)hotmail.com> >>CC: "boost owner" <boost-owner(a)lists.boost.org> >>Subject: Housemarque Oy Copyright in the Boost.Preprocessor Library >>Date: Fri, 13 Aug 2004 12:44:22 +0100 >> >>Visa, >> >>As you will know already, in order to simplify Boost licensing, we >>are in the process of moving to a single common license >>(http://www.boost.org/LICENSE_1_0.txt) The aim of the new license is to >>provide a single wording, that encapsulates the our previous license >>requirements, and which will simplify the evaluation of Boost for >>commercial >>organisations. >> >>So here's the big question: may we have permission to change code that has >>copyright "Housemarque Oy" to use the new license? The copyright >>declaration would >>obviously remain, it's only the license text that would change. >> >>If "yes", and you have Boost-cvs write access, please add "Housemarque Oy" >>to >>more/blanket_permission.txt. >> >>If "no", please give us some idea what objections you may have. >> >>Many thanks, >> >>John Maddock. >>[Boost Moderator] >> > > _________________________________________________________________ > Add photos to your e-mail with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com) > Version: 6.0.737 / Virus Database: 491 - Release Date: 2004.08.11 > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com) > Version: 6.0.759 / Virus Database: 508 - Release Date: 2004.09.09 > >

2 2

serializing a hash_map (tweaks for gcc-3.3.4/libstdc++-v3)
by troy d.straszheim 14 Sep '04

14 Sep '04

Had a couple problems serializing a hash map on gcc-3.3.4/gnu libstdc++-v3. Sorry if this is a repeat, I've googled around a bit and found nothing. Here are the tweaks necessary: 1. BOOST_HAS_HASH is not defined for this stdlib, needs to be turned on. 2. The <hash_map> header itself is not accessible as <hash_map>, it's <ext/hash_map>, and 3. The BOOST_STD_EXTENSION_NAMESPACE in this case is "__gnu_cxx". I have a patched stdlibcpp3.hpp and serialization/hash_map.hpp if somebody wants 'em... Cheers, -t

4 6

Re: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 14 Sep '04

14 Sep '04

John Torjo wrote: >>PS: >> I noticed that in earlier versions strings within STL containers >> where surrounded by "quotes"; now, they are no longer, which causes >> problems if a string contains ",". Why was that changed? >> >at my suggestion ;) > >I think you'd use this library a lot for pretty printing. Thus, the above >would only hurt. You can still specify it manually (if you wish to read the >strings back) The problem with the system I developed was that it overrided the "natural" behaviour of the basic format object (read/write the object to/from the stream using >> and << respectively). As John points out, this can result in output that looks like: [ "Tina", "Dana", "Eric", "Shaun" ] when you would want: [ Tina, Dana, Eric, Shaun ] I am aware of the problems reading the data back in if the string contains spaces. Placing quotes around it requires that you escape the quotes (to allow quotes in the string, e.g. \") and to escape the character that signals an escaped character (e.g. \\). This can lead to "ugly" output, e.g.: "This is a message \\ to say \"Hallo Welt!\" to my German friends." when you'd want: This is a message \ to say "Hallo Welt!" to my German friends. Now, consider the case when you want to generate XML or HTML-based output. In that case, you would want something like: <message>This is a message \ to say "Hallo Welt!" to my German friends.</message> and do not need to explicitly escape the string. In this case you can do: namespace io = boost::io; std::cout << io::formatob( str, io::containerfmt()).format( "<message>", "</message>", "" ); I am looking to add support for format objects that transform elements, i.e.: OutStream & write( OutStream & os, const Elem & e ) { return( os << fn( e )); // fn = transformation function } bool read( InStream & in, Elem & e ) { return( inv_fn( in, e )); // inv_fn = inverse transformation function } That way you can define character escapers for strings, XML, HTML and other escaped formats. To format the string as: "This is a message \\ to say \"Hallo Welt!\" to my German friends." you can do: std::cout << io::formatob( str, io::containerfmt( io::string_escaper()) ).format( "\"", "\"", "" ); This makes the process more well formed, consistent within the framework and explicit. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

RE: [boost] any interest in Boost Unification andBacktracking library(UBL)?
by Klaus Nowikow 14 Sep '04

14 Sep '04

Kresimir Fresl wrote: > Klaus Nowikow wrote: > > [...] > > My company uses a Prolog engine from a C++ program > > to solve a problem that is very hard to solve in C++ (I > can't explain > > this in detail here). > > Anyways, the inclusion of this Prolog engine caused various problems > > - the biggest being hard-to-reproduce program crashes when > we did not use > > the library _very_ carefully. > > > > So, if there was a C++ library that we could use for these tasks, we > > would surely consider it. > > Did you try LC++ library? > > http://www.cc.gatech.edu/~yannis/lc++/ > Not yet. Thanks for the link :-) -- Klaus

1 0

RE: [boost] any interest in Boost Unification and Backtracking library(UBL)?
by Klaus Nowikow 14 Sep '04

14 Sep '04

G. Wang wrote: > I am wondering how many people here are interested in a Boost > Unification > and Backtracking Library (UBL). UBL will implement the unification and > backtracking feature with the help of both preprocessor > meta-programming > (Boost Preprocessor library) and template meta-programming > (MPL). With UBL, > you will define Prolog-like predicates right inside your C++ code. I am very interested. My company uses a Prolog engine from a C++ program to solve a problem that is very hard to solve in C++ (I can't explain this in detail here). Anyways, the inclusion of this Prolog engine caused various problems - the biggest being hard-to-reproduce program crashes when we did not use the library _very_ carefully. So, if there was a C++ library that we could use for these tasks, we would surely consider it. Best regards, Klaus

2 1

Re: [boost] [1.32 Release] Branch-for-release date
by Robert Ramey 14 Sep '04

14 Sep '04

>With the new MPL in the main trunk and the updated MPL documentation coming >later this week, we've finally come to the point when it's feasible to talk >about the branch-for-release date. >Given that there is still some work on regressions to be done, I'd like to >aim for the end of the week, let's say Friday, September 17th. Does that >sound OK to everybody? Sounds too optimistic to me. >I'm assuming that at this point all library authors/maintainers are >finished with the tasks they wanted to perform before the release, minor >regression fixes aside. If not, please scream loudly! That's a reasonable assumption. But ... >One thing that we really have to take care of before branching is long >filenames. Could maintainers of the following libraries please fix the >corresponding problems listed in detail in http://www.boost.org/regression->logs/inspection_report.html? > archive (serialization) > build > date_time > graph > iterator > preprocessor > property_map > python > serialization > spirit > test > utility/enable_if The problem here is that some boost libraries depend on other boost libraries. E.g. serialization depends on spirit, lots of stuff depend on iterator, everything depends on test. So changing names will have lots of secondary effects. I'm still struggling with the fact that spirit 1.61 depends upon apply_if.hpp which no longer exists. In effect this makes the serialization library unavailable to vc 6.0, borland and others. That's just one case. BTW. These changes will break user code that depends on previous boost versions. So that's another question. Another issue is that the toolsets have some pending anomalies. Aside from the fact that the toolset documentation is now out of sync with the actual toolsets available and in use, I'm having problems with all those which use stlport which used to work. I'm still tracking this down. This is just the stuff I know about. I would say 17 Sep is hopelessly optimistic. Robert Ramey

3 2

Re: [boost] Re: Formal review of "OutputFormatters"library beginstoday
by Reece Dunn 14 Sep '04

14 Sep '04

John Torjo wrote: >>>I think one type of delimeter is enough (I assume you wholeheartidly >>>disagree with this). >> >>I don't wholeheartedly disagree... I am open to persuasion ;) >> >>>This type should be the std::basic_string<underlying_char_type>(). >> >>This would still mean that you have one per underlying_char_type, so the >>same problem exists although it is now in a smaller problem domain. My > >Nope, in this case, the problem does not exist. >It's because you have this correspondence: >1 stream - 1 underslying character type - 1 object that can keep delimeters >As oposed to: >1 stream - N delimeter_types - N objects keeping these delimeters. <light-bulb = on>! ;) >>main reason against using std::basic_string as the storage type is >>performance (excessive copying of the delimeter values). Also, what about >>managed strings in C++/CLI? Don't they require a String^ type, or am I >>missing something? > >whoa. I have no idea. But I do think that std::string should work ;) Or am >I dreaming ;) ? C++/CLI implements it's String objects as wchar_t * strings. In VC7.x you do String * str = S"Hello"; to create a string. VC8 allows the following: String ^ str = "Hello"; String ^ str2 = L"World"; You would need to convert to an ASCII string if outputting on std::cout. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

RE: [boost] Secret handles and descriptors: Enemies of reuse, conspirators with frameworks.
by Hurd, Matthew 14 Sep '04

14 Sep '04

> Behalf Of Scott Woods > > >From: "Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> > > <snip> > > > Discounting polling, as its generally unacceptable, you always will need > > access to that underlying system resource handle, unless . . . <snip> Please don't discount polling. Trading CPU for latency benefits latency critical applications. A quick $0.02, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Secret handles and descriptors: Enemies of reuse,
by Simon Meiklejohn 14 Sep '04

14 Sep '04

>From my perspective developing interactive telephony applications this problem is an example of a more general one. Heres the outline of a solution that I've been using In general a program may need to integrate a variety of libraries which are sources of information/events. Often it's the nature of these libraries that they either own a thread which calls back into application code, or require the user to call a potentially blocking function that returns the data/event. Then again there are the libraries which explicity make available o/s objects that can be waited on. Its frequently the case that no single 'raw' demultiplexor system can interface to all of these at once. (I guess that's the reason for this thread). To me the underlying issue is one of threading. Heres a list of typical issues that arise in my apps. - my networking library wants to call me back in its own thread - ditto for my multi-media timer - my telephony library wants to signal me by setting an event - so I'd better dedicate a thread to it. That thread will also call me back. - my application objects are having events fired at them from all sides from multiple threads and therefore need to use Mutex's, but events from below (telephony) keep on deadlocking with events from above (network). - my COM interface wants to issue connection point callbacks to me in a the app main thread via the app message pump. - I cant call out on my COM interface on my Network library's callback thread because its not marshaled for that kind of stuff. - So I put the network messages in a queue - now I have to send a windows message to the main thread, where its ok to call COM. This isn't necessary on my unix version, so I have ugly platform specific code in the middle of my app. - My smart network library parses my messages into complex data types before I get to see them. So getting them out of the queue in the main thread involves some kind of dispatch on type. This is expensive and hard to maintain. STEPPING BACK A BIT While it may seem that many of my problems stem from COM, I think it stems from an unfortunate need to implement the application's threading policy at all levels of the code - library and application code. Also, the hoops I have to jump through to get COM working wont be at all applicable if I shift to unix or move to a non-COM interface. What I really need is the ability to define a threading policy at some high level point in my code (e.g. main), have library code that defers to that policy. I've called this a Thread Redirector policy Looking at the Network lib to COM path as an example: - the network lib receives bytes from the network in its own thread. When it has a complete message (but before it starts decoding the message) it calls the Thread Redirector asking for a callback in the appropriate thread. - in main() we've set things up so that when Networking asks for a callback it will be called back in the main thread via a windows message. (On Unix I substitute a pthreads based callback.) - On windows the callback occurs in the main thread. The Network library starts decoding the message. It determines it's a message type XXX and calls back into the App code MyAppObj.DeliverMessageXXX( MsgXXXType& XXX ). - the app can now call into its COM API like - myCOMIF->DoSomething( XXX.param) - without first queueing the message. I can define it so that all my libs deliver their events to the application objects on the same thread. This relieves the thread deadlock issues. I can go into more detail if required - but that's the flavour of it. Simon Meiklejohn

2 1

IOStreams formal review start
by Jeff Garland 14 Sep '04

14 Sep '04

All - Today (August 28th, 2004) is the start of the formal review of the Iostreams library by Jonathan Turkanis. I will be serving as review manager. Note that this is a somewhat unusual situation in that we have several libraries that overlap in the same area, so comments related to the MoreIo overlap are needed. As usual, please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments ********************************************** Library Synopsis ********************************************** The Iostreams Library serves two main purposes: * To allow the easy creation of standard C++ stream and stream buffer classes for new data sources and sinks. * To provide a convenient interface for defining i/o filters and attaching them to standard streams and stream buffers. The library focuses on freeing users from writing boiler plate code and allowing them instead to create highly reusable components. In addition to providing an abstract framework the library provides a number of concrete filters, sources and sinks which serve as example applications of the library but are also useful in their own right. These include components for accessing memory-mapped files, for file access via operating system file descriptors, for code conversion, for text filtering with regular expressions, for line-ending conversion and for compression and decompression in the zlib, gzip and bzip2 formats. The latest package can be found at the following locations: http://home.comcast.net/~jturkanis/iostreams/ Thanks, Jeff

14 88

meta-comm page not found
by troy d.straszheim 13 Sep '04

13 Sep '04

I was hunting around for something to do. If I click on any of the failed tests for gcc-3.4.1 on this page: http://tinyurl.com/3uxpm, you get a "page not found" error, on, for instance, the following page: http://www.meta-comm.com/engineering/boost-regression/developer/output/ bin-boost-libs-test-test-token_iterator_test-test-gcc-3-4-1-linux- debug.html ? -t

2 1

[ANN] asio - yet another networking library!
by Christopher Kohlhoff 13 Sep '04

13 Sep '04

Hi all, In light of some of the recent discussion about sockets (e.g. the "behond IOStreams" thread), I'd like to take this opportunity to announce "asio". asio will be going live in a commercial system in a little over a month, and I think it's now at a point where it is suitable for use by a wider audience. I would like to think that asio has potential as the basis of a boostified networking library, or that at least it can inject some ideas into the discussion. asio is a cross-platform library for doing network programming, using a "modern" c++ style. It is designed to use an asynchronous I/O model for virtually all operations, even when the OS lacks native asynchronous I/O. The library is intended to ease the development of scalable network applications through the use of a proactive event-driven architecture. You can download asio from: http://tenermerx.com/programming/cpp/asio/asio-0.1.12.tar.gz I have also put the generated documentation online at: http://tenermerx.com/programming/cpp/asio/asio-0.1.12/doc/html/ asio supports Win32 and Linux, and has been infrequently tested on Solaris. It is free for any use. Here is a sample usage of asio showing how to receive data on a socket: char buf[BUFSIZ]; void handle_receive(asio::error& e, size_t bytes_recvd) { if (!e) { /*...*/ } } int start_receiving(asio::socket& s) { s.async_recv(buf, BUFSIZ, boost::bind( handle_receive, asio::arg::error, asio::arg::bytes_recvd)); } I have been working on asio for well over a year and, as I said, it will be going into production in a commercial system in a little over a month. For commercial reasons I can't give too much detail, but I can say that asio has been used to develop a custom HTTP proxy that supports hundreds of concurrent connections. The inspiration for asio was the work of Alex Libman in developing a "portable Proactor framework" for ACE (see http://www.terabit.com.au) This is a Proactor that can use select or a similar synchronous event demultiplexer if no more appropriate OS mechanism is available. Regards, Chris

5 10

Secret handles and descriptors: Enemies of reuse, conspirators with frameworks.
by Aaron W. LaFramboise 13 Sep '04

13 Sep '04

Boost now contains several classes that provide abstraction for operating system resources that are logically _waitable_. A waitable resource is any resource for which an operation on it might not complete immediately. Examples include threads and processes, files and the file system, and sockets and pipes. A notification of some activity on a waitable resource is often called an _event_. In modern software, it is often necessary to wait for events asynchronously. Quite often threading is a good solution for this, but quite often it isn't. In these latter cases, it is necessary to have some sort of _demultiplexor_ entity that handles the system-specific mechanics of waiting for events. In both UNIX and Windows, to wait for events relating to a resource, one must have a handle or a descriptor associated with that resource. In general, this must be provided by the class that maintains the abstraction itself. If a class managing a waitable resource, through encapsulation, allows no way for a demultiplexor to access the handle needed for waiting, waiting is impossible. Despite having all the functionality that a programmer may require, this class is useless to the programmer because it can not be demultiplexed. This is unacceptable. To solve this design deficiency, a particular Boost demultiplexor class might be created. Boost classes that are associated with waitable resources might provide the needed handles to the demultiplexor—perhaps using _friend_—and so make asynchronous waiting possible. Unfortunately, there is a problem with this approach. Resources managed by classes outside of Boost would, in general, be incompatible with the demultiplexor. In addition, demultiplexors other than the one provided by Boost—that might be able to handle these classes incompatible with the Boost demultiplexor—would likely be unusable. The nature of typical demultiplexor implementations is that they monopolize control flow (for reasons that are usually unavoidable), and may only cooperate within the same program by using separate processes or threads, which may be inappropriate if there is no other logical reason for such separation. The affect is that waitable resources provided by libraries other than Boost are useless to the Boost programmer, as they are fundamentally incompatible. This is the mark of a conniving, conspiratorial framework, which lures its victims in with attractive features, and then locks them in its dungeon by preventing them from using other libraries. This is also unacceptable. It is the unfortunate truth that until the C++ world decides on universal resource concepts there will always need to be some piece of code that knows the interfaces of both the waitable resource and the demultiplexor. However, there is no need for this dependent code to be part of either the demultiplexor or the resource. This code might be an adapter for the Boost thread class that allows it to be compatible with a particular third party demultiplexor class. In consideration of the these issues, one may conclude that there must be a mechanism in Boost classes to allow arbitrary code to access the encapsulated handle or descriptor that describes the underlying resource for purposes of implementing demultiplexing. While this may, at first, seem a potential violation of encapsulation, it might also be seen as proper application of the Open-Closed Principle. One simple mechanism for achieving this is presented: class unix_thread_handle { protected: pthread_t handle() { return hand; } private: pthread_t hand; }; class thread : public unix_thread_handle, public boost::noncopyable { // ... }; Demultiplexor adaptors are permitted to access the underlying handles by deriving from a system-specific type and copying from an existing resource. Such access is subject to the lifetime of the origin object and documented constraints about the meaning of the handle. A demultiplexor should also be designed to be compatible. The demultiplexor must provide some mechanism to allow code outside of Boost to obtain control flow when particular system events occur. In addition, interoperability should be maintained not only with foreign waitable resource classes, but with other demultiplexors, to the maximum extent possible. For example, on a system where an event is delivered through a chain of handlers (such as Windows hooks or UNIX sigaction), the demultiplexor must be careful to pass on the event when appropriate. In light of recent interest and development relating waiting and demultiplexing, it is especially important that the above points are considered. Writing a naïve demultiplexor that will forever plague future programmers who use third party libraries is a temptation that should be strenuously ignored. There are already plenty of frameworks that have implemented this unfortunate xenophobia. If Boost is able to offer an interface that makes its waitable resources and future demultiplexor openly compatible with the rest of the world, it will continue to be popular long after other libraries have outlived their usefulness. Any thoughtful consideration and comments would be greatly appreciated. If there is some interest in these things for Boost, I’d like to prepare some proof-of-concept alterations for waitable parts of Boost. I also have designed a cross-platform demultiplexor class, but unfortunately it is not in a state that is immediately ready to be shared with Boost. However, if there was interest, I would consider polishing it up. Aaron W. LaFramboise

5 14

RE: [boost] Formal review of "Output Formatters" library begins today
by Reece Dunn 13 Sep '04

13 Sep '04

Paul A Bristow wrote: >| [mailto:boost-bounces@lists.boost.org] On Behalf Of Reece Dunn >| > One thing I would REALLY REALLY like is a Boost 'Standard' way of >| >colouring and indenting code similar to Visual Studio IDE - >| though I don't >| >feel their colour scheme is quite as good mine! >| >| What do you think about the new Boost.quickdoc? The docs for >| quickbook are >| available at http://tinyurl.com/64el7, and the source is at >| http://tinyurl.com/4tdjj. Thanks to Eric and Joel for this great tool. > >I don't like the greyed background to anything. I don't think it helps at >all. >It makes things take longer to print out if you need a paper copy - when >the >going gets really tough. >Nor do the boxes around really help much either, but they at least don't >hinder. > >The coloring isn't strong enough for my taste - using blue for keywords is >a >great help in reading, IIUC, this can all be controlled via the CSS, e.g.: .keyword{ color: red; font-weight: bold; } >My view is that color is a massive hit in helping people to read code, >especially if it can be applied uniformly, something that Boost could >'impose'. This is true and would be where QuickDoc --> BoostBook --> HTML+CSS pays off. I am not sure about how the styling is controlled in XSL:FO+PDF, though. QuickDoc for syntax highlighting the C/C++ code; BoostBook for a consistent documentation format and CSS for consistent styling. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

[1.32 Release] Branch-for-release date
by Aleksey Gurtovoy 13 Sep '04

13 Sep '04

Hi All, With the new MPL in the main trunk and the updated MPL documentation coming later this week, we've finally come to the point when it's feasible to talk about the branch-for-release date. Given that there is still some work on regressions to be done, I'd like to aim for the end of the week, let's say Friday, September 17th. Does that sound OK to everybody? I'm assuming that at this point all library authors/maintainers are finished with the tasks they wanted to perform before the release, minor regression fixes aside. If not, please scream loudly! -- Aleksey Gurtovoy MetaCommunications Engineering

7 8

RE: [boost] Re: Compression usinig IOStreams library
by Ben Hutchings 13 Sep '04

13 Sep '04

George M. Garner Jr. <gmgarner(a)erols.com> wrote: [Jonathan Turkanis wrote:] > > Dumb question - is Winzip supposed to be able to read the zlib > > format? I usually use it to decompress .zip or tar.gz archives. > > Well I made that assumption because Winzip and XP both maintain > associations for the .z extension. This is from the Winzip help > file: <snip> The ".Z" extension is conventionally used for files compressed with the Unix "compress" program, which uses LZW. zlib and gzip were created to provide a patent-free alternative to it. They use the same compression algorithm as PKZip and WinZip but do not use the PKZip file format. I doubt that WinZip has any support for raw compressed files.

2 1

[1.32 Release] Fixing long filenames
by Aleksey Gurtovoy 13 Sep '04

13 Sep '04

One thing that we really have to take care of before branching is long filenames. Could maintainers of the following libraries please fix the corresponding problems listed in detail in http://www.boost.org/regression-logs/inspection_report.html? archive (serialization) build date_time graph iterator preprocessor property_map python serialization spirit test utility/enable_if Thanks! -- Aleksey Gurtovoy MetaCommunications Engineering

7 8

Re: [boost] Re: Formal review of "OutputFormatters"library beginstoday
by Reece Dunn 13 Sep '04

13 Sep '04

John Torjo wrote: >>That is basically what I do already: >>wrappedfmt() is associated with openclose_formatter; >>pairfmt() is associated with formatter (using default_nary_traits) >>containerfmt() is associated with formatter (using >>default_sequence_traits) >>etc. > >Yes, and that is great! >But you hold them in the formatob object. I have this relationship: formatob isa FormatObject isa formatter usesa DefaultTraits FormatObject hasa FormatObject >What I'm saying is that (overridable) defaults for each of the above can >also be kept in the stream object itself. I understand what you are saying, I am just looking at how to implement it. >>so you can theoretically use any string type to store the default >>delimeter values. How do we do the equivalent with ios_base::pword/iword? > >That's your job - to come up with a technique for this ;) :) >Basically, the library's underlying concept doesn't have to change. This is >just an extra goodie you can provide. Sure. >>openclose_formatter/formatter set their delimeter values to the values >>provided by the default traits object passed to them. You can then >>override these defaults by calling format(). How do you tell that the >>default has been overrided? > >It's certainly possible. Internally, in the delim object, you can keep the >data like this: > >template<class value_type> struct val_keeper { > value_type val; > bool has_been_set; > //getter and setter - I assume you get the point >}; This might be easier if instead of formatter holding DelimeterType objects for each delimeter, have it store an io::delimeter< CharT > object and have that responsible for access, thus: template< typename CharT > class delimeter { private: const CharT * value; bool is_set; public: const CharT * get() const{ return( is_set ? value : ios_base::pword -> value()); } void set( const CharT * v ){ value = v; is_set = true; } delimeter(): value( "" ), is_set( false ){} }; and template< typename CharT > class formatter { public: delimeter< CharT > separator; // separator is now a property! }; >>The main questions are: >>[1] how do you store different DelimeterTypes in this mechanism? > >Which brings us to ;) : >I think one type of delimeter is enough (I assume you wholeheartidly >disagree with this). I don't wholeheartedly disagree... I am open to persuasion ;) >This type should be the std::basic_string<underlying_char_type>(). This would still mean that you have one per underlying_char_type, so the same problem exists although it is now in a smaller problem domain. My main reason against using std::basic_string as the storage type is performance (excessive copying of the delimeter values). Also, what about managed strings in C++/CLI? Don't they require a String^ type, or am I missing something? Regards, Reece _________________________________________________________________ Get ready for school! Find articles, homework help and more in the Back to School Guide! http://special.msn.com/network/04backtoschool.armx

2 1

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 13 Sep '04

13 Sep '04

Jeff Flinn wrote: >"John Torjo" <john.lists(a)torjo.com> wrote in message >news:414443E0.60008@torjo.com... > > Dear boosters, > > > > The FORMAL Review of "Output Formatter" library begins today, > > Sept 12, 2004. > > > > 1. What is your evaluation of the design? > >I find the naming conventions misleading. 'outfmt' but it does io? What is >an '...ob' and '...obex'? This effort at reducing verbosity is then >countered as mentioned by Dave Abrahams, by the "syntactic noise". I am going to provide more consistent names once the review period is over. I made a start at this before review, but wanted to get a more general view of peoples thoughts before sticking to any particular names. The name outfmt is legacy. Initially it only provided output, but people were interested in input as well. Xob is an "X object" and Xobex is the variant of Xob that takes < DelimeterType >, e.g. Xobex< wchar_t * >. (I don't have a better name for this and am open to suggestions). >I do like the delimiter traits objects approach to dealing with >leader/trailer existence issues. Although I have not found passing "" >(empty >string) as the leader/trailer being a performance bottleneck since they are >only performed once per range. What about for the separator delimeter? For example: std::cout << io::formatob( vec ).format( "" ); >I like the range approach, but isn't a range library coming? Boost.Range has recently been adopted into boost. It should be fairly trivial to replace io::range with the Boost equivalent. >Will io::range be entirely compatible? My home grown range_streamer is >often used with >filter and transform iterators. It would be nice to use a shorter syntax >like: > os << range_stream( aC, lFilterFnc, "\n=\n{ ", "\n, ", "\n}" ); >rather than > [snip] You mean supporting your range_streamer from within my framework? Or supporting ranged types in general (range types are supported within the framework)? > > 2. What is your evaluation of the implementation? > >The main motivation I had for developing a similar output facility was >dealing with the dangling separator when using std::copy and >ostream_iterator in a consistent/performant fashion. Your rearrangement is quite neat! It removes the duplicated test. > > 3. What is your evaluation of the documentation? > >After reading Jonathon's IOStream documentation, my expectations have been >raised. Some of the problems are due to the misleading names used in the >implementation itself. Almost everything is a format_this or format_that >with format methods... Perhaps an additional namespace level would >alleviate >some of this. As I have mentioned above, I am going to revise the naming once the review is over, based on the comments provided here. >Missing are Motivation and Rationale sections. When/Why would someone use >this library versus ostream_iterator/Tokenizer/Spirit/... ostream_iterator does not, AFAIK, handle nested constructs like std::vector< std::list< int > >. Tokenizer is primarliy concerned with reading data back in and I'm not sure if/how it supports containers, arrays and pair/nary types. Spirit is too complex for when you want simple formatting and is only concerned with parsing (reading) data. It also adds a lot of overhead and does not fit in with the C++ I/O stream framework. Boost.Serialize does a great job, but is not very flexible in the way that the data is serialized. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

4 4

boost/tools/build/jam_src/strings.c typo
by Caleb Epstein 13 Sep '04

13 Sep '04

Looks like version 1.6 of boost/tools/build/jam_src/strings.c introduced a typo. #include is spelled #Include (capital I) on line 5. -- Caleb Epstein caleb.epstein(a)gmail.com

1 0

C++ GUI - another view
by Andy Little 13 Sep '04

13 Sep '04

Hi, Recent discussions on boost have talked about GUI's in quite technical terms, windowing etc. Another part of the abstraction is simply that of providing an area for drawing on. The code below is a simple example of what I mean. The "drawFunction" is meant to be like a graphics version of a main() function .( Note that there should ideally be no DeviceHandle visible to the "drawFunction". The DeviceHandle should be wrapped in the GX object, passed to the function so some of the impl is poking through here in form of the gx.line_to etc functions 'hdc' argument. Its early days.) The display output from the function is available at: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/source/capacitor… Behind the function there is of course a windows app, (built using WTL in this case), though the function could could be invoked on any widget, any operating system ,screen or printer or any device,,, even (say) an oscilloscope with suitable exposure of the x, y type traits of the GX object :-) Note that the use of the unit'ed lengths eg length:::mm provides the key to the success of the abstraction. If (say) doubles were used, one would need to provide (Somehow) the information as to what those values represent. here it is encoded in the type. (And a note to Java programmers... The same scheme is entirely possible in Java too ). The other useful device is the "morph" object, which is used to morph time and voltage into lengths in this example. However it can be used on any two types that can be divided by one another. There arent many primitives yet, only lines which makes the function a bit wordy as it stands, but the intention is to make lines, rects etc available which can be used to build more complex objects which can be sent to an output "graphics stream". ... and then the "three_d" namespace ;-) regards Andy Little /////////////// #if (defined _MSC_VER) && (_MSC_VER >= 1200) # pragma once #endif /* draw the voltage/time discharge curve for a capacitor */ #ifndef PQS_TWO_D_VIEW_ABSTRACTION_HPP_INCLUDED #define PQS_TWO_D_VIEW_ABSTRACTION_HPP_INCLUDED #include "pqs/ct_quantity/operations/morph.hpp" #include "pqs/pqs.hpp" namespace pqs { namespace two_d{ template <typename GX, typename DeviceHandle> inline void drawFunction(GX & gx, DeviceHandle hdc) { // vect<X,Y> is a general purpose (x,y) container // for coords sizes etc typedef vect<length::mm> pt; // set up size of drawing area in world coordinate sizes // This can be scaled and scrolled by the other layers // for output on a device // world coordinates as used here // are the top layer of the graphics view gx.max_position() = pt(length::mm(180),length::mm(170)); gx.min_position() = pt(length::mm(0), length::mm(0)); // set up border length::mm const border(20); // set up a drawing rectangle for the graph // of voltage / time pt draw_rect; draw_rect.x() = gx.max_position().x() - 2 * border; draw_rect.y() = gx.max_position().y() / 2 - border; // move origin to (0,0) on graph gx.set_origin(border,border); // draw a border round the graph gx.move_to(hdc,length::mm(0),length::mm(0)); gx.line_to(hdc,draw_rect.x(),length::mm(0)); gx.line_to(hdc,draw_rect.x(), draw_rect.y()); gx.line_to(hdc,length::mm(0), draw_rect.y()); gx.line_to(hdc,length::mm(0),length::mm(0)); gx.text_out(hdc,length::mm(20), draw_rect.y() - length::mm(10), "Capacitor Time Curve" ); // capacitor time curve data capacitance::uF const C(0.47); //capacitor voltage::V const V0(5); //starting voltage across capacitor resistance::kR const R(4.7); // resistance between terminals time_<int>::ms const max_time(20); // The "morph" functors convert the source physical-quantities to target types // (here lengths for drawing obviously) // with correctly dimensioned scaling value // as ctor argument morph<length::mm,time::ms> time_x( draw_rect.x() / max_time); morph<length::mm,voltage::V> volts_y( draw_rect.y() / V0); // draw the graph for ( time_<int>::ms t ; t <= max_time; ++t ){ voltage::V Vt = V0 * std::exp(-t / (R * C)); if (t == time_<int>::ms(0)){ gx.move_to(hdc, time_x(t),volts_y(Vt) ); // "morph" useage } else{ gx.line_to(hdc, time_x(t),volts_y(Vt) ); } } } }}//pqs::two_d #endif

1 0

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 13 Sep '04

13 Sep '04

David Abrahams wrote: >John Torjo <john.lists(a)torjo.com> writes: > > > When doing the formal review, please answer the following questions: > > > > 1. What is your evaluation of the design? > >It seems to introduce a great deal syntactic noise: > > std::cout << boost::io::formatob( vec ); > // output: [ 1, 2, 3 ] > > std::cout << boost::io::formatob( vec ).format( "{ ", " }" ); > // output: { 1 : 2 : 3 } > > >I'd like to (at least) see rationale on why something cleaner wasn't >chosen. For example: > > namespace io = boost::io; > std::cout << io::sequence( vec ); > // output: [ 1, 2, 3 ] > > std::cout << io::sequence( vec, "{ ", " }" ); > // output: { 1 : 2 : 3 } There are two basic components: a delimeter holder (formatter/openclose_formatter) that contain the delimeters and control over them, and a format object that tells the library what type the object being formatted is. Your suggestion for placing the delimeter specifications in the type construction messes things up since you are combining two separate concepts. This would lead to many different function overloads (you'd need one for each variant). Also, the design would fail when adding new delimeters for things like trees and graphs. >In case it's not obvious, I don't like the name "formatob." Abbrevs >should generally be avoided, and frankly I don't know what 'ob' >stands for. Also "format" doesn't seem to add much semantically. "ob" stands for "object". I am willing to negotiate appropriate names. io::sequence seems reasonable enough. >I'm generally not a great fan of statefulness, but this also seems >like a reasonable thing to want: > > namespace io = boost::io; > std::cout << io::sequence_delimiters("{ ", " }"); > std::cout << io::sequence( vec ); > // output: { 1, 2, 3 } You can achieve something like this using: io::formatter< const char * > fmt( "{ ", " }" ); std::cout << io::sequence( vec ).format( fmt ); If there are any better alternatives, I am willing to listen. >Library organization seems problematic. On one hand, I'd like to see >the io for individual boost types like octonion distributed across >their respective libraries (e.g. in boost/math/io.hpp). On the other >hand that will introduce an "apparent library dependency" that may not >be needed by some. The "apparent dependency" of this library on all >the others isn't very comforting, either. Perhaps some refactoring is >appropriate. I think this will be an issue no matter how it is implemented. Especially for the STL container types. The code has already been refactored so that each STL/Boost type registers its self in a separate file, so you can include them individually. It might be a good idea to have the Boost/complex types include just the type deduction mechanism code. This would reduce the file/library dependencies. >Another point: I'd like to see functionality for pretty-printing >sequences. It's very common to have sequences that are too long to >represent comfortably on one line. There are several strategies for >dealing with that, and it seems to me that to be *really* >indispensible, this library should help in that department. I don't know if additional support needs to be built into the framework, but you can implement your own format object that could perform pretty-printing functionality, e.g.: std::cout << io::sequence( vec, io::pretty_container()); It should also be possible to design character escapers/unescapers, allowing: std::cout << io::sequence( str, io::container_fmt( xml::char_escaper().format( "", "" )); >It might >also need ways to prevent infinite recursion in self-referential >sequences (consider sequences that embed ranges). Hmm. I am not sure how to implement this. Suggestions are welcome. >Where's I/O for tuples? I have not added tuple support yet. > > 3. What is your evaluation of the documentation? > >What little I saw of the tutorial documentation looked readable and >comprehensible. The lack of namespace aliases in the examples don't >help the library's case. I'd like to see more rationales. okay. >AFAICT the docs lack any sort of formalized reference guide, showing >interface summaries, what headers to include, requirements, etc. IMO >it's unacceptable without that component. Did I miss something? okay. IIUC, Doxygen will auto-generate these when provided javadoc-like comments. >The use of "implementation defined" in the documentation is >incorrect. To be correct, the Boost implementation would have to >define whatever it is. The appropriate term is "unspecified." okay. >I/O for existing Boost types such as rational<>: > > IMO the fact that we didn't have I/O for these is sort of > embarassing, but at the same time it's unclear to me that not > having inserters/extractors was a burden for anyone. I can't > recall a single post asking where these things were. I/O does exist for rational, octonion, interval and so forth. The headers in my library for boost components are there to tell my library what type of sequence a particular type is (e.g. rational<> is a pair type, octonion an n-ary type and std::list a container). This is so that my library knows how to format that type. > > And most important, > > 8. Do you think the library should be accepted as a Boost library? > > Be sure to say this explicitly so that your other comments don't > > obscure your overall opinion. > >The lack of reference docs is a showstopper for me. okay. I'll look at getting doxygen up and running on my machine. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

4 7

Re: [boost] Re: Formal review of "Output Formatters"library beginstoday
by Reece Dunn 13 Sep '04

13 Sep '04

John Torjo wrote: >>>Well, I think my alternative is better if you want a stateful change, >>>since yours doesn't accomplish that. My suggestion is certainly >>>consistent with normal io manipulators. The point is to stream a >>>bunch of sequences without having to repeat the format part. >> >>I understand what you are saying and yes your version is neater. However, >>implementing something like this would have performance penalties (because >>you will need to create/store the preset values at run-time). > >The penalties are small. Anyway, using std::istream/ostream have penalties, >compared to using raw FILEs ;) This is true. >That said, in this case there shouldn't be many penalties. >Again, you can use >ios_base::pword and ios_base::iword for this. >It's an advanced technique, but I think it can prove very neat and >flexible. okay. >>It will also change the way all sequence constructs are rendered. (n-ary >>types have a different rendreing so won't be affected). As I understand, >>this is the desired effect. But then: > >You can make it possible to associate a fmt object with a delimeter object. > >Example: pairfmt() with openclose_formatter. >basicfmt() with formatter. Etc. That is basically what I do already: wrappedfmt() is associated with openclose_formatter; pairfmt() is associated with formatter (using default_nary_traits) containerfmt() is associated with formatter (using default_sequence_traits) etc. At the moment, default_nary_traits/default_sequence_traits provide the default strings to map to the specific type, e.g.: const char * default_nary_traits< const char * >::open_default(){ return( "( " ); } wchar_t default_nary_traits< wchar_t >::open_default(){ return( L"(" ); } std::string default_nary_traits< std::string >::open_default(){ return( std::string( "(" )); } so you can theoretically use any string type to store the default delimeter values. How do we do the equivalent with ios_base::pword/iword? openclose_formatter/formatter set their delimeter values to the values provided by the default traits object passed to them. You can then override these defaults by calling format(). How do you tell that the default has been overrided? One solution would be to use a null string as a default value. Then you can do class openclose_formatter { private: inline DelimeterType get_default_open() const { return ios_base::pword -> open(); // pseudocode } public: inline DelimeterType open() const { return( _open == null ? get_default_open() : _open ); } }; but this would complicate the access process for open(), close() and separator(), that in the current implementation simply return the data member. Also, what about string types such as std::string, QtString, CBStr and CString? What are their appropriate "null" values and how do you test that? I suppose you could have a resolve_default_values() function in the formatter class that is called when using FormatObject::read/write to reduce the resolution to a single pass, but what about when you save a formatter/format object, e.g.: io::formatter< const char * > fmt( " : " ); // oen/close use defaults std::cout << io::formatob( lst, io::containerfmt()).format( fmt ) // [1] << io::set_sequence_defaults( "< ", " >" ) // [2] << io::formatob( vec, io::containerfmt()).format( fmt ); // [3] [1] will resolve the default values used by fmt, [2] will change the defaults used and [3] will not be updated to reflect these changes, so you'd need the slower version. Alternatively, you can do this in FormatObject::read/write: DelimeterType separator_delim = separator(); while( first != last ) { // ... os << separator_delim; } >Then, you can store (default) delimeter objects within the stream. >Once you want to output/input something, it requires a specific delim >object. You'll somehow use ios_base::pword/iword to get a reference to that >object. The main questions are: [1] how do you store different DelimeterTypes in this mechanism? [2] how do you tell if the default is needed (see above)? Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

Re: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 13 Sep '04

13 Sep '04

John Torjo wrote: >>2. The first part of documentation should >> be what is purpose of the library. >> >> I guess in this case it is debugging >> and testing support, 100% cases. > >Introduction: >"The Standard Template Library (STL) provides a mechanism for storing >collections of objects, but does not provide I/O support via streams. [...] > The outfmt library is an attempt to solve the problems outlined above, >providing an extensible framework [...]" > >So, what I gather is that it provides customizable I/O for >containers/ranges. Yes. >That said, I donot think its purpose is debugging/testing support 100% >cases. It does definitely support that, but you can do more - like, do some >pretty printing to file(s), std::cout, etc. Yes. >>5. To support debugging I would like to see >> many more features: >> >> - ability to wrap long lines in pretty way > >I guess this could be solved by IO streams lib ;) :) The problem with doing this during the output phase with my library is that you don't know in advance if outputting the next element will wrap around to the next line (and thus will need a new line inserting). Jonathan's library does indeed provide a solution for this. The example he gives does not support smart word-wrap facilities, but this can be done by writing to an internal buffer and outputting that up to the last space in the buffer, retaining the rest of the buffer until it wraps. >> - ability to generate HTML as output >> (+ ability to fold/unfold big data >> structures using Javascript). > >I assume this could be added in time... Reece? You can generate this now if what you are generating is regular, for example: <ol><li>a</li><li>b</li><li>c</li></ol> if you want an id or special position-based output, you can create a state object and use statefmt() like is done in libs/example/john-torjo.cpp to output: [0] John, [1] Jane, [2] Claire, [3] Mark for example: <ol><li id = "elem1">a</li><li id = "elem2">b</li><li id = "elem3">c</li></ol> Alternatively, you can output the data as XML and use XSL:T to generate the javascript/dynamic content. For example: std::list< std::pair< int, std::vector< char > > > data; std::cout << xml_signature << '\n' << xsl_stylesheet_signature << '\n' << '\n' << io::formatob( data, io::containerfmt ( io::pairfmt ( io::wrappedfmt().format( "<e>", "</e>" ) io::containerfmt().format( "<seq><e>", "</e></seq>", "</e><e>" ) ).format( "<pair>", "</pair>" ) ).format( "<seq>", "</seq>" ) ); output: <seq><pair><e>5</e><seq><e>a</e><e>b</e><e>c</e></seq></pair><pair><e>102</e><seq><e>x</e><e>y</e><e>z</e></seq></pair></seq> If you want it to be pretty, e.g.: <seq> <pair><e>5</e> <seq><e>a</e><e>b</e><e>c</e></seq> </pair> <pair><e>102</e> <seq><e>x</e><e>y</e><e>z</e></seq> </pair> </seq> You can specify this as: io::formatob( data, io::containerfmt ( io::pairfmt ( io::wrappedfmt().format( "<e>", "</e>" ) io::containerfmt().format( "\n <seq><e>", "</e></seq>", "</e><e>" ) ).format( "\n <pair>", "\n </pair>" ) ).format( "<seq>", "</seq>" ) ); Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 13 Sep '04

13 Sep '04

David Abrahams wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> writes: > > >>I'm generally not a great fan of statefulness, but this also seems > >>like a reasonable thing to want: > >> > >> namespace io = boost::io; > >> std::cout << io::sequence_delimiters("{ ", " }"); > >> std::cout << io::sequence( vec ); > >> // output: { 1, 2, 3 } > > > > You can achieve something like this using: > > > > io::formatter< const char * > fmt( "{ ", " }" ); > > std::cout << io::sequence( vec ).format( fmt ); > > > > If there are any better alternatives, I am willing to listen. > >Well, I think my alternative is better if you want a stateful change, >since yours doesn't accomplish that. My suggestion is certainly >consistent with normal io manipulators. The point is to stream a >bunch of sequences without having to repeat the format part. I understand what you are saying and yes your version is neater. However, implementing something like this would have performance penalties (because you will need to create/store the preset values at run-time). It will also change the way all sequence constructs are rendered. (n-ary types have a different rendreing so won't be affected). As I understand, this is the desired effect. But then: [1] how do you select sequence or n-ary formatting? [2] what about extending this to incorporate - for example - tree or string formatting? [3] how do you extend this to formatter types that have additional delimeters? [4] how do you know when to extract the default delimeter values from the stream? Adding a formatter as a parameter to io::sequence, etc. would further complicate function lookup. Perhapse if I had an is_format_object< T >::value trait I could use MPL wizardry to distinguish between format object and delimeter formatter, allowing: io::formatter< const char * > fmt( "{ ", " }" ); std::cout << io::sequence( vec, fmt ); // output: { a, b, c } The problem with this is: what if you want to specify a format object and a delimeter formatter? This might work, but the implementation becomes more complex. Another idea would be to overload an operator like: std::cout << io::sequence( vec )( fmt ); // output: { a, b, c } or std::cout << io::sequence( vec )[ fmt ]; // output: { a, b, c } but this would further add to the confusion. If operator() was adopted, it would be possible to have that as a shorthand for format(). For example: std::cout << io::sequence( vec )( " | " ); // output: [ 1 | 2 | 3 ] Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Access to compiler options for all tests
by Stefan Slapeta 13 Sep '04

13 Sep '04

Would it be possible to provide the compiler options also for the regression tests that passed? They sometimes are interesting, too! Stefan

2 1

warning about metacomm darwin results
by JOAQUIN LOPEZ MU?Z 13 Sep '04

13 Sep '04

The metacomm darwin results use a toolset named gcc-3.1-darwin. Yet, its corresponding config_info test (http://tinyurl.com/5afdp) reveals that the version of GCC used is 3.3, and not 3.1; this could be misleading. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[ANN] xpressive 0.9
by Eric Niebler 13 Sep '04

13 Sep '04

It's been nearly a year since I first announced my intention to build a new regular expression engine. It has finally reached a point where I am comfortable recommending it for general use. << xpressive 0.9 >> http://boost-sandbox.sourceforge.net/libs/xpressive - What is it? It is a regular expression engine which allows you to author regexes as expression templates (like Spirit) *or* as strings (like Boost.Regex). When written as an expression template, the regex is syntax-checked at compile-time and statically bound for maximal inlining and optimization. (See http://tinyurl.com/6k9p8 for more detail.) Also, regular expressions can nest and call each other recursively, which gives you the power of a context free grammar. That makes it appropriate for simple parsing tasks. (See http://tinyurl.com/4enn4 for more detail.) - What's the interface like? xpressive is a Boost.Regex work-alike. It follows the regex standardization proposal closely, but not too close! You can read about all the differences in xpressive's documentation. The domain-specific embeded language for xpressive is heavily influenced by Spirit. - Where can I read more? xpressive's documentation is online at: http://boost-sandbox.sourceforge.net/libs/xpressive - Where can I download the code? You can get the xpressive zip archive at: http://boost-sandbox.sourceforge.net/xpressive.zip It contains the source code and the documentation in PDF format. Alternatively, you can get xpressive directly from the boost-sandbox. Source code is at /boost-sandbox/boost/xpressive, and the regression test and documentation are at /boost-sandbox/libs/xpressive. Note: this is version 0.9. Check out the "Not Yet Implemented" section in the documentation to see why. I'll be working towards v1.0 in the coming weeks and months, but I am confident at this point that the interface is not likely to change. What's there is stable and solid and ready for (ab)use. Original announcement of xpressive: http://lists.boost.org/MailArchives/boost/msg55623.php Cheers, -- Eric Niebler Boost Consulting www.boost-consulting.com

8 27

[move_ptr] implementation and docs available
by Jonathan Turkanis 13 Sep '04

13 Sep '04

Hi All, A long time ago, I announced that I was working on an implementation of a move pointer: On Wednesday, January 21, 2004 6:30 PM, "Jonathan Turkanis" <technews(a)kangaroologic.com> wrote: > ... My goal is to have the > implementation done tonight. That means it will be done next week. :-) Well, I actually did write the implementation, but never documented it, and finally forgot about it. Recently, Thorsten Ottosen requested a move_ptr implementation, so I cleaned up my implementation from Janurary and wrote some tests and documentation. Here it is: http://home.comcast.net/~jturkanis/move_ptr/ It's based on Daniel Wallin's adaptation of an idea of Rani Sharoni, mixed in with some ideas of Howard Hinnant and Bronek Kozicki. Best Regards, Jonathan

2 6

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 13 Sep '04

13 Sep '04

David Abrahams wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> writes: > > >>AFAICT the docs lack any sort of formalized reference guide, showing > >>interface summaries, what headers to include, requirements, etc. IMO > >>it's unacceptable without that component. Did I miss something? > > > > okay. IIUC, Doxygen will auto-generate these when provided > > javadoc-like comments. > >You won't get Concept documentation from Doxygen unless you take care >to actually write it ;-), and regardless I don't think this can be >done as an afterthought. I would be wary of taking this route unless >your implementation is very simple. It's important to present a >coherent view of the *user interface* that doesn't expose >implementation details. For example, sometimes public inheritance >from some helper class is neccessary as an implementation technique, >and you don't want to expose it, but you need to expose the public >members of that helper. I don't think Doxygen can deal with that. I suppose it depends what you are doing. If you are just inputting/outputting an object, then you don't need to be concerned with how things like boost::io::pairfmt() are implemented. However, you will need to know the object that pairfmt() returns if you want to save that type for use later, e.g.: // note: using new names: // renders the format: ( < a, b, c > | 5 ) io::pair_fmt_t< const char *, io::container_fmt_t< const char * > > my_type_renderer = io::pair_fmt( io::container_fmt().format( "< ", " >" )).format( " | " ); std::pair< std::list< char >, int > data; std::cout << io::sequence( data, my_type_renderer ); // output: ( < a, b, c > | 5 ) NOTE: This is where typedecl/auto comes in useful, making the above example become: auto my_type_renderer = io::pair_fmt( io::container_fmt().format( "< ", " >" )).format( " | " ); std::cout << io::sequence( data, my_type_renderer ); // output: ( < a, b, c > | 5 ) Likewise, you will not need to know how boost::io::formatter_t differs from boost::io::formatter in most cases. However, this becomes important when implementing your own format object (for example, adding tuple rendering support). It's all about context. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

range addition - generic constructor
by Neal Becker 12 Sep '04

12 Sep '04

It is not unusual to need to construct a container from another where one or the other doesn't comply with sequence. When generic code needs to convert to a container of unknown type (e.g., the return container type of a function is a template parameter), a generic constructor is useful, and could be part of range. Here is the idea: #ifndef const_from_range_hpp #define const_from_range_hpp #include <boost/range.hpp> #include <algorithm> #include <boost/numeric/ublas/vector.hpp> namespace detail { template<typename cont_t, typename range> struct construct_from_range_impl { cont_t operator() (range const& r) { return cont_t (boost::begin (r), boost::end (r)); } }; template<typename T, typename range> struct construct_from_range_impl<boost::numeric::ublas::vector<T>, range> { typedef typename boost::numeric::ublas::vector<T> ret_t; ret_t operator() (range const& r) { ret_t v (boost::size (r)); std::copy (boost::begin (r), boost::end (r), v.begin()); return v; } }; } template<typename cont_t, typename range> cont_t construct_from_range (range const& r) { return detail::construct_from_range_impl<cont_t,range>() (r); } #endif Here is a test example: #include "const_from_range.hpp" #include <vector> #include <boost/numeric/ublas/vector.hpp> namespace ublas = boost::numeric::ublas; // simple example int main() { std::vector<int> v (10); ublas::vector<int> w = construct_from_range<ublas::vector<int> > (v); } // more realistic example template<typename cont_t> cont_t F () { std::vector<int> v (10); do_something(); return construct_from_range<cont_t> (v); }

2 6

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 12 Sep '04

12 Sep '04

Pavel Vozenilek wrote: >"John Torjo" wrote: > > > The FORMAL Review of "Output Formatter" library begins today, > > >I briefly looked on the library and wrote down few >notes. I am especially interested in point [4]. > >1. Name of the library would be better changed. > Hearing it for the first time I suspected > something like variant on std::endl. I agree, especially as it also works for input as well. >2. The first part of documentation should > be what is purpose of the library. okay. > I guess in this case it is debugging > and testing support, 100% cases. It can also be used for additional stuff (see Techniques section for examples). As a demonstration, if you implement localization within your program by providing a std::map< std::string, std::string > locale; where you do something like: std::cout << locale[ "usage" ]; you can use my library to read it in. I understand you can use the serialization library to do this, but you can control the formatting in my library, allowing: english.loc "welcome" = "My World" "" spanish.loc "wecome" = "Mi Tierra" "" german.loc "wecome" = "Meine Welt" "" I am not sure how feasible it is to do something like this in the serialization library. >4. There seems to be significant overlap > with Boost.Serialization (I suspect > outfm doesn't handle cyclic > structures). outfmt does not support cyclic structures. > It may or may not be possible > to implement outfm functionality > with special archive. > > Was this considered? Is it possible to control the formatting for the same type to produce different results? For example: std::pair< std::pair< int, char >, std::pair< int, char > > p; std::cout << io::formatob( p, io::pairfmt ( io::pairfmt().format( " | " ), io::pairfmt().format( "{ ", " }", " : " ) ) ).format( "<: ", " :>" ); // output: <: ( 5 | a ), { 5 : a } :> >5. To support debugging I would like to see > many more features: It is possible to create your own format object and delimeter formatter classes to extend the libraries functionality, so some of what you suggest can be done that way. I am thinking of extending the library to support function objects as delimeter types, thus expanding the possible uses of the library. I am also planning on supporting character escaping to better support string in/output as well as allowing HTML/XML character escapers. You can produce simple HTML/XML output using format(), for example: std::cout << io::formatob( vec, io::containerfmt ( io::wrappedfmt().format( "<li>", "</li>" ) ).format( "<ol>", "</ol>" ) ); // output: <ol><li>a</li><li>b</li><li>c</li></ol> Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

tiny review iostreams library
by Jan Christiaan van Winkel 12 Sep '04

12 Sep '04

Hello, I have been asked by Jonathan D. Turkanis to take a look at his iostreams library that is currently in review for inclusion in Boost. He asked me because I presented a paper at ACCU in 2003 about adding a filtering capability to iostreams aloing with a very convenient notation to sting filters together using the vertical bar (|) as is done in UNIX. I had very little time to do a decent review (busy working on the Netherlands Unix Users Group's conference about system administration and network engineering - see www.sane.nl it will be great!), but I think I have a good impression of the structure. 1) The library fills in some (for me) much needed gaps in the standard iostreams library. Especially being able to use a (pre-opened) filedescriptor is important to me (since attach() was not included in the standard). 2) The filtering idea I have great feelings about - I wouldn't have written an article about that kind of thing if I didn't like the idea ;-) I would like the vertical vbar (akin to UNIX'pipe notiation) were also available, but I heard that Jonathan has already worked on that. In general, I think his approach is far, far better, more evolved and complete that my own try, that was only meant as a proof of concept. What I would like: a good user-level manual. The documentation is filled with quite some standardeze (and rightly so - it should be exact!). But users may not see the full strength of the library if they are not introduced to the library using some user-oriented documentation. So, my conclusion: I hope the submission of the library to boost is succesfull - the library would be most helpfull. JC -- ___ __ ____________________________________________________________________ |/ \ Jan Christiaan van Winkel Tel: +31 24 3527252 jc(a)ATComputing.nl | AT Computing P.O. Box 1428 6501 BK Nijmegen The Netherlands __/ \__/ __________ http://www.ATComputing.nl/image/midfotos/jc.jpg _________

1 0

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 12 Sep '04

12 Sep '04

Thorsten Ottosen wrote: >Here are some general comments: >---------------------------------- > >0. I think the library should be put in the directory >"boost/output_format" >I hate cryptic names. Or "boost/ioformat" since it also has input capabilities :). There was talk when I was developing the library about moving it into the "boost/io" directory, but that seems to be getting a little crowded ;) >1. In this example > > std::cout << boost::io::formatob( vec ); > // output: [ 1, 2, 3 ] > std::cout << boost::io::formatob( vec ).format( "{ ", " }" ); > // output: { 1 : 2 : 3 } > >why does the change of braces change "," to ":" ? It doesn't! This was a typeo. (Fixed in my documents, will commit post-review). >2. In this example > > int a[] = { 5, 4, 3, 2, 1 }; > std::cout << boost::io::formatob( boost::io::range( a, a + 5 )); > std::cin >> boost::io::formatob( boost::io::range( a, a + 5 )); > // output: [ 5, 4, 3, 2, 1 ] > >it might be good to support a range version with the posibility to > >1. throw if there is too few elements >2. default initialize if there is too few elements You mean when reading in the input? The default behaviour is to set the input stream fail bit, so you can check that. >3. cryptic name: formatob.hpp && formatobex; should be format_object and >whatever the latter really means I was going for ease of typing :). maybe boost::io::format/boost::io::formatex. The latter allows you to control the delimeter type being used, so you can do: std::wout << boost::io::formatobex< const wchar_t * >( v ).format( " : " ); >4. given std::cout << boost::io::formatobex< std::string >( v ); > > maybe std::string should be a default argument? I was thinking here about performance. The default type is const char * which should be fairly flexible without providing compy penalties. >5. A lot of boost::io::range() can be replaced with one Taking a Single >Pass >Range You mean from your Boost.Range library? This is something that I am considering, but don't know enough of the library to do this yet. >6. STL IO: It is not obvious how insertion is done? With push_back or by >overwriting elements? The container is cleared and insert is used to insert the elements into the container. >7. why is it necessary with > boost::io::formatob( boost::io::range( a, a + 5 )); > could we not just say > boost::io::range( a, a + 5 ); Because the boost::io::range_t class (created by boost::io::range) does not provide input/output functionality. It is a holder for a range [first, second) so that boost::io::formatob can process it. This is if you either specify a std::pair (boost::io::formatob treats this as a 2-ary type and not a range holder) or a (first, last) pair of values (since boost::io::formatob accepts a single object). It could be possible to make boost::io::range return a boost::io::formatob_t type (and thus allow the above), but when I previously used seperate constructs, it interfered with the type/format deduction mechanism. >8. It should be possible to say > > vector<int> v = ...; > cout << v; > >without the format_ob() if I include stl.hpp, ie, overloads for all >standard >types. Yup. This will provide the default formatting ("[ a, b, c ]" in this case). If you need alternate formatting, you need to use boost::io::formatob. >9. I would prefer basicfmt_t to be basic_format_type or perhaps >basic_fmt_type >if the "fmt" shorthand is used consistently etc. That is, all the cryptic > concatenation should be removed. That would make things fairly long-winded. For example: std::pair < std::pair< int, std::vector< char > >, std::list< std::complex< float > > > mct; std::cout << boost::io::format_object( mct, boost::io::pair_format ( boost::io::pair_format ( boost::io::basic_format(), boost::io::container_format() ), boost::io::container_format( boost::io::nary_format()) ) ); compared to: std::cout << boost::io::formatob( mct, boost::io::pairfmt ( boost::io::pairfmt( boost::io::basicfmt(), boost::io::containerfmt()), boost::io::containerfmt( boost::io::naryfmt()) ) ); >And now my review comments. > >| When doing the formal review, please answer the following questions: >| >| 1. What is your evaluation of the design? > >seems ok. I'm a little irritated about too cryptic names, concatenation and >_t >types. Basically, the "_t" types indicate the implementation type of a given construct. For example, the boost::io::formatob function creates an instance of the boost::io::formatob_t class. With regards to names, I am intending on changing FormatTraits to DelimeterTraits and possibly a few others. I am not sure what you mean by concatenation. >| 2. What is your evaluation of the implementation? > >haven't looked. > >| 3. What is your evaluation of the documentation? > >good, although I miss return-types and template paramaters and some >synopsises >with better overview. >For example, what does boost::io::formatobex< DelimeterType >( const T & ob >); >return? Maybe it doesn't matter, but >then it should say <i>Implementation-defined</i>boost::io::formatobex< >DelimeterType >( const T & ob ); etc. Okay, I will bear that in mind. FYI, the above function returns: formatob_t< T, DelimeterType, typename deducer< T, DelimeterType >::type::outputter > ! My rationale for not supplying the return types was to not consume more space and not confuse readers. Marking them *implementation defined* would be a good idea. >| And most important, >| 8. Do you think the library should be accepted as a Boost library? >| Be sure to say this explicitly so that your other comments don't obscure >| your overall opinion. > >yes. I think all issues can be dealt with quite easy for a post-review. Great. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

Re: [boost] [Config] Re: serializing a hash_map (tweaks for gcc-3.3.4/libstdc++-v3)
by Robert Ramey 12 Sep '04

12 Sep '04

troy d.straszheim wrote: >>> I have a patched stdlibcpp3.hpp and serialization/hash_map.hpp if >>> somebody wants 'em... >> >> Yes, please post them as attachments, and put [Config] in your >> subject line. >Here they are. I figure there is a "best practice" I'm missing (that >#ifdef __GLIBCPP__ looks out of place to me in hash_map) if so clue me >in for future reference. Also that <ext/hash_map> might very well >apply for __GLIBCXX__ as well, dunno, I made the minimum change to fix >my platform... Shouldn't there be similar set of changes for hash_set as well? Robert Ramey

1 0

RE: [boost] Re: Re: Formal review of "Output Formatters"librarybeginstoday
by Reece Dunn 12 Sep '04

12 Sep '04

Thorsten Ottosen wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> wrote >| Thorsten Ottosen wrote: >|The default behaviour is to set the >| input stream fail bit, so you can check that. > >Ok, I guess that goes in hand with the bahavior of the standard library >(although I prefer throw by default). > >could syntax like > >std::cin >> io::throw_on_error() >> io::formatob( ... ) >std::cin >> io::default_init_rest() >> io::formatob( ... ) > >be supported too.? Possibly. I'd need to look into this. >| >3. cryptic name: formatob.hpp && formatobex; should be format_object and >| >whatever the latter really means >| >| I was going for ease of typing :). maybe >| boost::io::format/boost::io::formatex. The latter allows you to control >the >| delimeter type being used, so you can do: > >yeah, what does "ex" mean? "extended". A better name is probably needed and should be consistent throughout (i.e. for boost::io::wrappedfmtex, etc.) The problem is how to keep close to the original so that you know what it does and also tells you that this variant controls the delimeter type, since you can't reuse the original name due to overload resolution issues. >| I was thinking here about performance. The default type is const char * >| which should be fairly flexible without providing compy penalties. > >seems reasonable...just mention this stuff in the docs. It is (in a round-about way). I have fixed in my local docs to say: "This uses const char * as its delimeter storage type." >| >5. A lot of boost::io::range() can be replaced with one Taking a Single >| >Pass >| >Range >| >| You mean from your Boost.Range library? This is something that I am >| considering, but don't know enough of the library to do this yet. > >Ok, basically you can replace > >foo( std::pair<iterator,iterator> ); >foo( T (&array)[sz] ); >foo( const standard_container& ) >foo( builtin-strings ); > >with one function taking a Range > >foo( const Range& ); Great! I will replace boost::io::range and boost::io::range_t with this post-review. >| >6. STL IO: It is not obvious how insertion is done? With push_back or by >| >overwriting elements? >| >| The container is cleared and insert is used to insert the elements into >the >| container. > >ok, a small comment about it would be good. Done in local docs. >| >7. why is it necessary with >| > boost::io::formatob( boost::io::range( a, a + 5 )); >| > could we not just say >| > boost::io::range( a, a + 5 ); >| >| Because the boost::io::range_t class (created by boost::io::range) does >not >| provide input/output functionality. It is a holder for a range [first, >| second) so that boost::io::formatob can process it. This is if you either >| specify a std::pair (boost::io::formatob treats this as a 2-ary type and >not >| a range holder) or a (first, last) pair of values (since >boost::io::formatob >| accepts a single object). > >hm...it seems to me that boost.range has all you need: > >class iterator_range or class sub_range + >function make_iterator_range( a, a + 5 ); > >I could probably benefit you code to use this instead (unless I'm >overlooking >something). Nope. I'll update post-review. >| >9. I would prefer basicfmt_t to be basic_format_type or perhaps >| >basic_fmt_type >| >if the "fmt" shorthand is used consistently etc. That is, all the >cryptic >| > concatenation should be removed. >| >| That would make things fairly long-winded. For example: >| [snip] > >yeah, I know, but at least say pair_fmt instead of pairfmt etc. Yes. This is better. >| I am not sure what you mean by concatenation. > >the contraction of X_fmt to Xfmt. Okay. I'll look at revising the affected names. >| Okay, I will bear that in mind. FYI, the above function returns: >| formatob_t< T, DelimeterType, typename deducer< T, DelimeterType >| >::type::outputter > >| ! My rationale for not supplying the return types was to not consume more >| space and not confuse readers. Marking them *implementation defined* >would >| be a good idea. > >yeah, that would be sufficient. Great. 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

RE: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 12 Sep '04

12 Sep '04

troy d.straszheim wrote: >Anybody have a hint on how to build the docs for this (or be willing to >just build them and put them up somewhere)? HTML versions of the docs are provided here: >>As a convenience (only for the period of the review), you can also get it >>from >>http://www.torjo.com/code/outfmt.zip (153Kb) Open the file: libs/outfmt/docs/html/frame.html. Alternatively, to build from the sources, open up a command line at libs/outfmt/docs and run bjam using: bjam This should build the docs as long as you have BBv2 (not sure about BBv1) set up and BoostBook properly configured. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

mipspro tests?
by Joaquín Mª López Muñoz 12 Sep '04

12 Sep '04

Hello, MIPSpro tests haven't been updated since Aug 18, yet I see some recent fixes being done in the CVS for this compiler. Is there anywhere else where tests for this platform can be consulted? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 6

boost.cvs range.hpp broken?
by Neal Becker 12 Sep '04

12 Sep '04

Just ran cvs update. Something is wrong with range.hpp: g++34 -x c++ /usr/local/src/boost.cvs/boost/range.hpp -I /usr/local/src/boost.cvs -fsyntax-only In file included from /usr/local/src/boost.cvs/boost/range/begin.hpp:18, from /usr/local/src/boost.cvs/boost/range/functions.hpp:18, from /usr/local/src/boost.cvs/boost/range.hpp:18: /usr/local/src/boost.cvs/boost/range/config.hpp:24:21: missing binary operator before token "("

3 5

OOPSLA 2004 Boost workshop proposal
by PORKOLAB Zoltan 12 Sep '04

12 Sep '04

Dear Sir, Here is the abstract of our proposal for the OOPSLA2004 Boost Workshop. The proposal and the corresponding source is downloadable from http://gsd.web.elte.hu/Publications/GPCE_04/concept.pdf http://gsd.web.elte.hu/Publications/GPCE_04/concept.h Please forgive us the possible errors. Istvan Zolyomi scamel(a)elte.hu Zoltan Porkolab gsd(a)elte.hu ================================================================== Improving concept checking in Boost ABSTRACT To ensure the correctness of template based constructions in C++, constraints on template parameters are especially useful. Though C++ does not directly support checking requirements on template parameters, several solutions address this problem. Boost provides a comprehensive concept checking library that could be further advanced in many areas. In this paper we propose a different structure and an extended feature set to improve the Boost concept checking library into a general template introspection library. Our recommended solution takes the advantages of previous solutions, such as REQUIRE-like macros and static interfaces. On the lowest level, we suggest an orthogonal construction of elementary concepts instead of a predefined set of complex constraints. These basic concepts should return a boolean results instead of aborting compilation immediately, thus any metaprogramming tool could use the result of the check. Based on these building blocks, it is possible to express highly complex constraints using arbitrary logical expressions instead of the implicit conjunction used in all current concept checking libraries. Our solution is non-intrusive, relies only on standard C++ language features and implies no runtime overhead. Note that this is a shortened version of our paper 'Towards a general template introspection library' for GPCE'04 which can be downloaded from http://gsd.web.elte.hu/Publications/GPCE_04/introspection.pdf. In that article we also introduce a possible implementation detailed to the source-level. The sample source code can be downloaded from http://gsd.web.elte.hu/Publications/GPCE_04/concept.h. ==================================================================

3 2

IOStreams Review -- Last Day
by Jonathan Turkanis 12 Sep '04

12 Sep '04

Hi all, This is the last day of the iostream library review. There have been a lot of messages to read; I've tried to respond to all of them, but I may have missed some. If you feel you have raised an issue which I have not adequtely addressed, please try again. Also, if you have been considering posting a review, but have run out of time, please post whatever comments you have even if they are not as detailed as you may have liked. Best Regards, Jonathan

2 2

Re: IOStreams formal review start
by Robert Ramey 11 Sep '04

11 Sep '04

What is your evaluation of the documentation? I've been reading through the documentation and I have a couple of questions and observations. I'm not sure I understand all the details so feel free to correct me if I've miss understood something. 1) Generally the quality of the documentation is very good. 2) I have a problem with the name of the library - I find it very misleading. I would character the library by its main functionality a) simplify the creation of new stream buffers. b) permit stream buffers to be "chained" together to sequentially process input and output. So I think a better name would be "Stream Buffer Library" Additionally it includes some very "thin" classes to make streams with with the indicated buffers. As I understand it this this basically replaces the rdbuf member of the stream in the normal way. In my view the tutorials don't make a clear distinction between stream buffers and streams. For example, I would prefer that the first one be: Defining a Stream Buffer for a New Data Source. Which would create a new stream buffer and then use in a stream created the old fashion way. Basically I think the tutorial is easier to understand if one can add one concept at a time - especially when (in my view) they are orthogonal concepts. Same for the other tutorials. The stream constructor can be in separate section. This would also make it much easier to see where the overlap is with Daryl's library. Adaptors and Object Generators Hmmm - I'm not sure "Adaptors" should be in here. How about "Streambuffer Generator" as it seems just to be shorthand for the above. Filtering Input/Output At first I was going to complain about this, but upon forming my complaint it became clear how its supposed to be used. Again I was thrown by the mixing of streambuffer and stream. I would prefer to see this divided into two pieces - making a chain of streambuffers and a final layer to used the buffer in a standard stream. It would characterize the source/sink concepts as "helpers" to building streambufs but providing the end points of a chain of filters. But that leaves me with the question "What about a filter to a standard filebuf? What do we use for sink? I'm sure its in there, I just didn't see it where I expected to find it. I presume its hidden in the filtered_?stream .. which makes harder to see. Of course this is the way its was designed so I guess I'm complaining about this design decision. 3) Reference ========= Another very professional job. A few observations: a) I'm sort of intrigued with the sequence that things are explained. For example, it's hard to understand the concept of "chains" until the Filter Stream is described. These are relatively small points. b) I'm intrigued with the section "Code Converters". How does this contrast with using a codecvt facet? What are we doing here that is not better than adding a codecvt facet? Might be better make a method of composition ("chaining") codecvt facets? I don't know the answer. As I went through that part of the documentation this question occurred to me - it sort of begs and answer. 4) Rationale a) The section Generic Design left me stumped. The selection of conditional verb tenses suggests that neither alternative was used. b) Interesting to me was that fact that the issue of streambuf vs stream is dealt with explicitly. 5) What is your evaluation of the design? a) I've already stated my reservations about the mixing of streams and stream buffers. b) the concept of "chaining" is quite different than what I would have envisioned. As I understand it, if 10 filters are chained together, this system is going to require ten levels of function calls to get a character in/out. Someone is bound to object to this. On the other hand, this system permits filter to be composed "chained" at runtime which may be useful in some instances. I would have expected something like the filters be composed at construction time with templated constructors. This would permit the inlined member functions to be collapsed by the compiler to minimize copying. The Dataflow iterators in the serialization library manifest this expection. I'm not saying that the method chosen by Jonathon isn't as good ( though I might believe that) its just not what I expected. c) I'm a little concerned as to where codecvt, wide character i/o etc fit into this. d) I would be curious as to whether this is suitable for something other than filebuf - e.g. stream adaptor for sockets i/o. ? 6) What is your evaluation of the implementation? I didn't build the library or use in any tests so I recall can't contribute to that assessment. 7) What is your evaluation of the potential usefulness of the library? This is very useful and necessary. Something like this is what I've hoped for to complement the serialization library. I envision something like this combined with the serialization libray, combined with the mult-index set as making one great in memory database. Did you try to use the library? With what compiler? Did you have any problems? no How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A couple hours with the documentation Are you knowledgeable about the problem domain? Fairly knowledgable. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. I have reservations as stated above. It very useful and necessary, and seems (from the quality of the documentation) a high quality implementation. If my choices were t accept or reject it as is I would accept it. Of course, if others who've studied it in more depth confirm my reservations above, I would like to see them addressed first. Robert Ramey

4 16

Two issues with the IBM xlC compiler
by Matthias Troyer 11 Sep '04

11 Sep '04

Dear Boosters, I've got a patch to report for the IBM Viisual Age C++ compiler xlC, and one other problem to discuss. The patch we found necessary for version 6.0 of the compiler is: diff -u -r1.26 filtered_graph.hpp --- boost/graph/filtered_graph.hpp 22 Nov 2003 01:18:37 -0000 1.26 +++ boost/graph/filtered_graph.hpp 1 Jul 2004 14:11:27 -0000 @@ -208,8 +208,8 @@ > edge_iterator; typedef typename Traits::edges_size_type edges_size_type; - typedef typename edge_property_type<Graph>::type edge_property_type; - typedef typename vertex_property_type<Graph>::type vertex_property_type; + typedef typename ::boost::edge_property_type<Graph>::type edge_property_type; + typedef typename ::boost::vertex_property_type<Graph>::type vertex_property_type; typedef filtered_graph_tag graph_tag; //private: The original version just gives compiler errors, probably incorrectly but it does. The second problem is in the configure files. Who is responsible for maintaining them? The issue is the following patch I found necessary: --- boost/config/compiler/vacpp.hpp 22 Jun 2004 12:33:06 -0000 1.16 +++ boost/config/compiler/vacpp.hpp 1 Jul 2004 14:11:23 -0000 @@ -26,7 +26,7 @@ #endif #if (__IBMCPP__ <= 600) || !defined(BOOST_STRICT_CONFIG) -# define BOOST_NO_INCLASS_MEMBER_INITIALIZATION +//# define BOOST_NO_INCLASS_MEMBER_INITIALIZATION # define BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS #endif in-class member initializtions seem to work flawlessly on this compiler, so I wonder why BOOST_NO_INCLASS_MEMBER_INITIALIZATION is defined. Having it defined causes problems with the Boost random library, which then tries to initializes values of an enum tto a 64-bit integer, which fails. Is there a reason why BOOST_NO_INCLASS_MEMBER_INITIALIZATION is defined for this compiler or is this a bug? Best regards, Matthias

3 7

Re: Empty member optimization
by Joao Abecasis 11 Sep '04

11 Sep '04

David Abrahams wrote: > I think the question is whether it's ever desirable to break the > current C++ invariant that no two objects of the same type will ever > share an address **in generic code** -- that is, when you don't know > anything about the assumptions that may be made by that type. An alternative implementation is to privately inherit from the specified type for empty classes as compressed_pair does. This maintains the invariant but has the drawback that inheritance is visible in user code. For a generic compressed_tuple the private inheritance should not be a problem. João

3 5

[Config] proposal of new macro, BOOST_DECL
by Pavel Vozenilek 11 Sep '04

11 Sep '04

In order to export class from dynamic library one needs to add something as: __declspec(dllexport) wrapped in a macro. (Win32 example.) Right now libraries define their own macros, e.g Iostreams has BOOST_IO_DECL and Regex uses BOOST_REGEX_DECL. There could be more. I suggest common macro, BOOST_DECL to be used Boost-wide. Its value may be by default empty or deduced from BOOST_ALL_DYN_LINK as it is done in Regex. /Pavel

5 7

Regex
by Lucas Galfaso 11 Sep '04

11 Sep '04

What should be the behavior of a regex::smatch whenever the regex::expression you are trying to match is not a well formed regex expression? With the current implementation is crush and burn. I do not know what is boost policy on this matter, but I think this is not desirable. Lucas/

2 2

Re: Copyright (again, sorry...)
by Jürgen Hunold 11 Sep '04

11 Sep '04

Hi John ! On Friday 10 September 2004 12:08, John Maddock wrote: > Juergen, > > In case you missed this at the end of my last mail, there are still > some copyright issues to try and sort out; the copyright I'm seeing > in some of your work is: > > // Copyright (c) 2003 Institute of Transport, > // Railway Construction and Operation, > // University of Hanover, Germany > // > // Author: Jürgen Hunold > > In the files: > > libs/graph/test/property_iter.cpp This was changed to BSL in current cvs already > tools/build/v2/test/railsys/libx/include/libx/test_libx.h > tools/build/v2/test/railsys/libx/src/test_libx.cpp > tools/build/v2/test/railsys/program/include/test_a.h > tools/build/v2/test/railsys/program/liba/test_a.cpp > tools/build/v2/test/railsys/program/main/main.cpp > > I don't think having your name in blanket-permission.txt is enough > for us to move these over to the BSL is it? Well, I thought it was enough ;-) Especially because all files (should) have stated: // Permission to copy, use, modify, sell and distribute this software is // granted provided this copyright notice appears in all copies. This // software is provided "as is" without express or implied warranty, and // with no claim as to its suitability for any purpose. So I thought that changing to the equivalent BSL would not be such an issue, especially because all that matters is the fact that the copyright itself stays. But luckily I'm no lawyer. > So I guess what we really need is the permission of the "Institute of > Transport", would you be able to help us out with that? Yes I can. I'm in charge of the Boost issue here, and the author of all the files, so I can give you the permission: You may change these files to the Boost Software License. I hope this is sufficient. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de

2 1

serialization tests status
by Robert Ramey 10 Sep '04

10 Sep '04

NOB_AVEx - mingw >From the test output I have no idea why this fails. I also don't know which version of gcc is being used. General - mingw Tests which use wide char i/o fail because mingw standard library doesn't implement wchar_t i/o VC 8.0 Library fails to build because of an error compiling a spirit 1.8 header. This also fails in the spirit tests (chest) Comeau Wide char tests because of a bug in library implementation. Comeau has been notified and verified it's a bug. Borland, msvc 6.0, 7.0 These libraries fail to build. They depend on spirit 1.61. Spirit 1.61 in turn depends upon the existence of mpl/apply_if.hpp which has been removed. For backwards compatibility sake, there should be an apply_if even only if it's a wrapper around eval_if. intel- win32- 7.1- vc6- stlport- 4.5.3 pending library issue - under investigation gcc- 2.95.3- stlport- 4.5.3- linux I have verified that this works on Win 32 if spirit 1.61 is installed (subject to the above). Robert Ramey

1 0

[serialization] building fails on OS X...
by Ronald Garcia 10 Sep '04

10 Sep '04

Hi, I have tried a few times recently to build Boost from CVS under OS X on machine with 2 GB of memory. Unfortunately building fails at the following point: darwin-C++-action bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/xml_wgrammar.o virtual memory exhausted: Cannot allocate memory Has anyone else run into this problem? ron

2 1

Re: [boost] Re: [admin] Overlapping reviews -- should this be allowed?
by brangdon＠cix.compulink.co.uk 10 Sep '04

10 Sep '04

In-Reply-To: <chm2sp$bs9$1(a)sea.gmane.org> reportbase(a)yahoo.com (tom brinkman) wrote (abridged): > 2) The current backlog of libraries to review is quite large. How large? The schedule at: http://www.boost.org/more/formal_review_schedule.html is years out of date and I couldn't find an online schedule using google. > 7) The reason for not having overalpping reviews is based on the > preference for a flexible review schedule. This flexibility, > however, has a large cost in terms of not being able to provide > firm start dates for our library authors. That partly depends on whether the current necessary adjustment is a once-off or a regular thing. I suppose if a review looks like going over time, we have 4 choices: (1) Give up and reschedule the review for later - presumably 6 or more months later if it goes to the back of the queue, so as not to upset published schedules. (2) Force the review to end on time anyway, with a hurried judgement. (3) Extend the review period, and reschedule subsequent reviews. (4) Extend the review period, and don't reschedule subsequent reviews. This is the option which may lead to overlap. None of which are ideal, of course, but to me the latter two seem better then the first two. I'm inclined to think (4) should be considered on a case by case basis. It would depend mainly on whether the same people would be reviewing both of the overlapping libraries. Or rather, whether the people who aim to review both can get the first one done in time. Is it fair to say that the people who review all submissions do so relatively shallowly and quickly? And the people who review in depth, only do so for submissions they are specifically interested in and/or have expertise about and/or an immediate real-world application for? -- Dave Harris, Nottingham, UK

1 0

Re: [boost] Re: static sized strings
by Reece Dunn 10 Sep '04

10 Sep '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > [1] How do I pass the buffer and capacity to the implementation while > > allowing both fixed_string_base and fixed_string access to the >basic_string > > interface? I have chosen to route the data through one of the >basic_string > > constructors, requiring a const_cast. This is the best approach AFAICS. > >I haven't looked at your recent implementation, and I don't >presently have the time, so I really don't know what you're >talking about. If you can explain the dependencies to which you >refer, I'd appreciate it. I think it has bearing on the swap() >discussion. I have a class called detail::fixed_string_impl that has three data members: size, capacity and a pointer to the data buffer (len, cap and str respectively). Doing this allows the virtual functions to be removed and the implementation moved out of fixed_string. The fixed_string class can then pass its buffer and the capacity template parameter to the implementation via a constructor. The problem is that fixed_string is derived from fixed_string_base, which itself is derived from detail::basic_string_impl. This is needed to allow both fixed_string and fixed_string_base to have access to the full basic_string interface (like was done in the old implementation). The solution I have taken is to use the basic_string_impl( const CharT * s, size_type l ) constructor and use this to pass the buffer (s) and capacity (l) to the string. This is not ideal since it requires a const_cast to extract the buffer. This required modifying the constructor implementation in basic_string_impl to forward the parameters to Base and not implement them using append. The old implementation had the same problem with swap as the current one, since the string would get clipped when it is copied. For now, I will leave the implementation of swap as is (i.e. clipping and not signalling an exception), but add a note on this issue in the docs so that users are aware of it. Another problem I can forsee is using a custom char_traits or format_policy class, e.g. boost::fixed_string< 20, char, std::char_traits< char > > s1; strcpy( s1, "Hello" ); // ok boost::fixed_string< 20, char, win_char_traits< char > > s2; strcpy( s2, "There" ); // error This is the problem shared with basic_string when implementing functions using std::string. I have also fixed the problems relating to using the strxxx functions with Borland: the compiler may set them as instrinsic and add a macros defining strxxx as __strxxx__. To get around this, I now detect if they are macros and the Borland compiler is being used, then create an inlined function to the __strxxx__ version. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

filesystem exists/is_directory suggestion
by Martin 10 Sep '04

10 Sep '04

The filesystem status operations exists & is_directory will both throw if the status of the file can't be determined (access problems or race conditions). I think this makes the operations overly complicated to use since you need to enclose them in try catch blocks. You normally guard operations that use files in some way but it is easy to forget try/catch around exists / is_directory. (Noticed that exists has been updated in CVS to return true on error which is probably ok but I think is_directory need to be updated as well.) I think a good solution would be to have a non-throwing overload where the return value in case of error is specified. bool is_directory(const tdFS::path& aPath, bool aErrorRet) { try { return tdFS::is_directory(aPath); } catch (...) { return aErrorRet; } } Another way could be to have a "is_accessable" operation that determines if the status of the entry can be determined but it will not solve the racing problem. usage: for (directory_iterator itr(mypath); itr != directory_iterator(); ++itr) if (is_directory(*itr, true)) continue; // skip directories or for (directory_iterator itr(mypath); itr != directory_iterator(); ++itr) if (!is_accessable(*itr) || is_directory(*itr)) continue; instead of for (directory_iterator itr(mypath); itr != directory_iterator(); ++itr) try { if (is_directory(*itr)) continue; } catch (...) { continue; }

4 8

[admin] Overlapping reviews -- should this be allowed?
by Jeff Garland 10 Sep '04

10 Sep '04

Hi all - Our review wizard, Tom B. has suggested to me that we allow subsequent reviews to begin even if a previous review has been extended. This means 2 or more reviews will possibly be running in parallel. I don't believe we have a written policy, but I'm quite certain we have never run reviews in parallel. I also think it is a very bad idea. I believe reviews will suffer because people that want to review all the libraries in progress and participate in the discussion will not have enough time to do so. For most of us boost is a part-time thing -- we only have so much time per week to participate... This leads me to the conclusion that the current review schedule needs to be redone. 1st because IOStreams has been extended and 2nd because we agree that the current schedule is too aggressive. See http://lists.boost.org/MailArchives/boost/msg11034.php I realize it is a major pain to rearrange the agreed dates, but I don't think overlapping reviews is the answer. Thoughts? Jeff

11 26

Filesytem compile problem
by Martin 10 Sep '04

10 Sep '04

I get a compile error in boost/filesystem/operations.hpp when building an application that also uses the date_time library (using current CVS files). The problem is that date_time includes boost/operator.hpp which defines the template boost::equivalent. The name collides with boost::filesystem::equivalent. Reordering the include files (filesystem before date_time) fixes the problem for me but since boost/operators.hpp is used in a lot of libraries it might not always be that easy.

2 1

intel problems
by Pavol Droba 10 Sep '04

10 Sep '04

Hi, Most of tests in intel-win32-7.1-vc6-stlport-4.5.3 toolset are failing for the string_algo lib. Here is the output: http://tinyurl.com/5l2k4 All are linkinig errors. So there is probably an error in my jamfiles. Can somebody give me a hint what's wrong? Thanks, Pavol

1 0

RE: [boost] [filesystem] large file support test added
by Ben Hutchings 10 Sep '04

10 Sep '04

Beman Dawes <bdawes(a)acm.org> wrote: <snip> > Normally we would have a regression test that identifies the systems > which fail. But we don't test large file support directly because to > do so would be a burden on those who run the regression tests; such > tests would chew up gigabytes of disk space and might also be very > slow. <snip> why so? Unix file-systems support sparse files, as does NTFS.

2 1

[serialization] - xml bug?
by Jeff Flinn 10 Sep '04

10 Sep '04

Robert, The following demonstrates a problem with serialization of strings conataining '<' and/or '>'. This is on VC7.1 using serialization20 with boost_1_13_0. I'm not in a position to check this on the CVS version at this time. Is this still an issue? Thanks, Jeff ///////////////////////////////////////// #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/xml_iarchive.hpp> #include <string> #include <fstream> int main(int argc, char* argv[]) { std::string lStringOut("<empty>"); { std::ofstream lOut( "C:/xmltest.xml" , std::ios_base::out | std::ios_base::trunc ); if( lOut.good() ) { boost::archive::xml_oarchive oa( lOut ); oa << boost::serialization::make_nvp( "MyString", lStringOut ); } } std::string lStringIn; { std::ifstream lIn( "C:/xmltest.xml" ); if( lIn.good() ) { boost::archive::xml_iarchive ia( lIn ); ia >> boost::serialization::make_nvp( "MyString", lStringIn ); } } assert( lStringOut == lStringIn ); return 0; }

1 0

[filesystem] large file support test added
by Beman Dawes 10 Sep '04

10 Sep '04

Something special (defining some preprocessor macro) has to be done for 32-bit POSIX-like operating systems to enable support for file sizes greater than can be represented by 31 bits. The exact preprocessor macro name that has to be defined varies from system to system. Boost Filesystem currently supplies the correct macro for Linux, but not some of the UNIX systems. Normally we would have a regression test that identifies the systems which fail. But we don't test large file support directly because to do so would be a burden on those who run the regression tests; such tests would chew up gigabytes of disk space and might also be very slow. It recently occurred to me that sizeof(stat.st_size) > 4 is a pretty good surrogate for an actual test on a large file. While in theory it could yield a false positive, in practice it should identify whether or not large file support has been correctly enabled. It should never yield a false negative. Accordingly, I've added a new regression test, large_file_support_test.cpp. Initially it should pass on Windows and Linux systems, but fail on any UNIX systems that need additional macros defined. We can then experiment with adding additional macro definitions to get the test to pass on any systems it is currently failing. --Beman

1 0

dynamically created program options
by Rodolfo Schulz de Lima 10 Sep '04

10 Sep '04

Hi, I wonder if it's possible to handle dynamically created program options with boost::program_options. For instance: I have a config file that specifies configure options for dynamic loaded modules in my project. So the cfg file would be: [module.foo1] module_file = foo.so listen_port = 564 enabled = true [module.foo2] module_file = foo.so listen_port = 565 enabled = false [module.bar1] module_file = bar.so listen_port = 145 enabled = true As can be seen, foo1, foo2 and bar1 names are defined by the user in the configure file, and the program doesn't know about them before parsing the configuration. But if we parse that (somehow), an exception saying that the option "module.foo1.module_file" is invalid will be thrown. Can I manage the options_description "on the fly"? Another less complicated situation would be something like this: modules = foo1 foo2 bar1 [module.foo1] . . . [module.foo2] . . . [module.bar1] . . . So when parsing the "modules" option, we would know the new options name and it would be a matter of appending more option descriptions to the object. Regards, rod

2 1

ublas::vector from std::vector
by Neal D. Becker 10 Sep '04

10 Sep '04

I noticed there is no constructor for ublas::vector that takes a pair of iterators. Is there no direct way to construct a ublas::vector from a std::vector? Could there either be a constructor: (STL-style) template<typename input_iterator> vector (input_iterator begin, input_iterator end); or: (range-style) template<typename cont_t> vector (cont_t const&)

1 0

mingw build failed at regex
by Jim Pritts 10 Sep '04

10 Sep '04

Hi all, I am compiling boost 1.31.0 with mingw. Specifically the packages I am using are: boost 1.31.0 with regex patch binutils-2.13.90-20030111-1.tar gcc-core-3.4.1-20040711-1.tar gcc-g++-3.4.1-20040711-1.tar mingw-runtime-3.3.tar Boost builds find until bjam reaches the regex library. There seems to be a problem with wide character streams in the regex library. I don't think the latest mingw supports wide character streams. Is this correct? If so, how do I compile the regex library? If there is no workaround, is it possible to use mingw with STLPort and boost? The following is an excerpt form the actual error message I get: g++ -c -Wall -ftemplate-depth-100 -DBOOST_REGEX_CONFIG_INFO=1 -DBOOST_REG EX_DYN_LINK=1 -g -O0 -fno-inline -mno-cygwin -I"c:\build\bin\boost\libs\regex \build" -I "C:\boost_1_31_0" -o "c:\build\bin\boost\libs\regex\build\boost_reg ex.dll\mingw\debug\c_regex_traits.obj" "C:/boost_1_31_0/libs/regex/build/../src /c_regex_traits.cpp" ...failed gcc-C++-action c:\build\bin\boost\libs\regex\build\boost_regex.dll\min gw\debug\c_regex_traits.obj... gcc-C++-action c:\build\bin\boost\libs\regex\build\boost_regex.dll\mingw\debug\c _regex_traits_common.obj gcc-C++-action c:\build\bin\boost\libs\regex\build\boost_regex.dll\mingw\debug\c pp_regex_traits.obj C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf: I n instantiation of `std::basic_streambuf<wchar_t, std::char_traits<wchar_t> >': C:/boost_1_31_0/libs/regex/build/../src/cpp_regex_traits.cpp:92: instantiated from `<unnamed>::parser_buf<wchar_t, std::char_traits<wchar_t> >' C:/boost_1_31_0/libs/regex/build/../src/cpp_regex_traits.cpp:590: instantiated from here C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf:13 5: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf:23 4: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf:23 9: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf:57 4: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' C:/mingw/bin/../lib/gcc/mingw32/3.4.1/../../../../include/c++/3.4.1/streambuf:58 6: error: no type named `pos_type' in `struct std::char_traits<wchar_t>' C:/boost_1_31_0/libs/regex/build/../src/cpp_regex_traits.cpp: In instantiation o f `<unnamed>::parser_buf<wchar_t, std::char_traits<wchar_t> >': C:/boost_1_31_0/libs/regex/build/../src/cpp_regex_traits.cpp:590: instantiated from here ... Thanks, Jim.

2 1

Empty member optimization
by Joao Abecasis 10 Sep '04

10 Sep '04

Hi! I have written a small utility class to provide "empty member optimization" for arbitrary types. The implementation makes use of the empty base class optimization (EBCO) but avoids injection of the class. A uniform and contained interface is exposed wether the optimization applies or not: template <typename T, size_t Index> compressed_pair { // several constructors may be provided but, for now, // default and copy constructor typedef T value_type; value_type & get(); value_type const & get() const; }; I believe this could be used as the basis for a compressed_tuple. Here's a sample use: template <typename T0, typename T1> struct A : private compressed_member<T0> , private compressed_member<T1, 1> { typedef compressed_member<T0> member0; typedef compressed_member<T1, 1> member1; T0 const & first() { return base0::get(); } T1 const & second() { return base1::get(); } }; There is a catch with the current implementation: some regular empty member (or regular empty member of some compressed_member) could end up sharing address with an empty compressed_member. This happens because compressed_member<T> does not inherit from T but hides this "relationship" from the compiler. Is there any interest in such an utility? To test compressed member I wrote another (toy) utility: empty_store. empty_store is an empty class with a static map that associates an instance's address to data. Checks are made everywhere to ensure that no two instances share the same address. The code can be found (zipped) here: *http://tinyurl.com/4e85l* Best regards, João Abecasis

4 8

ublas indirect_array, shared_array, array_adaptor doc?
by Neal D. Becker 10 Sep '04

10 Sep '04

I noticed in ublas/storage.hpp a number of interesting-looking types, such as array_adaptor, shared_array, indirect_array. I did not find any documentation on these.

1 0

class random_device from <boost/nondet_random.hpp> has no implementation
by steven.robbins＠videotron.ca 10 Sep '04

10 Sep '04

Hi, Most of the boost libraries' implementation is either in header files, or in a compiled library. Class boost::random_device is an exception: the implementation is found in libs/random/random_device.cpp, but this file is not built into any library. This issue has been raised by a Debian user (http://bugs.debian.org/261719) and earlier (http://lists.boost.org/MailArchives/boost-users/msg03506.php) but never addressed. I wanted to confirm whether this is a bug or is by design. Thanks, -Steve

1 0

Re: [boost] IOStreams Formal review -- Guide for Reviewers
by Jonathan Graehl 09 Sep '04

09 Sep '04

First, let me apologize for not being able to review the actual code (yet). The interface and correctness/performance of implementation are all I really care about for now :) >There are some special cases where the copying is wasteful, though. For >instance: > >1. If filter1 is just a passive observer, simply counting the number of >occurences of '\n', or copying the data to a logging stream, then the end user >should really be writing directly to buf2. Filter1 could process the data using >the same buffer as filter2. > >2. Same as above, but filter1 also modifies the data in-place, making >character-by-character modifications. (E.g., a toupper filter). This can be >handled the same way. > >3. If 'resource' is a stream or stream buffer, it could be assumed to do its own >buffering. In that case, filter2 should be writing directly to resource, instead >of to streambuf3: > > filter2.write(resource, buf2, buf2+ n2). > >These three cases can be handled easily by modifying the existing framework. I >didn't add special treatment because it occurred to me rather late in >development. > > > I'd certainly feel a bit more proud of the library if it handled these cases (1 and 3 seem most important). It seems well worth a few days' delay. >There is another class of cases in which the current setup is wasteful, but I >think it is rather domain-specific: > >4. Most filters in the chain modify only small parts of character sequences, >leaving big chunks unchanged. > > > Well, basic_newline_filter would do this - at least when replacing CRLF with a single '\n' character. >To optimize case 4 would require a major library extension. My feeling is that >it is not necessary at this point, but I'd like to know what others think. > > > It should certainly wait if you don't have a design already in mind. The library is good enough without this. >----------------------------------------------------- > >Part III: Interface questions: > >1. How to handle read and write requests which return fewer characters than >requested, though there has been no error, and EOF has not been reached. I think >some answer to this question is necessary to allow the library to be extended >later to handle models orther than ordinary blocking i/o. I mention three >possibilties here, http://tinyurl.com/6r8p2, but only two are realistic. I'm >interested to know how important pople think this issues is, and what is the >best way to resolve it. > > > I think #2 would be most in line with what people are used to under Posix (-1/EAGAIN). Blocking (option 1) actually doesn't make any sense at all except at the ends (source/sink), unless you put each filter in a chain into its own thread and use something like semaphores. I suppose the idea is, if you're in the middle of a filter chain, and somebody gives you some input which would overflow your buffer, you attempt to empty out your buffer to the next guy, but if he can't take enough of it to allow you to accept the whole input (or even, none of it), you have to tell the guy who sent it to you you can't take it, and he has to hold onto it in his buffer. That seems reasonable. I might in fact prefer that my source or sink resource act like #1 (block until at least one character or EOF), and I assume this would be the default behavior if I open it in the default, blocking mode, but it isn't possible to have filters act that way; they need to pass the "can't take your data" feedback all the way back through the stack to the end user, who then needs to hold onto it and select/spin/whatever on the underlying sink resource ... >2. The stack interface. Is the interface to the underlying filter chains rich >enoguh? Originally is was similar to std::list, so that you could disconnect >chains at arbitrary points, store them, and reattach them later. I decided there >wasn't much use for this, so I simplified the interface. > > I'm sure someone, somewhere, sometime will want to perform splices/appends on filter chains, but I can't imagine why, either. At least, keep the simple interface and put the more complicated, flexible one in the appendix. >3. Exceptions. James Kanze has argued repeatedly that protected stream buffer >functions should not throw exceptions (http://tinyurl.com/5o34x) I try to make >the case for exceptions here: http://tinyurl.com/6r8p2. What do people think? > > > > I sympathize with both arguments; either way seems fine to me. There is no real performance penalty for an exception that is thrown at most once per stream (EOF), but he's right that the existing interface (which end users never see) seems to specify a return value in that case. But, as you say, if you want to support async IO, it's moot - you do have to return the number of characters successfully read/written, so you need the std::streamsize return type, so ... you may as well return EOF instead of throwing it. That is, I see no reason to throw an EOF value if you support async IO (which I think would be lovely). >So the question is: Should an open() function be added to the closable >interface, to eliminate the need for first-time switches? Alternatively, should >there be a separate Openable concept? > > > Without a doubt, an Openable concept. If you add open() to Closeable you'd really want to change the concept name ;) For example, if I implement a first-time flag (no real hardship), I'll have to remember to add the first-time test not only when data is processed, but also when the stream is closed (need to handle empty input properly). I suspect people will forget this at least once. There's also a minor performance gain: the interface would be called when the stream is initialized, I assume, and not require a first-time flag check with each use. Admittedly, inconsequential. -Jonathan Graehl

2 6

[boost.range] comparison operators for iterator_range and sub_range
by Thorsten Ottosen 09 Sep '04

09 Sep '04

Dear all, Another small issue have surfaced regarding operator==(), operator!=() and operator<() (the latter currently not there). The current behavior is compare the two underlying iterators. I would suggest to change this to compare the objects in the underlying range. The motivation would be the follwoing: 1. comparing the iterators is seldom useful and can be done explicitlty or by a new member function equal() 2. comparing the objects is the range is highly useful and allows for code like sub_range<string> sub = ...; if( sub == "foo" ) 3. operator<() cannot be defined for iterators in general and hence we couldn't put iterator_range into a set/map; Any comments? An additional question would be if operator> operator>= etc really needs to be defined? I would support just to have ==, !=, < to start with. br Thorsten

3 4

Incorrect XML output using boost::serialization
by Brian Riis 09 Sep '04

09 Sep '04

Using boost CVS (boost-04-09-05-2200), I am using the serialization library (which generally is a real life-saver, btw. Thanks Robert!!!) Anyway, I have been using the XML output for a few days, and I just had a good look at it, and realized it is not well-formed. > <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> > <!DOCTYPE boost_serialization> > <boost_serialization signature="serialization::archive" version="3"> > <m_db class_id="0" tracking_level="0"> > ... The boost_serialization STag above is never matched by a ETag, nor is it an EmptyElem apparently. Is this intended? Or did I miss something while writing the serialization code? I.e. am I supposed to close it myself, or something? It is a minor thing, I know, but it _will_ make any standards-conforming XML-viewer reject it. Other than that, as I mentioned above, Boost.Serialization has saved my life recently (rewriting to use it was by far easier than debugging the I/O routines I was using, and they were somehow _seriously_ messed up). Great work! -- /Brian Riis

1 0

Re:[boost] Re: IOStreams formal review start
by Robert Ramey 09 Sep '04

09 Sep '04

>I decided not to use iterators because I concluded that it would miss the >opportunity for many important optimizations that can be made when one is >presented with a contiguous buffer full of characters instead of one >character at a time. For example, I don't think zlib is very efficient if >you pass it one character at a time. >Still ... >I wish I had looked at the Dataflow Iterators in your library when I first >read your message! I put it on my mental 'to do' list then promptly forgot. >It looks like Dataflow Iterators and input/output filters are intended to >solve exactly the same sort of problems in many cases. So there are these >obvious questions: I didn't want to make a big issue of this because it amounts to comparing what currently the sketch of an idea (my dataflow iterators) to a fully developed and implemented idea (your iostreams). It's an unfair (to you) and often misleading type of comparison. So I see your library getting accepted more or less as it is because it works, well documented and addresses a real and pressing need. Dataflow iterators really became practical with Dave's new iterator façade/adaptor library - with its very formal definition. But, in spite of the fact that they have been used successfully in the serialization package for doing some of the things your library does, Dataflow iterators are a little too fragile for general use. Someday you or someone might want to re-implement some of your library with dataflow iterators - or not. At that point it would become an implementation issue. I'm very pleased that someone has seen the appeal of this idea. I sort of feel that I'm out there by myself with my ideas. I think its because I'm getting old. Anyway. >1. Where the functionality overlaps, which approach is faster? One of the prime motivations for the dataflow iterators is gain absolutely maximum speed. This should occur by collapsing of composed inline functions by C++ optimizing compilers. My limited investigation into this convinces me that this occurs as I would hope. >2. What can your approach do that mine can't? >3. What can my approach do that yours can't? Dataflow iterators is basically a compile-time composition concept while your method is basically a run-time composition concept. There in lies the difference Compile time composition a) compilers can collapse inline code for maximum speed b) each composition of filters is recompiled - can imply replicated almost the same code. Code bloat possible c) new chains can't be made at runtime under program control - its too late to recompile. Runtime composition a) filter chain can be built as needed under program control. b) each filter is compiled only once and reused. No code bloat c) no opportunity for "inter-filter" optimization - the code is compiled before the filters are composed. >4. If your approach is better all around, or in a broad class of cases, can >I adapt my library to use it? (I think so -- the pipe notation, which you >don't like, can give the compiler a clue which filters should be fused at >compile time.) My main complaint with the pipe notation is that, is doesn't permit the following idea to be expressed without destroying its original elegance: Encrypt( Cat( Stream 1, Stream 2 ) ) That is, that you have to break it (the pipe idea) in order to save it. Also I believe that implementing this at compile time by overloading operators would be a lot of work for mere syntactic sugar. In fact this hides the operation of your chaining scheme rather than keeping it transparent. This is the same reason I like to see the streambuf/stream clarified rather than hidden. Hiding is often a good idea - unix command line pipes - but I don't think its a great idea for programmer libraries. I want sharp tools whose application and usage are obvious so that I can compose them into what I need. I don't want a wrapped up solution. So I like a smaller library (e.g. streambuf) with examples (for cut and paste) on how to use it. I also think it's easier to document. I don't think you mess with your library in a major way. Separating out streams/buffers is useful conceptually but that's really mostly a matter of documentation. Basically you should finish what you started, let people start using it then at your leisure if you have the inclination look in this idea. 5. If my approach is better, can your library use it? (BTW, How do you use the Dataflow Iterators in your library?) My use case for this functionality is the following I want a zlib compression filter and an encryption filter. I want to be able to use them in a stream either as compress | encrypt or encrypt | compress. Your library can do that. So the problem is solved in the short term. Its interesting how my thinking has evolved on this. First I thought what I need was a stream adaptors to adapt a stream using filters. After I became more familiear with streams and streambufs I realized that this functionality didn't belong in streams but in streambufs - exactly where you put it. I was much encouraged by your efforts and approach - and Jeff Garland's previous accomplishment of adding zlib compression to a streambuf. Alas, I've now come to understand where codecvt facet fits in here. My current thinking - its just speculation at this point - is composition of codecvt facets using dataflow iterators. This would result in: a) a codecvt_facade - template for making a codecvt class given a dataflow iterator chain at compile time. b) dataflow iterators for encrypt, compress, base64, wchar_t to mbchar, mbchar to wchar_t, wchar_t to utf-8 etc. c) a method - codecvt_adaptor ? - for composition of arbitray codecvt facets. This would permit us to use other existing pre-compiled facets like translating to Chinese mult-byte characterset. So given the above, we could make a custom codecvt facet which would take the output, compress it, encrypt it, convert to base64, convert to Chinese character set with one compile time statement and use that facet with any stream. Except for the Chinese part which used a pre-compiled element, the compiler would optimize away all redundant copying. Naturally this codecvt facet on steroids could be used with any streambuf without alteration. (or even recompilation). So the "final division of effort would be" Streams - rendering types like int, float, etc as char or wchar strings. Streambuf - buffering Codecvt_facet - filtering/transformation Bear in mind that this glosses over details like the fact that there's a lot of annoying little differences in standard libraries in codecvt_facet interface, function prototypes, etc. GCC used 4 by wchar_t, window uses 2 byte wchar_t, endien issues, on and on and on. I've had problems with several libraries that I don't believe handle codecvt facets properly. Just using the utf-8 facet written by Ron Garcia - (nice job - no errors) has been a trial due to these issues. >I'm going to try to re-implement some of your iterators as Filters, and see >what happens. Feel free to experiment at your leisure. But don't get distracted. Starting something is easy - finishing something is very hard. You're in a position to get something of substance actually finished and in the hands of real users. Don't lose focus on that. In the serialization library - composition of dataflow iterators is used to implement the following: Escaping/unescaping html text Binary <-> base64 translation Wstring <-> string translation Maybe others - I don't remember The dataflow concept was once and object of research interest as a fundamental programming paradigm. It's somewhat to related to functional programming in this regard. My dataflow iterator implementation is somewhat similar to the FP package reviewed earlier this year in that it implements a different programming paradigm using the facilities of C++ templates. However, its much less ambitious and much more focused on immediate C++ problems rather producing a complete implementation of another programming paradigm. One thing is clear to me. We're going to see lots of new things in the future of programming. Much more than people think. Robert Ramey

2 1

Re: typeof
by Arkadiy Vertleyb 09 Sep '04

09 Sep '04

Hi Goran, > First, why there isn't a way to register wstring type, even though I've registered wchar_t? I've > managed to use it only after I've registered basic_string template with one template parameter. > Seems inpractical... There are a few choices here: 1) BOOST_TYPEOF_REGISTER_TYPE(wstring); 2) BOOST_TYPEOF_REGISTER_TYPE(wchar_t); BOOST_TYPEOF_REGISTER_TEMPLATE(std::basic_string, 1); 3) BOOST_TYPEOF_REGISTER_TYPE(wchar_t); BOOST_TYPEOF_REGISTER_TEMPLATE(std::basic_string, 3); BOOST_TYPEOF_REGISTER_TEMPLATE(std::char_traits, 1); BOOST_TYPEOF_REGISTER_TEMPLATE(std::allocator, 1); Pre-registration of STL types would be a very nice addition to the library. For now I am avoiding this, and trying to focus on the facility itself. > Second problem, no matter whether I've used wstring or basic_string for registration, I wasn't able > to get a type of wstring::iterator expression! This is much more complicated problem, and I am not sure it can be resolved... The problem is that you can't specialize (or overload) on a nested types. The Standard clearly says that this is a non-deducible context. So we can't do something like: template<class V, class T> encode_type<V, T::iterator>{}; // compiler error! This is VERY unfortunate, and I 've been trying to think of workarounds, but so far I only came up with one that is quite limited and ugly... So I decided to put this on hold. Regards, Arkadiy

2 2

Test of list access through gmane -- please ignore
by Larry Meehan 09 Sep '04

09 Sep '04

Test of boost list access through gmane -- please ignore.

1 0

Re: [boost] Re: Empty member optimization
by JOAQUIN LOPEZ MU?Z 09 Sep '04

09 Sep '04

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Jueves, Septiembre 9, 2004 6:44 pm Asunto: [boost] Re: Empty member optimization [...] > Second, I don't have time to look into the details of your > implementation, but I > wan't to make sure you're aware of the EBO problems Dave Held ran > into with his > policy_ptr, based on the loki SmartPtr. Basically, compilers will > apply EBO once > or twice for a given class, and that's it. The exception seems to > be recent > versions of gcc (I don't remember if its 3.3 or 3.4). > Maybe the implementation can be changed so that compressed_member can inherit from another compressed_member, so as to make this syntax feasible: template <typename T0, typename T1> struct A : private compressed_member<T0> ::and<T1, 1>::type ::and<T2, 2>::type { } or something similar, resolving to a linear hierarchy of compressed_member's. AFAICS, EBO applicability limitations would be solved that way. An sketch of copmresed_member implementation would be as follows: struct dummy{}; template <typename T, size_t Index = 0, typename Base=dummy> struct compresed_member: public Base { // utility metafunc for adding members template <typename Q, size_t AnotherIndex = Index+1> struct and { typedef compressed_member< Q, AnotherIndex, compressed_member<T, Index, Base> > type; }; // rest of the implementation } Get the idea? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[Boost-bugs] [ boost-Bugs-1025124 ] boost::function doesn't accept classes declared in functions
by SourceForge.net 09 Sep '04

09 Sep '04

Bugs item #1025124, was opened at 2004-09-09 06:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1025124&group_… Category: functional Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Rodgers (mark_rodgers) Summary: boost::function doesn't accept classes declared in functions Initial Comment: Submitter: John Engström <john.engstrom\spam\(a)\spam\solcorp.com> Using MSVC 7.1, I use a functor defined in-scope, as in the following example. ///////////////////// code snippet void bar() { ... struct my_functor { void operator () (int arg1, int arg2) { ... foo(); ... } ... }; my_functor my_functor_instance; boost::function2<void, int, int> my_function1 = boost::ref(my_functor_instance); boost::function2<void, int, int> my_function2 = my_functor_instance; } /////////////////// explanation This fails to compile, see below for error messages, however if I move the declaration of the functor out of the function bar(), it compiles fine. Perhaps it only happens with MSVC. /////////////////// error messages main.cpp(116): error C2893: Failed to specialize function template 'const boost::reference_wrapper<T> boost::ref(T &)' main.cpp(117): error C2440: 'initializing' : cannot convert from 'WinMain::my_functor' to 'boost::function2<R,T0,T1>' with [ R=void, T0=int, T1=int ] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1025124&group_… ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Boost Digest, Vol 844, Issue 5
by Michael Stevens 09 Sep '04

09 Sep '04

On Thursday 09 September 2004 05:42, David Abraham wrote: > If these are (supposedly) random access iterators, it's because the > ublas people aren't using iterator_facade or iterator_adaptor to > define them. I think you hit the nail on the head there! Making this change is number one on the priority list. The base classes to do this are already partially in place. Just a little work is required to change the rest of the code! Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

[mpl][vacpp] remaining problems
by Joaquín Mª López Muñoz 09 Sep '04

09 Sep '04

Tests are failing due to a problem with BOOST_MPL_ASSERT_RELATION, for instance: "../libs/mpl/test/arithmetic.cpp", line 25.5: 1540-1264 (S) The template argument must be preceded by an ampersand (&). I've checked boost/mpl/assert.hpp, and seems like there is already an alternative implementation for buggy compilers driven by the macro BOOST_MPL_CFG_ASSERT_USE_RELATION_NAMES If given permission, I can commit a fix to define this for vacpp as well, and see how things work. If Markus is listening, maybe he can do a local test before. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [admin] Overlapping reviews -- should this be allowed?
by Dave Gomboc 09 Sep '04

09 Sep '04

> > I wonder if enough libraries are going through the preliminary > > submission/refinement phase outlined at > > http://www.boost.org/more/submission_process.htm#Preliminary > > Many are not. The items listed there before submission for review are not that onerous. If they haven't been performed, the package should not be added to the review queue. Also, FWIW, I'm ixnay on the overlapping reviews. Dave

1 0

Re: ublas iterator problem
by Michael Stevens 09 Sep '04

09 Sep '04

Neal, > > "Neal D. Becker" <ndbecker2(a)verizon.net> writes: > Actually, I'm having trouble tracing this. AFAICT, in vector.hpp > // Array based vector class > template<class T, class A> > class vector: > ... private: > typedef typename A::const_iterator const_iterator_type; > typedef typename A::iterator iterator_type; You missed out that iterator_type a private (at least in CVS!). Later you will see some thing like: class const_iterator: public container_const_reference<vector>, public random_access_iterator_base<dense_random_access_iterator_tag, const_iterator, value_type> { public: Which does the work. The documentation is correct. Here const_iterator is a uBLAS Indexed Random Access Iterator concept which SHOULD (indirectly) supply operator[]. Michael -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

Re: ublas iterator problem
by Michael Stevens 09 Sep '04

09 Sep '04

On Thursday 09 September 2004 05:42, David Abraham wrote: > If these are (supposedly) random access iterators, it's because the > ublas people aren't using iterator_facade or iterator_adaptor to > define them. I think you hit the nail on the head there! Making this change is number one on the priority list. The base classes to do this are already partially in place. Just a little work is required to change the rest of the code! Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

problem compiling spirit in VC7.1
by Arkadiy Vertleyb 09 Sep '04

09 Sep '04

Hi, Somehow my post to the Spirit forum didn't pass through, so I am repeating it here. The following problem results from just including spirit.hpp from the current Boost CVS, when compiling with VC7.1: boost\spirit\utility\impl\chset\range_run.ipp(57) : warning C4003: not enough actual parameters for macro 'min' Apparently there is a conflict with an STL macro... Is it a known problem? Regards, Arkadiy

3 2

ublas iterator problem
by Neal D. Becker 09 Sep '04

09 Sep '04

#include <boost/numeric/ublas/vector.hpp> namespace ublas = boost::numeric::ublas; void F () { ublas::vector<int> u (10); int y = *u.begin(); int x = u.begin()[0]; } This code fails to compile with g++34 + current boost.cvs. Test.cc:8: error: no match for 'operator[]' in 'boost::numeric::ublas::vector<T, A>::begin() [with T = int, A = boost::numeric::ublas::unbounded_array<int, std::allocator<int> >]()[0]' u.begin() should return an iterator, and the iterator should define operator[]. Why doesn't this work?

3 2

RE: [boost] ublas iterator problem
by Stefan Seefeld 09 Sep '04

09 Sep '04

> From: Neal D. Becker [mailto:ndbecker2@verizon.net] > Sent: September 8, 2004 15:59 > u.begin() should return an iterator, and the iterator should define > operator[]. Why doesn't this work? huh ? Which iterator defines operator[] ? It may define operator+(size_type) or similar, if it allows random access, but not operator[]. If you know your container manages contiguous memory you may use '&*u.begin()' to access the raw memory, and apply your operator[] to that. Regards, Stefan

3 2

finding jscript ebnf
by Chau Johnthan 08 Sep '04

08 Sep '04

I am totally a newbie of boost lib, I am finding ebnf of jscript, and I wish I can gen c source of lexer, parser by using boost. thanks.

1 2

[serialization] BOOST_SHARED_POINTER_EXPORT and namespaces
by Jeff Flinn 08 Sep '04

08 Sep '04

The following is invalid: namespace x { class y { ... }; } BOOST_SHARED_POINTER_EXPORT( x::y ) Which requires something like: typedef x::y x_y; BOOST_SHARED_POINTER_EXPORT( x::y ) The following additional macro mimics some of the other export macros: #define BOOST_SHARED_POINTER_EXPORT_GUID(T,N) \ typedef boost::detail::sp_counted_base_impl< \ T *, \ boost::checked_deleter< T > \ > __shared_ptr_ ## N; \ BOOST_CLASS_EXPORT(__shared_ptr_ ## N) \ BOOST_CLASS_EXPORT(T) \ /**/ So this is valid: BOOST_SHARED_POINTER_EXPORT_GUID( x::y, x_y ); Thoughts on adding this. Thanks, Jeff

1 0

Different results for identical (?) regressions
by Stefan Slapeta 08 Sep '04

08 Sep '04

There are some toolsets in the regression results that are run by more than one person and which produce different results! As example the results for vc7.1 in this table: http://tinyurl.com/6zmuo Could somebody explain this? It's not easy to guess which one is the "better" test result... Stefan

4 3

Re: [boost] [serialization] request: low-level info about order of serialization
by Robert Ramey 08 Sep '04

08 Sep '04

Joaqu?n M? L?pez Mu?oz wrote: >Ummm, I guess I'm not explaining myself, let me try with an example: >consider a multi_index_container like this: >typedef multi_index_container< > int, > indexed_by< > sequenced<>, > sequenced<> > > >> bilist; >Then, when serializing such a bilist, the order maintained by indices #0 and >#1 must be recorded separately. Roughly speaking, this involves: >1. serializing the elements in the order induced by index #0. >2. traversing index #1 and serializing a record of rearrangements with >respect to index #0. >Step 2 can be accomplished in a simple manner by serializing pointers to >the (previously serialized) elements, but in the order induced by index #1. >As Boost.Serialization keeps track of previously stored objects, this will >work OK. To further exemplify this, consider a particular bilist like this: >index #0: [begin(),end) = 1 4 3 5 2 6 >index #1: [begin(),end) = 1 3 5 6 2 4 >then all the info we need to reconstruct the container can be saved as: >1 4 3 5 2 6 >&1 &3 &5 &6 &2 &4 >where & means we save a pointer to a previously serialized element. >I hope everything's clear up to this point. This looks clear to me. It seems well within the normal application of the serialization library and would seem to work as expected. Question: have you built and tested this? I think this would be a useful starting point for what follows. I will refer to this as the plain vanilla implementation. (PVI) Assuming that the above works as expected, I understand that your concern is that the sequences of pointers could be reduced to a smaller sequence. The question is what would be the best way to exploit this possibility. One way would be just keep a list when serializing index #0 and referring to it when serializing index #1. This would give you everything you need without changing anything about the serialization library. Of course, this does replicate some of the information within the serialization library. I would be extremely reluctant to make the library more elaborate to accommodate what I see as a very special case. If it were me, I would think the PVI was plenty good enough as the space for a replicated pointer is very small relative to the data as whole. The PVI also has a pleasing symmetry in that no index is "privileged" by being first and will work automatically for an arbitrary number of indexes. But that's my opinion and its your library. We have one alternative - keeping your own list of saved/loaded object addresses which can be used to streamline the process. There might be another way that would give you what you want. Rather than thinking: a) serialize data b) serialize index 0 c) serialize index 1 d)... e).serialize index n which is the way that the serialization library encourages one to think. One might consider: a) serialize data b) serialize all indexes in parallel: i) read indexes in order ii) "merge indexes" into a virtual list iii) for each unique index entry 1) serialize the list of indexes to which it applies 2) serialize the index entry itself I think this would be "sort of" equivalent to what you want to do in that replicated pointers would not be stored. This would even eliminate the need to track the addresses of the serialization of base data allowing one so designate all instances of indexed_set as not using tracking. So even the address-object id lookup inside the serialization library would be skipped. This would be maximally efficient. Personally, I'm skeptical that it would be worth the effort - but of course its up to you. One thing I would like to see is that the "Plain Vanilla Implementation" is working before something like the above is considered. Robert Ramey

1 0

Boost.Threads MinGW compiler warning patches
by Daniel Schlyder 08 Sep '04

08 Sep '04

Hello, Attached are patches to fix a few warnings I get when compiling Boost.Threads using MinGW (GCC 3.4.1): native_error-dllimport-warning.diff fixes (maybe not in a good way, but at least now you know the warning exists :)): boost/thread/exceptions.hpp:37: warning: inline function 'int boost::thread_exception::native_error() const' is declared as dllimport: attribute ignored. tss-no-newline-warning.diff fixes: boost/thread/detail/tss_hooks.hpp:78:39: warning: no newline at end of file libs\thread\build\..\src\tss.cpp:206:37: warning: no newline at end of file -- Daniel Schlyder http://bitblaze.com/

2 1

Review schedule
by Miro Jurisic 08 Sep '04

08 Sep '04

Could we keep the review schedule more up-to-date? I went there expecting to find a handy like to the library currently under review, rather than grovelling through the mail archive, but alas, it's 10 months out of date. Thanks, meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>

7 11

review for range scheduled?
by Neal D. Becker 08 Sep '04

08 Sep '04

I didn't see range scheduled for review? I hope this is planned. I vote +10.

2 1

date_time warnings on VC 7.1
by Stefan Slapeta 08 Sep '04

08 Sep '04

A single #include <boost/date_time/posix_time/posix_time.hpp> produces the following warnings on VC 7.1. Can this be fixed? Cheers, Stefan C:\views_cvs\boost\boost\date_time\time_system_counted.hpp(57) : warning C4244: 'initializing' : conversion from 'boost::date_time::counted_time_rep<config>::int_type' to 'boost::date_time::gregorian_calendar_base<ymd_type_,date_int_type_>::date_int_type', possible loss of data with [ config=boost::posix_time::millisec_posix_time_system_config ] and [ ymd_type_=boost::gregorian::greg_year_month_day, date_int_type_=boost::date_time::int_adapter<unsigned long>::int_type ] C:\views_cvs\boost\boost\date_time\time_system_counted.hpp(52) : while compiling class-template member function 'boost::date_time::counted_time_rep<config>::date_type boost::date_time::counted_time_rep<config>::date(void) const' with [ config=boost::posix_time::millisec_posix_time_system_config ] C:\views_cvs\boost\boost\date_time\time_system_counted.hpp(111) : see reference to class template instantiation 'boost::date_time::counted_time_rep<config>' being compiled with [ config=boost::posix_time::millisec_posix_time_system_config ] C:\views_cvs\boost\boost\date_time\time.hpp(52) : see reference to class template instantiation 'boost::date_time::counted_time_system<time_rep>' being compiled with [ time_rep=boost::posix_time::int64_time_rep ] C:\views_cvs\boost\boost\date_time\posix_time\ptime.hpp(32) : see reference to class template instantiation 'boost::date_time::base_time<T,time_system>' being compiled with [ T=boost::posix_time::ptime, time_system=boost::posix_time::posix_time_system ]

2 1

Container optimized for "insert once"
by Stefan Slapeta 08 Sep '04

08 Sep '04

Hi all, I'm looking for an associative container which is optimized for one-time insertion and avoids much of the overhead of std::map therefore. IIRC Andrei once published something like this: a vector of pairs that was sorted once and accessed by binary search. Is there something similar in boost? Stefan

6 7

Challenge: Implement a state machine compiler as a Cpp macro using Order
by Vesa Karvonen 08 Sep '04

08 Sep '04

Hi, During the summer, I have been designing and implementing a metalanguage for C preprocessor metaprogramming named Order. The Order language is a *complete* high-level functional programming language with features such as - lexical scoping, - first-class functions, - anonymous functions, - partial application of functions (currying), - intuitive call-by-value semantics, and - tail-recursion optimization. The Order prelude supports, among other things, - arithmetic on arbitrary precision natural numbers and small literals {0,...,100}, - sequences (with many higher-order functions), - tuples, and - so called token strings/sequences. The Order interpreter, which is implemented using the C preprocessor macro mechanism, can be used to generate arbitrary sequences of preprocessing tokens (read: code). The intepreter also provides a debug mode that checks for many kinds of programming errors (syntax-errors, run-time type errors and user assertions). The Order language has been designed to transform the feel of C preprocessor metaprogramming from "learning lots of tricky, low-level Cpp specific idioms" to "thinking in an intuitive high-level language". Here is a short example of Order code that generates the complete lyrics to the song "99 Bottles of Beer on the Wall": #define GEN_phrase(N_bottles, N_minus_1_bottles) \ N_bottles of beer on the wall, \ N_bottles of beer, take one down, pass it around, \ N_minus_1_bottles of beer on the wall. #define ORDER_PP_DEF_8bottles \ ORDER_PP_FN(8fn(8N, \ 8cond((8greater(8N, 1), \ 8separate(8N, 8quote(bottles))) \ (8equal(8N, 1), \ 8quote(1 bottle)) \ (8else, \ 8quote(no more bottles))))) ORDER_PP(8for_each_in_range (8fn(8N, 8emit(8quote(GEN_phrase), 8tuple(8bottles(8N), 8bottles(8dec(8N))))), 100, 1)) (The above is an extract from a completely documented example.) There are two known caveats. First of all, the Order interpreter requires standard C variadic macros and placemarkers, which aren't standard C++, yet. The second caveat is that the Order interpreter currently requires a standards conforming preprocessor. The interpreter has been developed on the GNU CPP (3.x). Theoretically, the interpreter should be quite portable to less conforming preprocessors, because the interpreter is a "closed system of macros", but I personally don't have the preprocessors nor the time, though I would be happy to assist in such porting work by providing information on the interpreter. I'm currently working on the Order programming manual. I have already written several completely documented examples for the programming manual, which should be enough to get one started in using the Order interpreter, but one example I'd like to have would be a state machine compiler (SMC). Instead of implementing and documenting a SMC myself, I'd like to challenge *you* to write such a SMC example to be included in the forthcoming manual. Knowing that the documentation is still unfinished, I will be happy to assist people writing such a compiler (or some other kind of code generator) through e-mail (I might setup a mailing list). This might also help me to identify specific issues (e.g. sources of confusion, important design heuristics) that need to be addressed in the forthcoming programming manual. If you are interested in seeing the future of C preprocessor metaprogramming by trying out the Order intepreter and implement a state machine compiler (or some other program generator), please contact me at vesa_karvonen(a)hotmail.com. Note that you won't need previous Boost.Preprocessr library experience. Learning to use the Order interpreter should be an order of magnitude easier than learning to use the Boost.Preprecessor library. After I've completed the Order programming manual, I will release the Order interpreter (independently) and submit it to Boost if there is enough interest. Regards, Vesa Karvonen _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0