- Boost - lists.boost.org

old regression results question
by Reece Dunn 19 Sep '04

19 Sep '04

On the regression summary page (http://www.meta-comm.com/engineering/boost-regression/developer/summary.html) there are several instances where a toolset is duplicated (win32+cw-8.3, win32+vcX.X). I was wondering if it was possible to display only the most recent results for the toolset in that instance. This would help to see where the regressions are and shorten the width of the table. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

3 3

Re: [boost] Where are they now? (needed license permissions)
by JOAQUIN LOPEZ MU?Z 19 Sep '04

19 Sep '04

----- Mensaje original ----- De: John Maddock <john(a)johnmaddock.co.uk> Fecha: Jueves, Septiembre 16, 2004 2:20 pm Asunto: [boost] Where are they now? (needed license permissions) > Here are the people we still need to contact, in order to move the > rest of > Boost over to the BSL, if anyone has a more up to date email > address for > these folks than the ones shown here, please let me know, as at > present > they're not responding :-( > > Joaquín M López Muñoz joaquin(a)tid.es Hi John, this is Joaquín. I'm afraid my name appears in the list due to the occurrence of the SGI text in some of my files which are, otherwise, under the BSL license. This thread will probably refresh your mind, as we already discussed the issue: http://lists.boost.org/MailArchives/boost/msg69520.php I case you still need my permission in the blanket tile (which I don't think it's the case) please tell me so. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

stlport.jam patch
by Aleksey Gurtovoy 19 Sep '04

19 Sep '04

I just commited the following patch to "stlport.jam": =================================================================== RCS file: /cvsroot/boost/boost/tools/build/v1/stlport.jam,v retrieving revision 1.7 diff -r1.7 stlport.jam 103,104c103,106 < flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug : $(STLPORT_LIB_BASE_NAME)_stldebug ; < flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release : $(STLPORT_LIB_BASE_NAME) ; --- > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)_stldebug_static ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)_stldebug ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)_static ; > flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; That should take care of a number of failures with all STLPort-based toolsets; for instance, like this one -- http://tinyurl.com/5djsj. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

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