July 2004 - Boost - lists.boost.org

Re:[boost] Serialization Menu
by Robert Ramey 15 Jul '04

15 Jul '04

This is an interesting question. It seems I spend half my time bouncing back and forth between boost documentation pages. When this started to happen with my own boost serialization documentation I added a navigation frame with with a static index which would let be jump right to the part that I was interested in. Eventually as I added more pages to the documentation, the scrolling started to annoy me and I implemented the current scheme. I was inspired by the boost pre-processor documentation and I don't remember whether or not I was aware of the "kind of policy" against. I've been very, very pleased with the utility of the result. I made it and checked with both IE and netscape. I haven't checked with other browsers but have no received no reports that it doesn't work. I love this system. I think it should be adopted for all boost documentation. In this way I have a collapsible navigation pane which would let me navigate all of boost rather than just the serialization library. There are a couple of issues a) I had to make it "by hand" for the serialization library. OK for a prototype - but unsatisfactory in general. Ideally it should be generated automagically by Boost.Book. After all it's just an index which I would presume Boost.Book should be generating anyway. I haven't studied boost book so I don't really know anything about it. But if it doesn't include something like this I would consider it a glaring oversight. b) I believe that with a little effort the browser portability issues could be addressed. Basically there could be two index pages - a dynamic as well as a static one. All the "documentation pages" would be unchanged. I didn't really go into this because no one seemed to have a problem with the dynamic one. Of course the above doesn't raise the key issue that Dave raises. Should it be removed now? Should it be replaced with anything? - if so what? I would prefer to leave as it is. A final point regarding boost book. When I go to the main boost page and select nightly CVS I get a page which seems to have the look/feel that of the pages the boost.book is going to produce. I don't want to start a religious argument about aesthetics, but... I prefer the previous look and feel which was supported by the original documentation guidelines. Its just one man's opinion. Dave Abrahams wrote: >We have a kind of policy against using scripting in our library doc >pages, mostly because in the past scripts have caused major >portability or usability problems. I personally love the menu on the >left of the serialization lib docs page, but if it uses scripts and we >can't really be assured that they'll work everywhere, it probably >ought to be removed. >There are alternatives that might actually be more usable: >http://article.gmane.org/gmane.comp.lib.boost.documentation/389

3 2

Re:Re: [boost] serialization test failure on darwin
by Robert Ramey 15 Jul '04

15 Jul '04

Marshall Clow wrote: >So, I moved it so that it is only set when building on GCC 2.95.x. >Index: boost/boost/config/platform/macos.hpp >=================================================================== >RCS file: /cvsroot/boost/boost/boost/config/platform/macos.hpp,v >retrieving revision 1.13 >diff -r1.13 macos.hpp >19d18 >< # define BOOST_NO_CWCHAR >41a41,42 >> # define BOOST_NO_CWCHAR >> >This did not break any other tests, and made some (many) of the >serialization tests pass. There are still many failures, which I am still >investigating. >Could someone vet this change, and commit it to CVS? Thanks! When I look at this I conclude that define BOOST_NO_CWCHAR ( and BOOST_NO_CWTYPE) should just be removed from this file. Its not clear to me why its there. The MacOS compiled with GCC includes the file library configuration file that sets/doesn't set these macros according to the platform. And the gcc version isn't enough to do it right. E.G. Cygwin gcc doesn't support wchar_t etc even though its version 3.3. I would like to a) hear from someone who knows why that code was put in there in the first place. b) take it out and run the tests. If b) looks ok and we don't hear from anyone shortly, then I'll make the change in CVS. Robert Ramey

1 0

RE: [boost] BOOST_PP_REPEAT with internal macro problem
by Yossi.Itzkovich＠ecitele.com 15 Jul '04

15 Jul '04

Thanks all for your fast (and good) answers. Yossi "Paul Mensonides" <pmenso57@comcast. To: <boost(a)lists.boost.org> net> cc: Sent by: Subject: RE: [boost] BOOST_PP_REPEAT with internal macro problem boost-bounces@list s.boost.org 07/15/2004 07:00 Please respond to boost > -----Original Message----- > [mailto:boost-bounces@lists.boost.org] On Behalf Of > BOOST_PP_REPEAT works great for me when used like: > > #define MAX 5 > #define CODE my_code_goes_here > BOOST_PP_REPEAT(MAX, CODE, ) ^^ Passing nothing as a macro argument is undefined in C++. You should use a dummie argument instead--preferably not an identifier. I usually use ~ or ?. > > But it gets confused when used like: > > #define MAX (4+1) Arkadiy is correct. The library cannot understand the expression (4+1). It can only understand unadorned integer literals (such as 1, 2, 3, etc.) from 0 to 256. If you need to do arithmetic, you have to use the arithmetic primitives of the library, such as BOOST_PP_ADD or, in this case, BOOST_PP_INC (which is more efficient). Thus, if you want to do a repetition of MAX + 1, you need to say: BOOST_PP_REPEAT(BOOST_PP_INC(MAX), CODE, ~) Regards, Paul Mensonides _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

BOOST_PP_REPEAT with internal macro problem
by Yossi.Itzkovich＠ecitele.com 15 Jul '04

15 Jul '04

Hi, BOOST_PP_REPEAT works great for me when used like: #define MAX 5 #define CODE my_code_goes_here BOOST_PP_REPEAT(MAX, CODE, ) But it gets confused when used like: #define MAX (4+1) Is ther a work around ? I even tried: #define MAX (4+1) const int myMax=MAX; BOOST_PP_REPEAT(myMax, CODE , ) but still no luck. Any help ? Thanks Yossi

4 3

Serialization needs a redirect
by David Abrahams 15 Jul '04

15 Jul '04

Someone needs to add libs/serialization/index.html that redirects to the library's front page. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

serialization test failure on darwin
by Robert Ramey 15 Jul '04

15 Jul '04

In reviewing the failure of the serialization library build on Darwin - it seems that none of the include file can be found. This sounds like some sort of Jamfile or build setup issue. Can anyone give me any insight here? Robert Ramey

5 6

Re: numeric_cast
by John Kalucki 15 Jul '04

15 Jul '04

On Tuesday, April 20th, Fernando Cacciola wrote: >Indeed. The accepted numeric conversions library handles this case properly >(throwing). >Right now I'm technically on vacation until next Monday. I'll start working >with the review comments right next week. I'll check it in on CVS after I >made the neccesary changes. > >Anyway, users can download the review version from here: > >http://personales.ciudad.com.ar/fernando_cacciola/numeric_conversions.zip > >or > >http://groups.yahoo.com/group/boost/files/numeric_conversions.zip > > >Fernando Cacciola >SciSoft Is this fix in a released version of Boost? If so, which version? -John Kalucki

1 0

erroneous use of BOOST_STATIC_CONSTANT ?
by Toon Knapen 15 Jul '04

15 Jul '04

When using BOOST_STATIC_CONSTANT, the member still need to be _defined_ in a .cpp file (IIUC 9.4.2 par 4 of the standard), unless the enum-trick is used, right? However gcc, intel-linux and the mipspro compiler (and probably others) do not require a seperate definition. OTOH IBM/VisualAge does really _need_ the definition (otherwise the symbols are undefined when linking). Would'nt it be better to advise library-developers to use an enum instead of BOOST_STATIC_CONSTANT if their library does not contain a definition? toon

5 15

Re:Re: [boost] serialization test failure on darwin
by Robert Ramey 15 Jul '04

15 Jul '04

> Ok, I've completed that, and the test results are (more or less) the same. > The error messages are different, though. > Suggestions? Relax - your test setup is fine. The library fails to build so all the tests are marked as faile. Its my problem now. I'll be making a couple of small changes and we can try again. Robert Ramey

1 0

Re: [boost] Re: Suggestion for iterator_adaptor
by JOAQUIN LOPEZ MU?Z 14 Jul '04

14 Jul '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> [...] > I'm soliciting suggestions for the name of the member. All names with > suffixes like "_t" will be rejected, and be aware that base is > already taken for other purposes. Currently my thoughts are > > super // super > crtp // ugly > I'd vote for super, which has an established reputation in Java. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0