- Boost - lists.boost.org

[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