- Boost - lists.boost.org

boost::function question
by Balasubramanyam, Shivakumar 06 Aug '07

06 Aug '07

Hi, I would be like to know how you can bind a member function that has a overloaded arguments. For example. Class X; Class Y; Class A{ Line1: Void Func(X x); Line2: Func(Y y); } Any ideas? Thanks, Shiva

2 1

Re: [boost] Release Tools Analysis Part I: Build systems
by David Abrahams 06 Aug '07

06 Aug '07

on Sun Aug 05 2007, Stefan Seefeld <seefeld-AT-sympatico.ca> wrote: > FWIW, I submitted a patch to SCons providing a python extension > module around ucpp (http://pornin.nerim.net/ucpp/) to provide a > 'more accurate' C/C++ dependency scanner, long before wave was around. Does anyone know if ucpp is actually conforming? Until very recently, most preprocessors were badly broken (and maybe most still are). If it conforms, it would be interesting to benchmark it against Wave. > Steven refused that, believing that it could (and should) all be done > in pure python. Well, with a great deal of due respect to Steven, he's wrong. Sure it /can/ be done in pure python, but /should/ it be? Before we had insane C++ template metaprograms, the cost of preprocessing and lexing typically swamped that of any other C/C++ compilation phase, just because they had to deal with more data (individual characters). And now we have insane preprocessor metaprograms, so things have not gotten any easier on the C/C++ preprocessor. > That was many years ago, and the situation hasn't substantially > changed since then. Sounds familiar. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com

4 9

Organization idea: separate libraries in our SVN
by Daryle Walker 06 Aug '07

06 Aug '07

[I thought I wrote a message similar to this a few years ago, but I can't seem to find it on GMane. Anyway, this is a good time to re-introduce it since Subversion allows directory manipulations.] The current layout of the Boost material in our SCM system is the same as the final archives. That does not necessarily have to be the case. Since we put emphasis on distinct libraries within Boost as far as maintenance is concerned, maybe we should enforce in the SCM layout. You know how, when we look at a potential library, the library is in an archived folder with sub-folders mirroring the files' places in the final layout. The trial library would have its own root "boost" and "libs" (and any other) sub-directories. I suggest that all the current libraries be set up like that, in a common directory holding all the libraries. This common directory would be the trunk. At release time, the contents of each library's directory are merged into a release directory. If only one library directory has a particular file object, it's copied as-is. If multiple libraries have a commonly-named file object, we have an error if at least one of them is a file. Otherwise, the commonly-named directories are merged using this algorithm recursively. (A particular leaf file should only be part of one library.) So the new trunk would be like: * trunk/ ** General/ ** any/ ... ** crc/ ... ** filesystem/ ... ** math-quaterion/ ** math-common_factor/ ... ** quickbook/ ... ** utility-general/ ** utility-enable_if/ ... ** wave/ ** wave-tool/ ... Note that the tools get parallel library directories. The "General" folder holds our license, logos, and any other non-library common files. Libraries of the same category don't have to have distinctive namespaces (and sub-folders of the boost/ header directory); they can be merged in the final product, but maintained separately in the SCM system. (The existing I/O, math, and numeric namespaces/directories are sort of like this, but now we can refine them further, and do stuff like put all the Boost container classes under one sub-namespace/directory.) While the final users get a merged archive, Boost developers would have to include each library's header separately in their compiler options. This could be useful because it will tell us about each library's dependencies on other Boost libraries. I think Subversion has some sort of symbolic-file-link support. Maybe with that, we could create a directory parallel to the trunk that represents an already merged archive. (It would have to be read-only, of course.) It could be updated with a commit script watching the trunk directory. * master-level/ ** trunk/ ** synthetic-archive/ <- read-only; maybe at separate website ** branches/ ** tags/ Something I like about this system is that it lets me know exactly how many libraries we have. (There's so many and it's hard to keep track sometimes.) Furthermore, now that libraries can be safely enumerated enables all sorts of automatic processing. Using SVN properties on each library's folders, and various sub-objects, would enhance said processing. (I think that properties and their changes generally can be version-controlled.) We could have the commit script make sure that the appropriate file objects have the properties we need. * The master list of libraries can be script-generated. Descriptions of each library and their original authors can be stored as SVN properties in each library's folder. * The current maintainers for each library can be stored as an SVN property. A regression suite that access SVN can then send notifications to the right people. (A master list of maintainers can also be generated for the final archive.) * There can be a property listing which sibling libraries a particular library (directly) depends on. This can be used by a script to isolate one library for extraction and take all it needs for the ride. An extraction can be in my separate library directories form or in a fused archive form. Furthermore, when actually built, you'll discover any missing sibling library dependencies. * Did you know that you can mix-and-match various revisions of items in the same directory? Exploiting this could reduce the need of branching in order to isolate breaking changes. Let's say that we start out at revision r25. The Filesystem library is changed and checked-in at r30. All the other libraries stay at r25 until an explicit update bumps everything to r30. (Subversion's commits do _not_ sneak in an update to uninvolved file objects.) Unknowingly, r27 introduced a bug in the CRC library which breaks Filesystem. The Filesystem maintainer could temporarily lock his/her copy of the CRC library folder to r26 until the bug is fixed! Taken to the extreme, the release manager can check out the copy of the trunk's HEAD, back-step any libraries as necessary to their individual last-known-good(-enough) revision, and then run the merge script for the release's archive. * For each library's documentation directory, the directory could have a property describing the primary file. Each documentation file could have a property describing build directions, if needed. * For each library's testing directory, each test file could have a property describing which kind of test (compile, compile-fail, run, run-fail, etc.) it is. Jamfiles don't necessarily have to be included; they could be synthesized from the properties while the merge script builds an archive. And if we move to a different build system than Jam, then the properties could be used for the new system. * For the mandatory source files, a property could be added for distinct execution closures. As far as I know, this property wouldn't be needed except for three files in Boost.Test. Those files each include a "main" function, and so can't be mixed with each other or all other mandatory source. Each one of those files could have a distinct execution closure tag, which puts it in a separate "src" subdirectory, while all the other mandatory source files leave that property blank and all go into a main "src" subdirectory when merged. (I know we don't keep a root-level "src" directory; but with SCM separation of libraries and a merge script, we can!) Any special compilation directions could be placed in a property to be transfered to a Jamfile (or successor) for our build system. (Obviously this isn't 100% recommended since a user could use his/her own IDE to compile a source file and miss the property's directions.) There is a _one-time_ cost to separate each library/tool from the existing merged archive to distinct directories. That might take a while, but advantages of a separated system should be worth it. (It can be done in piecemeal; keep everything in the "General" directory and separate the libraries/tools out one at a time. We should probably do the leaf libraries [0 sibling dependencies] first. Actually, we should start with Boost.Config; it should have low dependencies, but a lot of other libraries depend on it.) I've heard that Windows, when moving the contents of one directory into another, will (recursively?) merge the contents of commonly-named directories. If that's accurate, then a Windows user could temporarily be a release manager until the merge script is made. I don't really know how to script, but hopefully a merge would be simple enough to write that the Windows-user workaround wouldn't be needed. (Macs use overwrite semantics, being consistent in not distinguishing between file objects based on the source's and destination's is-directory flags.) I know that there's a lot of automation. But, if it's possible to do this plan, we'll be working smarter, not harder, for maintenance and releases. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

SVN commit and inspection checks?
by John Maddock 05 Aug '07

05 Aug '07

Just wondering, but can we set up the SVN commit script to verify the file with our inspect program before a commit is allowed? No doubt folks will be greatly annoyed by this at first, but at least we should gradually get those inspection-failures fixed that way :-) John.

6 5

new proposal: boost-config
by Domenico Andreoli 05 Aug '07

05 Aug '07

Hi, Suppose two systems, a Fedora based on gcc 4.1 and a Debian based on gcc 4.2, both sporting Boost 1.35.0 built with --layout=system, for simplicity. Now Joe User writes his app on the Fedora system and links Boost.DateTime using the familiar -lboost_date_time switch. He builds the app and tries it on both his Fedora system and the friend's Debian one. What is going to happen? BTW, the user is a free software developer and his app is going to be ported also to other Microsoft, UNIX and popular embedded operating systems, where Boost has been built mixing --layout=system and --layout=versioned. Now he faces the problem of linking to the Boost library of interest. How he is supposed to solve the problem? This is a new summary of the binary and source portability problems that current build system is inflicting on the Boost libraries. My proposal is: 1) dump the --layout= thing, versioned/decorated sonames are always used 2) provide symlinks like the following, when appropriate: /usr/lib/libboost_date_time-gcc42-1_34_1.so -> libboost_date_time-gcc42-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-d-1_34_1.so -> libboost_date_time-gcc42-d-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-mt-1_34_1.so -> libboost_date_time-gcc42-mt-1_34_1.so.1.34.1 /usr/lib/libboost_date_time-gcc42-mt-d-1_34_1.so -> libboost_date_time-gcc42-mt-d-1_34_1.so.1.34.1 3) provide also these symlinks, if desired: /usr/lib/libboost_date_time.so -> libboost_date_time-gcc42-1_34_1.so /usr/lib/libboost_date_time-d.so -> libboost_date_time-gcc42-d-1_34_1.so /usr/lib/libboost_date_time-mt.so -> libboost_date_time-gcc42-mt-1_34_1.so /usr/lib/libboost_date_time-mt-d.so -> libboost_date_time-gcc42-mt-d-1_34_1.so 4) add more decorations as required. e.g. Python version to Boost.Python library name. This way multiple Boost.Python libraries, every built with a different Python version, could coexist on the same system. 5) provide a program, say boost-config, that may be invoked to find the right build parameters for a given library, toolset and variant(s). some examples (suppose default compiler is gcc 4.0, the one used to build Boost): $ boost-config --name=DateTime --ldflags -lboost_date_time-gcc40-1_34_1 $ boost-config --name=DateTime --toolset=gcc-4.1 --variant=mt,d --ldflags -lboost_date_time-gcc41-mt-d-1_34_1 $ boost-config --name=Threads --toolset=gcc-4.2 --ldflags -lboost_threads-gcc42-mt-1_34_1 $ boost-config --name=DateTime --toolset=gcc-4.2 --variant=python-2.5 --ldflags Error: unknown variant python-2.5 for the given library $ boost-config --name=Python --variant=python-2.4 --ldflags -lboost_python-gcc40-python24-1_34_1 $ boost-config --name=Python --toolset=gcc-4.2 --variant=python --cxxflags -I/usr/include/python if toolset is omitted, the default system compiler is used, if any (e.g. cc/c++ under linux), otherwise an error is reported. Point 1) is really optional. In case --layout is kept, the subsequent points would be related only to --layout=versioned and --layout=system should be documented as source of any sort of portability issues. Point 2) is required only on UNIX systems where GNU ld is used, it might have not sense with other linkers. Every linker has its own story. Point 3) is applicable only where 2) is and would be handy only when source portability is not an issue, to the user discretion. Big warning about source portability should be placed nearby its documentation. Point 4) would allow packaging Boost.Python on distributions in which multiple versions of Python may be available. Point 5) is the way to the complete source portability, at least across sane systems (read, probably not Windows/MSVC). Note that if Boost is built using a compiler different from the one asked to boost-config, the linker will complain about the inexistent library. It would be easy to make boost-config extract allowed parameter combinations from an XML file built by Boost.Build at build time. That's all, good night. Domenico -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

5 9

1.34.1 PDF docs
by Vladimir Prus 05 Aug '07

05 Aug '07

Over at https://sourceforge.net/project/showfiles.php?group_id=7586&package_id=1597… I see PDF docs for 1.33.1, but not for 1.34.*? Is this omission intentional? - Volodya

1 0

interest in a stats library?
by Chris Fairles 04 Aug '07

04 Aug '07

I'm wondering if anyone has started a statistical analysis library at all? Something I might be interesting in starting if not. It could include features such as: sample mean, alpha-trimmed mean, weighted-mean, geometric-mean, harmonic-mean, mode, median, midrange. mean deviation, sample std deviation, RMS, sample range, interquartile range higher order sample moments maximum likelihood estimators (and other estimators for various distributions), confidence intervals, hypothesis testing linear regression, ANOVA even Any interested in such a lib? (i think i saw a probability lib somewhere, it could build on that as well). Chris

4 4

Testing tools location.
by Rene Rivera 04 Aug '07

04 Aug '07

NOTE: This is not question about the whole testing & release management stuff on that /other/ thread. Since I'm going to be mucking about with Buildbot this weekend I'm wondering about where to put things in the SVN repo. Instead of continuing to shove stuff into the boost-root/tools tree, I'd rather move some of the testing infrastructure tools onto their own tree as we did with the beta web site. The goal, as with the web site, is to make it easier to develop without getting in the way of the release content. In particular because like the web site, testing doesn't follow the same release schedule as the libraries. The obvious location I have in mind is a top level testing dir, with subdirs as needed: svn/testing svn/testing/buildbot svn/testing/reports ... Thoughts? ...I'll assume this is OK after a short time. And move stuff around/back if people object. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 3

[x-files] the code's out there...
by Tobias Schwinger 03 Aug '07

03 Aug '07

Dear fellow Boosters, There is lots of useful, Boost-worthy utility code out there: Implementation details of existing / upcoming / (maybe even) proposed and rejected libraries that could stand alone, code on private hard disks never brought up for review, additions to existing libraries, etc. Fact is, that for small submissions the administrative overhead of (even) a formal (fast-track) review can be too high for developers' decency. Just imagine someone allocating five fast-track slots at once just for factoring out some unrelated bits of code from an existing library. So, why not group a bunch of unrelated utilities into a set of "Boost X-Files" and have them reviewed as a single library? It's completely non-intrusive to the review process and could seriously increase its efficiency. Like the idea? As a start, I stuffed my (tested and documented) "Boost candidate bits and pieces" into a common directory in the vault: http://tinyurl.com/35vlvb Feedback and more X-files welcome, of course. Regards, Tobias

3 6

Improving --layout=system
by Caleb Epstein 03 Aug '07

03 Aug '07

I sent this to the boost-build list, but I think it should have been CC'ed to this list as well. I'd like to commit this change to the SVN trunk if there are no objections. I think its a big win for anyone who uses --layout=system. This is the way BBv1 (correctly IMHO) handled --layout=system. ---------- Forwarded message ---------- From: Caleb Epstein <caleb.epstein(a)gmail.com> Date: Aug 2, 2007 2:23 PM Subject: Improving --layout=system To: "Boost.Build developer's and user's list" <boost-build(a)lists.boost.org> On systems that support shared library version numbers, I believe that these should be used even when building with --layout=system. At present, when you build Boost with --layout=system, you end up with libraries called libboost_xyz-mt.so that have this same value set at their ELF SONAME (this is the shared library version number embedded into the library itself). The problem with these libraries is that you can never have multiple versions of them installed side-by-side in the same place. Go too far down this road and you end up with Windows-style 'DLL hell'. If instead the BOOST_VERSION is appended to the target name as it is with --layout=versioned, you end up with SONAME'd libraries that can live side-by-side with earlier/later versions of Boost. For example, by adding the version number to the libraries, you end up with a lib directory that looks like: lrwxrwxrwx 1 cepstein 33 Aug 2 13:44 libboost_date_time-mt-d.so -> libboost_date_time-mt-d.so.1.35.0 -rwxrwxr-x 1 cepstein 388K Aug 2 13:44 libboost_date_time-mt-d.so.1.35.0 lrwxrwxrwx 1 cepstein 31 Aug 2 13:44 libboost_date_time-mt.so -> libboost_date_time-mt.so.1.35.0 -rwxrwxr-x 1 cepstein 52K Aug 2 13:44 libboost_date_time-mt.so.1.35.0 ... Now when you link applications using -lboost_date_time-mt, the linker records the dependency on the library's SONAME, which is libboost_date_time_mt.so.1.35.0. No other name will satisfy this runtime dependency. As a result, you can install the (hypothetical) Boost 1.36.0libs into the same directory and old applications will continue to pick up the *.so.1.35.0 libs correctly, while new applications built when the symlink points to the new library versions will pick up *.so.1.36.0. This is how Boost.Build v1 handled --layout=system and I believe this is the most correct and desirable behavior for platforms that support versioned shared libraries. Attached is my simple patch against the latest SVN trunk to make this work. -- Caleb Epstein

1 0