September 2004 - Boost - lists.boost.org

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

17 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 17 Sep '04

17 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