- Boost - lists.boost.org

Avoiding warning on the do{...}while(0) macro implementation trick
by Ivan Vecerina 19 Sep '04

19 Sep '04

I've noticed discussions about this a couple of years ago. For assert-style macros that include multiple statements, a common idiom is to enclose the statements in a do{...}while(0) dummy loop. This makes the macro behave like a single statement. A problem with some compilers (notably VC7.x) is that this triggers a warning (C4127: conditional expression is constant). The workaround adopted by boost is to automatically disable this warning -- which however can be legitimate and useful in user code. I think I have found a better 'always-false' condition which does not trigger a warning, and works at least in VC7.1: do{ }while(__LINE__==-1) Do you see a problem with this approach? Could this approach be used to stop disabling warning 4127 when boost is compiled? Do other compilers have similar warnings and workarounds? Should a boost macro that expands to a warning-free always-false (or always-true) compile-time constant be considered? This would also allow statements such as BOOST_ASSERT(BOOST_FALSE), while(BOOST_TRUE), or do{...}while(BOOST_FALSE) to compile without warning... Regards, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form

2 1

Concept_check.hpp question
by Aleksey Gurtovoy 19 Sep '04

19 Sep '04

Is there a good reason for the following #ifdef in "concept_check.hpp": template <class Concept> inline void function_requires(mpl::identity<Concept>* = 0) { #if !defined(NDEBUG) void (Concept::*x)() = BOOST_FPTR Concept::constraints; ignore_unused_variable_warning(x); #endif } ? It causes "concept_check_fail_expected" test to fail if compiled in "release mode"; see http://tinyurl.com/6u286. Any objections to removing it? -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re:[boost] Re: [static_assert] Regression with gcc 3.4.2?
by Robert Ramey 19 Sep '04

19 Sep '04

"David B. Held" <dheld(a)codelogicconsulting.com> wrote in message news:cihmvu$3ik$1@sea.gmane.org... > #include <boost/static_assert.hpp> > > template <typename T> > struct foo > { > void bar(void) > { > BOOST_STATIC_ASSERT(false); > } > }; I use .... BOOST_STATIC_ASSERT(sizeof(T) == 0); .... Robert Ramey

2 1

RE: [boost] Re: [Output Formatter]: Cascading Style Sheets (CSS)proposal
by Robert Ramey 19 Sep '04

19 Sep '04

Reece Dunn wrote: >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. Personally, I don't see much overlap at all between, serialization, io streams, spirit and output formatting. I see them a more complementary. Of course serialization uses streams so might work with io streams library. Serialization uses spirit to implement xml archives and it is possible someone might want to make an "annotated" archive and so want to exploit output formatting facilities. But in general these are orthogonal functions that can be composed at will. So I would be careful about making the output formatter library bigger. Bigger isn't necessarily better. I think its better if it focuses on doing one thing better than any other library does it and presents a minimal interface so that can be easily composed with related but different concepts. Robert Ramey

1 0

[static_assert] Regression with gcc 3.4.2?
by David B. Held 18 Sep '04

18 Sep '04

#include <boost/static_assert.hpp> template <typename T> struct foo { void bar(void) { BOOST_STATIC_ASSERT(false); } }; int main(void) { } --------------------------------------------------------------------- toot.cpp: In member function `void foo<T>::bar()': toot.cpp:8: error: invalid application of `sizeof' to incomplete type `boost::STATIC_ASSERTION_FAILURE< false>' --------------------------------------------------------------------- Is gcc wrong, or am I missing something really obvious? This used to work. And yes, I have the latest boost CVS snapshot. Dave

2 4

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