- Boost - lists.boost.org

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