August 2004 - Boost - lists.preview.boost.org

License
by Andrei Alexandrescu (See Website for Email) 12 Aug '04

12 Aug '04

I give permission for all my contributions to Boost to be moved to the Boost Software License Version 1. (Not sure what those contributions are, but I got that email.) Way to go boost! Andrei

1 0

Re:[boost] Re: serialization and cwpro status
by Robert Ramey 12 Aug '04

12 Aug '04

David Abrahams wrote: >Are you really testing CW 7.x? Hmm - I thought I was. Actually I'm not doing the testing. I'm just relying on the table of test results which refers to compiler "CW" So I don't really know what version it is. CWPro9 fails export and wide char tests on my machine when built for debug and CWPro8 fails tests on Rene's machine and he builds for release. So I just assumed the CW referred to some previous version. Since it was passing I never had to find out what it really was. >If you really count on the result of is_convertible being true when >it should be, then no, you don't have enough tests. >FWIW, I dropped CW 7.x support in Boost.Python and the iterators >library when CW 9 came out and have not received a single complaint. >I think VC6 is arguably the only 2-version-old compiler that might >warrant continued support. I never set out to make CW pass. It just did. I have spent time with CWPro as Rene expressed an interest and has been willing to help. The same goes for Borland where Pavel Vozenilek invested most of the effort. I wouldn't have done either of these were it not for this. I should say they did take a lot more effort than I originally anticipated - but then that applies to just about everything I do. Generally, I would agree that it makes no sense to spend effort to accommodate a compiler for which an upgrade is available. I wonder if having them in our test matrix creates a subtle pressure on developers to do the otherwise un-necessary work. It sort of plays on the obsessive aspect of the typical software developer personality. Robert Ramey

3 3

Traits question
by Malcolm Smith 12 Aug '04

12 Aug '04

Hi everyone, Can someone either assist me or point me to a relevant site / newsgroup to post this question. I want to determine if traits can be used to choose a container type at compile time based on the nature of hierarchial data to be stored. By this I mean: * Is the data in a 1:1 or 1:Many relationship ? * Can there be more than one item in the container ? * Are the contained items be unique or not ? These questions help decide which container to use such as std::deque, std::map or even std::pair. I have tried to give an example below for a typical usage in my work which occurs all the time (for creating config files). *** I'm new to all this, so don't yell if I'm writing absolute garbage below *** Example: Imagine data to be stored in a hierarchy fashion given the information: (i) IP Address = Site ID ( 1 : 1 ). There are many (unique) items to be stored. (ii) Site ID has a collection of mapped items ( Code1 = Code2 ) where Code1 is unique Such as: 192.168.0.1 = ID1 192.168.0.2 = ID2 192.168.0.3 = ID3 For ID1 the linked information might be something like ABCD = 1234 EFGH = 5678 For ID2 the linked information might be something like IJKL = 1010 MNOP = 2020 For ID3, the data might be the same as for ID1 ABCD = 1234 EFGH = 5678 From (i) std::map< IP, ID > can be used. From (ii) std::pair< ID, std::map< Code1, Code2 > > can be used. Which can be combined into std::map< IP, std::pair< ID, std::map< Code1, Code2 > > > So, is it possible using traits (or something else) to determine which container to use and the appropriate nesting of objects. I'm reading "Modern C++ Design" for the second time.....but that's the limit of my experience with this type of development. Thanks in advance for any suggestions. Malcolm Smith MJ Freelancing http://www.mjfreelancing.com Borland Technology Partner --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.736 / Virus Database: 490 - Release Date: 09/08/2004

1 0

Intel 8.1 and Unit test suite?
by John Maddock 12 Aug '04

12 Aug '04

All the tests that use the Unit Test Suite fail with the Intel 8.1 Beta compiler, has anyone seen and/or reported this to Intel already, or have any ideas what's going on? Typical errors are: Exception in "test_conversion_to_char": memory access violation c:/data/boost/develop/boost/libs/test/src/unit_test_suite.cpp(127): fatal error in "test_conversion_to_char": Test case initialization has failed The access violation appears to be a vtable lookup problem, but I'd like to be sure it's not a boost problem before reporting it. Thanks, John.

2 2

boost-build and version numbering
by Russell Hind 12 Aug '04

12 Aug '04

Given boost uses version numbers x.y.z such as 1.30.2 1.31.0 The build system generated libs and stuff with -1_31 appended. I have a few questions about this: How is this generated? We wish to build our own version of boost (based on one of the above releases, but with patches) so wanted to version it accordingly. The obvious way would be for us to version it 1.31.0.1 so it is differentiated from the official 1.31 release. Unfortunately, boost only appears to support the x.y.z format. So we could number it 1.31.1 and hope boost doesn't release a 1.31.1. But I've edited boost/version.hpp to be 103101 and 1_31_1 and also the jamrules file to be 1.31.1 but the build-generated libs are still only post-fixed with -1_31. Where does the bulid system pick up the version number so I can modify it for the build and would it be easy to modify it to support w.x.y.z format so we don't run a risk of coliding with boost versions? Thanks Russell

2 2

install messed up?
by Victor A. Wagner Jr. 12 Aug '04

12 Aug '04

I'm reasonably sure that the install shouldn't copy two _different_ files to the same place/name I'm guessing that one of those shouldn't have the -mt- in the name ================================================================================================= Creating library bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\threading-multi\boost_date_time-vc71-mt-gd-1_32.lib and object bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\threading-multi\boost_date_time-vc71-mt-gd-1_32.exp FileClone C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.dll copy "bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\boost_date_time-vc71-mt-gd-1_32.dll" "C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.dll" >NUL: FileClone C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.dll copy "bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\threading-multi\boost_date_time-vc71-mt-gd-1_32.dll" "C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.dll" >NUL: FileClone C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.lib copy "bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\boost_date_time-vc71-mt-gd-1_32.lib" "C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.lib" >NUL: FileClone C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.lib copy "bin\boost\libs\date_time\build\boost_date_time.dll\vc7.1\debug\threading-multi\boost_date_time-vc71-mt-gd-1_32.lib" "C:\Boost\lib\boost_date_time-vc71-mt-gd-1_32.lib" >NUL: ====================================================================================================== I expect a lot of things are going to fail if my system ever gets around to actually running the tests Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 3

[thread] wrong name of the thread lib and dll.
by Sven Johannsen 12 Aug '04

12 Aug '04

Hi, when you compile the current boost with the following cmd-line the thread-lib has a wrong filename: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_PATH=D:\Develop" "-sSTLPORT_VERSION=4.5.3" this cmd-should generate "gdpn" files like: boost_thread-vc6-mt-gdpn-1_31.dll but it generate a "gdp" (without "n") file. the "n" stands for native iostreams. (boost_thread-vc6-mt-gdp-1_31.lib) the lib behave like "gdpn"-file, but i have to rename the lib. otherwise i get the following linker error: LINK : fatal error LNK1104: cannot open file "boost_thread-vc6-mt-gdpn-1_31.lib" who can modifier the jam-file. (i don't speak jam) Sven

3 5

[graph] GIF files not marked as binary in CVS.
by Rene Rivera 12 Aug '04

12 Aug '04

In this recent update: U libs/graph/doc/figs/betweenness_centrality.gif U libs/graph/doc/figs/central_point_dominance.gif U libs/graph/doc/figs/relative_betweenness_centrality.gif U libs/graph/doc/figs/sigma_st.gif U libs/graph/doc/figs/sigma_stv.gif U libs/graph/doc/figs/v_star.gif U libs/graph/doc/figs/wheel_graph.gif Those files are not marked as binary in CVS. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

Re:[boost] Re: serialization and cwpro status
by Robert Ramey 11 Aug '04

11 Aug '04

David Abrahams wrote: "Robert Ramey" <ramey(a)rrsd.com> writes: >> Now that I do, I'm strongly convinced that >> it's a really bad idea. >Give it a chance to sink in. Looks like I don't have much choice. > It's a good idea even if you ignore > export because it reduces the chance that a template's meaning will > change based on definitions that follow it, allows syntax checking > before instantiation, and adds rigor. That's the problem with it in my view. Before, I could keep things in my head by extending the "macro" concept to include types. Now I can't. Now the meaning of something depends upon the order it is included in the program - an incredibly subtle side-effect. Worse, the meaning of a template now can vary quite a bit depending upon the argument used to instantiate it. The whole thing reminds me of trying to write a memo with Microsoft word. It constantly "helps you out" without telling you so you can't really see what's going on without keeping the whole global environment in your head. So it diminishes transparency, verifiability, and opportunity to enforce rigor in coding requires increased dependence on testing to gain confidence on program correctness. Sorry, I know we're going off topic, but I couldn't let the above pass without comment. >> CW < 8 >> >> I believe that these versions will pass 100 % >I wouldn't count on it. CW 7.x couldn't handle the "sizeof() trick", >so *lots* of basic TMP things (like is_convertible) fail there. Of >course, maybe you're sure that none of these things are used...? Good thing you didn't tell me that before - its now passing 100% It feels like I've used everything in mpl (of course I didn't - it just feels like I did). I use is_convertible in many places as well as just about all the type_traits. On the other hand, maybe its just that I don't have enough tests to make it fail. Robert Ramey

3 2

Re:[boost] Re: question re VC 8.0
by Robert Ramey 11 Aug '04

11 Aug '04

Joaquin M Lopez Munoz wrote: > Looks like VC 8.0 does not handle member *qualified* template friends. > The solution I applied is to simply extend the defect macro > BOOST_NO_MEMBER_TEMPLATE_FRIENDS to VC 8.0 (by using a local version of > the macro, namely BOOST_MULTI_INDEX_NO_MEMBER_TEMPLATE_FRIENDS), until > this issue is officially resolved in Boost.Config. Can we not just resolve this issue "officially" right now by amending config/compiler/visualc.hpp ? What is the value of _MSC_VER with VC 8.0 ? Robert Ramey

3 2