- Boost - lists.preview.boost.org

[string_algo] split suggestion
by Vladimir Prus 08 Sep '04

08 Sep '04

Hello, suppose I have a string "module.foo1.port" and want to get the second dot-separated element. I think I can use the 'split' algorithm, but it does not look very convenient, I need to declare container, then call split and then obtain the result. In Qt, there's QString::section method, which allows to do this in one line. Here's example from the docs: QString csv( "forename,middlename,surname,phone" ); QString s = csv.section( ',', 2, 2 ); // s == "surname" And the complete docs are at: http://doc.trolltech.com/3.3/qstring.html#section Maybe, something like this can be added? - Volodya

2 3

RE: [boost] Re: RFI: RMI in C++
by Schalk_Cronje＠McAfee.com 08 Sep '04

08 Sep '04

In a related vein, I have been working on a generic functionality to launch asynchronous functions be it in another thread, another process or even out-of-box. The key is the definition of a set of asynchronous function traits allowing a number of free functions such as run_task() wait_task() and task_result() to be presented. One might for instance have something like to run a task on a different thread // Assuming boost::threader is defined and != boost:thread // The following line will launch a function on a separate thread using boost:thread. task_id<boost::threader> id= run_task( boost::threader(), boost::bind( my_dns_request, "www.boost.org" ) ); // do some work here { } // and some time later wait for request to finish wait_task( id ); By specialising the asynchronous function traits it can allow for requests to performed on another host via SOAP or in a RMI-lie fashion for instance. Would anyone be interested in something like this?

1 0

Re: [boost] [serialization] request: low-level info about order of serialization
by Robert Ramey 08 Sep '04

08 Sep '04

>I'm slowly designing the addition of serialization support to >Boost.MultiIndex, and come up with a need that, AFAIK, the >current serialization library does not cover: >The serialization of a multi_index_container should ensure that >the order in which elements appear is preserved for all indices >of the container. Appear? >This implies serializing the elements and then >recording the appropriate rearrangements in each index. I'm >writing the code for serializing these rearrangements in >an efficient manner as some sort of "diff" sequences, using >an algorithm called "longest increasing subsequence" (LIS). >The algorithm would greatly benefit for some low-level API >by the serialization lib that, given an object reference, would >return the order in which that object was serialized. I guess this >information is already available internally, as the lib must keep >track of previously saved objects. >If this requirement is deemed too exotic to provide to the >general user, well, I can write something myself without aid from >the lib, but I thought I should ask at least :) It seems too exotic to me. The focus of the serialization library is to re-create exactly that which was there before. So far, that has already been possible with the API provided. Some containers (e.g. slist) required a little bit of special handling to preserve sequence but this did not require any change in the basic API. All of this special handling is part of the implementation of the container in question. I'm really not sure what your doing, so without knowing more its hard for me to comment. Robert Ramey

2 1

Re:[boost] Boost serialization: release configuration linker errors
by Robert Ramey 08 Sep '04

08 Sep '04

Andy Favell >Thanks for the info, actually yes, I am using version 1_31. Is that a >mistake by me? Personally I would recommend using 1.31 until 1.32 is released. >Can you tell me where the CVS tree is, thanks, www.boost.org main page has a link to the main cvs tree. Robert Ramey

1 0

boost::generic_pool ??
by Rohit Joshi 08 Sep '04

08 Sep '04

boost::pool is specific to memory pool. boost doesn't have library to support generic pool which can be used for connection pooling, thread pool or any generic object pooling. Look at this article : "Generic Pool : Policy based design (http://www.codeproject.com/library/Generic_Pool_Design.asp) I like the concept and let's make it as part of boost library. What's your opinion???

1 0

IOStreams basic_newline_filter convenience request
by Jonathan Graehl 08 Sep '04

08 Sep '04

For basic_newline_filter (great idea; I hadn't even realized Macintosh had yet ANOTHER newline convention), it would be nice to be able to get the current line number and possibly even the character number on that line, for reporting errors in input. I realize this should be possible as a separate filter counting '\n' and non-'\n' characters, which handles the output of basic_newline_filter, but I don't think the cost of maintaining one or two counters would be too much a burden for those who don't need it (or if it is, provide versions with and without). Even nicer would be a call that extracts up to the previous N already consumed characters, for even more helpful context (I have already made a practice of showing the next N characters to be read in case of a fatal error, when the input is a file and not interactive). Obviously this could be a filter in its own right, and really has nothing to do with basic_newline_filter.

2 1

possible conflict with new mpl
by Pavol Droba 07 Sep '04

07 Sep '04

Hi, After merging the new MPL version, an error popped out in vc7 tests of string_algo lib. http://tinyurl.com/3t6zc It seems that std::distance is conflicting with something else. I'm using both "using namespace std;" and "using namespace boost;" in the tests. This problem do not appear with other compilers. I can possibly fix it with the explicit qualification, but it may just hide some other problem. Any suggestions? Regards, Pavol

3 4

IOStreams Formal review -- Guide for Reviewers
by Jonathan Turkanis 07 Sep '04

07 Sep '04

Dear All, I've been very pleased with the discussion of the iostreams library so far. I'd like to thank all those who have posted review and comments. One thing that has been lacking, to a large extent, is a detailed examination of the source code. I understand that this may seem a daunting task, since the library is quite large. Therefore, I would like to point out the relatively small bits of the source which contain the core implementation. I'll also give a brief description of the filtering framework, to make it easier to answer the questions raised by Carlo Wood that large amounts of data are being copied needlessly. Finally -- the easiest part -- I'll mention what I think are the most important outstanding issues about the library interface. ----------------------------------------------------- Part I: Overview of the source. Even if you only look at one of the following three sections, I'd be very happy :-) A. Filter and resource support. This provides the infrastructure for the generic i/o operations read, write, close, etc. It contains no definitions of stream or stream buffers: <boost/io/categories.hpp> <boost/io/concepts.hpp> <boost/io/operations.hpp> <boost/io/io_traits.hpp> <boost/io/detail/ios_traits.hpp> <boost/io/detail/wrap_unwrap.hpp> B. Policy-based streams and stream buffers. This provides the implementation of the fundamental library component streambuf_facade: <boost/io/detail/adapters/filter_adapter.hpp> <boost/io/detail/adapters/resource_adapter.hpp> <boost/io/detail/streambufs/direct_streambuf.hpp> <boost/io/detail/streambufs/indirect_streambuf.hpp> <boost/io/streambuf_facade.hpp> C. Filtering streams and stream buffers. This provides the infrastructure for chaining filters. <boost/io/detail/chain.hpp> <boost/io/detail/streambufs/chainbuf.hpp> <boost/io/filtering_streambuf.hpp> ----------------------------------------------------- Part II. Implementation of filter chains. The following diagram should be viewed with a fixed-width font: streambuf1 streambuf2 streambuf3 filter1 -> filter2 -> resource [------------] [------------] [------------] buf1 (size n1) buf2 (size n2) buf3 (size n3) ^ | | filtering_stream Here the end user write to the filtering_stream at the bottom of the diagram, and the data is passed through streambuf1, streambuf2 and streambuf3, each of which contains a character buffer and either a filter or a resource. The end user, through the filtering stream functions and operatiors, writes *directly* to buf1. When buf1 is full, the buffer's contents are passed to filter1 as follows: filter1.write(streambuf2, buf1, buf1 + n1); This writes *directly* to buf2. When buf2 is full, filter2 is called filter2.write(streambuf3, buf2, buf2 + n2); This writes *directly* to buf3. When buf3 is full, resource is called: resource.write(buf3, buf3 + n3); In the general case, data is copied no more than absolutely necessary. There are some special cases where the copying is wasteful, though. For instance: 1. If filter1 is just a passive observer, simply counting the number of occurences of '\n', or copying the data to a logging stream, then the end user should really be writing directly to buf2. Filter1 could process the data using the same buffer as filter2. 2. Same as above, but filter1 also modifies the data in-place, making character-by-character modifications. (E.g., a toupper filter). This can be handled the same way. 3. If 'resource' is a stream or stream buffer, it could be assumed to do its own buffering. In that case, filter2 should be writing directly to resource, instead of to streambuf3: filter2.write(resource, buf2, buf2+ n2). These three cases can be handled easily by modifying the existing framework. I didn't add special treatment because it occurred to me rather late in development. There is another class of cases in which the current setup is wasteful, but I think it is rather domain-specific: 4. Most filters in the chain modify only small parts of character sequences, leaving big chunks unchanged. For example, a web server might have a chain of filters which add headers to an HTTP message, but leave the body unchanged. In this case, it might be better to allow the filters to send the body through the chain simply as a pointer to a file or memory block. If at some point a filter needs to modify the body, it will read the actual data, modify it, and send it to the next filter as a sequence of characters rather than a pointer to a file or memory block. To optimize case 4 would require a major library extension. My feeling is that it is not necessary at this point, but I'd like to know what others think. ----------------------------------------------------- Part III: Interface questions: 1. How to handle read and write requests which return fewer characters than requested, though there has been no error, and EOF has not been reached. I think some answer to this question is necessary to allow the library to be extended later to handle models orther than ordinary blocking i/o. I mention three possibilties here, http://tinyurl.com/6r8p2, but only two are realistic. I'm interested to know how important pople think this issues is, and what is the best way to resolve it. 2. The stack interface. Is the interface to the underlying filter chains rich enoguh? Originally is was similar to std::list, so that you could disconnect chains at arbitrary points, store them, and reattach them later. I decided there wasn't much use for this, so I simplified the interface. 3. Exceptions. James Kanze has argued repeatedly that protected stream buffer functions should not throw exceptions (http://tinyurl.com/5o34x) I try to make the case for exceptions here: http://tinyurl.com/6r8p2. What do people think? 4. Closable. Many output filters need to write additional information to a stream as soon as it is about to close. For instance, a gzip_compressor needs to write a checksum and message length. This is one of the motivations for the 'Closable' concept (http://tinyurl.com/3pg5j) Sometimes, however, the beginning -- rather than the end -- of a character sequence requires special treatment. For instance, a gzip_compressor must write the gzip header before the compressed data is written. Currently this has to be implemented using a 'first-time switch'. So the question is: Should an open() function be added to the closable interface, to eliminate the need for first-time switches? Alternatively, should there be a separate Openable concept? ----------------------------------------------------- Best Regards, Jonathan

1 0

IOStreams formal review
by John Torjo 07 Sep '04

07 Sep '04

------------------------------------------- * What is your evaluation of the design? Very nice and clean. ------------------------------------------- * What is your evaluation of the implementation? ------------------------------------------- * What is your evaluation of the documentation? Documentation is very nice and neat. Small comments: tutorial.html: " The Iostreams Library allows users to create a standard input stream or stream buffer by defining a classes with a single member function read and several member types." Q: What do you mean, by 'several member types'? "Buffering and the ability to put back characters come for free." Q: Can I putback multiple chars, or just one? 3.4 Output Filters Here your examples use 'filtered_streambuf', while in the Reference section, you use 'filtering_streambuf'. Is this a typo? examples.html I love the presidential filter ;) policy_based_streams.html: I think you should visually show that streambuf_facade owns the policy (the source). I had to look through the code to realize that. I have later realized that you did say at the beginning " by delegating to a contained instance of a policy class". Maybe emphasize the "contained instance" (bold or something)? filtering_streambuf.html: Again, by looking at the code, it seems that you own the streambufs. Is that so? If it is, please state it in the docs (this is more of a general issue - it applies to other classes as well). I am worried about this, since I want to know what I need to destroy manually, and what is destroyed automatically for me. General issues: I'm not sure if mixing streambuf and stream concepts is such a good idea. As I've seen in your examples, you only use streams. Tnus, you don't use streambufs directly. While having streambuf_facade is DEFINITELY a good idea, I think you should have an "Advanced" section, where you talk about the streambufs. The rest of us are quite happy with having and using stream_facade. ------------------------------------------- * What is your evaluation of the potential usefulness of the library? Very useful ------------------------------------------- * Did you try to use the library? With what compiler? Did you have any problems? VC7.1 Compiled some examples - they worked ok, after I slightly modified the jamfile. (which makes me not like bjam even more - it makes it so hard to build even trivial things) ------------------------------------------- * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Reviewed it several times (in the past as well). ------------------------------------------- * Are you knowledgeable about the problem domain? Yes ------------------------------------------- * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. I think this library should be ACCEPTED. 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) # Boost.Iostreams Library Build Jamfile # (C) Copyright Jonathan Turkanis 2004 # Distributed under the Boost Software License, Version 1.0. (See accompanying # file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt.) subproject libs/io/build ; # bring in compression-options template import ../build/compression ; local ZLIB = [ cond $(NO_ZLIB) $(NO_COMPRESSION) : : zlib ] ; local LIBBZ2 = [ cond $(NO_LIBBZ2) $(NO_COMPRESSION) : : bzip2 ] ; SOURCES = file_descriptor memmap $(ZLIB) $(LIBBZ2) ; lib boost_io : ../src/$(SOURCES).cpp [ unless $(NO_COMPRESSION) : <template>compression-options ] : # build requirements [ common-names ] # magic for install and auto-link features <include>$(BOOST_ROOT) <sysinclude>$(BOOST_ROOT) : debug release # build variants <debug><runtime-link>static <release><runtime-link>static ; dll boost_io : ../src/$(SOURCES).cpp [ unless $(NO_COMPRESSION) : <template>compression-options ] : # build requirements [ common-names ] # magic for install and auto-link features <define>BOOST_IO_DYN_LINK=1 # tell source we're building dll's <runtime-link>dynamic # build only for dynamic runtimes <include>$(BOOST_ROOT) <sysinclude>$(BOOST_ROOT) : debug release # build variants ; install io lib : <lib>boost_io <dll>boost_io ; stage stage/lib : <lib>boost_io <dll>boost_io : # copy to a path rooted at BOOST_ROOT: <locate>$(BOOST_ROOT) # make sure the names of the libraries are correctly named: [ common-names ] # add this target to the "stage" and "all" psuedo-targets: <target>stage <target>all : debug release # build variants ; # end

4 9

Re: [boost] IOStreams formal review
by Reece Dunn 07 Sep '04

07 Sep '04

Carlo Wood wrote: >On Tue, Sep 07, 2004 at 07:41:25AM +0200, John Torjo wrote: > > Why binary? I could see lots of uses for text as well. > >Because text is a special case of binary. If the library >supports streambufs, and when it would support the concept >of 'message blocks', then "text" just means that you'd >detect End-Of-Line sequences and cut the stream into >messages that are in fact lines of text. Bring a text stream means that you do \r\n <--> \n normalization for the streams (or whatever end of line encoding your OS uses). That, AFAIK, is the only percievable difference between the two modes according to the standard. (I am not sure how text streams handle '\0'). >Actually putting that text in a std::string and doing >some work on it should be in user code imho. This would be inefficient in most contexts. Especially if you have a complex filter chain with inbuilt buffers that are only concerned with character-by-character processing. I understand that in some cases it would be useful to see the data as a sequence of lines stored as std::string, but then isn't that what: std::string str; std::ifstream in( "data.txt" ); while( std::getline( in, str )) { std::cout << "line = " << str << '\n'; } is for? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

Boost serialization: release configuration linker errors
by Andrew Favell 07 Sep '04

07 Sep '04

Robert, Thanks for the info, actually yes, I am using version 1_31. Is that a mistake by me? Can you tell me where the CVS tree is, thanks, Andy Favell -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

typeless trampoline
by Bronek Kozicki 07 Sep '04

07 Sep '04

Hi I factored out trampoline class from my ext_auto_ptr_090 . I'd like to know how it works on modern compilers. I was able to test it on few compilers I use for regression tests: msvc71 (passed with FAULTY set) como 4.3.3 with backend msvc71 mingw 3.3.1 mingw 3.4.1RC I will be happy to know how it works with other compilers. Maybe boosters could test this code with some compilers? I'm especially interested in recent Intel and CW versions. I think that it might be useful utility in boost, provided I can make it enough functional (passing arguments to function is first thing to be added). B. #include <cassert> #include <cstdio> #include <utility> // Copyright Bronislaw Kozicki 2003-2004. Use, modification and // distribution is subject to the Boost Software License, Version // 1.0. (See http://www.boost.org/LICENSE_1_0.txt ) #ifndef __COMO__ # if defined(_MSC_VER) && (_MSC_VER <= 1310) # define FAULTY # endif // _MSC_VER #endif // __COMO__ template <bool> struct static_assert; template <> struct static_assert<true> {}; class trampoline { private: typedef void(*_pf_t)(void *); template <typename Functor> struct _lever_t; template <typename Functor> struct _lever_t<Functor *> { static_assert<sizeof(Functor*) == sizeof(void *)> size; union convert { Functor* f; void* p; }; static void exec(void * p) { convert c; c.p = p; (*c.f)(); } static std::pair<_pf_t, void *> init(Functor* f) { convert c; c.f = f; return std::pair<_pf_t, void *>(&exec, c.p); } }; // the one and the only data std::pair<_pf_t, void *> _pf; public: template <typename Functor> trampoline(Functor f) : _pf(_lever_t<Functor>::init(f)) {} trampoline(const trampoline& rh) : _pf(rh._pf) {} trampoline& operator=(const trampoline& rh) { _pf = rh._pf; return *this; } void operator()() { _pf.first(_pf.second); } }; static int tmp = 0; static const int tmp_f = 2; void f() { printf("f()\n"); tmp = tmp_f; } static const int tmp_g = 5; static const int tmp_g_f = 6; #ifdef FAULTY int g() { int i = tmp_g_f; printf("faulty "); #else int g(int i = tmp_g) { #endif tmp = i; printf("g(%d)\n", i); return tmp; } static const int tmp_A = 10; struct A { void operator()() const { printf("A::operator()()\n"); tmp = tmp_A; } }; trampoline f1() { return trampoline(&f); } trampoline g1() { return trampoline(&g); } trampoline A1() { static A a; return trampoline(&a); } int main() { trampoline l = f1(); l(); assert(tmp == tmp_f); l = g1(); l(); assert(tmp == tmp_g || tmp == tmp_g_f); l = A1(); l(); assert(tmp == tmp_A); }

5 13

[mpl] mpl::if_ workaround for digital mars
by Daniel James 07 Sep '04

07 Sep '04

Aleksey, I've just been trying the new version of mpl on Digital Mars. The attached patch fixes the bug that sometimes causes mpl::if_ to fail. The problem is that the class template gets redeclared with different parameter names by bind.hpp, and this confuses the compiler. When it instantiates the class, it uses the wrong names. The fix is just to make sure bind.hpp is included before mpl::if_ is defined. thanks, Daniel

3 5

Thread-safe containers
by Tony Juricic 07 Sep '04

07 Sep '04

Browsing through the older posts I could not find any relevant discussion. What is the opinon on implementing thread-safe containers? Java library has them, for example, and, since extending existing containers to be thread safe using locks is a work each client would have to repeat, it looks like a good candidate for standardized library implementation. As for more efficient lock-free impleentations (using CAS) Microsoft has (relatively recently) added singly linked lock-free list to Win32 API. There are examples of lock-free implementations of doubly linked STL list using older Valois algorithm. I would argue that most of multi-threaded programs need thread-safe containers. Tony

6 12

[mpl][vacpp] recurrent problems with name confusions
by Joaquín Mª López Muñoz 07 Sep '04

07 Sep '04

Visual Age 6.0 for AIX complains about the way list iterator is defined "/home/tk/boost_regression/boost/boost/mpl/list/aux_/iterator.hpp", line 30.47: 1540-0416 (S) "next" cannot be declared because its name has already been used. The offending line is typedef l_iter<typename next<Node>::type> next; I guess it'd suffice with rewriting it as: typedef l_iter<typename boost::mpl::next<Node>::type> next; This error (and similar ones in range_c, transform_view, joint_view, pair_view,filter_view) seem to share the same pattern: the compiler complains whenever it finds a structure like this: struct foo { ... name ... typedef ... name; }; a possible workaround (though I cannot test it) is to rewrite this as: struct foo { ... boost::mpl::name ... typedef ... name; }; I don't know if vacpp is meant to be supported by MPL. In case it is, maybe this can be of some help. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

serialization - build shared libs
by Neal Becker 07 Sep '04

07 Sep '04

I'm using current boost cvs. Building with bjam -sTOOLS=gcc stage, builds only archive (.a) versions of serialization libs. I need shared (.so). What needs to be done?

3 3

Problems building --v2 (x86_64)
by Neal Becker 07 Sep '04

07 Sep '04

PYTHON_ROOT=/usr PYTHON_VERSION=2.3 PYTHON_LIB_PATH=/usr/lib64/python2.3 bjam --v2 ...patience... ...found 986 targets... ...updating 113 targets... MkDir1 bin.v2 MkDir1 bin.v2/libs MkDir1 bin.v2/libs/test MkDir1 bin.v2/libs/test/build MkDir1 bin.v2/libs/test/build/gcc MkDir1 bin.v2/libs/test/build/gcc/debug gcc.compile.c++ bin.v2/libs/test/build/gcc/debug/execution_monitor.o gcc.compile.c++ bin.v2/libs/test/build/gcc/debug/cpp_main.o gcc.link.dll bin.v2/libs/test/build/gcc/debug/boost_prg_exec_monitor.so /usr/bin/ld: bin.v2/libs/test/build/gcc/debug/execution_monitor.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC bin.v2/libs/test/build/gcc/debug/execution_monitor.o: could not read symbols: Bad value collect2: ld returned 1 exit status

2 1

Interest in custom numeric formatting?
by Stefan Slapeta 07 Sep '04

07 Sep '04

Hi all, I've recently developed a small lib for custom numeric formatting, which is part of many programming languages. You pass any number and a format string which controls the formatting. Some examples (using the US locale): num_format ( 3332123.3332, "$#,0.00" ) -> "$3,332,123.33" num_format ( 123, "#.00" ) -> "123.00" num_format ( 12, "000" ) -> "012" num_format ( 12.9, "000" ) -> "013" (rounded!) num_format ( -123.1, "#.#;-#.00" ) -> "-123.10" num_format ( -123, "$#;- $0.00;0" ) -> "- $123.00" num_format ( 0, "0.00;-0.00;<Zero>" ) -> "<Zero>" num_format ( 1000000, "#,#,.00" ) -> "1,000.00" Short explanation for the format string: . marks the decimal separator , has two functions: - if the format string contains any "," before, but not immediately before the decimal separator, there will be thousand separators in the output. - if the format string contains any "," immediately before the decimal separator, the number will be divided by the number of "," characters multiplied by 1000. 0 If there is no digit in this position, there will be a 0 in the output string # If there is a digit in this position, it is copied to the output string (except non-significant zeros) ; Section separator: if there is one section in the format string, it applies to all values. If there are two sections, the first applies to positive values and to zeros and the second applies to negative values. If there are three sections, the first applies to positive values, the second to negative values and the third to zeros, except if the second section is empty, in which case the first section applies to all non-negative values. Everything in enclosed by ' or " in the format string will be copied to the output as is. I've been looking for a (C++) solution for this for a long time and as I didn't find anything appropriate, I developed it myself finally. If anybody is interested, I could post source somewhere. Stefan

6 8

iostream problems
by Neal Becker 07 Sep '04

07 Sep '04

cd /home/nbecker/shannon2/wrap/ g++34 -o Test Test.cc -g -I /usr/local/src/iostream/ In file included from /usr/local/src/iostream/boost/io/detail/streambufs/direct_streambuf.hpp:18, from /usr/local/src/iostream/boost/io/streambuf_facade.hpp:15, from /usr/local/src/iostream/boost/io/stream_facade.hpp:20, from Test.cc:1: /usr/local/src/iostream/boost/io/detail/streambufs/linked_streambuf.hpp:54: error: variable or field `close' declared void /usr/local/src/iostream/boost/io/detail/streambufs/linked_streambuf.hpp:54: error: `close' declared as a `virtual' field /usr/local/src/iostream/boost/io/detail/streambufs/linked_streambuf.hpp:54: error: expected `;' before '(' token In file included from /usr/local/src/iostream/boost/io/detail/adapters/filter_wrapper.hpp:16, from /usr/local/src/iostream/boost/io/detail/streambufs/indirect_streambuf.hpp:23, from /usr/local/src/iostream/boost/io/streambuf_facade.hpp:16, from /usr/local/src/iostream/boost/io/stream_facade.hpp:20, from Test.cc:1: /usr/local/src/iostream/boost/io/operations.hpp: In static member function `static void boost::io::detail::read_impl<boost::io::input>::putback(T&, typename boost::io::char_type<T>::type)': /usr/local/src/iostream/boost/io/operations.hpp:106: error: invalid application of `sizeof' to an incomplete type In file included from /usr/local/src/iostream/boost/io/detail/push.hpp:16, from /usr/local/src/iostream/boost/io/detail/streambufs/indirect_streambuf.hpp:28, from /usr/local/src/iostream/boost/io/streambuf_facade.hpp:16, from /usr/local/src/iostream/boost/io/stream_facade.hpp:20, from Test.cc:1: /usr/local/src/iostream/boost/io/detail/resolve.hpp: At global scope: /usr/local/src/iostream/boost/io/detail/resolve.hpp:38: error: non-template `result_type' used as template /usr/local/src/iostream/boost/io/detail/resolve.hpp:38: error: (use `U::template result_type' to indicate that it is a template) /usr/local/src/iostream/boost/io/detail/resolve.hpp:38: error: expected `{' before ';' token Adding #include <iostream> fixes this problem.

2 3

Preliminary:building with VC++ 8.0 Express beta
by Tony Juricic 06 Sep '04

06 Sep '04

I downloaded and installed MS VC++ 8.0 Express beta. The advantage of Express over full Visual Studio 2005 is in a smaller disk footprint and you need 'only' MS Passport (not MSDN subscription) to download it. Note that Express does not come with Windows headers and libraries so you need to download Platform SDK or use existing, older installation. For example, before invoking bjam, you may say: set INCLUDE="C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include";%INCLUDE% set LIB="C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\lib";%LIB% Here are the problems encountered when building boost: 1) flags for DLL and single-threaded static library have changed. You would need the following flags in msvc-tools.jam: # VC8.0 flags msvc CFLAGS <runtime-build>release/<runtime-link>dynamic : /LD ; flags msvc CFLAGS <runtime-build>debug/<runtime-link>dynamic : /LDd ; flags msvc CFLAGS <runtime-build>release/<runtime-link>static/<threading>single : /MD ; flags msvc CFLAGS <runtime-build>debug/<runtime-link>static/<threading>single : /MDd 2) Og and Gs compiler flags will be deprecated and cause warning. 3) many string functions ( sprintf, strcat, wsccpy, etc. ) cause deprecated warning. 4) compilation errors, all involving wchar_t like: C:\Program Files\Microsoft Visual Studio 8\VC\include\xutility(207) : error C2664: 'bool boost::spirit::utility::impl::range_char_compare<CharT>::operator ()(const boost::spirit::utility::impl::range<CharT> &,const CharT) const' : cannot convert parameter 1 from 'wchar_t' to 'const boost::spirit::utility::impl::range<CharT> &' with [ CharT=wchar_t ] Reason: cannot convert from 'wchar_t' to 'const boost::spirit::utility::impl::range<CharT>' with [ CharT=wchar_t ] No constructor could take the source type, or constructor overload resolution was ambiguous Problem #1 can be solved by commenting out older flags and substituting them with the new ones in msvc-tools.jam. I am sure this is not the most elegant solution, ignorant of bjam as I am. Re. problem #2, I could not find an explicit suggestion on what new options should be used. However, the sheer number of problems with /Og option listed in MS Knowledge Base make me believe that it would be best to remove it. Whidbey (but not Express) is to offer more advanced profile-based optimizations. As for /Gs I would assume that /GS (also /RTC1) should substitute it, following the article: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstecha… As for #3, even barring security concerns, I tend to agree that using string functions with source and destination buffer size parameters is desirable. However, I wouldn't know which portable changes would avoid these warnings; presumably MS-specific extensions would be required. Still unfamilar with boost++ modules that caused errors under #4, I haven't looked into it. While more detailed info about these issues may be possible to find on MSDN, searching for any phrase, unfortunately, results in a huge number of .NET related articles. Tony

1 1

shared_ptrget_deleter
by David Pierre 06 Sep '04

06 Sep '04

I have got a shared_ptr use case where I use the Deleter to hold some extra data which I access through get_deleter. But now I would like to have custom deletion too, by subclassing from the common part. Then to access my data, I need get_deleter to work with superclass(es) of the actual deleter, not only with the exact type. Here is a simple suggestion to make it possible : in boost/detail/shared_count.cpp, introduce : template <class D> struct deleter_caster { void * operator()(std::type_info const & ti, D * del) const { return ti == typeid(D) : del : 0; } }; and make get_deleter implementation in sp_counted_base_impl as virtual void * get_deleter(std::type_info const & ti) { return deleter_caster<D>(ti, del); } Then I can specialize deleter_caster to my linking. D. Pierre

1 0

howto make test2 not run unless test1 succeeds
by Larry Evans 06 Sep '04

06 Sep '04

The following is my Jamfile.v2: <----------- project dependent_test ; run test1.cpp : #args : #input-files : #requirements : test1_test #target-name : #default-build ; run test1_test test2.cpp : : : : test2_test : ; >----------- What I want is for test2_test to run only if test1_test passes. I know the above rule invocations look suspicious because the target is normally the 1st token after the rule name; however, the run rule (in testing.jam) is: rule run ( sources + : args * : input-files * : requirements * : target-name ? : default-build * ) So, I thought putting test1_test in the 2nd run (for target test2_test ) would cause test1_test to always be run first, and only if that passed, then would test2_test be tried. However, this is not what happened. test2_test was ALWAYS run. What should I do to make test2_test's run only after test1_test successfully ran?

1 1

RE: [boost] Is there any interest in a simple template for streamingin/out primitives and STL Containers of them?
by Reece Dunn 06 Sep '04

06 Sep '04

Boris Kats wrote: >I am using it for some time and hope that other will >benefite from it. >One file streamline.h will help user to stream out/in >an arbitrary item of primitives or STL containers of >them. >It is very simple to use; just type like this: > >#include "streamline.h" >using namespace hekate; >....... >typedef std::pair<std::string, std::vector<int> > >element; >element one,other; >And stream it out as: streamline(cout,one); >or stream it in as: streamline(cin,other); . > >User will find a lot of examples in the streamtest.cpp >file >at streamline.tar in "Files section". >The streaming templates were tested with gcc version >3.3.2, msvc7 and >ibm89 c++ compiler. >Boris Kats. Hi Boris, As Jonathan has pointed out, my library is aimed at solving this type of problem. Your example would become: #include <sstream> #include <boost/outfmt/stl/vector.hpp> #include <boost/outfmt/stl/pair.hpp> int main() { typedef std::pair< std::string, std::vector< int > > element; element one, other; one.first = "Meine \"Grosse\" Welt!"; one.second.push_back( 3 ); one.second.push_back( 6 ); one.second.push_back( 9 ); std::stringstream ss; ss << one; std::cout << "written: " << ss.str() << '\n'; ss >> other; std::cout << "read: " << other << '\n'; return( 0 ); } Providing a much simpler syntax and stream integration. The output for this is: written: ( "Meine \"Grosse\" Welt!", [ 3, 6, 9 ] ) read: ( "Meine \"Grosse\" Welt!", [ 3, 6, 9 ] ) It is possible to control how the pair and vector types are rendered using a custom formatter. Refer to the examples and documentation for more information. Regards, Reece _________________________________________________________________ Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx

2 1

outfmt formal review - postponed
by John Torjo 06 Sep '04

06 Sep '04

Dear boosters, Due to the feedback I've received, I chose to postpone the formal review of Output Formatters library until 12th of Sept. 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)

1 0

New design proposal for boost::filesystem
by Martin 06 Sep '04

06 Sep '04

Just a thought on the filesystem implementation. Why not separate the path from the filesystem? Let the path be a container for all kind of paths that follow the generic syntax explained in the boost::filesystem documentation. Then use implementation classes that handles root name and conversion to native strings etc. The benefits would be: 1. The path can be used for other things than filesystems (XPath, Win32 registry) 2. Operations can be implemented selectivly for different types (No need for the current messy #ifdefs) bool exists( const path_base<posixfs<std::string> >& aPath); bool exists( const path_base<win32fs<std::wstring> >& aPath); bool exists( const path_base<win32reg<boost::fixed_string<100> > >& aPath); 3. Easy to expand the functionality for specific tasks without touching the boost headers. The implementation could look something like: template <class ImplT> class path_base : private ImplT { public: typedef ImplT::string_type string_type; path_base() : ImplT() {} // all path operations as in current implementation ... private: string_type m_path; }; // // implementation for win32 filesystem // template <class StringT> class win32fs { // root-name ::= root-drive | root-share | root-device // root-drive ::= char ":" // root-share ::= "//" name // root-device ::= name ":" protected: typedef StringT string_type; win32fs() { } string_type make_generic(const string_type::value_type* src); string_type native_file_string(const string_type& m_path) const { return algorithm::replace_all_copy(m_root + m_path, "/", "\\"); } ... private: string_type m_root }; // // implementation of posix filesystem // template <class StringT> class posixfs { win32fs() { } string_type make_generic(const string_type::value_type* src); string_type native_file_string(const string_type& m_path) const { return m_path; } ... } #ifdef BOOST_POSIX typedef path_base<posixfs<std::string>> path; #else ...

5 8

[serialization] request: low-level info about order of serialization
by Joaquín Mª López Muñoz 06 Sep '04

06 Sep '04

I'm slowly designing the addition of serialization support to Boost.MultiIndex, and come up with a need that, AFAIK, the current serialization library does not cover: The serialization of a multi_index_container should ensure that the order in which elements appear is preserved for all indices of the container. This implies serializing the elements and then recording the appropriate rearrangements in each index. I'm writing the code for serializing these rearrangements in an efficient manner as some sort of "diff" sequences, using an algorithm called "longest increasing subsequence" (LIS). The algorithm would greatly benefit for some low-level API by the serialization lib that, given an object reference, would return the order in which that object was serialized. I guess this information is already available internally, as the lib must keep track of previously saved objects. If this requirement is deemed too exotic to provide to the general user, well, I can write something myself without aid from the lib, but I thought I should ask at least :) Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[request] Sun and IBM users...
by Paul Mensonides 06 Sep '04

06 Sep '04

Can someone test the following preprocessor code on the Sun and IBM preprocessors: #include <boost/preprocessor/detail/split.hpp> #include <boost/preprocessor/punctuation/comma.hpp> #include <boost/preprocessor/punctuation/paren.hpp> #include <boost/preprocessor/tuple/eat.hpp> #define IS_NULLARY(x) \ BOOST_PP_SPLIT(1, IS_NULLARY_C x BOOST_PP_COMMA() 0) \ /**/ #define IS_NULLARY_C() \ ~, 1 BOOST_PP_RPAREN() \ BOOST_PP_TUPLE_EAT(2) BOOST_PP_LPAREN() ~ \ /**/ IS_NULLARY(()) // 1 IS_NULLARY(()abc) // 1 IS_NULLARY(+) // 0 IS_NULLARY(xyz) // 0 #define IS_UNARY(x) IS_NULLARY(IS_UNARY_C x) #define IS_UNARY_C(a) () IS_UNARY((a)) // 1 IS_UNARY((a)abc) // 1 IS_UNARY(+) // 0 IS_UNARY(xyz) // 0 Regards and thanks, Paul Mensonides

3 12

algorithm/string bug
by Llew Sion Goodstadt 06 Sep '04

06 Sep '04

There seems to be a bug somewhere in #include <boost/algorithm/string.hpp> If I am not mistaken, this is the central include file for all the string algorithms. But if, e.g. in replace_example.hpp, you replace the separate declarations of #include <boost/algorithm/string/replace.hpp> #include <boost/algorithm/string/erase.hpp> #include <boost/algorithm/string/case_conv.hpp> with //#include <boost/algorithm/string/replace.hpp> //#include <boost/algorithm/string/erase.hpp> //#include <boost/algorithm/string/case_conv.hpp> #include <boost/algorithm/string.hpp> the file no longer compiles. However, #include <boost/algorithm/string/replace.hpp> //#include <boost/algorithm/string/erase.hpp> //#include <boost/algorithm/string/case_conv.hpp> #include <boost/algorithm/string.hpp> does work. Is there an error in the order of header inclusion? Leo Goodstadt

2 1

Program options possible error?
by Llew Sion Goodstadt 06 Sep '04

06 Sep '04

In <boost/program_options/detail/config_file.hpp> why is BOOST_WORKAROUND used (line 19) before the inclusion of #include <boost/detail/workaround.hpp>? Thanks Leo

2 1

RE: [boost] Re: IOStreams formal review start
by Reece Dunn 06 Sep '04

06 Sep '04

Jonathan Turkanis wrote: >I'm starting to think it would be very useful to have a Flushable concept, >which >would allow components to advertise that they can send all buffered data >downstream at any time. I haven't given it much though yet, but I think it >would >allow OuputFilters to be inserted and removed in the middle of processing a >character sequence, as Dietmar suggested. This would make it possible to write a processor for a PDF file that contains several 'stream' objects, each with different filters (LZW compression, ASCII85 encoding, JPEG images, etc.). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

tru64cxx65 regression tests temporarily disabled
by Markus Schöpflin 06 Sep '04

06 Sep '04

The regular regression tests for Compaq C++ 6.5 on Tru64 V5.1 have been temporarily disabled. They will be reactivated as soon as possible. Markus

1 0

RE: [boost] Re: New design proposal for boost::filesystem
by Reece Dunn 06 Sep '04

06 Sep '04

Vladimir Prus wrote: >Martin wrote: > > > Vladimir Prus <ghost <at> cs.msu.su> writes: > > The current path implementation doesn't > > allow you to handle more than one type (i.e. winfs or posixfs). You >can't > > store a registrypath in a fs::path since it can't handle a hkey.. root. > >Why? Can't I put literal "HKEY_CURRENT_USER" in boost::path? I don't think he's questioning that, but the case where you can use a HKEY handle as the root, for example: // note: not sure on exact calls HKEY hkCU, hkBase; ::OpenKey( null, "HKEY_CURRENT_USER", &hkCU ); ::OpenKey( hkCU, "software\\microsoft\\windows", &hkBase ); boost::fs::path regwin( hkBase ); // oops: error boost::fs::path spyware = regwin / "CurrentVersion" / "Run" / spyware_app; if( exists( spyware )) // does the registry key exist { // display the value std::cout << "removing: " << boost::fs::get_regval( spyware ) << '\n'; boost::fs::delete( spyware ); // delete the registry entry } Also, iterating through registry entries requires different API calls to that of iterating through files. > >> Actually, I think it is very desired to have boost::path usable in more > >> contexts than the filesystem. For example > >> > >> fs::path base("http://my_site.org"); > >> ..... get_file(base / "foo" / "bar") ..... > >> > >> would be great. But I'm just don't sure this requires all that drastic > >> changes. > > > > Why do you think it is a drastic change? > > Changing operations will not take much time since it is only to move the > > things inside "#ifdef BOOST_POSIX" and "#ifdef BOOST_WINDOWS" into > > separate overloads. > >And #ifdef the overloads ;-) I don't think Win32 API calls can be compiled >on Linux. > >I really think that win32/posix distinction should say as it is. For other >types of path, I'm not sure. I *think* that boost::fs::path can accomodate >all of them. Of course, if you stick URL into boost::fs::path, the name >'native_file_path' becomes questionable ;-) Why not have a class like std::char_traits (e.g. boost::fs::path_traits) that abstracts the API used by path. That way, you can have: template< typename CharT > struct posix_path_api { typedef ... file_handle; typedef ... directory_iterator_handle; static bool exists( file_handle ); static void delete( file_handle ); static directory_iterator_handle get_next( directory_iterator_handle ); }; This would then simplify the Win32/posix API problems and allow for internet_api, winregistry_api, etc. to be included, e.g. boost::fs::path< char, internet_api< char > > boostweb( "http://www.boost-consulting.com/boost" ); Regards, Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

1 0

warning in boost::program_options
by Rodolfo Schulz de Lima 06 Sep '04

06 Sep '04

Hi, I'm using boost::program_options for the first time and noticed that when compiling a program that uses it using gcc's -Wall, it spits out a warning about an unused function parameter: /usr/include/boost-1_32/boost/program_options/value_semantic.hpp:137: warning: unused parameter 'value_store' Can this be corrected? It's just annoying when using -Werror. Since I've seen warnings in other libraries as well, I wonder why those ones aren't being caught in boost's test summary (on the home page). Just adding -Wall to the compiler option would suffice. Regards, rod

2 1

another warning in boost::program_options
by Rodolfo Schulz de Lima 06 Sep '04

06 Sep '04

Oops... another warning: /usr/include/boost-1_32/boost/program_options/detail/value_semantic.hpp:78: warning: unused parameter 'target_type' There might be others...

1 0

Is there any interest in a simple template for streaming in/out primitives and STL Containers of them?
by Boris Kats 05 Sep '04

05 Sep '04

I am using it for some time and hope that other will benefite from it. One file streamline.h will help user to stream out/in an arbitrary item of primitives or STL containers of them. It is very simple to use; just type like this: #include "streamline.h" using namespace hekate; ....... typedef std::pair<std::string, std::vector<int> > element; element one,other; And stream it out as: streamline(cout,one); or stream it in as: streamline(cin,other); . User will find a lot of examples in the streamtest.cpp file at streamline.tar in "Files section". The streaming templates were tested with gcc version 3.3.2, msvc7 and ibm89 c++ compiler. Boris Kats. boriskats(a)yahoo.com __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

2 1

Geometric Algebra Library (again)
by Tony Juricic 05 Sep '04

05 Sep '04

I couldn't reply to the original post but I found Boost++ disussion on this topic between Ken Hagan, Jaap Suter and Hubert Holin on Google. Since quaternions and octonions are already part of the library I would second the opinion that more generic Geometric Algebra library would be one useful addition. Tony

2 2

[boost.range] renaming empty() to is_empty()
by Thorsten Ottosen 05 Sep '04

05 Sep '04

Dear all, John Torjo asks why don't rename the Range concepts empty() function to the more idiomatic and less embarrassing name is_empty()? My initial thoughts were if this could ceate more confusion, but I'm beginning to think John is right. So if people would cast some yes or no votes it would be great. br Thorsten

7 6

[1.32 Release] MPL has been merged into the main trunk
by Aleksey Gurtovoy 05 Sep '04

05 Sep '04

Everything has been tested locally, so the disturbance should be minimal. I'll post a detailed changelog later today. Metacomm regressions have been restored to run against the main trunk. -- Aleksey Gurtovoy MetaCommunications Engineering

6 12

CodeWarrior and alignment_of (help!)
by Doug Gregor 05 Sep '04

05 Sep '04

Some of the Graph tests are failing on CodeWarrior due to some strange interaction within alignment_of, where it doesn't like mpl::size_t. I don't have the compiler to test on :( Here's one example of the failures: http://tinyurl.com/4dapg Doug

2 1

[1.32 Release] Summary of MPL changes
by Aleksey Gurtovoy 05 Sep '04

05 Sep '04

The HMTL version of the changelog is available at http://www.mywikinet.com/mpl/mpl_1_32_changelog.html MPL changelog for 1.32 release ****************************** The following summarizes major changes in the library interface and implementation from the previous release, with the accent on backward compatibility. Note that this is *not* a comprehensive list of all changes (yet). Apply/lambda semantics ---------------------- 1. Nullary metafunction classes are no longer special-cased, and are *not* identical to nullary metafunctions: +-------------------------+---------------+---------------------------+ | Nullary... | Before | Now | +=========================+===============+===========================+ | metafunction | ``f::type`` | ``f::type`` | +-------------------------+---------------+---------------------------+ | metafunction class | ``c::type`` | ``c::apply<>::type`` or | | | | ``c::apply::type`` [1]_ | +-------------------------+---------------+---------------------------+ This fixes a flaw in the metafunction/metafunction class algebra that long has been the major source of other inconsistencies throughout the library. 2. ``apply`` now automatically invokes ``lambda`` on its first argument, e.g. the following is well-formed now:: typedef apply< plus<_1,_1>, int_<2> >::type four; ``apply_wrap``\ *n* auxiliary metafunctions are available for rare cases when it's crutial to eliminate small overhead associated with lambda expressions while still avoiding various compiler bugs known to lurk in the obvious ``f::template apply<...>::type``. 3. Lambda implementation for broken compilers has been reworked to match as close as possible the semantics of the full-fledged version; consequently, there might be some incorrect code out there that will stop working with the new implementation. To get the detailed picture of the new apply/lambda semantics, please see the corresponding test case at http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/mpl/test/apply.cpp?v…. .. [1] The second form is available only on fully conforming compilers. Iterator protocol ----------------- The library no loger guarantees nor relies on the direct presence of ``advance`` / ``distance`` / ``next`` / ``prior`` / ``type`` members in iterator types; the following table summarises the new requirements: +-------------------------------+-------------------------------+ | Before | Now | +===============================+===============================+ | ``i::type`` | ``deref<i>::type`` | +-------------------------------+-------------------------------+ | ``i::next`` | ``next<i>::type`` | +-------------------------------+-------------------------------+ | ``i::prior`` | ``prior<i>::type`` | +-------------------------------+-------------------------------+ | ``i::advance<n>::type`` | ``advance<i,n>::type`` | +-------------------------------+-------------------------------+ | ``i::distance<j>::type`` | ``distance<i,j>::type`` | +-------------------------------+-------------------------------+ | ``i::category`` | ``i::category`` | +-------------------------------+-------------------------------+ Sequence traits protocol ------------------------ Sequence algorithms' traits protocol has been changed to that of metafunction classes: +------------------------------------------------+------------------------------------------+ | Before | Now | +================================================+==========================================+ | *name*\ ``_traits<Tag>::algorithm<...>::type`` | *name*\ ``_impl<Tag>::apply<...>::type`` | +------------------------------------------------+------------------------------------------+ Correspondingly, if your code implemented a custom sequence, it needs to be adjusted according to the above table; for example: +-----------------------------------------------+-------------------------------------------+ | Before | Now | +===============================================+===========================================+ |:: |:: | | | | | template<> struct begin_traits<my_tag> | template<> struct begin_impl<my_tag> | | { | { | | template< typename S > struct algorithm | template< typename S > struct apply | | { | { | | typedef ... type; | typedef ... type; | | }; | }; | | }; | }; | | | | +-----------------------------------------------+-------------------------------------------+ Numeric metafunctions protocol/infrastructure --------------------------------------------- The arithmetic, comparison and bitwise metafunctions are `polymorphic`, and can operate on a variety of numeric types, including rational, fixed-point and complex numbers. The metafunctions allow `mixed arithmetic`, meaning that you can perform an operation on the arguments of different types, and the result will yeild the largest/most general of the arguments types. The infrastructure is provided to allow easy plugging of user-defined numeric types which can be made freely intermixable with predefined library types. See http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/mpl/test/numeric_ops… for an illustrative example. If you were using MPL numeric metafunctions on your own integral wrapper class similar to ``mpl::int_``, you can plug it into the new infrustructure by extending the class with the following member:: typedef mpl::integral_c_tag tag; For example: +---------------------------------------+-------------------------------------------+ | Before | Now | +=======================================+===========================================+ |:: |:: | | | | | template< int n > struct my_int | template< int n > struct my_int | | { | { | | static int const value = n; | typedef mpl::integral_c_tag tag; | | typedef my_iny type; | static int const value = n; | | }; | typedef my_iny type; | | | }; | | | | +---------------------------------------+-------------------------------------------+ Renaming/cleanup ---------------- 1. ``apply_if`` metafunction has been renamed to ``eval_if``. 2. All ``_backward`` algorithm counterparts have been renamed to use ``reverse_`` prefix; e.g. ``fold_backward`` became ``reverse_fold``. 3. ``<boost/mpl/aux_/has_xxx.hpp>`` header has been made public and became ``<boost/mpl/has_xxx.hpp>``; correspondingly, the ``BOOST_MPL_NO_AUX_HAS_XXX`` macro was renamed to ``BOOST_MPL_CFG_NO_HAS_XXX``. 4. ``<boost/mpl/assert_is_same.hpp>`` header has been replaced by a more general ``<mpl/assert.hpp>``; the new asserts provide a significantly higher-quality diagnostics. See the table below for the new equivalents of the old macros: +-------------------------------------------+-----------------------------------------------------+ | Before | Now | +===========================================+=====================================================+ | ``BOOST_MPL_ASSERT_IS_SAME(t1, t2)`` | ``BOOST_MPL_ASSERT(( boost::is_same<t1,t2> ))`` | +-------------------------------------------+-----------------------------------------------------+ | ``BOOST_MPL_ASSERT_IS_NOT_SAME(t1, t2)`` | ``BOOST_MPL_ASSERT_NOT(( boost::is_same<t1,t2> ))`` | +-------------------------------------------+-----------------------------------------------------+ 5. All configuration macros has been renamed to include ``CFG`` prefix; in particular, ``BOOST_MPL_NO_FULL_LAMBDA_SUPPORT`` has become ``BOOST_MPL_CFG_NO_FULL_LAMBDA_SUPPORT``. 6. The following other public headers/components has been renamed or removed as obsolete:: iterator_tag.hpp (renamed to iterator_tags.hpp) project1st.hpp project2nd.hpp select1st.hpp select2nd.hpp Miscellaneous ------------- 1. ``vector`` has been re-implemented to support constant-time insertion at both the beginning and the end. For example, this is now well-formed:: typedef push_back<v,int>::type v1; typedef push_front<v1,int>::type v2; 2. The interface of some sequence building algorithms such as ``copy`` has been changed. Please see the corresponding headers for the details (updated docs are upcoming!). -- Aleksey Gurtovoy MetaCommunications Engineering

4 9

[mpl] problems with borland 5.6.4
by Hugo Duncan 05 Sep '04

05 Sep '04

Aleksey, The following does not compile, on bcc 564 with latest pserver CVS. The Variant definition is similar to the one Borland provides in their VCL headers (and the problem therefore exists with any code that uses the VCL). The error message is E2015 Ambiguity between 'operator !=(int,const Variant &)' and '!=' Removing the mpl include gets rid of the compile error. Any ideas? Regards, Hugo # include <boost/mpl/placeholders.hpp> struct Variant { Variant(int); }; bool operator!=(int, const Variant&); namespace // problem occurs both with and without unnamed namespace { enum Abc { abcd, abcde }; } int fn() { int x=0,y=1; if (x!=y) // OK return 1; Abc a; if (a!=abcd) // ERROR HERE return 1; return 0; }

2 1

repost: [mpl][multi_index][intel-8.0-linux] regression
by JOAQUIN LOPEZ MU?Z 05 Sep '04

05 Sep '04

I posted this a couple of days ago and got no response. Please help. Thank you. Newly merged MPL seems to be having problems in Intel 7.x/8.0 under Linux with BOOST_MPL_AUX_ADL_BARRIER_NAMESPACE_OPEN, as shown in http://tinyurl.com/5rj4d Appart from this, the merge is mostly working fine, as far as multi_index is concerned. There's another MPL-related problem, but it's due to a previously masked bug of mine. Congrats and thanks for the staggering effort. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

mpl::map not working?
by Max Khesin 05 Sep '04

05 Sep '04

I wanted to play with mpl::map, but I noticed that it is having problems on vc7.1 (http://tinyurl.com/3kr99) and many other compilers - is there a known fix? 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.

3 2

[v2]command line argument feature treated as target
by Larry Evans 04 Sep '04

04 Sep '04

Based on the following example: borland/<runtime-link>static located at: http://boost.org/boost-build2/doc/html/bbv2.reference.commandline.html I tried the following: bjam --v2 gcc/\<link-runtime\>static error: Unable to find file or target named error: 'gcc/<link-runtime>static' error: referred from project at error: '.' I also tried <runtime-link> without success. I guessed <link-runtime> from looking at: tools/build/v2/tools/gcc.jam which contains: flags gcc.link OPTIONS <link-runtime>static : -static ; What am I doing wrong? TIA. Regards, Larry

1 1

Re: [boost.thread] Experimental alternative TLS implementation
by Tony Juricic 04 Sep '04

04 Sep '04

I just downloaded Roland's implementation and I quite like it. By the way, congrats Roland on resolving TLS callback issues for static link library for VC6 and VC7; after digging into it as I joined the group I was too busy but now I hope to have more time and, at least, help with more testing. While intentional TLS slot leak is not a big issue (one expects that OS will do proper cleanup on program exit) it may be confusing to the first-time reader who may have a hard time understanding the motivation for protecting programmers from some leaks, while leaving other leaks to the OS. Reference counting makes it quite clear to the reader what is intended by the code. I wonder what are current plans for the future of threads libray, after a lot of discussion about rewrite? My own perspecitive is colored by everyday practical use: for example, I never encountered any need for thread-specific pointer but I often had to pass a boolean to thread proc to make a thread stop. Consequently, and as I would like to use boost threads instead of my own concotion, I would like to see "thread stopping pattern", lacking better term and just for example, as the part of the interface. I understand these are difficult issues but after quite a few years of using threads I am not sure that I still find 'older' Java-like thread(s) interface particularly useful. Tony

2 2

[bbv1] MkDir rule broken on Win32!?
by Bertolt Mildner 04 Sep '04

04 Sep '04

When started form a Windows Commandline (cmd.exe) bjam tries to create existing directories and of curse failes to do so! For example when building boost::thread: ------------------------------------ ...found 205 targets... ...updating 20 targets... MkDir1 ..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threading-multi Ein Unterverzeichnis oder eine Datei mit dem Namen "..\..\..\bin\boost\libs\thre ad\build\boost_thread.dll\cw\\threading-multi" existiert bereits. mkdir "..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threading- multi" ...failed MkDir1 ..\..\..\bin\boost\libs\thread\build\boost_thread.dll\cw\\threa ding-multi... ------------------------------------ (the german error-msg means "directory or file "..." allready exists") As this causes targets to be skipped this is getting pretty annoying ... As far as i understand the root of the problem is that the nativ "mkdir" on Win32 does not take any options to be quiet if the directory exists ("-p" on Unix). It looks like allyourbase.jam tries to address this in the MkDir rule, but fails to. Bertolt PS: I have tried to post this in gmane.comp.lib.boost.build but i always got mail that i should join <jamboost(a)yahoogroups.com>!

2 3

[utility] value_init fails on CW*
by Stefan Slapeta 04 Sep '04

04 Sep '04

see http://tinyurl.com/5639d Has anybody a solution for this? Seems that all CWs have problems with casts in combination with conversion functions. Stefan

4 4

Boost serialization: release configuration linker errors
by Robert Ramey 04 Sep '04

04 Sep '04

I assume you're using the version currently in the main CVS tree. Or are you using the version 1.31? I've always had this problem. It manifests itself differently with different compiliers. In often related to linkers removing "dead code" that really isn't dead - the linker isn't smart enough to see that in fact the code is used. One of the ways I've found to address this is to mark certain templates for export (dllexport). Unfortunately, the way of doing this varies from compiler to compiler. So, I occasionally re-run all tests in release mode to detect these problems. Usually this is enough. Recently, I've fixed up export to work regardless of idiosyncrasies of various compilers and I may have broken something. I'll retest and recheck this. Robert Ramey >Ive been using Boosts serialization library with MSVC 7.1 (the first time >that Ive used it). For most of my project I put the load / save function >declaration in the class header (the .h file) and the definitions in the >.cpp file VC 7.1 allows this for templated functions, unlike some older >compilers. In debug mode this compiled and linked fine except for abstract >base classes through trial and error I found that for abstract classes >the functions had to be defined in the .h file to avoid linker errors. >My project built fine in Debug mode and I then tried to compile / link it >in Release mode this threw up quite a few LNK2001 errors relating to just >a few of the serialization load / save functions in just some of the >classes most of the classes that declared the load / save functions >evidently linked fine (as they all did in Debug mode). After much double >checking of the compile / link project configurations I tried the >following: >1. I removed the BOOST_CLASS_EXPORT(etc) declaration at the bottom of the >.h files in which the load / save functions were not linking. On >recompiling / linking most of the linker errors were gone, but a few >remained. >2. For the remaining classes that were not still not linking, I moved the >load / save functions from the .cpp file into the .h file (these were not >abstract classes). This fixed the remaining linker errors and my >application compiled / linked / ran fine. >I can't see why this occurred. I havent checked yet (its very time >consuming to rebuild this application) but possibly option (2) would have >worked for all the affected classes. For most of this project, the load / >save functions remain defined in the .cpp file and clearly link fine in >both debug and release configurations. Before someone asks, I did complete >clean / rebuilds for both configurations anybody any ideas?

1 0

Porting to SCO Unix
by Davlet Panech 04 Sep '04

04 Sep '04

Good day, I'm trying to port Boost to SCO Unix using STLport and GNU Pth (a user-space Pthreads library), and gcc 2.95 controlled by a customized compiler driver (so some of the following observations may not be applicable to stock gcc users on this platform). Anyway, I've had a few problems that I'd like to report; I think at least some of them are worth correcting in future Boost releases: The following tests in libs/config/configure produce incorrect results: ** checking for pthread_exit in -lpthread... no This test tries to compile a C source file that prototypes "pthread_exit" as "char pthread_exit();". But my compiler driver always adds "-include <...>/pthread.h" to the command line, which includes a different, conflicting prototype for this function. I think the test ought to include <pthread.h> instead. ** checking pthread_yield... no This is correct, but I do have a pthread_yield_np() function, maybe we should look for it, too. ** checking std::basic_streambuf<wchar_t> ... OK I think this should fail if _STLP_NO_WCHAR_T is defined, which it is in my STLport configuration headers. This macro does not prevent one from instantiating basic_string<>, etc. with wchar_t, but it does disable explicit instantiations of these in STLport binaries. So basic_string<char> ends up being compiled into libstlport.so, while basic_string<wchar_t> doesn't. The macro also disables the typedefs (wstring, wcout, etc) and the wide char - related C headers (<cwchar>, <cwctype>). I really think Boost should disable all wide char stuff in this case. I also discovered some problems with Jamfiles (BTW what is Jamfile.v2? Is it useable? How does one use it?): tools/build/v1/allyourbase.jam, near line 574): rule CcMv is called but never defined. What does variable "RELOCATE" do in allyourbase.jam? It seems to indicate that the compiler doesn't support the -o switch, shouldn't this be defined in compiler-specific toolset files? Why is there no static version of Boost.Threads? I know this is required in Windows, but not if it's compiled on top of Pthreads on any platform (I'm using pthreads-win32 from Redhat, on Windows), right? The documentation (http://www.boost.org/more/getting_started.html#Build_Install) states that "[...] For toolsets that support it in Unix they will also have a full version extension (for example ".so.1.31.0")". But this does not seem to be the case. I ended up with "libboost_thread-gcc-mt-1_31.so" etc. using gcc toolset on SCO. Where are the ".so.1.31.0" versions? Maybe I'm missing some toolset settings. Also it seems that some of the .so files generated ought to be symbolic links, but are instead copies of one another. Where is this controlled? Do I need to edit/create some toolset file to replace "cp" with "ln -s"? If I pass -DNDEBUG to my source files that #include Boost headers, do I have to link with non-debug version of boost libs? How about multithreaded vs single-threaded configurations? For example, is it safe to link with MT Boost libs with non-MT programs using gcc/Linux? I know it makes a difference in Windows, but it should not matter on platforms where compiler runtimes don't differentiate between MT/non-MT, IMHO. That is, unless the Boost headers provide different declarations depending on the presence of some "MT" macro. This would be very unfortunate, because it's very easy to link with the wrong library and the compiler won't complain about it. It would be nice to have an option of not using the long "mangled" library names while installing. As a user I would expect a more customary convention for library names on UNIX-like systems, with only two variants, something like the following: libboost_foo.a libboost_foo.so.1.31.0 libboost_foo.so (symbolic link to libbost_foo.so.1.31.0) (... possibly more links depending on binary compatibility guarantees between the releases) both compiled with MT/non-debug configurations. Comments/suggestions? Thanks, D.

5 7

Another patch for long long in gcc -std=c++98
by Aaron W. LaFramboise 04 Sep '04

04 Sep '04

This is a followup from prior threads: TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC in type_traits/is_convertable.hpp: http://thread.gmane.org/gmane.comp.lib.boost.devel/106708 long long support with GCC: http://thread.gmane.org/gmane.comp.lib.boost.user/6693 The following patch is another attempt to get long long support working, in a manner acceptable with Boost, even when -std=c++98 and -pedantic are specified. In particular, GCC supports long long in all modes, but __extension__ is required to quiet errors and warnings. It is possible that other C++ compilers with a similar situation regarding long long might be able to use this patch constructively. In short, typedefs are added for long long and unsigned long long in cstdint.hpp, and all uses of these typenames in the headers are changed to use these new names. Aaron W. LaFramboise Index: boost/boost/cast.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/cast.hpp,v retrieving revision 1.22 diff -c -p -r1.22 cast.hpp *** boost/boost/cast.hpp 11 Aug 2004 10:59:33 -0000 1.22 --- boost/boost/cast.hpp 15 Aug 2004 08:25:07 -0000 *************** *** 45,50 **** --- 45,51 ---- # include <boost/config.hpp> # include <cassert> # include <typeinfo> + # include <boost/cstdint.hpp> # include <boost/type.hpp> # include <boost/limits.hpp> # include <boost/detail/select_type.hpp> *************** namespace boost *** 156,166 **** // long / unsigned long long. Not intended to be full // numeric_limits replacements, but good enough for numeric_cast<> template <> ! struct fixed_numeric_limits_base<long long, false> { BOOST_STATIC_CONSTANT(bool, is_specialized = true); BOOST_STATIC_CONSTANT(bool, is_signed = true); ! static long long max BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef LONGLONG_MAX return LONGLONG_MAX; --- 157,167 ---- // long / unsigned long long. Not intended to be full // numeric_limits replacements, but good enough for numeric_cast<> template <> ! struct fixed_numeric_limits_base<longlong, false> { BOOST_STATIC_CONSTANT(bool, is_specialized = true); BOOST_STATIC_CONSTANT(bool, is_signed = true); ! static longlong max BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef LONGLONG_MAX return LONGLONG_MAX; *************** namespace boost *** 169,175 **** # endif } ! static long long min BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef LONGLONG_MIN return LONGLONG_MIN; --- 170,176 ---- # endif } ! static longlong min BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef LONGLONG_MIN return LONGLONG_MIN; *************** namespace boost *** 180,190 **** }; template <> ! struct fixed_numeric_limits_base<unsigned long long, false> { BOOST_STATIC_CONSTANT(bool, is_specialized = true); BOOST_STATIC_CONSTANT(bool, is_signed = false); ! static unsigned long long max BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef ULONGLONG_MAX return ULONGLONG_MAX; --- 181,191 ---- }; template <> ! struct fixed_numeric_limits_base<ulonglong, false> { BOOST_STATIC_CONSTANT(bool, is_specialized = true); BOOST_STATIC_CONSTANT(bool, is_signed = false); ! static ulonglong max BOOST_PREVENT_MACRO_SUBSTITUTION () { # ifdef ULONGLONG_MAX return ULONGLONG_MAX; *************** namespace boost *** 193,199 **** # endif } ! static unsigned long long min BOOST_PREVENT_MACRO_SUBSTITUTION () { return 0; } }; # endif } // namespace detail --- 194,200 ---- # endif } ! static ulonglong min BOOST_PREVENT_MACRO_SUBSTITUTION () { return 0; } }; # endif } // namespace detail Index: boost/boost/concept_check.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/concept_check.hpp,v retrieving revision 1.28 diff -c -p -r1.28 concept_check.hpp *** boost/boost/concept_check.hpp 26 Jul 2004 00:31:58 -0000 1.28 --- boost/boost/concept_check.hpp 15 Aug 2004 08:25:10 -0000 *************** *** 16,21 **** --- 16,22 ---- #define BOOST_CONCEPT_CHECKS_HPP #include <boost/config.hpp> + #include <boost/cstdint.hpp> #include <boost/iterator.hpp> #include <boost/type_traits/conversion_traits.hpp> #include <utility> *************** struct require_same { typedef T type; }; *** 179,185 **** template <> struct SignedIntegerConcept<int> { void constraints() {} }; template <> struct SignedIntegerConcept<long> { void constraints() {} }; # if defined(BOOST_HAS_LONG_LONG) ! template <> struct SignedIntegerConcept<long long> { void constraints() {} }; # endif // etc. #endif --- 180,186 ---- template <> struct SignedIntegerConcept<int> { void constraints() {} }; template <> struct SignedIntegerConcept<long> { void constraints() {} }; # if defined(BOOST_HAS_LONG_LONG) ! template <> struct SignedIntegerConcept<longlong> { void constraints() {} }; # endif // etc. #endif Index: boost/boost/cstdint.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/cstdint.hpp,v retrieving revision 1.33 diff -c -p -r1.33 cstdint.hpp *** boost/boost/cstdint.hpp 10 Aug 2004 12:53:33 -0000 1.33 --- boost/boost/cstdint.hpp 15 Aug 2004 08:25:11 -0000 *************** namespace boost *** 278,283 **** --- 278,305 ---- #endif // BOOST_HAS_STDINT_H + + #ifdef BOOST_HAS_LONG_LONG + + namespace boost { + + # ifdef __GNUC__ + + __extension__ typedef long long longlong; + __extension__ typedef unsigned long long ulonglong; + + # else + + typedef long long longlong; + typedef unsigned long long ulonglong; + + # endif + + } // namespace boost + + # endif // BOOST_HAS_LONG_LONG + + #endif // BOOST_CSTDINT_HPP Index: boost/boost/integer_fwd.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/integer_fwd.hpp,v retrieving revision 1.3 diff -c -p -r1.3 integer_fwd.hpp *** boost/boost/integer_fwd.hpp 11 Aug 2004 10:59:33 -0000 1.3 --- boost/boost/integer_fwd.hpp 15 Aug 2004 08:25:11 -0000 *************** *** 12,19 **** #include <climits> // for UCHAR_MAX, etc. #include <cstddef> // for std::size_t ! #include <boost/config.hpp> // for BOOST_NO_INTRINSIC_WCHAR_T ! #include <boost/limits.hpp> // for std::numeric_limits namespace boost --- 12,20 ---- #include <climits> // for UCHAR_MAX, etc. #include <cstddef> // for std::size_t ! #include <boost/config.hpp> // for BOOST_NO_INTRINSIC_WCHAR_T ! #include <boost/cstdint.hpp> // for longlong ! #include <boost/limits.hpp> // for std::numeric_limits namespace boost *************** template < > *** 67,76 **** #ifdef ULLONG_MAX template < > ! class integer_traits< long long >; template < > ! class integer_traits< unsigned long long >; #endif --- 68,77 ---- #ifdef ULLONG_MAX template < > ! class integer_traits< longlong >; template < > ! class integer_traits< ulonglong >; #endif Index: boost/boost/limits.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/limits.hpp,v retrieving revision 1.11 diff -c -p -r1.11 limits.hpp *** boost/boost/limits.hpp 10 Aug 2004 12:53:33 -0000 1.11 --- boost/boost/limits.hpp 15 Aug 2004 08:25:12 -0000 *************** *** 12,17 **** --- 12,18 ---- #define BOOST_LIMITS #include <boost/config.hpp> + #include <boost/cstdint.hpp> #ifdef BOOST_NO_LIMITS # include <boost/detail/limits.hpp> *************** *** 25,31 **** #ifdef BOOST_HAS_MS_INT64 # define BOOST_LLT __int64 #else ! # define BOOST_LLT long long #endif namespace std --- 26,32 ---- #ifdef BOOST_HAS_MS_INT64 # define BOOST_LLT __int64 #else ! # define BOOST_LLT longlong #endif namespace std Index: boost/boost/iterator/counting_iterator.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/iterator/counting_iterator.hpp,v retrieving revision 1.5 diff -c -p -r1.5 counting_iterator.hpp *** boost/boost/iterator/counting_iterator.hpp 26 Jul 2004 00:31:59 -0000 1.5 --- boost/boost/iterator/counting_iterator.hpp 15 Aug 2004 08:25:14 -0000 *************** *** 6,11 **** --- 6,12 ---- # define COUNTING_ITERATOR_DWA200348_HPP # include <boost/iterator/iterator_adaptor.hpp> + # include <boost/cstdint.hpp> # include <boost/detail/numeric_traits.hpp> # include <boost/mpl/bool.hpp> # include <boost/mpl/if.hpp> *************** namespace detail *** 57,67 **** # if defined(BOOST_HAS_LONG_LONG) template <> ! struct is_numeric<long long> : mpl::true_ {}; template <> ! struct is_numeric<unsigned long long> : mpl::true_ {}; # endif --- 58,68 ---- # if defined(BOOST_HAS_LONG_LONG) template <> ! struct is_numeric<longlong> : mpl::true_ {}; template <> ! struct is_numeric<ulonglong> : mpl::true_ {}; # endif Index: boost/boost/numeric/interval/detail/ppc_rounding_control.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/numeric/interval/detail/ppc_rounding_control.hpp,v retrieving revision 1.3 diff -c -p -r1.3 ppc_rounding_control.hpp *** boost/boost/numeric/interval/detail/ppc_rounding_control.hpp 19 Jul 2004 21:38:06 -0000 1.3 --- boost/boost/numeric/interval/detail/ppc_rounding_control.hpp 15 Aug 2004 08:25:18 -0000 *************** namespace interval_lib { *** 25,31 **** namespace detail { typedef union { ! long long int imode; double dmode; } rounding_mode_struct; --- 25,31 ---- namespace detail { typedef union { ! __extension__ long long int imode; double dmode; } rounding_mode_struct; Index: boost/boost/python/type_id.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/type_id.hpp,v retrieving revision 1.15 diff -c -p -r1.15 type_id.hpp *** boost/boost/python/type_id.hpp 26 Jul 2004 00:32:05 -0000 1.15 --- boost/boost/python/type_id.hpp 15 Aug 2004 08:25:20 -0000 *************** *** 11,16 **** --- 11,17 ---- # include <boost/operators.hpp> # include <typeinfo> # include <cstring> + # include <boost/cstdint.hpp> # include <boost/static_assert.hpp> # include <boost/detail/workaround.hpp> # include <boost/type_traits/same_traits.hpp> *************** BOOST_PYTHON_SIGNED_INTEGRAL_TYPE_ID(lon *** 100,106 **** // using Python's macro instead of Boost's - we don't seem to get the // config right all the time. # ifdef HAVE_LONG_LONG ! BOOST_PYTHON_SIGNED_INTEGRAL_TYPE_ID(long long) # endif # undef BOOST_PYTHON_SIGNED_INTEGRAL_TYPE_ID # endif --- 101,107 ---- // using Python's macro instead of Boost's - we don't seem to get the // config right all the time. # ifdef HAVE_LONG_LONG ! BOOST_PYTHON_SIGNED_INTEGRAL_TYPE_ID(longlong) # endif # undef BOOST_PYTHON_SIGNED_INTEGRAL_TYPE_ID # endif Index: boost/boost/python/detail/wrap_python.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/detail/wrap_python.hpp,v retrieving revision 1.18 diff -c -p -r1.18 wrap_python.hpp *** boost/boost/python/detail/wrap_python.hpp 26 Jul 2004 00:32:07 -0000 1.18 --- boost/boost/python/detail/wrap_python.hpp 15 Aug 2004 08:25:21 -0000 *************** *** 25,30 **** --- 25,31 ---- // which confuses Boost's config // #include <limits.h> + #include <boost/cstdint.hpp> #ifndef ULONG_MAX # define BOOST_PYTHON_ULONG_MAX_UNDEFINED #endif *************** typedef int pid_t; *** 86,92 **** # endif # define HAVE_LONG_LONG 1 ! # define LONG_LONG long long # endif # elif defined(__MWERKS__) --- 87,93 ---- # endif # define HAVE_LONG_LONG 1 ! # define LONG_LONG longlong # endif # elif defined(__MWERKS__) Index: boost/boost/spirit/phoenix/operators.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/spirit/phoenix/operators.hpp,v retrieving revision 1.7 diff -c -p -r1.7 operators.hpp *** boost/boost/spirit/phoenix/operators.hpp 28 Jul 2004 01:57:45 -0000 1.7 --- boost/boost/spirit/phoenix/operators.hpp 15 Aug 2004 08:25:27 -0000 *************** *** 23,28 **** --- 23,29 ---- #include <boost/spirit/phoenix/actor.hpp> #include <boost/spirit/phoenix/composite.hpp> #include <boost/config.hpp> + #include <boost/cstdint.hpp> /////////////////////////////////////////////////////////////////////////////// namespace phoenix { *************** template <> struct rank<long> *** 373,380 **** template <> struct rank<unsigned long> { static int const value = 100; }; #ifdef BOOST_HAS_LONG_LONG ! template <> struct rank<long long> { static int const value = 110; }; ! template <> struct rank<unsigned long long> { static int const value = 120; }; #endif template <> struct rank<float> { static int const value = 130; }; --- 374,381 ---- template <> struct rank<unsigned long> { static int const value = 100; }; #ifdef BOOST_HAS_LONG_LONG ! template <> struct rank<boost::longlong> { static int const value = 110; }; ! template <> struct rank<boost::ulonglong> { static int const value = 120; }; #endif template <> struct rank<float> { static int const value = 130; }; Index: boost/boost/spirit/utility/chset.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/spirit/utility/chset.hpp,v retrieving revision 1.6 diff -c -p -r1.6 chset.hpp *** boost/boost/spirit/utility/chset.hpp 9 Jul 2004 08:28:06 -0000 1.6 --- boost/boost/spirit/utility/chset.hpp 15 Aug 2004 08:25:27 -0000 *************** *** 14,19 **** --- 14,20 ---- #include <boost/shared_ptr.hpp> #include <boost/spirit/core/primitives/primitives.hpp> #include <boost/spirit/utility/impl/chset/basic_chset.hpp> + #include <boost/cstdint.hpp> /////////////////////////////////////////////////////////////////////////////// namespace boost { namespace spirit { *************** chset_p(unsigned long ch) *** 164,177 **** #ifdef BOOST_HAS_LONG_LONG ////////////////////////////////// ! inline chset<long long> ! chset_p(long long ch) ! { return chset<long long>(ch); } ////////////////////////////////// ! inline chset<unsigned long long> ! chset_p(unsigned long long ch) ! { return chset<unsigned long long>(ch); } #endif /////////////////////////////////////////////////////////////////////////////// --- 165,178 ---- #ifdef BOOST_HAS_LONG_LONG ////////////////////////////////// ! inline chset<longlong> ! chset_p(longlong ch) ! { return chset<longlong>(ch); } ////////////////////////////////// ! inline chset<ulonglong> ! chset_p(ulonglong ch) ! { return chset<ulonglong>(ch); } #endif /////////////////////////////////////////////////////////////////////////////// Index: boost/boost/type_traits/is_convertible.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_convertible.hpp,v retrieving revision 1.25 diff -c -p -r1.25 is_convertible.hpp *** boost/boost/type_traits/is_convertible.hpp 6 Jan 2004 13:37:10 -0000 1.25 --- boost/boost/type_traits/is_convertible.hpp 15 Aug 2004 08:25:29 -0000 *************** *** 22,27 **** --- 22,29 ---- # include "boost/type_traits/is_void.hpp" #endif + #include "boost/cstdint.hpp" + // should be always the last #include directive #include "boost/type_traits/detail/bool_trait_def.hpp" *************** BOOST_TT_AUX_BOOL_TRAIT_DEF2(is_converti *** 260,266 **** TT_AUX_IS_CONVERTIBLE_SPEC_2(F,short) \ TT_AUX_IS_CONVERTIBLE_SPEC_2(F,int) \ TT_AUX_IS_CONVERTIBLE_SPEC_2(F,long) \ ! TT_AUX_IS_CONVERTIBLE_SPEC_2(F,long long) \ /**/ # define TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC(F) \ --- 262,269 ---- TT_AUX_IS_CONVERTIBLE_SPEC_2(F,short) \ TT_AUX_IS_CONVERTIBLE_SPEC_2(F,int) \ TT_AUX_IS_CONVERTIBLE_SPEC_2(F,long) \ ! TT_AUX_IS_CONVERTIBLE_SPEC(F,longlong) \ ! TT_AUX_IS_CONVERTIBLE_SPEC(F,ulonglong) \ /**/ # define TT_AUX_IS_CONVERTIBLE_FROM_FLOAT_CV_SPEC(F) \ Index: boost/boost/type_traits/is_integral.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/is_integral.hpp,v retrieving revision 1.8 diff -c -p -r1.8 is_integral.hpp *** boost/boost/type_traits/is_integral.hpp 1 May 2004 10:32:58 -0000 1.8 --- boost/boost/type_traits/is_integral.hpp 15 Aug 2004 08:25:29 -0000 *************** *** 10,15 **** --- 10,16 ---- #define BOOST_TT_IS_INTEGRAL_HPP_INCLUDED #include "boost/config.hpp" + #include "boost/cstdint.hpp" // should be the last #include #include "boost/type_traits/detail/bool_trait_def.hpp" *************** BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_inte *** 57,64 **** #endif # if defined(BOOST_HAS_LONG_LONG) ! BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,unsigned long long,true) ! BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,long long,true) #elif defined(BOOST_HAS_MS_INT64) BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,unsigned __int64,true) BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,__int64,true) --- 58,65 ---- #endif # if defined(BOOST_HAS_LONG_LONG) ! BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,ulonglong,true) ! BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,longlong,true) #elif defined(BOOST_HAS_MS_INT64) BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,unsigned __int64,true) BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,__int64,true) Index: boost/boost/type_traits/type_with_alignment.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/type_traits/type_with_alignment.hpp,v retrieving revision 1.24 diff -c -p -r1.24 type_with_alignment.hpp *** boost/boost/type_traits/type_with_alignment.hpp 26 Jan 2004 12:20:03 -0000 1.24 --- boost/boost/type_traits/type_with_alignment.hpp 15 Aug 2004 08:25:30 -0000 *************** *** 8,13 **** --- 8,14 ---- #ifndef BOOST_TT_TYPE_WITH_ALIGNMENT_INCLUDED #define BOOST_TT_TYPE_WITH_ALIGNMENT_INCLUDED + #include "boost/cstdint.hpp" #include "boost/mpl/if.hpp" #include "boost/preprocessor/list/for_each_i.hpp" #include "boost/preprocessor/tuple/to_list.hpp" *************** typedef int (alignment_dummy::*member_fu *** 43,49 **** #ifdef BOOST_HAS_LONG_LONG #define BOOST_TT_ALIGNMENT_BASE_TYPES BOOST_PP_TUPLE_TO_LIST( \ 12, ( \ ! char, short, int, long, long long, float, double, long double \ , void*, function_ptr, member_ptr, member_function_ptr)) #else #define BOOST_TT_ALIGNMENT_BASE_TYPES BOOST_PP_TUPLE_TO_LIST( \ --- 44,50 ---- #ifdef BOOST_HAS_LONG_LONG #define BOOST_TT_ALIGNMENT_BASE_TYPES BOOST_PP_TUPLE_TO_LIST( \ 12, ( \ ! char, short, int, long, longlong, float, double, long double \ , void*, function_ptr, member_ptr, member_function_ptr)) #else #define BOOST_TT_ALIGNMENT_BASE_TYPES BOOST_PP_TUPLE_TO_LIST( \

6 16

[boost] my 2 cents x 10 - Documentation, moreIO, iostreams, move_ptr, fsm, & boost
by Thomas Xkey 04 Sep '04

04 Sep '04

my 2 cents x 10 - Documentation, moreIO, iostreams, move_ptr, fsm, boost -------------------- Review Periods I would prefer to see a review period of 10-12 days [i like 12 days from a sunday thru the following weeks friday perspective.] The present period is just to short. Most of us are overworked, underpaid, and dont always care to look at works in progress of others until things are a bit more "finalized" and "stable" so to speak. Hence we may not peek early enough at a library to provide good guiding input but we can toss our 2 cents in during the final review melee lol :) ---------------------- Documentation !!! Please utilize & include more diagrams & examples in your library documentation!!!! Compare & contrast with existing implementations that are lacking, State why they are lacking, what they are lacking, with what the proposed library implementation presents to fill the missing pieces, how it is better in some respects to anything it "replaces", and why it replaces some typical library code currently in widespread use or fills a gaping hole. --------------------- moreIO & IOstreams Daryls rationales and motivations are completely lacking in depth and sharpness. The summarys are so general and non-delineated that they are no help to me in discerning the clarity of what he proposes as benefits and properties of his library. an example :: this snippet is from the wrapping streams rationale "The Standard stream base class templates are designed to use stream buffers with an independent lifetime, and include functionality for switching what stream buffer is used." Yes, but are you just reiterating something everyone already knew, do you feel that is a bad thing or a good thing? There are no "supporting" remarks no remarks of impact laden with design criteria or shortcomings. Not coming from a circle where I/O is the most important aspect of my development I am not an "expert" on streams. So reading the documentation which purports to support and sing the praises of this libary was completely useless to me. I had better luck just looking at the code. When i think rationale and motivation i think objectivity must be forefront. Even a simple outline or summary of design criteria clearly delineated and put forth makes it easier to read an overall document of this nature. Project managers and others working on a project need to see clarity of thought, clear cut guidelines, inputs, outputs, and the design that goes in the middle. I am sure as most have laid out the design of their libraries they have ad-hoc flowcharts, points pro & against certain features. You may wish to bring some of those out and flesh them into the documentation so that others can understand the motivations behind your design. It would surely make life easier for anyone reviewing the code to speak to the issues addressed and/or generated by the code. It would elevate the efficiency of the process. Now that isnt to say some fluff isnt nice *grin* null_stream yes. something missing that is necessary. would prefer though to see it constructed using the concept of sinks & sources from the turkanis IO library up for review. streambuf_wrapping I would vote no on this until it is cleaned up and a better rationale presented to me. array_stream maybe. you would have to convince me this buys something appreciable in an efficiency concern over the way the standard streams presently operate. perhaps give me 2 examples a non-I/O expert such as myself could "grasp" concretely. pointer_stream no. the concept would be better implemented again using turkanis IO lib up for review. value_stream no. this specialized stream doesnt seem all that beneficial to stuff it in to a library. if the appl programmer wishes to he can easily fabricate his own. [u have a value_stream for just a char, what about for just a user_type, for just a "string" etc why not a "pair_stream" that would return a pair of values etc ad nauseum] now that isnt to say such a stream cannot be useful on rare occasion but again it would be fairly easy to implement using an appropiate set of "sources/sinks" that could be implemented in turkanis IO lib. -------- Now having said that it may seem like i'm being a pita and trying to tear your hard work into pieces, but i think you have some good "ideas" but perhaps the implementation should come off differently. I think if you perhaps had looked into the other IO lib that jason was developing at the time you 2 coudl have had a meeting of the minds and come up with some great ideas and both done some things differently. This library is a software community and with scales ever growing great ideas shouldnt necessarily be pondered on by lone rocket scientists squirreled away with their code and not picking their heads up to look around and talk (though we all do accept input i'm sure, and even act upon some of it, it seems more often than not we do not communicate as much as we should in the "early stages" and leave it all for the end-game) Perhaps you 2 should get together and collaborate. [now there's a concept] --------- Now my rationale : We all agree a layered/tiered approach to complex software is the best way to go. It allows more degrees of freedom, greater re-user, greater specialization as well, and greater replacement of parts. It does push or mutate the complexity more from a particular piece of complex code into the complexity of "simpler components" with more complex entanglement, more complex communication and cooperation at times. This is why i would much prefer with some efficiency clean-ups & improvements that the turkanis library be used as a basis(implementation-wise) for any of the moreIO features accepted. I like the small raw nature & flexibility of the simpler "building pieces" at the bottom of this IO pyramid I can then compose my complex streams on these "sinks & sources" As to the turkanis library, I have not had as much time to examine it. I am not sure the merit of Carlo Woods remarks but from a 1st perusing I think i agree with him. I also partly agree with Daryl about some efficiency concerns and bloat concerns but i think with everyones assistance those can be hammered out or down in size. ---------------- 2 cents on names for manipulators & readability These comments are due to the disagreement some seem to have over things like newl versus newlines and proliferation of manipulators and whether some should be placed in the library and others left to appl developers to produce on their own. A) Do not have both a singular and plural version instead just opt for the plural version - the singular use could be the default and is typically understood as much by viewing code as well. that is to say dont have a skipline & skiplines instead just opt for skiplines skiplines(x) would skip x lines [thus for one line x==1] B) The use of underscores to break up and make names more readable for classes, vars & funcs is a good thing. Someone tried to bring up the point that the standard streams library was such n such a way well that doesnt just mean it was the best way in terms of its naming schema C) I prefer slightly longer more meaningful names getting away from obfuscation so when it comes to newl or nl i'd really prefer newline. i think most of us can type sufficiently fast and we are thinking "newline" in our heads we can type it with barely any speed difference nor loss in efficiency but it makes for a lot better readability than "nl" (my cognitive web sees "nl" as netherlands these days lol) now that isnt to say this should be taken to the maximum in the opposite direction!! macros/functions like "min" & "max" are plenty self-explanatory. Ok, so that was more like 3 cents on this topic :) ---------------- fsm This library seems & acts more like a "simulator" than an "efficient finite state machine". There is a very high level functionality tied into (possibly) a bare-bones base... not properly tiered or layered approach. Functionality is wrapped into one library rather than separated into add-on libraries with additional functionality. It doesn't seem to scale well even according to the author(s)? (most fsms a computer scientist would deal with encompass 100s to 1000s of states with as many different transitions possible) I would strongly urge something more efficient and bare bones along the lines of http://www.research.att.com/sw/tools/fsm/ take on the mantle of an "fsm" library in boost upon which coarse-grained objects can be simulated from above. would prefer this 'currently proposed' fsm to take on its true stance perhaps attaching the nomenclature of "hlfsm" --> "high level fsm". Due to its greater abstractions, fluffy aggregations and bulk in nature it isnt "efficient". If a library isnt efficient for its purpose or intended purposes then it will be under-utilized. I could never use this one as it is evolving away from an efficient fsm into more of a large coarse simulator. [now if i had need of that it would be great] This library seems more intended for simulation at a higher level than at a more simplistic state/event transition approach. Yes i am biased coming from an algorithms and mathematical background; I am more of a computer scientist who practices softare engineering than most application programmers who just want a product out the door and efficiency goes out the window. Can we adjust this library conceptually into a cleaner bare-bones fsm at one layer and then interject the higher level simulation aspects along with the ability to automatically produce code etc. [Canned automatically generated code is usually not so hot. In fact it rather bites. Any decent programmer can still out-optimize todays compilers based on intimate knowledge of their code & algorithms even on todays complex processors. Given that compilers have thousands of man-years of code & know-how how does one expect this fsm library to generate decent code or is it intended for someone who cannot program?] ------------------ On the subject of move_ptr How about self_consistent_ptr invar_postmove_ptr I must be a freak because "selfish_ptr" grows on me it instantly says "mine mine all mine i can move through proustian circles but it is still my object" moveptr is something i've seen in untold reams of computational code along with leftptr, rightptr, and currptr & variants thereof; so i'm really hoping someone comes up with better nomenclature to settle on :) -------------------- Lastly an area where I dont want to get into because no one manages software well lol The topic of boost - releases, the GABB (gawd almighty boost book), documentation & structure 1) is it possible to go with both a long-term more flexible scheme for release-dates along with a more rigid short-term window as we slide forward into the future? Note the famous M$ vaporware long-term software & release info is not the approach i'm talking about lmao more like "tentative" long range plans [the reiser boys(release 4 is out now) have done a good job with their long term feature & release targets] but sticking to your guns short term with branches rather than how it has been this "special circumstance" time I think most are of the opinion from the app & devel point of view that more "dot" releases are better rather than fewer. (of course within reason!) Presently it seems haphazard with cvs patch check-ins and outs and then fudging jam files, regression test failures and ... seems like by waiting so long between "dot" releases is NOT buying you any more efficiency or salvation from bug issues any more than having more frequent releases would but some of the libs within would be able to rev and get feedback faster. The compilation (syntax) issues are one thing but seems like some of the libs would benefit from hitting the streets when the developers have stomped most of their bugs. It becomes time the hapless consumer of the lib can play their guinea pig role and dive into their playground with much zeal. So i dont see any "good solid" argument as to why releases are so far apart rather than a bit more "reasonably timely" [ok well integration testing when a MAJOR lib-wide wholescale change occurs is one reason why a particular release would take forever :)] NOW if it was an end-user , we all know how psychologically important keeping the release #s down and only coming out with a major rev every few millenia(hic sarcasm hic) is great for business [hmm IE 6 hmmm how many years b4 IE 7? lolol] We devels are made of more sterner stuff though :) 2) Is the flippin book going to be available as ps or pdf since I dont feel the need to kill more trees just to have another book about programming yada yada yada collecting dust on my bookshelves? most programming books are so light on substance and full of wasted verbiage they could do without it isnt funny. [my fave c++ book was the annotated reference can ya tell? lol] If not, would at least the chapter summaries along with toc, glossary, and appendices be available for d/l? I much prefer cutting to the chase to get to information 3) Can someone get the documentation into a more consistent format along with the information at boost.org /boost-consulting site? as someone else pointed out the review information at boost.org was shall we say "slightly dated" 4) Structure ... oh forget it i've rambled enough on this random walk C++ya, xkey

4 3

C++ Random Container
by Joel Young 04 Sep '04

04 Sep '04

I would be very interested in such a container. Even more, I would be interested in a priority queue which allows one to specify a distribution based on either the order statistic or the priority. The head/front/pop operator would then select based on the distribution. Joel

2 3

Re:[boost] Re: IOStreams review
by Robert Ramey 04 Sep '04

04 Sep '04

>"Dietmar Kuehl" <dietmar_kuehl(a)yahoo.com> wrote in message >news:200409031908.13053.dietmar_kuehl@yahoo.com... >|On the ACCU 2003 conference JC (I can figure out the full name if >|necessary...) presented the idea for creating filters which I really >|liked. It looked something like this: >|filter_stream out(tee(std::cout) | encode | gzip | file("some file")); >|This would create a stream which writes everything to 'std::cout' >|and also encodes the stuff before sending it on to compress it and >|finally write it to the file. I like this notation... >I second that FWIW - I do NOT like this idea. I concede its mostly a matter of taste but I think it adds another layer of syntax. I think the original .. push, etc is ok. But my preference would be for filter_stream out( tee( std::out, encode( gzip( file("somefile") ) ) ) ) I'm sure people are going to love this idea. Robert Ramey

3 2

Checking if RTTI is available.
by Jurko Gospodneti� 03 Sep '04

03 Sep '04

Hi all. I was wondering if boost has any portable way for detecting whether RTTI is enabled? (For instance a macro expanding to _CPPRTTI in Visual Studio). If there is, I have not been able to find it. Best regards, Jurko

6 7

[range] Collection Concept
by David Abrahams 03 Sep '04

03 Sep '04

Are the authors of range libraries aware of http://boost/libs/utility/Collection.html? Just wanted to make sure. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 15

Building Boost with PathScale compiler
by Richard Hadsell 03 Sep '04

03 Sep '04

I am trying to build the Boost 1.31.0 libraries on an AMD Opteron platform using PathScale C++ 1.2. There is no toolset for this compiler, which looks something like a MipsPro compiler and something like a g++ compiler. Has anyone created a toolset for it? If not, how do I build a new toolset, or is there an easier way to build and install the libraries? -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601

2 5

Boost serialization: release configuration linker errors
by Andrew Favell 03 Sep '04

03 Sep '04

Ive been using Boosts serialization library with MSVC 7.1 (the first time that Ive used it). For most of my project I put the load / save function declaration in the class header (the .h file) and the definitions in the .cpp file VC 7.1 allows this for templated functions, unlike some older compilers. In debug mode this compiled and linked fine except for abstract base classes through trial and error I found that for abstract classes the functions had to be defined in the .h file to avoid linker errors. My project built fine in Debug mode and I then tried to compile / link it in Release mode this threw up quite a few LNK2001 errors relating to just a few of the serialization load / save functions in just some of the classes most of the classes that declared the load / save functions evidently linked fine (as they all did in Debug mode). After much double checking of the compile / link project configurations I tried the following: 1. I removed the BOOST_CLASS_EXPORT(etc) declaration at the bottom of the .h files in which the load / save functions were not linking. On recompiling / linking most of the linker errors were gone, but a few remained. 2. For the remaining classes that were not still not linking, I moved the load / save functions from the .cpp file into the .h file (these were not abstract classes). This fixed the remaining linker errors and my application compiled / linked / ran fine. I can't see why this occurred. I havent checked yet (its very time consuming to rebuild this application) but possibly option (2) would have worked for all the affected classes. For most of this project, the load / save functions remain defined in the .cpp file and clearly link fine in both debug and release configurations. Before someone asks, I did complete clean / rebuilds for both configurations anybody any ideas? andy :-) -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

IOStreams review
by Dietmar Kuehl 03 Sep '04

03 Sep '04

Hi, let's start with the obvious formal requirement for review, i.e. the answer to the question: Should this library be included into Boost? I don't know. I have no strong feelings either way. Maybe I'm too used to writing stream buffers without help from any library but to me it is unclear whether this really makes things simpler. The number of different concepts is, at least to me, quite confusing. The library does, however, avoid a small fraction of boilerplate code (mainly for buffer maintenance). Unfortunately it does not at all address the really problematic area in stream buffers, namely seeking: the interface of stream buffers is retained. This is interface is, in my opinion, really hard to use. Typically, I don't bother implementing it unless some specification requires me to do so. On the other hand, I'm not using seeking with streams anyway. The documentation should make clear that the filters are not usable as temporary add-ons: I have some uses where I have an underlying stream buffer which is used directly until a portion of the stream needs special processing. At this point, a filter is used to process the portio and normal processing is continued afterwards. For example, when parsing a mail, a mime-decode filter is used to handle embedded binary data. This assumes, however, that the filter synchronizes with the underlying stream buffer. On the ACCU 2003 conference JC (I can figure out the full name if necessary...) presented the idea for creating filters which I really liked. It looked something like this: filter_stream out(tee(std::cout) | encode | gzip | file("some file")); This would create a stream which writes everything to 'std::cout' and also encodes the stuff before sending it on to compress it and finally write it to the file. I like this notation... Finally, here are some issues I stumbled over in the documentation: - The description for "boost::io::read()" seems wrong to me: "returning a value less than n indicates end-of-sequence". At least on POSIX systems, return less than the number of requested bytes indicates that *currently* no more characters are available. The next call may return more characters. This behavior could be useful e.g. when filtering: get a buffer from the underlying stream and pass on what is left from this buffer after filtering. - On the "Filter" concept page, "OutputFilter" is not found (but it is reachable from the "InoutFilter" page). - On the "SeekableFilter" concept page, I think the preconditions for "f.put()" and "f.write()" should be "output" rather than "input". At least, I would consider it confusing if "input" were right... -- <mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/> <http://www.contendix.com> - Software Development & Consulting

5 6

[mpl] bug: has_xxx, default bool parameter
by Daniel Wallin 03 Sep '04

03 Sep '04

The traits generated with BOOST_MPL_HAS_XXX_TRAIT_DEF() doesn't work with lambda on VC7.1+. I think the problem is the default bool parameter: template< typename T, bool fallback_ = default_ > struct trait \ ^^^^^^^^^^^^^^^^^^^^^^^^^ This template will never match: template<template<typename ..> class F, class U1 .. UN> struct lambda<F<U1 .. UN> >; So lambda breaks. I guess the solution is to stop using a default bool parameter and use a class type instead. -- Daniel Wallin

2 1

[mpl] patch for config/has_xxx.hpp
by Jonathan Turkanis 03 Sep '04

03 Sep '04

Hi Aleksey, It looks like boost/mpl/aux_/config/has_xxx.hpp has an unnecesary include directive for boost/mpl/aux_/config/gcc.hpp. Jonathan begin 666 has_xxx.patch M26YD97@Z(&AA<U]X>'@N:'!P#0H]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]#0I2 M0U,@9FEL93H@+V-V<W)O;W0O8F]O<W0O8F]O<W0O8F]O<W0O;7!L+V%U>%\O M8V]N9FEG+VAA<U]X>'@N:'!P+'8-"G)E=')I979I;F<@<F5V:7-I;VX@,2XR M#0ID:69F("UU("UR,2XR(&AA<U]X>'@N:'!P#0HM+2T@:&%S7WAX>"YH<' ) M,B!397 @,C P-" Q-3HT,#HT-2 M,# P, DQ+C(-"BLK*R!H87-?>'AX+FAP M< DR(%-E<" R,# T(#$X.C$P.C$X("TP,# P#0I 0" M,38L-R K,38L-B! M0 T*("\O("12979I<VEO;CH@,2XR("0-"B -"B C:6YC;'5D92 \8F]O<W0O M;7!L+V%U>%\O8V]N9FEG+V]V97)L;V%D7W)E<V]L=71I;VXN:'!P/@T*+2-I M;F-L=61E(#QB;V]S="]M<&PO875X7R]C;VYF:6<O9V-C+FAP<#X-"B C:6YC M;'5D92 \8F]O<W0O;7!L+V%U>%\O8V]N9FEG+W=O<FMA<F]U;F0N:'!P/@T* M( T*("\O(&%G=7)T+" Q,2]J86XO,#,Z('-I9VYA;',@82!S='5B+6]N;'D@ :)VAA<U]X>'@G(&EM<&QE;65N=&%T:6]N#0H` ` end

2 1

[BGL] Compilation failure of adjanceny_list on IBM
by Matthias Troyer 03 Sep '04

03 Sep '04

Since a recent CVS update the assignment operator of an adcacency_list graph fails to compile under the IBM vacpp compiler (xlC). The simplest test case is: #include <boost/graph/adjacency_list.hpp> int main() { typedef boost::adjacency_list<boost::vecS,boost::vecS,boost::directedS> G; G g; g = G(); } which fails as follows: "/users/matroyer/boost/boost/optional/optional.hpp", line 353.66: 1540-0210 (S) "T" is not a base class of "pair<boost::detail::out_edge_iter<std::_Ptrit<boost::detail:: sep_<unsigned long,boost::no_property>,long,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &>,unsigned long,boost::detail::edge_desc_impl<boost::directed_tag,unsigned long>,long>,boost::detail::out_edge_iter<std::_Ptrit<boo...". "/users/matroyer/boost/boost/optional/optional.hpp", line 353.10: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::pair<boost::detail:: out_edge_iter<std::_Ptrit<boost::detail::sep_<unsigned long,boost::no_property>,long,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &>,unsigned long,boost::detail::edge_desc_impl<boost::directed_tag,un...". "/users/matroyer/boost/boost/optional/optional.hpp", line 212.10: 1540-0700 (I) The previous message was produced while processing "boost::optional_detail::optional_base<std::pair<boost::detail:: out_edge_iter<std::_Ptrit<boost::detail::sep_<unsigned long,boost::no_property>,long,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &>,unsigned long,boost::detail::edge_desc_impl<boost::directed_tag,un...". "/users/matroyer/boost/boost/graph/detail/adj_list_edge_iterator.hpp", line 38.11: 1540-0719 (I) The previous message was produced while processing the implicit member function "boost::detail::adj_list_edge_iterator<boost:: counting_iterator<unsigned long,boost::use_default,boost::use_default>,boost::detail:: out_edge_iter<std::_Ptrit<boost::detail::sep_<unsigned long,boost::no_property>,long,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsign...". "/users/matroyer/boost/boost/tuple/detail/tuple_basic.hpp", line 578.10: 1540-0700 (I) The previous message was produced while processing "boost::tuples::tuple<boost::detail::adj_list_edge_iterator<boost:: counting_iterator<unsigned long,boost::use_default,boost::use_default>,boost::detail:: out_edge_iter<std::_Ptrit<boost::detail::sep_<unsigned long,boost::no_property>,long,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,boost::no_property> &,boost::detail::sep_<unsigned long,boost::no_property> *,boost::detail::sep_<unsigned long,...". "/users/matroyer/boost/boost/graph/detail/adjacency_list.hpp", line 1943.19: 1540-0700 (I) The previous message was produced while processing "boost::vec_adj_list_impl<boost::adjacency_list<boost::vecS,boost:: vecS,boost::directedS,boost::no_property,boost::no_property,boost:: no_property,boost::listS>,struct boost::detail::adj_list_gen<class boost::adjacency_list<boost::vecS,boost::vecS,boost::directedS,boost:: no_property,boost::no_property,boost::no_property,boost::listS>,boost:: vecS,boost::vecS,boost::directedS,boost::no_property,boost:: no_property,boost::no_property,boost::...". "../../src/alps/lattice/unitcell.C", line 3.5: 1540-0700 (I) The previous message was produced while processing "main()" Can any of the BGL experts help? Matthias

1 0

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

03 Sep '04

> Behalf Of David Turner > Sent: Friday, 20 August 2004 3:32 AM > To: boost(a)lists.boost.org > Subject: RE: [boost] Java style GUI in C++ > > > 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 it's > > AWT and Swing libraries. Specifically: > > [snip] > > > I would appreciate comments and ideas as to what people would > > like out of a > > GUI framework, especially one that will be multi-platform. > > > > Boost-style C++ GUI library utilizing boost::signals and with a nice way > of handling message loops: > > http://cxxgui.sf.net/ Looks like a very nice conservative approach. I think you're wise to keep it simple and take a conservative c++ approach. Only trouble is it still feels like a lot of other things just shines a bit brighter and has cleaner lines. However I must say I've never seen a UI lib I've been happy with. Nor have I written one, or infrastructure that uses one, that I've been fond of. I find even 200 lines of code (not cxxgui) for a simple split windows file explorer-like interface scary, but the sad thing is that it is a great improvement over the norm. 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... 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. 3. get rid of the distinction between properties, events and methods. Consider a widget a functor with visual side affects. Consider it like a dataflow where properties being set, events and method calls are just messages coming into this node. Allows you to interpose handlers, recorders, do nice testing and all sorts. Draw backs are interoperability with initialization requirements of widgets. That is, some things are set at widget create time. But this might handled by avoiding by not changing such parameters and thus not needing to change, but if initialization only parameters of legacy components change, then destroy and recreate the component. 4. Structural context sensitivity, 4a inherit properties from your run-time structural parents, fonts, colours, whatever, perhaps from theme packages that are higher in the tree. The structural tree is used to find the appropriate handler for properties, events and methods (all one in the same) 4b Context sensitive addressing and sources. Just like event handling, property setting and method calls are sinks that are handled with structural sensitivity, sources, such as changing properties, data propagation flow out and can be addressed in a context sensitive manner. E.g. if you have a widget that is expecting an source for stock code, it should look up the structural hierarchy to find it, unless it is provided with an explicit mapping to a different source. Allow non UI components that can act as holders for properties (like a root blackboarding thingo (technical term) ) so that components can reflect context of non-parental nodes. 4c Context sensitive addressing. Want to be able to get the properties / sources of siblings, i.e. children of parents of yours. "Instrument" -> "maturity". You find the parent and then lock into its context for a piece of detail. 5. must be multiplatform, leveraging off something like wxwidgets like notus does for its implementation layer would probably be a good idea. 6. must have a wysiwyg designer (though I could live without it) (self hosting would be a neat goal) - integrating the compiler into this and being an ide would be nice - perhaps something like eclipse could help 6a Because of the run configurability of everything there is nothing to stop external descriptions of components, including the mapping of sources to sinks to capture most of the requirements. Obviously where code is needed you need code and an xml resource description will not help. 7. Should support run time type conversions to allow easy hooking up of stuff. Not sure how explicit or implicit this should be. A while ago I did something like this that also supported the dimensionality of the data so you could cut, slice and aggregate stuff easily between widgets. E.g. use the entire list, the selected items, etc... would take some kind of multidimensional iterator thing I guess. Allows some sophisticated run-time modelling capabilities. See the data in a grid, or a list control, a combo, .... With this kind of structure you should be able to compose widgets hierarchies that have awareness of the others around them and will have reasonable normal functionality without too much coding at all. Supporting this at run time as well allows you to have some nice drag / drop or otherwise dynamic configurability. Have some that get a list of strings, displays it in a list. Click on a list item and a chart and grid automatically updates. A detailed pane of items relevant to the first click docked at the side updates. The exit item in the menu does the default behaviour of shutting down the application. My goal is that this should be possible with out an enormous number of lines of code. Structurally specify it. Use context sensitivity, standardish workflows and data set handling / iterator capabilities to avoid code. Thwack custom events in where needed. Been thinking about this for years and have implemented various systems that do bits of this approach. Enough to know it works pretty well. It has always been too much work to chew on as a generic solution though... $0.005, Matt. Side issue: resizing / device independence. Problem with swing / wxwidget sizers and the like is that you can end up with some ugly looking screens with lots of space, things that are too small on screen sizes that are inappropriate. A lot of the time it doesn't matter too much, but often enough to irk me the screens just don't look "sharp" enough compared to an explicitly designed screen. This is often the issue with smaller screen sizes like portable devices. Something I've done in the past is to give components fractions of resizing for top, left, height and width which allows a tight design, to the pixel ( I really like the compile time unit dimensioning of the co-ords by the way, positioning by mm dimensions is great) with easier control on how the thing will resize. Also for device independence you might be able to target a different device by using a capability set where controls map to other controls for that device, they just have to handle the same sources and sinks for their node, i.e. have the same conceptual support. Perhaps that be a nice level of indirection to solve problems. Use a tree control, grid or list or whatever, just don't specific which. The platform configuration maps in the explicit control. Is you use a more refined control that is not available on that specific platform, you can substitute a generic one based on a substitutability principle (like Liskov SP), or perhaps it is an error (perhaps the design can specific the functionality that must exist for the there to be no error). A thin client approach to this would be even nicer, separate the visual aspects from the data it refers to by protocol and/or method call so that interesting thin / thick / adaptive clients can be built. 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.

6 17

Boost::Python iterators are off by 1?
by Dan Eloff 03 Sep '04

03 Sep '04

If this is my fault the docs need to be more explanatory, but here's the problem: for the sequence (0, 1, 2), the Boost::Python iterator starts at 1 and ends 1 past 2 ( where 3 might be ). It does this because it calls the C++ iterators functions in this order: operator == post-increment dereference It should imho call them like (which would correct the issue) operator == dereference post-increment Like a normal for loop would execute: condition, code, action. The code to reproduce this is: #include <iterator> #include <boost/python.hpp> namespace py = boost::python; struct ctn { struct iterator: public std::iterator< std::input_iterator_tag, py::str > { int mNum; iterator( int num = 0 ): mNum( num ) {} py::str operator *() const { char temp[20]; const char * str = itoa( mNum, temp, 10 ); return py::str( str, strlen( str ) ); } iterator& operator ++(int) { mNum++; return *this; } friend bool operator ==( iterator lhs, iterator rhs ) { return ( lhs.mNum == rhs.mNum ); } }; iterator begin() { return iterator( 0 ); } iterator end() { return iterator( 3 ); // the range (0, 1, 2) three items } }; BOOST_PYTHON_MODULE(iter_bug) { py::class_< ctn >( "ctn" ) .def( "__iter__", py::iterator< ctn >() ) ; } >>> from iter_bug import * >>> c = ctn() >>> for i in c: ... print i ... 1 2 3 >>> Notice how it's off by one because of the very strange order of doing things. Please help! -Dan

2 8

[test][vacpp] problem with Boost.Test under IBM VisualAge C++ V6.0 for AIX
by JOAQUIN LOPEZ MU?Z 03 Sep '04

03 Sep '04

Many tests are failing with the following "/home/tk/boost_regression/boost/libs/test/src/unit_test_result.cpp", line 147.61: 1540-0130 (S) "std::__log10" is not declared. I've taken a look at the offending file and seems nothing has changed in the past months with respect to the usage of std::log10, so I guess this will have to do with some problem or misconfiguration in vacpp std lib. Any idea? Thank you Joaquín M López Muñoz Telfónica, Investigación y Desarrollo

3 3

[Boost-bugs] [ boost-Bugs-1021799 ] struct pointer_iterator_traits<T*> fails on VC7.1
by SourceForge.net 03 Sep '04

03 Sep '04

Bugs item #1021799, was opened at 2004-09-03 14:50 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=1021799&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marvin H. Sielenkemper (sielenk) Assigned to: Nobody/Anonymous (nobody) Summary: struct pointer_iterator_traits<T*> fails on VC7.1 Initial Comment: We are using boost::iterator_facade in our project. During compilation we got an error: c:\Boost\include\boost-1_31\boost\detail\iterator.hpp (270) : warning C4346: 'boost::remove_const<T>::type' : dependent name is not a type The error was caused by class k_EntryIterator : public boost::iterator_facade<k_EntryIterator, r_DirectoryEntry, boost::single_pass_traversal_tag> { public: k_EntryIterator(k_DirectoryInfo& ak_Owner); ~k_EntryIterator(); private: friend class boost::iterator_core_access; k_DirectoryInfo& mk_Owner; void increment(); bool equal(k_EntryIterator const& other) const; r_DirectoryEntry& dereference() const; }; and was easily fixed by adding a 'typename' in line 270 of iterator.hpp: old: typedef remove_const<T>::type value_type; new: typedef typename remove_const<T>::type value_type; MfG, Marvin H. Sielenkemper ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1021799&group_… ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

compile-time variables
by Goran Mitrovic 03 Sep '04

03 Sep '04

I've got a question. Is a compile-time variables concept known? It would be a set of macros that would allow assigning and changing a number assigned to a variable's name. Such variable would be considered as a constant from template argument's perspective, for example. One of the usage for such classes I have in mind would be the painless type registration of typeof macro, for example...

6 8

An alternative typeof macro
by Daniel James 03 Sep '04

03 Sep '04

I've come up with an alternative way to invoke the typeof emulations that have been posted. It basically works by defining an iterator over the encoded type. Unfortunately, it can't be used inside a function, and is awkward to use in general, but has the advantage is that it only has to define the call to foo once, which might result in faster compile times. It could possibly also remove the limit on the complexity of the type. Arkadiy's version would require a some changes to do this, but I think Peder's could quite easily. Although I'm not sure as I've only had a brief look at his version. I've implemented it as a sort of typedef, which seems like the easiest way to use it. It's probably easier to understand the code than my explanation, so here it is. It's based on Arkadiy's version in the yahoo groups file section. #define BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name) \ BOOST_PP_CAT(BOOST_TYPEOF_TYPEDEF_ITERATOR_##Name##_, __LINE__) #define BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ struct BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name) { \ template <int pos> \ struct iterator { \ typedef boost::mpl::int_< \ sizeof(boost::type_of::foo<pos>(Expr))> type; \ typedef iterator<pos+1> next; \ }; \ }; #define BOOST_TYPEOF_TYPEDEF(Expr, Name) \ BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ typedef boost::type_of::decode_type< \ BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name)::iterator<0> \ >::type Name; #define BOOST_TYPEOF_TPL_TYPEDEF(Expr, Name) \ BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ typedef typename boost::type_of::decode_type< \ BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name)::iterator<0> \ >::type Name; Here is an example of it's use: template <class Op> struct result_of_nullary_functor { static Op op; BOOST_TYPEOF_TPL_TYPEDEF(op(), type); }; struct g { int operator()(); }; BOOST_MPL_ASSERT_IS_SAME(result_of_nullary_functor<g>::type, int); I've only tested on the intel linux compiler. Daniel

5 38

RE: [boost] Porting to SCO Unix
by Ben Hutchings 03 Sep '04

03 Sep '04

John Maddock <john(a)johnmaddock.co.uk> wrote: > > The following tests in libs/config/configure produce incorrect > > results: > > > > ** checking for pthread_exit in -lpthread... no > > This test tries to compile a C source file that prototypes > > "pthread_exit" as "char pthread_exit();". But my compiler driver > > always adds "-include <...>/pthread.h" to the command line, which > > includes a different, conflicting prototype for this function. I > > think the test ought to include <pthread.h> instead. > > Grrrrr, I used the standard autoconf macros for checking this, if I > get the time I'll try and write my own version that does what you > suggest. > > > ** checking pthread_yield... no > > This is correct, but I do have a pthread_yield_np() function, > > maybe we should look for it, too. > > It's up to the thread lib guys to use it (or not), maybe you could > hassle the authors of the thread lib you are using to provide a > standard function signature? pthread_yield is non-standard; you should use sched_yield instead (if at all). See <http://groups.google.com/groups?selm=3ecbb70c%40usenet01.boi.hp.com>

2 1

Minor preprocessor library documentation typo fixed.
by Jurko Gospodneti� 03 Sep '04

03 Sep '04

Hi all. I'm attaching a patch for a minor typo fix in the Boost preprocessor library docs. HTH, Jurko begin 666 enum_binary_params.html.diff.txt M1DE,12!#3TU005))4T].#0I0<F]D=6-E9#H@,RXY+C(P,#0@,3(Z,C0Z-3(- M"@T**BHJ(&5N=6U?8FEN87)Y7W!A<F%M<RYH=&UL(#(P,#(M,3 M,#0@,# Z M,3 Z,C N,# P,# P,# P("LM,#(P, T*+2TM(&5N=6U?8FEN87)Y7W!A<F%M M<RYH=&UL(#(P,#0M,#DM,#,@,3(Z,3@Z,C,N,# P,# P,# P("LM,#(P, T* M*BHJ*BHJ*BHJ*BHJ*BHJ#0HJ*BH@,C$L,S4@*BHJ*@T*(" )"0D\9'0^<#$\ M+V1T/@T*(" )"0D\9&0^#0H@( D)"0E4:&4@=&5X="!O9B!T:&4@9FER<W0@ M<&%R="!O9B!T:&4@<&%R86UE=&5R+B9N8G-P.PT*(" )"0D)/&(^0D]/4U1? M4%!?14Y535]"24Y!4EE?4$%204U3/"]B/B!C;VYC871E;F%T97,@;G5M8F5R M<R!R86YG:6YG(&9R;VT@/&D^,#PO:3X@=&\@/&D^8V]U;G0\+VD^("T@/&D^ M,3PO:3X-"B @"0D)"71O(&=E;F5R871E('!A<F%M971E<G,N#0H@( D)"3PO M9&0^#0H@( D)"3QD=#YP,CPO9'0^#0H@( D)"3QD9#X-"B$@"0D)"51H92!T M97AT(&]F('1H92!F:7)S="!P87)T(&]F('1H92!P87)A;65T97(N)FYB<W [ M#0H@( D)"0D\8CY"3T]35%]04%]%3E5-7T))3D%265]005)!35,\+V(^(&-O M;F-A=&5N871E<R!N=6UB97)S(')A;F=I;F<@9G)O;2 \:3XP/"]I/B!T;R \ M:3YC;W5N=#PO:3X@+2 \:3XQ/"]I/@T*(" )"0D)=&\@9V5N97)A=&4@<&%R M86UE=&5R<RX-"B @"0D)/"]D9#X-"B @"0D\+V1L/@T*(" )/&@T/E)E;6%R M:W,\+V@T/@T*(" )"3QD:78^#0HM+2T@,C$L,S4@+2TM+0T*(" )"0D\9'0^ M<#$\+V1T/@T*(" )"0D\9&0^#0H@( D)"0E4:&4@=&5X="!O9B!T:&4@9FER M<W0@<&%R="!O9B!T:&4@<&%R86UE=&5R+B9N8G-P.PT*(" )"0D)/&(^0D]/ M4U1?4%!?14Y535]"24Y!4EE?4$%204U3/"]B/B!C;VYC871E;F%T97,@;G5M M8F5R<R!R86YG:6YG(&9R;VT@/&D^,#PO:3X@=&\@/&D^8V]U;G0\+VD^("T@ M/&D^,3PO:3X-"B @"0D)"71O(&=E;F5R871E('!A<F%M971E<G,N#0H@( D) M"3PO9&0^#0H@( D)"3QD=#YP,CPO9'0^#0H@( D)"3QD9#X-"B$@"0D)"51H M92!T97AT(&]F('1H92!S96-O;F0@<&%R="!O9B!T:&4@<&%R86UE=&5R+B9N M8G-P.PT*(" )"0D)/&(^0D]/4U1?4%!?14Y535]"24Y!4EE?4$%204U3/"]B M/B!C;VYC871E;F%T97,@;G5M8F5R<R!R86YG:6YG(&9R;VT@/&D^,#PO:3X@ M=&\@/&D^8V]U;G0\+VD^("T@/&D^,3PO:3X-"B @"0D)"71O(&=E;F5R871E M('!A<F%M971E<G,N#0H@( D)"3PO9&0^#0H@( D)/"]D;#X-"B @"3QH-#Y2 896UA<FMS/"]H-#X-"B @"0D\9&EV/@T* ` end

1 0

[mpl][multi_index][intel-8.0-linux]
by Joaquín Mª López Muñoz 03 Sep '04

03 Sep '04

Newly merged MPL seems to be having problems in Intel 7.x/8.0 under Linux with BOOST_MPL_AUX_ADL_BARRIER_NAMESPACE_OPEN, as shown in http://tinyurl.com/5rj4d Appart from this, the merge is mostly working fine, as far as multi_index is concerned. There's another MPL-related problem, but it's due to a previously masked bug of mine. Congrats and thanks for the staggering effort. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

UML for templates/conepts/models
by Andreas Fabri 03 Sep '04

03 Sep '04

Hello, do you have any recommendations concerning tools and books for modelling concepts/models with UML. The last time I had a look at such tools there was no support for generic programming, but things might have evolved. Thanks in advance, Andreas

1 0

Re: IOStreams formal review start
by Michel Decima 03 Sep '04

03 Sep '04

>The latest package can be found at the following >> locations: >> >>http://home.comcast.net/~jturkanis/iostreams/ The package avalaible on this page doesn't build with gcc-3.3 on linux and darwin. There are some compilation-time warnings and errors: boost/libs/io/src/file_descriptor.cpp: In member function `void boost::io::file_descriptor_resource::open(const std::string&, std::_Ios_Openmode, std::_Ios_Openmode)': boost/libs/io/src/file_descriptor.cpp:91: error: no matching function for call to `boost::io::file_descriptor_resource::open( const char*, int&, mode_t&)' boost/libs/io/src/file_descriptor.cpp:47: error: candidates are: void boost::io::file_descriptor_resource::open(const std::string&, std::_Ios_Openmode = std::operator|(std::_Ios_Openmode, std::_Ios_Openmode)((std::_Ios_Openmode)8, (std::_Ios_Openmode)16), std::_Ios_Openmode = std::operator|(std::_Ios_Openmode, std::_Ios_Openmode)((std::_Ios_Openmode)8, (std::_Ios_Openmode)16)) boost/libs/io/src/file_descriptor.cpp:68: warning: enumeration value `_M_ios_openmode_end' not handled in switch boost/libs/io/src/file_descriptor.cpp:68: warning: case value `8' not in enumerated type `_Ios_Openmode' /boost/libs/io/src/file_descriptor.cpp:68: warning: case value `16' not in enumerated type `_Ios_Openmode' boost/libs/io/src/file_descriptor.cpp:68: warning: case value `24' not in enumerated type `_Ios_Openmode' ... you may apply the patch file_descriptor-cpp.patch to solve the problem. The link of the shared libraries fails too, because the gzip and bzip2 libraries names are wrong in the file compression.jam (the common names are libz.so and libbz2.so on unix/darwin/solaris...): darwin-Link-DyLib-action bin/boost/libs/io/build/libboost_io.dylib/darwin/debug/shared-linkable-true/libboost_io-d-1_32.dylib ld: can't locate file for: -lzlib ld: can't locate file for: -llibbz2 The patch compression-jam.patch solves the problem, but it may break your build system on other platforms (I'm not a jam file expert yet ;) MD. Vous manquez despace pour stocker vos mails ? Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com

4 11

RE: [boost] Checking if RTTI is available.
by brangdon＠cix.compulink.co.uk 03 Sep '04

03 Sep '04

In-Reply-To: <20DCDD8F0FCED411AC4D001083CF504501AA9741@MTL-EXCHANGE> sseefeld(a)art.ca (Stefan Seefeld) wrote (abridged): > Out of curiosity: why would anybody not use RTTI ? Why shouldn't > compilers without RTTI just considered broken ? It's generally more expensive than hand-rolled solutions, at least ones that don't have to cope with multiple virtual inheritance. (And I've yet to find a problem for which multiple virtual inheritance seemed like the best solution in C++.) In particular, VC++ ships with MFC, which has its own hand-rolled solution. If you use that, you may not want the overhead of RTTI. -- Dave Harris, Nottingham, UK

2 1

RE: [boost] Re: New design proposal for boost::filesystem
by Bennett, Patrick 03 Sep '04

03 Sep '04

Er, sorry, I mean Dave (I'm sure people knew who I meant). You. :) Anyway, hopefully I didn't misrepresent a statement of yours. I was referring to your message to Carlo Wood where you stated: "...I'm among them. However, I have a hard time articulating what I found difficult about the library, other than that the path portability checks seemed to get in my way. If there's something deeper going on, I'd like to hear your opinion of what it is..." It was this message that I believe I originally replied to stating that internationalization support was an issue (for my company at least). Cheers... > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Tuesday, August 24, 2004 5:00 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: New design proposal for boost::filesystem > > "Bennett, Patrick" <Patrick.Bennett(a)inin.com> writes: > > > My real issue with boost::filesystem is that as currently defined, it's > > unusable in an application that will be used around the world. My > > initial response to this whole thread was just to point out to David > > that there *are* issues preventing people from using the library. He > > didn't think there were any, so I was compelled to point out what one of > > the issues was for me at least. > > David who? > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

6 21

FC++ help!
by David Abrahams 03 Sep '04

03 Sep '04

Did anyone get familiar enough with FC++ during the review period to help me with a few simple examples? I have them in the TMP book and I can't get anything to compile! Thanks in advance, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

Re: IOStream mmap too restrictive?
by Jonathan Graehl 02 Sep '04

02 Sep '04

> > >After reviewing this, I think I spoke too soon. The above restrictions are >consistent with Posix. I had thought that mmap would allow mapping beyond >the file current size, but it seems not. One should use ftruncate to set >the size before mmap instead. > Since ftruncate isn't portable, it seems something like this (warning: untested) would be appropriate for boost::filesystem (perhaps taking a path object as an argument instead of a string - and shouldn't the Boost IO library do the same?) #ifdef _WIN32 #include <io.h> #else #include <unistd.h> #endif bool create_file(const std::string& path,std::size_t size) { #ifdef _WIN32 int fh=::_open(path.c_str(),_O_CREAT|_O_SHORT_LIVED); if (fh == -1) return false; if (::_chsize(fh,size) == -1) return false; return ::_close(fh) != -1; #else return ::truncate(path.c_str(),size) != -1; #endif } I don't see how, in Windows, to atomically keep the file open before it's mmapped, because chsize takes an int fh and the (equivalent of) mmap takes a HANDLE (maybe there is some Win32 call to get the HANDLE from the int fh?). The abstraction/interface that seems to be missing here is a low level (operating system level) file descriptor that can be passed to platform specific functions like ftruncate or _chsize, which weren't anticipated and wrapped by the higher-level libraries. I'd also like to see a constructor for mapped_file that creates a new file of exactly the required size (this might be a reasonable request for mapped_file_sink as well). It might also be nice to be able to set MAP_SHARED vs MAP_PRIVATE, or to be allowed to atomically deactivate an existing mapped_file (substituting a new backing file), guaranteeing the same address space (this is, I think, feasible if you do no allocation between munmap and mmap, and you can always detect failure by setting MAP_FIXED). I guess there's enough work left to be done for a "proper" Windows/POSIX mmap wrapper that the IO library shouldn't attempt to promote it yet.

2 4

RE: [boost] Checking if RTTI is available.
by Stefan Seefeld 02 Sep '04

02 Sep '04

> From: brangdon(a)cix.compulink.co.uk > [mailto:brangdon@cix.compulink.co.uk] > Sent: September 2, 2004 17:05 > In particular, VC++ ships with MFC, which has its own hand-rolled > solution. If you use that, you may not want the overhead of RTTI. Yeah, I noticed, MSVC is full of 'hand-rolled' 'solutions'. One more reason to avoid it. Sorry, couldn't resist. Regards, Stefan

1 0

Re: [boost] Re: [1.32 Release] MPL has been merged into the main trunk
by JOAQUIN LOPEZ MU?Z 02 Sep '04

02 Sep '04

----- Mensaje original ----- De: Eric Niebler <eric(a)boost-consulting.com> Fecha: Jueves, Septiembre 2, 2004 8:11 pm Asunto: [boost] Re: [1.32 Release] MPL has been merged into the main trunk > > > Jonathan Turkanis wrote: > > > "Eric Niebler" <eric(a)boost-consulting.com> wrote in message > > news:41374F88.9010100@boost-consulting.com... > > > >>Aleksey Gurtovoy wrote: > >> > >>>Everything has been tested locally, so the disturbance should > be minimal. > >>>I'll post a detailed changelog later today. Metacomm > regressions have > >>>been restored to run against the main trunk. > >>> > >> > >>Yikes! Where did apply_if go? The docs still talk about > apply_if. Is its > >>absence an oversight or by-design? > > > > > > Can I assume it's now 'eval_if'? > > > > If so, I like it better, since there's no temptation to confuse > apply_if and > > apply. > > > > Jonathan > > > > Oh. How do I make my code work with old versions of MPL and new? > There > is no mpl/version.hpp or a macro I can test for conditional > compilation > AFAICT. I'll have to avoid both mpl::apply_if and mpl::eval_if and > roll > my own. :-( I think you can use BOOST_VERSION in boost/version.hpp for this purpose. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Checking if RTTI is available.
by Stefan Seefeld 02 Sep '04

02 Sep '04

> From: Jurko Gospodnetiæ [mailto:jurko@zse.hr] > Sent: September 2, 2004 04:14 > Hi all. > > I was wondering if boost has any portable way for detecting whether > RTTI is enabled? (For instance a macro expanding to _CPPRTTI in > Visual Studio). If there is, I have not been able to find it. Out of curiosity: why would anybody not use RTTI ? Why shouldn't compilers without RTTI just considered broken ? Being able to switch RTTI support off just introduces binary incompatibilities and makes some code illegal (you can't cast between classes with a virtual inheritance relationship without dynamic_cast, etc.) Regards, Stefan

2 1

RE: [boost] Re: Porting to SCO Unix
by Glen Knowles 02 Sep '04

02 Sep '04

> From: David Abrahams > "Peter Dimov" <pdimov(a)mmltd.net> writes: > > > John Maddock wrote: > >>> ** checking pthread_yield... no > >>> This is correct, but I do have a pthread_yield_np() > function, maybe > >>> we should look for it, too. > >> > >> It's up to the thread lib guys to use it (or not), maybe you could > >> hassle the authors of the thread lib you are using to provide a > >> standard function signature? > > > > There is no pthread_yield in POSIX. Yields are evil anyway. ;-) > > Why evil? There's a lot of backing for this, and the best single comment is probably: ....Similarly, sched_yield() can be used to resolve some problems on a uniprocessor, though such problems can usually be solved more cleanly in other ways. Using sched_yield() will never solve a problem (unless the problem statement is "the performance is too good") on a multiprocessor, and you should never use it there. - Butenhof Glen

1 0

RE: [boost] Re: IOStreams formal review start
by Reece Dunn 02 Sep '04

02 Sep '04

Jonathan Turkanis wrote: >"Daryle Walker" <darylew(a)hotmail.com> wrote: > > On 8/28/04 8:09 PM, "Jeff Garland" <jeff(a)crystalclearsoftware.com> >wrote: > > 2. This library does what a lot of other text-I/O libraries do, try to >fit > > in "kewl" compression schemes. The problem is that the types of >compression > > here are binary oriented; they convert between sets of byte streams. > > However, characters are not bytes (although characters, like other >types, > > are stored as bytes). > >Are you saying there are problems with the implementation of the >compression >filters, e.g., that they make unwarranted assumptions about 'char'? If so, >please let me know. I'm sure it can be fixed. If you want to read a bzip2 file (for example), the bzip2 file will be a binary stream and the resulting stream will be either binary or text depending on what the compressed file stores. You can tell std::ifstream to read the stream as binary, so what is the problem? Also, you might want to convert between text and binary modes: file > bzip2 (binary) > text > (process) > bzip2 (binary) > file > > 1. Actual code using this library is very slick and easy to set up. >This > > ease of use/set-up also applies to the plug-in filters and/or resources. I also like the ability to chain filters. I have a program that uses a similar mechanism on a character tape stream that allows text to be split to a certain character length and/or merged back into one block. It would be interesting to compare the performance of using my program verses an implementation using this library. >Can I rephrase this as follows: InputFilters and OutputFilters are a useful >addition to the standard library, but Sources and Sinks just duplicate >functionality alread present? If this is not your point please correct me. > >There are two main resons to write Sources and Sinks instead of stream >buffers: > >1. Sources and Sinks and sinks express just the core functionality of a >component. Usually you have to implement just one or two functions with >very >natural interfaces. You don't have to worry about buffering or about >putting >back characters. This is similar to what iterator adaptors and flex_string do for iterators and std::strings respectively. This makes it easy to write standard conforming components. For example, if you wanted to add support for a COM-based IStream, it would be easy to implement a source and/or sink. I will post a more detailed review once I have had a better look through the documentation and library, but at the moment it looks good. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

4 14

serialization, pickling, and mersenne_twister
by Neal D. Becker 02 Sep '04

02 Sep '04

I propose to add the following to mersenne_twister, which will support both the [proposed] boost::serialization as well as any other use: Index: mersenne_twister.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/random/mersenne_twister.hpp,v retrieving revision 1.16 diff -c -r1.16 mersenne_twister.hpp *** mersenne_twister.hpp 27 Jul 2004 03:43:32 -0000 1.16 --- mersenne_twister.hpp 2 Sep 2004 16:44:07 -0000 *************** *** 133,138 **** --- 133,145 ---- return os; } + template<class Archive> + void serialize(Archive & ar, const unsigned int version) + { + ar & x; + ar & i; + } + template<class CharT, class Traits> friend std::basic_istream<CharT,Traits>& operator>>(std::basic_istream<CharT,Traits>& is, mersenne_twister& mt) For use with boost::python pickling, I considered 2 approaches. 1) Use boost::serialization. This would require providing an archive format that would archive via pickling. 2) Use an independent technique, but share the same interface "serialize". I believe #2 is the best choice. Layering pickling on top of serialization would result in duplication and inefficiency. Although #2 is a bit awkward, it is feasible. Here is an example of how to serialize mersenne_twister via the above interface, using boost::python pickle. Perhaps this technique could be made more generic. struct mt_pickle_suite : python::pickle_suite { struct Archive { struct Save { python::list result; void operator & (rng_t::result_type x[]) { python::list l; for (int i = 0; i < 2*rng_t::state_size; i++) l.append (x[i]); result.append (l); } template<typename T> void operator & (const T& x) { result.append (x); } }; struct Load { python::object entries; Load (const python::object& _entries) : entries (_entries) {} void operator & (rng_t::result_type x[]) { python::list l = python::extract<python::list> (entries[0]); for (int i = 0; i < 2*rng_t::state_size; i++) x[i] = python::extract<rng_t::result_type> (l[i]); } template<typename T> void operator & (T& x) { x = (python::extract<T>(entries[1])); } }; }; static python::object getstate (rng_t& rng) { Archive::Save ar; rng.serialize (ar, 0); return ar.result; } static void setstate(rng_t& rng, python::object entries) { Archive::Load ar (entries); rng.serialize (ar, 0); } };

1 0

Changes to numeric/ublas/vector.hpp break ublas bindings
by Matthias Troyer 02 Sep '04

02 Sep '04

Yesterday's change in numeric/ublas/vector.hp in the Boost CVS (making the pointer typedefs private) breaks the ublas LAPACK and BLAS bindings which need access to this type. Is it possible to make these types public again? Matthias

1 0

RE: [boost] Re: New design proposal for boost::filesystem
by Ben Hutchings 02 Sep '04

02 Sep '04

Beman Dawes <bdawes(a)acm.org> wrote: > At 01:53 PM 8/30/2004, Carlo Wood wrote: > > >My idea on this was (and still is) that it is possible to convert > >a relative path to an absolute path (automatically) by adding an > >absolute path object reference to the relative path object. > > Yes, as long as you know the absolute path reference. Is the absolute > path reference known for all operating systems? I'm not sure about > that. For example, there have been multi-rooted systems that didn't > have a concept of "current drive". How would that work? <snip> Further, I know of one OS that supports directories but not a current directory: Windows CE. All paths passed to its filesystem functions must be absolute.

2 1

RE: [boost] Re: IOStream mmap too restrictive?
by Ben Hutchings 02 Sep '04

02 Sep '04

Jonathan Graehl <jonathan(a)graehl.org> wrote: <snip> > I don't see how, in Windows, to atomically keep the file open before > it's mmapped, because chsize takes an int fh and the (equivalent of) > mmap takes a HANDLE (maybe there is some Win32 call to get the HANDLE > from the int fh?). <snip> You mean file descriptor, not "int fh". "File handle" usually means a FILE or FILE pointer. Anyway, file descriptors are a Unix feature emulated by many C libraries and not by Win32. The VC++ library provides the function _get_osfhandle which returns the underlying Win32 file handle for a file descriptor. Other C/C++ libraries for Windows may provide similar functions.

1 0

lambda: missing result deduction
by David Abrahams 02 Sep '04

02 Sep '04

I had to add this to get some tests for the TMP book to pass: namespace boost { namespace lambda { template<int N> struct plain_return_type_2<arithmetic_action<plus_action>, char[N], std::string> { typedef std::string type; }; }} // namespace boost::lambda Obviously this could be generalized for basic_string and for the reversed arguments. I assume it's not in the library because it forces you to #include <string>? Maybe there should be a special lambda header for each std:: type that needs deduction help? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

Get/set state in Mersenne Twister
by Neal D. Becker 02 Sep '04

02 Sep '04

In order to serialize, it would be helpful to add an interface to mersenne_twister to get/set the state. I don't think there is any I/F to get the state.

4 7

Fw: Boost in Software 2.0 Extra! magazine
by John Maddock 02 Sep '04

02 Sep '04

This one may be of interest to a some our continental developers: > Hello, > > We are currently working on an issue of our Software 2.0 Extra! magazine > devoted exclusively to C/C++ programming using crossplatform libraries. > The Boost project is widely known and its constituent libraries are used > by many programmers all over the world, so it would be great if we had > something about it in our magazine. > > Would you or anyone else from the Boost development team be interested > in writing an article on C/C++ programming with Boost for our magazine? > We can agree on a specific subject later on. > > Our magazine appears in four language versions: Polish (Poland), French > (France, Belgium, Canada), German (Germany, Austria, Switzerland) and > Spanish (Spain, Portugal) with a total circulation of about 30000. Each > issue is devoted to a different area of IT. > > Please let me know if you are interested in cooperating with us on this > issue. > > Best regards, > > Zbigniew Banach > > -- > Software-Wydawnictwo Sp. z o.o. > ul. Lewartowskiego 6, 00-190 Warszawa > tel.: +48 22 860-17-60 > fax.: +48 22 860-17-71 > www: http://www.software20.org > e-mail: zbyszek(a)software.com.pl > >

1 0

another bjam question
by Robert Ramey 02 Sep '04

02 Sep '04

When I build and run config_info using msvc-stlport I get the output below which doesn't seem correct. I get no reference to stlport. When I investigate the bjam output I find (for another test) I find that the following is being used for the command line: "cl" /Zm800 -nologo /EHsc -c -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 -D_STLP_USE_DYNAMIC_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd -I"C:\BoostMainCVS" -I"c:/Program Files/microsoft visual studio\vc98\include" -I"c:\STLport-4.5.3\stlport" -Fo"..\..\..\bin\boost\libs\config\test\no_ded_typename_fail.test\msvc-stlpo rt\debug\threading-multi\no_ded_typename_fail.obj" -Tp"..\..\..\libs\config\test\no_ded_typename_fail.cpp" This indicates that the Microsoft native include is specified BEFORE the STLPort one. This would explain why the config_info doesn't reflect the STLPort usage. Can someone tell me what I should be doing differently? Robert Ramey Microsoft Visual C++ version 6.0 _CPPUNWIND =1 __cplusplus =1 _M_IX86 =500 _WIN32 =1 _WCHAR_T_DEFINED [no value] _CPPRTTI =1 _DLL =1 _MSC_EXTENSIONS =1 _MSC_VER =1200 _MT =1 __BOOL_DEFINED =1 ********************************************************************* Dinkumware standard library version 1.x ********************************************************************* Detected Platform: Win32 Type char is signed Type wchar_t is unsigned byte order for type short =0 8 byte order for type int =0 8 16 24 byte order for type long =0 8 16 24 sizeof(wchar_t) =2 sizeof(short) =2 sizeof(int) =4 sizeof(long) =4 sizeof(size_t) =4 sizeof(ptrdiff_t) =4 sizeof(void*) =4 sizeof(void(*)(void)) =4 sizeof(float) =4 sizeof(double) =8 sizeof(long double) =8 CHAR_BIT =8 CHAR_MAX =127 WCHAR_MAX =((wchar_t)-1) SHRT_MAX =32767 INT_MAX =2147483647 LONG_MAX =2147483647L ********************************************************************* Boost version 103100 BOOST_USER_CONFIG =<boost/config/user.hpp> BOOST_COMPILER_CONFIG ="boost/config/compiler/visualc.hpp" BOOST_STDLIB_CONFIG ="boost/config/stdlib/dinkumware.hpp" BOOST_PLATFORM_CONFIG ="boost/config/platform/win32.hpp" BOOST_BCB_PARTIAL_SPECIALIZATION_BUG [no value] BOOST_DEDUCED_TYPENAME [no value] BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL [no value] BOOST_HAS_DECLSPEC [no value] BOOST_HAS_FTIME [no value] BOOST_HAS_MACRO_USE_FACET [no value] BOOST_HAS_MS_INT64 [no value] BOOST_HAS_THREADS [no value] BOOST_HAS_WINTHREADS [no value] BOOST_MSVC =1200 BOOST_MSVC_STD_ITERATOR =1 BOOST_MSVC6_MEMBER_TEMPLATES [no value] BOOST_NESTED_TEMPLATE =template BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP [no value] BOOST_NO_ARRAY_TYPE_SPECIALIZATIONS [no value] BOOST_NO_CV_VOID_SPECIALIZATIONS [no value] BOOST_NO_DEDUCED_TYPENAME [no value] BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS [no value] BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS [no value] BOOST_NO_FUNCTION_TEMPLATE_ORDERING [no value] BOOST_NO_HASH [no value] BOOST_NO_INCLASS_MEMBER_INITIALIZATION [no value] BOOST_NO_INTEGRAL_INT64_T [no value] BOOST_NO_INTRINSIC_WCHAR_T [no value] BOOST_NO_LONG_LONG_NUMERIC_LIMITS [no value] BOOST_NO_MEMBER_TEMPLATE_FRIENDS [no value] BOOST_NO_MEMBER_TEMPLATES [no value] BOOST_NO_MS_INT64_NUMERIC_LIMITS [no value] BOOST_NO_PRIVATE_IN_AGGREGATE [no value] BOOST_NO_SFINAE [no value] BOOST_NO_SLIST [no value] BOOST_NO_STD_ALLOCATOR [no value] BOOST_NO_STD_ITERATOR [no value] BOOST_NO_STD_ITERATOR_TRAITS [no value] BOOST_NO_STD_MIN_MAX [no value] BOOST_NO_STD_OUTPUT_ITERATOR_ASSIGN [no value] BOOST_NO_STD_USE_FACET [no value] BOOST_NO_STDC_NAMESPACE [no value] BOOST_NO_SWPRINTF [no value] BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION [no value] BOOST_NO_TEMPLATE_TEMPLATES [no value] BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS [no value] BOOST_NO_USING_TEMPLATE [no value] BOOST_NO_VOID_RETURNS [no value] BOOST_STD_EXTENSION_NAMESPACE =std BOOST_UNREACHABLE_RETURN(0) [no value] EXIT STATUS: 0

4 8

Compilation problem of ublas
by Matthias Troyer 02 Sep '04

02 Sep '04

Hi, Doing a cvs update of the Boost CVS I encountered a compiler bug in ublas: ...boost/boost/numeric/ublas/matrix_sparse.hpp:2556: error: no matching function for call to `boost::numeric::ublas::unbounded_array<size_t, std::allocator<size_t> >::unbounded_array() Is there a problem in the constructor of matrix_sparse, or is the missing default constructor of unbounded_array the problem? Could one of the ublas developers look into this problem? Matthias

1 0

name mangling scheme for tru64cxx65
by Markus Schöpflin 02 Sep '04

02 Sep '04

Hello! Currently, the name mangling scheme used on this platform is the default one selected by the compiler. It turns out that this is a bad choice when compiling boost. The problem is illustrated by the following example: ---%<--- #include <iostream> using namespace std; template <typename T> void foo(T const &x) { cout << "1" << endl; } template <typename T> void foo(T * const &x) { cout << "2" << endl; } int main() { foo("abc"); return 0; } --->%--- This prints out "2" with the default name mangling scheme. When manually selecting "ansi" as the name mangling scheme, the correct result "1" is printed. Therefore I propose to explicitely set the name mangling to ansi in the tools file for this compiler. Does anyone have any strong feelings or arguments against such a change? Markus

7 36

C++ random container
by AngleWyrm 02 Sep '04

02 Sep '04

A proposal for inclusion into the boost libraries: ----------------------------------------------- The hat container derives it's name from the act of pulling names from a hat. It is a container which provides random selection of it's contents, where the items can have differing probabilities, and can either be removed like cards from a deck, or come up again like rolling dice. Rationale ======= There are easy ways to generate uniform chance containers. If one wishes to roll a die, it's a simple matter of scaling a random number to the appropriate range, and then picking from an ordered set. If one wishes to draw cards from a deck, then it is also easy to place all the cards in a container and perform a random_shuffle, then take as many as desired from one end. In 1977, A.J. Walker published a method for the non-uniform first case, in "An Efficient Method for Generating Discrete Random Variables with General Distributions" to the ACM, and Donald Knuth, in his second volume of The Art Of Computer Programming, "Seminumerical Algorithms" presents an implementation of Walker's alias algorithm. This alias technique is very efficient when the probability distribution is fixed before selection, and answers a large subset of uses. It performs in constant time, once a table has been set up, which requires linear time. But there is still one class of problem left out. In the case where the distribution changes dynamically as choices are added to or removed from the set, the above technique must recalculate a lookup table for each insert/delete operation, a linear-time operation. Examples of this problem space are: Drawing lottery balls, random selection from a changing client list, or situations where a random sample is taken before all data is gathered. The hat container provides a solution for all four of the above scenarios: uniform and non-uniform distributions, both with and without replacement. Furthermore, it performs these functions with a time complexity of O( log n ). -:|:- AngleWyrm hat container and documentation at http://home.comcast.net/~anglewyrm/hat.html

4 3

RE: Serialization questions
by Robert Ramey 02 Sep '04

02 Sep '04

> Hello again, > > I have started using your serialization library. It is working pretty > well, but I have run into a few small problems: > > 1) No serialization for bitset: No big deal, because I can just > convert to ulong, but I was surprised it wasn't there. Feel free to add it in along with a test. I would like to see people adding serialization bit by bit to the existing data structures as the need becomes apparent. We're coming to the view that these things should be added to the data structures themselves rather than the serialization library. I'm trying to get myself out of the business of serializing things. > > 2) I have a text archive with a bunch of pairs of strings. I want to > append another pair. There doesn't seem to a way to append items > to an archive. LOL - an interesting question that only recently - (in the last couple of months) occurred to me. There is no reason that you can't create an archive and just append to it as many times as you see fit. Oa << t; ... Oa << t; EXCEPT that the t (and its constituents) should have its serialization trait set so that memory tracking is turned off. Otherwise, copies subsequent to the first one won't copy any data - just a pointer to the original. I have considered making and testing an example of such a thing, but I've been busy. To support this and make a good example what is really needed is: a) another archve construction flag - "no_tracking" to suppress memory tracking for the archive regardless of the setting for each individual type. b) serialization added to boost::any and/or boost::variant. Probably doable but maybe a little tricky. In this way one could just save willy-nilly anything to the archive and load later. This would be very interesting for things like database transaction logs which want to implement rollback/rollforward and things like that. It would also make a dynamite log for debugging. Again, feel free to explore this at your leisure. > 3) similarly, if I'm reading items from an archive, there is no simple > way to keep reading until the end of the file. I have to catch the > exception, which seems wrong for such an unexceptional > circumstance. Setting a fail bit as with streams would be nicer. Checking the fail bit on the stream before reading the next archived item should work. It's intended to anyway. If it doesn't work it's a bug. There might be a little tweaking required as I didn't test for this specifically. If you try this and it doesn't work and you find the oversight let me know and I'll add the fix. Better yet, make and test a small test and submit it to me and I'll add it into the test suite. > However, you could take the view that you should always know what > is in the archive, and to have a method of failure that does not > throw an exception would invite errors. That suggests that a > constructor flag might work (e.g. throw_on_eof default to true). I recently discovered that one can set a flag on an input stream so that an attempt to read past eof will throw an exception. This would leave all options open. After learning ths I'm considering removing the code that checks the fail bit as I would like to leave the flexibility for the user and make the serialization library smaller. BTW the fail bit means - "the next operation is expected to fail", NOT "the last operation failed". This confused me for quite a while until I actually carefully read the documentation for stream rather than presuming what I thought was obvious. > 4) A minor point: It would be nice to be able to construct an archive > with a boost::filesystem::path, instead of creating an fstream and > then using that to create the archive. It is certainly nice that I > can attach an existing stream to an archive, but directly using a > path would reduce some clutter. It would also make it a little > safer, because I couldn't accidently insert something into the > stream that was not serialized. Feel free to make your own - it should be trivial exercise. It should be easy to do deriving from any of the current archives. Polymorhphic archive works this way. Its one template that "adapts" any archive it's applied to. Also the current setup is specifically designed to permit serialized data to be embedded within some other data stream if the user requires it. I haven't specifically tested this either. > I have read large parts of the discussions when you were submitting > your library, but not all. If I have missed something, you can just > point me to it. Seems like you've pretty much got it. The thing that takes special care is the serialization of pointers through abstract base pointers. This works fine but there are a couple of non-intuitive aspects that can trip you up. The manual is pretty complete. This is mostly because I kept adding to it as questions kept coming up on the list. So I would hope that one can understand and use the package without going back and trolling through the list. If you don't mind, I'm posting this to the list. Your questions are interesting, good grist for the list, and help diminish the frequency of the same questions getting asked multiple times. Robert Ramey

2 1

IOStream mmap too restrictive?
by Neal D. Becker 01 Sep '04

01 Sep '04

"Files must exist before being opened, and are never truncated; attempting to write past the end of a file results in an error. " This is quite restrictive, compared to the capabilities of posix mmap. Are these restrictions really necessary?

2 3

lambda; ->*
by Goran Mitrovic 01 Sep '04

01 Sep '04

Is it normal that boost lambda's member pointer operator fails on member functions that have throw() modifier? Compiler is VC7.1. Is there a solution?

1 0

integer tests not working on 64 bit platforms
by Markus Schöpflin 01 Sep '04

01 Sep '04

Currently the integer tests report an error on 64 bit platforms, as can be seen on http://tinyurl.com/6whtg The following code in integer_test.cpp causes the problem: PRIVATE_FIT_TESTS( int_t, least, long, LONG_MAX ); PRIVATE_FIT_TESTS( int_t, fast, long, LONG_MAX ); PRIVATE_FIT_TESTS( uint_t, least, unsigned long, ULONG_MAX ); PRIVATE_FIT_TESTS( uint_t, fast, unsigned long, ULONG_MAX ); The first line expands to: do { long v = LONG_MAX ; PRIVATE_FIT_TEST(int_t, 32, least, v); v >>= 1; PRIVATE_FIT_TEST(int_t, 31, least, v); v >>= 1; ... } which becomes: do { long v = LONG_MAX ; BOOST_TEST( int_t < 32 > :: least ( v ) == v ); v >>= 1; BOOST_TEST( int_t < 31 > :: least ( v ) == v ); v >>= 1; ... } which of course alway fails on 64 bit platforms because LONG_MAX is a 64 bit number. A possible fix would be to start the test with 64 bit and not 32 on 64 bit platforms. But how can 64 bit platforms be detected? Probably with #if (LONG_MAX > INT_MAX) ... #endif or something like this. Another fix (which ignores 64 bit values alltogether) would be to change the lines above to not use long and LONG_MAX but int and INT_MAX. Opinions, anyone? Markus

3 2

Boost::Python exception translation not working?
by Dan 01 Sep '04

01 Sep '04

I attempted a simple exception translation that was almost an exact copy of the examples in the docs. struct MySQLException : public std::exception { MySQLException( const char * what = "MySQL Exception" ) : std::exception( what ) {} }; And then in a class's default constructor I throw this exception. I tried exposing it as both a function and a functor: void mysql_translate( MySQLException& e ) { PyErr_SetString( PyExc_RuntimeError, e.what() ); } BOOST_PYTHON_MODULE(pymysql) { // regular expression translation py::register_exception_translator< MySQLException >( &mysql_translate ); } And... struct mysql_translate { void operator ()( const MySQLException& e ) const { PyErr_SetString( PyExc_RuntimeError, e.what() ); } }; BOOST_PYTHON_MODULE(pymysql) { // regular expression translation py::register_exception_translator< MySQLException >( mysql_translate() ); } Both had the same result when I created the exported object. "RuntimeError: unidentifiable C++ exception". What am I doing wrong? Thanks, -Dan

2 4

Re: [boost] CodeWarrior and alignment_of (help!)
by JOAQUIN LOPEZ MU?Z 01 Sep '04

01 Sep '04

----- Mensaje original ----- De: Doug Gregor <dgregor(a)cs.indiana.edu> Fecha: Miércoles, Septiembre 1, 2004 6:46 pm Asunto: [boost] CodeWarrior and alignment_of (help!) > Some of the Graph tests are failing on CodeWarrior due to some > strange > interaction within alignment_of, where it doesn't like > mpl::size_t. I > don't have the compiler to test on :( > > Here's one example of the failures: http://tinyurl.com/4dapg > I think current results are built from a CVS merge in progress by Aleksey, and as such one shouldn't pay them too much attention until they're stabilized. The particular problem you refer to has to do (I think) with some haeder making the symbol size_t ambiguous; this pops with variations in other tests. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

tuple and std::set question
by Trey Jackson 01 Sep '04

01 Sep '04

All, I was trying to use the tuple in a set, and the STL complained about not having an operator&() - I think. My question is, is tuple supposed to be usable in a set? I read the STL docs: no mention of operator&() required. I tried both STLport and gcc's stl. I'm using gcc 3.2.2, and the snippet of code is real easy: ,---------------- | #include <boost/tuple/tuple.hpp> | #include <set> | | using namespace std; | | using namespace boost; | | int | main(int, char *[]) | { | typedef tuple<int, int, int> Things; | | std::set<Things> mySet; | | Things oneThing(1,2,3); | mySet.insert(oneThing); | | return 0; | } `---------------- tia, TJ -- Trey Jackson tjackson(a)ichips.intel.com "Nobody can give you wiser advice than yourself." -- Cicero

2 2

Nightly CVS documentation
by Jurko Gospodneti� 01 Sep '04

01 Sep '04

1 0

regression tests broken?
by Bronek Kozicki 01 Sep '04

01 Sep '04

I'm no longer able to run regression tests, and quick look at ftp://fx.meta-comm.com/boost-regression/CVS-HEAD/ reveals that few others have this problem too. Apparently bjam is called from regression.py in wrong way, or Jamfile is broken, as bjam.log ends with: don't know how to make None don't know how to make -sALL_LOCATE_TARGET=C:\MinGW\Bronek\boost\results ...found 2 targets... ...can't find 2 targets... B.

3 5

Re: [boost] IOStreams formal review start (memory-mapped files)
by Jonathan Graehl 01 Sep '04

01 Sep '04

Generally: four stars, two thumbs up, and a partridge in a pear tree. I'm interested in directly using the Windows/POSIX mmap portability wrapper; might we promote it out of the detail namespace? That is, I may want to use mmap to perform some explicit memory swapping/caching. It looks like I could first create a file of the desired size, then acquire a mapped_file_resource - but then I don't get access to the actual pointer to memory (it's hidden in the private _pimpl). This is fine; what I really want is a portability wrapper for mmap :) Thanks, Jonathan

2 1

Problems with Boost.Random docs
by Daryle Walker 01 Sep '04

01 Sep '04

* BOOST_ROOT/libs/random/random-misc.html Mentions "generator_iterator" at the top, but there's nothing else about it. Does it have to be a secret that "random_number_generator" can now be accessed in its own header ("random_number_generator.hpp")? The web page still places it in "random.hpp" (which does include the previous header). I just noticed that "random.hpp" doesn't mention anything about a generator-iterator either. * BOOST_ROOT/libs/random/random-distributions.html Mentions that users that want an iterator interface should just put an adaptor over the existing generator interface. That sentence gives a link to the Iterator Adaptor library, instead of its own generator-iterator (which I guess is good in a way since it's MIA). There's a problem with this arrangement: * BOOST_ROOT/libs/iterator/doc/index.html Of its list of specialized adaptors, there's is NO generator adaptor! (There is an adaptor that goes the other way, i.e. output iterator to unary function, but we need generator to input iterator.) The sum up, it looks like the Random guys dumped their private generator adaptor for iterators, expecting the Iterator guys to replace it, but the latter guys never did. Unless the generator adaptor is hidden somewhere else, can someone add it (back). BTW, a generator would have to support a Boolean conversion where TRUE means it's still usable and FALSE means it isn't. (This is a new semantic for generators.) This would allow a reasonable way to implement the end-input-iterator. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[type_traits] function_pointer_traits extension
by Tobias Schwinger 31 Aug '04

31 Aug '04

I'll continue this discussion (previously in private email) on the boost mailinglist, in order to allow others to join in. Any critiques (i.e. having a look at the (comparatively small) submission and dropping me a couple of lines) are still very welcome, in fact ! Alexander Nasonov wrote: >>>[... char array in struct as sizer for type classification via overload resultion ...] >>> >>Good point. This will be changed. >>By the way: the same hack is in the current boost release >>[boost/type_tratis/function_traits.hpp:177]. >> >> >> This has been changed [ref. 5.3.3]. >>> // tester returns a reference to an array >>> template< /* ... */ > >>> char (& tester( /* ... */ ) ) [size]; >>> >>> This would have been my personal preference. Unfortunately this causes bcc to fail with an 'Internal compiler error'. >>>or making it a meta-function >>> >>> template<std::size_t Size> >>> struct sized_type >>> { >>> typedef char (&type)[Size]; >>> }; >>> >>>and using typename sized_type<Size>::type in place of sized_type<Size>. >>> >>> >>> This is the current, but not necessarily the best implementation. Comments ? I believe this could be a common issue - for that matter: What about a type synthesizer like 'type_with_size<size_t>::type' or a 'BOOST_TYPE_WITH_SIZE(n)' macro ? Or even: BOOST_SIZED_RESULT_TYPE_OVERLOAD_PROTO(template_args,function_args,size_expression). Is there something like this in boost somewhere, already ? >>>The example compiles fine on g++ 3.2.2, g++ 3.4.0 and Intel 8.0 under linux. >>>I didn't check that BOOST_STATIC_ASSERT covers all cases but non-empty >>>output looks suspicious for metaprogramming library ;-) >>> >>> >>> The static assertion just aids keeping the errors where they belong. If it doesn't work there is a more obscure error message and one has to read the manual for proper usage. The documentation has been updated (Intel 8.0 is listed as tested and your work has been acknowledgeded). >>>I appreciate your efforts in boostifying function traits. Keep doing! >>> >>> >>I sure will ! >> >>Thanks a lot for your work, ideas and the very nice mail - despite the >>fact of having no time, that is ! >> >> > >Have you considered wrapping function signature into mpl sequence? > > Currently function_signature<T>::type is an mpl::vector and therefore a model of sequence. I believe I don't understand you correctly. In general, I aim to keep it as 'pure' as possible, so any conveniene feature should outweigh its cost in terms of code complexity , compilation time and maintainability. Tobias

3 6

Review Wizard Status Report
by tom brinkman 31 Aug '04

31 Aug '04

Review Wizard Status Report 1) Summary 2) Review Managers Needed 3) Review Schedule 4) Libraries under development //////////////////////////////////////////////////////////////////// 1) Summary //////////////////////////////////////////////////////////////////// Daryle Walker's library "More IO" is currently under review, starting August 21, 2004. Download the library at: http://boost-sandbox.sourceforge.net/more_io_4.zip. Please post a review of this library if you have not already done so. For information about submitting a Formal Review, see http://www.boost.org/more/formal_review_process.htm. The next library to be reviewed is Jonathan Turkanis "IOStreams" library. The "Iostreams" library allows the easy creation of standard C++ streams and stream buffer classes for new data sources and sinks. Download the library at: http://home.comcast.net/~jturkanis/iostreams. Be prepared to review this library in the next few days. If there are no objections, starting with the "More IO" library, I will attach an ID number to each reviewed library. Please reference this ID number in any postings to the group. This will help in organizing the reviews and assist in searching for related postings. I've also added a permanent section to this status report, called "Libraries Under Development". The purpose of this section is to prevent duplication of effort and support collaberation between library authors. Please contact me to add libraries to this section. Note: If you have any suggestions about how I could improve the Review Wizard's status report, please email me at reportbase(a)yahoo.com. //////////////////////////////////////////////////////////////////// 2) Review Managers Needed //////////////////////////////////////////////////////////////////// If you would like to volunteer to be a review manager, please contact me at reportbase(a)yahoo.com. The following libraries still require review manager volunteers: 10006 - Named Parms 10007 - Policy Pointer 10008 - Wave 10009 - Finite State Machine (FSM) 10010 - Fixed Strings //////////////////////////////////////////////////////////////////// 3) Review Schedule //////////////////////////////////////////////////////////////////// August 21, 2004 10001 - More IO (Currently Under Review) August 28, 2004 10002 - Iostreams September 7, 2004 10003 - Output Formatters September 15, 2004 10004 - Mini-Review wiki algorithims September 17, 2004 10005 - Smart Containers September 27, 2004 10006 - Named Params October 6, 2004 10007 - Policy Pointer October 16, 2004 10008 - Wave October 26, 2004 10009 - Finite State Machine (FSM) November 4, 2004 10010 - Fixed Strings 10001 - August 21, 2004 More IO (Currently Under Review) 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 10002 - August 28, 2004 Iostreams Author - Jonathan Turkanis - turkanis(a)kangaroologic.com Review Manager - Jeff Garland - jeff(a)crystalclearsoftware.com 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. 10003 - 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. 10004 - September 15, 2004 Mini-Review wiki algorithims Author - Various Review Manager - Tom Brinkman - reportbase(a)yahoo.com Download: to be determined Description: not available 10005 - September 17, 2004 Smart Containers Author - Thorsten Ottosen - nesotto(a)cs.auc.dk Review Manager - Pavol Droba - droba(a)topmail.sk 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. 10006 - 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); 10007 - 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. 10008 - 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 SO/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). 10009 - October 26, 2004 Finite State Machine (FSM) Author - Andreas Huber - ah2003(a)gmx.net Review Manager - to be determined Download: http://boost-sandbox.sf.net/fsm.zip Documentation: http://boost-sandbox.sf.net/libs/fsm Description: The boost::fsm library is a framework that allows you to quickly transform a UML state chart into executable C++ code, without needing to use a code generator. Thanks to support for almost all UML features the transformation is straight-forward and the resulting C++ code is a nearly redundancy-free textual description of the state chart. 10010 - 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. //////////////////////////////////////////////////////////////////// 4) Libraries under development //////////////////////////////////////////////////////////////////// 10011 boost::xpressive - Under Development Author: Eric Niebler (eric(a)boost-consulting.com) Download: Boost sandbox at sourceforge.net Description: Advanced regular expression template library that allows regexes to be written as expression templates (statically bound) or as strings (dynamically bound) and allows regexes to nest and call each other recursively (like perl6) and bind to semantic actions (like Spirit). Development status: Under active development. Basic functionality in place. 10012 boost::geometry2d - Under Development Author(s): Aleksey Gurtovoy Description: simple cartesian geometry classes (point<>, rectangle<>, etc.) Download: yahoogroups files section, geometry2d/ Development status: basic functionality working Tom Brinkman Boost Review Wizard reportbase(a)yahoo.com

7 12

RE: [boost] Re: Re: Review of Daryle Walker's "More IO" librarybeginstoday, August 21, 2004.
by Reece Dunn 31 Aug '04

31 Aug '04

Jonathan Turkaniswrote: >"Rob Stewart" <stewart(a)sig.com> wrote in message >news:200408262114.i7QLEOP14442@lawrencewelk.systems.susq.com... > > From: "Jonathan Turkanis" <technews(a)kangaroologic.com> > > > - multi_skipper: I'm not sure I see why this is needed; how > > > often do you need to skip a sequence of repeated characters? Id rather > > > > When parsing, it is often useful to ensure that there were > > exactly 10 spaces between one token and the next, for example. > >I'll take your word for it, but an example would help. I am used to just >worrying about whitespace. Haskell uses whitespace to associate code on the right of the whitespace with the code on the left. e.g. [haskell.hs] factorial x = fimpl x where fimpl 0 = 1 fimpl x = fimpl ( x - 1 ) * x power (x:xs) = power xs * x power [] = 1 [end] where [] is an empty list and (x:xs) is a list with x as the head and xs as the tail. In this example, fimpl is associated with factorial and is only visible in its scope. factorial and power (both patterns) are in global scope. When writing a Haskell lexer, you need to be aware of the number of space characters after a given new-line. Therefore, something like multi_skipper would be useful, but it would need to: [1] reset an internal nspace variable on recieving a new-line character, allowing read access to it by the lexer; [2] incrementing by n (where n=3,4 or 8) upon recieving a tab character; [3] incrementing by 1 when recieving a space character I am not sure how the above could be implemented using multi_skipper, but this is an example where the number of spaces is important. Another example would be in padding. For example, the TAR file format ensures that each file fills a number of blocks of 256 bytes, so you need to skip the remaining bytes at the end of each file. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

3 3

RE: [boost] Re: [Boost.Test] New testing procedure?
by Rozental, Gennadiy 31 Aug '04

31 Aug '04

> FYI, if there are no files in that directory of the > repository, cvs will generally not create the directory on > update/checkout. Not sure what's happening here, but you > might just have to add a dummy file to ensure it gets created. This directory have some files already. > That said, Boost tests should be able to be run from a > read-only CVS tree, so if you're creating files you probably > ought to do it elsewhere (like /tmp/...). Could you show how to do this portably? Gennadiy.

2 1

toolset proliferation
by Robert Ramey 31 Aug '04

31 Aug '04

I would like to see a little more order/organization in the creation of new toolsets. For example in the current CVS we have for Codewarrior Cw Cw-9.2 Cwpro-9.2 Cw-8.3 Cwpro-8.3 This is only an example. The same problem is occurring in gcc and mingw It creates a couple of problems a) we're not all testing with the same Jamfile. This leads to a lot of confusion. b) If I have a jam file which needs special treatment for a particular compiler, I have to included a line for each toolset - and that can change in the future creating another obscure bug to track down. c) The documentation on the "getting started" page is way out of sync with the toolsets in existences. A somewhat related problem - or maybe the cause of the above is the fact that the Jamfile doesn't have access to the compiler version. I'm not sure what to do about this. But, here's a suggestion for consideration to start the discussion. Right now we pass a variable to bjam with the toolset name. e.g bjam -sTOOLS=cwpro-9.2 How about the idea Bjam -sTOOLS=cw -sCOMPILER_VERSION=9.2 -sSTD_LIBRARY=stlport The "base" toolset would fill in variables COMPILER_VERSION and STL_LIBRARY_VERSION with defaults - probably the currently shipping version. Or a "base" toolset could require one or the other of the above switches. Also the "base" toolset could include a "config_check" target what would double check that compiler version invoked is the same as the one that is specified by the switch. This would catch the case where one has one compiler in his path and tries to build for another. This would have the following advantages: a) a smaller number of toolsets b) a greater likelihood that we're all testing the same thing c) documentation more likely to be insync with the actual toolsets available The recently re-organized stlport.jam "add-in" with all stlport stuff factored out so it can be "added-in" to any library is a good idea. Unfortunately it has a bug but that's fixable. This would allow us to specify usage of STLPort (or any other library) without creating a new toolset. I guess we sometimes use: bjam "-sTOOLS=cwpro-9.2 msvc" to handle multiple compilers in one shot. If its important to keep this feature then we could use Bjam "-sTOOLS=cw msvc" "-sCOMPILER_VERSION=cw-9.2 msvc-6.0" -sSTD_LIBRARY=cw-stlport or something similar. Just a small suggestion to keep the pot boiling. Robert Ramey

2 1

[multi_index] Question about 'modify'
by Vladimir Prus 31 Aug '04

31 Aug '04

I have a question about the 'modify' method of ordered indexes in the multi_index library. I have an iterator obtained from an ordered index and would like to modify the pointed element. I'm pretty sure that the modification won't change the order, won't create collisions and so on. The documentation suggests to use either 'replace', or more efficient 'modify' method. Why can't I do the following: typedef variables_t::nth_index<1>::type index_t; index_t& index = variable_declarations.get<1>(); index_t::iterator existing = index.find(vd); const_cast<Variable_declaration&>(*existing) .make_external(); ? TIA, Volodya

2 3

user defined facets in date_time library
by Markus Schöpflin 31 Aug '04

31 Aug '04

While trying to make date_time tests compilable on tru64cxx65, I have come accross an issue with user defined facets (namely date_names_put and all_date_names_put) that leaves me scratching my head. Is a user defined facet required to be default constructible? Or does it need a constructor of the form "foo(size_t refs = 0) : locale::facet(refs) {}"? [lib.facets.examples] doesn't say so but most examples I could find either have a default constructor or a constructor taking a reference count. Markus

2 3

copyright question (bjam examples)
by John Maddock 31 Aug '04

31 Aug '04

Some of the examples in bjam v2 are actually taken verbatim from the QT libraries examples, and currently have no copyright or license declaration on them at all. Vladimir asks: "Will /* This file is part of Qt and is available under the Q Public License, available from http://doc.trolltech.com/3.3/license.html */ be enough to make inspect tool happy. If we're really going to be extra-picky, I don't think I can add any "Copyright" string to the file I don't own." Is adding such a string acceptable? Clearly we need to do something, but what? Thanks, John.

4 4

Something odd with the meta-comm tests?
by David Abrahams 31 Aug '04

31 Aug '04

It looks like some of them are being run against the mplbook branch of boost/mpl. How else to explain the lack of mpl/aux_/has_xxx.hpp reported in http://tinyurl.com/524ur? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

RE: [boost] Re: Review Wizard Status Report
by Glen Knowles 31 Aug '04

31 Aug '04

> From: David B. Held > David Abrahams wrote: > > > [...] > > What is the point of these IDs? It seems like it adds busywork for > > reviewers and no especially useful information. Now we're talking > > about making them more complicated... > > Maybe they have to do with a nagging feeling that Boost > Libraries don't all have a canonical name, and even when it > seems like they do, people tend to call them whatever they > feel like. Perhaps we should either go with a numerical > index (which the DBA in me prefers), or insist that all > libraries have a canonical name and that everyone use that > name to refer to it (perhaps to make it easier to filter > messages containing the name). There is also the case of a library having multiple reviews, the serialization library comes to mind. Glen Knowles Centor Software Corporation

2 1

Is boost::fsm suitable for embedded systems?
by Thomas Stevens 31 Aug '04

31 Aug '04

Hi, forgive me for my ignorance but I'm a boost newbie... The rationale document for boost::fsm states that the library should meet a number of requirements, numbered from 1 to 9. Especially, the sixth requirement says "support the development of arbitrarily large and complex state machines.". Ok, this may be good - I guess it is in fact good. But I'm a bit anxious that this implies that the library is therefore not suitable for enviroments where no unnecessary overhead is acceptable, like in many embedded applications. However, the seventh requirement indicates that my worries are unjustified since it reads: "allow the user to customize all resource management so that the library could be used for applications with hard real-time requirements". And further down the Rationale document one can read a section on the Resource usage of Memory which looks good. So, just to be sure, is boost::fsm suitable for the development of embedded applications where constraints such as memory footprint is an issue? (Hopefully, someone can answer this based on the experience of using the library or by knowing the code - not by reading the documentation (like me ;-)). Thanks, Thomas S.

4 7

VC8.0 and std::list
by Pavol Droba 31 Aug '04

31 Aug '04

Hi, I have encountered a problem with vc8.0 std library. I was able to fix it, but I'm not sure what is correct according to standard. The problem can be narrowed to one simple case. In vc8.0 method iterator std::list<>::erase(iterator First, iterator Last) returns a 'singular' iterator when the list is empty after erase operation. Because I'm dependant on the returned iterator to make insertion at this point later on, I had to make an explicit workaroud. I would expect it to return .end() iterator in this case. Is this behavior correct according to standard or not? If not, is it reasonable to submit bug report? Thanks, Pavol

3 3

Workflow, process flow, mapping of an activity diagram to code.
by Batov, Vladimir 31 Aug '04

31 Aug '04

In my spare time I've been fooling around with an implementation of an infrastructure that would allow workflow to be configured at run-time. A well-defined process flow is clearly easier to configure/implement at compile-time using the conventional means (coding). Say, bool my_process_flow() { if (call_a() == success/true) { return call_b(); } else { return call_c(); } } However, to be able to quickly adjust to changing customer requirements and/or procedures we might decide to provide a set of building blocks (like call_a, call_b, call_c) that could be assembled into a certain process flow at run-time. Maybe even give that ability to the customer themselves through, say, GUI interface. So, the infrastructure boils down to an Activity class that has an operation associated with it and can have two sub-activities to be called when the operation succeeds or fails. For example, // Create an activity with call_a() as an operation. Activity a(call_a); // Register call_b to be called when call_a succeeds. a.success() = call_b; // Regiter call_c to be called when call_a fails. a.failure() = call_b; call_a, call_b, call_c can be Activity instances themselves. So, we are building hierarchical tree-like structure to represent a certain process flow. We can easily support concurrent activities like a.success() = Concurrent(call_b)(call_c); Loops can be supported in a similar fashion (via pre-defined functiors). All mostly based on boost::function (a very handy gadget I must say. Kudos to the authors). Now after such a long and boring introduction to my actual question. :-) Is there any interest in having/developing such an infrastructure under the boost umbrella? Any input is welcomed even if you think it is a crappy idea. Best, Vladimir.

2 1

Boost License Permission
by Fernando Cacciola 31 Aug '04

31 Aug '04

I, Fernando Luis Cacciola Carballal (Fernando Cacciola for short) give permission for all my contributions to Boost to be moved to the Boost Software License Version 1 P.S.: Odd that I need this since I have my name added to blanket_permission.txt, but I recieved the email so just in case. Fernando Cacciola SciSoft

2 1

[format] patch for tru64cxx65
by Markus Schöpflin 31 Aug '04

31 Aug '04

Hello, attached is a patch which makes the format tests compile on tru64cxx65. It turns out that the compiler has troubles with the following code snippet: ---%<--- template <class X> class foo; namespace detail { template<class X> void bar (foo<X>& self); } template<class X> class foo { public: template<class Y> friend void detail::bar(foo<Y>&); }; --->%--- This gives the following error message: cxx: Error: /usr/users/schoepf/net/tmp/test_namelookup.cpp, line 13: declaration is incompatible with function template "void detail::bar(foo<X> &)" (declared at line 5) friend void detail::bar(foo<Y>&); ----------------------^ There are several possible workarounds I found, namely moving bar() out of the detail namespace, or making bar() a simple member of foo (not a member template), or just removing the friend declaration alltogether. I decided to use the latter workaround as it is already present in the format library for other compilers. Markus Index: format_class.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/format/format_class.hpp,v retrieving revision 1.21 diff -u -r1.21 format_class.hpp --- format_class.hpp 1 Feb 2004 14:57:09 -0000 1.21 +++ format_class.hpp 31 Aug 2004 09:11:02 -0000 @@ -83,7 +83,8 @@ #if !defined( BOOST_NO_MEMBER_TEMPLATE_FRIENDS ) \ && !BOOST_WORKAROUND(__BORLANDC__, <= 0x570) \ - && !BOOST_WORKAROUND( _CRAYC, != 0) + && !BOOST_WORKAROUND( _CRAYC, != 0) \ + && !BOOST_WORKAROUND(__DECCXX_VER, <= 60590041) // use friend templates and private members only if supported #ifndef BOOST_NO_TEMPLATE_STD_STREAM

1 0

New option for regression.py
by Markus Schöpflin 31 Aug '04

31 Aug '04

Hello. I have done a patch for regression.py which adds a new option '--test-options'. I needed this to pass options to the actual test run. For example: python regression.py --toolset=tru64cxx65 --test-options='-sPYTHON_VERSION="2.3" -sPYTHON_ROOT="/opt" -sPYTHON_INCLUDES="/opt/include/python2.3 /opt/exec/OSF1-V5.1-alpha/include/python2.3"' Any interest in this? Markus

6 11

[admin] Mail archive looks 'stuck'
by Jeff Garland 31 Aug '04

31 Aug '04

Not sure who's in charge of this, but the archive page looks as though it's recording any longer. Last recorded email was from this morning: http://lists.boost.org/MailArchives/boost/bydate.php Jeff

1 0

Re: Re: Re: Review of Daryle Walker's"MoreIO"librarybeginstoday, August 21, 2004.
by JOAQUIN LOPEZ MU?Z 30 Aug '04

30 Aug '04

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Sábado, Agosto 28, 2004 9:27 pm Asunto: [boost] Re: Re: Re: Review of Daryle Walker's"MoreIO"librarybeginstoday, August 21, 2004. > > "Pavel Vozenilek" <pavel_vozenilek(a)hotmail.com> wrote in message > news:cgpgmb$gla$1@sea.gmane.org... > > > > "Jonathan Turkanis" wrote: > > > > > Yes, I think skip_line/skip_lines is a good combination. > > > > > > I like newline and newlines. > > > > > It is often recomended not to distinguish names only > > on plural suffix. Easy to overlook bug here. > > I know that's a consideration. But then there's tuple and tuples... > Boost.Tuple's authors would have used "tuple" alone everywhere but they found difficulties, as explained at: http://boost.org/libs/tuple/doc/design_decisions_rationale.html section "For those who are really interested in namespaces". Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

RE: [boost] Copyright and License in XML documentation
by Reece Dunn 30 Aug '04

30 Aug '04

Jeff Garland wrote: >I found a few moments to work on cleaning up licensing issues and decided >to >go make sure all the date_time xml docs have licensing info. The problem >is, >how should the copyright be added to all the files? I hunted around in >other >libraries using boostbook and it looks like they all lack copyright and >license info in all but the top level xml file. I notice that in the >library >main file we correctly notice the following construct in the inspection: > ><libraryinfo> > <author> > <firstname>Jeff</firstname> > <surname>Garland</surname> > </author> > > <copyright> > <year>2001</year> > <year>2002</year> > <year>2003</year> > <year>2004</year> > <holder>CrystalClear Software, Inc</holder> > </copyright> > > <legalnotice> > <para>Subject to the Boost Software License, Version 1.0. (See >accompanying file > <filename>LICENSE_1_0.txt</filename> or copy at <ulink > >url="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</ulink>)</para> > </legalnotice> > > <librarypurpose>A set of facilities to ease programming with dates and >times. > </librarypurpose> > <librarycategory name="category:misc"/> ></libraryinfo> This is so that the legal notice can be rendered in the introduction page of the library documentation. >So it seems one option would be to change the boostbook schema and allow >copyright and legal notice elements in each file. The other possibility >would >be to add this as a comment: > > > >Thoughts on how best to approach this? I think the best approach would be in a comment, since adding copyright markup to each file would require adding code in the XSLT files to prevent it from being rendered. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

3 2

VC8.0 and algorithm/string/replace failure
by Victor A. Wagner Jr. 30 Aug '04

30 Aug '04

I compiled replace_test with vs.net2005 and debugged it. It clearly throws an exception, and re-throws it later from the test framework, which causes the "ask to terminate abnormally" message. BUT............ the output window has the following in it _before_ the exception is thrown: error: list iterators incompatible, at g:\program files\microsoft visual studio 8\vc\include\list: 283 I'm not sure why it thinks the iterators are incompatible, but.... it might help the author(s) to have the above error mentioned in the failure log (I don't know why it's not there) Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

4 7

[inspect] Status...
by Rene Rivera 30 Aug '04

30 Aug '04

Just updating on the current status from the inspection tests... 8105 files scanned 680 directories scanned 184 problems reported problem counts: 2 files with invalid line endings 0 bookmarks with invalid characters 1 invalid urls 72 broken links 46 unlinked files 59 file names too long 4 files with tabs Of interest in those... libs/thread/test/Jamfile: invalid (cr only) line-ending libs/graph/example/fibonacci_heap.cpp: tabs in file libs/range/test/partial_workaround.cpp: tabs in file libs/serialization/test/test_utf8_codecvt.cpp: tabs in file libs/spirit/test/distinct_tests.cpp: tabs in file 8105 files scanned 680 directories scanned 4397 problems reported problem counts: 2970 files missing Boost license info 1427 files missing copyrights -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

2 1

Re: Your copyright in the Boost C++ Libraries (second try)
by Christian Engström 30 Aug '04

30 Aug '04

I Christian Engström, give permission for all my contributions to Boost to be moved to the Boost Software License Version 1. Christian Engström John Maddock wrote: > Hi, if you are receiving this reminder again it is because there are > one or more > files in the Boost C++ libraries that contain your copyright declaration. > [...]

1 0

Fw: Your copyright in the Boost C++ Libraries (second try)
by John Maddock 30 Aug '04

30 Aug '04

And another permission: ----- Original Message ----- From: "Nicolai Josuttis" <nico(a)josuttis.de> To: "John Maddock" <john(a)johnmaddock.co.uk> Cc: <boost-owner(a)lists.boost.org> Sent: Sunday, August 29, 2004 2:44 PM Subject: Re: Your copyright in the Boost C++ Libraries (second try) > Hi John, > sorry for not answering immediately, but these > mails were considered as spam. > However,m this time I saw it. > > OK, here it is: > > I, Nicolai Josuttis, give > permission for all my contributions to Boost to be moved to the Boost > Software License Version 1. > > Best > Nico > > John Maddock wrote: > >> >> Hi, if you are receiving this reminder again it is because there are one >> or more >> files in the Boost C++ libraries that contain your copyright declaration. >> >> PLEASE, do take a little time to read through this and respond - it would >> help us a great deal! If you already have responded, then I missed it, >> and I apologise, but if you could take a little time to put me right, >> then that would be appreciated as well. >> >> 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 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). >> >> 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. >> >> > > -- > Nicolai M. Josuttis http://www.josuttis.de/ > Solutions in Time mailto:nico@josuttis.de > phone: 0700 / 5678 8888 (international: +49 700 5678 8888) > 0700 / JOSUTTIS (international: +49 700 JOSUTTIS) > >

1 0

Nightly CVS docs broken?
by Vladimir Prus 30 Aug '04

30 Aug '04

The link to nightly CVS documentation on boost.org appears to be broken: it leads to http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/libraries.h… which generates an error. Is it possible to fix somehow? Thanks, Volodya

2 2

Re:Re: [boost] another bjam question
by Robert Ramey 30 Aug '04

30 Aug '04

John Maddock >> This indicates that the Microsoft native include is specified BEFORE the >> STLPort one. This would explain why the config_info doesn't reflect the >> STLPort usage. >> >> Can someone tell me what I should be doing differently? I don't know, but the dmc toolset is broken for the same reason. Actually this seems to me to be a bad design decision: why would the compilers include directory be present on the command line at all? If my compilers environment has been modified to place some other directory first (for example in vcvars32.bat) then why would bjam subvert that? I traced this to changes made at the beginning of august by Rene Rivera to factor out commonalities of stlport toolset. Basically not a bad idea but it ended up with this error. Rene is the best person to fix it if he's around. I sent him a private email but go no response. So I'm a little bit in holding pattern on this. Apparently there are some loose ends with the stlport/serialization library combination that I would like to resolve. Robert Ramey

2 1

Re:[boost] Review of Daryle Walker's "More IO" library begins today, August 21, 2004.
by Robert Ramey 30 Aug '04

30 Aug '04

Some general comments: First of all, let me say that I am a fan of Daryle's state-saver library. I have found it to be very useful. The documentation sections use the word "Rationale" where I think they should be using the word "Motivation". I see Motivation as the explanation why the library is useful in the first place. I see Rationale (plural) as a list of justifications for design choices. This is one library submission. However, it is really several almost disjoint or orthogonal parts. a) new io manipulators b) facilities for wrapping streambuf c) a couple of new kinds of streams These should be considered separately. Manipulators ============ Here is the first part of the documentation: Rationale There are several I/O manipulators that can be useful to a general audience besides the ones given in the Standard library. This header supplies some of them. Form-based Manipulator Header The header boost/io/iomanip_form.hpp contains a class template for multiple manipulations. Form-based Manipulator Objects from a boost::io::basic_ios_form template class represent manipulators that determine what and how to affect the standard I/O attributes via repeated calls to its member functions, then can change how a single insertion or extraction call happens for an streamable object. Said manipulators can be temporarily created (in-line, without a name) or created conventionally in advance for multiple insertions/extractions. On getting this far, I have no idea what these manipulators are supposed to do, what problem they are meant solve. Or when I would use them. I believe that this part of the manual should contain: Motivating example. Problem solved by form-based manipulators. A sort of Tutorial section. The line-skipping an repeated-char seem a little more understandable- if only because of their names. Repeated_char_narrow - I would think that the "narrowing" of characters might be something more commonly handled by codecvt facet. I would prefer that the html files be broken in smaller sections. Array Based Streams =================== Its not clear to me how this is functionally different from strstream Stream buffer implementations ============================= Stream buffer with variable size buffer Stream buffer which discards output Stream buffer which returns a constant value These I find understandable though I'm not sure what I would use them for - but that's not a criticism. The streams based on these buffers are small facilitators when don't have much code. OK. Stream buffer wrapper ===================== I gather this is to factor out common code for making new stream buffers. Actually, since I haven't made a streambuffer myself I don't know all of what's involved. I'll take your word that its useful. Overlap ======= I've also taken a forward look at Jon Turkanis coming offering. I see significant overlap. Jonathon's library is more ambitious in that it in that it addresses composition of stream buffer adaptors. I suspect it would include the above as subset. So - I'm going to recommend that the review manager for this library reserve judgment pending the upcoming review of the Jonathon's library. Ideally the two managers involved would coordinate their reviews so that functionality doesn't get duplicated. >What is your evaluation of the design? The design is a natural extension of standard C++ library and in principle I see no problems here. >What is your evaluation of the implementation? I didn't run the code, but it seems to follow standard convention - a good thing for a library like this. >What is your evaluation of the documentation? The documentation is pretty clear - as far as it goes. It needs more background, motivation, and tutorial like examples. >What is your evaluation of the potential usefulness of the library? >Did you try to use the library? With what compiler? Did you have any >problems? I didn't use the library. >How much effort did you put into your evaluation? A glance? A quick >reading? In-depth study? Just about 1-2 hours reviewing the documentation. >Are you knowledgeable about the problem domain? Fairly knowledgable >And finally, every review should answer this question: >Do you think the library should be accepted as a Boost library? Be sure to >say this explicitly so that your other comments don't obscure your overall >opinion. a) manipulators are probably OK - but they need more documentation to explain what they are to be used for. With these changes, I would expect to see them added to the io library. b) streambuffers. I believe that it premature to include these in Boost. I think this will be more clear after the upcoming review of Jon Turkanis library which has overlapping functionality. Robert Ramey

3 2

Java style GUI in C++
by Reece Dunn 29 Aug '04

29 Aug '04

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 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. [2] The use of layout managers. I like the various layout managers in Java and how easy it is to construct complex GUI interfaces. [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). [4] Support for windowed and windowless components. Windowed components will use the native controls where possible, allowing a natural look and feel. Windowless controls will be lightweight components that do not use a native component (a Window handle on the Windows platform); these will be useful for writing the layout managers. 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()); } 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. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

12 27

Copyright and License in XML documentation
by Jeff Garland 29 Aug '04

29 Aug '04

I found a few moments to work on cleaning up licensing issues and decided to go make sure all the date_time xml docs have licensing info. The problem is, how should the copyright be added to all the files? I hunted around in other libraries using boostbook and it looks like they all lack copyright and license info in all but the top level xml file. I notice that in the library main file we correctly notice the following construct in the inspection: <libraryinfo> <author> <firstname>Jeff</firstname> <surname>Garland</surname> </author> <copyright> <year>2001</year> <year>2002</year> <year>2003</year> <year>2004</year> <holder>CrystalClear Software, Inc</holder> </copyright> <legalnotice> <para>Subject to the Boost Software License, Version 1.0. (See accompanying file <filename>LICENSE_1_0.txt</filename> or copy at <ulink url="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</ulink>)</para> </legalnotice> <librarypurpose>A set of facilities to ease programming with dates and times. </librarypurpose> <librarycategory name="category:misc"/> </libraryinfo> So it seems one option would be to change the boostbook schema and allow copyright and legal notice elements in each file. The other possibility would be to add this as a comment:  Thoughts on how best to approach this? Jeff

1 0

is_abstract< A<int> > fails with gcc 3.4.1
by Christoph Ludwig 29 Aug '04

29 Aug '04

FYI: According to the regression tests, gcc 3.4.1 supports boost::is_abstract<T>. Unfortunately, that does not hold if T is a class template specialization, as exhibited by the following program: cludwig@lap200:~/C++/gcc3.4/tmp> cat ./is_abstract_test.cc #include <iostream> #include <iomanip> #include <boost/type_traits/is_abstract.hpp> template<typename T> class A { virtual void f() = 0; }; class B { virtual void f() = 0; }; int main() { std::cout << std::boolalpha; std::cout << "is_abstract< A<int> >::value == " << boost::is_abstract< A<int> >::value << '\n'; std::cout << "is_abstract< B >::value == " << boost::is_abstract< B >::value << '\n'; } cludwig@lap200:~/C++/gcc3.4/tmp> ./is_abstract_test is_abstract< A<int> >::value == false is_abstract< B >::value == true This causes problems, e.g., when using the serialization library with class templates. I entered the problem in the gcc bug database. It's PR#17232. Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

1 0

problem with small width CRCs
by Bert Klaps 29 Aug '04

29 Aug '04

Hi, I ran into a problem using the CRC library for SDH LCAS control words (3-bit CRC) and SDH Trail Trace Identifier messages (7-bit CRC). For CRC widths smaller than character width the theoretical and optimized CRC computers produce different results for non-reflected input. Gcc produces this warning: /usr/local/boost/boost_1_31_0/boost/crc.hpp:581: warning: right shift count >= width of type The problem is that for the table based computer the msb of the remainder needs to be compared to the msb of the input byte. For most popular CRC parameters that's a right shift, but for CRC widths smaller than a character this should be a left shift... Reflected input requires comparing lsb's which doesn't involve any shifting. I've attached a patch that solved the problem for me. Regards, Bert Klaps /usr/local/boost/boost_1_31_0/boost/crc.hpp: In static member function `static unsigned char boost::detail::crc_helper<Bits, false>::index(typename boost::uint_t<Bits>::fast, unsigned char) [with unsigned int Bits = 3]': /usr/local/boost/boost_1_31_0/boost/crc.hpp:928: instantiated from `void boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem>::process_block(const void*, const void*) [with unsigned int Bits = 3, typename boost::uint_t<Bits>::fast TruncPoly = 3, typename boost::uint_t<Bits>::fast InitRem = 0, typename boost::uint_t<Bits>::fast FinalXor = 0, bool ReflectIn = false, bool ReflectRem = false]' /usr/local/boost/boost_1_31_0/boost/crc.hpp:947: instantiated from `void boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem>::process_bytes(const void*, unsigned int) [with unsigned int Bits = 3, typename boost::uint_t<Bits>::fast TruncPoly = 3, typename boost::uint_t<Bits>::fast InitRem = 0, typename boost::uint_t<Bits>::fast FinalXor = 0, bool ReflectIn = false, bool ReflectRem = false]' /usr/local/boost/boost_1_31_0/boost/crc.hpp:907: instantiated from `void boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem>::process_byte(unsigned char) [with unsigned int Bits = 3, typename boost::uint_t<Bits>::fast TruncPoly = 3, typename boost::uint_t<Bits>::fast InitRem = 0, typename boost::uint_t<Bits>::fast FinalXor = 0, bool ReflectIn = false, bool ReflectRem = false]' /usr/local/boost/boost_1_31_0/boost/crc.hpp:973: instantiated from `void boost::crc_optimal<Bits, TruncPoly, InitRem, FinalXor, ReflectIn, ReflectRem>::operator()(unsigned char) [with unsigned int Bits = 3, typename boost::uint_t<Bits>::fast TruncPoly = 3, typename boost::uint_t<Bits>::fast InitRem = 0, typename boost::uint_t<Bits>::fast FinalXor = 0, bool ReflectIn = false, bool ReflectRem = false]' /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/include/g++-v3/bits/stl_algo.h:157: instantiated from `_Function std::for_each(_InputIter, _InputIter, _Function) [with _InputIter = __gnu_cxx::__normal_iterator<unsigned char*, std::vector<unsigned char, std::allocator<unsigned char> > >, _Function = boost::crc_optimal<3, 3, 0, 0, false, false>]' lcas.cpp:44: instantiated from here /usr/local/boost/boost_1_31_0/boost/crc.hpp:581: warning: right shift count >= width of type *** crc.hpp.orig Tue Aug 10 14:10:34 2004 --- crc.hpp Tue Aug 10 14:57:06 2004 *************** *** 527,532 **** --- 527,556 ---- did_init = true; } + #ifndef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION + // Align the msb of the remainder to a byte + template < std::size_t Bits, bool RightShift > + class remainder + { + public: + typedef typename uint_t<Bits>::fast value_type; + + static unsigned char align_msb( value_type rem ) + { return rem >> (Bits - CHAR_BIT); } + }; + + // Specialization for the case that the remainder has less + // bits than a byte: align the remainder msb to the byte msb + template < std::size_t Bits > + class remainder< Bits, false > + { + public: + typedef typename uint_t<Bits>::fast value_type; + + static unsigned char align_msb( value_type rem ) + { return rem << (CHAR_BIT - Bits); } + }; + #endif // CRC helper routines template < std::size_t Bits, bool DoReflect > *************** *** 555,561 **** // Compare a byte to the remainder's highest byte static unsigned char index( value_type rem, unsigned char x ) ! { return x ^ ( rem >> (DoReflect ? 0u : Bits - CHAR_BIT) ); } // Shift out the remainder's highest byte static value_type shift( value_type rem ) --- 579,587 ---- // Compare a byte to the remainder's highest byte static unsigned char index( value_type rem, unsigned char x ) ! { return x ^ ( DoReflect ? rem : ! ((Bits>CHAR_BIT)?( rem >> (Bits - CHAR_BIT) ) : ! ( rem << (CHAR_BIT - Bits) ))); } // Shift out the remainder's highest byte static value_type shift( value_type rem ) *************** *** 578,584 **** // Compare a byte to the remainder's highest byte static unsigned char index( value_type rem, unsigned char x ) ! { return x ^ ( rem >> (Bits - CHAR_BIT) ); } // Shift out the remainder's highest byte static value_type shift( value_type rem ) --- 604,610 ---- // Compare a byte to the remainder's highest byte static unsigned char index( value_type rem, unsigned char x ) ! { return x ^ remainder<Bits,(Bits>CHAR_BIT)>::align_msb( rem ); } // Shift out the remainder's highest byte static value_type shift( value_type rem )

4 4

Triple change to Base-from-member
by Daryle Walker 28 Aug '04

28 Aug '04

I applied three changes for this library to CVS. (Three separate commits were done.) 1. Implemented a scheme to use the Pre-processor library to generate the various constructor templates. This allows the maximum number of constructors to be set at compile-time. It's a macro constant, so other headers can copy the exact number of constructors too. Changed "base_from_member.hpp" and "base_from_member.html". Shouldn't cause any problems unless your header can't work with the Pre-processor library. 2. Moved the default of the second template argument of base_from_member to the primary header. This removes the last component of "utility_fwd.hpp". Changed "base_from_member.hpp" and "base_from_member.html", and removed "utility_fwd.hpp". Shouldn't cause any problems unless your header directly #included "utility_fwd.hpp", which my check didn't pick up. 3. Forgot to update the copyright year list of "base_from_member.hpp" to add 2004. Changed that. Shouldn't cause any (additional) problems. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

[type_traits] "member_function_pointer_traits" ?
by Tobias Schwinger 28 Aug '04

28 Aug '04

Dear Boosters, what is the reason for the absence of "member_function_pointer_traits" (or alike) in the type_traits library ? To be precise: is it a design decision or just something not yet implemented ? In the latter case I hereby volunteer for implementing it. I suggest an interface similar to the one of function_traits but with two additional constants for 'const' and 'volatile' qualification of the pointee method, because there is no member function type without the pointer thus making it impossible to use remove_pointer / is_[qualifier] or pass 'Class::member_function' (without the '&', that is) as an argument of parametrized type to a template function. Best regards, Tobias

5 7

RE: [boost] Re: [1.32 Plan] Stalled forever?
by Rozental, Gennadiy 28 Aug '04

28 Aug '04

> Gennadiy Rozental writes: > > I would like to second that. > > > > Two month ago I was told that I had to freeze any development yet > > another month ago. Now we still nowhere and I still couldn't move a > > finger. > > 1) Release or not, any major new development should happen on > the branch. I could do my own development anywhere, even keep files on my hard drive. How am I supposed to test it? > 2) At least please take care of the unmarked failures in > Boost.Test before > claiming that you've done your part for the release. Does it say anywhere that I am required to? All the failures either expected or too minor to jump to fixes now and disturb the release. I had enough unexpected headache with things I did decide to fix > > I understand that it may be caused by book preparation. But > should we > > necessarily need to use namely this release? > > Yes. We have to use a coherent set of sources that contains > the new version of the MPL, and this is what this release is > going to provide us with, in particular. We may've published this release month ago with MPL changes. And publish another one (may be patch release) month from now with new MPL. > > > > Let at least set a policy for open information: if for > whatever reason > > release needs to be postponed lets announce it and set a new date. > > There *was* announcement of the release delay. The new date is > going to be set as soon as MPL is in the main trunk. I don't believe "release postponed until further notice" is good enough. The same time new schedule needs to be proposed and agreed upon (or after discussion we may decide to go ahead with release on previously defined terms, ignoring issues causing release to postpone). Please, understand that I am not trying to find responsible. But I also don't find this uncertainty acceptable. Regards, Gennadiy.

3 2

[boost.thread] Thread local storage on Windows
by Roland 28 Aug '04

28 Aug '04

As everyone is currently busy preparing for the 1.32 release, I do not want to clutter up the list with discussion of new things too much. However, recently I posted some suggestions for improving the windows implementation of tls. Because noone yet had time to comment on it, (because there are lot of other things to be done) I decided to also post a reworked version to http://codeproject.com/useritems/tls.asp Anyone interested in my proposal, please refer to the above article, instead of going to the boost file section. I did this in the hope to get some feedback that could help to find out whether these improvements are worth considering to be implemented to the boost library as well. Regards, Roland

1 0

preprocessor question
by Arkadiy Vertleyb 28 Aug '04

28 Aug '04

Hi all, I am trying to find a way to implement something like a preprocessing-time map. As far as I understand, the task is trivial if "keys" contain only one token: #define FIND(x) BOOST_PP_CAT(FIND_, x) #define FIND_key1 val1 #define FIND_key2 val2 #define FIND_key3 val3 And then: FIND(key1) // evaluates to val1 FIND(key2) // evaluates to val2 FIND(key3) // evaluates to val3 However, this approach obviously brakes when keys contain more than one token, like "key 1" (or, to be closer to the real problem, "unsigned int"). So I am wonderring if there is any facility in the preprocessor (or in the Boost.Preprocessor) that would allow me to do this. Thanks in advance, Arkadiy

4 4

[boost.move] move_ptr
by Thorsten Ottosen 28 Aug '04

28 Aug '04

Hi, I just wanted to hear if anybody had already made a move_ptr I could use? br Thorsten

9 24

Re: MPL vector size limit
by Arkadiy Vertleyb 28 Aug '04

28 Aug '04

Sorry to repeat this question, but I think I am missing somehing here: Do I understand correctly that it's not possible in the current version of MPL to use mpl::vector of a size larger than 50? If this is not correct, what exactly do I have to do to use, for example, mpl::vector97<...>? If this _is_ correct, I would like to make a feature request for it to be increased, since the limit of 50 doesnt seem to be high enough (I am making this statement in conjunction with the need of my typeof emulation lib, but I am kind of surprized this question hasn't yet popped up in other contexts, or has it?). In particular, isn't it possible to just get it fully controlled by BOOST_MPL_LIMIT_VECTOR_SIZE without any limitations whatsoever? Thanks, Arkadiy

2 1

Suggestion for a new class TextTableFormat
by AviadR 28 Aug '04

28 Aug '04

Hi, I am (shamefully) a newbie. I want to suggest a tiny library I've written that allows you to create "tables" of textual strings. What I mean is supposed you want to output rows of data that look like this FIELD1 (tab) FIELD2 (tab) .... FIELD-N Because many times the actual data that is written to the fields are of different lengths, You might get your output like this Field1_data field2_data field3_data Another_field1_data another_field2_data another_field3_data ... Which is not very readble or conveniet. The library I am proposing fixes this dire situation by defining a format, which states for each field: 1. its 'width' or how many columns it takes 2. its length, how many characters can it hold altogether. Data is written to a buffer using a special class which relies on the Format information. * Lines within a field are broken down in order for the column invariant to be preserved. * if data written to a field is too long for the field, the output of the field ends with "..." to indicate that the data was truncated. * the classes uses NO dynamic memory whatsoever and are very fast. If this is somehow interesting to someone I can spend the time 'boostfying' it And maybe factor some of the features stated above into Strategy classes. So how about it? I am attaching the relevant code here. IT WILL NOT COMPILE because it currently relies on My IO library, my string classes etc. of course if it is deemed interesting I will change it to use boost's classes. Thanks AviadR mailto:aviadr@pob.huji.ac.il

1 0

patch to kill warnings on boost-cvs
by Rodolfo Schulz de Lima 27 Aug '04

27 Aug '04

Hi, here's a patch to shut up the gcc-3.4.1 compiler with all warnings enable (-Wextra -Wall). That'll be nice if this was put in the main package. My projects usually have -Werror and those ones below doesn't help. It's all about harmless unused function parameters. I must point that I didn't check other libraries, just the ones I usually use. Thanks, rod diff -ur boost/date_time/date_names_put.hpp /usr/include/boost-1_32/boost/date_time/date_names_put.hpp --- boost/date_time/date_names_put.hpp 2004-07-17 19:20:18.000000000 -0300 +++ /usr/include/boost-1_32/boost/date_time/date_names_put.hpp 2004-08-23 17:35:05.000000000 -0300 @@ -142,10 +142,10 @@ default: {} //quiet compilers that want all cases covered here (eg: gcc 3.1) } } - virtual void do_put_weekday_short(iter_type& oitr, weekday_enum wd) const + virtual void do_put_weekday_short(iter_type&, weekday_enum) const { } - virtual void do_put_weekday_long(iter_type& oitr, weekday_enum wd) const + virtual void do_put_weekday_long(iter_type&, weekday_enum) const { } virtual bool do_has_date_sep_chars() const diff -ur boost/date_time/gregorian/greg_month.hpp /usr/include/boost-1_32/boost/date_time/gregorian/greg_month.hpp --- boost/date_time/gregorian/greg_month.hpp 2004-07-18 15:36:16.000000000 -0300 +++ /usr/include/boost-1_32/boost/date_time/gregorian/greg_month.hpp 2004-08-23 16:29:25.000000000 -0300 @@ -78,20 +78,20 @@ /* parameterized as_*_string functions are intended to be called * from a template function: "... as_short_string(charT c='\0');" */ - const char* as_short_string(char c) const + const char* as_short_string(char) const { return as_short_string(); } - const char* as_long_string(char c) const + const char* as_long_string(char) const { return as_long_string(); } #ifndef BOOST_NO_STD_WSTRING - const wchar_t* as_short_string(wchar_t c) const + const wchar_t* as_short_string(wchar_t) const { return as_short_wstring(); } - const wchar_t* as_long_string(wchar_t c) const + const wchar_t* as_long_string(wchar_t) const { return as_long_wstring(); } diff -ur boost/token_functions.hpp /usr/include/boost-1_32/boost/token_functions.hpp --- boost/token_functions.hpp 2004-08-19 12:23:46.000000000 -0300 +++ /usr/include/boost-1_32/boost/token_functions.hpp 2004-08-23 16:34:48.000000000 -0300 @@ -212,7 +212,7 @@ } template<class Token, class Value> - static void plus_equal(Token &t, const Value &v) { + static void plus_equal(Token &, const Value &) { } @@ -220,7 +220,7 @@ // the clear. // template<class Token> - static void clear(Token &t) { + static void clear(Token &) { } };

5 5

zip iterator misbehaving
by Antonio Piccolboni 27 Aug '04

27 Aug '04

Hi everyone, I have the following problem. I need to apply the same permutation to two sequence collections. The following code for the single permutation works like a charm: random_shuffle(TGraphRowVectorIterator<Identifier>(theGraph.begin()), TGraphRowVectorIterator<Identifier>(theGraph.end())); (only, I haven't figured out how to random seed random_shuffle, but I guess this is a question for another forum) TGraphRowVectorIterator<Identifier> is a projection iterator. Unfortunately when I wrote it I didn't know about boost so I wrote it by hand and I hate that code now (attached at the end) but it seems to work ok in many contexts. Now to the simultaneous permutation of two: random_shuffle (boost::make_zip_iterator (boost::make_tuple (TGraphRowVectorIterator<long>(firstGraph.begin()), TGraphRowVectorIterator<long>(secondGraph.begin()) ) ), boost::make_zip_iterator (boost::make_tuple (TGraphRowVectorIterator<long>(firstGraph.end()), TGraphRowVectorIterator<long>(secondGraph.end()) ) ) ); (I think if this is going to work I will make it my favorite example of generic programming. Isn't it a thing of beauty? Can this be solved in C without duplicating and uglyfying the shuffle code?). This unfortunately doesn't return a permutation. The resulting vector has repetitions in it. I debugged the code all the way inside iter_swap and it looks like the side effects of the swap are propagated only to one of the arguments, to my astonishment because they have THE SAME TYPE. So if I screwed with the iterator definition, which is totally a possibility, it should simply not permute anything. I am not yet ready to claim there is a bug in zip_iterator, but this is very suspicios. Thanks for anyone's help Antonio ----Ugly iterator code, is there anythng wrong with the signatures? Thank God for the <iterator>!------- template<class Identifier> class TGraphRowVectorIterator : public iterator<random_access_iterator_tag, vector<double>, long> { typename TGraph<Identifier>::iterator rowIterator; public: TGraphRowVectorIterator<Identifier> (typename TGraph<Identifier>::iterator rowI) { rowIterator = rowI; } TGraphRowVectorIterator<Identifier> () { } vector <double> & operator *() const { return rowIterator->values; } vector <double> * operator ->() { return &(operator*()); } bool operator == (const TGraphRowVectorIterator<Identifier> & that) const { return rowIterator == that.rowIterator; } bool operator != (const TGraphRowVectorIterator<Identifier> & that) const { return !(*this == that); } bool operator < (const TGraphRowVectorIterator<Identifier> & that) const { return rowIterator < that.rowIterator; } bool operator >= (const TGraphRowVectorIterator<Identifier> & that) const { return !(*this < that); } bool operator >(const TGraphRowVectorIterator<Identifier> & that) const { return (*this >= that) && (*this != that); } bool operator <= (const TGraphRowVectorIterator<Identifier> & that) const { return !(*this > that); } TGraphRowVectorIterator<Identifier> operator ++ (){ rowIterator ++; return *this; } TGraphRowVectorIterator<Identifier> operator -- (){ rowIterator --; return *this; } TGraphRowVectorIterator<Identifier> operator ++ (int){ TGraphRowVectorIterator<Identifier> tmp(*this); rowIterator ++; return tmp; } TGraphRowVectorIterator<Identifier> operator -- (int){ TGraphRowVectorIterator<Identifier> tmp(*this); rowIterator --; return tmp; } TGraphRowVectorIterator<Identifier> operator + (long drow) { return TGraphRowVectorIterator<Identifier> (rowIterator + drow); } TGraphRowVectorIterator<Identifier> operator += (long drow) { rowIterator += drow; return *this; } TGraphRowVectorIterator<Identifier> operator - (long drow) const{ return (*this + (-drow)); } long operator - (TGraphRowVectorIterator<Identifier> that) const { return rowIterator - that.rowIterator; } Identifier position() { return rowIterator->position(); } }; -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

1 0

typeof for vintage compilers
by Peder Holt 27 Aug '04

27 Aug '04

Hi. I started working on implementing remove_bounds for the VC 6.5 compiler, and found that the source had all the similarities of Arkadiys typeof implementation, so I have implemented typeof for compilers not supporting partial specialization. I took many ideas from Arkadiys implementation, but I had to rewrite the encoding part from scratch. The library (apart from being incomplete with respect to function types etc) has the following key elements in place: encoding/decoding of: -fundamental types -template types -modifiers (*&const volatile []) The library has a few improvements that could perhaps be implemented in Arkadiys typeof implementation as well: The max depth of an expression increased from the mpl limit of 60 to the preprocessor limit of 256 template expressions containing integral values are allowed The template: template<typename T,unsigned long V> struct X {}; can be exposed to typeof in the following way: BOOST_TYPEOF_DEFINE_TEMPLATE(X,2,(typename,unsigned long)) (VC 7.1 had some problems preprocessing the code needed to make this work.) The source is available at: http://groups.yahoo.com/group/boost/files/typeof_vintage.zip I have compiled the library for VC 6.5 and 7.0. They both fail when the depth of an expression gets too large, with the error message: fatal error C1045: compiler limit : linkage specifications nested too deeply. -- Peder Holt

2 3

Re: RE: [boost] [minmax] patch to solve issue in GCC 2.95
by JOAQUIN LOPEZ MU?Z 27 Aug '04

27 Aug '04

----- Mensaje original ----- De: "Rozental, Gennadiy" <gennadiy.rozental(a)thomson.com> Fecha: Viernes, Agosto 27, 2004 6:47 pm Asunto: RE: [boost] [minmax] patch to solve issue in GCC 2.95 > Which file? My bad :) The file is libs/algorithm/minmax/test/minmax_test.cpp > > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [boost-bounces(a)lists.boost.org] On Behalf Of joaquin(a)tid.es > > Sent: Friday, August 27, 2004 4:14 AM > > To: boost(a)lists.boost.org > > Subject: [boost] [minmax] patch to solve issue in GCC 2.95 > > > > > > GCC 2.95 has problems supporting using declarations inside > > functions, as > > > > indicated by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. > > > > This affects a minmax test in this compiler. The following > > trivial patch moves a using directive to global scope and > > solves the issue. This would make it all green for minmax > > regression tests under every platform considered. > > > > OK to commit? > > > > Joaquín M López Muñoz > > Telefónica, Investigación y Desarrollo > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] [minmax] patch to solve issue in GCC 2.95
by Rozental, Gennadiy 27 Aug '04

27 Aug '04

Which file? > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of joaquin(a)tid.es > Sent: Friday, August 27, 2004 4:14 AM > To: boost(a)lists.boost.org > Subject: [boost] [minmax] patch to solve issue in GCC 2.95 > > > GCC 2.95 has problems supporting using declarations inside > functions, as > > indicated by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. > > This affects a minmax test in this compiler. The following > trivial patch moves a using directive to global scope and > solves the issue. This would make it all green for minmax > regression tests under every platform considered. > > OK to commit? > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo >

1 0

Re: Copyright
by Vladimir Prus 27 Aug '04

27 Aug '04

David Abrahams wrote: > Vladimir Prus <ghost(a)cs.msu.su> writes: > > Could you clarify? To be exactly specific, if I have a file with the > > following content, as a part of Boost.Build test: > > > > int main() { return 0; } > > > > why does it need copyright? > > Files without copyrights make corporate lawyers nervous, and that's a > barrier to adoption. If everything in Boost is copyrighted, there > won't be any problem with dropping a Boost release on a corporate > server. *Any* file without copyright? What about 'boost.css' or 'c++boost.gif' for example? What about BoostBook DTD, which has the following: Copyright (c) 2002 by Peter Simons <simons(a)computer.org>. All Rights Reserved. What about tools/regression/xsl_reports/merger/__init__.py And, for a completely interesting question, whose copyright should be on 'status/explicit-failures-markup.xml'? Of all the authors? The reason I'm asking all this is that it seems that a lot effort was already spend to add copyrights, and more is likely to be spend and I find it hard to believe that lawyers will examine every single file of Boost. Maybe, just headers and the code which goes into compiled libraries really need to be license-clean. - Volodya

2 1

[program_options + test] Intel problem
by Vladimir Prus 27 Aug '04

27 Aug '04

The error message in http://tinyurl.com/6ynh9 says that some symbols are multiply declared. The error messages refer to Boost.Test, and also some compiler library, and is hard to understand. Could any expert take a look? - Volodya

7 11

a problem with lambda expressions
by zaufi 27 Aug '04

27 Aug '04

Hi, everybody! We've got a problem with a following code that does not compile: -------------------------------------------------------------------------------------- #include <list> #include <algorithm> #include <boost/lambda/bind.hpp> int main() { using namespace boost::lambda; std::list<std::list<int> > l; bool some_are_empty = false; std::for_each(l.begin(), l.end(), var(some_are_empty) = bind(&std::list<int>::empty, _1) || some_are_empty); return 0; } ---------------------------------------------------------------------------------------- Compiler (gcc 3.4.1) gives the following errors: ---------------------------------------------------------------------------------------- lambda-problem.cc: In function `int main()': lambda-problem.cc:13: error: no match for 'operator||' in 'boost::lambda::bind(const Arg1&, const Arg2&) [with Arg1 = bool (std::list<int, std::allocator<int> >::*)() const, Arg2 = boost::lambda::lambda_functor<boost::lambda::placeholder<1> >](((const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >&) (+boost::lambda::<unnamed>::_1))) || some_are_empty' lambda-problem.cc:13: note: candidates are: operator||(bool, bool) <built-in> -------------------------------------------------------------------------------------- Can anybody shed a light on what are we doing wrong in this example?

3 2

discrepancy between regression tests and manual testing
by Bronek Kozicki 27 Aug '04

27 Aug '04

While examining some error in regression tests I have noticeed that this error does not appear when I'm starting bjam in "test" directory of library. It does however appear in regression test. Reason for this discrepancy is that regression tests are always started from boost/status/Jamfile , and this Jamfile contains number of settings for specific tests ; thus when test started from different Jamfile (like the one in test directory) these settings are not applied, effectively both Jamfiles produce different results. I hope it's possible to move all these library-specific settings into specific Jamfiles in test directories? Right now it might be quite difficult to fix regression errors for someone not willing to run full regression tests. B.

1 0

Re: mingw test results
by John Maddock 27 Aug '04

27 Aug '04

> >I've been looking at your regression test results for mingw: > > > >config_test and all the regex tests are failing with a runtime exit code of > >128, however they pass for me here, and for some of the other testers as > >well (see the Bronek Kozicki results). Do you have any idea what's > >happening here? If you can get a stack backtrace for the problem that's > >happening in config_test that would be a big help. > > I re-compiled the test (config) using dev-cpp (which is the mingw I'm > using) and ran the test manually AND with the debugger > error_count (and what gets returned) is clearly 0 in both runs. > > apparently there is some hiccup w/ the interface to the boost test fixture. > I'll be happy to debug there if someone can give me a hint where to start. Not sure, but you could try: bjam -a -d2 config_test which may indicate some kind of difference between what bjam is doing, and what your manual builds are doing; then again it may not :-( Thanks! John.

1 0

Re:[boost] Re: [1.32 Plan] Stalled forever?
by Robert Ramey 27 Aug '04

27 Aug '04

>> The branch should occur now. MPL update can go into the next release. >> Or you can see it a slightly different way. Branch and release 1.32 now. >> Rebranch and release 1.32 when MPL update has been added and any >> related issues resolved. >Please be patient. >Aleksey is having a hard time getting finished and the release date has >slipped; it's true. That said, the very existence of this release is due >to our need to have a Boost release with an updated MPL for >http://www.boost-consulting.com/mplbook. The CD for the book has to be >final by early next month, and there's no possible way we can do two >releases before that time. The schedule is getting increasingly tight; I >just hope we can do _one_. >I considered what would happen if we branched now and Aleksey integrated >his changes into the release branch. It seems apparent that it would only >slow the release down further, since the changes would have to be >integrated into the trunk, too. This would be even worse than the current situation. My real question was what is the downside of including MPL in release 1.33 rather than 1.32 ? The important thing is the release date - not the release number. I believe that the rest of concentrating on a bug free release of 1.32 while others get MPL ready for the NEXT release will result in a sooner release date for the current library + MPL than otherwise. So my suggestion is: Branch 1.32 rc now - make only bug fixes. Actually at this point they aren't really bugs so much as accommodation to different platforms, tool configuration scripts. Etc. Define 1.33 as 1.32 + new MPL and release it as soon as its ready - I would envision this coming out a short time (4-8 weeks? - whatever) after 1.32. If MPL slips in with no ripple effect - well no harm done. If MPL ripples through creating a bunch of new test failure, still no harm done, 1.32 is still available. This would in effect de-couple the release progress of the boost library as a whole from any issues associated with a particular library. I didn't not think that I would be able to make the release for the serialization library - indeed - I couldn't make the original one. I was prepared to work at my own pace and upload a "serialization add-in" compatible with the latest release. It would be then up to the manager of the next to decide whether it was worthy to be included in the next "boost release" Actually, all boost libraries - including an MPL update, should take this approach. Robert Ramey

5 4

[minmax] patch to solve issue in GCC 2.95
by Joaquín Mª López Muñoz 27 Aug '04

27 Aug '04

GCC 2.95 has problems supporting using declarations inside functions, as indicated by BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL. This affects a minmax test in this compiler. The following trivial patch moves a using directive to global scope and solves the issue. This would make it all green for minmax regression tests under every platform considered. OK to commit? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo 46a47,48 > using namespace boost; > 50d51 < using namespace boost;

1 0

[1.32 Plan] Stalled forever?
by JOAQUIN LOPEZ MU?Z 27 Aug '04

27 Aug '04

I don't want to sound harsh or anything, and I truly appreciate the effort that's being put in this, but a month has slipped by since the first schedule for releasing, and AFAIK we don't even have an agreed upon branching date for the near future. People are beginning to divert (a review in progress, etc.) I haven't been involved in previous releases, but I guess a month delay is well over what's considered normal/acceptable. Shouldn't we settle now on a realistic branching date and proceed with the release? Or, should I shut my mouth and let the release manager handle this as he deems convenient? Again, don't get me wrong. I am not willing to push anybody, but the process looks, well, erratic. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 7

Re:Re: [boost] Seialization library current status
by Robert Ramey 27 Aug '04

27 Aug '04

>Bronek Kozicki wrote: #include <fstream> #include <boost/config.hpp> #include "test_tools.hpp" int main() { const char * testfile = boost::archive::tmpnam(NULL); test_ostream os(testfile, TEST_STREAM_FLAGS); test_oarchive oa_implementation(os); printf("boom\n\n"); } I'm amazed you could figure this out. Thank you, this is very helpful. Robert Ramey

2 1

RE: [boost] [Boost.Test] New testing procedure?
by Rozental, Gennadiy 27 Aug '04

27 Aug '04

> According to http://tinyurl.com/3f32c tests have been failing > (IIUC for several days if not longer) because of > protected/private access violations in the test library. See > the end of http://tinyurl.com/35ole for details. IMO this > situation is unacceptable, and I'm looking for practical > solutions. Problems with the Boost.Test affect our ability > to get meaningful feedback on the state of other libraries. > > If Gennadiy can't test on more compilers before checking in, > and respond faster to problems introduced in its source, and > if library authors genuinely find Boost.Test useful, maybe we > need to move to a different model wherein the test library's > own tests are run on a CVS branch of the code (?) so that > Gennadiy can see and deal with his problems before they are > merged into the main trunk and break everything else? I do test on as much compilers I have accessible. In this particular case It was working on all compilers but Borland. I posted request for workaround while ago. Still no response. I had to test other configuration and I committed it. Actually I was surprised that so many compilers had an issue with completely innocent using declaration. Anyway I think it should be fixed as of last night. I found some hack that should work on complaining compilers. I will see the results of regression test today. As for creating separate brunch for Boost.Test development, I do not really mind. But I believe it will create an extra headache for regression testers (and me). Essentially we will need to have two copies of development tree. And run Boost.Test unit test in a separate tree. I will need to keep moving files back and forth 2 branches. Also I wonder how it will interact with release procedure. You may noticed that I am trying to introduce modification in Boost.Test in "packages", meaning I do not d code modifications all the time. I am not sure that several days of "no regression test on some compilers", worth all that trouble. Especially since all the developers could always rollback Boost.Test modification locally for development testing. Regards, Gennadiy.

4 10

Seialization library current status
by Robert Ramey 26 Aug '04

26 Aug '04

Here is short summary of the current status of the serialization library. Its based on tests on my own machine and others. In some cases I'm anticipating results of next tests. Linux - 100 % passing all compilers Except intel 8.0 - problem with serialization some collections - list, map, set, and array. Darwin - 100 * passsing Except - one test of demo fail Windows Mingw - 100 % of all char archives 0 % of wchar_t archives. Apparently mingw doesn't support wchar_t. Itel 100 % all versions Borland - mostly passing - this is the best I can do here VC <= 7.0 - mostly passing - this is the best I can do here VC 7.1 - 100% VC 8.0 - 0% - I don't know the status of this compiler. Library fails to build due to syntax error compiling spirit headers. I'm not prepared to address this. Commeau - 100 % EXCEPT archives which use wide characters. I believe it would be easy to find if I could figure out a way to debug this. Metrowerks CodeWarrior - This is a little confusing. One tester shows 100% success. The best I have is all pass EXCEPT tests which use export facility or wchar_t archives. Another tester has the same result I do. All tests that fail have unexpected linker warnings. I suspect a build issue but have been unable to find it. So that's it I could use help with Intel 8.0 array, list, set and map. Its probably one error in collection loading. Comeau - problems with wchar_t. Very likely related to codecvt facit usage Metrowerks CodeWarrior. Weird linker warnings. Fails for programs which use utf8_codecvt_facet and which use export. Export seems to fail due to an over zealous link time optimizer eliminating what might look like dead code. Robert Ramey

3 3

Re:[boost] Re: Seialization library current status
by Robert Ramey 26 Aug '04

26 Aug '04

>"Robert Ramey" <ramey(a)rrsd.com> writes: >> Metrowerks CodeWarrior. Weird linker warnings. Fails for programs which >> use utf8_codecvt_facet and which use export. Export seems to fail due to an >> over zealous link time optimizer eliminating what might look like dead code. >?? CW doesn't support export ?? Export refers to one of the features of the serialization library - not to be confused with all the other ways we use this word. Sorry if there is any confusion here. >Are you aware that some of the facet stuff is only supported in the >*statically-linked* version of the MW standard library? ><runtime-link>static might be a requirement of these tests. I'm certainly not aware of that. I looked carefully through all the information I could find and didn't see anything like that. However, that would explain at least test failures associated with utf8 codecvt. I'll try this. Robert Ramey

2 1

RE: [boost] Re: Re: New design proposal for boost::filesystem
by Beman Dawes 26 Aug '04

26 Aug '04

At 09:33 AM 8/25/2004, Bennett, Patrick wrote: > If I can't write a >portable (to at least Linux and Windows), internationalizable >application with boost::filesystem then it's of no use to (at least) me. And a lot of other people. I'd like to see the library become part of std::tr2, and lack of internationalization is the main impediment to that. I've spent a lot of time for the last two years looking into the issues, and am pretty close to being ready to make a detailed proposal. >This is why I suggested that UTF-8 be used as boost::filesystem's >encoding. It can be passed through as-is or converted as needed on each >platform and it would be backwards compatible with existing >boost::filesystem code. For standardization (and I don't have any interest in internationalization except in the context of standardization) I don't think any proposal will fly unless it is in sync with current standard library internationalization. That means that the internal encodings must be char, wchar_t, or a template parameter charT. Once the Unicode TR being worked on is accepted, then those character types will be presumably be added. Just as with strings, presumably there will be path and wpath typedefs, and then Unicode typedefs when they evolve. As far as external encodings go, there will be a program default (which defaults to the platform default, but can be set to a user specified encoding), but individual paths can be constructed using a user-supplied external encoding if desired. Translation issues between encodings are messy, to say the least. Note that there has to be a way to pass strings in the operating system's external encoding on to (at the lowest level) file open functions, and that the current standard does not provide this. Bill Plauger has proposed the addition of this functionality to the standard, so that aspect is moving forward. --Beman

1 0

[filesystem] issue with path::iterator
by Martin Wille 26 Aug '04

26 Aug '04

Hello, a momemnt ago, someone reported a problem on IRC regarding boost::filesystem::path::iterator. He basically has code like this: using boost::filesystem::path; path::iterator i = somepath.begin(); path::iterator j = i++; That code used to work but stopped working recently. Now, there is a compiler error saying that the value returned by i++ is not suitable for constructing j: error: conversion from ` boost::detail::postfix_increment_proxy<boost::filesystem::path::iterator>' to non-scalar type `boost::filesystem::path::iterator' requested I suspect the change was caused by a recent change to iterator adaptors. Investigation of the problem revealed that the documenation for path::iterator says it is a bidirectional iterator while the implementation uses single_pass_traversal_tag. This looks wrong to me. Regards, m

5 15

xtime_get unsafe on Windows for IA64
by Ben Hutchings 26 Aug '04

26 Aug '04

The implementation of the boost::xtime_get() function in libs/thread/src/xtime.cpp includes the following code for Windows: #if defined(BOOST_HAS_FTIME) FILETIME ft; ... const boost::uint64_t TIMESPEC_TO_FILETIME_OFFSET = ((boost::uint64_t)27111902UL << 32) + (boost::uint64_t)3577643008UL; xtp->sec = (int)((*(__int64*)&ft - TIMESPEC_TO_FILETIME_OFFSET) / 10000000); xtp->nsec = (int)((*(__int64*)&ft - TIMESPEC_TO_FILETIME_OFFSET - ((__int64)xtp->sec * (__int64)10000000)) * 100); return clock_type; #elif ... (This is reformatted slightly so that Outlook doesn't screw it up.) The pointer casts are not safe because although the representations of FILETIME and __int64 are compatible, FILETIME is only 32-bit- aligned whereas __int64 must be 64-bit-aligned on IA64 (in some processor modes). One can instead use union { FILETIME ft; __int64 i64; } and read out i64, though I'm not sure this code should be unconditionally using __int64 anyway. There is a longer explanation at <http://weblogs.asp.net/oldnewthing/archive/2004/08/25/220195.aspx>. Ben.

2 1

[Serialization] question
by Russell Hind 26 Aug '04

26 Aug '04

I have a std::list<ublas::vector<double> > and also a list of iterators in to this list (which basically contain a subset of the initial list e.g. std::list<std::list<ublas::vector<double> >::iterator> Is there a way with serialization library to serialise both lists so that when both lists are re-loaded, the second list contains valid iterators again? Thanks Russell

1 0

[program_options + test] cw 8.3 fails all tests
by Vladimir Prus 26 Aug '04

26 Aug '04

As shown in http://tinyurl.com/3smdm all program_options tests fail on cw 8.3, because boost.test refers to the _errno variable, but that reference is somehow unresolved. Could anybody suggest any solution? TIA, Volodyaya

4 3

Re: [boost] [1.32 Plan] Stalled forever?
by Robert Ramey 26 Aug '04

26 Aug '04

Aleksey Gurtovoy wrote: >JOAQUIN LOPEZ MU?Z writes: >> I don't want to sound harsh or anything, and I truly appreciate the >> effort that's being put in this, but a month has slipped by since the >> first schedule for releasing, and AFAIK we don't even have an agreed >> upon branching date for the near future. >The branching date is pending MPL check-in. The latter has been postponed >several times as the new issues surfaced (in particular, due to better >tests), but it's crucial to ensure that the library is in the predictable >state before the release (remember that it goes on the CD with the TMP >book), so please bear with us. The branch should occur now. MPL update can go into the next release. Or you can see it a slightly different way. Branch and release 1.32 now. Rebranch and release 1.32 when MPL update has been added and any related issues resolved. > There are external constraints for this release's timeframe, > but within those, the release is criteria-driven. One of the > criteria is regression-free codebase, This is criteria for release - not for branching > and another is the new > MPL version. There is no point of releasing "on time" if the > release is useless. Nothing in the current development tree - i.e. the 1.32 release candidate depends on the MPL update that has yet to be integrated. There is no reason to hold up branch/release for new features. > > Shouldn't we settle now on a realistic branching date > and proceed with the release? Or, should I shut my mouth > and let the release manager handle this as he deems > convenient? > > Again, don't get me wrong. I am not willing to push > anybody, but the process looks, well, erratic. > Please don't forget that we are all volunteers here. The best > way to speed up things is to contribute to them. MPL issues > notwithstanding, we still have the regression field to be > cleared -- > http://www.meta-comm.com/engineering/boost-> regression/developer/summary.html. > Turning it green while MPL is in works will make a huge difference. The only way an MPL update can be expected to not create new issues is it makes only small changes. If that's the case its not worth holding things up for. If the changes are not small, it likely will create a slew of new issues. >> If you are willing to take over managing that one >> until the MPL check-in, be my guest. I wish we could all do as well as Joaquin has been doing in clearing issues related to his library. He has been doing an excellent job. When this topic was discussed at the beginning of the release process, it was indicated that subsequent releases would already be scheduled and would be soon after 1.32 . This was to assure developers that if they missed this release, it wouldn't be a big issue as the next one would be soon anyway. This is still a good idea and should be implemented. So Branch now Release branch available only for bug fixes and test clearing Main branch new MPL and what ever else. Robert Ramey

2 1

[filesystem] Status of issues
by Beman Dawes 26 Aug '04

26 Aug '04

For reasons unrelated to Boost, I've been sidelined from most work on filesystem issues since late March and am just now starting to catch up. It will take awhile just to read backed up email. Thanks to John Maddock, Dave Abrahams, and Vladimir Prus for resolving several issues when I wasn't available. As far as the 1.32.0 release goes, I'll try to give priority to bug fixes. But there probably won't be a lot of change compared to the current CVS state, since the library is pretty stable (and has a number on nice fixes and tweaks compared to 1.31.0.) --Beman

5 4

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

26 Aug '04

Ralf W. Grosse-Kunstleve wrote: >--- Reece Dunn <msclrhd(a)hotmail.com> wrote: > > Thus, in Java Swing-style C++, you can do something like: > > > > boost::gui::frame * main = new boost::gui::frame( "My GUI App" ); > > frame -> set_pane( new boost::gui::button( "PUSH" )); > > frame -> set_size( 500, 400 ); > > frame -> show(); > > > > boost::gui::message_loop msg; > > return msg.execute(); > >How does main get deallocated here? Oops :) >I am very surprised to see "new" and raw pointers in a library designed >from >scratch. Manual lifetime management is going to lead to a lot of clutter, >memory leaks, and is incompatible with exception handling. A system based >on >smart pointers like boost::shared_ptr and reference-counted container types >is >essential IMO. The library currently uses reference counted types to manage allocated types. I understand the use of smart pointers and agree that it is essential. I was just using this example as a guideline. Regsrds, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

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

26 Aug '04

Miro Jurisic wrote: >I also believe this community is capable of producing such a framework, but >I >think that it's telling that the title of this thread is "Java style GUI in >C++"; a Java style GUI typically implies making user experience sacrifices >on >every platform, and therefore I believe that a "Java style GUI in C++" is >likely >to be driven by misguided goals. What I meant by "Java style GUI" is not in terms of L&F, but in terms of programming the framework. I understand how important having a native L&F is to the particular OS you are using (implemented using OS components for native feel): this is one of the goals I am aiming for. Thus, in Java Swing-style C++, you can do something like: boost::gui::frame * main = new boost::gui::frame( "My GUI App" ); frame -> set_pane( new boost::gui::button( "PUSH" )); frame -> set_size( 500, 400 ); frame -> show(); boost::gui::message_loop msg; return msg.execute(); And this will work, creating a window with a button in it's "client" area. That is, allow the user to: [1] create components/widgets using constructors instead of Create functions (like MFC); [2] allow "native" components (buttons, etc.) and windowless components (for performance); [3] provide a set of "layout managers" that are windowless components allowing you to specify scrolling panes, splitter panes, grid layouts, flow layouts, fixed/stretchy layouts and so on -- I personally find using layout managers easy to produce interfaces rapidly; [4] avoid message maps if possible -- I personally don't like message maps and feel there is a better way to implement event handling. From the discussions here boost::signal seems to be the way to go, but some effort needs to be taken to produce a flexible, portable way of handling messages that can both write generic handlers and OS-specific handlers; That is what I mean by a Java-style C++ GUI framework. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

7 8

more fixes in como-vc71
by Bronek Kozicki 26 Aug '04

26 Aug '04

I have received two more fixes from Comeau for libcomo 31, run on como 4.3.3, backend MSVC71: - better support for "long long" type - "int swprintf(wchar_t*, size_t, const wchar_t*, ...)" is available As usually, all fixes are available to everyone upon request. I believe these fixes will be incorporated into future version of libcomo, but this might require some more work (eg. make swprintf available on other backends etc.). B.

1 0

boost::add_reference breaks type deduction
by Judd Tracy 25 Aug '04

25 Aug '04

I am trying to use boost:add_reference in a template function to protect against the reference of reference problems, but it is breaking type deduction and I was wondering if any one know of a solution to this. template<typename Type> read(std::istream& stream, Type& data); This works properly of course. ----------------------------------------- template<typename Type> read (std::istream& stream, typename boost::add_reference<Type>::type data); This one does not work properly and I have to explicitly specify the type. Judd Tracy Assistant in Simulation Institute for Simulation and Training University of Central Florida

2 1

[mpl] A simple question about using lists/vectors
by Jody Hagins 25 Aug '04

25 Aug '04

I apologize in advance for this seemingly simple question, but I am having a hard time finding a simple solution in the online docs (I am in line for the MPL book, though ;-) Lets say I have some code like this... template <class A, class B> class Bar { public: Bar() { foo.template do_something<A>(); foo.template do_something<B>(); } private: Foo foo; }; Bar<Type1, Type2> bar; but I want to create a Bar with an arbitrary number of classes... Bar<boost::mpl::vector<Type1, Type2, Type3, ..., TypeN> > bar; and in the ctor, I want to call the do_something template method for each type, so that it expands to something like... Bar() { foo.template do_something<Type1>(); foo.template do_something<Type2>(); foo.template do_something<Type3>(); ... foo.template do_something<TypeN>(); } Any help would be appreciated. Thanks!

2 1

C++ Template Metaprogramming
by David Abrahams 25 Aug '04

25 Aug '04

For the past year Aleksey Gurtovoy and I have been working on a new book, titled _C++ Template Metaprogramming: Concepts, Tools and Techniques from Boost and Beyond_. The book has recently entered copyediting. If you're interested you can peruse some sample chapters at http://boost-consulting.com/mplbook. Regards, Dave -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

9 16

RE: [boost] Re: New design proposal for boost::filesystem
by Bennett, Patrick 25 Aug '04

25 Aug '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Wednesday, August 25, 2004 9:08 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: New design proposal for boost::filesystem > > "Bennett, Patrick" <Patrick.Bennett(a)inin.com> writes: > > > I'll probably not talk about this topic too much more. I think I've > > pretty much said everything I'm going to say, so if no one else agrees, > > I'll just move along. ;) > > I wouldn't take the fact that people are correcting technicalities of > your statements as an indication of universal disagreement. > [Bennett, Patrick] Fair enough. It just doesn't seem like anybody else really sees it as an issue for then, so I don't think it's worth repeatedly beating a drum when no one particularly cares to hear it. :) Cheers...

1 0

Overload resolution & boost::bind
by Arturo_Cuebas＠bpmicro.com 25 Aug '04

25 Aug '04

The program below contains a compile error. Following the program you will find the typical fix then my idea for a library that facilitates a syntactically prettier fix. #include <boost\bind.hpp> using namespace boost; struct C { void F(char, char){} void F(int, int){} void F(char, int){} void F(char){} }; int main() { C o; bind( C::F, // error: which C::F? &o, _1); } Typical solution: bind(static_cast<void (C::*)(char)>(C::F), &o, _1); And if you're a nice guy: typedef void (C::* OneCharOverload)(char); bind(static_cast<OneCharOverload>(C::F), &o, _1); Here's my idea. If we had these: template<typename TC, typename TR> TR (TC::* resolve_cast0(TR (TC::* Func)(void)))(void) { return Func; } template<typename TP, typename TC, typename TR> TR (TC::* resolve_cast1(TR (TC::* Func)(TP)))(TP) { return Func; } template<typename TP1, typename TP2, typename TC, typename TR> TR (TC::* resolve_cast2(TR (TC::* Func)(TP1, TP2)))(TP1, TP2) { return Func; } template<typename TP1, typename TP2, typename TP3, typename TC, typename TR> TR (TC::* resolve_cast3(TR (TC::* Func)(TP1, TP2, TP3))) (TP1, TP2, TP3) { return Func; } ...etc; the bind call would look like this: bind(resolve_cast1<char>(C::F), &o, _1); If I want to specify C::F(char, int): bind(resolve_cast2<char, int>(C::F), &o, _1, _2); If the struct looked like this: struct D { void F(char, char){} void F(char){} }; Things would be even nicer: If I want to specify D::F(char, char): bind( resolve_cast2(D::F), // Notice no template parameters specified. &o, _1, _2); If I want to specify D::F(char): bind(resolve_cast1(D::F), &o, _1); Benefits: - No ugly syntax due to specifying member function pointer type with static_cast. or - One less line of code due to no typedef. It would be nice to do this, but I can't find a way: If I want to specify C::F(char): bind( resolve_cast<char>(C::F), // Notice no number appended. &o, _1); If I want to call D::F(char, char): bind( resolve_cast<2>(D::F), // Notice no number appended. &o, _1); Is this worth the trouble? Has anyone seen this before? Is it possible to implement a form without a number appended? Is there a name better than resolve_cast? This was tested only in VC7.1.

10 32

boost::filesystem with network paths on windows
by Arne.Adams＠t-online.de 25 Aug '04

25 Aug '04

Hi, I am trying to use boost filesystem to copy files from a local directory to a directory on a network server (the latter having a path like \\databaseserver\c$\importfiles\myTabledump.txt <file:///\\databaseserver\c$\importfiles\myTabledump.txt> ) Unfortunately the leading double backslashs (\\) get converted in the constructor of filesystem::path to double slashs - yielding a different meaning. Is there a way to copy files on windows to network servers like this? Regards, Arne Adams Nerotal 23 65193 Wiesbaden Tel.: (+49) 611 3413745 Mobil: 0172 6147473 Mail: inbox(a)arneadams.com

3 2

RE: [boost] Re: Re: New design proposal for boost::filesystem
by Ferdinand Prantl 25 Aug '04

25 Aug '04

Hi, I will be shorter, as I answered some pointes before. > [mailto:boost-bounces@lists.boost.org] On Behalf Of Bennett, Patrick > > [Bennett, Patrick] Yes, you could pass UTF-8 through as-is in > Linux. If your application was running in Japan on Windows, > boost::filesystem would not work at all. So, yes, you can > pass all sorts of extended characters to Windows in an 8-byte > string (the majority of which aren't really valid for > filenames), but that does nothing for Unicode support. > It simply won't work. For Unicode support the application > must call the xxxxxW versions of the windows API's and pass > in a UCS-2 string. I will run as long as you use ASCII and Japanese characters from an ANSI codepage, for example from SJIS only. Yes the application will not be capable of the full Unicode support as ANSI-C and STL is not. See my last e-mail for some discussion. > > What you can't do is use the same encoding on all platforms, because > the > > underlying platform API's won't understand them. > > [Bennett, Patrick] Correct, this was my whole point. If I > can't write a portable (to at least Linux and Windows), > internationalizable application with boost::filesystem then > it's of no use to (at least) me. :-) Workarounds are being build all the time in multiplatform applications. You have to workaround ANSI-C for that. STL too. It is a question if to workaround boost::filesystem as well, if Windows (only?) provide Unicode methods. > This is why I suggested that UTF-8 be used as > boost::filesystem's encoding. It can be passed through as-is > or converted as needed on each platform and it would be > backwards compatible with existing boost::filesystem code. It will not be compatible. It is not the way to force UTF-8, breaking the current local encoding only support. Moreover, it would force all people to recode to UTF-8 even if they would not need. That is why std::streams use imbuing - no reader is forced to accept UTF-8 only. See my last e-mail. Note: here I put together filenames with file content, with filenames it is not so painful, but though... > I'll probably not talk about this topic too much more. I > think I've pretty much said everything I'm going to say, so > if no one else agrees, I'll just move along. ;) I do not agree with you suggestion because it breaks the compatibility with the current interface and would force me to recode into UTF-8. I sketched a solution for the interface, which is non-intrusive to the current interface and the underlying implementation can use XxxW for Unicode input. However, I still think it is a cannon for a sparrow... What do the others think about this extension: * provide methods for std::wstring and wchar_t (or generalize them for basic_string<T>) * implement the <wchar_t> methods to support Unicode by imbuing * provide the most common imbuing objects in boost::filesystem (at least the null one - see 1) 1) unicode <-> local: wcstombcs and mbcstowcs to support the current locale functionality (imbue local) 2) unicode <-> unicode: UTF-8 conversion from boost::xxx to support UTF-8 encoding on UN*Xes and _wxxx or XxxW on Windows to support Unicode on Windows (imbue unicode) 3) using externally implemented codecvt-like objects (using ICU, libiconv, Win32...) can be achieved any conversion from the applications model into filesystem codepage Ferda > Cheers... > Patrick Bennett

1 0

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

25 Aug '04

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. The signals library looks very good, but it solves half the problem. You need to work out what types of signals are raised: MouseUp MouseDown MouseDoubleClick MouseMove and have a signal for each. This would mean that you could have hundreds of signals! It might be easier to group events by type, use signals to dispatch them and an event handler like I suggested to deal with them, e.g. MouseEvent( unsigned int event, const MouseEvent & info ); KeyEvent( unsigned int event, const KeyEvent & info ); This might be useful for command/reflection type events, having a std::list< boost::signal< bool ( const Event & ) > > or even std::map< std::string, boost::signal< ... > > Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

6 14

RE: [boost] Re: Re: New design proposal for boost::filesystem
by Ferdinand Prantl 25 Aug '04

25 Aug '04

Hi, I am sorry for the length of the e-mail, I hope I make myself clear better than last time. > [mailto:boost-bounces@lists.boost.org] On Behalf Of Bennett, Patrick > > > On Behalf Of Ferdinand Prantl > > > > I have nothing against usage of UTF-8 if it suits the > scenario well. I > > just say that it is not an encoding for all purposes. It is a > multibyte > > one and so extremely inefficient for getting size, searching, etc. > > [Bennett, Patrick] I fail to see how this is the case. Right > now, today, filesystem supports *only* ascii. If you IMHO it is not true. boost::filesystem does neither recoding nor modification to the strings passed into its methods. It calls underlying OS functions, the XxxA methods on Windows and the POSIX functions on UN*Xes. These work with the current locale on UN*Xes and in the current ANSI codepage on Windows. They accept all characters valied in the current codepage. If you change it, you may see the filenames crippled, because the characters can be mapped differently, but that's it, it's not problem of boost::filesystem. This the current boost::filesystem does not solve and lets it on the programmer, to convert the filenames, if needed. You can use UTF-8 even today on non-Windows platforms. Unfortunately, there is no setting on Windows to enforce a UTF-8 codepage, like on UN*Xes. You set the regional settings and the codepage is assigned automatically. So the XxxA functions continue use the ANSI encoding. Well, the speed of searching in filenames can be discutable... But I like to use only one string type for everything in my application model and convert only on rare places, where a contact with OS is necessary. I like to use wstring only. > If you > continued to use ASCII, nothing would change. Yes, if I used ASCII but I use all characters from the current locale. I write localized application, including names of files. Then simply throw UTF-8 in would break it. > There is zero > speed penalty for calculating the # of *bytes* in an utf-8 > string. If you want to determine the # of characters, then > there is, but then only if you're actually working on a > Unicode string. There is no getting around this for an > international application, no matter what encoding is used. It is not predictable, if there are some non-ASCII characters in a string or not. Use a different, more suitable Unicode encoding for it. If you have to declare the complexity of your algorithms and the application is time critical, the multibyte (UTF) encodings are not used, but the fixed-byte (UCS) ones. UTF are recommended for transport because they do not waste space, UCS for runtime because they guarantee constant complexity of operations. But it is not a dogma, UTF encodings are not "forbidden" in runtime, it depends on requirements on an application. Windows (XxxW) and Java use UCS-2 for the Unicode character representation in their APIs, for example. > > Why to prescribe it for all boost::filesystem users and > force them to > put > > recoding into their sources, > > [Bennett, Patrick] Absolutely no recoding would be necessary > for current users of boost::filesystem. boost::filesystem > has no support for unicode today, so why would they have to > recode anything? As I said, absolutely no recoding is necessary now, if you use boost::filesystem with the strings in a native codepage. For example East Europe or Cyrillic. Everything will work well because you deliver your application localized in these countries. If you start accepting only UTF-8, such application would be broken. The application, which does not use Unicode (on Windows it does not have to and it can run on Japanese Windows good though), would have to perform recoding from the local codepage, in which it works, into UTF-8, which boost::filesystem would accept. And I did not mention, that Windows9x do not implement all XxxW methods (aditional library must be used to compile an application) and the recoding methods on Windows95 do not have support for UTF-8 as a codepage as Windows 98/NT have. It would mean a different solution for Windows9x withinn boost::filesystem. > > UTF-8 is not identical with the complete iso-8859-1 > (latin1) codepage. > > Some code could be broken by accepting UTF-8 in the new version. > > [Bennett, Patrick] Hmmm, good point, but... would it break > for any of the characters that are valid characters for a > path or filename on an > 8859-1 system? No, not that I can think of. Again, valid are all characters in the current codepage for XxxA methods and in the current locale for POSIX methods. Except for wildcards and path delimiters, of course. Then it is change of interface breaking all usage scenarios. > [Bennett, Patrick] If you can think of a good way of handling > this that doesn't involve a mess of codepages, locales, and > facets, then I'm all for it. Frankly I think C++'s > 'built-in' internationalization support is a nightmare, but > that's probably just me. My (intentional) limited exposure > to them probably hasn't helped. It's hard to beat having a > 'single' encoding like UTF-8 that can handle all defined characters. > Unicode is definitely the way to go IMO. Unicode is the ideal way, however, not all systems support it or are configured to use it. If you force its support in boost::filesystem, you would force Unicode to all applications using it, which do not do it now. Currently boost::filesystem does not force it, but allows it with the following setup: A local encoding on UNIX: no problem OS: configure for example cs_CZ environment boost::filesystem: use cs_CZ strings UTF-8 on UNIX: no problem OS: configure UTF-8 environment boost::filesystem: use UTF-8 strings A local encoding on Windows: no problem System: configure for example Czech environment boost::filesystem: use czech strings Windows has no predefined regional settings with UTF-8, but uses always an ANSI codepage. Unicode support is additional and preferred for NT. If you wanted UTF-8 on API boost::filesystem, you would have to: 1) either use XxxW methods in boost::filesystem and convert from UTF-8 to UCS-2 2) or recode the input UTF-8 strings into the local ANSI codepage within boost::filesystem to be able to use XxxA methods ad 1) it needs a recoding engine (built in Windows, for UTF-8 on 98/NT) ad 2) it will work for names from the current codepage only (UTF-8 recoding is from 98/NT) > My real issue with boost::filesystem is that as currently > defined, it's unusable in an application that will be used > around the world. My initial response to this whole thread > was just to point out to David that there *are* issues > preventing people from using the library. He didn't think > there were any, so I was compelled to point out what one of > the issues was for me at least. Could you specify exactly what prevents you to use it? I can use boost::filesystem in czech and russian environments happily and for japanese it is the same as long as you stay within the local codepage. boost::filesystem is perfectly usable in any localized application, which instance runs in a single language environment. The application itself can be installed in any language environment, however. The only thing you have to keep in mind is, that the strings being accepted by boost::filesystem are in the current locale/ANSI codepage. The problem is somewhere else and does not concern only boost::filesystem but the whole locale support by OSes. Just to clarify: localized application is an application, which can run on a localized environment, has a localized interface and accepts all arguments (here: filenames) from the localized environment. This boost::filesystem fulfills this for any existing locale, including japanese, without recompiling (single binary, localized resources). Nowadays comes another requirement - sharing applications and its data throughout more locales (locale switching, data distribution) without loosing information (here: crippled characters in filenames). To make myself clear - to use more locales together in a single application, for example czech, russian and japanese together. Unfortunately, this is not possible to achieve using POSIX methods (libc, libstdc++/STL), because they use the current locale, which does not need to be defined to Unicode (UTF-8) but to any ANSI. AFAIK only Windows implement C/C++ runtime with native Unicode suport, using UCS-2. It is a question, if boost::filesystem should help it. Currently it behaves the same way, how POSIX and libc and libstdc++/STL: works in the current locale. I think, that ANSI-C comitee should have updated the library specification to contain wchar_t methods since a long time, btw... It could have a positive influence on std::streams (wchar_t* methods) and boost::filesystem as well. In such ideal worlds you would have no problems :-) You are right in these points: 1) you cannot write an application, which has characters from more codepages (locales) in a filename 2) if characters in two codepages are mapped differently, filenames would be incompatible, although the characters are valid in both encodings Currently you are not able to write applications for Windows, which require usage of Unicode API (XxxW functions) - the two poins above. It is not because boost::filesystem does not use UTF-8. It is because: ANSI-C does not use Unicode -> ANSI-C++ (STL) does not use Unicode -> boost::filesystem does not use Unicode. My opinion: the way to solve it is not to change encoding of std::string and char* parameters of the current boost::filesystem to UTF-8 but to follow the STL way - to introduce methods with std::wstring and wchar_t or better, templatize it with basic_string<CharType>. It is difficult because wchar_t is not in STL and libc, I know. > At the company where I work we're currently just pursuing our > own wrappers for what filesystem provides. I originally > tried using filesystem, but once I saw that it's handling of > internationalization was absent, I had no choice but to dump > it. I certainly have an interest in it being improved, and I > could see looking at it again, but someone will have to > spearhead that initiative. Considering that this hasn't > really been brought up before tells me that people either > aren't using the library, or simply don't care about > internationalization (probably the latter). I, > unfortunately, don't have that luxury. I am from an Eastern European country and you bet we are concerned with internationalization. However, no change comes without a discussion and you are not alone using the library and your suggested change would make the others (at least me ;-) dificulties. If nobody has got the problem could also mean, that there is a usage style, which works. This I pointed out above. Besides, I don't have the luxury to support platforms with full support of XxxW methods and UTF-8 support in WideCharToMultibyte. That's why would like to extend boost::filesystem with the support of the current behavior (work in the current locale) but for Unicode applications perform recoding, which does not need to happen, if OS supports Unicode natively. That's why I pointed out the imbue principle used in std::streams for the similar case - application can work in Unicode (UCS-2 wchar_t) and content of the stream can be in any encoding (including UCS2 wchar_t for no recoding). Ferda > Cheers... > Patrick Bennett

1 0

RE: [boost] Re: Re: New design proposal for boost::filesystem
by Bennett, Patrick 25 Aug '04

25 Aug '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of John Maddock > Sent: Wednesday, August 25, 2004 5:50 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: New design proposal for boost::filesystem > > > > Win32 doesn't support UTF-8 filenames natively. That's why > > boost::filesystem would have to convert t o/from UCS-2 along Win32 > > interface boundaries. > > If you're concerned about other platforms, you shouldn't be. > > boost::filesystem currently works only with latin encodings in ascii > > strings so no functionality would be taken away. > > Not true: currently the narrow character strings passed to > boost.filefsystem are assumed to be in that platforms native encoding - > you can for example pass native Windows narrow character strings (not > just ACSII ones) to the lib, and actually I don't see why you can't pass > UTF-8 on Linux. [Bennett, Patrick] Yes, you could pass UTF-8 through as-is in Linux. If your application was running in Japan on Windows, boost::filesystem would not work at all. So, yes, you can pass all sorts of extended characters to Windows in an 8-byte string (the majority of which aren't really valid for filenames), but that does nothing for Unicode support. It simply won't work. For Unicode support the application must call the xxxxxW versions of the windows API's and pass in a UCS-2 string. > What you can't do is use the same encoding on all platforms, because the > underlying platform API's won't understand them. [Bennett, Patrick] Correct, this was my whole point. If I can't write a portable (to at least Linux and Windows), internationalizable application with boost::filesystem then it's of no use to (at least) me. This is why I suggested that UTF-8 be used as boost::filesystem's encoding. It can be passed through as-is or converted as needed on each platform and it would be backwards compatible with existing boost::filesystem code. I'll probably not talk about this topic too much more. I think I've pretty much said everything I'm going to say, so if no one else agrees, I'll just move along. ;) Cheers... Patrick Bennett

2 1

casting shared_ptr to function to void
by Vladimir Prus 25 Aug '04

25 Aug '04

If I have boost::shared_ptr<some_class>, it's possible to cast it to shared_ptr<void>. But it does not appear to be any way to convert pointer to function to pointer to void -- just because there's no implicit conversion from function pointer to void*. So, when I compile the attached program with g++, I get: sp.cpp:22: instantiated from here /home/ghost/Work/boost/boost/shared_ptr.hpp:163: error: invalid conversion from `void (* const)()' to `void*' Is there any way to make it work? What I'm trying to do is: - access a function from DLL -- i.e. get shared_ptr<function_type> - do something with the function - cast the pointer into shared_ptr<void> The last pointer will be stored in various places to keep the DLL in memory until last object which depend on it is destroyed. I think I can keep shared_ptr<function_type> everywhere, but can shared_ptr<void> work somehow? Thanks, Volodya

2 2

RE: [boost] Re: Re: New design proposal for boost::filesystem
by Ferdinand Prantl 25 Aug '04

25 Aug '04

Hi, I would prefer to use the standard types like std::string and char * as well. However, I do not like much the idea about a fixed encoding, UTF-8 or something else. It is possible to use any encoding in std::string and even in std::wstring. What do you think about imbuing and codecvt-like approach in boost::filesystem for the names of the files? It has a standard interface for the content of streams, it could serve also the filenames. Not all platforms support UTF-8 filenames, sometinmes could it serve as name mangling support. Ferda > [mailto:boost-bounces@lists.boost.org] On Behalf Of Patrick Bennett > > Correct (kind of), but I'd far prefer that std::string be > used than for some completely new type to be defined. > For users of boost::filesystem, I can't personally think of a > time when a user would need to iterate the paths or files a > character at a time. > Because of UTF-8's nature, even if a user were to search for > something like '/', it would still work for find's, [], etc. > UTF-8 maps to std::string extremely well. > I think there is also a fair amount of precendents already > set for using > UTF-8 internally using std::string as the storage mechanism. > UTF-8 strings don't contain embedded nul's (std::string still > works for that though), ASCII characters remains ASCII > characters, and you can tell if you're in the middle of a > multi-byte sequence. > > Since we're talking about filesystem's inability to be used > with internationalized applications, and you don't think > UTF-8/std::string is the way to do it, what is your recommendation? > > Cheers... > Patrick Bennett > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

3 2

Type traits on Digital Mars
by Daniel James 25 Aug '04

25 Aug '04

Hi, The attached patch improves the type traits library on Digital Mars. Mostly it just selects the correct code to be used, the only new code is a new version of boost::is_convertible. Using '...' to overload the conversion check works really badly, so I experimented with different ways of trying to get it to select the right overload, and found one that mostly works. You can see it in the patch. Also, when using static cosnt values it can sometimes cause '_m_from' to get instantiated - causing a link error. To work round this, it uses enums. With this patch applied there are still the following problems: The compiler has trouble with const and volatile modifiers on voids and arrays in template variables. So it gets a lot of the tests involving these types wrong. The compiler allows some conversions that it shouldn't. For example, it only warns about binding temporaries to non-const references, instead of causing an error. So, in these cases is_convertible is true. Would it be worth adding checks for these cases? is_abstract doesn't work. is_base_and_derived uses the 'broken' implementation, based on is_convertible. The test tricky_is_enum_test fails to compile. Daniel

5 13

Regex lib bug: wrong alignment on 64 bit platforms
by Benzinger, Ralph 25 Aug '04

25 Aug '04

Hello, The regex library contains an alignment bug that leads to bus errors on 64 bit platforms (in particular, Sun and HP). To reproduce, compile regular expression '(?>a+b|a+)bc+' with flags regex_constants::normal. This should raise SIGBUS in perl_matcher<>::push_alt(). As a fix, I suggest forcing alignment of structure saved_state in perl_matcher_common.cpp: struct saved_state { < unsigned int id; < saved_state(unsigned i) : id(i) {} -> union align -> { -> unsigned int id; -> void* dummy; -> align(unsigned i) : id(i) {} -> } id_aligned; -> saved_state(unsigned i) : id_aligned(i) {} }; and further down below: < unwinder = s_unwind_table[m_backup_state->id]; -> unwinder = s_unwind_table[m_backup_state->id_aligned.id]; The other saved_* structures that get pushed onto the stack seem fine for now. Regards, Ralph

2 1

Roadmap of boost::fsm
by Schalk_Cronje＠McAfee.com 25 Aug '04

25 Aug '04

> What is the state of boost::fsm? Are there plans to move it in to Boost from the sandbox? I have noticed that the problem with atomic_count_gcc has now been fixed on HEAD so that is not a limiting factor anymore.

3 2

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

25 Aug '04

Hello Bronek, > I have received updated <cmath> from Comeau and it contains all > necessary functions - I just removed your workaround on my machine and > performed tests, everything is fine. If anybody is interested, I can > send out fixed <cmath> file for libcomo 31. Support for Comeau compiler > is incredibly responsive, I think they treat it personally ;-) > Excellent. I think we can now assume the problem will not exist in future libcomo versions. I have made the uBLAS config.hpp library version dependant on this assumption.. #if defined (__COMO__) && ! defined (BOOST_STRICT_CONFIG) // Missing std::abs overloads for float types in <cmath> are in <cstdlib> #if defined(__LIBCOMO__) && (__LIBCOMO_VERSION__ <= 31) #include <cstdlib> #endif #endif Michael

1 0

Re: [boost] test_read_write_mutex trouble under Tru64 Unix
by Ralf W. Grosse-Kunstleve 25 Aug '04

25 Aug '04

--- "Ralf W. Grosse-Kunstleve" <rwgk(a)yahoo.com> wrote: > --- "Ralf W. Grosse-Kunstleve" <rwgk(a)yahoo.com> wrote: > > > 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. > > I had to use the kill command a few more times. I don't think the results > made > it to the meta-comm server. The output of regression.py is available here: > > http://cci.lbl.gov/~rwgk/tmp/tru64cxx65_boost_regression/ > > The file name is run_2004_08_18_0207.log. The file run_regression.csh was > used > to start the tests. For the record: the tests are still broken. I just had to kill -INT the "process_jam_log" process after 75 minutes of CPU time. Before that I already killed -INT two mutex-related tests. Ralf __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

2 3

shared_ptr and pointer to function
by Vladimir Prus 25 Aug '04

25 Aug '04

I wonder if shared_ptr can hold a pointer to a function. I've just tried the following program: #include <boost/shared_ptr.hpp> using namespace boost; int main() { extern int* object; boost::shared_ptr<int> p(object); extern void (*function)(); boost::shared_ptr<void ()> p2(function); return 0; } The first initialization, of course, work. The second produces a lots of errors. Do I miss something obvious? TIA, Volodya

3 6

libs/filesystem/example/Jamfile
by David Abrahams 24 Aug '04

24 Aug '04

Some questions: 1. Why does this Jamfile build the example with sources included directly instead of referencing the library? exe file_size : file_size.cpp <lib>@boost/libs/filesystem/build/boost_filesystem : <define>BOOST_ALL_NO_LIB <include>$(BOOST_ROOT) <sysinclude>$(BOOST_ROOT) ; 2. Why isn't there an entry to build simple_ls? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

RE: [boost] Re: Re: New design proposal for boost::filesystem
by Bennett, Patrick 24 Aug '04

24 Aug '04

> -----Original Message----- > On Behalf Of Ferdinand Prantl > Sent: Tuesday, August 24, 2004 4:30 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: New design proposal for boost::filesystem > > I have nothing against usage of UTF-8 if it suits the scenario well. I > just say that it is not an encoding for all purposes. It is a multibyte > one and so extremely inefficient for getting size, searching, etc. [Bennett, Patrick] I fail to see how this is the case. Right now, today, filesystem supports *only* ascii. If you continued to use ASCII, nothing would change. There is zero speed penalty for calculating the # of *bytes* in an utf-8 string. If you want to determine the # of characters, then there is, but then only if you're actually working on a Unicode string. There is no getting around this for an international application, no matter what encoding is used. > Why to prescribe it for all boost::filesystem users and force them to put > recoding into their sources, [Bennett, Patrick] Absolutely no recoding would be necessary for current users of boost::filesystem. boost::filesystem has no support for unicode today, so why would they have to recode anything? > when it can be achived inside the boost::filesystem as it is done > in std::streams? > I would like to have the boost filesystem as flexible as > possible. Someone can work with filenames in std::string in current > locale, > in UTF-8 or a different locale, someone can use std::wstring with UCS-2 or > UTF-16, etc. The question is, if such a flexibility is not so rare, that > it rather spoils the interface. I don't think so. > > > Win32 doesn't support UTF-8 filenames natively. That's why > boost::filesystem > > would have to convert to/from UCS-2 along Win32 interface boundaries. > > If you're concerned about other platforms, you shouldn't be. > boost::filesystem > > currently works only with latin encodings in ascii strings so no > functionality > > would be taken away. > > UTF-8 is not identical with the complete iso-8859-1 (latin1) codepage. > Some code could be broken by accepting UTF-8 in the new version. [Bennett, Patrick] Hmmm, good point, but... would it break for any of the characters that are valid characters for a path or filename on an 8859-1 system? No, not that I can think of. > Linux can be configured to support UTF-8 natively. However, it is not > necessary and depends on your locale installation and configuration. > > By imbuing I meant the conversion "application filenames encoding" -> > "machine filenames encoding". Instead of putting a platform dependent code > into conditions, which does the translation, one could simply say "I am > running in UTF-8, boost::filesystem, please understand it and do the > system > translation for me". Exceptoins could sourt out incompatibilities. > > boost::filesystem::imbue("UTF-8"); // more abstract than codecvt > pseudocode > :-) > > In this example an internal conversion into UCS-2 would be done on > Windows, > on Linux it would depend on the configured locale and on the other > systems, > which could support ASCII only, it would convert into ASCII only. However, > it does not constrain the application from running wholly in wchar_t (e.g. > UCS-2) or char (UTF-8 or something else), or does not force the user to > write extra code for character conversion if it is not necessary. [Bennett, Patrick] If you can think of a good way of handling this that doesn't involve a mess of codepages, locales, and facets, then I'm all for it. Frankly I think C++'s 'built-in' internationalization support is a nightmare, but that's probably just me. My (intentional) limited exposure to them probably hasn't helped. It's hard to beat having a 'single' encoding like UTF-8 that can handle all defined characters. Unicode is definitely the way to go IMO. My real issue with boost::filesystem is that as currently defined, it's unusable in an application that will be used around the world. My initial response to this whole thread was just to point out to David that there *are* issues preventing people from using the library. He didn't think there were any, so I was compelled to point out what one of the issues was for me at least. At the company where I work we're currently just pursuing our own wrappers for what filesystem provides. I originally tried using filesystem, but once I saw that it's handling of internationalization was absent, I had no choice but to dump it. I certainly have an interest in it being improved, and I could see looking at it again, but someone will have to spearhead that initiative. Considering that this hasn't really been brought up before tells me that people either aren't using the library, or simply don't care about internationalization (probably the latter). I, unfortunately, don't have that luxury. Cheers... Patrick Bennett

2 1

[documentation] liks to other boost libs
by Thorsten Ottosen 24 Aug '04

24 Aug '04

Hi, When I link to the documentation of other libraries, would I have to use full address http://www.boost.org/doc/html/ref.html or can I simply do ../../lib-name/index.html ? Thanks Thorsten

3 2

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

24 Aug '04

Hi Bronek, It seems from Jonathan's and your info the overloads uBLAS needs (for float types) should be in cmath. As you show the work around is to #include <cstdlib> I would like to make this library version dependant but for now have simply place the include in uBLAS's "config.hpp" header. Looking at the regression tests there is a far more serious problem. There is a series of warning thus: ublas/matrix.hpp", line 1030: warning #504-D: nonstandard form for taking the address of a member function size1_ (ae ().size1 ()), size2_ (ae ().size2 ()), data_ (functor_type::size1 (size1, size2) + 1) { The warning point to the functor_type::size1(size1,size2). The compiler is getting this very wrong. There is no address to be taken here! It should be calling the static 'size1' member of the functor_type. This is probably the cause of a few further failures. Michael

2 2

boost::random Unneceassry standard stream definitions
by Michael Stevens 24 Aug '04

24 Aug '04

In boost::random the random number generators #include <iostream> This introduces the unnecessary definitions of the standard stream cin, cout etc. These are not required to define the stream operations and will fail on runtime environments which cannot define the default streams. It would be better to use instead: #include <istream> #include <ostream> On indeed only the forward definition are required to define stream operations #include <iosfwd> The latter requires that when the templates are instantiated a stream definition exists. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

boost::dereferenceable<>::operator->() problem
by Pavel Kuznetsov 24 Aug '04

24 Aug '04

Recently two of our developers encountered the same problem with boost::dereferenceable<>::operator->(). There were an iterator which returned value_type from its operator*, not value_type&: value_type operator*() const; And it was inherited from boost::random_access_iterator_helper, which in turn is indirectly inherited from boost::dereferenceable. Since our iterator class template did not have its own operator->, one from boost::dereferenceable<> was inherited. And it is defined as follows: P operator->() const { return &*static_cast<const T&>(*this); } where P is pointer to value_type of corresponding iterator. Both of the compilers which we use (MSVC 6.0 and CodeWarrior) compile this code without any errors (though at least one of them did gave a warning). That lead to operator-> returning addres of a temporary object. What do you think about modifying operator-> so that it would be permissive to iterators for which operator* gives rvalue? E.g. this way: struct address_of_proxy { value_type value; address_of_proxy( value_type const& v ) : value( v ) { } operator value_type const*() const { return &value; } value_type const* operator->() const { return &value; } }; address_of_proxy operator->() const { return address_of_proxy( *static_cast<const T&>(*this) ); } where value_type is value_type of corresponding iterator. And of course it is possible to avoid creating proxy object when iterator's operator* returns reference, not value... -- Pavel Kuznetsov MetaCommunications Engineering http://www.meta-comm.com/engineering

2 7

Type mismatch in type_with_alignment.hpp
by Joaquín Mª López Muñoz 24 Aug '04

24 Aug '04

Most templates in these header take an alignment parameter of type size_t, yet a few of them accept an int instead: is_aligned type_with_alignment These causes in some compilers nasty truncation warnings when using aligned_storage with its default alignment_ parameter (maximum alignment) integer conversion resulted in truncation detected during: instantiation of class "boost::aligned_storage<size_, alignment_> [with size_=16UL, alignment_=18446744073709551615UL]" at line 114 of... 1. Is there any fundamental reason why some alingment parameters are int instead of size_t? 2. If not, any objection to fixing this in the CVS? 3. Could it be the other way around, namely that aligned_storage must use ints instead of size_t's? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[bug] bug in 'octonion.hpp' file
by Oleg Anashkin 24 Aug '04

24 Aug '04

I think there is a bug in the 'octonion.hpp' file. There are several tt[0] consecutive assignments (lines 1243-1250, 1292-1299, 1340-1346). It seems that they should be changed to tt[0]..tt[7]. -- Thanks.

2 1

algorithm / string / container regression failure on tru64cxx65
by Markus Schöpflin 24 Aug '04

24 Aug '04

Hello, currently beforementioned test fails on tru64cxx65 with the following error message: cxx: Error: ../libs/algorithm/string/test/container_test.cpp, line 94: #434 a reference of type "char *&" (not const-qualified) cannot be initialized with a value of type "char [4]" argument_test( ach1, "abc" ); The underlying problem is illustrated by the following code snippet: ---%<--- template< typename T > void argument_cv_test( const T& C, const string& strResult ) { } template< typename T > void argument_test( T& C, const string& strResult ) { } void foo() { char ach1[]="abc"; argument_cv_test( ach1, "abc" ); // ok argument_test( ach1, "abc" ); // not ok } --->%--- The line marked as not ok triggers the error. I tried to compile that code snippet with Comeau online and it succeeds. But I could not find a definitive answer in the C++ standard whether that code is legal or not. If it's legal, could anyone please provide me with a reference to the paragraph of the standard which applies here? I would need that to file a proper bug report to HP. TIA, Markus

2 2

Re: [boost] Re: Re: New design proposal for boost::filesystem
by Ferdinand Prantl 24 Aug '04

24 Aug '04

Hi Patrick, > Patrick Bennett wrote: > > Ferdinand Prantl wrote: > > What do you think about imbuing and codecvt-like approach in > > boost::filesystem for the names of the files? > I don't (personally) care for it. More and more libraries and standards are using UTF-8 (for good > reason) these days. It's a nice, simple, and flexible encoding. I have nothing against usage of UTF-8 if it suits the scenario well. I just say that it is not an encoding for all purposes. It is a multibyte one and so extremely inefficient for getting size, searching, etc. Why to prescribe it for all boost::filesystem users and force them to put recoding into their sources, when it can be achived inside the boost::filesystem as it is done in std::streams? I would like to have the boost filesystem as flexible as possible. Someone can work with filenames in std::string in current locale, in UTF-8 or a different locale, someone can use std::wstring with UCS-2 or UTF-16, etc. The question is, if such a flexibility is not so rare, that it rather spoils the interface. I don't think so. > Win32 doesn't support UTF-8 filenames natively. That's why boost::filesystem > would have to convert to/from UCS-2 along Win32 interface boundaries. > If you're concerned about other platforms, you shouldn't be. boost::filesystem > currently works only with latin encodings in ascii strings so no functionality > would be taken away. UTF-8 is not identical with the complete iso-8859-1 (latin1) codepage. Some code could be broken by accepting UTF-8 in the new version. > The UTF-8 representation of ascii strings is identical, so if you already use > ascii strings, nothing will change, and nothing will break. If you want your > application to be runnable in multiple countries though, an operating system > which boost::filesystem has translations defined for would be required. Linux > is UTF-8 natively (assuming the right environment variable is set), so > boost::filesystem would just pass everything through as-is. The Win32 poet > would have to make some simple conversions (Windows even has built-in functions > to perform this conversion) . Other platforms might have to have make other > conversions to/from UTF-8, but assuming that platform supports Unicode at all, > this is a no-brainer. Linux can be configured to support UTF-8 natively. However, it is not necessary and depends on your locale installation and configuration. By imbuing I meant the conversion "application filenames encoding" -> "machine filenames encoding". Instead of putting a platform dependent code into conditions, which does the translation, one could simply say "I am running in UTF-8, boost::filesystem, please understand it and do the system translation for me". Exceptoins could sourt out incompatibilities. boost::filesystem::imbue("UTF-8"); // more abstract than codecvt pseudocode :-) In this example an internal conversion into UCS-2 would be done on Windows, on Linux it would depend on the configured locale and on the other systems, which could support ASCII only, it would convert into ASCII only. However, it does not constrain the application from running wholly in wchar_t (e.g. UCS-2) or char (UTF-8 or something else), or does not force the user to write extra code for character conversion if it is not necessary. Ferda > Patrick Bennett

1 0

Proposal for New Template Metafunction 'is_iterator'
by Alex Chovanec 24 Aug '04

24 Aug '04

Is there a utility in Boost which determines at compile time whether or not a given type meets the most basic requirements for an iterator, without generating an error if the test fails? (This last part is crucial, so concept checks are insufficient.) I recently needed something like this, and I couldn't seem to find it in any of the libraries, so I went ahead and wrote a template metafunction called 'is_iterator' which gets the job done. It uses the same SFINAE techniques as the enable_if library. The declaration looks like this: template <typename T> struct is_iterator; The 'is_iterator' struct template is a model of the "integral constant expression" concept. Thus, 'is_iterator<T>::value' evaluates to true if-and-only-if type T defines iterator traits as well as overloaded operators with the following signatures: boost::iterator_reference<T>::type operator*(void) const; boost::iterator_pointer<T>::type operator->(void) const; T & operator++(void); T operator++(int); These seem to be the minimal requirements (i.e. Readable and Incrementable) according to the New Iterator Concepts. Ideally, T would also have to be a Copy Constructible type, but I don't know of a reliable way to detect this. Originally, i needed the ability to determine at compile time whether or not a given type meets the requirements for a Readable Lvalue iterator. The 'is_readable_iterator' and 'is_lvalue_iterator' template metafunctions work fine for this purpose, except that they both generate an error when passed a template argument that is not an iterator at all. Assuming I'm correct in stating that a utility like 'is_iterator' does not already exist in Boost, is there any interest in such a utility? Thanks, Alex

4 16

boost-sandbox question
by Eric Niebler 23 Aug '04

23 Aug '04

I'd like to make the documentation for xpressive available from the boost-sandbox project home page, like the FSM docs (http://boost-sandbox.sourceforge.net/libs/fsm/doc/index.html) According to the SourceForge docs, I should be able to copy my files there with scp like this: scp index.html eric_niebler@shell.sourceforge.net:/home/groups/b/bo/boost-sandbox/htdoc/libs/xpressive But when I tried that, I got "permission denied". Then I ssh'ed to shell.sourceforge.net and tried to mkdir /home/groups/b/bo/boost-sandbox/htdoc/libs/xpressive, but I got "permission denied" there, too. Do I need special permission to be able to do this? I already have CVS write access -- I guess that's not enough. Any hints? -- Eric Niebler Boost Consulting www.boost-consulting.com

4 3

boost::random overflow bug
by Samuel Krempp 23 Aug '04

23 Aug '04

while checking uniform_int.hpp, I spotted 2 weirdnesses in uniform_int.hpp that almost cancel themselves out, but not to the point that a contrived example is impossible. The heart of the problem is this loop : while(mult <= limit) { result += (eng() - bmin) * mult; mult *= result_type(brange)+result_type(1); // <-- overflow possible } where limit = (range+1)/(brange+1) the multiplication is almost always guaranteed not to overflow (that was the motivation to write the loop that way, I guess), except when mult==limit (which is reached when range+1 is a power of brange+1) in that case, the last multiplication assigns (range+1) to mult. And range+1 might in fact overflow. Now, it turns out in cases where range+1 overflows, limit is computed with special anti-overflow code, and there 's a bizarre condition there that looks like a bug : if(_range % result_type(brange)+1 == result_type(brange)) ++limit; instead of expected if(_range % result_type(brange+1) == result_type(brange+1)) ++limit; so in the end, most of the time when range==max, limit is assigned the value : range/(brange+1) instead of (range+1)/(brange+1). So it cancels out the first bug most of the time (maybe that is the reason for the bizarre code). but the limit will still be equal to (range+1)/(brange+1) for brange=1 (I'm not sure how useful a coin-flipper generator would be, but we never know..), and mult can then be made to wrap and reach 0 in the previous loop, which loops forever. I've attached a compilable exemple and suggested patch. I've thought it over carefully, the patch works in all situations. after the test on (mult==limit), it's all safe since mult is guaranteed to be > limit, and thus _range/mult will still be < brange+1, so the recursive call at the end is safe. -- Samuel

2 2

Shouldn't boost::filesystem be BOOST_POSIX on cygwin?
by Carlo Wood 23 Aug '04

23 Aug '04

At several places in the code we find something like: // BOOST_POSIX or BOOST_WINDOWS specify which API to use. # if !defined( BOOST_WINDOWS ) && !defined( BOOST_POSIX ) # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) || defined(__CYGWIN__) # define BOOST_WINDOWS # else # define BOOST_POSIX # endif # endif (As in for example boost/libs/filesystem/src/path_posix_windows.cpp) This sets BOOST_WINDOWS explicitely, as default, for cygwin - which is a POSIX operating system with a single root. This breaks a lot of code - if not all - of boost::filesystem. For example, the following code: #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; } indeed causes boost::filesystem::exists to return 'false' on cygwin while "/usr" definitely exists. The reason for that is obvious and looks like a clear bug: The code of boost::filesystem::exists is as follows: BOOST_FILESYSTEM_DECL bool exists( const path & ph ) { # ifdef BOOST_POSIX struct stat path_stat; if(::stat( ph.string().c_str(), &path_stat ) != 0) { if((errno == ENOENT) || (errno == ENOTDIR)) return false; // stat failed because the path does not exist // for any other error we assume the file does exist and fall through, // this may not be the best policy though... (JM 20040330) } return true; # else if(::GetFileAttributesA( ph.string().c_str() ) == 0xFFFFFFFF) { UINT err = ::GetLastError(); if((err == ERROR_FILE_NOT_FOUND) || (err == ERROR_PATH_NOT_FOUND) || (err == ERROR_INVALID_NAME)) return false; // GetFileAttributes failed because the path does not exist // for any other error we assume the file does exist and fall through, // this may not be the best policy though... (JM 20040330) return true; } return true; # endif } Therefore, with BOOST_POSIX undefined, "/usr" is passed directly to ::GetFileAttributesA() and that can obviously not work. My question is therefore: shouldn't BOOST_POSIX be forced to be defined on cygwin? -- Carlo Wood <carlo(a)alinoe.com> PS Please note that, looking at http://www.meta-comm.com/engineering/boost-regression/developer/summary.html nobody is running the testsuite on cygwin! How broken on cygwin is boost really?

8 21