- Boost - lists.boost.org

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