- Boost - lists.preview.boost.org

boost::random uniform_int bias and speed
by Samuel Krempp 23 Aug '04

23 Aug '04

Looking inside boost::random, I noticed a few things that I think could be better, and since I could not find mentions about those in the lists's archive, I'll ask here. 1. the case : brange / _range <= 4 Is implemented by rejection, directly. But the average number of rejects could be decreased (by a factor up to 4) by rescaling before rejection. i.e. (pseudo code) : .k = (brange+1) / (_range+1) .rejection_thresh = k * (_range+1) .keep generating random number until result < rejection_thresh .return result/k; the probabilty of a reject is then less than _range/brange, and also always less than 1/2, and can reach 0 (if (brange+1) is a multiple of (_range+1)) Was this possible speedup considered useless ? 2. the case brange / _range > 4 since direct rejection could mean very very many retries in this case, this case is dealt with uniform_smallint (which always uses exactly one number generation). But by using previous rejection scheme, there is no need for this case since the average number of needed number generations will be fairly close to 1, and the generator's speed will be equivalent to uniform_smallint. Plus, using a rejection scheme would completely avoid any added bias (contrary to uniform_smallint in which the added bias can reach 1/32, thus unsuitable for high-precision statistics programs) Why not use such a "rescaled" rejection scheme as I describe rather than uniform_smallint's possibly biased computation ? -- Samuel

1 2

RE: [boost] Java style GUI in C++
by Hurd, Matthew 23 Aug '04

23 Aug '04

> Behalf Of John Torjo > > Some rambling thoughts on things I'd like to see are: > > > > 1. run-time and compile-time configurability, especially with some like > > compile time specification language like layout capability. There was > > some talk about this and some suggestions previously on this list. > > Marrying this to run-time would be interesting. > > > > Perhaps at compile time you can decide if there is an explicit handling > > method and if not call something with your source and event type that > > will dispatch. However this would lock you in at run-time if did this > > as a compile time metaprogramming thing that ending up optimizing to a > > function call equivalent but perhaps both options are appropriate... > > that's more or less what win32gui does. > > And more to the point, when you extend a window class, you can add your > own handlers into the picture. > > Thus, you can end up with more event handlers for the same > event/command/notificiation. > > This is TOTALLY ok. > Whenever a handler for an event/command/notification gets called, it can > decide what to consider this event: > - event_not_handled: I consider this handler did not handle this event. > If more handlers exist, call them. If no more handlers, call default (in > our case, DefWindowProc) > > - event_is_handling. I did handle his event, but it's ok if other > handlers handle it too. So, if there are other handlers, call them too. > After all handlers are called, DO NOT call default (in our case, > DefWindowProc). > > - event_handled: I handled this event. DO NOT call other handlers, nor > the default( DefWindowProc). > > > I thinks this handles most (if not all) cases. Yep, in my mind it should be handled by the highest level event handler in the structural tree composite thingo that represents the ui layout. That event handler has the option to allow dispatch to the next lower level handler. I was thinking that you would attach event handlers for messages from sources to any place in the structural ui tree. It is handled by the highest handler in the structural tree or it is ignored if there is no handler. > > > > 2. reverse structural inheritance of events handler equivalents. > > Widgets are composed of other widgets. A window may handle the click, > > or prevent it, for a child. You can attach a handler for a named event > > at any point in the composition / structural hierarchy, it doesn't have > > to be the source, but is aware of it. Handling goes down the hierarchy > > to source. > > In fact, I think it should be quite reversed. > If a window cannot handle a command/notification, forward it to its > parent and so on - until someone handles it or reaches top. I think it should be the other way around, if I understand it. You need to be able to over-ride the behaviour of your components by interposing another handler. E.g. don't do the normal stock window click event do this instead (which may also continue the chain down...). More importantly, should be able to disable and enable all contained (child) messages. Doing so by category as someone else suggested would be nice... e.g. all drag drop, all mouse, etc... Goodluck, your lib sounds interesting. Matt. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

New design proposal for boost::filesystem
by Carlo Wood 23 Aug '04

23 Aug '04

I propose the following design. The aim of boost::filesystem should be to support the following coding idiom: * The programmer should take care to only handle two types of paths in his application: 1) Complete paths 2) Relative paths * The programmer will have to specifically tell the libary when a constructed path is 'native' and when not. A native path is accepted according to native rules and never gives any problem (exceptions) further on. A non-native path is checked according to the existing rules, which basically means that the programmer can set a default check routine that will in effect determine how portable the application will be. I propose two design changes: 1) 'native' is now not only a representation, but an *internal state* of fs::path. (this has no effect on the representation as returned by fs::path::string()). 2) All 'complete' paths are automatically marked as 'native'. Examples, the following code is legal: fs::path p1("C:\\foo\\a.exe", native); // As one might do on windows. fs::path p2("/usr/src/a.out, native); // As one might do on linux. std::cout << p1.native_file_string(); // ok, p1 is native. fs::path p3("foo/bar"); // Relative path, always succeeds. std::cout << p.string(); // ok std::cout << p.native_directory_string(); // Useless, but ok. fs::path p4(complete(p3)); // p4 is now "native", because now it is complete. std::cout << p4.native_directory_string(); // ok And the following will fail (assertion?): std::cout << p4.string() // Not allowed because p4 is native (complete). Since there would be a default way defined of how a relative path is completed, all operation functions will accept both, relative and complete paths. For example: fs::path p1("C:\\cygwin\\usr/bin/ls", native); // Legal path on Cygwin. if (fs::exists(p1)) // Ok, access complete path. // For clarification fs::path p2("C:\\cygwin\\usr"); // Just an example fs::default_working_directory(p2); // fictuous function. fs::path p3("bin/ls"); // Portable representation (refers in fact to "C:\cygwin\usr\bin\ls.exe"). if (fs::exists(p3)) // Ok : exists() will make the path complete before testing. And this throws: fs::path p4("/bin/ls"); // Not allowed: this path has a root but is not marked 'native'. Setting the default_working_directory shall allways need to be done for each supported OS seperately. Of course you can set it to "/" on single root machines, and set it to "E:/" after extracting the 'E:' from the current path at application start up, in effect simulating a 'single root': int main() { fs::default_working_directory(fs::current_path().root_path()); // ... simulate single root machine below. fs::path p("bin/ls"); } The average application will work with relative paths, relative to some (native) base directory and next to that have some arbitrary, complete and thus native directories (ie, read from environment variables). But in case more than one 'working' directory seems needed then we can add support for that too by allowing to construct paths with a reference to the (complete/native) working directory. Ie, fs::path homedir(g_getenv("HOME"), native); fs::path rcdir(homedir / "edragon/rc", native); fs::path tmpdir(current_path().root_path() / "tmp"); // ... fs::path runtime_rcfile(rcdir); // Set 'runtime_rcfile' to be relative to 'rcdir'. // ... runtime_rcfile = "config/runtimerc"; which is then relative to `rcdir' instead of a single, global 'working directory' (as now returned by fs::current_path()). Most of the current boost::filesystem API can be preserved with this design. -- Carlo Wood <carlo(a)alinoe.com>

10 26

Re: [boost] numeric-ublas errors with Comeau
by Michael Stevens 23 Aug '04

23 Aug '04

Hi Bronek, > "C:\Comeau\libcomo\concept_checks.h", line 423: error #349: no operator "!=" > matches these operands > operand types are: I agree with Comeau. The index_pair/triple helpers need and != to be Equity Comparable. Fixed and committed. Michael

1 0

re: [boost] numeric-ublas errors with Comeau
by Michael Stevens 23 Aug '04

23 Aug '04

Bronek Kozicki wrote: > All tests in numeric-ublas are failing in Comeau compiler. Most of these > errors can be fixed if we define BOOST_UBLAS_NO_CMATH in > boost/numeric/unblas/config.hpp for this compiler. Patch attached Sorry I missed the first posting. A case on mailing list overload. > Hello, is there maintainer of numberic-ublas? Certainly! Looking at patch simply defining NO_CMATH for all Comeau versions does not seem to be a good idea. The problem appears to be the old std::abs is not defined for built in types. I sure the problem will non exist for ever in the Comeau library. It could also be due to the --vc71 compatibility flag being set. Do you know what the current __LIBCOMO_VERSION__ is and if the problem still exists. Thanks, Michael

3 5

[tools.regression] performance patch
by Markus Schöpflin 23 Aug '04

23 Aug '04

On my platform (tru64cxx65) the appended patch speeds up process_jam_log by a factor of five(!). If the patch is ok, could anyone please apply it? TIA, Markus *** /vol1/tmp/boost/boost/tools/regression/process_jam_log.cpp Tue Aug 10 10:34:19 2004 --- process_jam_log.cpp Fri Aug 20 09:20:01 2004 *************** *** 50,55 **** --- 50,58 ---- || src.find( "cc1plus.exe: warning: as it has already been specified as a non-system directory" ) != string::npos ) return; + // on some platforms (e.g. tru64cxx) the following line is a real performance boost + target.reserve(src.size() * 2 + target.size()); + for ( string::size_type pos = 0; pos < src.size(); ++pos ) { if ( src[pos] == '<' ) target += "<";

2 3

numeric/ublas aix test failures
by Michael Stevens 23 Aug '04

23 Aug '04

Hallo Danial, > I am interested in using ublas for a large government project. > I noticed ublas (as of 8-19-2004) failed test3 on the visual age c++ compiler. > What does this test exercise? Test3 exercise the whole spectrum of sparse vector and matrix types with a variety of BLAS operations. These tests are by far the most demanding on the compiler. Unless > We have currently installed the 1.31 libraries. Is this the same code that > produced the test results? The the code the regression test use is take from the HEAD of Boost CVS. This code has been developed a great deal since Boost-1.31 The aim at the moment is to get maximum compiler compatibility. Bar an incorrect commit over the weekend and the recent noncopyable problems this is progressing well. I have cross posted this to the ublas-dev mailing list. This is the best place for uBLAS specific discussion as there are many active contributers. In particular you will find many people who also use Visual age C++ on large systems. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

Segfault at program exit using memory pools
by Thomas 22 Aug '04

22 Aug '04

Hi all, I'm running into a problem where I'm getting a segfault when my program exits when I use boost's memory pools. If I call purge_memory right before the end of the program, that also produces the segfault. Basically all I'm doing with the pools is calling ordered_malloc to allocate memory for arrays, and then free(myPointer,size_of_array) to de-allocate the memory. Oddly enough, when I run the code through valgrind, I don't get the segfault at all. I'm pretty sure that it's not bad memory or anything like that because none of the other programs I compile & run yields this kind of result. Any thoughts on what might be going wrong? Thanks Tom -- Thomas <hazard(a)imsa.edu>

1 0

Successfully compiled & static linked with Boost.Threads using Visual Studio .NET 2003
by David Barrett 22 Aug '04

22 Aug '04

Hi, I see a lot of people have been having problems statically-linking Boost.Threads with Visual Studio .NET 2003. For what it's worth, I just got it to work, and here's what I did: 1) Created and entered a C:\Libraries folder C:\> Mkdir c:\Libraries C:\> cd c:\Libraries 2) Checked out the latest code from CVS using: (From http://boost.org/more/getting_started.html) cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost login [Hit <return> when it asks for a password] cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost checkout boost cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost logout 3) Installed Boost.Build and Boost.Jam 4) Built everything: C:\Libraries\Boost> bjam --prefix=c:\Libraries\Boost install 5) Launched Visual Studio .NET 2003 6) Created a new Win32 Console Project (CTRL+SHIFT+N) and accompanying solution named BoostTest 7) Configured the wizard to create an Empty Project (click "Application Settings", check "Empty Project", click "Finish") 8) Configured the project to use the "Multi-threaded Debug Runtime Library" (Project::BootTest Properties, C/C++::Code Generation::Runtime Library) 9) Configured the project to search for the Boost include files (Project::BootTest Properties, C/C++::General::Additional Include Directories) by adding: C:\Libraries\boost\include 10) Created a new file named BoostTest.cpp (CTRL+SHIFT+A, click "C++ File", type "BoostTest.cpp" in the Name field, click Open) 11) Inserted the single include line: #include <boost/thread/thread.hpp> 12) Compiled (CTRL+F7) 13) It works! So yes, that all seems pretty obvious. But it took me a long time to get working. I was unable to get anything with a Boost.Thread header to compile *at all* (with any combination of static/dynamic runtimes, #defines, and code hacks) using the 1.31.0 release currently available for download via SourceForge. But it works now, and I'm proof that it can be done. Good luck! -david

1 0

Re: [boost] New design proposal for boost::filesystem
by Reece Dunn 22 Aug '04

22 Aug '04

Carlo Wood wrote: >On Sat, Aug 21, 2004 at 11:36:31AM +0100, John Maddock wrote: > > > I propose the following design. The aim of boost::filesystem should >be to > > > support the following coding idiom: > > > > > > * The programmer should take care to only handle two types of paths > > > in his application: > > > > > > 1) Complete paths > > > 2) Relative paths > > > > That is true now. > >No, the current implementation/design doesn't restrict anything at all >in this regard. You can just use fs::path to store paths - and that is >it. A path is not aware of a distinct difference between complete >paths and relative paths (except that they are complete or relative >of course) - definitely not in the same way as a design would that >uses two different classes for the two. A complete path is one that is fully qualified, thus: fs::path absolute = fs::path( "d:/devel/libraries/boost/1.31.0/libs" ); whereas a relative path is one that is "relative" to another. With a relative path, you must have an absolute path as the basis, e.g.: fs::path relative = fs::path( "../boost/mpl" ); and can turn the relative path into an absolute one by doing: fs::path qualified = absolute / relative; so where is the problem? >The most problematic difference is that it is possible to even store >a third possibility (one that is neither complete nor relative). ??? Do you mean one that isn't relative because it is not based from an absoute path, or that the path does not exist? If so, you can do that in any file system, e.g.: fs::path foobar = fs::path( "../booster/foobar.foo" ); fs::exists( absolute / foobar ); A path will either (in absolute form) refer to a file, a directory or be invalid. > > > * The programmer will have to specifically tell the libary when a > > constructed > > > path is 'native' and when not. A native path is accepted according >to > > native > > > rules and never gives any problem (exceptions) further on. > > > A non-native path is checked according to the existing rules, which > > basically > > > means that the programmer can set a default check routine that will >in > > effect > > > determine how portable the application will be. > > > > That is also true now, isn't it? > >No, because the 'native' that you can specify with the current design >is only a check on the characters used in the directory components, and >only related to the representation of a path - not *marking* the path >as different. The 'native' I am talking about is enforced for complete >paths and reflexs also the root part of a directory ("C:\", "c:/cywgin/", >"/" etc). The essential difference is that a path that is once marked >as 'native' must stay native. It can never be converted to a portable >path anymore. Only relative paths that are portable from the start >can stay portable after certain operations (like appending a directory, or >cutting off a directory at the end). The native you are referring to is an "absolute" path, correct? Boost.Filesystem stores the paths in a generic form. Thus, if your filesystem uses ':' as a directory separator, the library will map this correctly from it's internal state. If you enforce that all "native" Windows paths must have a directory, you are restricting the use of the library, e.g. "\\mycomp\devel\libraries" is not possible! Likewise, it would not be possible to store URLs. NOTE: I am not sure if Boost.Filesystem currently supports URLs, but it should be possible to extend it to add that support. Also, URLs are not attached to a particular filesystem and are thus portable. It should be possible to handle both URLs and native paths, but limiting "native" paths will only make this harder. > > > I propose two design changes: > > > > > > 1) 'native' is now not only a representation, but an *internal state* >of > > fs::path. > > > (this has no effect on the representation as returned by > > fs::path::string()). This would make things too restrictive. I think you are confusing "native" with "absolute" paths, but how do you validate an absolute path? Is there a Windows and a POSIX function to validate an absolute path (e.g. IsPathAbsoute)? It would then be possible to have a fs::is_absolute( ... ) function. > > > 2) All 'complete' paths are automatically marked as 'native'. Likewise, how do you validate a complete path? What about a URL? If you have the URL "http://www.boost.org/people" and are using a system whereby the native directory separator is ':', the URL will be mapped to "http:::www.boost.org:people", corrupting the URL. > > If I understand you correctly, you are suggesting that error checking is > > turned off for native paths, I would support that, but other than that I > > don't see how it differs. > >Heh - the current design does NOT have an internal state that marks >a path as native or not. Hence, it cannot do sensible error checks >that need that knowledge. Isn't that difference enough? Native - as Boost.FileSystem uses it - is used to mark a path as using the native OS syntax for specifying paths. This is so you can do: fs::system_complete( fs::path( argv[1], fs::native ) ); and use the library on Windows, *nix, OpenVMS, MacOS, etc. without having to worry about the differences between how they specify their paths and thus what regular expressions need to be used on the string. The example from the documentation (using OpenVMS) is: DISK$SCRATCH:[GEORGE.PROJECT1.DAT]BIG_DATA_FILE.NTP;5 > > > Examples, the following code is legal: > > > > > > fs::path p1("C:\\foo\\a.exe", native); // As one might do on windows. > > > fs::path p2("/usr/src/a.out, native); // As one might do on linux. > > > std::cout << p1.native_file_string(); // ok, p1 is native. > > > > > > fs::path p3("foo/bar"); // Relative path, always succeeds. > > > std::cout << p.string(); // ok > > > std::cout << p.native_directory_string(); // Useless, but ok. > > > > Not useless at all. And works now. > ^^^^^^^^^^^^^^^^ > \__ this. > >That is not backupped. Did you mean p to be the relative path p3? If so, then p3.native_directory_string() is perfectly valid and *not* useless. If the OS uses ':' as it's directory separator, then this will return "foo:bar". It is useful for all sorts of purposes, like debuging. > > > fs::path p4(complete(p3)); // p4 is now "native", because now it is > > complete. Why does native ==> complete? You can have a native relative and/or complete path. > > > std::cout << p4.string() // Not allowed because p4 is native >(complete). Huh? IIUC path.string() returns the internal format of the path (e.g. "foo/bar") whereas path.native_directory_string() returns the path as represented by the native OS (e.g. "foo:bar"). >Right now you can call all the operations that actually pass a path to some >system call - and UNLESS that path is complete - it will not be >non-portable. Not true. "foo/bar" is relative *and* non-portable for OS's that use ':' as a directory separator. >THAT means that boost::filesystem has a structural design error. You are >now saying that I can complete all paths just prior to calling any >operation >that passes paths to system calls. Would you mind even listing those for >me? >Why not change boost::filesystem so that it takes care of completion >automatically when needed? That way you cannot make errors. If you have an absolute path boost_dir and a relative path boost_build2, you can do: ::SetWorkingDirectory(( boost_dir / boost_build2 ).native_directory_string().c_str()); >As an example - I developed my application first on GNU/Linux with as only >demand that it had to be portable to cygwin. Therefore, I used UNIX paths. >Testing if /usr/src/edragon/edragon/build/src/gui/gui.la existed on linux >worked fine. It did NOT work on cygwin. Because I was stupid? No, I >think >that was because boost::filesystem is not activily supporting portable >programming. Did you check that you have the file where you said on the cygwin system. Have you checked that "/usr/bin/ls.exe" exists? Also, have you checked that BOOST_POSIX is defined as per the note on using the cygwin platform in the docs? Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Review Wizard Status Report
by tom brinkman 22 Aug '04

22 Aug '04

Review Wizard Status Report 1) Summary 2) Review Managers Needed 3) Review Schedule 1) Summary The next three libraries under review extend the c++ iostreams framework through stream modifiers. Please be prepared to discuss these libraries in the coming weeks. 2) Review Managers Needed If you would like to volunteer to be a review manager, please contact me at reportbase(a)yahoo.com. 3) Review Schedule August 21, 2004 More IO August 28, 2004 Iostreams September 7, 2004 Output Formatters September 15, 2004 Mini-Review wiki algorithims September 17, 2004 Smart Containers September 27, 2004 Named Params October 6, 2004 Policy Pointer October 16, 2004 Wave October 26, 2004 Finite State Machine (FSM) November 4, 2004 Fixed Strings August 21, 2004 More IO Author - Daryle Walker - darylew(a)hotmail.com Review Manager - Tom Brinkman - reportbase(a)yahoo.com Download: http://groups.yahoo.com/group/boost/files/more_io_4.zip [or] http://boost-sandbox.sourceforge.net/more_io_4.zip Description: Provides a multitude of I/O-oriented extensions. Some are extra manipulators; variants of "std::endl", a resetting manipulator, and a configurable manipulator. The library includes a set of base class templates for wrapping a new stream-buffer type around a stream class. Changes from the last interim version (called "more_io_3b.zip"): * split the manipulator header into several headers * refined the license statements in some already-affected files Changes from the first formal review (called "more_io.zip"): * refined the interface and implementation of array-streams and stream-buffer wrappers (including a wrapping example) * added the null-stream, value-stream, and pointer-stream headers * added generalizations to the new-line and skip-line manipulators * added the non-oriented 'reset' and 'form' manipulators * split the manipulator header into several headers * changed the license statements August 28, 2004 Iostreams Author - Jonathan Turkanis - turkanis(a)kangaroologic.com Review Manager - Volunteer needed Web-Page: http://home.comcast.net/~jturkanis/iostreams Download: http://home.comcast.net/~jturkanis/iostreams Description: The Iostreams Library serves two main purposes: To allow the easy creation of standard C++ stream and stream buffer classes for new data sources and sinks. To provide a convenient interface for defining i/o filters and attaching them to standard streams and stream buffers. The library focuses on freeing users from writing boiler plate code and allowing them instead to create highly reusable components. In addition to providing an abstract framework the library provides a number of concrete filters, sources and sinks which serve as example applications of the library but are also useful in their own right. These include components for accessing memory-mapped files (based on work of Craig Henderson) , for file access via operating system file descriptors, for code conversion, for text filtering with regular expressions, for line-ending conversion and for compression and decompression in the zlib, gzip and bzip2 formats. September 7, 2004 Output Formatters Author - Reece Dunn - msclrhd(a)hotmail.com Review Manager - John Torjo - john(a)torjo.com Download: http://cvs.sourceforge.net/viewcvs.py/ boost-sandbox/boost-sandbox/boost/outfmt/ [or] http://cvs.sourceforge.net/viewcvs.py/ boost-sandbox/boost-sandbox/libs/outfmt/ Description: The I/O formatters library provides an easy and customizable way to input/output arrays, STL arrays, STL collections, sub-arrays from/to STL streams. It allows you to configure how each element in such an array will be written to the stream or read from the stream, while providing reasonable defaults. September 15, 2004 Mini-Review wiki algorithims Author - Various Review Manager - Tom Brinkman - reportbase(a)yahoo.com Download: to be determined Description: not available September 17, 2004 Smart Containers Author - Thorsten Ottosen - nesotto(a)cs.auc.dk Review Manager - Pavol Droba - droba(a)topmail.dk Download: the boost sandbox: ptr_container Description: The Smart Container Library consists of several container classes that are capable of storing heap-allocated objects in an exception-safe manner. The interface of the container classes effectively hides the underlying pointers so one can work on objects directly; this indirection is done to make the classes safer and easier to use. The library can also be customized to allow, for example, that a container does not rake ownership of the stored objects. September 27, 2004 Named Params Co-Authors - David Abrahams - dave(a)boost-consulting.com) & Daniel Wallin (dalwan01(a)student.umu.se) Review Manager - to be determined Download: Boost sandbox boost/named_params.hpp [and] libs/utility/doc/named_params.html Description: This library is an attempt to address the problems of positional parameters by associating each parameter with a keyword identifier. Using this library, users can identify parameters by name instead of just argument position, and pass them in any order: window* w = new_window("alert2", movable = movability, opacity = 50); October 6, 2004 Policy Pointer Author - David Held - dheld(a)codelogicconsulting.com Review Manager - to be determined Download: available via boost CVS Description: Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications. October 16, 2004 Wave Author - Hartmut Kaiser - hartmutkaiser(a)t-online.de Review Manager - to be determined Download Boost-sandbox Description: The Wave C++ preprocessor library is a Standards conformant implementation of the mandated C99/C++ preprocessor functionality packed behind a simple to use interface, which integrates well with the well known idioms of the Standard Template Library (STL). It uses the Spirit[4] parser construction library to implement a C++ lexer with ISO/ANSI Standards conformant preprocessing capabilities. It exposes an iterator interface, which returns the current preprocessed token from the input stream. This preprocessed token is generated on the fly while iterating over the preprocessor iterator sequence (in the terminology of the STL these iterators are forward iterators). October 26, 2004 Finite State Machine (FSM) Author - Andreas Huber - ah2003(a)gmx.net Review Manager - to be determined Summary - not available Download - not available November 4, 2004 Fixed Strings Author - Reece Dunn - msclrhd(a)hotmail.com Review Manager - to be determined Download: boosts-sandbox/boost/fixed_string [or] boost-sandbox/libs/fixed_string Description: The fixed string library provides buffer overrun protection for static sized strings (char s[ n ]). It provides a C-style string interface for compatibility with C code (for example, porting a C program to C++). There is also a std::string-style interface using a class based on flex_string by Andre Alexandrescu with a few limitations due to the non-resizable nature of the class. Tom Brinkman Boost Review Wizard reportbase(a)yahoo.com

5 5

[multi_index] adding support for Compaq C++ for Tru64 Unix
by JOAQUIN LOPEZ MU?Z 21 Aug '04

21 Aug '04

Latest changes to Boost.Test have revealed that Boost.MultiIndex almost works for this compiler (toolset tru64cxx65), and I think the remaining problems are fixable. Is there any volunteer with local access to this compiler willing to help me in the process? Many thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

regression in graph - brandes_betweenness_centrality_test
by Bronek Kozicki 21 Aug '04

21 Aug '04

There's memory access violation in brandes_betweenness_centrality_test.cpp . This error is thrown inside function put called in line 264 : for (tie(vi, vi_end) = vertices(g); vi != vi_end; ++vi) put(centrality, *vi, 0); // <<--- access violation inside put B.

1 0

numeric-ublas errors with Comeau
by Bronek Kozicki 21 Aug '04

21 Aug '04

All tests in numeric-ublas are failing in Comeau compiler. Most of these errors can be fixed if we define BOOST_UBLAS_NO_CMATH in boost/numeric/unblas/config.hpp for this compiler. Patch attached B. Index: boost/boost/numeric/ublas/config.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/ublas/config.hpp,v retrieving revision 1.36 diff -u -r1.36 config.hpp --- boost/boost/numeric/ublas/config.hpp 16 Aug 2004 05:31:03 -0000 1.36 +++ boost/boost/numeric/ublas/config.hpp 17 Aug 2004 22:12:08 -0000 @@ -33,6 +33,11 @@ #include <boost/type_traits/remove_reference.hpp> +// Comeau compiler +#ifdef __COMO__ +#define BOOST_UBLAS_NO_CMATH +#endif + // Microsoft Visual C++ #if defined (BOOST_MSVC) && ! defined (BOOST_STRICT_CONFIG)

1 1

Fw: Please Read: Boost Software License.
by John Maddock 21 Aug '04

21 Aug '04

And another permission: ----- Original Message ----- From: "Dan Gohman" <djg(a)cray.com> To: <boost-owner(a)lists.boost.org> Sent: Friday, August 20, 2004 9:21 PM Subject: Re: Please Read: Boost Software License. > I Dan Gohman, give permission for all my contributions to Boost to be > moved to the Boost Software License Version 1. > > On Thu, Aug 12, 2004 at 01:51:59PM +0100, John Maddock wrote: > > Hi, if you are receiving this message it is because there are one or more > > files in the Boost C++ libraries that contain your copyright declaration. > > > > As some of you will know already, in order to simplify Boost licensing, we > > are in the process of moving to a single common license > > (http://www.boost.org/LICENSE_1_0.txt) The aim of the new license is to > > provide a single wording, that encapsulates the our previous license > > requirements, and which will simplify the evaluation of Boost for commercial > > organisations. > > > > So here's the big question: may we have permission to change code that has > > your copyright to use the new license? Your copyright declaration would > > obviously remain, it's only the license text that would change. > > > > If "yes", and you have Boost-cvs write access, please add your name to > > more/blanket_permissions.txt. > > > > If "yes" and you have access to the Boost mailing list > > (boost(a)lists.boost.org) then please post a message there, subject "Boost > > License Permission", and content something like: "I Jim Hacker, give > > permission for all my contributions to Boost to be moved to the Boost > > Software License Version 1". (This gives us a public record that your > > permission has been given). > > > > If "yes", but you are no longer subscribed to the Boost list then please > > reply to boost-owner(a)lists.boost.org with content as above. > > > > If "no", please give us some idea what objections you may have. > > > > Finally, if this message was sent in error, please let us know, it's just > > about possible that we have you mixed up with someone of the same name, and > > if so apologies. > > > > Many thanks for your time, > > > > John Maddock. > > (Boost Moderator). >

1 0

Re: [boost] shared_ptr feature request: void_pointer_cast
by Jeff Williams 21 Aug '04

21 Aug '04

> Date: Thu, 19 Aug 2004 21:09:07 -0400 > From: "Joe Gottman" <jgottman(a)carolina.rr.com> > Subject: [boost] shared_ptr feature request: void_pointer_cast > > I know this isn't the best time to request a new feature, but I just had > an idea for an extremely useful new function for shared_ptr. It is common > to use a shared_ptr<void> in places where a void * would otherwise be used. > While a void * can point to anything, there is no safe way to determine at > run-time what type it originally pointed to. Casting it to the wrong type > can result in undefined behavior. How is this idea any different that just using boost::shared_ptr<boost::any> ? Jeff

2 1

Need help with XCode
by Daryle Walker 20 Aug '04

20 Aug '04

I'm finally trying to compile More-I/O(4) with XCode. I extracted more-io from a ZIP file, not the Sandbox. I included the directories for the extraction and Boost-CVS in the project settings. I dragged in all the more-io files (and later the Boost.Test mandatory source code). But it still can't find the Boost header files. I think it only includes the Boost files under "", and I need them under <>. Does anyone have Boost working with XCode? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 1

Problem with noncopyable in current cvs
by Neal D. Becker 20 Aug '04

20 Aug '04

/usr/local/src/boost.cvs/boost/noncopyable.hpp:32: error: conflicting types for `typedef class boost::noncopyable_::noncopyable boost::noncopyable' /usr/local/src/boost.cvs/boost/utility_fwd.hpp:26: error: previous declaration as `struct boost::noncopyable'

8 16

iterator_facade failing on vc7.1
by Bronek Kozicki 20 Aug '04

20 Aug '04

For some time already I'm receiving failed assertion error in iterator_facade test. The problem is that this error is displaying message box (is calling _assert function defined in CRT) that cannot be automatially closed by execution_monitor.exe . I suggest that BOOST_ASSERT(state == 8) in iterator_facade.cpp be changed to BOOST_CHECK_EQUAL(state, 8) . Actual value of "state" variable at this point in this test is 7, thus failed assertion. B.

2 5

Big BSL update
by John Maddock 20 Aug '04

20 Aug '04

I've just committed a large number of files converted to the BSL, based on the permissions in blanket-permission.txt: boost/python.hpp boost/variant.hpp boost/detail/named_template_params.hpp boost/pending/fibonacci_heap.hpp boost/pending/iterator_adaptors.hpp boost/pending/detail/int_iterator.hpp boost/python/bases.hpp boost/python/call_method.hpp boost/python/class.hpp boost/python/class_fwd.hpp boost/python/copy_const_reference.hpp boost/python/copy_non_const_reference.hpp boost/python/data_members.hpp boost/python/def.hpp boost/python/enum.hpp boost/python/exception_translator.hpp boost/python/has_back_reference.hpp boost/python/implicit.hpp boost/python/init.hpp boost/python/iterator.hpp boost/python/lvalue_from_pytype.hpp boost/python/make_constructor.hpp boost/python/manage_new_object.hpp boost/python/object_call.hpp boost/python/opaque_pointer_converter.hpp boost/python/operators.hpp boost/python/other.hpp boost/python/overloads.hpp boost/python/pure_virtual.hpp boost/python/raw_function.hpp boost/python/reference_existing_object.hpp boost/python/register_ptr_to_python.hpp boost/python/return_arg.hpp boost/python/return_by_value.hpp boost/python/return_internal_reference.hpp boost/python/return_opaque_pointer.hpp boost/python/return_value_policy.hpp boost/python/to_python_converter.hpp boost/python/with_custodian_and_ward.hpp boost/python/converter/as_to_python_function.hpp boost/python/converter/implicit.hpp boost/python/converter/shared_ptr_from_python.hpp boost/python/detail/char_array.hpp boost/python/detail/dealloc.hpp boost/python/detail/def_helper.hpp boost/python/detail/defaults_def.hpp boost/python/detail/defaults_gen.hpp boost/python/detail/if_else.hpp boost/python/detail/is_shared_ptr.hpp boost/python/detail/make_keyword_range_fn.hpp boost/python/detail/make_tuple.hpp boost/python/detail/nullary_function_adaptor.hpp boost/python/detail/operator_id.hpp boost/python/detail/overloads_fwd.hpp boost/python/detail/pointee.hpp boost/python/detail/result.hpp boost/python/detail/scope.hpp boost/python/detail/target.hpp boost/python/detail/translate_exception.hpp boost/python/object/class_wrapper.hpp boost/python/object/iterator.hpp boost/python/object/make_holder.hpp boost/python/object/value_holder.hpp boost/python/object/value_holder_fwd.hpp boost/python/suite/indexing/container_utils.hpp boost/python/suite/indexing/indexing_suite.hpp boost/python/suite/indexing/map_indexing_suite.hpp boost/python/suite/indexing/vector_indexing_suite.hpp boost/python/suite/indexing/detail/indexing_suite_detail.hpp boost/signals/detail/config.hpp libs/python/test/args.cpp libs/python/test/as_to_python_function.cpp libs/python/test/auto_ptr.cpp libs/python/test/back_reference.cpp libs/python/test/bases.cpp libs/python/test/bienstman4.cpp libs/python/test/bienstman5.cpp libs/python/test/borrowed.cpp libs/python/test/callbacks.cpp libs/python/test/complicated.hpp libs/python/test/copy_ctor_mutates_rhs.cpp libs/python/test/crossmod_exception_a.cpp libs/python/test/crossmod_exception_b.cpp libs/python/test/data_members.cpp libs/python/test/defaults.cpp libs/python/test/docstring.cpp libs/python/test/embedding.cpp libs/python/test/enum.cpp libs/python/test/extract.cpp libs/python/test/if_else.cpp libs/python/test/implicit.cpp libs/python/test/injected.cpp libs/python/test/input_iterator.cpp libs/python/test/keywords.cpp libs/python/test/long.cpp libs/python/test/m1.cpp libs/python/test/module_tail.cpp libs/python/test/nested.cpp libs/python/test/object.cpp libs/python/test/object_fail1.cpp libs/python/test/object_manager.cpp libs/python/test/opaque.cpp libs/python/test/operators.cpp libs/python/test/pointee.cpp libs/python/test/polymorphism.cpp libs/python/test/polymorphism2.cpp libs/python/test/raw_pyobject_fail1.cpp libs/python/test/raw_pyobject_fail2.cpp libs/python/test/result.cpp libs/python/test/return_arg.cpp libs/python/test/select_holder.cpp libs/python/test/shared_ptr.cpp libs/python/test/simple_type.hpp libs/python/test/staticmethod.cpp libs/python/test/test_builtin_converters.cpp libs/python/test/test_class.hpp libs/python/test/test_pointer_adoption.cpp libs/python/test/upcast.cpp libs/python/test/virtual_functions.cpp tools/build/v2/example/customization/codegen.cpp tools/build/v2/example/hello/hello.cpp tools/build/v2/example/libraries/app/app.cpp tools/build/v2/example/libraries/lib1/lib1.cpp tools/build/v2/example/libraries/lib1/include/lib1.h tools/build/v2/example/make/a.cpp tools/build/v2/example/make/extlib/c.cpp tools/build/v2/example/make/lib/b.cpp tools/build/v2/test/dependency-test/a.cpp tools/build/v2/test/dependency-test/a.h tools/build/v2/test/dependency-test/b.cpp tools/build/v2/test/dependency-test/b.h tools/build/v2/test/dependency-test/c.cpp tools/build/v2/test/dependency-test/e.cpp tools/build/v2/test/dependency-test/src1/a.h tools/build/v2/test/dependency-test/src1/b.h tools/build/v2/test/dependency-test/src1/c.h tools/build/v2/test/dependency-test/src2/b.h tools/build/v2/test/direct-request-test/a.cpp tools/build/v2/test/direct-request-test/b.cpp tools/build/v2/test/direct-request-test/b_inverse.cpp tools/build/v2/test/generators-test/a.cpp tools/build/v2/test/generators-test/e.cpp tools/build/v2/test/generators-test/z.cpp tools/build/v2/test/generators-test/lib/c.cpp tools/build/v2/test/prebuilt/hello.cpp tools/build/v2/test/prebuilt/ext/a.cpp tools/build/v2/test/prebuilt/ext/debug/a.h tools/build/v2/test/prebuilt/ext/release/a.h tools/build/v2/test/project-test3/a.cpp tools/build/v2/test/project-test3/lib/b.cpp tools/build/v2/test/project-test3/lib2/c.cpp tools/build/v2/test/project-test3/lib2/d.cpp tools/build/v2/test/project-test3/lib2/helper/e.cpp tools/build/v2/test/project-test3/lib3/f.cpp tools/build/v2/test/project-test4/a.cpp tools/build/v2/test/project-test4/a_gcc.cpp tools/build/v2/test/project-test4/lib/b.cpp tools/build/v2/test/test2/foo.cpp tools/build/v2/test/v1-testing/b.cpp tools/build/v2/test/v1-testing/c.cpp tools/build/v2/test/v1_testing/foo.cpp tools/build/v2/test/v1_testing/lib.cpp tools/build/v2/test/v1_testing/lib.err.cpp If there are any problems from these, please do let me know. John.

2 1

numeric/ublas aix test failures
by Daniel Elliott 20 Aug '04

20 Aug '04

Hello, I am interested in using ublas for a large government project. I noticed ublas (as of 8-19-2004) failed test3 on the visual age c++ compiler. What does this test exercise? We have currently installed the 1.31 libraries. Is this the same code that produced the test results? Thank you for your time. Sincerely, Dan Elliott --------------------------------- Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers!

1 0

Any Tutorial?
by mistus 20 Aug '04

20 Aug '04

Do you know where to find a good tutorial on how to implement an STL-like container?

1 0

Metacom toolsets broken?
by John Maddock 20 Aug '04

20 Aug '04

The Metacom toolsets that use STLport in the current regression test results appear not to be finding the STLport binaries, which is basically causing these toolsets to fail all the tests :-( Any ideas? John.

2 1

Missing copyright in Format library
by John Maddock 20 Aug '04

20 Aug '04

The following file have no copyright, can the owner please fix? libs/format/example/sample_userType.cpp boost/format/detail/unset_macros.hpp Many thanks, John Maddock

2 2

[MPL] BOOST_MPL_METAFUNCTION_MAX_ARITY in template_arity
by Daniel Wallin 20 Aug '04

20 Aug '04

I think there's a mismatch in the use of BOOST_MPL_METAFUNCTION_MAX_ARITY. mpl::bind<> and aux::template_arity<> both make use of the BOOST_MPL_METAFUNCTION_MAX_ARITY when generating code. However, bind<> has an additional leading argument which increases it's arity by one. This means template_arity<> will return the wrong arity. This demonstrates the bug: #include <boost/mpl/bind.hpp> #include <boost/mpl/lambda.hpp> using namespace boost::mpl; template<int N, class T> void f() { T x[-1]; } int main() { f< aux::template_arity<bind<int> >::value , bind<int> >(); } With gcc3.3 this results in: arity.cpp: In function `void f() [with int N = 5, T = boost::mpl::bind< int , boost::mpl::void_ , boost::mpl::void_ , boost::mpl::void_ , boost::mpl::void_ , boost::mpl::void_ > ]': Where N should actually be 6. -- Daniel Wallin

2 1

irritation in ublas/lu.hpp
by troy d. straszheim 20 Aug '04

20 Aug '04

Real quick: numeric/ublas/lu.hpp will not compile on its own, it requires at least operation.hpp for the symbol axpy_prod<>. In the absence of examples, one of my users included matrix.hpp , vector.hpp, and lu.hpp intending to do some lu-decompositions, and was stymied when the headers wouldn't compile. As lu.hpp is not included from anywhere else, it appears that it is *not* a header that is designed not to be used directly... I asked on #boost, can't come up with an explanation, therefore submit as bug^-2 -t

2 1

vc7 lib name mangling broken
by John Maddock 20 Aug '04

20 Aug '04

Rene, The vc7 toolset is currently appending the suffix "vc" rather than "vc7" to lib names, which is breaking the auto-link code, do you have any idea what may have broken this? Thanks! John.

1 0

31 character limit for filenames
by Doug Gregor 20 Aug '04

20 Aug '04

Okay, it's time to ask again: do we still need to enforce the 31-character limit on filenames? AFAIK, we have this for MacOS 9, only. Is that platform still significant for Boost users? Doug

8 11

[mpl] Iterator categories for sequence views
by Daniel James 20 Aug '04

20 Aug '04

I'm not sure about this, but I think the iterator categories for joint_view, transform_view and filter_view are wrong. At the moment they are set to the category of their base iterator, but I think that they should be set to forward_iterator_tag (or maybe input_iterator_tag?) because they don't implement prior, advance or distance. I think this is the reason that the attached file fails to compile. Of course, this might not be the case in the new version? Daniel

2 1

Links to regression tests are broken
by Jeff Garland 20 Aug '04

20 Aug '04

Go to http://www.boost.org/regression-logs/ The developer and and user reports links are broken. I assume these now need to point to meta-comm? Jeff

2 1

shared_ptr feature request: void_pointer_cast
by Joe Gottman 20 Aug '04

20 Aug '04

I know this isn't the best time to request a new feature, but I just had an idea for an extremely useful new function for shared_ptr. It is common to use a shared_ptr<void> in places where a void * would otherwise be used. While a void * can point to anything, there is no safe way to determine at run-time what type it originally pointed to. Casting it to the wrong type can result in undefined behavior. Although there's no way to avoid this problem with a plain void *, except by passing type information along with it, it should be possible to improve on this situation for shared_ptr<void>, using the template function void_pointer_cast. template<class X> shared_ptr<X> void_pointer_cast(shared_ptr<void> pv); (and similarly for shared_ptr<const void>, shared_ptr<volatile void> and shared_ptr<const volatile void>) void_pointer_cast should have the following semantics: if (pv.get() && pv owns an object of type X) { return shared_pointer_cast<X>(pv); } else { return shared_ptr<X>(); } This would allow code like the following shared_ptr<void> pv = getNextObject(); if (shared_ptr<int> pInt = void_pointer_cast<int>(pv)) { // Do something with pInt; } else if (shared_ptr<string> pString = void_pointer_cast<string>(pv)) { // Do something with pString; } Note that while this code is very similar to code using dynamic_pointer_cast, void_pointer_cast would be usable even when the target type is not a class with virtual functions. On the other hand, given code like shared_ptr<void> pv(new Derived); shared_ptr<Base> pb = void_pointer_cast<Base>(pv); pb.get() would equal 0, even if Base were a public base class of Derived and had a virtual destructor. void_pointer_cast should be easy to implement, using the same techniques as were used in get_deleter, and I think it would be of great use to many programmers. Joe Gottman

1 0

problem re CW serialization tests
by Robert Ramey 19 Aug '04

19 Aug '04

Almost all the tests for the serialization system fail to link with the following message: ### mwld Linker Error: # Undefined symbol: '_errno' # referenced from 'void boost::unit_test::hrf_report_formatter::report_assertions_stat(class std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, unsigned long, unsigned long, unsigned long) (?report_assertions_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$basi c_ostream@DU?$char_traits@D@std@@@std@@IKKK@Z)' in unit_test_result.obj (libboost_test_exec_monitor.lib) ### mwld Linker Error: # Undefined symbol: '_errno' # referenced from 'void boost::unit_test::hrf_report_formatter::report_sub_test_cases_stat(class std::basic_ostream<char, struct std::char_traits<char> > &, unsigned int, unsigned long, unsigned long) (?report_sub_test_cases_stat@hrf_report_formatter@unit_test@boost@@UAEXAAV?$ basic_ostream@DU?$char_traits@D@std@@@std@@IKK@Z)' in unit_test_result.obj (libboost_test_exec_monitor.lib) Errors caused tool to abort. To me, this suggests some issue regarding libboost_test_exec_monitor.lib . Anyone care to comment? Robert Ramey

2 1

[boost.thread] Experimental alternative TLS implementation
by Roland 19 Aug '04

19 Aug '04

While searching for a method to overcome the intentional memory leak on the windows implementation of tss, I wrote a new shrink wrapped version of tss, for discussion of possible improvements over the current implementation. The proposal will not alter the current interface, but adds the following features: * Completely orthogonal to boost::thread * No memory leaks * Twice as fast for -> operator * Threads may (in principle) live after end of main() Currently this will only work on windows, but it should be possible to port it to pthreads as well with little effort. I have uploaded the file tls_win.zip to the boost filearea on Yahoo. Roland

4 10

[Boost-bugs] [ boost-Support Requests-1012276 ] test framework does not compile on cygwin
by SourceForge.net 19 Aug '04

19 Aug '04

Support Requests item #1012276, was opened at 2004-08-19 08:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1012276&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: test framework does not compile on cygwin Initial Comment: Hello, My e-mail address is : javier.revilla(a)free.fr I am trying to compile Boost on CygWin with gcc 3.3.3. My machine is a Windows 2000 PC. To install Boost I do : bjam "-sTOOLS=gcc" install I cannot compile the Test Framework. I obtain the following error report : gcc-Link-action bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll Chmod1 bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll chmod 755 "bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll" ...failed Chmod1 bin/boost/libs/test/build/libboost_prg_exec_monitor. dll/gcc/debug/libboost_prg_exec_monitor-gcc-d-1_31.dll.. . ...skipped <@boost! lib>libboost_prg_exec_monitor-gcc-d-1_31.dll for lack of <@boost!libs!test!build/libboost_prg_exec_monitor. dll/gcc/debug>libboost_prg_exec_monitor-gcc-d-1_31.dll. .. etc... What should I do ? Thank you very much for your help. Javier Revilla ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1012276&group_… ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

regex bit
by Yitzhak Sapir 19 Aug '04

19 Aug '04

Going on past my previous ETI problems thanks to Dave Abrahams' fix, I now had a problem in regex. In boost/regex/v4/regex_match.hpp, line 149+, we have: #if !defined(BOOST_NO_WREGEX) inline bool regex_match(const std::basic_string<wchar_t>& s, match_results<std::basic_string<wchar_t>::const_iterator, wregex::allocator_type>& m, const wregex& e, match_flag_type flags = match_default) This should be: #if !defined(BOOST_NO_WREGEX) inline bool regex_match(const std::basic_string<wchar_t>& s, match_results<std::basic_string<wchar_t>::const_iterator>& m, const wregex& e, match_flag_type flags = match_default) Otherwise passing a wsmatch to regex_match fails.

2 1

RE: [boost] Re: [boost.test] Patch for true64cxx65 support.
by Rozental, Gennadiy 19 Aug '04

19 Aug '04

> What about > > const_string const LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; > > That would work too. Is that ok for you? If yes, the File scope const declaration automatically assumes static anyway if I am not mistaken. Update from cvs and let me know how did it work. Gennadiy.

2 1

[signals] trackable object limitations
by Jeff Flinn 19 Aug '04

19 Aug '04

Any changes in 1.32 pertaining to: Warning: User-defined function objects and function objects from other libraries (e.g., Boost.Function or Boost.Lambda) do not implement the required interfaces for trackable object detection, and will silently ignore any bound trackable objects. Future versions of the Boost libraries will address this limitation. Thanks, Jeff

2 1

typeof and ODR
by Arkadiy Vertleyb 19 Aug '04

19 Aug '04

David Abrahams wrote: >We should try this stuff [typeof] out with EDG-based compilers in their >"template repository" link-time-instantiation mode. Also I think >Metrowerks now supports the same thing. These are the most likely >configurations to report problems from ODR violations. Can anybody help me with this? (I do realize that it's not a good timing now, but I just want to see if I can count on it once things get quieter) Thanks in advance, Arkadiy

1 0

test_read_write_mutex trouble under Tru64 Unix
by Ralf W. Grosse-Kunstleve 19 Aug '04

19 Aug '04

Last night I started Aleksey's regression.py script under Tru64 Unix. It used to finish after 6 hours, but now the test_read_write_mutex process has consumed 16 CPU hours already without finishing. I am going to kill it. I hope the failure shows up at the meta-comm site. Let me know if more information is required. Ralf _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

3 3

Re: [boost] Java style GUI in C++
by Reece Dunn 19 Aug '04

19 Aug '04

John Torjo wrote: >Hi Reece, > >Just a few thoughts: > >>I am currently designing a GUI framework in C++ (initially targeting the >>Windows platform) that uses a model similar to that which Java uses in > >Take a deep breath if you want to make it cross-platform ;) >I think that's Windows work x 10 or so. Maybe more ;) ... I was thinking about having a compatibility layer, e.g.: namespace windows { class window { public: inline handle_type create( const string_type title, ... ); inline void set_size( long, long ); // ... }; } namespace linux{ class window{ ... }; } Then engineer the library on top of that. This would simplify x-platform development... the problem is working out the right abstraction. >>it's AWT and Swing libraries. Specifically: >> >>[1] Being able to use constructors to create the windows/components. This >>means there is no need to explicitly call a Create method like in the MFC >>framework. > >win32gui does that ;) :) I am having a look at all the links to the various libraries, so it may take a while to process them all. (Thanks for everyone who compiled the links). >>[2] The use of layout managers. I like the various layout managers in Java >>and how easy it is to construct complex GUI interfaces. > >I like the idea of layout managers. Still, it seems (to me) in real-life >they kind of fail. You'll always want that special case where you need to >hide control X and show control Y, etc. So why not have that ability in the framework? That is the reason I posted this, to get ideas. It should not be that difficult to be able to change the layouts at run-time... once the layout managers have been written, that is. >So far, I've created splitters on dialogs at design time (still beta ;)). >If you use them correctly, you can specify a lot ot design time. Also, you >can easily hide/show the left/right panes. cool. >>[3] The support for events via "listeners". This will most likely be >>geared towards key/mouse events and "action" events (e.g. when the user >>presses on a button). > >I'm not a big fan of listeners. You need to do a lot of coding manually to >set them, etc. I've implemented them totally different - using event >handler classes. My idea was something along the lines of: class MouseEvent { public: static const int LeftButton = 0; static const int MiddleButton = 1; static const int RightButton = 2; private: int button; unsigned int vkeys; win::api::point pt; public: inline MouseEvent( int, WPARAM, LPARAM ); }; MouseEvent::MouseEvent( int btn, WPARAM wp, LPARAM lp ): button( btn ), vkey( wp ), pt( lp ) { } class MouseListener { public: virtual void mouseMove( const MouseEvent & ); virtual void mouseButtonDown( const MouseEvent & ); virtual void mouseButtonUp( const MouseEvent & ); virtual void mouseButtonDoubleClick( const MouseEvent & ); public: virtual ~MouseButtonListener(); }; With a common listener interface for GUI object actions, e.g. pressing a mouse button, selecting an item in a listbox, editing text, etc. >>At the moment, I have a basic working version that allows you to write the >>following: >> >>int PASCAL WinMain( HINSTANCE, HINSTANCE, LPSTR, int sw ) >>{ >> swing::JFrame frame( L"Swing JFrame!" ); >> frame.setPane( new swing::JPanel()); >> frame.setSize( 500, 500 ); >> frame.show( sw ); >> >> MessageLoop msg; >> return( msg.Execute()); >>} > >can you break the message loop? >That is, specify when a message loop should end (when a certain signal is >received). You can call ::PostQuitMessage( 0 ), but that is Windows specific. At the moment the message loop doesn't do anything fancy (accelerator/dialog box message processing), but it is on the list of things to work on. >>This creates two windows: the main frame and a panel that is a child of >>that frame. The JFrame is created in the constructor, but is not displayed >>until show is called. Likewise, the JPanel is created inside its >>constructor and the JFrame.setPane method makes that window a child of the >>frame. >> >>I would appreciate comments and ideas as to what people would like out of >>a GUI framework, especially one that will be multi-platform. > >I'm all for it, but again, I think it's so much work... But it will be fun! :D Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

4 4

[Boost-bugs] [ boost-Bugs-1012135 ] boost::filesystem is systematically broken
by SourceForge.net 19 Aug '04

19 Aug '04

Bugs item #1012135, was opened at 2004-08-19 14:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1012135&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Carlo Wood (libcw) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem is systematically broken Initial Comment: As is currently discussed on the boost mailinglist, cygwin is supposed to support windows paths (at least, when compiled with BOOST_WINDOWS, which is currently the default). I understand that Beman, the author of boost::filesystem, wants it that way. However, boost::filesystem does not accept a path like "/usr" (fs::exists fails in that case), when compiled with BOOST_WINDOWS and it *also* doesn't accept windows paths, like "c:/cygwin/usr", "C:\cygwin\usr" or anything remotely 'windows' like, because it throws when you try to construct a fs::path with a colon in it! As a result, one can ONLY construct usable paths on cygwin in the very non-portable format "/cggdrive/c/cygwin/usr" which is neither POSIX (on linux the same path would be "/usr") nor native (the _users_ of the application will view this path as "C:\cygwin\usr"). It is 100% cygwin specific. OR one has to construct paths on cygwin using 'native' all the time (or no_check) as path checker, because even windows_name doesn't work :/ Consider the following code: #include <iostream> #include <boost/filesystem/path.hpp> #include <boost/filesystem/operations.hpp> int main() { try { boost::filesystem::path p("C:\cygwin\usr", &boost::filesystem::windows_name); } catch(std::exception const& error) { std::cerr << "Exception: " << error.what() << std::endl; } } With the following result: Exception: boost::filesystem::path: invalid name "C:\cygwin\usr" in path: "C:\cygwin\usr" Same thing with any other variation that starts with 'C:'. I believe that this is a structural failure of boost::filesystem, revealing a major error in the design. A re-design seems to be in order before it can be considered to be usable in multi-platform applications. The most important problem with the current design is that a single type (namely fs::path) is being used for effectively two different types: canonical paths and native paths. A new design should provide a new type, fs::native_path that cannot be mixed with the canonical path representation. This native_path should have builtin checks that are native and fs::path should only check for portability (and allow relaxation of that when lesser OS need to be supported). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1012135&group_… ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Java style GUI in C++
by Johannes Brunen 19 Aug '04

19 Aug '04

Hi, Edward Diener wrote: > Why not use boost::signals for your event interface. It is much better than > hand-coded actions and listeners, since any type of function can handle an > event. The technology is already in Boost so why re-invent the wheel. I would like to emphazise this. I use the boost signal library for handling the tree view control and list view control events in an extension of the Zinc gui library. It works pretty well. Johannes

1 0

Re: Re: Java style GUI in C++
by Johannes Brunen 19 Aug '04

19 Aug '04

Hi, Pavel Vozenilek wrote: > To stop it: ultimate list of all (dozens) known GUI frameworks > is on http://www.free-soft.org/guitool/. I'm well aware of the link. But it is not up to date. For instance http://www.torjo.com/win32gui/ and http://notus.sourceforge.net/ aren't mentioned at all. http://gtkmm.sourceforge.net/ valuation is not correct with respect to the win32 platform. For some time I'm searching for the ultimate GUI framework. I didn't know of TnFox, Notus and Ultimate++. So I learned something from the contributions. Johannes

1 0

lightweight replacement for boost::function
by John Torjo 19 Aug '04

19 Aug '04

Dear boosters, Did a lightweight replacement for boost::function (compile-wise). Focus was on making it very fast to compile. Rationale: boost::function takes too long to compile. In a library I'm developing (win32gui), using boost::function would almost double the compilation time of some headers. This lightweight replacement takes virtually no extra compilation time. How I tested it: I took a project that took 1 minute to compile - added this to all of the headers, and it compiles in the same amount of time. #including <boost/function.hpp> almost doubled the time. Tested with vc71,gcc3.2. Feel free to use it any way you wish. Any feedback/suggestions deeply appreciated. Best, John -- John Torjo Freelancer -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32) #ifndef JOHN_TORJO_WIN32GUI_function #define JOHN_TORJO_WIN32GUI_function #if defined(_MSC_VER) && (_MSC_VER >= 1020) # pragma once #endif // function.hpp // Win32 GUI Generics library // // Copyright (C) 2004 John Torjo (john(a)torjo.com) // // Permission to copy, use, sell and distribute this software is granted // provided this copyright notice appears in all copies. // Permission to modify the code and to distribute modified code is granted // provided this copyright notice appears in all copies, and a notice // that the code was modified is included with the copyright notice. // // This software is provided "as is" without express or implied warranty, // and with no claim as to its suitability for any purpose. // // To see the version you have now, read win32gui/version.txt // // You can find the latest version of this library at http://www.torjo.com/win32gui/ #include <assert.h> #include <stdexcept> // #include <win32gui/.hpp> namespace win32 { namespace gui { /* Note: removed dependency on boost, and anyway, boost::function does take a lot to compile */ // note: removed dependency on boost, that's why we need this namespace detail { struct no_param {}; template<class func, class base> struct func_exec : base { typedef typename base::result res; typedef typename base::arg1 arg1; typedef typename base::arg2 arg2; typedef typename base::arg3 arg3; typedef typename base::arg4 arg4; typedef typename base::arg5 arg5; func_exec(func f) : f(f) {} // note: one of these is defined virtual in class base res operator()() { return f(); } res operator()(const arg1 & a1) { return f(a1); } res operator()(const arg1 & a1, const arg2 & a2) { return f(a1,a2); } res operator()(const arg1 & a1, const arg2 & a2, const arg3 & a3) { return f(a1,a2,a3); } res operator()(const arg1 & a1, const arg2 & a2, const arg3 & a3, const arg4 & a4) { return f(a1,a2,a3,a4); } res operator()(const arg1 & a1, const arg2 & a2, const arg3 & a3, const arg4 & a4, const arg5 & a5) { return f(a1,a2,a3,a4,a5); } // overrides the base' class base * clone() const { return new func_exec<func,base>(*this); } private: func f; }; template<class res> struct func_keeper0 { typedef func_keeper0<res> self; typedef res result; typedef no_param arg1; typedef no_param arg2; typedef no_param arg3; typedef no_param arg4; typedef no_param arg5; virtual res operator()() = 0; virtual self * clone() const = 0; }; template<class res, class a1> struct func_keeper1 { typedef func_keeper1<res,a1> self; typedef res result; typedef a1 arg1; typedef no_param arg2; typedef no_param arg3; typedef no_param arg4; typedef no_param arg5; virtual res operator()(const arg1&) = 0; virtual self * clone() const = 0; }; template<class res, class a1, class a2> struct func_keeper2 { typedef func_keeper2<res,a1,a2> self; typedef res result; typedef a1 arg1; typedef a2 arg2; typedef no_param arg3; typedef no_param arg4; typedef no_param arg5; virtual res operator()(const arg1&,const arg2&) = 0; virtual self * clone() const = 0; }; template<class res, class a1, class a2, class a3> struct func_keeper3 { typedef func_keeper3<res,a1,a2,a3> self; typedef res result; typedef a1 arg1; typedef a2 arg2; typedef a3 arg3; typedef no_param arg4; typedef no_param arg5; virtual res operator()(const arg1&,const arg2&, const arg3&) = 0; virtual self * clone() const = 0; }; template<class res, class a1, class a2, class a3, class a4> struct func_keeper4 { typedef func_keeper4<res,a1,a2,a3,a4> self; typedef res result; typedef a1 arg1; typedef a2 arg2; typedef a3 arg3; typedef a4 arg4; typedef no_param arg5; virtual res operator()(const arg1&,const arg2&, const arg3&, const arg4&) = 0; virtual self * clone() const = 0; }; } template<class res> struct func_wrapper0 { typedef res result; typedef detail::no_param arg1; typedef detail::no_param arg2; typedef detail::no_param arg3; typedef detail::no_param arg4; typedef detail::no_param arg5; typedef detail::func_keeper0<res> func_keeper; typedef func_wrapper0<res> self_type; func_wrapper0() : m_f(0) {} template<class func> func_wrapper0(func f) : m_f(new detail::func_exec<func,func_keeper>(f)) {} typedef res (*raw_func)(); func_wrapper0(raw_func f) : m_f(new detail::func_exec<raw_func,func_keeper>(f)){} func_wrapper0(const self_type & other) : m_f(other.m_f ? other.m_f->clone() : 0) {} res operator()() { if ( m_f) return (*m_f)(); else WIN32GUI_THROW std::runtime_error("null function"); } self_type& operator=(const self_type & other) { func_keeper * old = m_f; m_f = other.m_f ? other.m_f->clone() : 0; delete old; return *this; } private: func_keeper * m_f; }; template<class res,class arg1_type> struct func_wrapper1 { typedef res result; typedef arg1_type arg1; typedef detail::no_param arg2; typedef detail::no_param arg3; typedef detail::no_param arg4; typedef detail::no_param arg5; typedef detail::func_keeper1<res,arg1> func_keeper; typedef func_wrapper1<res,arg1> self_type; typedef res (*raw_func)(const arg1&); func_wrapper1() : m_f(0) {} template<class func> func_wrapper1(func f) : m_f(new detail::func_exec<func,func_keeper>(f)) {} func_wrapper1(raw_func f) : m_f(new detail::func_exec<raw_func,func_keeper>(f)){} func_wrapper1(const self_type & other) : m_f(other.m_f ? other.m_f->clone() : 0) {} res operator()(const arg1 &a1) { if ( m_f) return (*m_f)(a1); else WIN32GUI_THROW std::runtime_error("null function"); } self_type& operator=(const self_type & other) { func_keeper * old = m_f; m_f = other.m_f ? other.m_f->clone() : 0; delete old; return *this; } private: func_keeper * m_f; }; template<class res,class arg1_type,class arg2_type> struct func_wrapper2 { typedef res result; typedef arg1_type arg1; typedef arg2_type arg2; typedef detail::no_param arg3; typedef detail::no_param arg4; typedef detail::no_param arg5; typedef detail::func_keeper2<res,arg1,arg2> func_keeper; typedef func_wrapper2<res,arg1,arg2> self_type; typedef res (*raw_func)(const arg1&,const arg2&); func_wrapper2() : m_f(0) {} template<class func> func_wrapper2(func f) : m_f(new detail::func_exec<func,func_keeper>(f)) {} func_wrapper2(raw_func f) : m_f(new detail::func_exec<raw_func,func_keeper>(f)){} func_wrapper2(const self_type & other) : m_f(other.m_f ? other.m_f->clone() : 0) {} res operator()(const arg1 &a1, const arg2 &a2) { if ( m_f) return (*m_f)(a1,a2); else WIN32GUI_THROW std::runtime_error("null function"); } self_type& operator=(const self_type & other) { func_keeper * old = m_f; m_f = other.m_f ? other.m_f->clone() : 0; delete old; return *this; } private: func_keeper * m_f; }; template<class res,class arg1_type,class arg2_type,class arg3_type> struct func_wrapper3 { typedef res result; typedef arg1_type arg1; typedef arg2_type arg2; typedef arg3_type arg3; typedef detail::no_param arg4; typedef detail::no_param arg5; typedef detail::func_keeper3<res,arg1,arg2,arg3> func_keeper; typedef func_wrapper3<res,arg1,arg2,arg3> self_type; typedef res (*raw_func)(const arg1&,const arg2&,const arg3&); func_wrapper3() : m_f(0) {} template<class func> func_wrapper3(func f) : m_f(new detail::func_exec<func,func_keeper>(f)) {} func_wrapper3(raw_func f) : m_f(new detail::func_exec<raw_func,func_keeper>(f)){} func_wrapper3(const self_type & other) : m_f(other.m_f ? other.m_f->clone() : 0) {} res operator()(const arg1 &a1, const arg2 &a2, const arg3 &a3) { if ( m_f) return (*m_f)(a1,a2,a3); else WIN32GUI_THROW std::runtime_error("null function"); } self_type& operator=(const self_type & other) { func_keeper * old = m_f; m_f = other.m_f ? other.m_f->clone() : 0; delete old; return *this; } private: func_keeper * m_f; }; template<class res,class arg1_type,class arg2_type,class arg3_type,class arg4_type> struct func_wrapper4 { typedef res result; typedef arg1_type arg1; typedef arg2_type arg2; typedef arg3_type arg3; typedef arg4_type arg4; typedef detail::no_param arg5; typedef detail::func_keeper4<res,arg1,arg2,arg3,arg4> func_keeper; typedef func_wrapper4<res,arg1,arg2,arg3,arg4> self_type; typedef res (*raw_func)(const arg1&,const arg2&,const arg3&,const arg4&); func_wrapper4() : m_f(0) {} template<class func> func_wrapper4(func f) : m_f(new detail::func_exec<func,func_keeper>(f)) {} func_wrapper4(raw_func f) : m_f(new detail::func_exec<raw_func,func_keeper>(f)){} func_wrapper4(const self_type & other) : m_f(other.m_f ? other.m_f->clone() : 0) {} res operator()(const arg1 &a1, const arg2 &a2, const arg3 &a3, const arg4 &a4) { if ( m_f) return (*m_f)(a1,a2,a3,a4); else WIN32GUI_THROW std::runtime_error("null function"); } self_type& operator=(const self_type & other) { func_keeper * old = m_f; m_f = other.m_f ? other.m_f->clone() : 0; delete old; return *this; } private: func_keeper * m_f; }; /* void f() { std::cout << "f" << std::endl; } void f1(int i) { std::cout << "f1(" << i << ")" << std::endl; } bool f2(int i, char c) { std::cout << "f2(" << i << "," << c << ")" << std::endl; return true; } int f3(int i, char c, char d) { std::cout << "f3(" << i << "," << c << d << ")" << std::endl; return 2; } int f4(int i, char c, char d, char e) { std::cout << "f4(" << i << "," << c << d << e << ")" << std::endl; return 3; } struct titi { titi() : idx(0) {} void operator()() { std::cout << "titi" << idx++ << std::endl; } int idx; }; int main() { func_wrapper0<void> test(&f); test(); titi t; func_wrapper0<void> test2( t ); test2(); func_wrapper0<void> test3( test2 ); test2(); test2(); test3(); func_wrapper0<void> test4; test4 = test3; test4(); test4 = test; test4(); func_wrapper1<void,long> func1(f1); func1(0); func1(2); func_wrapper2<int,long,int> func2(f2); int i = func2(10,97); assert(i == 1); func_wrapper3<int,long,int,char> func3(f3); i = func3(11,97,'b'); assert(i == 2); func_wrapper4<int,long,int,char,char> func4(f4); i = func4(12,97,'b','c'); assert(i == 3); std::cin.get(); return 0; } */ }} #endif // JOHN_TORJO_WIN32GUI_function

4 6

Java style GUI in C++
by Johannes Brunen 19 Aug '04

19 Aug '04

Hi Reece, did you know of the existence of the following list of C++ GUI frameworks? I think they are currently the most important ones. http://www.fltk.org/index.php http://www.fox-toolkit.org/ http://gtkmm.sourceforge.net/ http://inti.sourceforge.net/ http://www.trolltech.com/ http://vcf.sourceforge.net/ http://www.wxwindows.org/ http://www.torjo.com/win32gui/ All of them have some strength and some weaknesses. It may be worth to look at least at the gtkmm, vcf and the win32gui frameworks. Johannes

7 6

boost::noncopyable broken?
by Bronek Kozicki 19 Aug '04

19 Aug '04

Hello when testing some regression errors I updated my second local copy from anonymous CVS @ sf.net (first copy is always from meta-comm and is producing regression tests you can see on www.meta-comm.com) Then I started running some tests, and received many errors similar to following: (vc71) boost\noncopyable.hpp(32) : error C2371: 'boost::noncopyable' : redefinition; different basic types boost\utility_fwd.hpp(26) : see declaration of 'boost::noncopyable' boost\test\unit_test_log.hpp(138) : error C2504: 'boost::noncopyable' : base class undefined (como-win32-4.3.3-vc7.1) boost/noncopyable.hpp", line 32: error #256: invalid redeclaration of type name "boost::noncopyable" (declared at line 26 of "boost/utility_fwd.hpp") typedef noncopyable_::noncopyable noncopyable; ^ I then took archived boost.tar.bz2 from meta-comm (boost-04-08-18-1200) and found the same error in this archive. Fortunatelly I also have older copy of this archive (boost-04-08-18-0600) and this archive is currently used to produce regression tests you will see soon - without error mentioned above. Apparently boost::noncopyable (or test unit?) got broken somewhere between Aug 18th 06:00 and Aug 18th 12:00 (I do not know what timezone) and this will produce many errors in next regression tests run. Unless it's quickly fixed. B.

2 2

link in python docs
by John Maddock 18 Aug '04

18 Aug '04

Dave, In libs/python/doc/tutorial/index.html there is: <link rel="next" href="quickstart.html"> But the file quickstart.html does not exist - and this is fooling bcp, I assume that it should point to doc/quickstart.html ? Whatever it should be can you fix? Thanks, John.

3 2

Boost Software License Progress As Of 20040817
by Stephan T. Lavavej 18 Aug '04

18 Aug '04

http://stl.nuwen.net/bsl3.html (now with serialization, though not python) * 5037 BSLed files. * 39 files converted which have to be manually verified. * 1 file that could be converted, but hasn't yet been. That's boost/variant/detail/move.hpp. It's dual-copyrighted and dual-licensed, but both Eric Friedman and Andrei Alexandrescu are now in blanket-permission.txt. The file should be converted. * 619 files that cannot be converted yet. * 83 files without a recognizable license (including files from format, lambda, pending, any, graph, iterator, mpl, property_map, and utility). * 248 files without a recognizable copyright holder (all mpl, except for one file from serialization, where bcp is getting confused - that's got a copyright and a variant of the BSL). Still need many authors for the BSL. [David Abrahams] > What do you mean? What was broken? python and serialization used to cause bcp to fail. serialization has since been fixed, but something is still wrong with python: **** exception(205): std::runtime_error: Bad file name: libs\python\doc\tutorial\quickstart.html ******** errors detected; see standard output for details ******** [John Maddock] > Done, I've added the Aliases to blanket-permission.txt, and > fixed up the regex scanning to pick up on Robert Ramey's web > address. Cool! > I use "." as the module name, of course then it flags up a > whole load of new problems :-( I tried what you suggest, but it didn't work: C:\Temp\boost\boost>..\bcp --report . bsl4.html **** exception(205): std::exception: boost::filesystem::is_directory: ":sys:stat.h": The parameter is incorrect. ******** errors detected; see standard output for details ******** If you know how to scan everything, perhaps you could post the results? The recent flurry of additions to blanket-permission.txt is /awesome/. Thanks, Stephan T. Lavavej [I don't speak for Microsoft]

4 5

Fw: Boost
by John Maddock 18 Aug '04

18 Aug '04

Another permission: ----- Original Message ----- From: "Maarten" <mkeijzer(a)xs4all.nl> To: <boost-owner(a)lists.boost.org> Sent: Wednesday, August 18, 2004 8:30 PM Subject: Boost > License Permission > Date: Wed, 18 Aug 2004 21:30:43 +0200 > User-Agent: KMail/1.6.2 > MIME-Version: 1.0 > Content-Disposition: inline > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: 7bit > Message-Id: <200408182130.43251.mkeijzer(a)xs4all.nl> > Status: R > X-Status: NQ > X-KMail-EncryptionState: > X-KMail-SignatureState: > X-KMail-MDN-Sent: > > I Maarten Keijzer, give > permission for all my contributions to Boost to be moved to the > Boost Software License Version 1 > > I think this involves a single file in the detail section of the > interval library. FYI. > > -Maarten- >

1 0

Re: lightweight replacement for boost::function
by Max Khesin 18 Aug '04

18 Aug '04

John, just in case you missed this there is a similar effort happening here (from a competing GUI library!): http://tinytl.sourceforge.net/ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

python/embedding fails under Intel 8
by Stefan Slapeta 18 Aug '04

18 Aug '04

Maybe somebody who is more experienced with boost.python than me could have a look at this: http://tinyurl.com/6p8zf. Thanks, Stefan

3 7

RE: [boost] Re: ETI bug and iterators
by Yitzhak Sapir 18 Aug '04

18 Aug '04

> -----Original Message----- > From: David Abrahams > > "Yitzhak Sapir" writes: > > > I can't send my own code, but the following code causes the > > previously described error with an unpatched minimum_category.hpp > > and an ICE when compiled with patched and unpatched > > minimum_category.hpp: > > Not for me. Of course I had to remove the include of stdafx.h since > I don't have that, but the first error is: > > Dave Abrahams The problem is with debug STLPort iterators, not the pointer iterators that you get in non-debug iterators mode. Yes, release compiles fine for me with the additional BOOST_TT_BROKEN_COMPILER_SPEC. But I also want to be able to compile in debug, with the debug STLPort iterators. :-) Also, when I speak of ETI workarounds removed, I speak only of the #ifdefed lines in the following block: typedef minimum_category_impl< # if BOOST_WORKAROUND(BOOST_MSVC, == 1200) // ETI workaround is_same<T2,int>::value || # endif ::boost::is_convertible<T1,T2>::value , ::boost::is_convertible<T2,T1>::value # if BOOST_WORKAROUND(BOOST_MSVC, == 1200) // ETI workaround || is_same<T1,int>::value # endif > outer; I didn't notice there was another ETI workaround before.

2 1

algorithm/minmax_element regression with Comeau
by Bronek Kozicki 18 Aug '04

18 Aug '04

Following error http://tinyurl.com/5t7cj is due to too strict requirements of libcomo (at least I believe so). I received fix from Comeau Computing (stl_algo.h, too large to send as attachment with this message) and deployed it, tommorow we shall see this error gone. Again, I deployed it without stopping regression tests, thus next results in como-win32-4.3.3-vc7.1 may be screwed. B.

2 1

Suggestion for weak_ptr's
by Jeff Williams 18 Aug '04

18 Aug '04

Simply small change, curious as to what others think: I'll illustrate with a trivial example: struct foo { virtual ~foo() { } }; struct bar : foo { }; typedef shared_ptr<foo> fooptr; typedef shared_ptr<bar> barptr; void some_func(weak_ptr<foo> wf) { barptr pb = wf.lock<bar>(); } // currently the way to do this is (as I am sure everyone knows) void some_func(weak_ptr<foo> wf) { barptr pb = dynamic_pointer_cast<bar>(wf.lock()); } My suggestion seems easier to read. Would require no additional overhead and would preserve existing behavior. I suppose you could provide a static and dynamic version: lock_static<bar> and lock_dynamic<bar> Any thoughts? Or is the general concensus that ideas like this are something indivudual people should do in their own source? Jeff

3 2

Intel: different macros for Windows and Linux
by Stefan Slapeta 18 Aug '04

18 Aug '04

I would like to introduce different config macros for the windows and linux version of ICL which should be defined like BOOST_INTEL. The names should be BOOST_INTEL_WIN and BOOST_INTEL_LINUX. It's just to improve the control over the completely different front ends of these compilers.... (actually they are two different compilers. In many cases it doesn't make sense to make behaviour dependent on "the" Intel compiler!) OK to commit? Stefan --- intel.hpp 29 Jun 2004 10:19:27 -0000 1.36 +++ intel.hpp 18 Aug 2004 10:00:24 -0000 @@ -29,6 +29,12 @@ #define BOOST_COMPILER "Intel C++ version " BOOST_STRINGIZE(BOOST_INTEL_CXX_VERSION) #define BOOST_INTEL BOOST_INTEL_CXX_VERSION +#ifdef _WIN32 +# define BOOST_INTEL_WIN BOOST_INTEL +#else +# define BOOST_INTEL_LINUX BOOST_INTEL +#endif + #if (BOOST_INTEL_CXX_VERSION <= 500) && defined(_MSC_VER) # define BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS # define BOOST_NO_TEMPLATE_TEMPLATES

2 3

[boost-sandbox] deleting old stuff
by Thorsten Ottosen 18 Aug '04

18 Aug '04

Hi all, Does anybody know a quick way fo deleting old libaries in the sandbox? Thanks Thorsten

2 2

RE: [boost] Re: ETI bug and iterators
by Yitzhak Sapir 18 Aug '04

18 Aug '04

> -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > > "Yitzhak Sapir" <yitzhak.sapir(a)actimize.com> writes: > > >> -----Original Message----- > >> From: David Abrahams > >> > >> "Yitzhak Sapir" <yitzhak.sapir(a)actimize.com> writes: > >> > >> > Hello. > >> > > >> > I am in the process of upgrading code to use boost 1.31.0 > >> for MSVC6.5. > >> > During this process I happened upon minimum_category.hpp which > >> > contains "ETI workarounds". Now, it seems that the ETI > workarounds > >> > cause the compilation to fail, with the error message: constant > >> > expression expected. Particularly, we are creating zip > iterators to > >> > two STLPort vectors. In debug iterator mode, I get the following > >> > error. (minimum_category.hpp was modified a bit > >> > >> Post the error you get with an unmodified minimum_category.hpp, > >> please. It's hard to analyze when the line numbers are wrong. > >> > > > > ../../3rdParty\boost/iterator/detail/minimum_category.hpp(86) : > > error C2039: 'apply' : is not a member of > > '?$minimum_category_impl@$$00' > > Does the enclosed patch fix it? > No. I get the following: ../../3rdParty\boost/iterator/detail/facade_iterator_category.hpp(146) : error C2516: 'Traversal' : is not a legal base class ../../3rdParty\boost/iterator/detail/facade_iterator_category.hpp(145) : see declaration of 'Traversal' C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\stlport\stl/_algobase.c(196) : see reference to class template instantiation 'boost::detail::iterator_category_with_traversal<struct _STL::output_iterator_tag,int>' being compiled I can't send my own code, but the following code causes the previously described error with an unpatched minimum_category.hpp and an ICE when compiled with patched and unpatched minimum_category.hpp: #include "stdafx.h" #include <boost/iterator/zip_iterator.hpp> #include <boost/tuple/tuple.hpp> #include <vector> #include <algorithm> class c1 {}; class c2 {}; typedef std::vector<c1> c1_vec_t; typedef std::vector<c2> c2_vec_t; using namespace boost; void f(const tuples::tuple<c1, c2>& param) { } int main(int argc, char* argv[]) { c1_vec_t vec1; c2_vec_t vec2; make_zip_iterator(make_tuple(vec1.begin(), vec2.begin())); return 0; } If the ETI workarounds in minimum_category.hpp are removed the above code compiles fine.

2 1

Problem with boost::iterator_value
by Alex Chovanec 18 Aug '04

18 Aug '04

Hi, The following code does not compile under vc7.0-stlport-4.6.2: struct foo {}; typedef std::vector<int> vector_int; typedef std::vector<foo> vector_foo; BOOST_STATIC_ASSERT(( boost::is_same< int, boost::iterator_value<vector_int::iterator>::type>:: value)); BOOST_STATIC_ASSERT(( boost::is_same< foo, boost::iterator_value<vector_foo::iterator>::type>:: value)); Obviously, neither of these assertions should fail, but the second one does. I'm guessing that this is a problem with boost::iterator_value. Does anyone know how to fix this? Thanks, Alex

3 2

[boost.range] post-review
by Thorsten Ottosen 18 Aug '04

18 Aug '04

Dear All, Finally I have written the documentation for boost.range. Everyone who is interested should take a look at it all in the cvs and let me know what you think. (If you don't have cvs access, just mail me so I can send it) There is one major decisions that I think should be decided upon in this post-review, ans it is about naming. The boost iterators new iterator traits has this naming scheme: iterator_value<T>::type iterator_difference<T>::type I have used this scheme (originally proposed by Peter Dimov) iterator_of<T>::type value_type_of<T>::type. The question is now if the range librray should do as the iterator library, ie, prefix everyhitng with "range_": range_iterator<T>::type range_value_type<T>::type etc. br Thorsten

8 25

intrinsice 64 bit integers
by Robert Ramey 18 Aug '04

18 Aug '04

In testing the serialization library it has come to my attention that at least the two compilers on 64 bit platforms use something like typedef long int int64_t; typedef long unsigned int uint64_t; This is causing me some problems. At the same time some compilers have typedef short int wchar_t; This would cause similar problems for me except for the fact that we have BOOST_NO_INTRINSIC_WCHAR_T So I can skip over them at the preprocessor level. Is there any reason we can't add to the config files? BOOST_NO_INTRINSIC_INT64 BOOST_NO_INTRINSIC_UINT64 Robert Ramey

2 1

Passing variables to bjam when run by regression.py?
by Markus Schöpflin 18 Aug '04

18 Aug '04

Hello, I need to pass some variables (PYTHON_...) to bjam in order to compile the python tests. When invoking bjam directly, boost.build picks up those variables from the environment automatically. When running the regression tests with regression.py, the environment variables seem to be ignored, because I get a warning that my python installation is not found. How do I pass environment variables to boost.build when running it from regression.py? Or is there some other way to pass arguments to bjam when it is run by regression.py? TIA, Markus

1 0

Metacomm STLport regressions generally failing
by Michael Stevens 18 Aug '04

18 Aug '04

Hi Aleksey, It seems that the STLport tests 'msvc- stlport' and 'intel- win32- 7.1- vc6- stlport- 4.5.3' for many libraries are failing with the same error. They report the library 'stlport_vc6_stldebug.lib' as missing. No idea why this should be! Thanks for the great work and very useful test runs. I'm grinding uBLAS back to VC6 compaitbility! Michael

1 0

Metacomm
by Michael Stevens 18 Aug '04

18 Aug '04

intel- win32- 7.1- vc6- stlport- 4.5.3 msvc- stlport -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

RE: [boost] Re: ETI bug and iterators
by Yitzhak Sapir 18 Aug '04

18 Aug '04

> -----Original Message----- > From: Yitzhak Sapir > I can't send my own code, but the following code causes the > previously described error with an unpatched > minimum_category.hpp and an ICE when compiled with patched > and unpatched minimum_category.hpp: I meant an ICE with patched only. Sorry about that.

1 0

RE: [boost] Re: [boost.test] Patch for true64cxx65 support.
by Rozental, Gennadiy 18 Aug '04

18 Aug '04

> Because I get duplicated symbols when linking otherwise. > Therefore you > need to use either > > c_literal_string LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; > > or > > literal_string const LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; > > in the header file. > > Markus I would unconditionally add static to all parameter definitions instead. Gennadiy.

2 1

[inspect] Update on inspection tests...
by Rene Rivera 18 Aug '04

18 Aug '04

Here's a summary of the latest state of the Boost tree: 8101 files scanned 680 directories scanned 221 problems reported problem counts: 1 files with invalid line endings 0 bookmarks with invalid characters 1 invalid urls 99 broken links 46 unlinked files 60 file names too long 14 files with tabs As you can see some TABS have crept in. And a fair number of files break the 31 character limit. And for license and copyrights: 8101 files scanned 680 directories scanned 4657 problems reported problem counts: 3230 files missing Boost license info 1427 files missing copyrights Slowly but surely it's improving. More details at: http://www.boost.org/regression-logs/ -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

RE: [boost] [boost.test] Patch for true64cxx65 support.
by Rozental, Gennadiy 17 Aug '04

17 Aug '04

> Hello, > > attached is a patch which makes boost.test work for the > beforementioned > toolset. It contains a workaround for the internal compiler > error currently > preventing any tests from running. Could anyone please apply > it, if it's ok? > > Thanks, Markus Why do you need anything more then: +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590041)) +typedef const_string literal_string; +#else typedef const_string const literal_string; +#endif Gennadiy

2 1

Fw: Rational Discovery LLC Copyrights?
by John Maddock 17 Aug '04

17 Aug '04

Another permission for our records: ----- Original Message ----- From: "Greg Landrum" <Landrum(a)RationalDiscovery.com> To: "David Abrahams" <dave(a)boost-consulting.com>; "John Maddock" <john(a)johnmaddock.co.uk> Sent: Monday, August 16, 2004 3:37 PM Subject: Re: Rational Discovery LLC Copyrights? > At 07:14 AM 8/16/2004, David Abrahams wrote: > >"John Maddock" <john(a)johnmaddock.co.uk> writes: > > > > > Dave, > > > > > > I see that you committed two files copyright "Rational Discovery LLC" > > > (libs/python/test/crossmod_exception_a.cpp > > > libs/python/test/crossmod_exception_b.cpp). Do you know who we need to > > > contact to get permission to change these to the BSL? > > > >These are Greg Landrum's. I am not certain how to reach him, but I > >Cc'd all the likely emails I could find. > > Feel free to change the copyright/license statements as is necessary. > > Best Regards, > Greg Landrum > President > Rational Discovery LLC > > >

3 4

RE: [boost] Re: ETI bug and iterators
by Yitzhak Sapir 17 Aug '04

17 Aug '04

> -----Original Message----- > From: David Abrahams > > "Yitzhak Sapir" <yitzhak.sapir(a)actimize.com> writes: > > > Hello. > > > > I am in the process of upgrading code to use boost 1.31.0 > for MSVC6.5. > > During this process I happened upon minimum_category.hpp which > > contains "ETI workarounds". Now, it seems that the ETI workarounds > > cause the compilation to fail, with the error message: constant > > expression expected. Particularly, we are creating zip iterators to > > two STLPort vectors. In debug iterator mode, I get the following > > error. (minimum_category.hpp was modified a bit > > Post the error you get with an unmodified minimum_category.hpp, > please. It's hard to analyze when the line numbers are wrong. > ../../3rdParty\boost/iterator/detail/minimum_category.hpp(86) : error C2039: 'apply' : is not a member of '?$minimum_category_impl@$$00' ../../3rdParty\boost/iterator/detail/minimum_category.hpp(97) : see reference to class template instantiation 'boost::detail::minimum_category<struct boost::random_access_traversal_tag,struct boost::random_access_traversal_tag>' being compil ed ../../3rdParty\boost/mpl/aux_/preprocessed/msvc60/apply.hpp(88) : see reference to class template instantiation 'boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >::apply<struct boost::random_access_travers al_tag,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/mpl/aux_/preprocessed/msvc60/apply.hpp(101) : see reference to class template instantiation 'boost::mpl::aux::msvc_apply2<struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> > >::re sult_<struct boost::random_access_traversal_tag,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/iterator/zip_iterator.hpp(173) : see reference to class template instantiation 'boost::mpl::apply2<struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >,struct boost::random_access_ traversal_tag,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/mpl/aux_/preprocessed/msvc60/apply.hpp(9) : see reference to class template instantiation 'boost::detail::tuple_impl_specific::tuple_meta_accumulate_impl<struct boost::tuples::cons<struct boost::random_access_traversal_t ag,struct boost::tuples::null_type>,struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/mpl/apply_if.hpp(39) : see reference to class template instantiation 'boost::mpl::apply0<struct boost::detail::tuple_impl_specific::tuple_meta_accumulate_impl<struct boost::tuples::cons<struct boost::random_access_traver sal_tag,struct boost::tuples::null_type>,struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >,struct boost::random_access_traversal_tag> >' being compiled ../../3rdParty\boost/iterator/zip_iterator.hpp(198) : see reference to class template instantiation 'boost::mpl::apply_if<struct boost::mpl::or_<struct boost::is_same<struct boost::tuples::cons<struct boost::random_access_traversal_tag,struc t boost::tuples::null_type>,struct boost::tuples::null_type>,struct boost::is_same<struct boost::tuples::cons<struct boost::random_access_traversal_tag,struct boost::tuples::null_type>,int>,struct boost::mpl::bool_<0>,struct boost::mpl::bool_<0>,str uct boost::mpl::bool_<0> >,struct boost::mpl::identity<struct boost::random_access_traversal_tag>,struct boost::detail::tuple_impl_specific::tuple_meta_accumulate_impl<struct boost::tuples::cons<struct boost::random_access_traversal_tag,struct boost ::tuples::null_type>,struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >,struct boost::random_access_traversal_tag> >' being compiled > > but the problem is > > in the instantiation of boost::is_same<T1 or T2,int>). > ^^^^^^^^ > > Huh? That's not valid regardless of any ETI workarounds. > That was my attempt to shorthand "either boost::is_same<T1,int> or boost::is_same<T2,int>"

2 1

[boost.test] Patch for true64cxx65 support.
by Markus Schöpflin 17 Aug '04

17 Aug '04

Hello, attached is a patch which makes boost.test work for the beforementioned toolset. It contains a workaround for the internal compiler error currently preventing any tests from running. Could anyone please apply it, if it's ok? Thanks, Markus diff -ru boost-04-08-17-0400/boost/test/detail/basic_cstring/basic_cstring_fwd.hpp boost-cvs/boost/test/detail/basic_cstring/basic_cstring_fwd.hpp --- boost-04-08-17-0400/boost/test/detail/basic_cstring/basic_cstring_fwd.hpp 2004-07-19 14:28:17.000000000 +0200 +++ boost-cvs/boost/test/detail/basic_cstring/basic_cstring_fwd.hpp 2004-08-17 17:39:02.000000000 +0200 @@ -16,13 +16,21 @@ #ifndef BASIC_CSTRING_FWD_HPP_071894GER #define BASIC_CSTRING_FWD_HPP_071894GER +#include <boost/detail/workaround.hpp> + namespace boost { namespace unit_test { template<class CharT> class basic_cstring; typedef basic_cstring<char const> const_string; + +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590041)) +typedef const_string literal_string; +#else typedef const_string const literal_string; +#endif + typedef char const* const c_literal_string; } // namespace unit_test diff -ru boost-04-08-17-0400/boost/test/detail/unit_test_parameters.hpp boost-cvs/boost/test/detail/unit_test_parameters.hpp --- boost-04-08-17-0400/boost/test/detail/unit_test_parameters.hpp 2004-07-19 14:24:32.000000000 +0200 +++ boost-cvs/boost/test/detail/unit_test_parameters.hpp 2004-08-17 17:33:31.000000000 +0200 @@ -25,19 +25,41 @@ namespace unit_test { // framework parameters and there corresponding command-line arguments -literal_string LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; // --log_level -literal_string NO_RESULT_CODE = "BOOST_TEST_RESULT_CODE"; // --result_code -literal_string REPORT_LEVEL = "BOOST_TEST_REPORT_LEVEL"; // --report_level -literal_string TESTS_TO_RUN = "BOOST_TESTS_TO_RUN"; // --run_test -literal_string SAVE_TEST_PATTERN = "BOOST_TEST_SAVE_PATTERN"; // --save_pattern -literal_string BUILD_INFO = "BOOST_TEST_BUILD_INFO"; // --build_info -literal_string CATCH_SYS_ERRORS = "BOOST_TEST_CATCH_SYSTEM_ERRORS"; // --catch_system_errors -literal_string REPORT_FORMAT = "BOOST_TEST_REPORT_FORMAT"; // --report_format -literal_string LOG_FORMAT = "BOOST_TEST_LOG_FORMAT"; // --log_format -literal_string OUTPUT_FORMAT = "BOOST_TEST_OUTPUT_FORMAT"; // --output_format - -enum report_level { CONFIRMATION_REPORT, SHORT_REPORT, DETAILED_REPORT, NO_REPORT, UNDEF_REPORT }; -literal_string report_level_names[] = { "confirm" , "short" , "detailed" , "no" }; +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590041)) +// Needed because literal_string must not be const, you get multiple defined +// symbols otherwise. (see 'basic_cstring_fwd.hpp') As an alternative, +// 'c_literal_string' could be replaced by 'literal_string const' as well. +c_literal_string LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; // --log_level +c_literal_string NO_RESULT_CODE = "BOOST_TEST_RESULT_CODE"; // --result_code +c_literal_string REPORT_LEVEL = "BOOST_TEST_REPORT_LEVEL"; // --report_level +c_literal_string TESTS_TO_RUN = "BOOST_TESTS_TO_RUN"; // --run_test +c_literal_string SAVE_TEST_PATTERN = "BOOST_TEST_SAVE_PATTERN"; // --save_pattern +c_literal_string BUILD_INFO = "BOOST_TEST_BUILD_INFO"; // --build_info +c_literal_string CATCH_SYS_ERRORS = "BOOST_TEST_CATCH_SYSTEM_ERRORS"; // --catch_system_errors +c_literal_string REPORT_FORMAT = "BOOST_TEST_REPORT_FORMAT"; // --report_format +c_literal_string LOG_FORMAT = "BOOST_TEST_LOG_FORMAT"; // --log_format +c_literal_string OUTPUT_FORMAT = "BOOST_TEST_OUTPUT_FORMAT"; // --output_format +#else +literal_string LOG_LEVEL = "BOOST_TEST_LOG_LEVEL"; // --log_level +literal_string NO_RESULT_CODE = "BOOST_TEST_RESULT_CODE"; // --result_code +literal_string REPORT_LEVEL = "BOOST_TEST_REPORT_LEVEL"; // --report_level +literal_string TESTS_TO_RUN = "BOOST_TESTS_TO_RUN"; // --run_test +literal_string SAVE_TEST_PATTERN = "BOOST_TEST_SAVE_PATTERN"; // --save_pattern +literal_string BUILD_INFO = "BOOST_TEST_BUILD_INFO"; // --build_info +literal_string CATCH_SYS_ERRORS = "BOOST_TEST_CATCH_SYSTEM_ERRORS"; // --catch_system_errors +literal_string REPORT_FORMAT = "BOOST_TEST_REPORT_FORMAT"; // --report_format +literal_string LOG_FORMAT = "BOOST_TEST_LOG_FORMAT"; // --log_format +literal_string OUTPUT_FORMAT = "BOOST_TEST_OUTPUT_FORMAT"; // --output_format +#endif + +enum report_level { CONFIRMATION_REPORT, SHORT_REPORT, DETAILED_REPORT, NO_REPORT, UNDEF_REPORT }; + +#if BOOST_WORKAROUND(__DECCXX_VER, BOOST_TESTED_AT(60590041)) +// See comment on workaround above. +c_literal_string report_level_names[] = { "confirm" , "short" , "detailed" , "no" }; +#else +literal_string report_level_names[] = { "confirm" , "short" , "detailed" , "no" }; +#endif enum output_format { HRF /* human readable format */, XML /* XML */ };

1 0

Fw: Re your copyright in Boost C++ Library
by John Maddock 17 Aug '04

17 Aug '04

And yet another permission.... ----- Original Message ----- From: "Lars Gullik Bjønnes" <larsbj(a)lyx.org> To: "John Maddock" <john(a)johnmaddock.co.uk> Sent: Tuesday, August 17, 2004 1:57 PM Subject: Re: Re your copyright in Boost C++ Library > "John Maddock" <john(a)johnmaddock.co.uk> writes: > > >> | Hi, if you are receiving this message it is because there are one or > | more > >> | files in the Boost C++ libraries that contain your copyright > | declaration. > >> > >> I belive that my name (and copyright) should just be removed from > >> those files. > > > | Are you sure? > > If it is ok by you, yes. > (if not just add me to the blanket file. Or do that anyway...) > > > > | You can view the two files here: > > > | http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/detail/atomic_count… > | http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/detail/lwm_gcc.hpp?… > > > | cvs revision history suggests that the implementation originally came from > | you? > > It is really something of an super simple adaptation of code that was > already in boost. And I belive that this has be rewritten a bit since > even. (and it is even buggy... or so they say :-) ) > > -- > Lgb >

1 0

Fw: Re your copyright in Boost C++ Library
by John Maddock 17 Aug '04

17 Aug '04

Another permission for out records... ----- Original Message ----- From: "Nikolay Mladenov" <nickm(a)sitius.com> To: <boost-owner(a)lists.boost.org> Sent: Tuesday, August 17, 2004 3:03 PM Subject: Re: Re your copyright in Boost C++ Library > I Nikolay Mladenov, give > permission for all my contributions to Boost to be moved to the Boost > Software License Version 1 >

1 0

ETI bug and iterators
by Yitzhak Sapir 17 Aug '04

17 Aug '04

Hello. I am in the process of upgrading code to use boost 1.31.0 for MSVC6.5. During this process I happened upon minimum_category.hpp which contains "ETI workarounds". Now, it seems that the ETI workarounds cause the compilation to fail, with the error message: constant expression expected. Particularly, we are creating zip iterators to two STLPort vectors. In debug iterator mode, I get the following error. (minimum_category.hpp was modified a bit, but the problem is in the instantiation of boost::is_same<T1 or T2,int>). If I remove the ETI "workarounds" the code compiles fine. So my question is what is ETI, what does the ETI workaround provide, and how can I benefit from both the workaround and normal use of the code? The code looks something like: std::find(boost::make_zip_iterator(boost::make_tuple(vector1.begin(), vector2.begin())), boost::make_zip_iterator(boost::make_tuple(vector1.end(), vector2.end())), ... The beginning of the error looks something like this: ./../3rdParty\boost/iterator/detail/minimum_category.hpp(86) : error C2057: expected constant expression ../../3rdParty\boost/iterator/detail/minimum_category.hpp(112) : see reference to class template instantiation 'boost::detail::minimum_category<struct boost::random_access_traversal_tag,struct boost::random_access_traversal_tag>' being compi led ../../3rdParty\boost/mpl/aux_/preprocessed/msvc60/apply.hpp(88) : see reference to class template instantiation 'boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >::apply<struct boost::random_access_travers al_tag,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/mpl/aux_/preprocessed/msvc60/apply.hpp(101) : see reference to class template instantiation 'boost::mpl::aux::msvc_apply2<struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> > >::re sult_<struct boost::random_access_traversal_tag,struct boost::random_access_traversal_tag>' being compiled ../../3rdParty\boost/iterator/zip_iterator.hpp(173) : see reference to class template instantiation 'boost::mpl::apply2<struct boost::detail::minimum_category<struct boost::mpl::arg<1>,struct boost::mpl::arg<2> >,struct boost::random_access_ traversal_tag,struct boost::random_access_traversal_tag>' being compiled Thanks.

2 1

CVS at boost-consulting.com
by Christoph Ludwig 17 Aug '04

17 Aug '04

Hi, my Boost CVS working directory used to be rooted at :pserver:anonymous@boost-consulting.com:/boost. However, for some time I didn't get any updates any more. Since it's not plausible that there were no check-ins in the last week I checked out the boost directory from SourceForge. And indeed, there are many differences between the two working directories. For instance: After `cvs up' I have revision 1.4 of boost/algorithm/string/classification.hpp in the working directory rooted at boost-consulting and its status is up-to-date according to `cvs stat' (no sticky tag or date). But in the working directory rooted at sourceforge there's revision 1.5. `cvs log' says it was checked in on 2004-07-30. Even if the CVS at boost-consulting is mirrored only once a day, revision 1.5 of boost/algorithm/string/classification.hpp should be in the repository by now. Do others experience the same problem? Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

2 1

[Boost-bugs] [ boost-Bugs-1010681 ] boost::filesystem::exists is broken on cygwin
by SourceForge.net 17 Aug '04

17 Aug '04

Bugs item #1010681, was opened at 2004-08-17 14:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1010681&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Carlo Wood (libcw) Assigned to: Nobody/Anonymous (nobody) Summary: boost::filesystem::exists is broken on cygwin Initial Comment: Compile the following code snippet: #include <iostream> #include <boost/filesystem/path.hpp> #include <boost/filesystem/operations.hpp> int main() { boost::filesystem::path p = "/usr"; if (!boost::filesystem::exists(p)) std::cerr << p.string() << " doesn't exist according to boost::filesystem" << std::endl; } $ uname -a CYGWIN_NT-5.0 vmware 1.5.10(0.116/4/2) 2004-05-25 22:07 i686 unknown unknown Cygwin $ g++ -g -I"/usr/src/install/3.3.1/include/boost-1_31" test.cc -L"/usr/src/install/3.3.1/lib" -lboost_filesystem-gcc-d-1_31 $ ./a.exe /usr doesn't exist according to boost::filesystem Needless to say that /usr does exist: $ ls -ld /usr drwxrwxrwx+ 18 carlo Gebruike 4096 Aug 8 14:49 /usr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1010681&group_… ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: tru64 ICE
by David Abrahams 17 Aug '04

17 Aug '04

Daveed Vandevoorde <daveed(a)edg.com> writes: > Hello, > > On Aug 16, 2004, at 2:57 PM, David Abrahams wrote: > [...] >> This construct is causing tru64cxx6.5 to ICE. Is there any chance >> this is an old bug of yours for which you know a workaround, or is it >> all Compaq? > > We couldn't get it to abort in our released versions > of the last few years. So our suspicion is that this > is a Compaq-specific issue. > > Is there anything in the wording of the internal error > message (if any) that would indicate that it originates > in an EDG front end? Nobody showed me the actual error, so I can say. Sorry :( Thanks for looking at this. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

[boost.test] basic_cstring troubles with tru64cxx65
by Markus Schöpflin 17 Aug '04

17 Aug '04

I think I have found the source of the internal compiler errors currently preventing boost.test to work with the toolset tru64cxx65. The following small sample fails to compile and gives me an internal compiler error when compiled with cxx. ---%<--- #include <boost/test/detail/basic_cstring/basic_cstring.hpp> using namespace boost::unit_test; // void foo(const_string const & s) // ok void foo(const_string s) // not ok { } int main() { foo(literal_string("foo")); return 0; } --->%--- Changing the declaration of foo() makes the compiler error go away. I'm currently thinking that the compiler perhaps has problems with the automatically generated copy constructors for the class basic_cstring. I tried writing an explicit copy constructor for basic_cstring but this doesn't seem to help. The compiler still crashes. Maybe someone else working with this platform has any ideas... Markus

2 3

Re: [boost] Re: 31 character limit for filenames
by Steve Ramsey 17 Aug '04

17 Aug '04

On Mon, 16 Aug, 2004, at 11:34 pm, Miro Jurisic wrote: > Steve Ramsey <steve(a)lucena.com> wrote: >> FSRefs can only refer to pre-existing file system objects - this >> merited a >> single sentence in a single tech note far away from the File Manager >> documentation - which makes them bloody useless for general path >> conversions. > > You probably want CFURL APIs for path conversions. However, you should > explain a > little more what you mean by path conversions, as there are some > non-trivial and > very subtle issues regarding HFS paths and Unicode characters. (But > they may be > completely irrelevant to you, which is why I ask what you mean.) I'm not sure sure how helpful the CFURL stuff is for what I'm doing, as I'm not sure there's an easy way to get HFS paths out of them when running under OS X (as I hinted before, why on earth would you want an HFS path at all under OS X, except to make the MSL happy). The path conversion was an obscure reference to one of my failed cunning plans to convert POSIX paths to HFS paths by having FSPathMakeRef/FSRefMakePath do the work for me; I was toggling the gestaltFSUsesPOSIXPathsForConversion bit in the gestaltFSAttr Gestalt selector between calls. This fails in the general case since FSRefs can't refer to non-existent objects, but it neatly side-steps the text encoding issues when the object does exist. In the absence of system-level hacks, I'm hoping this sort of path conversion isn't the answer. I'm now looking into re-writing certain low-level MSL source files such as path2fss.c to use POSIX paths instead of HFS paths, as there is precedent for Boost libraries providing alternative MSL files to overcome certain deficiencies (boost::thread, for example). Really, though, at this point I'm just fishing while I wait for an elegant solution to suggest itself, where elegant is something other than writing off the MSL for Mac development. Here's a quick summary of what I'm dealing with: the goal is to be able to use boost::filesystem with Metrowerks CodeWarrior and the Metrowerks StdLib/STL implementation, MSL, on a CFM Carbon program intended to run under OS 9 and OS X. Ideally, only a source implementation should be necessary, and the interface files and MSL source should be off-limits (although I'm thinking some interface files needs to be changed to be more generic, e.g. handle-body idiom for path, or I need to throw this restriction out and just litter the interface files with more preprocessor conditionals and give the classes target-specific privates). The POSIX path will not work in this scenario since the MSL uses HFS paths (HFS paths: multi-root, colon delimiters, specify relative paths in the reverse fashion of POSIX, often Pascal strings in Carbon API calls, C strings in MSL calls). You can get a lot of mileage out of a proper rewrite of fs::path::native_file_string, but for total compliance work also needs to be done in fs::operations. Without system-level conversions to handle all the gritty details, the key solution here will probably be to write a heroically specialized manual HFS<->POSIX path converter that takes into account things like multiple roots (e.g., faking a /Volumes directory under OS 9), File Manager name mangling, and possible weird issues with aliases and symbolic links (mmm...cross-volume aliases). I'd _really_ like to avoid going this route... Steve

2 1

Re: [boost] 31 character limit for filenames
by Steve Ramsey 17 Aug '04

17 Aug '04

On Mon, 16 Aug, 2004, 9:03 am, Doug Gregor wrote: > Okay, it's time to ask again: do we still need to enforce the > 31-character limit on filenames? AFAIK, we have this for MacOS 9, only. > Is that platform still significant for Boost users? I believe that the native file name size for ISO 9660 Level 2 is also 31 (32) characters, which affects a whole lot of CDs. What library does this relate to? There might be an easy way to provide an extension, depending on intended use. Speaking of Macs and filenames, has anyone created a successful implementation of boost::filesystem for use with the Metrowerks MSL? I've been trying to shoehorn one into the filesystem interfaces for a week, now, and I'm alternately cursing Metrowerks and Apple. This might be the final indignity that finally drives me away from CFM and the MSL and into the prickly, awkward arms of Mach-O and the BSD stdlib. Two highlights of my wobbly path: 1) MSL only supports HFS paths, even for POSIX-alike functions; 2) FSRefs can only refer to pre-existing file system objects - this merited a single sentence in a single tech note far away from the File Manager documentation - which makes them bloody useless for general path conversions. Right now, I'm thinking my best bet is to go with a tainted implementation that leverages off of Apple's old MoreFiles sample code. This wouldn't necessarily be compatible with the BSL, however, which makes contributing something useful to the library dicey. All this for cross-platform fstreams... Steve

2 1

generalized arithmetic functors
by Neal D. Becker 17 Aug '04

17 Aug '04

STL defines some common arithmetic operators, such as template<typename T> struct plus { T operator+(const T&, constT&); }; There is a need for more general operators: template<typename T1, typename T2, typename res> struct plus { res operator+(const T1&, constT2&); }; For example, std::complex<double> + double -> std::complex<double>. Has there been any discussion on this issue?

2 3

[preprocessor] BOOST_PP_IS_UNARY for Borland
by Daniel James 16 Aug '04

16 Aug '04

I've written an implementation of BOOST_PP_IS_UNARY which works for Borland, and hopefully any other preprocessors which the current implementation doesn't. It is: #define EAT2(x,y) #define IS_UNARY_CHECK(x) ~, 1 BOOST_PP_RPAREN() \ EAT2 BOOST_PP_LPAREN() ~ #define IS_UNARY(x) IS_UNARY_1(IS_UNARY_CHECK x, 0) #define IS_UNARY_1(x, y) IS_UNARY_2(x, y) #define IS_UNARY_2(x, y) y For a non-unary argument, the expansion is simple: IS_UNARY(x) => IS_UNARY_1(IS_UNARY_CHECK x, 0) => IS_UNARY_2(IS_UNARY_CHECK x, 0) => 0 For a unary argument, it expands like this (I might have got the expansion order slightly wrong but, hopefully, this illustrates how it works): IS_UNARY((x)y) => IS_UNARY_1(IS_UNARY_CHECK(x)y), 0) => IS_UNARY_2(~, 1 BOOST_PP_RPAREN() EAT2 BOOST_PP_LPAREN() ~y, 0) => IS_UNARY_2(~, 1) EAT2(~y, 0) => 1 The same technique can be used for BOOST_PP_IS_NULLARY and BOOST_PP_IS_BINARY. So, if this is used as for borland, could these marcros be made 'public'? Also, with a full working BOOST_PP_IS_UNARY, I think it should be possible to make BOOST_PP_SEQ_NIL act as an empty sequence, if I write a patch to do that would it be accepted? Daniel

2 4

Boost License Permission
by Cromwell Enage 16 Aug '04

16 Aug '04

I, Cromwell Enage, give permission for all my past, present, and future contributions to Boost to be distributed under the terms of the Boost Software License Version 1. _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com

2 1

Boost License Permission
by Bruce Barr 16 Aug '04

16 Aug '04

I, Bruce Barr, give permission for all my contributions to Boost to be moved to the Boost Software License Version 1.

1 0

boost-python vector processing
by Neal D. Becker 16 Aug '04

16 Aug '04

I've posted a few times to the python-c++ list, but maybe this subject is of more general interest so I'm posting here. I'm interested in interfacing c++ algorithms (primarily for signal processing) with python via boost-python. I'm trying to develop a library of algorithms, but first the proper infrastructure is needed. Specifically, a choice of underlying container to be used for passing vectors between python and c++. Vector processing is in my view one of the primary interests for boost-python. By processing vectors, the overhead involved with python and the python-c++ interface becomes acceptable. I believe a suitable container for interfacing between python and c++ is of fundamental interest to the boost-python community. I'm sure there must be a lot of interest in this subject. I have tried to investigate 3 candidates. 1) std::vector 2) ublas 3) numarray So far the results are: 1) std::vector - pros: universal availability easily understood supports required operations (insert, erase...) vector_indexing_suite already implemented (could be optimized more) cons: lacks vector arithmetic - but I just implemented this and it isn't difficult even for an amateur like myself 2) ublas: pros: already has vector arithmetic cons: lacks required operations (e.g., erase) no indexing_suite (see above) 3) numarray pros: ? cons: I had a hard time finding documentation. Heavy-weight interface -> high learning curve Summary: It appears that std::vector is a good choice. Ublas might be better in the future, but at present it lacks some required functionality. A ublas vector does not fulfill all the requirements of Sequence. This topic is known to ublas developers and may be addressed in the future. Here is an initial version of vector arithmetic for std::vector:

1 0

enabling ADL even with namespace qualification
by Thorsten Ottosen 16 Aug '04

16 Aug '04

Dear All, I've put meself in a funny situation. I have a class with an begin() end() members, but I wan't to call boost::begin() boost::end() without the boost:: prefix so ADL is functional. Can that be done? Thanks Thorsten

7 25

random_test, GCC and minmax macros
by Michael Stevens 16 Aug '04

16 Aug '04

The 'random_test' has been failing on GCC-3.3 for quite some time... Looking a bit deeper the failure was rather nasty resulting in a infinite recursion. A lot of waist CPU and memory usage when running regression tests! The problem is GCC-3.3 specific and cause by a compiler bug. It was inadvertently introduced by Eric minmax workarounds. Specificly the 'max' member functions of class ruetti_gen in "random_test.cpp" and class rand48 in "linear_congruential.hpp" were defined: result_type max BOOST_PREVENT_MACRO_SUBSTITUTION () const { return (std::numeric_limits<result_type>::max)(); } Amazingly these are recursing, with max calling itseld rather then the correct max from numeric_limits! I have committed a fix which uses a different syntax thus: result_type max BOOST_PREVENT_MACRO_SUBSTITUTION () const { return std::numeric_limits<result_type>::max BOOST_PREVENT_MACRO_SUBSTITUTION (); } Eric, is this correct from a minmax macro point of view? -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

IMPORTANT: PLEASE READ
by John Maddock 16 Aug '04

16 Aug '04

Sorry for the loud subject line, but there are still a shockingly large number of *source files* with no copyright/licence information in current cvs. Please take a chance to scan through the file list below and add your moniker to any that belong to you - no-one can do this for you, if one of these files is your work, it's up to you to own up to it, no else can assign the copyright on your behalf. John. HEADERS: ~~~~~~~~ boost/format/detail/unset_macros.hpp boost/iterator/detail/categories.hpp boost/iterator/new_iterator_tests.hpp boost/pending/container_traits.hpp boost/pending/cstddef.hpp boost/pending/detail/disjoint_sets.hpp boost/pending/detail/property.hpp boost/pending/fenced_priority_queue.hpp boost/pending/fibonacci_heap.hpp boost/pending/property.hpp boost/pending/queue.hpp boost/pending/stringtok.hpp boost/utility/detail/result_of_iterate.hpp TEST FILES: ~~~~~~~~~ libs/any/any_test.cpp libs/format/example/sample_userType.cpp libs/graph/example/adjacency_list_io.cpp libs/graph/example/graph_property.cpp libs/graph/example/iohb.c libs/graph/example/iohb.h libs/graph/example/subgraph_properties.cpp libs/graph/src/graphviz_digraph_parser.hpp libs/graph/src/graphviz_graph_parser.hpp libs/graph/src/yystype.h libs/graph/test/bellman-test.cpp libs/graph/test/bidir_remove_edge.cpp libs/graph/test/subgraph.cpp libs/graph/test/transitive_closure_test2.cpp libs/iterator/example/permutation_iterator_example.cpp libs/iterator/example/reverse_iterator.cpp libs/iterator/test/is_convertible_fail.cpp libs/iterator/test/iterator_adaptor_cc.cpp libs/iterator/test/lvalue_concept_fail_expected.cpp libs/multi_array/test/generative_tests.hpp libs/property_map/example3.cpp libs/python/example/getting_started1.cpp libs/python/example/getting_started2.cpp libs/python/pyste/tests/abstract_test.h libs/python/pyste/tests/add_test.h libs/python/pyste/tests/basic.cpp libs/python/pyste/tests/basic.h libs/python/pyste/tests/code_test.h libs/python/pyste/tests/enums.h libs/python/pyste/tests/header_test.h libs/python/pyste/tests/inherit.cpp libs/python/pyste/tests/inherit.h libs/python/pyste/tests/inherit2.h libs/python/pyste/tests/inherit3.h libs/python/pyste/tests/inherit4.h libs/python/pyste/tests/nested.cpp libs/python/pyste/tests/nested.h libs/python/pyste/tests/opaque.h libs/python/pyste/tests/operators.cpp libs/python/pyste/tests/operators.h libs/python/pyste/tests/smart_ptr.h libs/python/pyste/tests/templates.h libs/python/pyste/tests/vars.cpp libs/python/pyste/tests/vars.h libs/python/pyste/tests/virtual.cpp libs/python/pyste/tests/virtual.h libs/python/pyste/tests/virtual2.h libs/python/pyste/tests/wrappertest.h libs/python/pyste/tests/wrappertest_wrappers.h libs/python/src/dict.cpp libs/python/src/str.cpp libs/python/test/ben_scott1.cpp libs/python/test/bienstman1.cpp libs/python/test/bienstman2.cpp libs/python/test/bienstman3.cpp libs/python/test/destroy_test.cpp libs/python/test/dict.cpp libs/python/test/exception_translator.cpp libs/python/test/indirect_traits_test.cpp libs/python/test/map_indexing_suite.cpp libs/python/test/multi_arg_constructor.cpp libs/python/test/pickle2.cpp libs/python/test/pickle3.cpp libs/python/test/pickle4.cpp libs/python/test/pointer_type_id_test.cpp libs/python/test/properties.cpp libs/python/test/register_ptr.cpp libs/python/test/select_arg_to_python_test.cpp libs/python/test/select_from_python_test.cpp libs/python/test/slice.cpp libs/python/test/str.cpp libs/python/test/string_literal.cpp libs/python/test/submod_subclass_api.cpp libs/python/test/vector_indexing_suite.cpp libs/utility/ref_ct_test.cpp libs/utility/ref_test.cpp

4 7

Boost License Permission
by Kresimir Fresl 16 Aug '04

16 Aug '04

John Maddock wrote: > Hi, if you are receiving this message it is because there are one or more > files in the Boost C++ libraries that contain your copyright declaration. Yes, I give permission for all my contributions to Boost to be moved to the Boost Software License Version 1". Kresimir Fresl

2 1

date_time test failure
by Rob Lievaart 16 Aug '04

16 Aug '04

L.S. The date_time test testfiletime_functions is failing on mingw 3.2 and 3.4 and on vc8.0 with the same error: ../libs/date_time/test/posix_time/testfiletime_functions.cpp:26: call of overloaded `pow(int, int)' is ambiguous The line in questions is: static_cast<int>(std::pow(10, time_duration::num_fractional_digits() - 3)); I changed the 10, to 10.0, to solve the ambiguity, locally and now the test compiles and passes. I attached a patch. Kind regards, Rob.

2 1

boost.regex v4 compilation issue on VC++ 6 (and correction suggestion)
by Baptiste Lepilleur 16 Aug '04

16 Aug '04

Compilation of boost regex v4 (from the CVS) fails with the following error under VC6: f:\projects\cpptool\cppparser_dependencies\cppparser\include\boost\regex\v4\ basic_regex.hpp(221) : error C2143: syntax error : missing ',' before '<' f:\projects\cpptool\cppparser_dependencies\cppparser\include\boost\regex\v4\ basic_regex.hpp(298) : see reference to class template instantiation 'boost::reg_expression<charT,traits,Allocator>' being compiled Looking at the sources (inside template reg_expression definition): bool BOOST_REGEX_CALL operator==(const reg_expression& e)const { return compare(e) == 0; } bool operator != (const basic_regex<charT, traits, Allocator>& e) // <<< *** error here *** { return compare(e) != 0; } basic_regex is defined later in the source, hence the compilation error. Also, the fact that operator == & != have different prototype is very suspicious... Using reg_expression instead or basic_regex would fix the error. Baptiste.

2 1

config/config_test regression with Comeau
by Bronek Kozicki 16 Aug '04

16 Aug '04

Any idea why this http://tinyurl.com/5urwa is failing? B.

2 1

Boost
by Gunter Winkler 16 Aug '04

16 Aug '04

License Permission Date: Mon, 16 Aug 2004 10:24:17 +0200 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline X-KMail-Identity: 1438018275 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200408161024.17180.guwi17(a)gmx.de> Status: R X-Status: NQ X-KMail-EncryptionState: X-KMail-SignatureState: X-KMail-MDN-Sent: I Gunter Winkler, give permission for all my contributions to Boost to be moved to the Boost Software License Version 1.

1 0

RE: Your Copyright in the Boost C++ Libraries.
by Gottfried.Ganssauge＠HAUFE.DE 16 Aug '04

16 Aug '04

> -----Original Message----- > From: John Maddock [mailto:john@johnmaddock.co.uk] > Sent: Friday, August 13, 2004 1:29 PM > To: Undisclosed-Recipient:; > Subject: Re: Your Copyright in the Boost C++ Libraries. > > > Hi, if you are receiving this message it is because there are > one or more files in the Boost C++ libraries that contain > your copyright declaration. > > As some of you will know already, in order to simplify Boost > licensing, we are in the process of moving to a single common > license (http://www.boost.org/LICENSE_1_0.txt) The aim of > the new license is to provide a single wording, that > encapsulates the our previous license requirements, and which > will simplify the evaluation of Boost for commercial organisations. > > So here's the big question: may we have permission to change > code that has your copyright to use the new license? Your > copyright declaration would obviously remain, it's only the > license text that would change. Yes, I give permission to move all my contributions to Boost to the Boost Software License Version 1. Cheers, Gottfried

1 0

Review Wizard Status Report
by tom brinkman 15 Aug '04

15 Aug '04

Review Wizard Status Report 1) Summary 2) Review Managers Needed 3) Review Schedule 4) More IO Review - August 18, 2004 5) Iostreams Review - August 28, 2004 1) Summary The next three libraries under review extend the c++ iostreams framework through stream modifiers. Please be prepared to discuss these libraries in the coming weeks. The following links provide a good background to the c++ iostreams framework. CUJ Experts Forum Using IOStreams - Creating a Whole New Stream Class http://www.cuj.com/documents/s=7993/cujcexp1907reeves/ Using IOStreams, Part I http://www.cuj.com/documents/s=7999/cujcexp1901reeves/ Using IOStreams - Part II http://www.cuj.com/documents/s=7997/cujcexp1903reeves/ Curiously Recurring Manipulators http://www.cuj.com/documents/s=7994/cujcexp1906langer/ Using IOStreams - locales and facets http://www.cuj.com/documents/s=7995/cujcexp1905reeves/ Stringstreams and Their Friends http://www.cuj.com/documents/s=7996/cujcexp1904austern/ Books C++ Iostreams Handbook http://www.amazon.com/exec/obidos/tg/detail/-/ 0201596415/104-0023521-7921526?v=glance Standard C++ IOStreams and Locales http://www.amazon.com/exec/obidos/tg/detail/-/ 0201183951/ref=pd_sim_books_1/104-0023521-7921526?v=glance&s=books 2) Review Managers Needed I need help with the next three reviews. If you have experience with I/O related extensions, manipulators and stream buffers, please contact me through private email. 3) Review Schedule Confirmed Dates August 18, 2004 More IO - Daryle Walker (Review Manager Needed) August 28, 2004 Iostreams - Jonathan Turkanis (Review Manager Needed) Proposed Dates September 7, 2004 Output Formatters - Reece Dunn September 15, 2004 Mini-Review of small-algorithims from wiki September 17, 2004 Pointer Containers - Thorsten Ottosen September 27, 2004 Named Params - David Abrahams & Daniel Wallin October 6, 2004 Wave - Hartmut Kaiser October 16, 2004 Policy Pointer - David Held October 26, 2004 Finite State Machine (FSM) - Andreas Huber 4) More IO Review - August 18, 2004, Daryle Walker This library still needs a review manager. Download: http://groups.yahoo.com/group/boost/files/more_io_4.zip Provides a multitude of I/O-oriented extensions. Some are extra manipulators; variants of "std::endl", a resetting manipulator, and a configurable manipulator. The library includes a set of base class templates for wrapping a new stream-buffer type around a stream class. Changes from the last interim version (called "more_io_3b.zip"): * split the manipulator header into several headers * refined the license statements in some already-affected files Changes from the first formal review (called "more_io.zip"): * refined the interface and implementation of array-streams and stream-buffer wrappers (including a wrapping example) * added the null-stream, value-stream, and pointer-stream headers * added generalizations to the new-line and skip-line manipulators * added the non-oriented 'reset' and 'form' manipulators * split the manipulator header into several headers * changed the license statements 5) Iostreams Review - August 28, 2004, Jonathan Turkanis This library still needs a review manager. Web-Page: http://home.comcast.net/~jturkanis/iostreams Download: http://home.comcast.net/~jturkanis/iostreams The Iostreams Library serves two main purposes: To allow the easy creation of standard C++ stream and stream buffer classes for new data sources and sinks. To provide a convenient interface for defining i/o filters and attaching them to standard streams and stream buffers. The library focuses on freeing users from writing boiler plate code and allowing them instead to create highly reusable components. In addition to providing an abstract framework the library provides a number of concrete filters, sources and sinks which serve as example applications of the library but are also useful in their own right. These include components for accessing memory-mapped files (based on work of Craig Henderson) , for file access via operating system file descriptors, for code conversion, for text filtering with regular expressions, for line-ending conversion and for compression and decompression in the zlib, gzip and bzip2 formats. Tom Brinkman Review Wizard reportbase(a)yahoo.com

1 0

[Boost-bugs] [ boost-Bugs-1009515 ] Is there a Bug In boost::any？
by SourceForge.net 15 Aug '04

15 Aug '04

Bugs item #1009515, was opened at 2004-08-15 20:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1009515&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: palzhou (palzhou) Assigned to: Nobody/Anonymous (nobody) Summary: Is there a Bug In boost::any？ Initial Comment: Is there a Bug In boost::any？ Description: In my DLL，There is a class as follows: class MyClass { ... boost::any m_var; } and DLL has an interface： void SetVar(boost::any & anyValue) { pMyClass->m_var = anyValue; } There is an application uses the SetVar interface and pass into a boost::any object. void SomeFunc() { ... boost::any anyValue; ... pfSetVar(anyValue); ... } result: when exit, The application will be crash , the spot of crash is at the destruction of class boost::any. ... class any { ... ~any() { delete content; // error，error code 0xC0000005。 } ... } ... environment: MS windows 2000 pro sp4 MS vc6 sp5 boost 1.31 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1009515&group_… ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost Software License Progress As Of 20040814
by Stephan T. Lavavej 15 Aug '04

15 Aug '04

http://stl.nuwen.net/bsl2.html (didn't try to cover python and serialization - did they get fixed yet?) Progress is awesome! However, there's still low-hanging fruit, and there's still some work to be done: * Authors We Need For The BSL "John R Bandela" is in blanket-permission.txt as "John Bandela". "Robert Ramey - http www rrsd com" is in blanket-permission.txt as "Robert Ramey". "Thorsten Ottosen" is in blanket-permission.txt as "Thorsten Jørgen Ottosen". It should be really easy to take care of these aliases. * See the "Old style Boost licence #8" - bcp is getting /terribly/ confused about the file boost/archive/impl/basic_xml_grammar.hpp . * There are 86 files with no recognizable license information, and 247 with no recognizable copyright holder. The latter are all MPL though. * The 20 files that have been automatically BSLed look good to me - no obvious munging, though I don't know if I should be looking for anything specific. * There are still 641 files that have not been BSLed (I think this category is disjoint from no-license and no-copyright). Compare this to the 4738 BSLed files! Whoo! Is bcp being enhanced to annotate which Boost modules are entirely BSLed and which aren't yet? This could go in the Input Information section; each module could have a tag saying "Not BSLed", "BSLed, But Dependent On Modules Not BSLed", and "BSLed". Also I don't know if my technique of getting bcp to report on all directory names in boost/libs is catching everything or not. Stephan T. Lavavej [I'm just a Booster, I don't speak for Microsoft]

4 4

[info] More Boost.org copyrights removed
by John Maddock 15 Aug '04

15 Aug '04

Here's the final batch of file to have their boost.org copyrights removed, as before: If your name has been added when it should not have been, or if your name should have been added to the copyright declarations, but has not been, then please speak up now. Here are the files affected: boost/cast.hpp: Kevlin Henney and Dave Abrahams boost/checked_delete.hpp: Peter Dimov Daniel Frey Howard Hinnant boost/integer_fwd.hpp: Dave Abrahams. boost/math_fwd.hpp: Dave Abrahams. boost/smart_ptr.hpp: Peter Dimov libs/conversion/cast_test.cpp: Beman Dawes, Dave Abrahams. libs/utility/noncopyable_test.cpp: Beman Dawes. Thanks, John Maddock

2 2

[Info] Updated Boost.org copyrights
by John Maddock 15 Aug '04

15 Aug '04

We agreed a while ago that the "Boost.org" copyrights should be removed from source files (on the grounds that there is no legal entity called Boost.org) So, the following files have had their copyright declarations updated as below, copyright assignments are based on cvs history. If I have either: missed your name off the list, or added your name when you don't think that it should be there, then please speak up now. Here's the list of assignments (so far): boost/io_fwd.hpp: Beman Dawes and Daryle Walker boost/iterator.hpp: Beman Dawes boost/limits.hpp: John Maddock, Dave Abrahams. boost/mpl/if.hpp: Aleksey Gurtovoy boost/next_prior.hpp: Aleksey Gurtovoy boost/noncopyable.hpp: Beman Dawes boost/numeric/conversion/cast.hpp: Fernando Luis Cacciola Carballal boost/utility.hpp Aleksey Gurtovoy boost/utility_fwd.hpp: Beman Dawes boost/version.hpp: John Maddock Thanks, John Maddock.

2 2

Fw: Boost,License Permission
by John Maddock 15 Aug '04

15 Aug '04

Forwarded here as a permanent record: ----- Original Message ----- From: "Eric Ford" <un5o6n902(a)sneakemail.com> To: <john(a)johnmaddock.co.uk> Sent: Friday, August 13, 2004 2:01 AM Subject: Boost,License Permission > I, Eric Ford, give permission for all my contributions to Boost to be > moved to the Boost Software License Version 1 >

1 0

[ATT:Jim Apple] Memoization Library status?
by Mattias Flodin 15 Aug '04

15 Aug '04

In December last year, Jim Apple asked if there was interest in a memoization library he was working on. [1] It seems there were several people interested in this, but I have seen no more posts about it. Was this project discontinued? Are there other boosters working on a library like this? Dave Abrahams pointed out (in [2]) that a library such as this may need the ability to invalidate parts of the cache, but was met with confusion and I don't think the motivation for the need was widely understood. I have had increasing need for a memoization library such as this in our current project, so I thought I'd try to summarize it as a kind of use case. The project is a medical diagnosis application using in the order of a hundred image processing step for diagnosis of digitized images. Some of these steps can take a very significant amount of time, and many of them may need to use intermediate results that were already computed in other steps. I am currently obtaining the result image recursively through a very rudimentary non-generic memoization cache class, where recursive calls are explicitly routed through the cache object (by a string->funptr mapping). Thanks to the caching I am now probably cutting away a good 90% of processing time. Although all processing-step functions now (of necessity) have the same signature, many of them use various globally set parameters related to the algorithm, such as threshold settings for neural-network outputs. Some parameters are not used until late in the process, whereas other parameters affect early steps. To optimize the parameter values we must perform a lot of searches through the parameter space using various parameter optimization techniques. Currently, with every parameter change we must re-run the entire process, even if the parameter actually only affects one of the very last steps. With a memoization library that knows about parameter dependencies, we would be able to try many different values of this parameter and only the dependent parts of the cache would be invalidated, which could save hours if not days of processing time. /Mattias [1] http://lists.boost.org/MailArchives/boost/msg56780.php [2] http://lists.boost.org/MailArchives/boost/msg56913.php

2 1

Re:Re: [boost] [serialization] export macros
by Robert Ramey 14 Aug '04

14 Aug '04

Christoph Ludwig wrote: >> template<class> struct pack; >> >> template<class T> struct pack<void (T)> { >> typedef T type; >> }; >> >> BOOST_CLASS_EXPORT( pack<void (DerivedStatus< Algo<int, double > >> >)>::type ); >That did the trick! Great! >I am not sure which of Boost's libraries is the most adequate place for >such a tool (preprocessor? mpl?), but it is certainly valuable. And if / >once there is such a tool in Boost, then the documentation of macros that >are likely to take classes genareted from templates as arguments should >refer to it. Hmmm - maybe we should just roll this into export.hpp - Would this create any other problems? Robert Ramey

3 6

remove_pointer type trait metafunction and smart pointers
by Jeff Mirwaisi 14 Aug '04

14 Aug '04

Currently (afaict) there isnt a specialization of remove_pointer that handles smart pointers. Providing a very generic specialization: template <typename T, template<typename> class Ptr> struct remove_pointer<Ptr<T> >; or a set of specializations that cover shared_ptr etc + auto_ptr explicitly, "seems" like a rational extension. Are there any potential problems, and if not can we get this added to type traits?

2 2

Directory for the regression test results doesn't exist.
by Martin Wille 14 Aug '04

14 Aug '04

Hi, http://boost.sourceforge.net/regression-logs doesn't exist. Instead, there is a tar file owned by root which seems to contain the result directory. What's happening there? Regards, m

2 1

[repost] regressions in como-win32-4.3.3-vc7.1
by JOAQUIN LOPEZ MU?Z 14 Aug '04

14 Aug '04

This post caught nobody's attention two days ago, but the error is still showing... -- Original message -- Please see http://tinyurl.com/5f7ba "C:\Comeau\libcomo\cnames\cstring", line 31: error #247: function "std::strlen" has already been defined extern "C++" inline size_t strlen(const char *arg) { return ::strlen(arg); } ^ "C:\Comeau\libcomo\cnames\cstring", line 31: error #247: function "std::strlen" has already been defined extern "C++" inline size_t strlen(const char *arg) { return ::strlen(arg); } ^ 2 errors detected in the compilation of "..\libs\multi_index\test\test_basic_main.cpp". The problem has nothing to do with Boost.MultiIndex, actually, as test_basic_main.cpp does not do anything more than including <boost/test/included/test_exec_monitor.hpp> These tests used to pass one or two days ago. I've inspected Boost.Test for recent changes and found none. Other libraries are affected by this problem: algorithm/minmax algorithm/string program_options ... Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 5

regression - failed tests for date_time and regex in vc7.1 toolkit
by Bronek Kozicki 14 Aug '04

14 Aug '04

I've noticed that regression test I'm running are failing on almost all tests in date_time and many tests in regex. Here's what I've found: bjam is building static library: libboost_date_time-71-mt-gd-1_32.lib Please note that there's no "vc71", but "71" instead. File: libboost_date_time-vc71-mt-gd-1_32.lib is not build, thus all tests linking to this file are failing. When I copy libboost_date_time-71-mt-gd-1_32.lib into libboost_date_time-vc71-mt-gd-1_32.lib , date_time tests are no longer failing. The same applies to dynamic library: what is actually being build is named: boost_date_time-71-mt-gd-1_32.lib boost_date_time-71-mt-gd-1_32.dll but for tests to succeed there should be: boost_date_time-vc71-mt-gd-1_32.lib boost_date_time-vc71-mt-gd-1_32.dll What's even more interesting, library files "71" are actually being used, too (besides "vc71" files). I've found that "cmd" files are referring to "71" files. I do not know what is referring to "vc71" files (maybe autolink feature?) The same problem plagued regression tests for regex library - libraries build by bjam are named : libboost_regex-71-mt-gd-1_32.lib boost_regex-71-mt-gd-1_32.lib boost_regex-71-mt-gd-1_32.dll while tests require also files named : libboost_regex-vc71-mt-gd-1_32.lib boost_regex-vc71-mt-gd-1_32.lib boost_regex-vc71-mt-gd-1_32.dll Any ideas what might be wrong? B.

3 6

"Making a Boost Library" - article for C/C++ user's journal - request for critique.
by Robert Ramey 14 Aug '04

14 Aug '04

Fellow boosters, Editors of the C/C++ users journal accepted my proposal for an article titled "Making a Boost Library" (subject to final review of course). Rather than being "code centric" as other articles for this journal are, this will focus on the Boost library development and review process from the vantage point of a library submitter. I've got the article done. Its 8 pages (3500 words) in Microsoft word format. If anyone is interested in reading this and critiquing it, please advise me by private email and I'll send you a copy for your review. Robert Ramey

1 0

[info] Copyright permission.
by John Maddock 14 Aug '04

14 Aug '04

Forwarded here, so we have a permanent record only: ----- Original Message ----- From: "Gregory Colvin" <gregory.colvin(a)oracle.com> To: "John Maddock" <john(a)johnmaddock.co.uk> Cc: <boost-owner(a)lists.boost.org> Sent: Friday, August 13, 2004 3:29 PM Subject: Re: Your Copyright in the Boost C++ Libraries. > > On Aug 13, 2004, at 5:29 AM, John Maddock wrote: > > > Hi, if you are receiving this message it is because there are one or > > more > > files in the Boost C++ libraries that contain your copyright > > declaration. > > > > As some of you will know already, in order to simplify Boost > > licensing, we > > are in the process of moving to a single common license > > (http://www.boost.org/LICENSE_1_0.txt) The aim of the new license is > > to > > provide a single wording, that encapsulates the our previous license > > requirements, and which will simplify the evaluation of Boost for > > commercial > > organisations. > > > > So here's the big question: may we have permission to change code that > > has > > your copyright to use the new license? Your copyright declaration > > would > > obviously remain, it's only the license text that would change. > > > > If "yes", and you have Boost-cvs write access, please add your name to > > more/blanket_permission.txt. > > > > If "yes" and you have access to the Boost mailing list > > (boost(a)lists.boost.org) then please post a message there, subject > > "Boost > > License Permission", and content something like: "I Jim Hacker, give > > permission for all my contributions to Boost to be moved to the Boost > > Software License Version 1". (This gives us a public record that your > > permission has been given). > > I, Greg Colvin, give permission for all my contributions to Boost to > be moved to the Boost Software License Version 1". > > > > > If "yes", but you are no longer subscribed to the Boost list then > > please > > reply to boost-owner(a)lists.boost.org with content as above. > > > > If "no", please give us some idea what objections you may have. > > > > Finally, if this message was sent in error, please let us know, it's > > just > > about possible that we have you mixed up with someone of the same > > name, and > > if so apologies. > > > > Many thanks for your time, > > > > John Maddock. > > (Boost Moderator). > > > >

1 0

Regression test results (metacomm broken?)
by Victor A. Wagner Jr. 14 Aug '04

14 Aug '04

Is it just me or has the metacomm site quit processing results. I've done _two_ runs, and my logs show the ftp suceeding, since the one they credit me with. (16 hours old at this point) the results from me (RudbekAssociates) is also the one showing with the latest timestamp Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

Re:RE: [boost] [serialization] BOOST_CLASS_EXPORT_GUID: expected ...
by Robert Ramey 13 Aug '04

13 Aug '04

>The load tests need the output of the save tests, but they are not run in >that >order. If you run the tests again, then the output from the previous run >should still be there, and then you can see if they actually pass or not If any Jamfile guru wants to explain a convenient way to require certain tests to be performed in a certain order I would be very grateful. Also, I would caution against using the development tree in production code. We're constantly fiddling with things like Jamfiles, options, etc for compilers we don't always have direct access to. Sometimes stuff is temporarily broken. I do role in bug fixes so any improvements you add to your production package should automagically show up in the next release. Robert Ramey

2 1

Re: Boost License changes
by Juergen Hunold 13 Aug '04

13 Aug '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi John ! On Friday 13 August 2004 14:07, John Maddock wrote: > Juergen, > > I hope I'm addressing this to the correct person, Yes. > As you will know already, in order to simplify Boost licensing, we > are in the process of moving to a single common license > (http://www.boost.org/LICENSE_1_0.txt) The aim of the new license > is to provide a single wording, that encapsulates the our previous > license requirements, and which will simplify the evaluation of Boost > for commercial organisations. I've seen the various threads about that change. > So here's the big question: may we have permission to change code > that has copyright "Institute of Transport, Railway Construction and > Operation, University of Hanover, Germany" to use the new license? > The copyright declaration would obviously remain, it's only the > license text that would change. > If "yes", please post a message to the main boost list > (boost(a)lists.boost.org) indicating that this is the case. Yes, you may change all code with the above copyright to use the new boost license. > John Maddock. > [Boost Moderator] Yours, Jürgen - -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBHPz5ljbJ/LLrxrYRAm3aAKDLADBjQ0OVixaObAy+gxLFXbc5ZgCeN59Z eSnTmoEBwoFjUWMXrcXDU3Q= =v4gh -----END PGP SIGNATURE-----

1 0

Re:[boost] [serialization] export macros
by Robert Ramey 13 Aug '04

13 Aug '04

> Is there an alternative to the macros for registering types? > (A sample program exhibiting what I am trying is attached.) Have you considered using "forward registration" rather than EXPORT? int main() { Status< Algo< int, double > >* p_s = new DerivedStatus< Algo< int, double > >; ====> boost::archive::text_oarchive oa(std::cout); oa.boost::archive::register_type( static_cast<DerivedStatus_Algo_int_double *>(NULL) ); oa << p_s; } Robert Ramey

1 0

Re:[boost] [serialization] export macros
by Robert Ramey 13 Aug '04

13 Aug '04

> Does anyone know a work around that does not need the typedefs? I had > a look at the preprocessor library but I couldnt come up with a > solution. Is there an alternative to the macros for registering types? The BOOST_CLASS_EXPORT facility has been a struggle to get implemented so that it can be used in a natural way. Besides the problem you mention here (which is a new one for me) There were some new ones that have become apparent with compilers that use two-phase lookup. Another problem is over-zealous unreachable code optimization of some compilers eliminates the code that implements the serialization. The fix for this is inherently non-portable. Subject to the above it does work - but is kind of fragile and really not quite right - it will need to be re-implemented (yet) again. So I'm interested in your cases. Is it possible you could make a few boostified test programs that we would like to see work but currently fail at compile time? The really funny part about BOOST_CLASS_EXPORT is that is started out soooo simple and ends up touching on all sorts of unexpected difficulties. The good part is that its not a fundamental building block of the system so fixing it up won't impact the rest of the system. So there is hope. Robert Ramey

1 0

date_time broken on intel-win32-8.0
by Stefan Slapeta 13 Aug '04

13 Aug '04

http://tinyurl.com/4y6tx LINK : fatal error LNK1104: cannot open file 'libboost_date_time-iw-mt-gd-1_32.lib' Has anybody an idea where to search? Stefan

3 5

regex win32 memory leaks
by Thomas Witt 13 Aug '04

13 Aug '04

Hi, I am having a windows MFC app that dynamically links to the regex lib. On application shutdown the memory leak detection kicks in and diagnoses leaks in the regex dll. If I use the static lib everything seems to be fine. I have to admit that I don't have a clue what's going on. Any ideas? Thomas BTW this is vc-7.1 boost 1.31 -- Thomas Witt witt(a)acm.org

3 2

RE: [boost] [serialization] BOOST_CLASS_EXPORT_GUID: expected `; ' before '('
by Rob Lievaart 13 Aug '04

13 Aug '04

Hi, The load tests need the output of the save tests, but they are not run in that order. If you run the tests again, then the output from the previous run should still be there, and then you can see if they actually pass or not Kind regards, Rob Lievaart. > Unfortunately, I see new failures in the > test_level_class_info_load_*_archive test that > http://boost.sourceforge.net/regression-logs/cs-Linux.html (dated > 2004-08-12) reports as passing. The test output does not tell me much: > > serialization - test_level_class_info_load_binary_archive - gcc > > Linker output: > > Chmod1 > ../bin/boost/libs/serialization/test/test_level_class_info_load_binary_archi ve.test/gcc/debug/test_level_class_info_load_binary_archive > > > Run output: > > Exception in "call_test_main": std::exception: stream error > > *** errors detected in test case "call_test_main"; see standard output > for details > Test case "call_test_main" was aborted due to uncaught exception, user > assert or system error > > EXIT STATUS: 200

2 1

[serialization] BOOST_CLASS_EXPORT_GUID: expected `; ' before '('
by Christoph Ludwig 13 Aug '04

13 Aug '04

Hi, the regression logs (dated 2004-08-10) show that, e.g., test_exported_text_archive fails for gcc 3.4.1: http://tinyurl.com/3tek6. That's the same problem I mentioned today in another post; in a simple test case I could solve the problem with the attached patch. However, I am not going to pretend that I understand how all the specializations and explicit instantiations in the export machinery interact. And I didn't have time yet to run a more complex test or the regression tests against the patched version. Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

1 1

[boost.test] Visibility problem in fixed_mapping.hpp
by Markus Schöpflin 13 Aug '04

13 Aug '04

In my efforts to make boost.test compile with tru64cxx65 I came about the following issue. Currently, class fixed_mapping contains a private member called elem_type which is later on used in the inline definition of an operator() contained in two inline structs. class fixed_mapping { typedef ... elem_type; struct p1 : public ... { bool operator()(elem_type const &x, ...) { ... } } }; My compiler complains that elem_type is inaccessible in the definition of operator() and I think it is right to complain. I fixed this by making elem_type public, but possibly operator() could be made a friend of fixed mapping as well. Markus

3 3

[serialization] export macros
by Christoph Ludwig 13 Aug '04

13 Aug '04

Hi, working with the post-review version #20 of the serialization library, I encountered problems with respect to the export macros (BOOST_CLASS_EXPORT_GUID etc.). I decided to check the Boost CVS for changes - but it turns out the problems became worse :-( (FWIW, I use gcc 3.4.1 on a Linux x86 machine.) I need to register class template specializations that have several arguments. Unfortunately, the preprocessor does not know about template argument lists and treats the 2nd, 3rd,... template argument as separate macro arguments. Therefore, the expansion of the export macros fails due to a wrong number of macro arguments. It does not help to surround the template-id with parentheses since after the macro expansion the argument is used as a template argument itself and the compiler rejects the "superfluous" parentheses in the new template argument list. With serialization#20 I had the workaround to define a typedef for the template specialization within an anonymous namespace. I could then pass this typedef to the export macros. But this approach becomes soon impractical if you write a library with internal class templates depending on some user defined types. Does anyone know a work around that does not need the typedefs? I had a look at the preprocessor library but I couldnt come up with a solution. Is there an alternative to the macros for registering types? (A sample program exhibiting what I am trying is attached.) Anyway, with the current CVS, even above mentioned workaround fails; I am going to discuss the reason in a separate posting. Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

3 3

range broken in current cvs
by Neal Becker 13 Aug '04

13 Aug '04

Just updated from mainline cvs. Then even range.hpp by itself will not compile: g++34 -x c++ -fsyntax-only -I /usr/local/src/boost.cvs /usr/local/src/boost.cvs/boost/range.hpp In file included from /usr/local/src/boost.cvs/boost/range.hpp:21: /usr/local/src/boost.cvs/boost/range/sub_range.hpp:66: error: `iterator' does not name a type /usr/local/src/boost.cvs/boost/range/sub_range.hpp:66: error: (perhaps `typename boost::iterator_range<typename boost::result_iterator_of<C>::type>::iterator' was intended) /usr/local/src/boost.cvs/boost/range/sub_range.hpp:68: error: `iterator' does not name a type /usr/local/src/boost.cvs/boost/range/sub_range.hpp:68: error: (perhaps `typename boost::iterator_range<typename boost::result_iterator_of<C>::type>::iterator' was intended)

3 3

Request to regression testers
by Michael Stevens 13 Aug '04

13 Aug '04

Firstly thanks to all those currently running regression tests, they really are very useful. I'm not sure what load the meta-comm web server gets but I am certainly accessing the results on a regular basis! At the moment the only thing the regression test system cannot do automatically is purge stale targets that are no longer part of the build. By the look of the results some regression testers are conservative and delete the target bin directories. Would it be possible for 'RubeckAssociates' and 'Martin Wille' to do this on a one of basis. I have a test7 in ublas which was only temporarily part of the regression run. The old stale results are somewhat confusing the test picture. Thanks! Thanks, Michael

3 2

mingw-stlport toolset
by Janusz Piwowarski 13 Aug '04

13 Aug '04

Hello, I created these toolset trying to run program_options library (mingw actually doesn't support wide char streams). Maybe it could be useful for someone else. Regards, Janusz

2 2

Re:Re: Re: [boost] [serialization] export macros
by Robert Ramey 13 Aug '04

13 Aug '04

>However, this problem is by no means specific to the serialization >library. Whenever you have a macro that takes a classname you may face >this issue. One could consider it a (inherent) preprocessor >shortcoming solved by means of template programming. Therefore the >preprocessor library or one of the libraries from Boost's Generic >Programming and Template Metaprogramming sections seem a more natural >place to me for such a tool. Of course, I don't know if one of the >authors of these libraries agrees and plans to eventually include such >a template. >Since the next release is (hopefully) not long away I'd only mention >this workaround in the documentation of the export macros. Once the >release is out and everything has settled down there's time to discuss >where this template belongs. >This template requires so few keystrokes that for the time being the >users that need it can easily provide it themselves. But in order to >avoid unnecessary bloat of Boost I wouldn't like to see it duplicated >in several Boost libraries in the end. Wow a very clear and concise explanation - I'm sold - I'll just tweak the docs and declare victory. Robert Ramey

1 0

Re:[boost] Re: [serialization] BOOST_CLASS_EXPORT_GUID: expected
by Robert Ramey 13 Aug '04

13 Aug '04

David Abrahams wrote: >"Robert Ramey" <ramey(a)rrsd.com> writes: >> If any Jamfile guru wants to explain a convenient way to require certain >> tests to be performed in a certain order I would be very grateful. >You could make one dependent on another. But why do you need to do >that? A few demos/tests are really a pair - one to save and one to load. In some cases this was to illustrate the fact that the system worked even though saveing and loading were not done in the same program which apparently wasn't altogether clear otherwise. In other cases, the tests are separate executables because, its possible that the version of class has changed but the version it was save under is the previous one so it's a lot more clear to check this case with a pair of tests. That is, class serialization traits can be changed but if we load an older archive, the traits have to be the ones that the archive used when saved. There's an opportunity for confusing the current serialization traits with the "historical ones" hence the separate executables. In the future this will probably be even more necessary as there really is a need to test for archive portability. This means having/creating canonical archives to test against before testing load. I don't remember all the scenarios but in testing persistence, it can be convenient to specify sequence. On the other hand, I'm pretty reluctant to make my Jamfile for serialization/test any more elaborate than it already is since I don't realy feel I understand the jam system all that well. Robert Ramey

1 0

[Serialization] doc error
by Christoph Ludwig 12 Aug '04

12 Aug '04

Hi, libs/serialization/doc/headers.html gives an overview when to include which serialization headers. (Robert, this overview turned out to be quite helpful!) However, some of the paths stated are wrong: The documentation lists all headers in the section `Serializations Declaration' under boost/archive, but they are actually in boost/serialization. Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

1 0

true64cxx and toupper
by Gennadiy Rozental 12 Aug '04

12 Aug '04

cxx: Error: /net/redbelly/scratch1/rwgk/boost_regression/boost/boost/test/detail/basic_c string/compare.hpp, line 42: #40 expected an identifier static bool eq( CharT c1, CharT c2 ) { return std::toupper( c1 ) == std::toupper( c2 ); } ---------------------------------------------------------------^ How should deal with this one? Any pointers? Gennadiy.

7 21

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

12 Aug '04

Message: 6 Date: Wed, 11 Aug 2004 23:46:32 -0500 From: Rene Rivera <grafik.list(a)redshift-software.com> Subject: To: Message-ID: <411AF628.80605(a)redshift-software.com> Content-Type: text/plain; charset=us-ascii; format=flowed Robert Ramey wrote: >> 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. >It's 9.2, or possibly 9.3. Stefan should really label the version. >Stefan: if you tell me which version you are running I can add a toolset >into CVS for it. Hmmm so the current set of facts is: Ramey:CWPro 9.2 in debug mode - fails export tests Rivera:CWPro 8.3 in release mode - fails export tests Stephan:CWPro 9.2?3 in ? mode - passes export tests. Its not clear to me how to address this. I would love to know what I'm doing differently than Stephan is. We're using the same tool set - cwpro9 or are we? Shouldn't the heading on the results table correspond to the toolset name? I'm using the toolset labeled cwpro9 - is this the correct one to use? Robert Ramey

3 2

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

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

11 Aug '04

Stefan Slapeta wrote: >>Robert Ramey wrote: >> >> CW two-phase lookup threw me for a loop. What I meant was it left me dazed and confused. >This seems _very_ strange to me because two-phase lookup should also be > turned on for Intel 8, so I don't understand why all the tests pass on >this compiler. Please could you mail me a particular test case or code >sequence which you think was failing because of two-phase lookup issues? Is this something that can be turned off/on at will for intel? And/or other compilers? I use boost-build defaults as much as possible. Hmmm - maybe two phase lookup should turned off by default for boost? This experience has convinced me that two phase lookup is a bad idea. A couple of months ago I tested the library with intel 8.0 . After resolving one anomally (related to typeid of const/non-const) things compiled and everything passed. My 30 day license exprired so I haven't been able to test here since. When I went to cw pro version 9, I had the tests for non-intrusive serialization failed. This uses function template overload. This turned out that to be the same problem I had with Commeau. After much effort I came to understand the issue. I made adjustments to address this. This resulted in more changes than I wanted to make at this point. Oh well. It has also resulted in a slightly more complex explanation of how to use non-intrusive serialization portably. This works but it offends my sense of aesthetics. On the other hand, It did force me implement ADL for finding overloads. This was the one feature that had been asked for but hadn't implemented. I didn't see a way to do it without causing a two large ripple effect through the API, docs, etc. Martin Ecker showed me how to fix this so now we have ADL for overloading serialize functions. So I would think that if Intel implements two-phase lookup, things would have failed much sooner. On the other hand, during my 30 test trial of Intel 8.0 I got two?! Notices for updates. It wouldn't surprise me if there are multiple versions named Intel 8.0. In spite of all the pain I've experienced in porting code like this to all such platforms. I've come to appreciate the general high quality of these compilers. They all have quirks and errors. But now having had to delve much deeper into details of C++ than I ever had to before, I have a much better appreciation of how difficult is has to be to write something like this. I think C++ would be much improved if the standards committee would be a little more conservative about "mandating" untested features. Sometimes I wonder if its not just a group of really smart guys sitting around a table thinking up the hardest stuff they can for other people to implement - Sort of like the marketing department. I've had huge difficulties traced to arcane areas of C++ that are really too hard to understand for the normal person. Anyway - one man's two cents. Robert Ramey

2 1

"blank permission" in license_info.html
by Jonathan Wakely 11 Aug '04

11 Aug '04

http://boost.org/more/license_info.html says "blank permission" should be "blanket permission" jon

2 1

Documentation copyright in Boost
by Jonathan Brandmeyer 11 Aug '04

11 Aug '04

John Maddock's prodding with regard to copyright notices in Boost's sources got me thinking about the copyright notices in its documentation. Currently, some docs have a copyright notice using the Boost Software License, some have a permissive license other than the BSL, and some just say "Copyright (c) DATE AUTHOR". I haven't done a detailed survey; that observation is just based on a random browsing of the Boost docs. I generally believe in using the same copyright license for the documentation as the one used for the software, at least in the context of Free/Open Source Software. That may or may not be entirely appropriate considering the BSL's particular language concerning compiled software. Has this issue been raised in the past? Was there a consensus? If not, what do you think about it, now? Thanks, Jonathan Brandmeyer

2 2

[boost.thread] Allowed lifetime of a thread?
by Roland 11 Aug '04

11 Aug '04

While considering various ways to get rid of the remaining intentional memory leak of the tss implementation, I came upon the following question: How long may a thread access it's tss storage anyway? I did not find anything in the documentation about the topic. Looking into the destructor of thread_specific_ptr reveals ~thread_specific_ptr() { reset(); } which in turn implies, that the thread(s) which are using it should have already terminated, when the main thread has exited (called its dtor list). Now when one has control over the lifetime of the threads this poses no problem, since they simply need to be terminated before main() ends. The situation is completely different when writing a piece of code (a library) that has to use tss and shall work with foreign threads too. The library writer in this case has no control over the lifetime of the threads (native or not). So I am wondering if it is possible to refine the inner workings of the thread_specific_ptr without changing the interface to account for these cases? Perhaps only a static pointer should be embedded that points to dynamic memory that will not be touched by destructor calls, but controlled in lifetime be real thread-detachements. (The last one frees everything which is really global.) How is the situation for other libraries, say e.g. pthreads? Are they allowed to run after main ended? Or is this simply considered bad programm behaviour? Any comments? Roland

2 3

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

11 Aug '04

David Abrahams wrote: >> This seems _very_ strange to me because two-phase lookup should also >> be turned on for Intel 8, so I don't understand why all the tests pass >> on this compiler. >Intel for windows has the "MSVC bug compatibility" switch turned on. >On linux it actually detects 2-phase problems, except insofar as it's >trying to emulate GCC bugs :( Ahhh - mystery solved - thanks for that. Robert Ramey

1 0

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

11 Aug '04

Howard Hinnant wrote: >> All tests using utf8-codecvt fail. This includes the test for >> utf8-codecvt >> itself. I have come to believe that its an error somewhere in the MSL >> 9.2 >> implementation of the standard library. >If you can send me an independent demo of anything you believe is a >CodeWarrior bug, I would be most grateful. If your demonstration is >depending heavily on boost, a preprocess is usually the best way to go. >If you can minimize the demonstration by eliminating irrelevant code, >that also helps a lot. The test test_utf8_codecvt in the serialization library is pretty minimal. But I'll strip it down to the minimum, verify that it still fails, and send it along. Thanks for helping me with this. Robert Ramey

1 0

[Serialization] Missing CSS file
by Douglas Gregor 11 Aug '04

11 Aug '04

libs/serialization/doc is missing the stylesheet file style.css. Doug

1 0

RE: [boost] Re: true64cxx and toupper
by Rozental, Gennadiy 11 Aug '04

11 Aug '04

> There must be some difference between my test platform and > the one used > to run the regression tests but I have no idea where to start looking. > > Just to be sure I checked with boost 1.30.0 and the test library > compiles ok with the current toolset. > > Markus I made some fixes since run of regression test. I may've helped unit_test_result compilation. As for compiler crash - no idea. Gennadiy.

1 0

CVS update problem: waiting for david_abrahams's lock
by Aaron W. LaFramboise 11 Aug '04

11 Aug '04

For the past few hours, I have been attempting to update my local CVS tree and have been getting the following message midway through the update: cvs update: Updating tools/build/test/project-test3/lib cvs update: Updating tools/build/test/project-test3/lib2 cvs update: Updating tools/build/test/project-test3/lib2/helper cvs update: [05:36:48] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/test/project-test3/lib2/helper cvs update: [05:37:18] waiting for david_abrahams's lock in /cvsroot/boost/boost/tools/build/test/project-test3/lib2/helper . . . The update appears to hang here, repeating that last message periodically. Aaron W. LaFramboise

2 1

shared_ptr improvement proposal
by Tylo 11 Aug '04

11 Aug '04

shared_ptr improvement proposal by T. Lovset --- note: Parts of this may be long-winded and possible obvious to some of you, but I feel it is needed to support the arguments. Let me know what you think. --- I propose a modification to the smart pointer classes. In my opinion, this modification improves the current smart pointer usage in several respects, although it is not completely backward compatible. However, that is also the main purpose of the modification, because as we know, the explicit constructors that take a raw pointer is dangerous in numerous ways. As an illustration, I show a realistic example that violates the smart pointer preconditions in a subtle (and dangerous) manner. As a background, some quotes from the boost "Proposal to Add General Purpose Smart Pointers to the Library Technical Report" (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1450.html) (1) > A common concern, dating back to [Colvin94], is that it is very easy to violate the preconditions > of smart pointer operations. This proposal attempts to systematically eliminate undefined behavior > possibilities as long as the user is manipulating already valid shared_ptr (and weak_ptr) > instances, but using the pointer constructor correctly is still up to the user. And: > - Widespread existing practice strongly favors the unprotected but powerful pointer constructor > approach. (2) > A. General Principles > 1. "As Close to Raw Pointers as Possible, but no Closer" For auto_ptr and shared_ptr, we are familiar with the form: shared_ptr<Widget> smartWidgetPtr( new Widget(a, b) ); The constructor is made "explicit" in order to avoid implicit and unintentional construction of smart pointers, e.g.: void f( shared_ptr<Widget> const & wp ); would without explicit constructors accept f(rawWidgetPtr) with disastrous results. Still, as mentioned, "explicit" does not make up for all misuses. For example, an inexperienced user could try to call f(shared_ptr<Widget> (rawWidgetPtr)) to make it compile. Fortunately, this is quite easy to spot as an error, and therefore "explicit" does it's mission here. But a much more common and subtle problem may arise when converting from raw pointers to smart pointers: class WidgetUtil { public: WidgetUtil(Widget* wp); private: Widget* m_wp; }; WidgetUtil::WidgetUtil(Widget* wp) : m_wp(wp) { ... } Now converting to shared_ptr: class WidgetUtil { public: WidgetUtil(Widget* wp); private: shared_ptr<Widget> m_wp; }; The unmodified constructor still compiles, but the precondition for m_wp is violated. One must therefore pay close attention to the constructors to make sure that they do not take raw pointer as arguments, which initializes smart pointers. In the case of a big class with a mixture of both smart and raw pointer members, the principle of "using the pointer constructor correctly is still up to the user", lays an unacceptable heavy burden upon the user (in my opinion) - especially when it is possible to avoid this problem. Before I move on to the proposal, I'll address another drawback with the current smart pointer implementations: implicit ctor-initialization and assignment to NULL (which is possible with raw pointers) is not supported. This would make things much easier when converting back and forth between smart and raw pointers. It also breaks the principle of "As Close to Raw Pointers as Possible, but no Closer". My proposal makes this possible, and thus making the usage closer to that of raw pointers, without introducing any side effects. [As a side note, Joe Guttman pointed out to me that with the proposed nullptr and nullptr_t, it will be easy to add these features to the current implementations of smart pointers. However, my proposal does not rely on nullptr.] The Proposal ============ Note that this proposal would be beneficial to most smart pointer implementation, including shared_ptr and auto_ptr. Unfortunately, auto_ptr is already in the standard, so it can't be touched. I propose this usage (for shared_ptr): shared_ptr<Widget> wp1 = NULL; shared_ptr<Widget> wp2 = rawptr(new Widget(a, b)); wp1 = rawptr( new Widget(a, b) ); wp2 = NULL; Current shared_ptr usage: shared_ptr<Widget> wp1( NULL ); shared_ptr<Widget> wp2( new Widget(a, b) ); wp1.reset( new Widget(a, b) ); wp2.reset(); Discussion: 1. As wp1 and wp2 should be raw pointer "look alikes", the proposed usage is more intuitive than the current usage, in my opinion, and allows to assign NULL without side-effects. 2. As noted by others [e.g. Andrei Alexandrescu], member functions in smart pointers should be avoided if possible. The reset() function makes it hard to switch between raw and smart pointers, and also allows mix-ups: wp1.reset(), (*wp1).reset(), wp1->reset(). 3. The rawptr() function makes initialization and assignment explicit using an alternative and better syntax, IMO. E.g., you can verify that every shared_ptr owns a valid raw pointer by investigating instances of "rawptr(" in the code. Typically, you want to see: rawptr(new SomeClass(..)). To do this is not easy with the current implementation. You have to search for: a) "shared_ptr<" stack variable constructions of which takes raw pointers as arguments. b) ".reset(" for re-assigning a new raw pointer. Unfortunately reset() is a commonly used name. c) shared_ptr's in class member initiation lists, as mentioned in the example presented. 4. Most importantly, all raw pointers that are assigned to smart pointers must go through the rawptr() function (or rawptr_t<T> type), always making it "explicit". The problem in the example presented earlier, is therefore eliminated. 5. This proposal introduces no additional overhead, as long as the compiler really inline the rawptr() function (the operator new call is dominant by an order of magnitude in any case). 6. The only obvious problem I see, is the backward compability issue, although it still support the "unprotected but powerful pointer constructor approach", with a slightly different syntax. Implementation for shared_ptr ============================= rawptr.hpp (new file): --------------------- namespace boost { template <class T> class rawptr_t { public: explicit rawptr_t(T * p) : px(p) {} T* get() const { return px; } private: rawptr_t& operator=(const rawptr_t&); T* px; }; template <class T> inline rawptr_t<T> rawptr(T * p) { return rawptr_t<T>(p); } } shared_ptr.hpp (diff from boost 1.31.0): ---------------------------------------- *************** *** 109,114 **** --- 123,129 ---- // Borland 5.5.1 specific workaround typedef shared_ptr<T> this_type; + struct null_tag {}; public: *************** *** 117,130 **** typedef T * pointer; typedef typename detail::shared_ptr_traits<T>::reference reference; ! shared_ptr(): px(0), pn() // never throws in 1.30+ { } template<class Y> ! explicit shared_ptr(Y * p): px(p), pn(p, checked_deleter<Y>()) // Y must be complete { ! detail::sp_enable_shared_from_this(p, p, pn); } // --- 132,145 ---- typedef T * pointer; typedef typename detail::shared_ptr_traits<T>::reference reference; ! shared_ptr(null_tag* = NULL): px(0), pn() // never throws in 1.30+ { } template<class Y> ! shared_ptr(rawptr_t<Y> const & w): px(w.get()), pn(w.get(), checked_deleter<Y>()) // Y must be complete { ! detail::sp_enable_shared_from_this(w.get(), w.get(), pn); } // *************** *** 226,231 **** --- 241,258 ---- } #endif + shared_ptr & operator=(null_tag *) + { + reset(); + return *this; + } + + template<class Y> + shared_ptr & operator=(rawptr_t<Y> const & w) + { + this_type(w).swap(*this); + return *this; + } void reset() // never throws in 1.30+ { *************** *** 235,241 **** template<class Y> void reset(Y * p) // Y must be complete { BOOST_ASSERT(p == 0 || p != px); // catch self-reset errors ! this_type(p).swap(*this); } template<class Y, class D> void reset(Y * p, D d) --- 262,268 ---- template<class Y> void reset(Y * p) // Y must be complete { BOOST_ASSERT(p == 0 || p != px); // catch self-reset errors ! this_type(rawptr(p)).swap(*this); } template<class Y, class D> void reset(Y * p, D d) ------------------------------------------------------------ Få din egen @start.no-adresse gratis på http://www.start.no/

6 9

question re VC 8.0
by Robert Ramey 11 Aug '04

11 Aug '04

The test results for the serialization library show a problem with VC 8.0 which for the life of me I can't understand. http://www.meta-comm.com/engineering/boost-regression/developer/output/Rudbe kAssociates-bin-boost-libs-serialization-test-test_array_binary_archive-test -vc8-0-debug.html The corresponding code is below. If someone has any insight here I would love to here it. FWIW - no other compiler complains. - and I can't see anything wrong with it. If it's a bug - how do I work around it? Thanks in advance. Robert Ramey namespace boost { namespace archive { namespace detail { template<class Archive, class T> class iserializer; template<class Archive, class T> class oserializer; } // namespace detail } // namespace archive namespace serialization { // forward declarations namespace detail { template<class Archive, class T> struct member_saver; template<class Archive, class T> struct member_loader; } // namespace detail // use an "accessor class so that we can use: // "friend class boost::serialization::access;" // in any serialized class to permit clean, safe access to private class members // by the serialization system class access { public: // grant access to "real" serialization defaults #ifdef BOOST_NO_MEMBER_TEMPLATE_FRIENDS public: #else template<class Archive, class T> friend struct detail::member_saver; template<class Archive, class T> friend struct detail::member_loader; template<class Archive, class T> friend class boost::archive::detail::iserializer; template<class Archive, class T> friend class boost::archive::detail::oserializer; template<class Archive, class T> friend inline void serialize( Archive & ar, T & t, const BOOST_PFTO unsigned int file_version ); template<class Archive, class T> friend inline void save_construct_data( Archive & ar, const T * t, const BOOST_PFTO unsigned int file_version ); template<class Archive, class T> friend inline void load_construct_data( Archive & ar, T * t, const BOOST_PFTO unsigned int file_version ); #endif

6 8

Boost.Threads static linking status report
by Michael Glassford 11 Aug '04

11 Aug '04

Based on recent work and discussions here, I've checked in changes that implement tss cleanup in statically linked Boost.Thread on Win32 (for VC++ only, so far). I've also used the opportunity to rewrite the rest of the Win32 tss cleanup code and update it to use the Boost copyright. In the process, I eliminated threadmon.cpp, threadmon.hpp, and pe_tls.cpp. They've been replaced by tss_hooks.cpp, tss_hooks.hpp, tss_pe.cpp, and tss_dll.cpp. As suggested by Roland in his posted sample code, the default for VC++ linking of Boost.Threads is now static linking. I also changed all non-Win32 platforms to use static linking by default. I realize this is very late in the regression testing process to make these changes, but it seemed too good an opportunity to miss. If you disagree, please let me know. If the changes cause problems or it turns out to be a wrong decision in people's opinions here, I'll back the changes out quickly until after the release. In any case, many, many thanks to Aaron and Roland for working out this solution and making static linking possible on Win32. Mike

5 8

Sumptin' happened
by Victor A. Wagner Jr. 11 Aug '04

11 Aug '04

I don't know who did what to whom, but my regression test took over 8 hours last time. and now there are some new failures in VC7.1 I started it manually since it had missed the scheduled time to restart and looked at the log from cvs.... seems there are a lot of corrected files this time also. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

serialization and cwpro status
by Robert Ramey 11 Aug '04

11 Aug '04

Rene, Here is my assessment of the status of the serialization library as it relates to the Metrowerks compiler. all versions of CodeWarrior C++ CW two-phase lookup threw me for a loop. It took me long time to really understand this. Now that I do, I'm strongly convinced that it's a really bad idea. I don't know if its true - but I think I heard that it was implemented in order to make template export work - which looks like another bad idea to me. Oh well. CWPro 9.2 - my home copy All tests using utf8-codecvt fail. This includes the test for utf8-codecvt itself. I have come to believe that its an error somewhere in the MSL 9.2 implementation of the standard library. CWPro 8.3 - your machine The tests which serialize arrays fail - I haven't looked at this too carefully. There might be an issue regarding references to arrays decaying into pointers. Borland also has this problem. test_diamond fails with this compiler - I haven't figured out why it fails only here. CWPro 8.3 and 9.2 Hashed set serialization fails to produce the correct result at runtime. I haven't looked real closely at this. Since its particular to this version of CWpro I suspect it might be a library problem. I don't know how many standard libraries include support for hashed sets so I don't know for a fact that other compilers are in fact testing this. serialization of polymorphic derived pointers. Forward declaration method. I had reorganize code in archive_pointer_oserialize etc and use MSVC specific key words (used by BOOST_FORCE_INCLUDE) in order to get certain things to instantiate static variables whose pre-runtime construction is necessary for this to function. This seems like a bad idea as CW supports lots of other platforms. I tried every alternative I could find but wasn't able to find a better one that worked. "Export" functionality suffers from a variation of the above which I have not been able to overcome. So tests which use export fail. I've spent even more time on this - without success. It seems to me that CW is too smart in eliminating code that it "knows" it won't need. Actually I'm not even sure it's a CW issue. Comeau has the same symptom. That would suggest it's another manifestation of the problem I'm having comprehending two-phase lookup. CW < 8 I believe that these versions will pass 100 % Robert Ramey

4 5

Lock unification (shared vs. upgradable)
by Bronek Kozicki 10 Aug '04

10 Aug '04

Is there any reason for distinction between shared lock and upgradable shared lock? I mean - obviously updgradable shared lock can be upgraded to exclusive one, but do we need separate type for this? What's rationale behind this distinciton? I can easily imagine design (and implementation) where every shared lock is also upgradable one, if it's mutex type support upgrade operation. Under such design one can upgrade shared lock only if it's the only (currently locking) lock on synchromization object (supporting such transition). Implementation of such mutex could be very similar to semaphore (or just using semaphore, if present on platform). Here are some simple use cases: some_mutex_type_not_supporting_shared_locks m1; shared_lock<some...> l1(m1); // compilation error some_mutex_type_fully_supporting_shared_locks m2; shared_lock<some...> l2(m2); // ok exclusive_lock<some...> l3 = l2.try_upgrade(); // ok, non-blocking some_mutex_type_with_limited_support_for_shared_locks m3; shared_lock<some...> l4(m3); // ok exclusive_lock<some...> l5 = l4.try_upgrade(); // compilation error exclusive_lock<some...> l6 = l4.upgrade(); // ok, blocking some_mutex_type_with_minimal_support_for_shared_locks m4; { shared_lock<some...> l7(m4); // ok exclusive_lock<some...> l8 = l7.try_upgrade(); // compilation error exclusive_lock<some...> l9 = l7.upgrade(); // compilation error } exclusive_lock<some...> l10(m4); // ok B.

6 25

boost::filesystem problems under windows
by Stefan Seefeld 10 Aug '04

10 Aug '04

hi there, I'v some trouble with filesystem::path manipulation with boost release 1.31 / vc 7.1 . The code ----------- fs::path src = fs::path(__FILE__, fs::no_check); std::cout << "src= " << src.string() << std::endl; fs::path dir = src.branch_path(); std::cout << "script dir= " << dir.string() << std::endl; ----------- generates the output src= C:\cygwin\home\stefan\ToolBox\test\scripting\Algo\embedding.cpp script dir= C: i.e. it appears path::branch_path() doesn't work. Does anybody have an idea what's going on here ? Thanks, Stefan PS: oh, and if I replace the fs::no_check above by fs::native, I get an exception 'invalid path' which, I assume, fs::native is supposed to suppress.

1 0

pool/detail/mutex.hpp patch
by Thomas Witt 10 Aug '04

10 Aug '04

The attached patch fixes what I think is a bug in the win32 platform detection code. Thomas -- Thomas Witt witt(a)acm.org Index: mutex.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/pool/detail/mutex.hpp,v retrieving revision 1.4 diff -u -3 -p -u -r1.4 mutex.hpp --- mutex.hpp 14 Sep 2003 00:50:31 -0000 1.4 +++ mutex.hpp 10 Aug 2004 00:15:22 -0000 @@ -22,7 +22,7 @@ // No multithreading -> make locks into no-ops #define BOOST_MUTEX_HELPER BOOST_MUTEX_HELPER_NONE #else - #ifdef __WIN32__ + #if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) #define BOOST_MUTEX_HELPER BOOST_MUTEX_HELPER_WIN32 #else #include <unistd.h> @@ -37,7 +37,7 @@ #endif -#ifdef __WIN32__ +#if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) #include <windows.h> #endif #ifdef _POSIX_THREADS @@ -49,7 +49,7 @@ namespace boost { namespace details { namespace pool { -#ifdef __WIN32__ +#if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) class win32_mutex { @@ -73,7 +73,7 @@ class win32_mutex { LeaveCriticalSection(&mtx); } }; -#endif // defined(__WIN32__) +#endif // defined(_WIN32) || defined(__WIN32__) || defined(WIN32) #ifdef _POSIX_THREADS

2 2

Missing typename in range compat2_test
by Jonathan Wakely 10 Aug '04

10 Aug '04

This fail (and a related warning for GCC 3.3) http://boost.sourceforge.net/regression-logs/cs-Linux-links.html#range-comp… would be fixed by applying the attached patch jon -- ABROAD, adj. At war with savages and idiots. To be a Frenchman abroad is to be miserable; to be an American abroad is to make others miserable." - Ambrose Bierce, 'The Devil's Dictionary'

4 5

old filesystem improvements
by Walter Landry 10 Aug '04

10 Aug '04

Greetings, In the past, I've posted various patches to the filesystem library. Some of them were implemented, and some were not. In particular, I offered patches to implement symlink and readlink http://lists.boost.org/MailArchives/boost/msg52521.php the who() function for filesystem exceptions, http://lists.boost.org/MailArchives/boost/msg52522.php copy and copy_directory, http://lists.boost.org/MailArchives/boost/msg58652.php and hard links. http://lists.boost.org/MailArchives/boost/msg61975.php Since these posts, I've modified and extended some of them a little. I'm happy to post the new versions, but I am wondering if there is actually any interest in any of these things. Regards, Walter Landry wlandry(a)ucsd.edu

3 2

why run-fail tests are missing from Boost-wide reports?
by Gennadiy Rozental 10 Aug '04

10 Aug '04

Regards, Gennadiy.

1 0

Problems with MPL in Fusion on MSVC 6.5
by Peder Holt 10 Aug '04

10 Aug '04

Hi. I am porting Fusion, Joel de Guzmans new tuple library to MSVC 6.5 and VC 7.0. Several of the testcases ICEs on MSVC 6.5. I traced the problems back to integral_c's operator int() Problem: When the template expressions gets too complicated, MSVC is unable to handle inlined functions inside a type computer struct. Solution: Place the function body outside of the struct. The relevant lines: operator AUX_WRAPPER_VALUE_TYPE() const #if BOOST_WORKAROUND(BOOST_MSVC,==1200) ; #else { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif }; #if BOOST_WORKAROUND(BOOST_MSVC,==1200) template< AUX_WRAPPER_PARAMS(N) > AUX_WRAPPER_INST(N)::operator AUX_WRAPPER_VALUE_TYPE() const { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif This change fixed most of the remaining (known) issues with Fusion & MSVC Is it OK if I check in these changes? -- Peder Holt

4 4

shared_ptr for ROOT
by troy d.straszheim 10 Aug '04

10 Aug '04

Hi boost:: I have created a work derivative of the boost::shared_ptr and would like boost's OK before I release this into the wild. Explanation: I am on a large project, a neutrino telescope, that involves the ROOT data analysis framework (http://root.cern.ch) This is a large package, one of whose features is a C++ interpreter. That's right, an *interpreter*. You build shared objects describing your classes, load them into the interpreter, and then you can run C++ *scripts*. The ability to do all of this is absolutely insisted upon by my client, a platoon of physicists. From what I can see this is almost a standard in high-energy physics. The general idea is that, if one inherits one's object from the ROOT uber-object "TObject", and puts a macro into the class class MyClass : public TObject { // whatever ClassDef(MyClass, 1); // this inserts "streamer" functions }; then one can quite easily write these objects to disk, and use a whole slew of introspection functions that come from TObject, like bool InheritsFrom(string classname) and Browse().. well you get the idea. One's code must make its way through a code generator, called "rootcint" which adds a bunch of functions to the class. One then specifies the template instances that one wants dictionaries for with #pragmas. I managed to put together a hybridized boost::shared_ptr that works with this framework. Objects that are inherited from the TObject that contain boost::shared_ptr-s to other TObjects make the round trip to/from disk with all reference counting and everything intact. Not a small feat, if I may say so, and possibly of general interest to the ROOT community. This involved a hybridization of the no-member-templates shared_ptr and the "regular" shared_ptr. rootcint is very idiosyncratic. Member template friends don't work (I am told the fix is in CVS). sp_enable_shared_from_this doesn't work. template member functions do, for the most part, but the keyword volatile seems to confuse things. You get the idea. the atomic_count stuff had to be taken out. specializations of void didn't go through, if I remember correctly. I removed most everything that was not necessary for linux/macosx and gcc (our project's platforms). I dislike "forking" code and doing merges, but I could not imagine that boost itself would have any interest in supporting this toolkit's interpreter, the #ifdefs would be nightmarish, and testing required the framework itself, of course. I also could not leave the hybridized version named "boost", as the full boost libraries remain in our toolset, and anyway it would not be truth in advertising, I may very well have introduced some bugs. With perl's help I named everything "roost" (root/boost). I have left the comments intact at the tops of the files and where applicable added my own. the boost license is of course included. The documentation clearly states that this is a ROOT-specific version of the boost::shared_ptr<> Again, I just wanted to be sure this all was OK and give an opportunity to before I release this into the wild. The tarball is at http://www.resophonic.com/software/ROOST-1.0.tar.gz and runs tests with ./configure && make runtests Which would require ROOT (http://root.cern.ch) If you're interested, I can give quick instructions on that offline, mail me directly. Thanks, -t

2 1

Re: [boost] shared_ptr improvement proposal
by brangdon＠cix.compulink.co.uk 09 Aug '04

09 Aug '04

In-Reply-To: <200408091418.i79EIu107210(a)entwistle.systems.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > The whole point behind the names selected for the new-style casts > was to make things more verbose. Yes. And as a result, I know some people still sometimes use old-style casts entirely because they are shorter. I can see mine is a minority view, so now that I've made my plea I'll shut up :-) > Note that it can be written as follows when not casting to a > different pointer type: > > boost::shared_ptr<Widget> p(boost::shared_ptr_cast(new Widget)); Thanks, that helps. -- Dave Harris, Nottingham, UK

1 0

Boost.Thread compile problems
by Johan Nilsson 09 Aug '04

09 Aug '04

Hi, I'm getting errors from the tss handling when compiling Boost.Thread using the DEC CXX 6.5 compiler (under OpenVMS). The compiler doesn't like the fact that a pointer to a function with C++ linkage is being passed to a function expecting a pointer to a function with "C" linkage. The function in question is when the address of "thread_specific_ptr<T>::cleanup" is used as an argument to pthread_key_create (indirectly). I'm using Boost 1.31.0. The workaround I've implemented is the following (snippets from the modified source to illustrate): --- tss.hpp --- namespace boost { namespace detail { extern "C" { typedef void (*pthread_key_destruct_cb_t)(void*); <<<=== } class BOOST_THREAD_DECL tss : private noncopyable { public: tss(pthread_key_destruct_cb_t cleanup = 0); <<<=== [snip] template <typename T> class thread_specific_ptr : private noncopyable { public: thread_specific_ptr() : m_tss(reinterpret_cast<detail::pthread_key_destruct_cb_t>(&thread_specific_p tr<T>::cleanup)) <<<=== {} [snip] --- tss.cpp --- [snip] #elif defined(BOOST_HAS_PTHREADS) tss::tss(pthread_key_destruct_cb_t cleanup) <<<=== { int res = 0; res = pthread_key_create(&m_key, cleanup); if (res != 0) throw thread_resource_error(); } [snip] ------ I'd be very grateful if you could implement something similar (this might not be the prettiest fix) before the release of 1.32.0. There are also some very annoying warnings originating from meaningless casts (from timeconv.inl), e.g.: --- timeconv.inl --- [snip] const int NANOSECONDS_PER_SECOND = 1000000000; [snip] #if defined(BOOST_HAS_PTHREADS) inline void to_timespec(const boost::xtime& xt, timespec& ts) { ts.tv_sec = static_cast<int>(xt.sec); ts.tv_nsec = static_cast<int>(xt.nsec); if(ts.tv_nsec > static_cast<const int>(NANOSECONDS_PER_SECOND)) <<<=== [snip] ------------ Basically the compiler finds it pretty meaningless to cast "const int"s to "const int"s (and so do I). Possible to fix this also? Thanks // Johan

3 4

Boost Workshop at OOPSLA 2004
by Jeremy Siek 09 Aug '04

09 Aug '04

CALL FOR PAPERS/PARTICIPATION C++, Boost, and the Future of C++ Libraries Workshop at OOPSLA October 24-28, 2004 Vancouver, British Columbia, Canada http://tinyurl.com/4n5pf Submissions Each participant will be expected to develop a position paper describing a particular library or category of libraries that is lacking in the current C++ standard library and Boost. The participant should explain why the library or libraries would advance the state of C++ programming. Ideally, the paper should sketch the proposed library interface and concepts. This will be a unique opportunity to critique and review library proposals. Alternatively, a participant might describe the strengths and weaknesses of existing libraries and how they might be modified to fill the need. Form of Submissions Submissions should consist of a 3-10 page paper that gives at least the motivation for and an informal description of the proposal. This may be augmented by source or other documentation of the proposed libraries, if available. Preferred form of submission is a PDF file. Important Dates • Submission deadline for early registration: September 10, 2004 • Early Notification of selection: September 15, 2004 • OOPSLA early registration deadline: September 16, 2004 • OOPSLA conference: October 24-28, 2004 Contact committee oopsla2004(a)crystalclearsoftware.com Program Committee Jeff Garland Nicolai Josuttis Kevlin Henney Jeremy Siek _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Student, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________

1 0

Re: [boost] shared_ptr improvement proposal
by brangdon＠cix.compulink.co.uk 09 Aug '04

09 Aug '04

In-Reply-To: <200408061504.i76F4EW20044(a)entwistle.systems.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > Note, however, that "rawptr" is rather terse for something you're > trying to call attention to. I liked the terseness. To be honest I am less likely to use new features if they are verbose. "boost::raw_ptr()" is already 16 characters. Surely the main benefit comes from being able to search for raw_ptr with tools like grep, rather than with eyeballs? The later suggestion of writing: boost::shared_ptr<Widget> p = boost::shared_ptr_cast<Widget>(new Widget); is even more verbose and repetitive, the word "Widget" occurring 3 times. The original proposal: boost::shared_ptr<Widget> wp2 = boost::raw_ptr(new Widget(a, b)); at least fits into 80 columns. Is it time to wrap operator new()? For example: boost::shared_ptr<Widget> wp2 = boost::make<Widget>(a, b); with something like: template <typename R, typename A, typename B> inline raw_ptr_t<R> make( A &a, B &b ) { return raw_ptr_t<R>( new R( a, b ) ); } Users being allowed to specialise make<> with their own factory code if desired. -- Dave Harris, Nottingham, UK

4 3

[program_options / g++ 3.3.3] Problem with UTF-8 codecvt facet
by Tilman Kuepper 09 Aug '04

09 Aug '04

Hello world, I took a closer look at the UTF-8 codecvt facet which is part of the program_options library. A test program is attached. The last assert (in the Read-function) fails with g++ (GCC) 3.3.3 (Debian 20040429). After some debugging I think I found the problem: The function utf8_codecvt_facet_wchar_t::do_in() converts only valid (com- plete) UTF-8 sequences into internal (wchar_t) characters. In case the input buffer ends with an incomplete UTF-8 character, do_in() returns codecvt_base::partial and points from_next at the beginning of this incomplete UTF-8 sequence. Obviously the library (libstdc++) is surprised by the fact that the codecvt facet stops the translation, although there is still room in the output buffer (i. e. to_next != to_end) and not all input characters have been processed (from_next != from_end). As a consequence the for-loop in the test program stops too early (wifstream not "good" any longer) and assert(pos == wstr.size()) fails. Is this a known issue with the GNU library or with the UTF-8 conversion facet? And what can be done? Best regards from Aachen, Tilman PS: You can find the codecvt facet cpp/hpp files in the folders /boost/boost/program_options/detail/ and in /boost/libs/program_options/src/ PPS: There seems to be no problem with VC7.1/Dinkumware. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #include "utf8_codecvt_facet.hpp" #include <string> #include <iostream> #include <fstream> #include <locale> #include <cassert> using namespace std; using namespace boost; using namespace boost::program_options; using namespace boost::program_options::detail; namespace { wstring wstr; } inline bool IsUnicode(wchar_t wch) { if(wch >= 0x00D800 && wch < 0x00E000) return false; if(wch >= 0x00FFFE && wch < 0x010000) return false; if(wch >= 0x110000) return false; return true; } inline void MakeTestStr() { const size_t loops = 1; wstr.clear(); wstr.reserve(loops * 0x110000); for(size_t i = 0; i < loops; ++i) for(wchar_t wch = 0; wch < WCHAR_MAX; ++wch) if(IsUnicode(wch)) wstr += wch; } inline void Write() { locale loc; locale utf8loc(loc, new utf8_codecvt_facet<wchar_t, char>()); wofstream f; f.imbue(utf8loc); f.open("test.utf8", ios::binary); f << wstr; assert(f); } inline void Read() { locale loc; locale utf8loc(loc, new utf8_codecvt_facet<wchar_t, char>()); wifstream f; f.imbue(utf8loc); f.open("test.utf8", ios::binary); wchar_t wch; size_t pos = 0; for(; f.get(wch); ++pos) assert(wstr[pos] == wch); assert(pos == wstr.size()); // ***PROBLEM HERE*** } int main() { MakeTestStr(); Write(); Read(); }

3 4

BGL: which algorithm needs edge_index
by Andreas Fabri 09 Aug '04

09 Aug '04

Hello, The subject says it all. Which are the algorithms that need this property? googling boost I only found the subgraph thanks in advance, andreas

2 1

Virtual function parameter variance
by Dave 08 Aug '04

08 Aug '04

Hello all, Quoting from page 24 of "The Boost Graph Library; User Guide and Reference Manual": "It turns out that by the contravariance subtyping rule, the parameter type in the derived classes member function must be either the same type or a base class of the type as the parameter in the base class." Now please consider this code: #include <iostream> struct base_1 {}; struct derived_1: base_1 {}; struct base_2 { virtual void foo(derived_1 *p) {std::cout << "base_2::foo()\n";} }; struct derived_2: base_2 { virtual void foo(base_1 *p) {std::cout << "derived_2::foo()\n";} }; int main() { base_2 *ptr = new derived_2; ptr->foo(new derived_1); } This outputs base_2::foo(). Why? The quoted passage implies derived_2::foo() should override base_2::foo(). Clearly, it does not. Furthermore, I cannot find anything in the Standard that indicates it should. So, I am clearly misinterpreting the quoted passage. Can anybody explain to me what was meant in that passage? Thank you, Dave

3 4

type_with_alignment question
by Maxim Yegorushkin 08 Aug '04

08 Aug '04

I am using boost::aligned_storage<> and I would like it to be aligned on 32 byte boundary (the reason being that sizeof(my type) is 32 bytes and I want it to be aligned on x86 cash line size so that it is cashed most effectively). I am working now under VC7.1 and it seems like the maximum alignment I can get with the compiler is 8 which is the alignment of the largest built-in type which is long double (or a pointer to member/function). But type_with_alignment.hpp seems to have special support for gcc in the form of: namespace align { struct __attribute__((__aligned__(2))) a2 {}; struct __attribute__((__aligned__(4))) a4 {}; struct __attribute__((__aligned__(8))) a8 {}; struct __attribute__((__aligned__(16))) a16 {}; struct __attribute__((__aligned__(32))) a32 {}; } template<> class type_with_alignment<1> { public: typedef char type; }; template<> class type_with_alignment<2> { public: typedef align::a2 type; }; template<> class type_with_alignment<4> { public: typedef align::a4 type; }; template<> class type_with_alignment<8> { public: typedef align::a8 type; }; template<> class type_with_alignment<16> { public: typedef align::a16 type; }; template<> class type_with_alignment<32> { public: typedef align::a32 type; }; Are MSVSs going to be supported as they have similar extension __declspec(align(x))? -- Maxim Yegorushkin

2 2

Re:Re:[boost] [serialization] CW8 and the recent changes...
by Robert Ramey 08 Aug '04

08 Aug '04

Rene Rivera wrote: > The most recent changes cause a large number of new warnings to show up. > The are all of the form: > ### mwcc Compiler: > # In: ..\boost\serialization\void_cast.hpp > # From: ..\libs\serialization\test\test_array.cpp > # -------------------------------------------------- > # 188: __declspec(noinline) __declspec(dllexport) > # Warning: ^^^^^^^^ > # illegal type qualifier(s) Thanks, I'm on it - I'll check in a fix soon. I'm still struggling with cwpro8+ but haven't run out of options yet so stay tuned and have patience. Robert Ramey

2 1

[preprocessor] More changes for Digital Mars, and some of the examples.
by Daniel James 08 Aug '04

08 Aug '04

Hello, I've got some more changes for the preprocessor library. I noticed the other day that there are no tests for sequences in the preprocessor library, which meant that I hadn't tested them on Digital Mars, so I missed a couple of changes that were needed there. I've put up a patch at: http://myweb.tiscali.co.uk/calamity/patches/preprocessor-2.patch.gz This also contains some unit tests for sequences (I just took the list tests and made some changes). It also fixes some typos in the examples in the reference documentation. Daniel

1 0

RE:RE: Serialization Library format stability
by Robert Ramey 08 Aug '04

08 Aug '04

One final thought that didn't occur to me before would be to make your own "provably portable" archive. The current libraries all contain a default "fall through" which handles otherwise unspecified types. This could cause surprises when moving code/archives between environments. The alternative would be to make your own archive (or perhaps a derivation) which restricted the serializable types to those that have been specifically accounted for. More work - but might be necessary to guarantee archive portability. Also this might support the idea that the archives produced be accessable by other applications which don't use the serialization library which normally would be much more awkward to implement. Just a thought. Robert Ramey

1 0

RE: Serialization Library format stability
by Robert Ramey 08 Aug '04

08 Aug '04

Walter Landry wrote: > I am thinking of using your serialization library as part of another > project [1]. It will be writing files that need to be read by > multiple operating systems far into the future. So I was wondering, > how stable is the output format? I will be serializing maps, lists, > strings, bitsets, and some simple classes. Do you forsee any possible > changes in the disk format of those kinds of objects? This is an exceptionally good question. I'm amazed that no one has yet to raise it. If you don't mind, I will post it to the list as I don't believe others have given this the importance I believe it deserves. Anyway - here's my answer: It is one of the stated goals that this system produce portable archives as well as use portable code. By portable archives I mean archives that can save data structures on one platform (compiler/os/library) and recovered to another. This is not as easy as it might seem. I have take specific steps in the design and implementation to achieve this. a) My preferred archive - the simple text archive saves/loads primitives as text. This is inherently portable across platforms. XML is also portable. The included binary archive is not-portabable. The signature processing code will detect egregious violations of portability and trap with an exception. However this is not an exhaustive check. There is a demo which includes a portable binary archive. Floating point primitives would have to be added to make this complete. Ralf W Grosse-Kunstleve has submitted code that would address this but I haven't spent any time with it. b) I have taken extra pains that certain things are serialized the same way across platforms. Take std::list<int> for example. Practical efficiency considerations suggest that this should be stored without class information. The simple way of specifying this depends upon the usage of TPS which not all environments support. So I have used a different method to accomplish this. c) In the archive signature - there is a library format version index. If the format the archive type changes the newer code could include branch to deal with older format. I'm hoping it will never be necessary to use this but its there - btw - its now at #3. This would be a fallback. Possible problems: a) In practice, true archive portability will require more. For example, suppose I save an integer on a 64 bit machine to a text archive and load it to a machine which supports 32 bits. This would work fine - until the 64 bit machine saves an integer > 2^32 . This problem wouldn't be detected until the archive is loaded - way too late. Note that wchar_t, which is serialized as an integer, is 4 byte on gcc and 2 bytes everywhere else. So its possible/likely that this problem would surface where you least expect it. b) there are subtle problems than can arise. On some machines size_t is a macro that resolves to an integer while on some it's a true type. Saving a datum as an integer in one environment while recovering it as a type ( with a class id ) on another machine create surprises. Worse (or maybe better) this issue could look different for different archives. Text archives save/load book-keeping info (class-id, object-id, etc. in sequence so differences of this type will cause problems. XML archives include this information as attributes in the XML start tag. Attributes are retrieved by tag rather than by sequence (thanks to spirit) so in XML archives might work where the normal text archive fails. The good news is that this problem has been considered as goal from the very start. So all code has been written to accommodate this goal. That bad news is that this facility hasn't been exhaustively tested. What's needed is a separate/additional test suite which tests archive portability. This would mean a set of "canonical archives". The save test would create a new archives and compare each one to its "canonical" canonical counterpart. The load test would load the canonical archive and check to see that we recovered what we expected to. Implementation of such tests would reveal a host of small errors. For example, int64_t is just a typedef with gcc on a 64 platform while its separate type on on a 32 bit platform. This breaks compilation of the polymorphic archive at compiler time. In itself, its not too hard to resolve. But it requires careful thought to resolve it once and for all. Conclusion and recommendation So, if you want to use the serialization library for your project I would suggest. a) Just start doing it. The serialization library saves an incredible amount of coding and you can effectively just get on with the other more intesting parts of your project. b) When its time to think build your app on another platform and transfer archives between environments, you can rethink the issue. This is basically and economic argument. At this point: i) You will have invested no effort in serialization, so if it were deemed unsuitable, you would have lost no investment of effort if you decide to replace it with something else. ii) Maybe you'll get lucky and someone else will have made the archive portability test suite and the archives your interested in can be "guaranteed" portable. iii) If ii) above hasn't happened, you'll have to make your own archive portability test suite. The cost of this is also zero. This is because if you use some alternative to the serialization library, you'll still have to test the passing of serialized data between platforms in any case. If you make an archive portability test suite, please consider adding it to the library and tests. (Hmm - you're an academic - making such a test suite would be a great small project for one of your students. Important, educational, small enough to do in reasonable time, orthogonal to your main project goal - whatever that might be). Thanks for considering the serialization library for your project. Robert Ramey

1 0

detail/iterator.hpp: workaround_test fails with two-phase lookup (+ patch)
by Stefan Slapeta 08 Aug '04

08 Aug '04

On compilers with two-phase lookup (CW*) the workaround_test (range lib) fails because of incorrect typedefs in iterator.hpp. (Yes, I know it's very strange to disable partial specialization on a compiler with two-phase lookup.) OK to commit this patch for detail/iterator.hpp? Stefan Index: iterator.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/iterator.hpp,v retrieving revision 1.30 diff -u -r1.30 iterator.hpp --- iterator.hpp 26 Jul 2004 00:31:59 -0000 1.30 +++ iterator.hpp 5 Aug 2004 09:35:08 -0000 @@ -334,8 +334,8 @@ : std::iterator_traits<Iterator> { typedef typename std::iterator_traits<Iterator>::distance_type difference_type; - typedef value_type* pointer; - typedef value_type& reference; + typedef typename std::iterator_traits<Iterator>::value_type* pointer; + typedef typename std::iterator_traits<Iterator>::value_type& reference; }; template <class Iterator> @@ -343,8 +343,8 @@ : std::iterator_traits<Iterator> { typedef typename std::iterator_traits<Iterator>::distance_type difference_type; - typedef const value_type* pointer; - typedef const value_type& reference; + typedef const typename std::iterator_traits<Iterator>::value_type* pointer; + typedef const typename std::iterator_traits<Iterator>::value_type& reference; }; # ifdef BOOST_BAD_OUTPUT_ITERATOR_SPECIALIZATION

3 8

return type of arithmetic operators
by beckmann.bremen＠t-online.de 08 Aug '04

08 Aug '04

Hi, I want to use the arithmetic operators from boost/operators.hpp but found something strange. If one takes for example boost::rational which uses boost::addable (and others), it is possible to write the following: boost::rational<int> x, y, z; x + y = z; This is not possible for integral types. Is this intended, considered minor or just overseen? Wouldn't it be better for the arithmetic operators to return const T instead of T? Thank you in advance, Thomas

2 1

[1.32 Plan] release status?
by JOAQUIN LOPEZ MU?Z 08 Aug '04

08 Aug '04

Hi all, I have only limited access to the list these days, so my apologies if there's been some progress in this area that I missed to read about. Are we ready to schedule a final deadline for branching? >From what Alexsey stated last week, I understand we are now in a position to inspect results for all the relevant platforms, and the turnaround cycle is kept under a healthy 24 hours. The issues reports show regressions (red cells) for only five libraries, and the number of yellow cells is, IMHO, resonable, given the many exotic compilers that have been recently introduced in the regression tests. OTOH, the release date has slipped over three weeks now, and I guess we cannot just go on forever fixing things, as it is not realistic to expect that every issue be resolved in a reasonable amount of time. Maybe having some fixed schedule for branching will help concentrate on those problems that are really important. Just my 2 cents. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

concept_check: abnormal termination on CW 8.3?
by Stefan Slapeta 07 Aug '04

07 Aug '04

This concept_check test case http://tinyurl.com/5q3zk on CW 8.3 looks like an abnormal termination. Please could somebody with access to this compiler verify that? Stefan

3 2

[serialization] CW8 and the recent changes...
by Rene Rivera 07 Aug '04

07 Aug '04

The most recent changes cause a large number of new warnings to show up. The are all of the form: ### mwcc Compiler: # In: ..\boost\serialization\void_cast.hpp # From: ..\libs\serialization\test\test_array.cpp # -------------------------------------------------- # 188: __declspec(noinline) __declspec(dllexport) # Warning: ^^^^^^^^ # illegal type qualifier(s) # (included from: # base_object.hpp:30 # nvp.hpp:26 # interface_oarchive.hpp:26 # common_oarchive.hpp:20 # basic_xml_oarchive.hpp:28 # xml_oarchive.hpp:30 # xml_archive.hpp:8 # test_tools.hpp:108 # test_array.cpp:20) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

[boost.thread] regression on vc7.1
by Bronek Kozicki 07 Aug '04

07 Aug '04

Apparently there's some problem with tss on vc7.1, see http://tinyurl.com/5zqrs . I will look into it later today. I hope that we still have time to fix it, no need to pull static library support out of release 1.32. B.

2 1

bgl connected_components ComponentMap
by Andreas Fabri 07 Aug '04

07 Aug '04

Hi, I wrote my own property map class, and wanted to use it in the connected_component function, in order to retrieve the components. When it didn't work, I realised that the component map is copied internally, that is the result was written in the copy. I have an obvious solution for this, but I am nevertheless wondering if I missed something in the definition of the property map concept, or the connected_component class. thank you in advance, andreas

2 1

JavaScript Menu for BoostBook
by Reece Dunn 07 Aug '04

07 Aug '04

Hi all, I have attached a patch that will add support for the JavaScript Menu by Jonathan Turkanis to BoostBook. It generates frame.html and menu.html, leaving index.html unchanged. The tree control files are set as tree.js and tree.css. These are searched for in the directory provided by the toc.treecontrol xsl:param (set to ./tree as default). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

[dynamic_bitset] CW8 regression, a plea for help!
by Rene Rivera 06 Aug '04

06 Aug '04

In running my set of _release_ mode tests I ran into a regression for dynamic_bitset, you can see it here (the RSI results): http://www.meta-comm.com/engineering/boost-regression/developer/dynamic_bit… Boost regression: dynamic_bitset/CVS-HEAD This is a new regression... I just also ran the tests for the dynamic_bitset in 1.31.0, and 1.30.2 (this is the version I currently use in my production code) -- And both of those pass. I'm asking for help in tracking this down. I'm not familiar at all with the dynamic_bitset code so some direction as to likely causes of the problems, or where to start looking are much appreciated. For now I'll just be single stepping through the code, oh fun :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 9

[boost.thread] at_thread_exit must be serialized?
by Roland 06 Aug '04

06 Aug '04

Dear Mike, could you please give me the reasoning why the cleanup handlers that are specified in at_thread_exit must be serialized? It turns out that this is caused by a mutex located in on_thread_exit. Essentially this prohibits more than an exit handler chain to run at the same time. While there might be sound reasons for this I'd like to know please. How did I run into this: I wanted to bind the lifetime of a second thread to the one who started it. So I did soemthing like: void start(void) { if (!at_thread_exit(stop)) syslog_thrd = new cthread::cancelable_thread(&syslog_run); } The stop function beeing declared as: void stop(void) { if (syslog_thrd) { syslog_thrd->cancel(); syslog_thrd->join(); delete syslog_thrd; syslog_thrd = 0; } } When my first thread is exiting now, the stop is getting called properly. However my cancel causes the thread to exit (calling into its exit handler chain in turn). This will of course cause deadlock (altough in an non obvious way) since stop also has been called from the exit handler chain. The thread cannot be joined because it does not really end. You see? Perhaps you even can suggest another solution to my problem? Regards, Roland

2 5

Proposal for New Iterator Adaptor
by Alex Chovanec 06 Aug '04

06 Aug '04

I realize that this isn't the best time for proposals, what with everyone trying to get the next release of boost out, but I have an idea for a new iterator adaptor which I'd like to propose. Consider an adapted iterator type Iter with base iterator type Base that has the following traits: typedef Base value_type; typedef const Base & reference; When you dereference an instance of the adapted iterator type Iter, you get a const reference to its base iterator of type Base. So instead of delegating the dereference operation to its base and returning the result, the iterator adaptor simply returns its base. Since it doesn't dereference its base, I would probably name it "lazy_iterator", or something like that. There are some interesting things that you can do with this. For example: typedef std::vector< CString > vector; typedef std::vector< vector::iterator > iter_vector; typedef lazy_iterator< vector::iterator > lazy_iter; vector my_vector; iter_vector my_iter_vector; ... std::unique_copy( lazy_iter( my_vector.begin() ), lazy_iter( my_vector.end() ), std::back_inserter( my_iter_vector ), indirect_equal_to()); where indirect_equal_to is a special binary predicate which is defined like this: struct indirect_equal_to { template <typename Iter> bool operator==(Iter a, Iter b) { return *a == *b; } }; After this call to std::unique_copy(), my_iter_vector is a sequence of iterators that point to the unique elements in my_vector. Typically, you would just copy the unique elements into another vector of strings, but the approach described here is advantageous if you need to access the original unique elements in my_vector (for instance, if you need to change them), or if you want to avoid the overhead of copying strings. You could also have an iterator adaptor type Iter whose dereferencing operator returns &(*b), where b is its base iterator of type Base. This could be useful for generating ranges of pointers from ranges of objects. I think that this would be a useful iterator adaptor that would complement indirect_iterator very nicely. Whereas indirect iterator is useful for performing operations on ranges of iterators, this adaptor is ideal for generating ranges of iterators. Is anyone else interested in this? Thanks, Alex Chovanec

3 4

[boost.thread] Static Library support for Windows
by Roland 06 Aug '04

06 Aug '04

In the attached file you will find a proposal for how the problem of static linkage can be solved for Windows. The files can be dircetly inserted into the boost library framework. They almost do not touch existing implementation and also provide for a backup solution (overrideable) in case some unforeseeable things are happening. The solution has been worked out for MS compilers so far. However the principle should be portable to borland compiler as well. I would like to encourage someone with knowledge in this field to attempt this. Roland ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** *****************************************************************************

5 15

Date time query
by John Maddock 06 Aug '04

06 Aug '04

Just out of interest, what is the problem that prevents the date-time library from implementing a microsecond clock using GetSystemTimeAsFileTime on Win32? Thanks, John.

4 8

Updated Darwin tools
by Marshall Clow 06 Aug '04

06 Aug '04

Apple has released a new version of their developer tools, including an updated version of gcc. I have rerun the tests using the new gcc (3.3 build 1666). No major changes in the test results; a ICE while compiling one of the tests has been fixed. 30 failures (old compiler) vs. 28 (new compiler). -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Windows MSVC thread exit handler for staticly linked Boost.Thread
by Aaron W. LaFramboise 05 Aug '04

05 Aug '04

Following is an implementation of, and some comments on, a staticly linked Boost.Thread thread exit handler for MSVC. By the way, I appologize for talking so long to cough this up after posting teasing remarks about this months ago. Programming is presently a hobby and volunteer work for me, unfortunately. First, the handler itself: ---msvc_exit_handler.cpp--- // copyright disclaimed. ABSOLUTELY NO WARRANTY. #define WIN32_LEAN_AND_MEAN #include <windows.h> #define BOOST_THREAD_USE_LIB #include <boost/thread/thread.hpp> #include <boost/thread/tss.hpp> extern "C" BOOST_THREAD_DECL void on_process_exit(void); extern "C" BOOST_THREAD_DECL void on_thread_exit(void); namespace { // Force a TLS directory to be generated even when static TLS is not used. extern "C" int _tls_used; int dummy() { return _tls_used; } // Report thread and process detach events. void NTAPI tls_callback (PVOID, DWORD Reason, PVOID) { if(Reason == DLL_THREAD_DETACH) on_thread_exit(); else if(Reason == DLL_PROCESS_DETACH) { on_thread_exit(); on_process_exit(); } } // Add callback to the TLS callback list in TLS directory. #pragma data_seg(push, old_seg) #pragma data_seg(".CRT$XLB") DWORD tls_callback_ptr = (DWORD)tls_callback; #pragma data_seg(pop, old_seg) } // namespace // Indicate that TSS cleanup is implemented. extern "C" void tss_cleanup_implemented(void) { } ---EOF--- And a simple testcase: ---tss.cpp--- /* Uncomment the following to use _beginthread() to create theads instead * of CreateThread. */ // #define USE_BEGINTHREAD #include <iomanip> #include <iostream> #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <process.h> #define BOOST_THREAD_USE_LIB #include <boost/thread/thread.hpp> #include <boost/thread/tss.hpp> class myclass { public: myclass(); ~myclass(); }; myclass::myclass() { std::cerr << "init: " << GetCurrentThreadId() << '\n'; } myclass::~myclass() { std::cerr << "fini: " << GetCurrentThreadId() << '\n'; } boost::thread_specific_ptr<myclass> value; #ifdef USE_BEGINTHREAD void thread_proc(void *) { value.reset(new myclass); } #else // USE_BEGINTHREAD DWORD WINAPI thread_proc(LPVOID) { value.reset(new myclass); return 0; } #endif // USE_BEGINTHREAD int main(int argc, char *argv[]) { value.reset(new myclass); for (int i=0; i<2; ++i) { #ifdef USE_BEGINTHREAD _beginthread(thread_proc, 0, 0); #else DWORD id; CreateThread(0, 0, thread_proc, 0, 0, &id); #endif } Sleep(100); } ---EOF--- I tested this on Microsoft Visual C++ Toolkit 2003 on Windows XP SP1, as follows: C:\aaronwl\cs\boost\tls\handler>cl /EHa /MT /I"C:\aaronwl\cs\boost\cvs\boost" tss.cpp msvc_exit_handler.cpp ... C:\aaronwl\cs\boost\tls\handler>tss init: 2976 init: 4080 fini: 4080 init: 4040 fini: 4040 fini: 2976 Note that thread termination is correctly reported for all of the main thread and the two extra threads. It is my guess that this mechanism will work correctly on all versions of i386 Windows since Windows 95 and Windows NT 3.51. However, I have not tested it exhaustively due to lack of access. This mechanism is required to work by the PECOFF specification, so I'd expect any compliant x86 PE loader to support it. It is also my guess that this method of generating a thread termination notification will work on any version of MSVC that generates "32-bit" Windows executables. Only part of this compiler support, as implemented, is mandated by PECOFF. While apparently unused, completely undocumented, and largely unknown, the TLS callback section support is very similar to the general CRT global initialization and finalization routines, which--while they are also undocumented--most likely can never be removed as it would break backward object compatibility. I would be suprised if this did not work on a future MSVC version. This method of catching thread termination shares a very serious flaw with the DllMain() method: the thread PTD has already been destroyed by the time this code runs. As you can see, everything appears to work fine despite this; however, this is only by chance. In some cases, I think the code will silently do the wrong thing. For example, output might be lost. There was some suggestion about re-creating the PTD temporarily. This sounds good to me, except I can not find a reasonable way to do this, as the ptd manipulation functions are not exported the MSVCRT runtime dll. It might be possible to create a ptd manually, but this seems very risky to me. There was also mention of some sort of runtime library floating point hook. I was unable to figure out anything about this; however, if this is possible, and the ptd is still valid when this hook is called, that method is probably superior. As far as I can tell, FlsCallback() offers no advantage with regards to the ptd issue. It is also called "too late." Another problem with this method is that it gets destructor order wrong. For example, in the case of termination of the main thread, global destructors will be called before the TSS destructors are. This also could lead to silent misbehavior. It is likely that a better method for handling termination of the main thread could be found, such as a global destructor. Note that, with this method, it doesn't particular matter how the thread was created. There will be no ptd regardless of whether the thread was created with _beginthread or not. I am working on code for the MinGW runtime that should be able to cause GCC on Windows to handle TSS destructors perfectly. I don't know anything about any of the other Windows compilers with regards to this issue. In summary, I beleive this is the best shot so far at implementing thread exit handlers when Boost.Thread is statically linked, despite its serious problems. It is possible that a way to mitigate these problems, or a superior alternative, could be found. Aaron W. LaFramboise

10 82

[regression] New CodeWarrior 8.3 tests
by Rene Rivera 05 Aug '04

05 Aug '04

In an effort to improve the situation with this toolset, and since it's the one I'm currently most interested in, I started running a set of regression tests for it on my machine. The results are the ones with "RSI" as the name. I'm running the tests on demand, that is whenever I do a CVS update, or otherwise don't have the machine tied. So if anyone wants a faster response than waiting the 12 or 24 hours for the other tests to run, email me (privately) and I'll try and do an update and run new tests as soon as possible. Also one important difference between this set of test and the rest, is that I run them in *release* mode. So regressions relating to optimizations show up, and also relating to NDEBUG being set. But more about that in another post :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

Invalid include in half_open_range.hpp
by Stefan Slapeta 05 Aug '04

05 Aug '04

...breaks half_open_range_test (utility) on all compilers. OK to commit? Stefan Index: half_open_range.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/half_open_range.hpp,v retrieving revision 1.5 diff -u -r1.5 half_open_range.hpp --- half_open_range.hpp 26 Jul 2004 00:31:58 -0000 1.5 +++ half_open_range.hpp 4 Aug 2004 14:21:29 -0000 @@ -12,7 +12,7 @@ #ifndef BOOST_HALF_OPEN_RANGE_HPP_ # define BOOST_HALF_OPEN_RANGE_HPP_ -# include <boost/counting_iterator.hpp> +# include <boost/iterator/counting_iterator.hpp> # include <functional> # include <cassert> # include <boost/operators.hpp>

3 6

[program_options] printing the variable map
by Jeff Garland 05 Aug '04

05 Aug '04

I'm writing a program with program_options (very cool and useful library, BTW) and I found myself wanting to print out the variable_map values for debugging purposes. Is there an easy way to do this? Also couple of documentation nits: 1) From the first example.... if (vm.count("help")) { std::cout << desc << "\n"; I had to read the code to figure out that variable_map inherits from std::map, and this is why you can call this. Documentation only says: class variables_map : : public boost::program_options::abstract_variables_map 2) In the 'Storage Component' section -- there's this: Let's consider an example: variables_map vm; store(parse_command_line(argc, argv, desc), vm); store(parse_config_file("example.cfg", desc), vm); finish(vm); .... Finally the call to notify function runs user-specified notify functions and stores values into regular variables, if needed. I assume 'finish' is supposed to be notify? I don't see any docs for finish. Jeff

2 1

build-monitor yet again
by Victor A. Wagner Jr. 05 Aug '04

05 Aug '04

I put the --monitored back in my script: ========================================== python regression.py setup --user=vawjr --toolsets=vc7.1,vc8.0 --bjam-toolset=vc7 python regression.py install --user=vawjr --toolsets=vc7.1,vc8.0 --bjam-toolset=vc7 --incremental python regression.py test --user=vawjr --toolsets=vc7.1,vc8.0 --incremental --monitored python regression.py collect-logs --user=vawjr --runner=RudbekAssociates --incremental --comment comment.html python regression.py upload-logs --runner=RudbekAssociates ========================================== I took a couple of "pictures" of the task manager one before I went to bed last night and when I got up this morning they can be found at ftp://rudbek.com/pub/boost I've modified regression.py to: ========================================= utils.system( [ 'start /belownormal %s bjam.exe %d >build_monitor.log 2>&1' % ( build_monitor_path, timeout*60 ) ] ) ========================================= unfortunately build_monitor.log is 0 length this morning I believe that the the dir of the logfiles shows that the IRC client wasn't all shut down at the same time, it seems to have taken several minutes I thought I'd taken a before picture of the desktop, but I apparently don't understand my grabber as well as I thought. I'll take one now that should resemble a lot the one from before. I trust this evidence will put to rest whether build_monitor actually arbitrarily stops probrams with NO regard as to who or what started them. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

shared_ptr doc issue
by David Abrahams 05 Aug '04

05 Aug '04

In the constructor documentation, it seems that "Notes" is used to document what really are preconditions, e.g.: "p must be a pointer to an object that was allocated via a C++ new expression or be 0" Normally, "notes" are considered to be non-normative in the standard. I am trying to update a document on exception safety and it would be a big help if all the preconditions appeared in the "Requires" clause. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 3

boost\libs\python\build\VisualStudio workspace
by Max Khesin 05 Aug '04

05 Aug '04

VS6 refuses to open the .dsw & .dsp from CVS. Char. diff to v 31.0 shows that the files are equivalent - have they been set to binary or something? thanks, max. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

const_pointer_cast for shared_ptr
by Colin Rafferty 05 Aug '04

05 Aug '04

I would like to propose adding const_pointer_cast<> to shared_ptr, in exactly the same way that there is dynamic_pointer_cast<> and static_pointer_cast<>. I am surprised that it is missing. Is there a reason for that? If not, I will submit a patch that implements this. Thanks. -- Colin

5 4

[Boost-bugs] [ boost-Bugs-1003889 ] tokenizer and signed char
by SourceForge.net 05 Aug '04

05 Aug '04

Bugs item #1003889, was opened at 2004-08-05 04:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1003889&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: tokenizer and signed char Initial Comment: boost::tokenizer incorrect works on platforms on which plain char is signed. For example, at least in boost::char_delimiters_separator::is_nonret should be explicit conversion from char type to int type. Something like this std::isspace (std::char_traits<Char>::to_int_type(E)). Minimal reproducer for this issue which uses Russian letters results in assert in MSVC 7.1: // cl /Zi /MDd -D_DEBUG test.cpp #include <boost\tokenizer.hpp> #include <string> #include <iostream> using namespace std; using namespace boost; int main() { string s = "Здравствуй мир!"; tokenizer<> tok(s); for (tokenizer<>::iterator beg=tok.begin(); beg! =tok.end();++beg) { cout << *beg << "\n"; } } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1003889&group_… ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

CVS snapshot problems (Was: [Boost-docs] Re: howto include .xml from doxygen autodoc into html from boostbook)
by Aleksey Gurtovoy 05 Aug '04

05 Aug '04

David Abrahams writes: > Larry Evans <cppljevans(a)cox-internet.com> writes: > > > [snip] > >> I've checked in a potential fix. By the way, which version of > >> Doxygen are you using? > > Since I was having trouble with boost-cvs, I downloaded the tar.bz2 > > file: > > http://www.boost-consulting.com/boost.tar.bz2 > > That might be several days old. I've been periodically getting > messages from my cron job that the tar.bz2 it downloads from SF is > corrupted. That's pretty bad, especially given that it's supposed to be an *hourly* snapshot. A few people are running regressions against it under this assumption. Should we provide an alternative resource for them? -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re[3]: [boost] Re: Re[2]: Re: Windows MSVC thread exit handlerfor staticlylinkedBoost.Thread
by Ferdinand Prantl 05 Aug '04

05 Aug '04

Hi Roland, _RTLDLL reminds me of borland or some other compiler, microsoft sets _DLL internally, if you use dynamic runtime (/MD or MDd). some essential for threading: if _MSC_VER: microsoft or intel (__INTEL_COMPILER for intel specific) then _MT: if multithreaded runtime then _DLL: if dynamic runtime Ferda > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Roland > > Just beeing curious. How does the _RTLDLL getting set? > I experimented with > #ifdef _RTLDLL > #error "DLL RT" > #else > #error "STATIC RT" > #endif > > No matter which runtime I select it always seems not to be defined. > > Roland

2 1

RE: [boost] VC 7.1 level 4 warnings (thread, lexical_cast)
by Brian Braatz 05 Aug '04

05 Aug '04

Paul A Bristow Wrote: > And I also note that there was an deficiency in lexical cast which, AFAIK > as > not been fixed. We don't seem to have the mecahnism for maintenance > working > as well as initial review, if the original author loses interest - an > increasing problem? [Brian Braatz] Suggestion: Identify those orphaned libraries in one place (one email) Communicate to this group the orphaned libraries Ask for volunteers to maintain said libraries

2 1

Re: Boost Mathematicians
by Michael Stevens 05 Aug '04

05 Aug '04

Hi Dave, hi all, I read with interest you plans for reviving MTL. It is certainly a shame that development of MTL was been stagnant for so long. It certainly had many interesting design features and I used it for all my work for many years. That said I switched to using and developing uBLAS long ago and it has an excellent design. On Saturday 05 June 2004 13:53, David Abrahams wrote: > "Neal D. Becker" <ndbecker2(a)verizon.net> writes: > > David Abrahams wrote: > >> Tom Brinkman <reportbase(a)yahoo.com> writes: > >>> In short, lets tell the world that this is the > >>> premiere place for advanced mathmatical library > >>> development, as I believe that it could be. > >>> > >>> Comments? > >> > >> 1. I think oonumerics.org has the jump on us here, though the site > >> seems to be douwn at this moment. > >> > >> 2. I will be starting work on a rewrite of MTL (the Matrix > >> Template Library) for linear algebra soon. > > > > What do you plan for MTL? How is it different than ublas? > > MTL is aimed at linear algebra, whereas IIUC ublas is not. Well the L and A in uBLAS certainly stand for Linear Algebra! Of course the B stands for Basic and uBLAS's primary aim is to provide the standard set of BLAS functions in a modern C++ environment. Of course as it stands the complete uBLAS library is more then just the BLAS functions and includes some common Linear Algebra algorithms and many useful types. That said I think it is important to separate BLAS functions from domain specific linear algebra algorithm development. This is something that proved itself since the seventies. > There's a lot more to what's in the current plan than I can lay out > here, but the focus will be on support for different kinds of matrices > with combinations of these aspects > > o Shape > o Orientation > o Symmetry > o Sparsity > o Blocking > o Upper / Lower storage > o Unit diagonal Other then the many forms of blocking (other then banded) uBLAS supports all these in its design. This really is its strength! To a large extent they can even be combine these properties where it makes mathematical sense. For example you can wrap up one of a number of sparse matrix types in a symmetric adaptor. > > and operations like: > > o scalar-vector (vector-scalar) multiplication > o vector addition (and subtraction) > o apply linear operator (left) > o norm > o inner product > o triangular solve Other then 'apply linear operator' these are all in uBLAS! > with expression templates, and of course, zero abstraction penalty ;-) Of course uBLAS does this all with ET, but the abstraction penalty may not be zero :-) Other then the lack of ET in the current MTL the big difference between the two libraries is the definition of iterators. Neither design seems to be perfect with regard to efficiency. Since uBLAS is already in Boost and has a well established and clean user syntax it would seem strange to ignore it. For the perspective of building further Linear Algebra algorithms it would not be too hard to use the syntax sufficiently portably so that a future MTL with expression templates could not be used interchangeably. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

12 18

Boost.Test fails to build on IRIX/mipspro
by Aleksey Gurtovoy 05 Aug '04

05 Aug '04

See http://www.meta-comm.com/engineering/boost-regression/developer/test.html -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Boost License future considerations
by Michael Glassford 04 Aug '04

04 Aug '04

Thinking about the problems we're having now contacting people to get permission to switch to the Boost license, I got to wondering what would happen if at some point in the future the Boost license needed to be changed (for instance, due to some legal challenge). I assume the possibility of it changing was considered; after all, usually if you give something a 1.0 version number you leave open the possibility of a version 1.1 or 2.0. What could we do to avoid even worse problems if that ever happens? Would it make sense to have people add their names to a blanket permissions file (or add explicit permission in their submissions) that would allow the copyright for their submissions to be updated under certain circumstances in the event that they could not be contacted for permission? What legal issues would be involved in such a case? Just a thought, Mike

5 12

Review Wizard Status Report
by Tom Brinkman 04 Aug '04

04 Aug '04

1) Proposed Library Review Schedule We have eight very interesting libraries to consider for inclusion into boost the next few months. If there are no objections, I will schedule reviews for next four libraries, as follows: (please contact me for adjustments to this schedule) More IO - Daryle Walker August 18, 2004 Iostreams - Jonathan Turkanis August 28, 2004 Output Formatters - Reece Dunn September 7, 2004 Pointer Containers - Thorsten Ottosen September 17, 2004 Named Params - David Abrahams & Daniel Wallin To be Determined Wave - Hartmut Kaiser To be Determined Policy Pointer - David Held To be Determined Finite State Machine (FSM) - Andreas Huber To be Determined 2) Algorithm Mini-Reviews If there are no objections, I will also schedule a mini-review of some of the algorithms from wiki starting September15, 2004. The format of the boost algorithms review has yet to be established and will evolve over time. Please contact me if you have any suggestions as to how this first boost algorithms review proceeds. 3) Review Managers Needed Please contact me if you would like to serve as a review manager for a library under consideration for inclusion into boost. It would be greatly appreciated and is a great way for you to network with other boost users. Tom Brinkman Boost Review Wizard __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

4 3