- Boost - lists.boost.org

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