- Boost - lists.preview.boost.org

VC++7.1 problem with swallow_assign multiple definitions
by Maciej Sobczak 12 Mar '04

12 Mar '04

Hi, I'm trying to port some code from VC++6.0 to VC++7.1. It is a DLL library that uses Boost.Python (from 1.30.2) to expose its interface for Python. It compiled without problems on VC++6.0, now I get during linking: file2.obj : error LNK2005: "struct swallow_assign::boost::detail::swallow_assign boost::tuples::`anonymous namespace'::ignore" (?ignore@?A0x3ab6eb85@tuples@boost@@3Uswallow_assign@detail@23@A) already defined in file1.obj and later: file2.obj : warning LNK4006: "struct swallow_assign::boost::detail::swallow_assign boost::tuples::`anonymous namespace'::ignore" (?ignore@?A0x3ab6eb85@tuples@boost@@3Uswallow_assign@detail@23@A) already defined in file1.obj; second definition ignored I found here: http://mail.python.org/pipermail/c++-sig/2002-November/002693.html the suggestion to use the latest tuple_basic_no_partial_spec.hpp file. No luck. I understand that it is the last line in this file that is a cause of problems. We would like to avoid upgrading to 1.31 if 1.30.2 can make it. Any suggestion for workaround will be highly appreciated. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

2 2

[serialization] serializable objects implemented in dlls
by David Tonge 12 Mar '04

12 Mar '04

Robert, I've made a small project which replicates the problems I was having yesterday. I think that part of the problem was that my solution for exporting the guids for shared_ptrs was like this... typedef boost::detail::sp_counted_base_impl<T*, ....> T_shared_ptr; BOOST_CLASS_EXPORT(T_shared_ptr); ...and if the typedef wasn't in scope where the streaming occurred then the streaming system didn't recognize that the sp_counted_base_impl<T*,...> was a T_shared_ptr. Anyway, I've resolved that by making a more complicated macro for exporting the guids, which doesn't use any typedefs. That's included in the attached archive as hack_shared_ptr.h. It isn't possible simply to do... BOOST_CLASS_EXPORT(boost::detail::sp_counted_base_impl<T*, ....>) ...because that contains a comma, and the preprocessor thinks you're passing two parameters to a macro which expects only one. Anyway, I think the new macro (HACK_SP_BOOST_CLASS_EXPORT(T)) avoids that problem. Now to my other problem. I wanted to investigate the serialization tools in the context of a larger project. My habit is to define my class interfaces in header files, like base_class.h, and provide their implementations in source files like base_class.cpp. I like my headers to be lightweight and include the minimum number of other header files in order that compilation times don't get out of hand. I had been including the BOOST_CLASS_EXPORT(T) commands in the headers but that means I have to include all of the archive headers, and export.hpp in every header, and that makes for slow compilations. My hope is that I can include all of those only in the implementation .cpp and put the BOOST_CLASS_EXPORT(T) there. I was also worried that if I included the BOOST_CLASS_EXPORT(T) in the header then every other .cpp which included that header would also try to register the guid for T - surely an unnecessary replication of effort. Having done all of this I found that my program would work fine if everything existed in a single EXE. However, if I implement them as a DLL containing my base_class and derived_class implementations and an EXE, which uses these classes, then things fail. In the attached .ZIP there is a VC7.1 solution which builds three different projects: single_project Contains all of my example source code, and builds a single .EXE which streams two shared_ptr<base_class> to file and then loads them back. One of the pointers contains a derived_class. dll_implemetation Contains implementations of base_class and derived_class. It also contains the BOOST_CLASS_EXPORT commands for those classes. This project builds a DLL which exports these classes. exe_using_dll Contains just the main() function. It should do the same as single_project does as the main() is the same. Single_project works fine. exe_using_dll fails when it tries to save the pointer to the derived_class. The failure is an unregistered_class exception. I've stepped through the code for exe_using_dll and I can see that the failure occurs when it tries to get extended type information for the derived_class (at line 297 of oserializer.hpp). However, I know that the class has been registered by the guid_initializer (at line 130 of export.hpp) because I put a breakpoint there, and saw initialization happen for base_class, derived_class and the shared_ptr versions of both. My suspicion is that the problem is caused by the serialization library using a static library, rather than a DLL. If the BOOST_CLASS_EXPORT commands updated a list contained in the static library then there would be one instance of this list statically linked into my DLL, and another in my EXE. Thus, the registration occurring in the DLL wouldn't affect the list used in the EXE. If this is the case then it's going to be quite inconvenient. It would mean one would have to BOOST_CLASS_EXPORT every class in every DLL where an instance of it (or a shared_pointer which might contain it) might be saved. If that were the case then I'd advocate making boost_serialization into a DLL, rather than a static library. I'd be grateful if you could take a look at my example, and let me know if there is something I can do to resolve my problems. Regards, David Tonge

2 2

RE: IO Formatters and lexical_cast
by Reece Dunn 12 Mar '04

12 Mar '04

Roland Richter wrote: >Reece, > I just checked out outfmt from the sandbox CVS and did some > tests to see whether it works together with lexical_cast. > The general idea is this: > Since lexical_cast internally uses a stringstream and its > associated operators>> and <<, it should be possible to > cast each type for which these operators are defined; > and since outfmt defines <</>> for STL container types, > I tried to combine them in order to convert between strings > and STL containers. > After some hassle, it works (under MS VC++ 7.0); see the > attachment. Issues: > 1) For reasons I don't completely understand, the compiler > could not find operator<< from stl_io_basic.hpp when > compiling lexical_cast.hpp. I had to hack detail/stl_io_basic.hpp > and put everything in namespace boost::detail (where > lexical_stream lives). > BTW, I'm not happy that stl_io.hpp includes everything from > vector to slist, and that so much code is put into the global > namespace. I am aware of this and am working on splitting the code into files like <boost/outfmt/stl/vector.hpp>, etc. There are three main areas that need to be split: [1] The STL I/O code [2] The type identification code [3] The get/put helpers for pair-like objects I have got a version of this to work with MS VC 7.x, but I have a compilation problem on borland and GCC 2.95.3-5 is generating a "signal 13" message on the regression tests (I think this is my cygwin setup, but haven't verified this). I have since been busy and haven't had a chance to look into these. I shall move the inserters and extractors to the boost::detail namespace and will look into the lexical_cast problem. > 2) The output operator puts spaces after '[', before ']', > and after each ','; whereas the input operator expects > no spaces at all; if spaces were present, a bad_lexical_cast > exception was thrown. I think it is really important that > operator>> can deal with an output which was generated by <<; > stated in terms of lexical_cast, > > lexical_cast<T>( lexical_cast<string>( t ) ) == t > > should hold for any T t. I stripped and skipped the spaces during the read operation to allow for the read operation to accommodate input variations, e.g. [ a, b ]; [a, b] and [ a,b ] would be read by the same formatter, making it easier to interoperate with data generated from other sources. I could make this a configurable option that does not strip the spaces by default. This should work. If you have examples where it doesn't, please let me know and I can add it into the regression tests. NOTE: There is a known defect when handling string data. This may be generating the problem you are encountering. If you run my regression tests (libs/outfmt/test/generate.sh) you should see it as a fail. I am aware of the problem and am looking into it. (This is made more difficult because the solution I implemented doesn't work with Borland :() > I intend to do some further tests, and to give more feedback during > the IO Formatters formal review (no date is fixed yet, or is it?) Thanks. I appreciate the feedback. I would like to get the string >// Copyright Roland Richter 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) > >#include <boost/test/minimal.hpp> > >#include <vector> >#include <string> > >#include <iostream> > >#include <boost/lexical_cast.hpp> >#include <boost/outfmt/stl_io.hpp> > >// 1) Namespace problem: >// e:\lib\boost_1_31_0\boost\lexical_cast.hpp(144): error C2679: binary >'<<' : >// no operator found which takes a right-hand operand of type 'const >_STL::vector<_Tp,_Alloc>' (or there is no acceptable conversion) >// with >// [ >// _Tp=double, >// _Alloc=_STL::allocator<double> >// ] >// >// => move everything in boost/outfmt/detail/stl_io_basic.hpp into >namespace boost::detail > >// 2) operator<< puts spaces after '[' and ',', whereas operator>> expects >// no spaces at all (otherwise, bad_lexical_cast is thrown). > > >void lexical_cast_and_outfmt_test() >{ > double foos[] = {0.7016, 0.9943, 1.3441, 1.1637, 0.5994, 0.0000, >0.0000}; > std::vector<double> fooVec( foos, foos + 7 ); > > std::string fooStr( "[ 0.7016, 0.9943, 1.3441, 1.1637, 0.5994, 0, 0 ]" >); > > // Output > std::string castedStr = boost::lexical_cast<std::string>( fooVec ); > BOOST_CHECK( castedStr == fooStr ); > > std::string fooStr_WithoutSpaces( >"[0.7016,0.9943,1.3441,1.1637,0.5994,0,0]" ); > > // Input > std::vector<double> castedVec > = boost::lexical_cast< std::vector<double> >( fooStr_WithoutSpaces ); > BOOST_CHECK( castedVec == fooVec ); >} > > >int test_main( int, char *[] ) >{ > lexical_cast_and_outfmt_test(); > > return 0; >} _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

2 1

metrowerks & vacpp
by Pavol Droba 12 Mar '04

12 Mar '04

Hi, I need somebody, that can help me out with a problem with codewarior and/or vacpp. Regressions are failing on these compilers due to incorrect classification of std::string and std::list. It seems, that the template signature for classes differs from standatard ( std::list<T,Alloct> ) and so, the sequence_traits are not recognizing these classes. Please, if somebody have an access to these compilers, check the singnature of them, and send it on the list. There might be another porblem as well, but I cannot figure it out right now. Regards, Pavol

3 4

BOOST_TRY like macros: time to add them?
by Pavel Vozenilek 12 Mar '04

12 Mar '04

Disabling try/catch through preprocessor when compiling without exception support was suggested e.g by Robert Ramey in: http://aspn.activestate.com/ASPN/Mail/Message/boost/1799735 Right now there are 3 libraries near review, each using their own set of similar macros: - circular_buffer - indexed_set - serialization The reasons to use macros instead of RAII is convenience and performance. Some compilers (BCB) do not allow try/catch with exceptions disabled so some solution is needed. It would be better to have and use standardized macros in Boost. Example: macros used in indexed_set: #if !defined(BOOST_NO_EXCEPTIONS) # define BOOST_INDEXED_SET_TRY try # define BOOST_INDEXED_SET_CATCH(x) catch(x) # define BOOST_INDEXED_SET_RETHROW throw #else # define BOOST_INDEXED_SET_TRY # define BOOST_INDEXED_SET_CATCH(x) if(0) # define BOOST_INDEXED_SET_RETHROW #endif Compiles w/o warnings on VC6+, BCB gives unreachable code warning (but I'll try to find workaround). /Pavel

12 32

Thread usage ?
by raja 12 Mar '04

12 Mar '04

Hi, I am trying out boost thread libraries with VC 7.1 Here are my includes : #define _MSC_VER 1310 #define BOOST_LIB_NAME "boost_thread" #define BOOST_LIB_DIAGNOSTIC "on"// Show library file details. #include <boost/config/auto_link.hpp> #include <boost/thread/thread.hpp> #include <iostream> I am getting the following error : c:\Boost\include\boost-1_31\boost\config\auto_link.hpp(269) : fatal error C1189: #error : "Mixing a dll boost library with a static runtime is a really bad idea..." Looks like I am missing some #define. Would appreciate if someone can let me know about this. Raja

2 1

Re: [boost] small addition to functional
by Fredrik 12 Mar '04

12 Mar '04

John Torjo wrote: >Hi all, >I think since member functions can be wrapped up as >functors, why not >same for member data? >Therefore, I think this could be a useful addition to >functional: <<snip>> >What do you think? I think Peter Dimov has already thought about this ;) Read the current mem_fn docs carefully and you'll find a data-case also. I agree it's very useful functionality. It was added fairly "silently" though (mid 2002 IIRC) which might have made people miss it(?). // Fredrik Blomqvist

4 7

function_equal and function::contains committed
by Douglas Gregor 12 Mar '04

12 Mar '04

Based on the discussion with Peter Dimov and Brian McNamara, I've checked in boost/function_equal.hpp with the new function_equal function. Overload boost::detail::function_equal_impl with a final argument of "int" in libraries that need to be compatible with older compilers. function_equal is documented as part of Boost.Function (because it needed a home somewhere inside BoostBook). function<> now has a contains() member function and uses function_equal instead of operator ==. Doug

1 0

Boost 2 - development in long term
by Pavel Vozenilek 12 Mar '04

12 Mar '04

Described is an idea how Boost can move on in the future. By future I mean 2-5 years, definitely not tomorrow or next month. Support for sub-standard compilers is taking away lot of time and energy of library writers. It also makes result code quite hard to understand and modify. Shouldn't only so many people be stuck with old equipment... What could be done: - create branch or fork of Boost in CVS, say Boost 2. - this project will have exactly the same structure as current Boost (directories/libraries/tests). - the project will be initially empty. - one by one, libraries will be removed of kludges, and workarounds (all of them, w/o exceptions) and copied into Boost 2. This includes: - fixes for nonconforming compilers (#ifdef BOOST_MSVC ...) - fixes for substandard STL (e.g. old Dinkumware) - fixes to deal with missing exception support - the converted libraries will be tested only with very recent compilers which are supposed to be conformant (GCC 3.4, VC8, Intel C++ 8, Metrowerks 9.2, Comeau). Why this may work: - all existing infrastructure (the tests) could be reused w/o change. - no need to deal with non-standard systems makes the cleanup less time consuming. - with no need to deal with non-standard systems it may be interesting work and fun for library writers, again. - compiler vendors may take it as incentive to improve their system, rather to rely on people will find workarounds. This effect can be already seen today. What would it require: - some site with latest compilers which would continually and automatically run all the tests. Not all people have access to newest tools. - the cleanup could be done by original library author or by someone who feels knowledgeable with it. - core libraries need to be identified and ported first. What to do with current Boost 1.XX: - the development will continue as it is now, as long as needed and feasible (my guess are few years more). - new libraries will be added into Boost 1.XX and may or may not contain legacy compilers support (as it is now). They will be eventually added into Boost 2 in 'clean state'. Problems: - how to keep both branches up to date with fixes and changes? This is real problem and should be solved by requiring every change in Boost 1.XX be considered for Boost 2. Backporting from Boost 2 to Boost 1.XX would be optional but rare. Hopefully most libraries are rather mature and don't go through major rewrites. Even if so, making clean version should be relatively painless. - should there be two sets of documentation? No, the documentation should not change except removing information about old systems support. This should be reasonably easy. - woudln't people with old compilers feel abandoned? Yes, but development for 1.XX should continue as long as needed/feasible. In few years hopefully support for VC6 and Borland will dimish. - there's no time to do yet more work: this should be long term project. Individual libraries can be ported at individual pace and independently. - code without kludges may not compile on ANY existing compiler: so be it. Next version of compiler will be hopefully better. Workarounds should be forbidden or very, very rare. Who will benefit of this all: - library writers who do not want to support old systems (less pressure on them) may spend more time with design. This gets more important if more powerfull/complex libraries will emerge. - users with new compilers (they can be more sure the library remains maintainable and may even be able to understand its inner, too). Their existing code using Boost should compile without changes. - compiler vendors will be able catch more errors. - standard comittee may be more interested in clean code. - if/when the world moves to C++0x it will be easier to move Boost there (this is beyond horizont of this idea though). What it it all fails: - Boost 1.XX should be unaffected by branching and could continue as if nothing had happened. I remind again this idea is about long term development of Boost. I think it has biggest effect for the effort spent. /Pavel

8 10

On bind::operator==, again
by Peter Dimov 12 Mar '04

12 Mar '04

What do you think this expression should do: bind(f, _1) == bind(g, _1) Currently, boost::bind returns f == g when f and g are of the same type, and fails at compile type otherwise (this is the equality comparison feature Doug requested). lambda::bind returns lambda(x) { return f(x) == g(x) }. It is clear that a future boost::bind that has limited lambda support would be even more problematic (as would be a future equality comparable boost.lambda). In that case, the expression will always compile, but do something different depending on whether f and g are of the same type. -- Peter Dimov http://www.pdimov.com

5 28

Explicit instantiation of boost::shared_ptr<SomeClasss>
by Greg Clayton 11 Mar '04

11 Mar '04

I am trying to do explicitly instantiate specific shared_ptr class for export from a Win32 DLL (currently with MSVC6, and eventually in VS2003). I have followed the Win32 rules found at: http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com… and have something like: // Provide the storage class specifier (extern for an .exe file, null // for DLL) and the __declspec specifier (dllimport for .an .exe file, // dllexport for DLL). // You must define EXP_STL when compiling the DLL. // You can now use this header file in both the .exe file and DLL - a // much safer means of using common declarations than two different // header files. #ifdef EXP_STL # define DECLSPECIFIER __declspec(dllexport) # define EXPIMP_TEMPLATE #else # define DECLSPECIFIER __declspec(dllimport) # define EXPIMP_TEMPLATE extern #endif EXPIMP_TEMPLATE template class DECLSPECIFIER boost::shared_ptr<SomeClass>; When I look through the exports, some needed class functions seem to be missing from the DLL, and linking fails. Most notable are: void boost::shared_ptr<SomeClass>::reset(SomeClass*) This function is declared in the shared_ptr header file as: template<class Y> void reset(Y * p); The reset function which does not take an argument is in the export list which is defined as: void reset(); // never throws And if I have a forward declaration of class followed by explicit instantiation, such as found below: class SomeClass; EXPIMP_TEMPLATE template class DECLSPECIFIER boost::shared_ptr<SomeClass>; The constructor that takes a class pointer is not generated: public: __thiscall boost::shared_ptr<class SomeClass>::shared_ptr<class SomeClass>(class SomeClass *) which is declared as: template<class Y> explicit shared_ptr(Y * p); Do I need to do extra explicit instantiations for the class members whose declarations start with "template<class Y>"? If so how does this syntax work? Any help or tips would be most appreciated. Greg Clayton

2 1

[math constants] a new approach (perhaps)
by Thorsten Ottosen 11 Mar '04

11 Mar '04

Dear boosters, I discovered something that at least was new to me. It's a simple way of coding floating point constants s.t. 1. no overhead at all 2. no order dependencies occur 3. the context in which the constant appears decides the precision of the constants [important in template code] 4. whenever a narrowing or widening conversion is required, explicit action must be taken by the programmer to determine what he wants 5. all precisions of the constants co-exist, so there is no need for several headers Example: #include "math_constant.hpp" #include <iostream> #include <cmath> #include <iomanip> using namespace std; template< typename T > void test(); int main() { cout << setprecision( 10 ); test<float>(); test<double>(); test<long double>(); // cout << pi; // ambiguous cout << float( pi ) << " " << double( pi ) << " " << (long double)( pi ); // ok // int i = pi; // ambiguous int i = float( pi ); // ok cout << sqrt( float( pi ) ); } template< typename T > void test() { T two_pi = T(2) * pi; two_pi = T(pi) + pi; // note: pi operator X() pi is ambiguous T plus = T(1) + pi; T minus = pi - T(1); T divide = pi / T(2); T all = pi + T(3) - T(pi) * pi / T(3); // also ambiguous cout << T( pi ) << " "; } Any comments are more than welcome. I know there are several proposals for defining math constants, but I don't see what the big problems are (so please help me understand them :-) ) br Thorsten

8 35

Re: [boost] Re: Boost 2 - development in long term
by JOAQUIN LOPEZ MU?Z 11 Mar '04

11 Mar '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> Fecha: Jueves, Marzo 11, 2004 9:19 pm Asunto: [boost] Re: Boost 2 - development in long term > Robert Geiman <rgeiman(a)buckeye-express.com> writes: > > > My point is, there will be a point in time where most compilers > > support template partial specialization, etc, and all that extra > code> that adds support to outdated compilers is way more trouble > than it'll > > be worth. We obviously aren't at that point right now, but at some > > point we will be. > > > > I don't think having Boost 2.x contain NO compiler hacks is a good > > thing, but it would be nice if there was a Boost feature list of all > > C++ features compilers must support to use Boost. These features > > could be added to the list when it's generally accepted that most > > compilers support these features, so then library writers can stop > > writing hacks to support those outdates compilers and even remove > > hacks to make the code smaller, cleaner, and easier to > understand and > > maintain. > Not that I love the idea of Boost 2 (B2 in the following), but maybe there's a reasonably manageable way to automate some of the process of converting Boost libraries into B2 form: * Identify the few compilers/stdlibs qualifying as B2 * Take the set of BOOST_NO_XXX macros in Boost.Config applying to any of the B2 compilers/stdlibs. Let us call these B2 defects. * Create an automatic tool that takes the source code of a B1 library and: - remove all #ifdef BOOST_NO_XXX sections where BOOST_NO_XXX is *not* a B2 defect. - remove all BOOST_WORKAROUND sections where the compiler/stdlib is not B2. This tool hopefully would give a compilable B2 source code, or at least something simple to get correct by manual postprocessing. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

bind vs. mem_fn with data members
by David Abrahams 11 Mar '04

11 Mar '04

This surprised me; should it have? #include <boost/bind.hpp> #include <boost/mem_fn.hpp> struct X { int y; }; int main() { boost::mem_fn(&X::y); // OK boost::bind(&X::y); // Error! } -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Re: [boost] Re: BOOST_TRY like macros: time to add them?
by JOAQUIN LOPEZ MU?Z 11 Mar '04

11 Mar '04

----- Mensaje original ----- De: Gennaro Prota <gennaro_prota(a)yahoo.com> Fecha: Jueves, Marzo 11, 2004 8:36 pm Asunto: [boost] Re: BOOST_TRY like macros: time to add them? > On Thu, 11 Mar 2004 12:21:09 -0500, David Abrahams > <dave(a)boost-consulting.com> wrote: > > >I think if you review this thread you'll see that there's no > argument. > No argument in favor of the macros? Yes, I see that. [...] Now I'm lost. Are you saying try-catch-rethrow macros for coping with BOOST_NO_EXCEPTIONS along the line proposed by Pavel are not good? Why not? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[indexed_set] volunteers wanted for testing
by Joaquín Mª López Muñoz 11 Mar '04

11 Mar '04

Review for indexed_set will take place in a couple of weeks; I'd like to ask for volunteers who want to try the tests on their compilers/platforms to make sure it works on a reasonable number of them. Current version has been tested for MSVC++ 6.0 SP5, ICC++ 7.1 and GCC 3.3.1 (cygwin). In particular, I'm interested in ICC+ 8.0 and MSVC 7.1, where prior versions of the library were tested without problems. Last version of the library (9.2) available at http://groups.yahoo.com/group/boost/files/indexed_set.zip Thank you in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

6 10

[filesystem] create_directory() & create_directories() return bool
by Beman Dawes 11 Mar '04

11 Mar '04

create_directory() no longer throws if the directory already exists. create_directory() and create_directories() now return a bool indicating if a directory was actually created. Both throw if the path argument exists and is not a directory. Docs and test cases updated accordingly. --Beman

1 0

[Signals] Added disconnect() based on function object equivalence
by Douglas Gregor 11 Mar '04

11 Mar '04

Since we're discussing the issue, I've added an experimental disconnect() member function to signals that allows one to disconnect equivalent slots, e.g., void foo(); void bar(); signal<void()> sig; sig.connect(&foo); sig.connect(&bar); sig.disconnect(&foo); // disconnects foo, but not bar We could also reconsider the += and -= syntax, since support for -= now makes some sense. Doug

2 1

iterator adaptors problem
by Pavol Droba 10 Mar '04

10 Mar '04

Hi, I have a problem with iterator_facade usage. Error is reported by Comeau and MIPSPro compilers: An error output can be found in regression tables: http://tinyurl.com/37mxz The compiler is reporting, that iterator_core_access cannot access the private equal() function, althought it has been marked as friend. My iterator class is publicaly derived from iterator_facade and privately from another templated class. Is it possible, that multiple inheritance creates the problem? Thanks for any help. Pavol

3 6

lambda BLL question
by Neal D. Becker 10 Mar '04

10 Mar '04

I was just trying out lambda and I have a question. I have a template class Ave template<typename in_t, typename Scale> struct Ave {...} It takes a function type argument "Scale". Here's a test: typedef typeof (_1 * 0.1) some_type; some_type func (_1 * 0.1); // Ave<double, typeof (_1 * 0.1)> ave (_1 * 0.1); << this will work Ave<double, some_type> ave (func); << this will also What is the preferred way to do this without "typeof"? How do I get the type returned by the lambda expression to feed to the template Ave?

2 1

[filesystem] create_directories not thread-safe?
by Vladimir Prus 10 Mar '04

10 Mar '04

I have an application which sometimes fails saying that it can't create a directory, because it already exists. The directory is created by fs::create_directories("run"); and the application is multi-threaded. It seems there's a race condition: if (ph.empty() || exists(ph)) return; // First create branch, by calling ourself recursively create_directories(ph.branch_path()); // Now that parent's path exists, create the directory create_directory(ph); After one thread checks that 'ph' does not exist, another one creates the same directory, so call to 'create_directory' fails. What can be done? Basically, adding a mutex for MT build and adding a warning to docs are the variants. Opinions? - Volodya

7 11

Re:[boost] Re: [serialization17] demo_fast_binary_archive.cpp CANNOT compile in gcc 3.3.3
by Robert Ramey 10 Mar '04

10 Mar '04

David Abrahams wrote: >"Allen Yao" <yaozhen(a)ustc.edu> writes: >> It seems that gcc does not allow this kind of template argument deduction: >> >> template <int N> >> void f(int a[N]) >> { >> for (int i = 0; i < N; i++) >> cout << a[i] << " "; >> cout << endl; >> } >> >> int main() >> { >> int a[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}; >> >> f(a); >> } >> >> The error message is: >> >> error: no matching function for call to `f(int[10])' > >> I would like to know how to fix this. Is there any workaround? >> Or if I am missing something? >You're missing something. Your declaration of f is equivalent to: > template <int N> > void f(int* a); >try: > template <int N> > void f(int a(&)[N]) ^^^ >instead. Hmm - that didn't work for me. But with the above hint I made the following compile and function with both VC 7.1 and gcc. template <int N> void f(int (& a)[N]) ^^^^ I had never been able to get demo_fast_binary_archive but could never figure out the reason - Mystery Solved ! Robert Ramey

2 1

another compilation problem
by Pavol Droba 10 Mar '04

10 Mar '04

Hi, I have another compilation problem, that I could use some help with. When I try to compile libs/algorithm/string/test/replace_test.cpp with gcc3.3.1 in release mode, it fails on out-of-memory error after allocating more then 400MB of memory. Older version of compiler were able to compile it, but it took something like an hour on 1Ghz Pentium III machine (As comparison, it takes just 2 minutes with vc7.1). I thought that it is just a bug in gcc optimization, but now it seems, that intel 8.0 has also similar problems. http://tinyurl.com/vbrx#algorithm/string-replace-intel-8.0-linux Have somebody encountered the similar problem? Thanks for help, Pavol

1 0

AIX vacpp question
by Pavol Droba 10 Mar '04

10 Mar '04

Hi, VACPP compiler is failing one of the test cases of the string_algo library. http://boost.sourceforge.net/regression-logs/cs-AIX-links.html#algorithm-re… It is the check for sequence traits. It seem, that trait classes did not get instantiated. Is there something special that this compiler needs, to avoid this problem? Other compilers do not seem to have a problem. It is not possible to instantiate all trait explicitly, because the template paramteres are mostly template again. I might have forgotten something, that other compilers just ignore. Can anybody give me some hints? Thanks, Pavol.

5 10

RE: [boost] Re: On bind::operator==, again
by Powell, Gary 10 Mar '04

10 Mar '04

> but my recent >attempts to use Lambda have been a dismal failure, mostly because of >subtle (and sometimes not-so-subtle) differences with Bind. For >example, Lambda doesn't seem to support get_pointer to dereference >through smart pointers. Yeah, in the past I've had to bind the operator->() to the smart pointer argument and that looks plain ugly! Plus its not good for generic programming, you end up having to do some template magic to get it to call the right version, (native pointer * -> vs smart_ptr::operator->() ) >I'm rather discouraged with how difficult it is to use standard >algorithms -- or even algorithms over sequences as opposed to >iterators -- to write something that could be coded quickly using dumb >loops. Yep, me too. That's why we wrote lambda in the first place. And that's why I'm promoting decltype and auto, and varidac templates, and why its imperative we figure out how to do anonymous functions. >I hold out some hope that the long-promised integration of >Lambda and Phoenix will help to solve these problems, but it's hard >to tell when (or if) that's actually coming. That's the trouble with day jobs and mortgages vs free coding. Just not enough time in the day to do everything. >Glum in Somerville, >Dave Don't be glum soon you will be in Sunny Australia! Yours, -Gary-

1 0

Re: [serialization17] demo_fast_binary_archive.cpp CANNOT compile in gcc 3.3.3
by Krishna Achuthan (TT) 10 Mar '04

10 Mar '04

David Abrahams wrote: >"Allen Yao" <yaozhen(a)ustc.edu> writes: > > > It seems that gcc does not allow this kind of template argument deduction: > > > > template <int N> > > void f(int a[N]) > > { > > for (int i = 0; i < N; i++) > > cout << a[i] << " "; > > cout << endl; > > } > > > > int main() > > { > > int a[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}; > > > > f(a); > > } > > > > The error message is: > > > > error: no matching function for call to `f(int[10])' > > > > I would like to know how to fix this. Is there any workaround? > > Or if I am missing something? > > You're missing something. Your declaration of f is equivalent to: > > template <int N> > void f(int* a); > > try: > > template <int N> > void f(int a(&)[N]) > ^^^ > instead. > I tried both the original problem and the proposed solution on VC 7.1 For the original problem I got the following error messages: c:\Krishna\Console\Console7.cpp(242) : error C2784: 'void f(int [N])' : could not deduce template argument for 'int [N]' from 'int [10]' c:\Krishna\Console\Console7.cpp(207) : see declaration of 'f' And when I tried the proposed solution, I got the following error messages: c:\Krishna\Console\Console7.cpp(209) : error C2988: unrecognizable template declaration/definition c:\Krishna\Console\Console7.cpp(209) : error C2059: syntax error : '&' c:\Krishna\Console\Console7.cpp(209) : error C2090: function returns array c:\Krishna\Console\Console7.cpp(241) : error C2783: 'void f(int *(__cdecl *)(void))' : could not deduce template argument for 'N' c:\Krishna\Console\Console7.cpp(209) : see declaration of 'f' I did manage to find a work-around, which goes like this: template<class T> struct F; template<class T, int N> struct F<T[N]> { void operator()(T a[N]) { for (int i = 0; i < N; i++) cout << a[i] << " "; cout << endl; } }; template<class T> void f(T& a) { F<T>()(a); } int main() { int a[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}; f(a); } Does it help? - Krishna Achuthan

1 0

Implementing WaitForMultipleObjects using boost
by M Shetty 10 Mar '04

10 Mar '04

Hi, Is it possible to simulate a behaviour like WaitForMultipleObjects using boost? If yes, kindly let me know. Thanks and Regards, M Shetty ___________________________________________________ Check-out GO.com GO get your free GO E-Mail account with expanded storage of 6 MB! http://mail.go.com

3 2

RE: Re: [boost] Implementing WaitForMultipleObjects using boost
by David Turner 10 Mar '04

10 Mar '04

Hi > I was checking out if I could use Boost to port code written > for Windows to Unix. > > The code has calls to WaitForMultipleObject which I would > need to replace. You can always do the same thing by means of conditions and signals. The paradigm is slightly different, though. //... boost::condition cond; object1.signal.connect(boost::bind(&boost::condition::notify_all, &cond)); object2.signal.connect(boost::bind(&boost::condition::notify_all, &cond)); cond.wait(mutex_lock); //... In this case, the objects have explicit signals (consider the parallel to windows kernel objects, which have an implicit "signal", i.e. their wait state). Regards David Turner

2 1

[serialization17] demo_fast_binary_archive.cpp CANNOT compile in gcc 3.3.3
by Allen Yao 10 Mar '04

10 Mar '04

It seems that gcc does not allow this kind of template argument deduction: template <int N> void f(int a[N]) { for (int i = 0; i < N; i++) cout << a[i] << " "; cout << endl; } int main() { int a[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}; f(a); } The error message is: error: no matching function for call to `f(int[10])' I would like to know how to fix this. Is there any workaround? Or if I am missing something?

2 2

vcapp & sgi regressions (string_algo)
by Pavol Droba 10 Mar '04

10 Mar '04

Hi, There are several problems reported by regression tests with the string_algo library on vcpp and mipspro compilers. I have no experience with these compilers and I wasn't able to figure out where the problem is from the error messages. 1. VCPP Following message is outputed: "/usr/vacpp/include/xmemory", line 120.23: 1540-0401 (S) The member "std::allocator<const char>::address(const_reference) const" is already declared. "/usr/vacpp/include/xmemory", line 118.17: 1540-0425 (I) "address" is defined on line 118 of "/usr/vacpp/include/xmemory". "/usr/vacpp/include/set", line 70.26: 1540-0700 (I) The previous message was produced while processing "class std::allocator<const char>". xlC -c -I/home/tk/boost_regression/boost -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"../bin/boost/libs/algorithm/string/test" -I"/home/tk/boost_regression/boost" -o "../bin/boost/libs/algorithm/string/test/find.test/vacpp/debug/find_test.o" "../libs/algorithm/string/test/find_test.cpp" It seems that the problem is triggered in my code by calling std::set<char>( char*, char* ) constructor. 2. MIPSPro In addtion to the following error in test framework: cc-1040 CC: ERROR File = /disk2/home/tk/boost_regression/boost/libs/test/src/test_tools.cpp, Line = 195 An identifier is expected. if( std::isprint( t ) ) ^ I'm getting similar error as with vcpp: cc-1377 CC: ERROR File = /usr/include/CC/stl_alloc.h, Line = 593 Member function function "std::allocator<const char>::address(std::allocator<const char>::reference) const" has already been declared. const_pointer address(const_reference __x) const { return &__x; } ^ A template was detected during header processing. instantiation of class "std::allocator<const char>" at line 92 of "/usr/include/CC/stl_set.h" instantiation of "std::set<const char, std::less<const char>, std::allocator<const char>>::set(const char *, const char *)" at line 74 of "/disk2/home/tk/boost_regression/boost/boost/algorithm/st ring/detail/classification.hpp" instantiation of "boost::algorithm::detail::is_any_ofF<const char>::is_any_ofF(const char (&)[4])" at line 201 of "/disk2/home/tk/boost_regression/boost/boost/algorithm/st ring/classification.hpp" instantiation of "boost::algorithm::detail::is_any_ofF<const char> boost::algorithm::is_any_of(const char (&)[4])" at line 143 of "../libs/algorithm/string/test/find_test.cpp" Can anybody help? Thanks, Pavol.

4 5

What header is transform_iterator in?
by John Maddock 10 Mar '04

10 Mar '04

OK, I know the answer, but the doc page for transform_iterator doesn't say, even the example doesn't include any headers - I had to follow the link to the example source to double check. Other doc pages may have the same issue, I haven't checked. John.

1 0

Re: Re: [boost] Implementing WaitForMultipleObjects using boost
by M Shetty 10 Mar '04

10 Mar '04

Hi, I was checking out if I could use Boost to port code written for Windows to Unix. The code has calls to WaitForMultipleObject which I would need to replace. Thanks and Regards, M Shetty -----Original Message----- From: "Jeremy Maitin-Shepard"<jbms(a)attbi.com> To: boost(a)lists.boost.org Date: Tue Mar 09 17:57:04 PST 2004 Subject: Re: [boost] Implementing WaitForMultipleObjects using boost >No, but why would you want to simulate it? > >-- >Jeremy Maitin-Shepard >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___________________________________________________ Check-out GO.com GO get your free GO E-Mail account with expanded storage of 6 MB! http://mail.go.com

1 0

_POSIX_C_SOURCE redefinition warning with python 2.3 and boost-1.31.0
by Peter Hornby 10 Mar '04

10 Mar '04

Sorry if this has been mentioned before. the following patch against boost-1.31.0 silences the warnings on linux, but I have not tested that there are no side-effects on other compilers. --------------------------------START PATCH------------------------ Index: boost/python/detail/wrap_python.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/detail/wrap_python.hpp,v retrieving revision 1.17 diff -p -r1.17 wrap_python.hpp *** boost/python/detail/wrap_python.hpp 1 May 2003 05:19:47 -0000 1.17 --- boost/python/detail/wrap_python.hpp 1 Mar 2004 05:36:49 -0000 *************** *** 23,28 **** --- 23,29 ---- // // Python's LongObject.h helpfully #defines ULONGLONG_MAX for us, // which confuses Boost's config + // Also kill any definition of _POSIX_C_SOURCE so Python.h can determine it. // #include <limits.h> #ifndef ULONG_MAX *************** *** 34,39 **** --- 35,44 ---- #ifndef ULONGLONG_MAX # define BOOST_PYTHON_ULONGLONG_MAX_UNDEFINED #endif + #ifdef _POSIX_C_SOURCE + # undef _POSIX_C_SOURCE + #endif + // // Get ahold of Python's version number --------------------------------END PATCH------------------------ Index: boost/python/detail/wrap_python.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/python/detail/wrap_python.hpp,v retrieving revision 1.17 diff -p -r1.17 wrap_python.hpp *** boost/python/detail/wrap_python.hpp 1 May 2003 05:19:47 -0000 1.17 --- boost/python/detail/wrap_python.hpp 1 Mar 2004 05:36:49 -0000 *************** *** 23,28 **** --- 23,29 ---- // // Python's LongObject.h helpfully #defines ULONGLONG_MAX for us, // which confuses Boost's config + // Also kill any definition of _POSIX_C_SOURCE so Python.h can determine it. // #include <limits.h> #ifndef ULONG_MAX *************** *** 34,39 **** --- 35,44 ---- #ifndef ULONGLONG_MAX # define BOOST_PYTHON_ULONGLONG_MAX_UNDEFINED #endif + #ifdef _POSIX_C_SOURCE + # undef _POSIX_C_SOURCE + #endif + // // Get ahold of Python's version number

2 2

Re:Re: [boost]Re: Re: [serialization] non-conformance
by Robert Ramey 10 Mar '04

10 Mar '04

>Robert Ramey wrote: >> This exchange illustrates the problem rather nicely. Its not clear >> to me from the name "aligned_storage" that its meant to do the same >> job as "stack_allocate" and in fact is easily confused with other >> boost functions. I've been able to find no documentation nor test >> nor other information. The only place its used is in variant.hpp but >> its not mentioned in the documentation of that either. There is no >> statement in the header itself as to what it does and the code is >> sufficiently non-trivial that it's not obvious what its supposed to >> do. The fact that it has a parameter than stack_allocate doesn't >> need also suggests that it's intended purpose is different from that >> of stack_allocate. The previous post referred to alignment_of rather than aligned_storage which seems to me to unrelated. Are they related in some non-obvious (to me) way? What's incorrect about my statement above? >It doesn't, see aligned_storage's "Rationale" subsection in >http://tinyurl.com/39asx. Is this part of boost documentation and tests? Robert Ramey

4 3

RE: [boost] First lambda
by Powell, Gary 09 Mar '04

09 Mar '04

> std::vector<X> xs(10); > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > _1 + (&_2) ->* &X::count); >This program adds up the "count" members in a vector of X objects. >Now, no offense intended, but this is nasty. There's just too much >extra syntax required for something so simple, plus you have to make >the type into a pointer just so you can dereference it Before I >realized I needed to take the address of _2, I had: > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > _1 + _2 ->* &X::count); >which is only slightly better (but incorrect). I realize that I can >use bind: > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > _1 + bind(&X::count,_2)); >but that's slightly counter-intuitive since the order of the target >object and its member pointer are reversed. It'd be nice to allow >something like: > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > _1 + _2.at(&X::count)); >while if _2 were to refer to a pointer type, we could say: > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > _1 + _2->at(&X::count)); >Dave Abrahams I tried to overload operator->() for a lambda object, but the C++ rule is that it _Must_ return a pointer, in this case to an object which has a member fn "at". So you are toast, because I couldn't figure out how to hold a pointer to a lambda object and recognize it as a delayed object holding a member pointer to vector<X>::at. When we aren't given the information about the member pointer. I'm working on a paper to allow us to overload operator.(), but the last time it was discussed in committee it burned the hair off of nearby dogs and scared children. So I'm waiting until the Redmond meeting so I won't have far to drag my burnt carcass home. Meantime it again highlights that a core language change to allow anonymous fns is needed so this whole mechanism of BLL can go away. // PROPOSED CHANGE IN SOME FUTURE PAPER unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, long (long lhs, X const &rhs) // inline fn with no name. { return lhs + rhs.count; } ); Yours, -Gary-

12 35

Re: RE: [boost] Re: Formal Review: Circular Buffer
by JOAQUIN LOPEZ MU?Z 09 Mar '04

09 Mar '04

----- Mensaje original ----- De: "Powell, Gary" <powellg(a)amazon.com> Fecha: Martes, Marzo 9, 2004 10:55 pm Asunto: RE: [boost] Re: Formal Review: Circular Buffer > > The VTL library does it IMO correctly, allowing that if there is > an operation > T1 F T2, then > > V1 F V2 compiles. Otherwise you just force the user to write what > should be library > code. > > (Obviously swap can't do this unless the Allocators are the same.) > I don't quite get you here. I think the two allocator types cannot be equal: the first allocator allocates T1's, the second T2's. I might be totally misinterpreting you, of course. > template<class T1, class T2, class Alloc> > void swap( circular_buffer<T1, Alloc> &lhs, circular_buffer<T2, > Alloc> &rhs) > { > // do an element by element swap. > // and insert for the leftover elements. > } > IMHO doing an elementwise swapping is very ill-behaved. It would reduce to repeatedly calling something like: template <typename T1,typename T2> void swap_different(T1& x,T1& y) { T1 tmp(y); x=y; y=x; } So, for swap to have *some* exception safety the assignment operators must not throw, which seems too restrictive (think types with dynamic allocation). Maybe things can be improved a bit with something along this line: template<class T1, class T2, class Alloc1, class Alloc2> void swap( circular_buffer<T1, Alloc1> &lhs, circular_buffer<T2, Alloc2> &rhs) { circular_buffer<T1, Alloc1> new_lhs; // copy rhs into new_lhs circular_buffer<T2, Alloc2> new_rhs; // copy lhs into new_rhs lhs.swap(new_lhs); // nothrow rhs.swap(new_rhs); // nothrow } There is a final annoyance, though: in many cases the code can emit a narrowing cast warning (if assigning an int to a short, for instance.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Re: Formal Review: Circular Buffer
by Powell, Gary 09 Mar '04

09 Mar '04

No, but just because the standard libraries scr*wed up is no reason to perpetuate the mistake. It's the rule of unexpected consequences. Is circular_buffer<int> x = { 1, 2, 3}; circular_buffer<short> y = { 1, 2 ,3}; x == y ?? or not? Sure looks like it should work. The VTL library does it IMO correctly, allowing that if there is an operation T1 F T2, then V1 F V2 compiles. Otherwise you just force the user to write what should be library code. (Obviously swap can't do this unless the Allocators are the same.) template<class T1, class T2, class Alloc> void swap( circular_buffer<T1, Alloc> &lhs, circular_buffer<T2, Alloc> &rhs) { // do an element by element swap. // and insert for the leftover elements. } template<class T1, class Alloc> void swap<T1, T1, Alloc> ( circular_buffer<T1, Alloc> &lhs, circular_buffer<T1, Alloc> &rhs) { // swap the whole container. lhs.swap(rhs); } Yours, -Gary- -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Pavel Vozenilek Sent: Tuesday, March 09, 2004 11:52 AM To: boost(a)lists.boost.org Subject: [boost] Re: Formal Review: Circular Buffer "Powell, Gary" <powellg(a)amazon.com> wrote > Shouldn't the comparison functions allow the types to differ? > > circular_buffer<T, MyAlloc> x; > circular_buffer<S, YourAlloc> y; > > bool b = x == y; for where the operator T == S is valid? > And what does the allocator have to do with it? > Hmm, do you know a STL implementation/some container with this feature? It may be often bug to compare containers with different types. /Pavel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

RE: [boost] Formal Review: Circular Buffer
by Powell, Gary 09 Mar '04

09 Mar '04

Shouldn't the comparison functions allow the types to differ? I mean don't they still lexigraphically compare as long as there is a comparison function F that a F b for each element exists circular_buffer<T, MyAlloc> x; circular_buffer<S, YourAlloc> y; bool b = x == y; for where the operator T == S is valid? And what does the allocator have to do with it? Therefore IMO, all of the comparison functions should change from template< typename T, typename Alloc> bool operator F ( circular_buffer<T, Alloc> &lhs, circular_buffer<T, Alloc> &rhs); to template< typename T1, typename Alloc1, typename T2, typename Alloc2> bool operator F ( circular_buffer<T1, Alloc1> &lhs, circular_buffer<T2, Alloc2> &rhs); Yours, -Gary- powellg(a)amazon.com

2 1

RE: [boost] Formal Review: Circular Buffer
by Powell, Gary 09 Mar '04

09 Mar '04

documentation bug: Definition of data() Shouldn't that be only in the doc for the circular buffer space optimized? It isn't part of the adaptor interface. Also this may be old ground, but any particular reason you are not using a std::vector as the underlying container, coupled with the iterator adaptors? On the positive side, I like the functionality. I use this sort of container all the time. I often have things for which I can only hold N and when I have N+1, I need to purge the oldest. Yours, -Gary-

2 1

more lambda woes
by David Abrahams 09 Mar '04

09 Mar '04

Lambda docs say: "When an actual argument is supplied for a placeholder, the parameter passing mode is always by reference" Yet when I changed the following code from using boost::bind to boost::lambda, I got complaints that Field is an abstract class and can't be copied. void (self_t::* insert_)(Field const&) = &self_t::insert; std::for_each(fields.begin(), fiends.end(), bind(insert_, this, _1)); What gives? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 3

RE: [boost] Formal Review: Circular Buffer
by Powell, Gary 09 Mar '04

09 Mar '04

I have reviewed Jan Gaspar's circular buffer. What is your evaluation of the design? It's a useful container. I've hacked up a couple in my coding career and this one is very nice. Although I've usually implemented them as an adaptor to a container. This separates the container that I've optimized for the problem from the circular nature of it. What is your evaluation of the implementation? I was able to run the sample code with gcc 3.2 no problem. What is your evaluation of the documentation? Doc's are fine. What is your evaluation of the potential usefulness of the library? Useful for both embedded systems and those with a stack that needs to be limited. With a smart destructor you can push objects into the circular buffer holding them until you are either "full", or have time to deal with them. How much effort did you put into your evaluation? Shallow-depth study? Shallow study. One evening. Are you knowledgeable about the problem domain? Somewhat. I used to program for embedded systems, games, where memory is limited. We used this sort of buffer to constrain the the art resources from taking over the available memory. Other comments: Do you think the library should be accepted as a Boost library? I vote for acceptance with or without the suggested change about adapting a container. The comparison operators do need to be fixed though to compare two types. i.e. circular_buffer<int> x = { 1, 2, 3 }; // pseudo code. circular_buffer<short> y = { 1, 2,3 }; x == y -> true However I would prefer that the underlying container be part of the interface. But that's not a fixed in stone opinion.

1 0

Re: [math constants] C++ Language gurus views
by Krishna Achuthan (TT) 09 Mar '04

09 Mar '04

I was able to cut the code down to this and got an ICE in VC 7.1: struct Base { template <typename T> operator T() { return T(); } }; struct Derived : Base { /* template <typename T> operator T() { return T(); } */ }; int main() { float f = Derived(); //ICE here } Notice that once you uncomment the function in the Derived class and hide the function in Base class, the ICE goes away. - Krishna Achuthan > Message: 10 > Date: Mon, 8 Mar 2004 21:15:27 +0100 > From: Bronek Kozicki <brok(a)rubikon.pl> > Subject: [boost] Re: [math constants] C++ Language gurus views > neededandCodewarrior & Comeau testers > To: boost(a)lists.boost.org > Message-ID: <g2gf20rte3qn.tx7plyoud13i.dlg(a)40tude.net> > Content-Type: text/plain; charset="us-ascii" > > On Mon, 08 Mar 2004 10:47:49 +0100, Daniel Frey wrote: > > but that's just a wild guess. I just seem to remember that I read about > > the VC having a small problem there. If this is in fact the problem, we > > might be lucky as my newest version no longer uses this conversion, > > instead I use a get<T>-function. > > I can reproduce this ICE on following code: > > template<template <typename> class F> struct constant > { > template <typename T> operator T() const > { > return F <T>()(); > } > }; > > template <typename T> struct map_type; > > template <template<typename> class F, typename T> struct constant_value > { > T operator()() const > { > return F<typename ::map_type<T> ::type>()(); > } > }; > > template <typename T> struct pi_value : constant_value< ::pi_value, T > > {}; > template <> struct pi_value <float> {float operator()() const {return > 3.14;}}; > > struct pi_t : constant <pi_value> {} const pi = pi_t(); > > int main() > { > const float f2 = pi; // ICE here > } > > possibly it can be made smaller, I just finished cutting it at this > moment and sent to private MS newsgroup asking for support. Comeau and > GCC both happily accept this code, and it just looks OK. However it's > bit too complicated and I'm too tired to look into it deeper. I hope > someone from VC71 developers will now take a look. VC71 quite often > bulks on invalid code, but if this one is valid (I certainly think so) > then we have issue that have to be fixed . In the meantime if you can > come up with some variations of the above, just send an email and I will > test it. BTW: problem with operator() and VC71 is that it does not > always recognize operator() as function, in context of pointer to member > function. However it does not ICE on that problem. > > Regards > > > B.

1 0

regresion tests - library name
by Pavol Droba 09 Mar '04

09 Mar '04

Hi, Where does the name of the library in the regression test table come from? string_algo library is reported as "algorithm", yet it is not the name used in Jamfiles. I assume, that the name comes from the directory name. This is not the best solution, because there can be more libraries residing in one subdirectory. (Although string_algo is probably just the first example). Isn't is possible to extract the name from the test-suite specified in Jamfile? This would make more sense. Regards, Pavol

2 1

RE:RE: [boost] [serialization] shared_ptr and binary archives
by Robert Ramey 09 Mar '04

09 Mar '04

David, This has been reported before but I've been unable to track it down. My personal guess is that it's a bug with VC 7.1 . Now that you've got a small test which demonstrates the problem, it should be easy to verify by using your test case under gcc. The attachement didn't show up on the list so please send it to me directly. Robert Ramey David Tonge wrote: >Now let me introduce a new problem. I seem to have uncovered another bug. >Using the workaround above I can demonstrate expected behaviour with text >archives. However, if I try to serialize a shared_ptr<A> containing a B* >to a BINARY archive then I get an assertion failure (puzzlingly in >basic_text_oarchive.hpp - line 133). I don't have any problems serializing >shared_ptr<A>s containing A*s to binary archives, and I don't have any >problems at all with text archives. >The file I've attached is a heavily modified version of demo_shared_ptr.cpp >which performs four tests: > 1. Serialize shared_ptr<A>s containing A*s to and from text archives. > 2. Serialize shared_ptr<A>s containing B*s to and from text archives. > 3. Serialize shared_ptr<A>s containing A*s to and from binary archives. > 4. Serialize shared_ptr<A>s containing B*s to and from binary archives. >Tests 1-3 all work fine. Test 4 fails as described. >I'd appreciate it if others with an interest in the serialization library >could take a look. I can quite believe that it's an error on my part but I >haven't been able to spot it yet.

1 0

Re:[boost] Re: Re:Serialization17 - assert in basic_text_oarchive.hpp
by Robert Ramey 09 Mar '04

09 Mar '04

Jeff Flinn wrote: >Another data point. I've separated binary/text/xml serialization into three >.cpp files so that each of the three compilation units only deals with a >single archive type. No doubt that works around the issue but it doesn't make ME feel much better. The problem of "confused" template parameters was a big one with VC 6.0 . I had hoped all those issues had been resolved with VC 7.1. Now I'm not so sure. I did make a small example which included several archive types but I had no problem with it so I'm kind of stuck. >The following results: > Save Load ---- ---- >Bin Pass Pass >Txt Pass Pass >Xml Pass Fail >Where Fail is an assertion in basic_xml_archive.ipp Line: 29. >Attached is the offending xml archive, if it will offer any insight. This is most likely a bug of my own in generating/parsing xml archives. Again, I'm going to need a smaller test case. However, your example does illustrate the need to replace the assertions with exceptions in case the XML has been tampered with - I'll add these in. Robert Ramey

3 4

Re: boost::any: explicit constructor?
by Kevlin Henney 09 Mar '04

09 Mar '04

In message <uk727uuvv.fsf(a)boost-consulting.com>, David Abrahams <dave(a)boost-consulting.com> writes >>> >>>The conversion to boost::any isn't a widening conversion in the usual >>>sense, though, is it? Normally, a widening conversion preserves not >>>only the information but the *interface* of the original data -- you >>>wouldn't consider an implicit conversion from int to string a widening >>>conversion, would you? >> >> Your assumption is not quite correct: most widening conversions are >> not interface preserving. > >So you're saying it's not even a little correct, it sounds like. Can >you give some examples of non-interface-preserving widening >conversions? T * to void *, derived * to base *, int (32 bit) to double (64 bit), T * to const T *, etc. Widening conversions are in the direction of the supertype, hence they often have a subset of the interface of source type. The corresponding narrowing of the interface with the widening of the type is not always the case, eg an int to long is effectively interface preserving -- the same set of operators is supported for both types. Kevlin -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

3 8

Re: std_min/std_max reference return value is problematic with boost::interval
by Michael Stevens 09 Mar '04

09 Mar '04

Eric, Guillaume, (sorry about the previously half send while I was composing) Thanks for the info, I think the solution is partly simple, partly complex. > Eric: What strikes me as odd with this overload, though, is that max(a,b) in > this case will return something that is not equal to either a or b. That > seems counter-intuitive. Is this right? Firstly it is now clear to me (as stated in the documentation) that max(interval_a,interval_b) is not std::max. The difference in semantics is however only represented by the difference in return value. > Me: Why gcc thinks it needs a temporary here is beyond me. I was confused here. I thought std_max would be choosing the std::max overload in this case and not the boost::numeric::interval::max overload. The later is however more specialised. > Guillaume: Consequently, since std_max has been defined so that it > returns a reference, it can't be used when one argument is an interval > and GCC is right to complain. GCC is correctly complain. The new std_max/ std_min should ONLY be used as a where we specifically require std::max/min. Therefore the committed changes to interval (particular utility.hpp) are incorrect. > Eric: The fix is to detect whether the unqualified call to max returns an > lvalue or not and define the return type of std_max appropriately. Easy > enough. > Given that std::max/min in the standard are defined to return a reference this fix would seem unnecessary/wrong. We don't want to use boost::std_max in this case. > However, in the particular case of uBLAS, the problem lies elsewhere > imho. At lines 620-621, 688-689, 753-754 of ublas/traits.hpp in the > equals function, uBLAS should not be using the norm_inf function. Indeed > norm_inf relies on abs(interval); and what is really needed is a > norm_inf_for_equals function that would rely on norm(interval). The same > problem will also appear later with complex intervals. Thanks for following this up and the info. The maths needs checking here. Lets see what Joerg thinks. For a Boost 1.31.x release we should change the mentioned lines in traits.hpp to use boost::numeric::interval::min/max so we at least do not have a regression. Michael -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

2 1

Re: std_min/std_max reference return value is problematic with boost::interval
by Michael Stevens 09 Mar '04

09 Mar '04

Eric, Guillaume, Thanks for the info, I think the solution is partly simple, partly complex. Firstly it is now clear to me (as stated in the documentation) that max(interval_a,interval_b) is not std::max. The difference in semantics is however only represented by the difference in return value. The new std_max/ std_min should ONLY be used as a -- ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

1 0

Boost.Iterator and const-qualification of value_type
by Joaquín Mª López Muñoz 09 Mar '04

09 Mar '04

A side note in iterator_facade docs says that the standard requires that an iterator's value_type not be const-qualified. I've skimmed through the std and, though this requirement seems reasonable enough, I haven't found any excplicit statement about it. Clues? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Updates to the Review Schedule/Upcoming Reviews
by Jeff Garland 09 Mar '04

09 Mar '04

I've recently checked in a new version of the review schedule. So you don't have to go to CVS and look, here is the set up upcoming reviews: Library Author Review Mgr Dates Circular Buffer Jan Gaspar Pavel Vozenilek 2004 Mar 5-15 Indexed Set Joaquín M López Muñoz Pavel Vozenilek 2004 Mar 20-30 Assignment Thorsten Ottosen Tom Brinkman 2004 Apr 1-11 Serialization Robert Ramey Jeff Garland 2004 Apr 13-20 Container Traits Thorsten Ottosen Hartmut Kaiser 2004 Apr 28-May 7 Tribool Douglas Gregor - - More IO Daryle Walker - - Iostreams Jonathan Turkanis - - Output Formatters Reece Dunn - - Pointer Containers Thorsten Ottosen - - Named Params David Abrahams & Daniel Wallin - - Wave Hartmut Kaiser - -

3 3

[Boost-bugs] [ boost-Bugs-912368 ] boost::tokenizer implicit typename
by SourceForge.net 08 Mar '04

08 Mar '04

Bugs item #912368, was opened at 2004-03-09 00:46 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=912368&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Ravnsgaard Riis (ravnsgaard) Assigned to: Nobody/Anonymous (nobody) Summary: boost::tokenizer implicit typename Initial Comment: boost::tokenizer gives warnings on gcc 3.3.1 (MinGW build) about implicit typenames in two typedefs in offset_separator::operator() and char_separator::operator(). Both typedefs look like: typedef tokenizer_detail::assign_or_plus_equal< tokenizer_detail::get_iterator_category< InputIterator>::iterator_category> assigner; I changed them to: typedef tokenizer_detail::assign_or_plus_equal< typename tokenizer_detail::get_iterator_category< InputIterator>::iterator_category> assigner; I.e. I added a "typename" keyword inside the typedef. g++ warned that "Implicit typename is deprecated". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=912368&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Futures revisited
by Slawomir Lisznianski 08 Mar '04

08 Mar '04

Hello, During discussions on possible extensions to Boost.Threads, concept of Futures came up rather frequently. Below, I’d like to introduce a particular implementation available at www.rhapsodia.org of which requirements were defined as follows: 1. Provide means to register exception types with a "Future Registry". Rationale: I find it imperative that users should not have to define a list of exception types on each invocation yielding a Future object. Instead, provide the ability to register exception types with a Future Registry and bundle it with Future objects. I feel that compile time registration should be sufficient. 2. Work under the assumption that asynchronous invocations returning Futures and system threads are not coupled. In particular, Futures implementation should not relay on joining with a particular thread to perform synchronization for returning results. Rationale: Although most prevalent, the technique of joining with a particular thread to synchronize on returning result is too limiting. It implies that each task be run on a dedicated thread, specially created to handle it and destroyed to meet with a caller using a Future. Although this approach may be adequate under certain conditions, it generally tends to be expensive on system resources and disorganizes the application. For example, it’s impossible to control the number of concurrently running threads. It may also perform poorly if executed code happens to run shortly as the overhead of creating a thread and cleaning up after it may be significant. More robust approach is to use a queue and a thread pool for running tasks. This adds complexity on the synchronization side, as we can no longer rely on a lifetime of a thread to join with Future’s result. 3. Ability to utilize Futures with arbitrary code without explicit support for them. Rationale: For implementation to be widely adopted, it should be possible to turn just about any function call into a Future-armored asynchronous invocation. No explicit thread synchronization primitives should be used as well. 4. Implement using existing Boost.Threads facilities only. Rationale: Boost.Threads library provides enough support to implement Futures paradigm that meets requirements listed here. 5. STL and Boost compatible. For example, storing Futures in an STL container. Be strongly typed. Futures implementation and usage patterns must naturally coexist with STL and Boost code. Additionally, compile-time type validation is key to safer code. Attached is a sample file from Rhapsodia library showing the use of Futures. Regareds, Slawomir Lisznianski [ www.rhapsodia.org ]

2 1

Blipping back on the radar... hopefully.
by Hubert Holin 08 Mar '04

08 Mar '04

Somewhere in the E.U., le 08/03/2004 Bonjour After what seems like an eternity, I may perhaps be able to get back to work on the math libraries I contributed here. For the last year or so, I believe, I could not even find the time to lurk in the newsgroup, that following about a year in which I barely had time to just lurk. I also fear mail sent thru my bigfoot redirector may have been chewn up befor I got it (or else nobody compalined about these libraries ;-) ). I know I have a lot off "Cat Soup" to do (eat :-) ?), and to make things more interesting, I may have to move to Xcode (gcc) as a primary platform rather than CodeWarrior (I may no longer be able to personnaly afford the updates, and MetroWerks has made it impossible for me to update at work by requiring they be purchased thru the internet... and that's corporately impossible where I work). As I had locally incorporated patches which I fear were never uploaded, some to squash incompatibilities, I apologize for the inconvenience. Not all the fires are out, so to speak, but most are now somewhat under control. I should have three weeks with a modicum of time to set a few things straight, at least. Merci Hubert Holin

2 1

std_min/std_max reference return value is problematic with boost::interval
by Michael Stevens 08 Mar '04

08 Mar '04

Eric, The recent changes to the new std_min/std_max caused some unexpected problems in uBLAS. I have narrowed them down to support for boost::numeric::interval in uBLAS. This is picked up by ublas/libs/test7. This test is however not at present part of the regression run. The new std_max (or std_min) is implemented by returning a constant reference to the return value of std::max. This should be OK as std::max similarly returns a const reference to one of its const reference parameters. For gcc this causes some problems when the type is a boost::numeric::interval. The test case is very simple. #include <boost/numeric/interval.hpp> #include <boost/minmax.hpp> int main() { boost::numeric::interval<float> a,b,c; c = boost::std_max(a, a); } gcc (2.95.3 and 3.3.1) is only warning "returning reference to temporary". I am surprised this doesn't show up in more cases. Why gcc thinks it needs a temporary here is beyond me Michael -- ___________________________________ Michael Stevens Systems Engineering ___________________________________

3 3

RE: [boost] Win32 regressions
by Rozental, Gennadiy 08 Mar '04

08 Mar '04

> Test test_tools_test - Regressions on VC++ 6.0 and 7.0. I did not make any changes lately. But from error messages it seems like has something to do with boost::bind. Peter could you please take a look. Gennadiy.

2 2

First lambda
by David Abrahams 08 Mar '04

08 Mar '04

I just tried using the lambda library for the first time. Here's what came out of it, after some struggle: #include <boost/lambda/lambda.hpp> #include <vector> #include <numeric> using namespace boost::lambda; struct X { X() : count(1) {} unsigned long count; }; std::vector<X> xs(10); unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, _1 + (&_2) ->* &X::count); This program adds up the "count" members in a vector of X objects. Now, no offense intended, but this is nasty. There's just too much extra syntax required for something so simple, plus you have to make the type into a pointer just so you can dereference it Before I realized I needed to take the address of _2, I had: unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, _1 + _2 ->* &X::count); which is only slightly better (but incorrect). I realize that I can use bind: unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, _1 + bind(&X::count,_2)); but that's slightly counter-intuitive since the order of the target object and its member pointer are reversed. It'd be nice to allow something like: unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, _1 + _2.at(&X::count)); while if _2 were to refer to a pointer type, we could say: unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, _1 + _2->at(&X::count)); -- Dave Abrahams Boost Consulting www.boost-consulting.com

6 11

shared_ptr reference count
by John McGinty 08 Mar '04

08 Mar '04

Is there any reason why shared_ptr does not use atomic_count (using InterlockedIncrement, InterlockedDecrement) for the reference count? The lightweight mutex used to protect the count in the current implementation is a spin lock that sleeps when contended. Using atomic count would offer performance improvements in both the uncontended and contended cases. Regards, John McGinty

2 1

Re: [boost]Re: Re: [serialization] non-conformance incollection_load_imp.hpp
by JOAQUIN LOPEZ MU?Z 08 Mar '04

08 Mar '04

----- Mensaje original ----- De: Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> Fecha: Sábado, Marzo 6, 2004 8:17 pm Asunto: Re: [boost]Re: Re: [serialization] non-conformance incollection_load_imp.hpp > Robert Ramey wrote: > > This exchange illustrates the problem rather nicely. Its not > clear > > to me from the name "aligned_storage" that its meant to do the > same > > job as "stack_allocate" and in fact is easily confused with > other > > boost functions. I've been able to find no documentation nor > test > > nor other information. The only place its used is in variant.hpp but > > its not mentioned in the documentation of that either. There is > no > > statement in the header itself as to what it does and the code > is > > sufficiently non-trivial that it's not obvious what its supposed > to > > do. The fact that it has a parameter than stack_allocate > doesn't > > need also suggests that it's intended purpose is different from > that > > of stack_allocate. > > It doesn't, see aligned_storage's "Rationale" subsection in > http://tinyurl.com/39asx. > I don't quite get what you mean. So, does boost::aligned_storage serve as a replacement for stack_allocate? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[Boost-bugs] [ boost-Bugs-911758 ] Silent random_number_generator failure.
by SourceForge.net 08 Mar '04

08 Mar '04

Bugs item #911758, was opened at 2004-03-08 04:56 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=911758&group_i… Category: random Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cromwell Enage (expaler) Assigned to: Jens Maurer (jmaurer) Summary: Silent random_number_generator failure. Initial Comment: The test program attached to this message fails silently when attempting to execute line 54. (The test does not return, but no exceptions or errors are thrown, either.) The culprit is in <boost/random/random_number_generator.hpp>, line 52: the variate_generator's first template parameter is base_type. Changing it to base_type& will squash the bug. Cromwell Enage ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=911758&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] serialization library #17
by Hurd, Matthew 08 Mar '04

08 Mar '04

> On Behalf Of Robert Ramey > Subject: [boost] serialization library #17 > > > Robert Ramey Small doc inconsistency with libs/serialization/doc/implementation.html#othercompilerissues Intel 8.0 appears in the left hand side frame but there is no relevant section. Regards, Matt Hurd. 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.

1 0

Re: [boost] Re: [indexed_set] volunteers wanted for testing
by JOAQUIN LOPEZ MU?Z 08 Mar '04

08 Mar '04

----- Mensaje original ----- De: Giovanni Bajo <giovannibajo(a)libero.it> Fecha: Viernes, Marzo 5, 2004 4:30 pm Asunto: [boost] Re: [indexed_set] volunteers wanted for testing > Testing on GCC 3.4 uncovers an issue. > > ../../../boost/indexed_set/index.hpp:155: error: there are no > arguments to > `final' that depend on a template parameter, so a declaration of > `final' must > be available > This happens also on all the similar lines in the same class: 161, > 177, 178, > 179. All final* members seem to be inherited from a dependent > base, so they > need to be qualified with "this->" in front of them. The same also > happens in > index_set.hpp, line 133, 459. sequenced_index.hpp: 134, 157, 175, > 176, 177, > 576, 580. > I think there are more occurrence of this but maybe they are not > excercised by > the testes. You're very right. I'll add the missing this->'s. Thanx for the tip. > > test_list_ops.cpp generates an ICE which I already submitted for > analysys. Is there a link in the GCC database that I can track? > All the other tests compile and run succesfully (after the above > fixes).-- > Giovanni Bajo > OK, thank you again. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

GUI library - another one
by David Turner 07 Mar '04

07 Mar '04

Hello It seems that the idea of adding a medium-complexity GUI library to boost is popular, but that there are widely varying opinions on how it should be done. I've written a first draft of a library that fulfils most of my expectations. It's available at http://www.turn.co.za/david/gui. It supports two platforms (Win32 and GTK2), and four user interface elements or widgets (window, label, button, text-entry). The design is such that it is extremely easy to support new platforms or widgets. These are my expectations of how a good C++ GUI library should behave: 1. It should be a consistent yet thin wrapper around the platform's native functionality. 2. It should degrade gracefully in the absence of certain features on the platform. 3. It should be extensible through the factory pattern. 4. It should couple loosely with user code - this means no inheriting from an abstract Window class. 5. It should do what the user (programmer) expects, whenever possible (i.e. no leaky metaphors). 6. Widgets that contain things should behave like containers, whenever this is practical. 7. It should not use device-specific units like pixels, wherever this is practical. and finally 8. It should be extremely easy to use. The library at the link above fulfils most of these requirements. But it's not perfect. There are some interesting design choices. In many respects the most difficult design work is still to be done (list boxes, menus, drawing areas). However, the code that exists has the great advantage of working. I'd like to know what the boost community thinks before proceeding. Regards David Turner

25 103

Boost+python building - Only 1 error to resolve...
by jeuxal_com 07 Mar '04

07 Mar '04

For win2000,msvc (vc6) Got the error (either python22 release or 2.4current source): vc-C++ bin\boost\libs\python\build\boost_python.dll\msvc\debug\inheritance.obj inheritance.cpp C:\Lib\boost_1_31_0\boost/graph/detail/adjacency_list.hpp(1055) : error C2244: 'bidirectional_graph_ move_edge' : unable to resolve function overload C:\Lib\boost_1_31_0\boost/graph/detail/adjacency_list.hpp(1057) : error C2954: template definitions C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2039: 'dm' : is not a member of '_mfi' C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2143: syntax error : missing ';' before '<' C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2501: 'dm' : missing storage-class or type specif C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2059: syntax error : ';' C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2059: syntax error : '<' C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2653: 'T' : is not a class or namespace name C:\Lib\boost_1_31_0\boost/mem_fn.hpp(315) : error C2645: no qualified name for pointer to member (fo C:\Lib\boost_1_31_0\boost/mem_fn.hpp(320) : error C2143: syntax error : missing ';' before '}' C:\Lib\boost_1_31_0\boost/mem_fn.hpp(320) : fatal error C1506: unrecoverable block scoping error Any idea? Thanks AL Same error compiling with bjam -sBOOST_ROOT=. -sTOOLS="msvc" -sPYTHON_ROOT=C:/python22 or from boost_python.dsw

2 2

Re: Explicit Conversion Operators (N1592)
by David Abrahams 07 Mar '04

07 Mar '04

Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> writes: > To: C++ extensions mailing list > Message c++std-ext-6834 > > David Abrahams writes: >> "Powell, Gary" <powellg(a)amazon.com> writes: >> >>From my reading of this paper, it would appear that this change does >> > that. I also like that the change reuses an existing keyword in what >> > would appear to be a natural extension of its use. i.e. explicit, >> > still means explicit, you have to specify not rely on the default. >> >> I haven't read the paper yet, but IMO a bigger problem is the fact >> that we don't have a single syntax for requesting an explicit >> conversion that will always be "safe". For example: >> >> T(x) // if T is a builtin type this might be a >> // reinterpret_cast >> >> static_cast<T>(x) // might be a downcast > > That's solvable, though: > > template< typename T, typename S > > T explicit_cast(S const& s, typename enable_if< is_class<T> >::type* = 0 ) > { > return T(s); > } > > template< typename T, typename S > > T explicit_cast(S const& s, typename disable_if< is_class<T> >::type* = 0) > { > return static_cast<T>(s); > } This formulation requires T (and S, if you want to pass rvalues) to have an accessible copy ctor. I'm not sure it's better than the formulation in boost/implicit_cast.hpp, which only puts a restriction on T. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Metrowerks 9.2 approaching 100% on Windows
by Beman Dawes 06 Mar '04

06 Mar '04

The Win32 regression test results now reflect the new Metrowerks 9.2 release. See http://boost.sourceforge.net/regression-logs/ Fails have been reduced to just two: graph adj_list_cc: That's a regression compared to 8.3 and the 9.2 beta that we need to look into. I've emailed Jeremy. type traits is_abstract_test: This is a new test, so it was not tested during the 9.2 beta. I'd appreciate it if the type traits folks would take a look to see if this is a Boost or Metrowerks problem. Anyhow, congratulations to Metrowerks, particularly Howard Hinnant, Andreas Hommel, and Ed Swartz. They put in a lot of effort checking out Boost regression test failures. --Beman

3 3

string algorithms check-in
by Pavol Droba 06 Mar '04

06 Mar '04

Hi All, I have just checked into main the cvs the string algorithm library. Feel free to try it out:) Few comments: - Most of the changes requested during the review are there, except for the documentation issues. Reference should be in sync, since it is doxygen-generated, but it will need some updating too. - The library resides in the directory algorithm/string (i.e. boost/algorithm/string and libs/algorithm/string) - Cummulative includes are located in boost/algorithm/string.hpp and string_regex.hpp - All functions/classes/types are in the namespace boost::algorithm (+ ...::algorithm::detail) - Public interface entities are pulled to the boost namespace via "using directive" - I might have spoiled something during commit, so if you have any problems, let me know ;-/ My questions: - How can I make the library to be part of automatic regression tests? - How can I make the library documentation to be automaticaly generated and accessible from the main docs page? Regards, Pavol

3 4

[boost]Re: Re: [serialization] non-conformance in collection_load_imp.hpp
by Robert Ramey 06 Mar '04

06 Mar '04

Tom Widmer wrote: >On Fri, 5 Mar 2004 07:59:31 -0800, "Robert Ramey" <ramey(a)rrsd.com> >wrote: >>Joaqu?n M? L?pez Mu?oz wrote: >> >>>"serialization/collections_load_imp.hpp" defines a private template >>>class stack_allocate for stack-based reservation of uninitialized >>>memory. To the best of my knowledge, the way it does so is not >>>std-conformant due to alignment issues. >>>Fortunately, (undocumented) "boost/aligned_storage.hpp" provides a >>>template class named aligned_storage which handles the issue, so I >>>guess the problem can be solved by just using this facility instead of >>>stack_allocate. >> >>This has been mentioned before. I was unable to find any information >>other than the code itself which wasn't all that transparent to me. >>And the stack allocate was soooooo simple. Is aligned_storage part of >>boost? Is it documented anywhere? Is it part of any test suite? Has >>it been tested for portability? In general I would prefer a boostified >>component over a homebrew one. I'm really not sure of what the status of >aligned_storage is. >>Also, the nameitself didn't make it clear to me that its intended >>purpose was identical to that implemented by stack_allocate. >It's a fully documented part of Boost type_traits, assuming you are just >after a POD type with a certain alignment: >::boost::alignment_of<T>::value >Identifies the alignment requirements of T. Actually returns a value that >is only guaranteed to be a multiple of the actual alignment requirements of >T. >T must be a complete type. >::boost::type_with_alignment<Align>::type >Attempts to find a built-in or POD type with an alignment that is a >multiple of Align. Neither of the above functions is the on in question. We're talking about aligned_storage here. This exchange illustrates the problem rather nicely. Its not clear to me from the name "aligned_storage" that its meant to do the same job as "stack_allocate" and in fact is easily confused with other boost functions. I've been able to find no documentation nor test nor other information. The only place its used is in variant.hpp but its not mentioned in the documentation of that either. There is no statement in the header itself as to what it does and the code is sufficiently non-trivial that it's not obvious what its supposed to do. The fact that it has a parameter than stack_allocate doesn't need also suggests that it's intended purpose is different from that of stack_allocate. Given all the above, I would be reluctant to replace the 10 transparently correct lines of stack_allocate by inclusion of 138 lines of aligned_storage. Now it's quite possible that stack_allocate is incorrect, non-portable, or in some other way undesirable such that it should be replaced with something else. If this is the case, I would very much like hear about it. Robert Ramey

2 1

Re:[boost] Serialization17 - assert in basic_text_oarchive.hpp
by Robert Ramey 06 Mar '04

06 Mar '04

Jeff Flinn wrote: >My app is hitting the assertion at line 133 in basic_text_oarchive.hpp with >delimiter = 3 when serializing to a text_oarchive. Whoops - I spoke way too soon. Clearly this is something new, I'll look into it. >The assertion occurs during serialization of the count for a shared_ptr. >There is an access violation when attempting to serialize to a >binary_oarchive also. The same assertion or a different one. This sounds like the pointer registration/export issue I alluded to earlier. >XML serialization in both directions works fine. The odd thing is, if I >comment out any usage of xml_oarchive, the assertion is not triggered, and >serialization to both text_oarchive and binary_oarchive succeeds. Odd indeed. Investigate some more. Again, which assertion? >Input from binary/text/xml succeeds in all cases. If it fails to create archive, how do we know input succeeds? Robert Ramey

2 2

Serialization17 - assert in basic_text_oarchive.hpp
by Robert Ramey 05 Mar '04

05 Mar '04

Jeff Flinn wrote: >My app is hitting the assertion at line 133 in basic_text_oarchive.hpp with >delimiter = 3 when serializing to a text_oarchive. The assertion occurs >during serialization of the count for a shared_ptr. There is an access >violation when attempting to serialize to a binary_oarchive also. XML >serialization in both directions works fine. The odd thing is, if I comment >out any usage of xml_oarchive, the assertion is not triggered, and >serialization to both text_oarchive and binary_oarchive succeeds. Input >from binary/text/xml succeeds in all cases. This has been reported recently and addressed in the next version. In the case I know about it occurred with an instance of a derived class serialized though a polymorphic base class pointer which was previously neither "registered" or "exported". This has been addressed by throwing of an exception at an earlier point. This also occurred when using serialization of a derived polymorphic shared pointer though its base class. This sounds like your case. An updated copy of test_shared_ptr shows how this can be addressed. (I'll send you the latest copy) It turns out that my implementation of serialization of shared pointer isn't quite there. It needs a more elegant way to automatically register/export shared_count<P, D> when P is the derived class and we're serializing through a base class pointer. I havn't thought about this because: a) I'm really reluctant to get involved with shared_ptr b) I think other issues will also come up - e.g. exception safety while serialization of shared pointer c) locking during multi-threading d) ? Robert Ramey

1 0

Comment regarding __GNUC__ spoofing
by Beman Dawes 05 Mar '04

05 Mar '04

In discussions with the Intel folks about their spoofing of __GNUC__ on Linux, Clark Nelson pointed out that Boost code should be much more careful about use of any predefined compiler identification macro, because there is nothing to prevent any compiler in the future predefining compiler identification macros used by other compilers. Scary as it is, he is right AFAICS. There are two cases I can see for checking a compiler identification macro: * The code wishes to see if it is safe to use an extension feature such as a pragma or compiler intrinsic provided by the compiler indicated by the macro. This is reasonably safe in that presumably the reason the actual compiler is pretending to be a different compiler is to indicate feature compatibility with the spoofed compiler. * The code wishes to apply a workaround for a bug in the spoofed compiler. This usage is fraught with possible problems. The actual compiler may or may not have the same bug. If not, useful functionality may be needlessly disabled or the workaround may not even work. We deal with _MSC_VER in various compilers by defining BOOST_MSVC if it is actually the Microsoft compiler. We deal with __GNUC__ inconsistently by defining BOOST_INTEL rather than BOOST_GCC. To be consistent and to prevent being blindsided in the future by other compilers deciding to spoof one another's macros, perhaps we should define BOOST_x, where x is the compiler name, for every compiler we have a config for. And then pointing out the problem in our lib guide for developers. --Beman

6 7

Re:[boost] [serialization] non-conformance in collection_load_imp.hpp
by Robert Ramey 05 Mar '04

05 Mar '04

Joaqu?n M? L?pez Mu?oz wrote: >"serialization/collections_load_imp.hpp" defines a private template >class stack_allocate for stack-based reservation of uninitialized >memory. To the best of my knowledge, the way it does so >is not std-conformant due to alignment issues. >Fortunately, (undocumented) "boost/aligned_storage.hpp" provides >a template class named aligned_storage which handles the issue, >so I guess the problem can be solved by just using this >facility instead of stack_allocate. This has been mentioned before. I was unable to find any information other than the code itself which wasn't all that transparent to me. And the stack allocate was soooooo simple. Is aligned_storage part of boost? Is it documented anywhere? Is it part of any test suite? Has it been tested for portability? In general I would prefer a boostified component over a homebrew one. I'm really not sure of what the status of aligned_storage is. Also, the nameitself didn't make it clear to me that its intended purpose was identical to that implemented by stack_allocate. Robert Ramey

2 1

boost isnan/isinf/etc...?
by Matthias Schabel 05 Mar '04

05 Mar '04

For numeric code these functions are indispensible but, since they're C99, they are technically C++ verboten. It seems to me that it would be worthwhile to add them to boost::math - they could probably just be cut-n-pasted from the C99 gcc headers... Matthias ------------------------------------------------------------------------ --------------------------- Matthias Schabel, Ph.D. Utah Center for Advanced Imaging Research 729 Arapeen Drive Salt Lake City, UT 84108 801-587-9413 (work) 801-585-3592 (fax) 801-706-5760 (cell) 801-484-0811 (home) mschabel at ucair med utah edu

3 2

Re: GUI library - another one
by Robert Ramey 05 Mar '04

05 Mar '04

I believe similar discussions were engaged some time ago and that these discussions resulted in: http://sourceforge.net/projects/notus/ What to the participants in these other discussions have to add? Robert Ramey

5 6

Re: whither the order language
by hartmutkaiser＠t-online.de 05 Mar '04

05 Mar '04

Vesa Karvonen wrote: > Ronald Garcia wrote: > >Where can I find a copy of the Order preprocessor language? The Boost > >files section seems to have examples of its use, as well as a manual, > >but I don't seem to see the implementation. > > I removed the Order interpreter implementation from the files section some > time ago, because it had changed significantly due to the discovery of a > couple of techniques for removing certain practical limitations. The > documentation and examples mostly reflect the current Order interpreter, > but as I have not been working on the implementation for some time, the > interpreter is not ready for publication. If you are really interested, > then I could e-mail you a snapshot of the interpreter. > > The current Order interpreter also uses C99 preprocessor features, namely > variadics and placemarkers, so it is not immediately useful for C++ > programming. The latest GNU CPP and the Wave library are known to be able > to preprocess the Order interpreter. Other preprocessors have not been > tested, but it should be possible to port the interpreter to most (more or > less buggy) preprocessors that support the C99 extensions. Yes, I'm interested in getting the latest version of your Order library, since I'm still using it as one of my test cases for Wave. Could you please send it to me? Regards Hartmut

1 0

Serialization17 - assert in basic_text_oarchive.hpp
by Jeff Flinn 05 Mar '04

05 Mar '04

Robert, My app is hitting the assertion at line 133 in basic_text_oarchive.hpp with delimiter = 3 when serializing to a text_oarchive. The assertion occurs during serialization of the count for a shared_ptr. There is an access violation when attempting to serialize to a binary_oarchive also. XML serialization in both directions works fine. The odd thing is, if I comment out any usage of xml_oarchive, the assertion is not triggered, and serialization to both text_oarchive and binary_oarchive succeeds. Input from binary/text/xml succeeds in all cases. I'll try to diagnose further. This is all with vc7.1, both the exe and libs are compiled with static multi-threading library flags (/MT). Any thoughts? A quick perusal of the test suite doesn't show any cases using multiple oarchive types within a single test. Thanks, ----------------- Jeff Flinn Applied Dynamics, International

1 0

RE: [boost] whither the order language
by Vesa Karvonen 05 Mar '04

05 Mar '04

Hi, Ronald Garcia wrote: >Where can I find a copy of the Order preprocessor language? The Boost >files section seems to have examples of its use, as well as a manual, >but I don't seem to see the implementation. I removed the Order interpreter implementation from the files section some time ago, because it had changed significantly due to the discovery of a couple of techniques for removing certain practical limitations. The documentation and examples mostly reflect the current Order interpreter, but as I have not been working on the implementation for some time, the interpreter is not ready for publication. If you are really interested, then I could e-mail you a snapshot of the interpreter. The current Order interpreter also uses C99 preprocessor features, namely variadics and placemarkers, so it is not immediately useful for C++ programming. The latest GNU CPP and the Wave library are known to be able to preprocess the Order interpreter. Other preprocessors have not been tested, but it should be possible to port the interpreter to most (more or less buggy) preprocessors that support the C99 extensions. Regards, Vesa Karvonen _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

1 0

[serialization] non-conformance in collection_load_imp.hpp
by Joaquín Mª López Muñoz 05 Mar '04

05 Mar '04

"serialization/collections_load_imp.hpp" defines a private template class stack_allocate for stack-based reservation of uninitialized memory. To the best of my knowledge, the way it does so is not std-conformant due to alignment issues. Fortunately, (undocumented) "boost/aligned_storage.hpp" provides a template class named aligned_storage which handles the issue, so I guess the problem can be solved by just using this facility instead of stack_allocate. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: GUI library - another one
by E. Gladyshev 05 Mar '04

05 Mar '04

--- Robert Ramey <ramey(a)rrsd.com> wrote: It seems that my post didn't make it through. I got the Boost post acknowledgement but the message did not appear on the list. I am trying to use another e-mail account. If the mailing list moderators would like to look into this problem, please e-mail me privately so I could give you my account information. Thanks. Anyway back to the GUI stuff. > I believe similar discussions were engaged some time ago and that these > discussions resulted in: > > http://sourceforge.net/projects/notus/ > > What to the participants in these other discussions have to add? Well, I am quite happy with the direction notus is taking but there is a lot to be done. First I'd like to comment on the issue of simplicity. Simplicity is great but IMHO, it should NOT be of concern of the core GUI design. The higher layers could simplify the core interface any way they like. Like another poster pointed out if a feature is missing it could easily be a showstopper. It is like missing a letter in the alphabet. The primary concern of the core GUI design should be consistency, *scalability* and feature support. I think that the discussion of the syntax like using operators '<<' or '[]' and so on is important but it is a secondary issue. I think that what we are missing a consistent fundamental GUI design. All this syntactic sugar or XML support could be added at a latter stage. Most of the GUI frameworks with their endless polymorphic hierarchies and castings are not fun anymore. :) The fundamental GUI library doesn't have to support all possible features right from the start. It is more important to identify all fundamental features and architectures that will let you to scale the framework up with new features. Usually a GUI feature is not a standalone thing. It relies on presence of other features. A good GUI library should identify a set of *fundamental* features and architectures that will let the library grow vertically and orthogonally. Notus is based on what we call MDS (the DDV terminology will be deprecated). Model - application data Display - physical device such as window, button Strategy - user defined behaviors template <typename Model, typename Display, typename Strategies > struct view {...} A typical strategy looks like this struct my_strategy : handle_event<mouse> handle_event<paint> { template< typename View > void on_event( View& v, mouse& e); template< typename View > void on_event( View& v, paint& e); }; As you can see, the strategy event handlers take the event source (View) as a template parameter. So as soon as the View provides the interface that is required by this strategy, it doesn't care what View really is. So strategies can be used as interchangeable components. Strategies can be combined and reused. typedef view< my_data, displays::window, tuple<my_strategy> > my_window; //customize my_window typedef view < my_data, displays::window, tuple<my_customization, typename my_window::strategy> > my_custom_window; //my_custom_window reuses all strategies that are defined in my_window; I'd like to note that notus doesn't have any casting stuff and almost no polymorphism. The idea is to create a *generative* framework where components can be constructed from a set of interchangeable and custom parts. I'd like to touch the issue of ownership. The core Notus doesn't care about ownership at all, the physical devices such as windows, buttons, etc. are represented by Displays. One display can be connected to one or more other displays so that it will get events generated by the displays that it is connected to. So at this level, it is a *network* of display connections not an ownership hierarchy. I anticipate your question about what happens when the display's "physical" owner is deleted. Nothing really except that all the connections to the deleted display are lost. *Important* the displays don't keep direct references to other displays. I appreciate your comments. Eugene

1 0

boost::lexical_cast optimizations
by Val Samko 05 Mar '04

05 Mar '04

At the moment, boost::lexical_cast is about 70 times slower than corresponding C functions (at least with VC++ with all the optimizations enabled) for integer and floating point types (see my benchmark below). Is it possible to add boost::lexical_cast specializations for std::string, integer and floating point types? Val Samko === Benchmark code ==================== Output: VC++ 7.1: atoi: 1297ms vs lexical_cast: 79703ms g++ 3.3.3 (mingw): atoi: 1547ms vs lexical_cast: 148078ms #include <boost/lexical_cast.hpp> #include <iostream> #include <string> #include <windows.h> int main() { std::string s = "25413248"; int r; int REPEATS = 20000000; DWORD c1 = GetTickCount(); for (int i = 0; i < REPEATS; ++i) r += atoi(s.c_str()); DWORD c2 = GetTickCount(); for (int i = 0; i < REPEATS; ++i) r += boost::lexical_cast<int>(s); DWORD c3 = GetTickCount(); std::cout<<"atoi: "<<(c2-c1)<<"ms vs lexical_cast: "<<(c3-c2)<<"ms "<<std::endl; }

1 0

whither the order language
by Ronald Garcia 05 Mar '04

05 Mar '04

hi, Where can I find a copy of the Order preprocessor language? The Boost files section seems to have examples of its use, as well as a manual, but I don't seem to see the implementation. Thanks, ron

2 1

[preprocessor] warnings on VC6
by Jonathan Turkanis 05 Mar '04

05 Mar '04

When I compile the following simple program on VC6: #include <boost/preprocessor/facilities/empty.hpp> #include <boost/preprocessor/punctuation/comma_if.hpp> #define PARAM(has_param) BOOST_PP_IF(has_param, typename Param, BOOST_PP_EMPTY()) #define MACRO(has_param) \ template< PARAM(has_param) BOOST_PP_COMMA_IF(has_param) typename T> \ struct name { }; \ /**/ MACRO(0) int main() { return 0; } I get the following warnings: warning C4003: not enough actual parameters for macro 'BOOST_PP_IIF' warning C4003: not enough actual parameters for macro 'BOOST_PP_IIF_I' warning C4003: not enough actual parameters for macro 'BOOST_PP_IIF_0' It works fine on other compilers. Am I missusing the preprocessor library, or is this a problem with VC6? If the latter, is there a workaround, or should I just turn off warning 4003? Jonathan

3 9

[Threads] Reactive Objects
by scott 05 Mar '04

05 Mar '04

Hi, I have been working on a small library that has become reasonably useful and possibly of interest to someone else. It's also become fairly large. I am quite interested in this library getting "boosted" but even given that there is substance to the library its scope is a bit of a problem; its quite large. It was started as a project with requirements very similar to those associated with the ActiveObject pattern; http://citeseer.nj.nec.com/lavender96active.html (reference from J. Garland) and takes many cues from the concepts and primitives found in SDL; http://www.sdl-forum.org/ Its possible to characterize this library as the basic building blocks for clean, robust multi-threading <ahem>. It could also be characterized as a subset of TAO, i.e. CORBA. While its a very small subset <sheepish grin>, maybe these comments gives scale to the scope issue. A breakdown of the incidental technologies tackled by this library follows; * multi-threading building block classes * network representation of structured data (variants) * saving and loading of network data (persistence) * interactive machines (inter-thread messaging) * stateless and stateful machine representation * code generation of network data and machine skeletons * message forwarding (distributed messaging) * transparent remote machines (proxies for inter-process messaging) * support for multiple encodings, e.g. binary, text, XML... To flesh this list out into something less opaque, a set of file fragments follows. These are the result of applying the library to the test case pushed around in the recent thread "Simple Active Object". They are necessarily abbreviated; // --------------------------------- // db_server.tms (the schema) // record configuration { // Persistent portion of the db_server string data_source integer maximum_workers integer maximum_clients } record open {} // Messages between the server and its clients record close {} record select { string sql_statement } record busy {} state INTIAL, // Pre-defined READY, // Normal operation OVERLOADED, // All workers busy OUT_OF_SERVICE // Something went wrong // Define the messages expected in the // different states transition INITIAL void // Standard startup transition READY open, // Another client connecting close, // Client closing configuration, // Reconfiguration select // An SQL select statement .. // --------------------------------- // db_server.h (auto-generated header) // .. #define db_server_configuration_hash 0x03493ac9 #define db_server_open_hash 0x7a6ffa00 #define db_server_close_hash 0x1093ac66 #define db_server_select_hash 0x004410ac #define db_server_busy_hash 0x74529711 struct typed03493ac9 { .. string &data_source; long &maximum_workers; long &maximum_clients; .. }; struct db_server { .. enum { INITIAL, READY, OVERLOADED, OUT_OF_SERVICE }; typedef typed03493ac9 configuration; typedef typed7a6ffa00 open; typedef typed1093ac66 close; typedef typed004410ac select; typedef typed74529711 busy; virtual int transition( typed_state<INITIAL> ) = 0; // void message virtual int transition( typed_state<READY>, typed_bind<open> & ) = 0; virtual int transition( typed_state<READY>, typed_bind<close> & ) = 0; virtual int transition( typed_state<READY>, typed_bind<configuration> & ) = 0; virtual int transition( typed_state<READY>, typed_bind<select> & ) = 0; int machine( typed_word & ); // The auto-generated switch statements .. }; .. // --------------------------------- // my_server.cpp (application declaration of db_server) // #include "db_server.h" class my_server : public state_machine<db_server> { typed_memory_folder home; db_server configuration; address_group client; virtual int transition( typed_state<INITIAL> ); virtual int transition( typed_state<READY>, typed_bind<open> & ); .. }; // my_server.cpp (application definition of db_server) // my_server::my_server() : home( "configuration\\my_server" ) { try // Persistence { load( home, configuration ); // Recover previous image } catch( ... ) { // Not found. Set factory defaults configuration.data_source = ""; configuration.maximum_workers = 4; configuration.maximum_clients = 100; save( home, configuration ); } } int my_server::transition( typed_state<INITIAL> ) { if( data_source.empty() ) { return OUT_OF_SERVICE; } if( ... ) // Attempt to connect to RDBMS { return READY; } return OUT_OF_SERVICE; } int my_server::transition( typed_state<READY>, typed_bind<open> &s ) { client.insert( sender() ); reply( configuration ); } .. int my_server::transition( typed_state<READY>, typed_bind<select> &s ) { if( ... ) // Find an idle worker { // Submit request to worker .. return READY; } reply( busy() ); return READY; } Hopefully these fragments have been enough to sketch out the intent of the library and where it currently is "at". As a bunch of materials, it is a .lib, headers and a .exe (the schema parser+generator) There are (serious) pretentions to platform independence but current materials are for Windows. I am very happy to work towards a boosted version of a subset of this work cos basically it seems too large to be a prospect otherwise. This subset would be in the area of mutli-threading building block classes, i.e. an "alternate threading model". However, after the recent exchange of related and interesting messages, I felt compelled to "come clean" with some background. So, to Matthew and Mark. Are you interested in dicsussing the possible implementation of; * simple active objects (completion of current alternate threading model) * simple reactive objects (completion of current with two-way calling of methods) * something else? Cheers, Scott

5 12

More versatile any_cast
by David Abrahams 04 Mar '04

04 Mar '04

Someone wanted to be able to put a derived class into a boost::any and use any_cast to get a base class pointer out. Enclosed is a patch to do it, FWIW. Disclaimer: I have no opinion on whether this should be done or not. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

RE: [boost] Re: [Threads] Simple active object wrapper, take 2
by Darryl Green 04 Mar '04

04 Mar '04

> -----Original Message----- > From: Matthew Vogt [mailto:mvogt@juptech.com] > Sent: Wednesday, 3 March 2004 8:44 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: [Threads] Simple active object wrapper, take 2 > > > scott <scottw <at> qbik.com> writes: > > > Yep. All straight now. I know understand your breakdown of calls > > to callbacks is very similar to that inherent in SDL. And > yes, you/we/it > > are fully asynchronous. > > > > I'm assuming you prefer this to the reactive object version? Which > > does a pretty good job of hiding the comms Oh yeah, and doesnt > > require selection of the method to call in either the receipient > > or the client (on response), i.e. at the point of making a method > > call. > > > > Maybe we're down to a matter of taste? > > Yes, I guess it depends on whether you're > familiar/comfortable with the message > passing paradigm, or whether you're more comfortable with C++ > shenanigans to > obscure the messy details. It may be the sign of a warped mind but queueing some form of bound functor-like object has almost always seemed to be (broadly) what I wanted to do in any message passing scheme, whether or not fancy machinery existed to do it. However, there are times when it is useful to have the messaging defined independently of either the sender or the receiver, with both being written to conform to the messaging interface. I've tended to think of the tightly/early bound, just queue a functor, and the message passsing + switch case as 2 completely independent patterns, but maybe they should be built on a common framework (at a level above the detail that they both ivolve queuing some sort of object). The AO pattern doesn't require that you identify the object you want to invoke the method on in the proxy, because you send the proxy to that object, and only that object. So one could drop the "this" parameter from the proxy. That would potentially allow the proxy to be routed/forwarded in a more general reactive object model (I think this was one of Scotts requirements)? I'm not 100% sure how useful this is, but it might be nice for the class of problem where you do want concurrent execution - of as many completely independent instances of the object as is "useful". The client/master doesn't care which instance - the next available one will do nicely. Further, it would seem possible to exclude any binding to a particular member function from the proxy itself and instead allow "free proxies" to be defined. To avoid confusion, I'm going to drop the work proxy for these "free proxies" and call them "messages". These would just define a function signature to match, not a particular (member) function. It is not clear to that the type of the "this" parameter need be defined by the message - excluding it would offer better separation between message sender and receiver. The sender need only know that it wants to notify or invoke something by sending the message. Such message types (just a tuple) could be defined with no reference to the wrapper or receiving object type at all. As you have said, the downside is that there is some form of type-switch implied in the receiver (eg the receiver wrapper would accept a boost::variant<message_type_1, message_type_2...> from the activation list and apply a generic visitor to do the dispatch). Maybe this can be avoided if there is a separate queue per message type? The additonal queue/scheduler complexity would probably wipe out any potential advantage though. So a receiver wrapper generator would need to, given the set of message types and corresponding member function pointers to handle them, generate the variant and corresponding visitor. I certainly like this better than a hand coded switch, and it is something like a simplified/limited form of the compile time (actually code generation time) generation of message demux code that is part of scotts existing framework (I think - I only skimmed scotts descriptions and possibly guessed too much from vaguely similar, but more primitive things I've used before). > I would postulate, however, that wrapping the details to > allow binding at the > call site (or message post) is slightly superior, due to the > removal of the > dispatch. Of course, this minor gain may easily be outweighed by the > contortions required to make it work, and the reduction in > the transparency > of the code... The tightly/call site bound case can be written as a simple layer on top of the lose/late bound system. Message type becomes variant<proxy> and the visitor for the one and only type dispatches to a wrapper function that just does the stuff that was done in the thread_function loop in your AO code. I'm not sure that for a reasonably small (any sane?) interface the performance difference due to the demux will be terribly large anyway, so maybe the specialisation isn't needed for that alone. However I've so far ignored the return value in this - the return type could obviously be defined in the message, but what should define how/where it should be delivered? It seems that the caller should define how/where it wants results delivered at the time of invoking the request - which it can do by passing some sort of result handler object in the message instance. Of course this is what the synch object in your proxy is. Perhaps its interface can be made more generic to allow its operation to be policy based. Broadening the definition from "return value" to "message delivery notification" with the sender supplied message delivery notifier object passed the return value from the handler doesn't feel too weird to include at the low level, and shouldn't cost anything for a void return without notification. Interestingly, the option to generate a a notification that a message with a handler returning void has been processed doesn't seem like a strange feature when looked at this way (a void future is a bit odd though). > > > > I hadn't realised how integral the state machine was to your > > > design until I > > > read your other post. Still, if you are doing dispatch on > > > both message code > > > and object state, it can be simplified to bind the message to > > > a per-message > > > code dispatch function which then dispatches on object state. > > > > Characterizing of reactive objects as a framework for state machines > > would be a little bit sad. I'm not sure it was your intention to say > > that so just in case others are listening, I will elaborate from > > my POV. > > > > Sorry, I read too much into the example code in the other > message. I assumed > the messaging would be an independent layer, but that the > design you were > using must have the communicating objects modelled as state > machines. Thanks > for clearing that up. > This observer didn't see the state machine aspect as the exclusive use, more an important use case reflected in the design. Would that be fair to say? > <snip> > > > The messaging facillity has _no understanding_ of what the > recipient does > > with a message. Proxies and state machines were intended to > highlight > > the benefits of that design. > > > > To summarize; the Reactive Objects that I currently > consider our target > > would communicate via a similar mechansim and there would be no > > assumption that a Reactive Object was a state machine, or a > proxy, or > > anything except an object that accepts messages. My questions that I've been thinking out loud about (always dangerous in public) were: What is a message? What is acceptance? Sorry this was so long - am I barking up the wrong tree here or not? > > Yes, that all sounds good. > > > Cheers, > > Scott > > Matt > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/bo> ost > ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

3 2

Re: [boost] Re: GUI library - another one
by Beman Dawes 04 Mar '04

04 Mar '04

At 12:10 PM 3/4/2004, David Turner wrote: >... A button in one window isn't necessarily >the same thing as a button in another window; just as a bold font in one >document isn't necessarily the same as a bold font in another. I'd rewrite that as "The implementation of a button in one window isn't necessarily the same thing as the implementation of a button in another window..." To modify Dave's example to make a point: button OK_button("OK"); window_one("Warning: now entering twilight zone one") [ text_field("my favorite color is:"), OK_button | button("cancel") | attribute_x(1) ] window_two("Warning: now entering twilight zone two") [ text_field("my favorite color is:"), OK_button | button("cancel") | attribute_x(2) ] Perhaps the implementation of OK_button in window_one is very different from window_two. But they both have OK_buttons, and at the interface level these are the same button. > >One cannot say in general that elements can be exchanged between >documents. Similarly, one cannot say in general that widgets can be >exchanged between windows. I understand that the implementation details can't be exchanged. But we aren't taking about implementations of buttons, we are talking about the abstract concept of an OK_button. That certainly could be transferred, couldn't it? More importantly, you could build up a widget library which could be used regardless of the target window. Sorry if I'm missing something here; I'm not much of a GUI programmer. --Beman

6 5

Re: GUI library - another one
by Jesse Booher 04 Mar '04

04 Mar '04

>>> dave(a)boost-consulting.com 03/04/04 08:59AM >>> > button("click me") doesn't have to be a widget. Think expression > templates. It can just build up a type to be used by window to add a > button. Well said. This exemplifies the reason why most gui toolkits are so horrible to use, they allow implementation technicalities to dictate interface. Having to decide where an object is going to live before any of its properties can be set is a clear violation of object oriented design principles but we live with these kind of problems all the time for supposed technical reasons.

7 12

Re: [boost] Re: GUI library - another one
by Jesse Booher 04 Mar '04

04 Mar '04

David Turner wrote: > At a broader level, I'd argue that there is a good reason to use this > document/elements design because the type of the widgets have to match the > type of window they're going to go into. If we think of a button object as a particular implementation designed explicitly to support a particular window's interface requirements, this is would make sense. However, we might step back from the implementation particulars and consider a button to be a collection of properties such as caption, color, etc. that might at some point get bound to a window at which point the button object could become linked to a widget implementation appropriate to that context. This opens up the possibility that an object will specify properties that the implementation to which it gets attached does not support, but this is one of the corner stones of object oriented design. An object (e.g. button) advertises it properties and it's up to the user of the object (e.g. window) to realize those properties as best it can. Regards, Jesse Booher

1 0

RE: [boost] Re: First lambda
by Powell, Gary 04 Mar '04

04 Mar '04

>>Yeah, but do you propose to make local names visible inside the anonymous >>function, or not? If you do, you open a big can of worms for implementations >>(recursive nested functions, need I say more?), if you don't, BLL can still >>do things that anonymous functions can not. Anonymous functors could help >>some, but their syntax won't be quite as compact as your example above. > Now, to complicate matters, what if I wish to access v in the > inner anonymous function? Can you also do that? Example: > std::for_each(vv.begin(), vv.end(), > void (vector<int> const& v) > { > std::for_each(v.begin(), v.end(), > void (int x) > { > cout << x << endl; > do_fomething_with(v); // <<--here > } > } > ); > Joel de Guzman This gets ugly. As you want to "import" only one the variables you declare. For the previous example with std::accumulate. e.g.. implementation. template <class InputIterator, class T, class BinaryOperation> T accumulate<InputIterator v, InputIterator l, T i, BinaryOperation bin_op) { while (v != l) i = bin_op(i, *v++); return i; } int i = 0; unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, auto (auto lhs, auto rhs) { return ( lhs + rhs.count) + i; // Which "i"!!!! } ); And this is where BLL wins big, it has a mechanism for importing variables into the fn. And no I don't have a good solution for this. -Gary-

1 0

RE: [boost] Re: First lambda
by Powell, Gary 04 Mar '04

04 Mar '04

> "Shannon Stewman" <stew(a)uchicago.edu> wrote in message > news:20040304025205.GD832@uchicago.edu... > >>On Wed, Mar 03, 2004 at 01:34:50PM -0800, Powell, Gary wrote: >> >> >>>unsigned long n = std::accumulate( >>> xs.begin(), xs.end(), 0UL, >>> long (long lhs, X const &rhs) // inline fn with no > > name. > >>> { >>> return lhs + rhs.count; >>> } >>> ); >> >>This seems to cast out the type inference present in BLL. I think >>that's one of the nicer concepts in the lambda library, and a real >>boon to programming. In my limited experience with SML/OCaml, type >>inference seems a better, safer, and more convenient way to program, >>albeit requiring a lot more compiler intelligence. As BLL shows, > > though, > >>this is quite possible, though perhaps limited, with existing C++. >> > > > How about: > > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > auto(long lhs, const auto& rhs) // inline fn with no > name. > { > return lhs + rhs.count; > } > ); > I would prefer also eliding the argument types: > > unsigned long n = std::accumulate( > xs.begin(), xs.end(), 0UL, > lambda(lhs, rhs) > { > return lhs + rhs.count; > } > ); > > Most of the time, you also do not know the type of the > arguments before hand. > Joel de Guzman There are still direct templates (even without implied ones.) The syntax would be a bit verbose though. unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, template<class T, class S) auto (T const &lhs, S const &rhs) { return lhs + rhs.count; } );

1 0

circular_buffer v3.6
by Jan Gaspar 04 Mar '04

04 Mar '04

Hello all! New version of the circular_buffer is available. It can be found at http://groups.yahoo.com/group/boost/files/circular_buffer_v3.6.zip Release notes: - fixed bug regarding not destroyed elements - requirements for element types were changed to CopyConstructible concept - changed debug support classes - no dynamic memory allocation needed - changed debug support for invalidated iterators: assertion raised also when used iterator which points to the overwritten element - added allocator& get_allocator() /* NONCONST */ {...} method - added functionality to set_capacity() and resize() methods - changed circular_buffer_space_optimized constructor signatures Regards Jan __________________________________ Do you Yahoo!? Yahoo! Search - Find what you�re looking for faster http://search.yahoo.com

1 0

RE: [boost] GUI library - another one
by Jesse Booher 04 Mar '04

04 Mar '04

>>> hurdm(a)sig.com 03/03/04 10:30PM >>> >> Even the "why not" version seems overly complex compared to a console >> iostreams "Hello, world". Why not just: >> >> winout << title("Example window") << button("Hello, world!") >> << wait_for(delete_signal); >> >> I'm not necessarily pushing that exact approach, but just pointing out >> more >> C++-like alternatives. > > I understand you're not pushing that approach. It couldn't quite work > like that as you're trying to structure a tree rather than a sequence. Not that I'm pushing the approach either, but if all your objects that can be parents have an insertion operator then building a tree is simple a matter of adding parentheses: tree << a << b << © << d << e << (f << g) ); or breaking it up f << g; c << d << e << f; tree << a << b << c;

1 0

Re: GUI library - another one
by Jesse Booher 04 Mar '04

04 Mar '04

It is never a bad thing when someone is interested in donating their time to develop software to share with the world, and if there is a community of developers here with the time and motivation to develop a full featured GUI library that rises to the high standards of Boost that would be a wonderful thing. That said a GUI library is a *HUGE* undertaking and other cross platform libraries like wxWidgets have a big head start. Not that this is a race or anything but when it comes to GUI libraries, features nearly always trump form. After all an awkward interface is a developer annoyance, whereas a missing feature can be a show stopper. There is a certain allure to clean slate designs and there may very well be no existing open source user interface projects that you would consider worthy of your time, but I wondered if you have considered any slightly less ambitious alternatives such as creating a framework employing components from an existing open source project? It seems to me that the promise of open source development is not served when wheels (or widgets) need to be reinvented over and over again.

3 2

RE: [boost] GUI library - another one
by Hurd, Matthew 04 Mar '04

04 Mar '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Shannon Stewman > Sent: Thursday, 4 March 2004 2:42 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] GUI library - another one > > On Wed, Mar 03, 2004 at 10:30:47PM -0500, Hurd, Matthew wrote: > > > On Behalf Of Beman Dawes > > > > <snip> > > > > > Even the "why not" version seems overly complex compared to a console > > > iostreams "Hello, world". Why not just: > > > > > > winout << title("Example window") << button("Hello, world!") > > > << wait_for(delete_signal); > > > > > > I'm not necessarily pushing that exact approach, but just pointing out > > > more > > > C++-like alternatives. > > > > I understand you're not pushing that approach. It couldn't quite work > > like that as you're trying to structure a tree rather than a sequence. > > This is beside the point. Trees are isomorphic to lists that contain > lists. For example: > > winout << title("Example window") > << divider(2) << up << ( panel << vertical > << label("Hello, world!") > << textentry("Name: ") ) > << down << ( panel << horizontal > << button("OK") > << button("Cancel") ); > > Which, assuming my parens are right, could give you something > like: > > +---------------------------------------------+ > | Hello, world! | > | Name: ____________________________ | > +---------------------------------------------+ > | /-------\ /--------\ | > | | OK | | Cancel | | > | \-------/ \--------/ | > +---------------------------------------------+ > For sure, to be sure. Not sure I like the approach though. You could off add and << as alternative for the same thing. I see that you could have multiple properties for the same container by having the result as the container too. Some_widget << colour_red << width(pixel(100)) << text_box << font("Arial") << height(millimetres(8)); Not unreasonable and you could format it like Some_window << ( some_widget << colour_red << width(pixel(100)) << some_other_property ) << ( panel << horizontal << ( button("OK") << click_event( dooby_doo::on_click ) ) << button("Cancel") ) ; Not as bad as I thought before I started typing this mail... Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ 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.

1 0

RE: [boost] GUI library - another one
by Hurd, Matthew 04 Mar '04

04 Mar '04

> On Behalf Of Beman Dawes <snip> > Even the "why not" version seems overly complex compared to a console > iostreams "Hello, world". Why not just: > > winout << title("Example window") << button("Hello, world!") > << wait_for(delete_signal); > > I'm not necessarily pushing that exact approach, but just pointing out > more > C++-like alternatives. I understand you're not pushing that approach. It couldn't quite work like that as you're trying to structure a tree rather than a sequence. Your << approach might be nice syntactic sugar for adding an element and event_handlers or listeners and / or modifying a property. Regards, Matt Hurd. 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.

3 2

RE: [boost] Re: First lambda
by Powell, Gary 04 Mar '04

04 Mar '04

>> // PROPOSED CHANGE IN SOME FUTURE PAPER >> >> unsigned long n = std::accumulate( >> xs.begin(), xs.end(), 0UL, >> long (long lhs, X const &rhs) // inline fn with no name. >> { >> return lhs + rhs.count; >> } >> ); >Yeah, but do you propose to make local names visible inside the anonymous >function, or not? If you do, you open a big can of worms for implementations >(recursive nested functions, need I say more?), if you don't, BLL can still >do things that anonymous functions can not. Anonymous functors could help >some, but their syntax won't be quite as compact as your example above. >...Max... In my plan, variables would have same scope in a function as they do now. i.e. variables local to std::accumulate are not visible in the anonymous fn. And yes its not a panacea. For instance, what about static variables in an anonymous function. Do they have the lifetime of the program, or does the anonymous function have a "lifetime" of the calling function? e.g. unsigned long foo (vector<X> const &xs) unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, unsigned long (unsigned long lhs, X const &rhs) // inline fn with no name. { static unsigned long y = 0; return ++y * (lhs + rhs.count); } ); return n; } int main() { vector<X> xs; // ... initialize xs unsigned long a = foo(xs); unsigned long b = foo(xs); a == b; // depends on the lifetime of foo::anonymous::y return 0; } In this case perhaps a functor created with a mix of BLL and an anonymous functions would be clear. Yours, -Gary-

4 3

RE: [boost] Re: [named_params] timing trivia and some comments
by Hurd, Matthew 04 Mar '04

04 Mar '04

> On Behalf Of David Abrahams > Subject: [boost] Re: [named_params] timing trivia and some comments > > > "Matthew Hurd" <matt(a)finray.net> writes: > > > Been looking at the very cute named_params in the sandbox. Getting > > around to trying to do some stuff with it. <snip> > > I'm deeply impressed. Well done Dave and Daniel. > > You can thank the good people at Microsoft for that. I don't think > we put any special attention on avoiding abstraction penalty other > than doing the obvious things (e.g. pass classes by reference). Design helps and the magic of C++ optimisation ;-) > > It would be nice if the macro could some how encapsulate the keyword > > definition so this might be eliminated. > > struct base_t; > > struct exponent_t; > > > > namespace > > { > > boost::keyword<base_t> base; > > boost::keyword<exponent_t> exponent; > > } > > > > struct power_keywords : boost::keywords< base_t, exponent_t> {}; > > Good point... but we anticipate the keywords for a given library will > probably be re-used in several function interfaces, so we can't > rightly do it all with a single macro invocation -- you might need to > write several lines like the last one, for different functions. We > can do something like: > > BOOST_NAMED_PARAMS_KEYWORD_DECL((base)(exponent)) > > to generate the keyword declarations and then something like: > > BOOST_NAMED_PARAMS_KEYWORD_SET(power, (base)(exponent)) > > for each line like the last one. That would work nicely. Though there might be some benefit in not reusing the keywords and putting them into a namespace with the function and I think ADL might help with the keyword name resolution. Hmm, or does it. I'll try it. > > The pre-processor trickery to do this is beyond me I'm afraid. > > It's not hard, if you're willing to spend the time poring through the > PP lib docs. I just worry a little about ending up with a library > interface that hides everything behind macros. I'll give it a crack. Though I too am concerned about ending up with a macro mess and little C++. Would be much nicer if there was a generative C++ approach that was suitable. > > I am interested in being able to iterate over the parameters extracting > > keyword_types, argument types and argument values. > > Since the parameters can have heterogeneous types, there's no way to > iterate over them. It would, however, be possible to "recurse" over > the items with something that looks like: > > for_each(params, some_templated_function_object) > > > Convenient string names would be good too but I can always uses > > typeid on the keyword_types. > > > > Why would I want to do this? I would like to use this approach as a way > for > > inserting an intermediary function. Specifically, I would like to call > > f<direct>(x,y) and have the direct representation called or f<marshal, > > destination>(x,y) and have an intermediary serialize the params into a > block > > and send it off on a transport where a representation along the lines of > > f<marshal, source>(x,y) would accept the block in some infrastructure > > somewhere else. f<queue_for_processing_in_a_thread_pool>(x,y) fits this > > model too. > > > > Any thoughts? > > I guess my first thought is: "Whaa??? What does any of the above have > to do with a named parameters library?" Pretty much nothing. I just like the named_params style of interface and wanted to adopt the approach. I want to build a mechanism where it is easy to build an interface to a function / functor than can have a policy that allows it to be a normal function or something else such as a function in worker pool or a remote function. My desire is to make it easy to represent a function and keep this orthogonal to whether it remote, pooled or local via a policy. For some of the mechanisms I actually would like names for the parameters to help fulfil a protocol requirement, thus the desire for introspection on the names and a look into your neat library. > And then I think: "OK, he wants something that mates the serialization > library from Robert Ramey with the new tuples (fusion) from Joel de > Guzman". This was my original thought. To use tuples and Robert's serialization. I haven't looked at the new tuples in fusion. Will do so. The get<0>(mr_tuple) approach is not as nice and it doesn't have a unique name for the param. I'll have a think about this. Which ever approach Robert's serialization will be a key plank. > I can begin to vaguely see a reason to slap a named parameters > interface on top of the whole thing, but it seems like you could do > that as an afterthought. Am I missing something? I must be. One extra note for you. There was a couple of typos in the doc. From memory, the order of the arity and the keywords in the macro are transposed in the documentation. Also the docs still refer to params[name | default] rather than p[name|default]. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ 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.

3 2

RE: [boost] Re: [named_params] timing trivia and some comments
by Hurd, Matthew 04 Mar '04

04 Mar '04

> On Behalf Of David Abrahams > Subject: [boost] Re: [named_params] timing trivia and some comments > > >"Hurd, Matthew" <hurdm(a)sig.com> writes: > > >> I guess my first thought is: "Whaa??? What does any of the above have > >> to do with a named parameters library?" > > > > Pretty much nothing. I just like the named_params style of interface > > and wanted to adopt the approach. > > > > I want to build a mechanism where it is easy to build an interface to a > > function / functor than can have a policy that allows it to be a normal > > function or something else such as a function in worker pool or a remote > > function. > > > > My desire is to make it easy to represent a function and keep this > > orthogonal to whether it remote, pooled or local via a policy. > > You're describing boost::function<...> now. Nearly, yep. I just want the cool named and default parameters with support for iteration / recursion over the parameters with a bit of introspection. > > For some of the mechanisms I actually would like names for the > > parameters to help fulfil a protocol requirement, thus the desire for > > introspection on the names and a look into your neat library. > > So put a named-param front end on a boost::function (?) OK, I'll take your advice and have a look at doing this. I'll also have a think about if I can find a way to generate the alternative functions using a class generation approach instead of macros later too. Thanks Dave, Regards, Matt Hurd 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.

1 0

RE: [boost] Re: GUI library - another one
by Hurd, Matthew 04 Mar '04

04 Mar '04

> On Behalf Of Jesse Booher > Sent: Thursday, 4 March 2004 8:05 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: GUI library - another one > > It is never a bad thing when someone is interested in donating their time > to develop software to share with the world, and if there is a community > of developers here with the time and motivation to develop a full featured > GUI library that rises to the high standards of Boost that would be a > wonderful thing. That said a GUI library is a *HUGE* undertaking and > other cross platform libraries like wxWidgets have a big head start. Not > that this is a race or anything but when it comes to GUI libraries, > features nearly always trump form. After all an awkward interface is a > developer annoyance, whereas a missing feature can be a show stopper. > > There is a certain allure to clean slate designs and there may very well > be no existing open source user interface projects that you would consider > worthy of your time, but I wondered if you have considered any slightly > less ambitious alternatives such as creating a framework employing > components from an existing open source project? It seems to me that the > promise of open source development is not served when wheels (or widgets) > need to be reinvented over and over again. I'd agree with this sentiment. The world is littered with limited cross platform gui libraries. I'd take a decent free one, such as wxWidgets (nee wxWindows), and look at wrapping its elements and leverage that experience. Add new controls/widget later. If it doesn't make boost maybe it could make wxWidgets... Building a RAD tool than generates C++ and resource files including itself in a self hosting way would be an excellent driver. I've never met a gui lib I've liked and I've met quite a few in the street. Ugly critters, they all need a big bath in some sheep drench. Lack of good GUI is a thorn in C++'s side. GUI in C++ is just too hard. Too messy. I want something RADically different. Some new, not just neat C++. The strength of a new approach in C++ could help improve the C++ community. Firstly, I'd like to see it driven by both a user requirement of building the gui and the developer requirement of elegant portable c++. I'd like to see a few things I'd like that are probably a little different to current approaches: 1. The ability to drap and drop complete panels in the builder where they are can be aware of their context and automagically hook up to their context if possible. This means "inheriting" a context where a property can hook up to a provider automagically if there is one that makes sense. E.g. you have a property stock_code, which goes up the structural context of the gui until it finds a match, or it is mapped. This way you can drag and drop components with a minimum of fuss. It is a bit like how events propagate on current windowing systems. This reminds me a little of spirits closure syntax. 1a. An extension to this is addressing properties where the scope of the property is found in the structural hierarchy automagically. Allowing automatic proprogation up and down the hierarchy would be neat. For example, I change my background colour and my parents do too until a parent is reached that doesn't with to. That kind of thing. Also being able to expose data / containers in a similar form so I can just get the stock_code that is relevant to my context by looking up my structural heirarchy... That kind of thing. 1c. Being able to address components and data by structure at run time where that structure may be constructed at run time in a similar way. 2. A natural MVC mechanism where changes flow by default but can have quality of service parameterisation added, like: stop it; all changes, but bundle them up; if there is a queue of changes cause I'm slow, just give me the latest, etc. That kind of thing. QoS is not so important to me but having the design there to support this is. A lot of systems I deal with need this feature as I often have torrents of data. Events would flow down the structural hierarchy similar to point 1. This flow is how gui toolkits already typically work for events. 3. A good sizing mechanism. Either swing or wxWidget sizer like (which often doesn't work out well for small devices) or something that is specifically laid out with pixel accuracy, perhaps with minimum size, with simple ratios of stretchiness. Julian Smart's DialogBlocks is going down this track with wxWidgets. 4. An annoyance of current approaches is that some things are fixed at widget creation time and some things are adaptable properties at run time. I'd like to see them all as run time properties. This could be approached wrapping current kits by buffering the display, deleting and re-creating the widget. Temporary messy implementation for a nice orthogonal concept. 5. Support Metalayout, with windows draggable to tool bars, tabs. Docking at the window edges and the like. wxWidgets frame layout toolkit does this for you. 99. It would be neat to have an abstraction layer where the gui detail was separated from the functional layer via a pipe which could be local or remote to support a fat, thin or chunky client approach. Eventually and approach where the code might migrate from server to client, and vice versa, to support execution where ever it is optimal... I call this the smart client approach :-) These have not much to do with c++, but such an approach in c++ could help c++. If I were to tackle this, I would take wxWindows as my implementation level so I get linux, win32 and mac with native controls and start building a gui composition thing that could generate the c++ and resource files I needed. Concurrently developing the c++ framework. A goal would be to self hosting where you can generate yourself. All the other neat c++ mentioned in this thread still holds true, but I think there needs to be more than just yet another gui toolkit for c++ and the focus needs to be on making a) a nice framework and b) something a little more innovative or added value than just yet another signal / slot or event routing thing. A neat way of simply composing the stuff by taking form of structural context and with a form of structural addressing (I just made that term up) might be the basis of such an innovative approach. A way I like to think of it is a workflow / graph / state machine that is hierarchically composed where each node can address it children and parents and some of the nodes / objects have i/o side affects which might include gui drawing stuff. Does this make sense or is it more of my typically worthless ramble? Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ 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.

1 0

Re: [boost] FC++ examples?
by Dave Gomboc 03 Mar '04

03 Mar '04

> In any case, I failed to extol other (non-obvious) virtues of > the quicksort example. A lazy quicksort can be used... The skeptic will in turn point to the C++ standard library routines: http://www.sgi.com/tech/stl/partial_sort.html http://www.sgi.com/tech/stl/nth_element.html > Again, the overall point is that some of the "slower" > elements of FC++ can offer you trade-offs: choices you > wouldn't otherwise have. Lists and lazy evaluation may not > always be the best choice for performance- critical portions > of applications, but for other cases they can often yield > novel and/or simpler designs. I think it's too much to ask Brian to defend functional programming as a whole. Some people will use fc++, and some won't -- I don't see how this differs from regex, spirit, etc. Ten years ago if you spoke of generic programming you might get a funny look from people, and "what do I need that for?". That's the reaction I'm sensing about functional programming by some reviewers. I hope that the review manager ignores that reaction, and makes their decision based upon the library itself. Dave

1 0

RE: [boost] Re: First lambda
by Powell, Gary 03 Mar '04

03 Mar '04

>> It sure would've been nice to be able to write _2.count, or count(_2), or >> _2.count(), but we can't, so we bind(). ;-) The regular syntax has its >> advantages, and the initial "member pointer first" surprise is a one-time >> adjustment. >It's an issue of how far the language is, mentally, from the domain >abstraction it represents. > _2.member(&X::count) >maps more directly to > _2.count >than > bind(&X::count,_2) >does. For me. >Dave Abrahams Ahhhh, Now I understand what you want. That's no problem at all. I thought you wanted to be able to do this, vector<X *> xs unsigned long n = accumulate(xs.begin(), xs,end(), 0UL, _1 + _2->count ); where the operator->() of the class LamdaPlaceHolder<2>, returns a lambda object that has a member pointer to "count". Hence my confusion about your earlier email. Yours, -Gary-

1 0

RE: [boost] Re: [named_params] timing trivia and some comments
by Hurd, Matthew 03 Mar '04

03 Mar '04

> On Behalf Of Peter Dimov > Subject: Re: [boost] Re: [named_params] timing trivia and some comments > > > David Abrahams wrote: > >> "Matthew Hurd" <matt(a)finray.net> writes: > >> > >> Why would I want to do this? I would like to use this approach as a > >> way for inserting an intermediary function. Specifically, I would > >> like to call f<direct>(x,y) and have the direct representation > >> called or f<marshal, destination>(x,y) and have an intermediary > >> serialize the params into a block and send it off on a transport > >> where a representation along the lines of f<marshal, source>(x,y) > >> would accept the block in some infrastructure somewhere else. > >> f<queue_for_processing_in_a_thread_pool>(x,y) fits this model too. > >> > >> Any thoughts? > > > > I guess my first thought is: "Whaa??? What does any of the above have > > to do with a named parameters library?" > > > > And then I think: "OK, he wants something that mates the serialization > > library from Robert Ramey with the new tuples (fusion) from Joel de > > Guzman". > > Conceptually, I think that he wants to serialize a boost::function<>. My > advice is "don't bother". I use shared_ptr<Command> for serializeable > polymorphic functions. Not too concerned about this as a simple id association gives me what I need for IPC. I just prefix the associated id to the message. Lots of options for this, just need to pick one. For a local call I'm hoping the mechanism will make the function call implicit and then there will not be a need for a function<> or shared_ptr <> indirection. Thanks for your thoughts. Appreciated. Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ 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.

1 0

FC++ examples?
by Giovanni Bajo 03 Mar '04

03 Mar '04

Hello, I wasn't able to review FC++ due to lack of time. Nonetheless, I have been following the reviews to gather what I can about this library. What am I basically missing is the most obvious question: what is this library for? Boost libraries mostly solve real-life problems of C++ coders. FC++ tries to add FP programming capabilities to C++, but I can't see how this is going to help, within a normal C++ program. The quicksort example was very cool, but it turns out that the generated code is too slow to be used for everything. If I need FP everywhere, I change language. Are there a couple of examples showing real-life C++ problems that can be solved with the help of FC++? -- Giovanni Bajo

2 1

Re:Re: serialization library #17
by Robert Ramey 03 Mar '04

03 Mar '04

Neal Becker wrote: >I have 1 more question. What about an archive that uses mmap? This should >be very efficient for saving/restoring large structures in binary format. >Is this a good idea? I did all the STL collections as I considered these "fundamental". . I did a version of shared_ptr myself as a test/proof of concept. 1 more question? Hmmm so for I have received submissions for serialization of optional, scoped_ptr, date_time library among othersThese are from people who needed to serialize other boost objects that they use. I've stopped incorporating them as the library is getting too big for me to manage. If this library is ever accepted, serialization of boost components will have to be a responsibility separate from the serialization library itself. After, they are really applications of the serialization library rathet than components of the library. So feel free, to make a serializer for any kind of data structure you find useful. All we have to do is to find a place to put it. Robert Ramey

6 9

FC++ -- reminder formal review ends today at midnight PST
by Mat Marcus 03 Mar '04

03 Mar '04

Please remember that the formal review for FC++ ends today at midnight PST. Please post your reviews, comments or questions today. Thanks, Mat ### once again the original notice reproduced below for your convenience The formal review of fcpp by Brian McNamara and Yannis Smaragdakis is now in progress, running from Friday February 13th at 12 noon, PST and and run to Monday, February 23rd, 12 noon PST. The library is currently available at <http://www.cc.gatech.edu/~yannis/fc++/boostpaper/> Here is a brief introduction to the library: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order polymorphic functions, currying, lazy evaluation, and lambda. In addition to the framework, FC++ also provides a large library of useful functions and data types. The main utility of the library comes from its ability to implement functional programming designs, especially those which use higher-order polymorphic functions or lazy evaluation in significant ways. The library also contains a number of ancillary components that implement features like currying and lambda for function objects; these features are also useful in their own right. For information about submitting a Formal Review, see <http://www.boost.org/more/formal_review_process.htm> Please try out the library and read the documentation and say whether or not you think the library should be accepted by Boost and why. Compiler notes: This library has been tested with icc7 and with gcc-3.1.1 (and various other gcc-3.x.y versions) on Solaris and Linux. The library is also likely to compile on VC++7.1 and Comeau (prior versions of the library succeeded with these compilers, but this particular snapshot has not been tested with them). The library covers a great deal of the C++ language and thus requires a high degree of standard conformance; compilers like gcc-2.95.x and VC++6 will not be able to compile the library. Getting started: The web page http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ mentions all the basics: The zip file will expand into these subdirectories: fcpp/fcpp/ # the library (.hpp) files fcpp/fcpp_clients/ # the example (.cpp) files Running the examples just involves invoking the complier with the right #include paths; for example, # in the fcpp_clients directory g++ -I/path/to/boost -I../fcpp some_example.cpp There is also a gnu-style Makefile included with the clients (examples), which will compile all of the examples in batch (you will have to edit a tiny bit at the top of the Makefile). The examples in the clients directory are a mix of both (regression-type) tests cases which cover the features of the library and example applications which demonstrate some of the library's utility. The README file in the client directory gives a short explanation of some of the more interesting clients. The documentation at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ provides a walkthrough and reference for most of the main features of the library. There are also some pointers out to other papers and documentation on the main FC++ web site: http://www.cc.gatech.edu/~yannis/fc++/ Conformance to Boost guidelines: The library meets most of the requirements described at http://www.boost.org/more/lib_guide.htm Here are a few notable exceptions: - the current library headers are too "monolithic"; you #include "prelude.hpp" and suck in all of the library - some of the lambda internals should be rewritten to use MPL rather than hand-rolled metaprogramming code - only a few of the example programs utilize the Boost testing framework (to automate regression testing) Should the library be accepted into Boost, Brian will remedy these deficiencies. (If you notice other major problems along these lines, please bring them to Brian's attention during the review.) The Formal Review manager is Mat Marcus.

6 7

RE: [boost] Re: GUI library - another one
by Powell, Gary 03 Mar '04

03 Mar '04

>>> 9. (really 0 in my view) It should use an extensive resource >>> description schema or language (for widget properties, >>> layouts and relations) that is either interpreted at run time >>> or (though I like it less) compiled into code transparently >>> to the user. This resource description should probably be XML-based. >> >> I agree, and would definitely go with a XUL-like approach for any new GUI >> library, i.e., have the GUI defined completely in an XML file. Maybe even >> handling Microsoft's future XML descriptors for GUIs (XAML?) >Well, I'd hope there would be a user-readable/writable format that >could be used as a front-end. You can go a long way in plain text: > +--------+ > | button | > +--------+ > * radio > * buttons > [ ] checkbox > you get the idea, I hope. >-- >Dave Abrahams While a human readable front end is nice, a machine parsable file is key. I've written I think 3 or 4 of these data format file GUI's and it always starts out as some simple GUI and rapidly becomes an embedded control language. Why because programmers don't want to spend time doing layout and button control! It is just a huge time suck. And every manager has a different opinion. What you want is out of that loop. Let the art director and the manager haggle over what the buttons look like and do. Ideally you create a flexible file format, and XML comes to mind, and then write a GUI tool to let the artists create button art, and tell it how where and how its connected. Then programmers write code which is event based. Then no matter the button is, or how its pressed, the program still runs. Last minute art is no problem. Last minute GUI changes, easy. The button "Quit" still sends a "quit" message. And no recompile, or new binary is necessary. I also despair of a multi platform GUI, it always seemed that each platform had its own look and feel and that users hated anything that reminded them of the other platform. Hence if you can abstract the "message" from the "button" you can have a dropdown menu in one platform and a radio button on another and the program should not care. So if you are selling software, do everything you can to get the "button" logic out of the program and into the art/menu/GUI control system. Layout. Its really nice if you can attach one piece of art to another so that they always line up. But that usually means "pixel" coordinates. Ever look at a game and see that the title is in flames and wonder what's going on? It's like 12 pieces of flame art all designed to run in a cycle. A good GUI can handle that easily. It's enter 12 pieces of art file names, and a sleep time between each in milli seconds and a set of coordinates for each art file that is exactly the same. It's one thing to have layout art such that no matter what size the window is, the art moves to fit, its another to have that same art "burn". Those positions are relative but "exact". A rollover button that highlights as you drag your mouse over it? 2 pieces of art at the same position with another sleep so it doesn't "flash". Depress it and there is a depress "on" followed by a undepressed "on". rollover that and its "highlighted on" art. It looks very 3D but is just wads of art. My recommendation is write a "control from the menu" library. A drawing library, a parse the dang Art file library. Make it send 'text' messages to the control library. Yes this is a bit heavyweight but all the light weight libraries I ever wrote became heavyweight in about 30 seconds due to changed requirements. So start with a resource file that can grow, write a quick text to resource file parser and then an artist GUI to resource file tool. I bet if you look at the game developer sites you'll find some of these already written (But not as well as you'd like.) Yours, -Gary-

1 0

Nightly CVS snapshot
by David Abrahams 03 Mar '04

03 Mar '04

Has anyone else tried to bunzip2 the nightly Boost CVS snapshot recently? My cron job keeps telling me there's a broken pipe; maybe there's something wrong with the archive file? -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

[named_params] timing trivia and some comments
by Matthew Hurd 03 Mar '04

03 Mar '04

Been looking at the very cute named_params in the sandbox. Getting around to trying to do some stuff with it. Noticed something interesting w.r.t. vc7.1 optimization: BOOST_NAMED_PARAMS_FUN(double, power, 0, 2, power_keywords ) { double b = p[base | 10]; double e = p[exponent | 1]; return pow(b ,e); } double pow_wrap(double b, double e) { return pow(b,e); } are the same speed, around 25 nanoseconds on my machine, when called with some variable parameters ( now = pow_wrap(t.elapsed(),t.elapsed() / (rand() * t.elapsed())); ) to defeat the chance of variable elimination and constant propagation. But interestingly, BOOST_NAMED_PARAMS_FUN(double, power, 0, 2, power_keywords ) { return pow(p[base | 10] , p[exponent | 1]); } is more than five times slower at 144 nanoseconds. Which is the opposite to what I would of expected... Anyway, I found it interesting :-) It seems the take home message for me is that it is possible to use the named_params library with no, zippo, notta bit of abstraction overhead even for a very simple function wrap. I'm deeply impressed. Well done Dave and Daniel. It would be nice if the macro could some how encapsulate the keyword definition so this might be eliminated. struct base_t; struct exponent_t; namespace { boost::keyword<base_t> base; boost::keyword<exponent_t> exponent; } struct power_keywords : boost::keywords< base_t, exponent_t> {}; The pre-processor trickery to do this is beyond me I'm afraid. I am interested in being able to iterate over the parameters extracting keyword_types, argument types and argument values. Convenient string names would be good too but I can always uses typeid on the keyword_types. Why would I want to do this? I would like to use this approach as a way for inserting an intermediary function. Specifically, I would like to call f<direct>(x,y) and have the direct representation called or f<marshal, destination>(x,y) and have an intermediary serialize the params into a block and send it off on a transport where a representation along the lines of f<marshal, source>(x,y) would accept the block in some infrastructure somewhere else. f<queue_for_processing_in_a_thread_pool>(x,y) fits this model too. Any thoughts? Regards, Matt Hurd. __________________________________________ First case results: ---------------------------------------------------------------------------- ---- looper invasive timing estimate simple_named_params ---------------------------------------------------------------------------- ---- median time = 24.88038277512962 nanoseconds 90% range size = 9.926167350636332e-015 nanoseconds widest range size (max - min) = 10.8665071770335 microseconds minimum time = 24.88038277511962 nanoseconds maximum time = 10.89138755980862 microseconds 50% range = (24.88038277512962 nanoseconds, 24.88038277512962 nanoseconds) 50% range size = 0 nanoseconds ---------------------------------------------------------------------------- ---- looper invasive timing estimate simple_wrap ---------------------------------------------------------------------------- ---- median time = 24.88038277512962 nanoseconds 90% range size = 9.926167350636332e-015 nanoseconds widest range size (max - min) = 10.51913875598087 microseconds minimum time = 24.88038277511962 nanoseconds maximum time = 10.54401913875599 microseconds 50% range = (24.88038277512962 nanoseconds, 24.88038277512962 nanoseconds) 50% range size = 0 nanoseconds Second case: ---------------------------------------------------------------------------- ---- looper invasive timing estimate simple_named_params ---------------------------------------------------------------------------- ---- median time = 144.4976076555124 nanoseconds 90% range size = 0 nanoseconds widest range size (max - min) = 1.#INF seconds minimum time = 144.4976076555077 nanoseconds maximum time = 1.#INF seconds 50% range = (144.4976076555124 nanoseconds, 144.4976076555124 nanoseconds) 50% range size = 0 nanoseconds ---------------------------------------------------------------------------- ---- looper invasive timing estimate simple_wrap ---------------------------------------------------------------------------- ---- median time = 24.88038277512962 nanoseconds 90% range size = 3.308722450212111e-015 nanoseconds widest range size (max - min) = 1.#INF seconds minimum time = 24.88038277512295 nanoseconds maximum time = 1.#INF seconds 50% range = (24.88038277512962 nanoseconds, 24.88038277512962 nanoseconds) 50% range size = 0 nanoseconds

3 3

Re:Re:Re: serialization library #17
by Robert Ramey 03 Mar '04

03 Mar '04

Neal D. Becker wrote: >Thanks. Actually, though, what I'm talking about is a different archive >type, not a data structure. Right now binary data is saved/restored using >read/write. mmap is potentially much more efficient for large data >structures. OTOH, there is one big problem for it, which is that mmap can >only be applied to one contiguous memory region. I believe you would have >to serialize one object to one file, and if you want more objects you would >need multiple files to map them to. Still, might be interesting. Hmmm - wouldn't be better to implement a new derivation of std::;basic_streambuf for memory mapped i/o. This would be useful for a lot more than serialization. Of course, all the archive already provided are implemented in terms of streams so they would automatically inherit all the features of memory mapped i/o. The whole topic of custom stream_buf versions or better yet, composable stream_buf adaptors has been under appreciated in my view. I know there was some discussion and work done. I don't know what happened. I suspect it turned out to be "too big" to finish to boost standards in the amount of time that the developer could allocate. I do much appreciate feedback on the serialization library on this list. It is very helpful and encouraging. Note that others have made significant efforts well. These are people that have been experimenting with the library in their own projects. They have been very patient and helpful. Among others I would mention Pavel Vozenilek, Vladimir Prus, David Tonge, and Jeff Finn. Robert Ramey

5 6

bug in string_algo
by John Torjo 03 Mar '04

03 Mar '04

Hi Pavol, Downloaded the latest string_algo from the CVS. It seems to be buggy. First of all, I expect the following to work: std::string result; boost::replace_range( result, "\r\n", "\n"); It fails, with a couple of errors (I'm using VC7.1). Since the above failed, tried to create a function to be equivalent: void replace( std::string & str, const char * find, const char * replace) { boost::replace_range( str, boost::make_range(find, find + strlen(find)), boost::make_range(replace, replace + strlen(replace)) ); } This also fails to compile: d:\boost\boost_latest_sandbox\boost-sandbox\boost\string_algo\iterator_range.hpp(96) : error C2664: 'std::basic_string<_Elem,_Traits,_Ax>::iterator::iterator(std::basic_string<_Elem,_Traits,_Ax>::iterator::pointer)' : cannot convert parameter 1 from 'const char *' to 'std::basic_string<_Elem,_Traits,_Ax>::iterator::pointer' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] and [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] Conversion loses qualifiers d:\john\projects\logview\log_handler.cpp(6) : see reference to function template instantiation 'boost::iterator_range<IteratorT>::iterator_range<const char*>(const boost::iterator_range<const char *> &)' being compiled with [ IteratorT=boost::string_algo::container_traits<std::string>::iterator ] d:\boost\boost_latest_sandbox\boost-sandbox\boost\string_algo\iterator_range.hpp(96) : error C2664: 'std::basic_string<_Elem,_Traits,_Ax>::iterator::iterator(std::basic_string<_Elem,_Traits,_Ax>::iterator::pointer)' : cannot convert parameter 1 from 'const char *' to 'std::basic_string<_Elem,_Traits,_Ax>::iterator::pointer' with [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] and [ _Elem=char, _Traits=std::char_traits<char>, _Ax=std::allocator<char> ] Conversion loses qualifiers This seems pretty unacceptable to me. Best, John

2 1

Indexed Set: design/naming thoughts
by Darren Cook 03 Mar '04

03 Mar '04

Hi, Some thoughts on design/naming after reading docs of indexed_set (version 9). I've not tried compiling anything yet. 1. The naming here seems redundant: employee_set::nth_index_type<1>::type employee_set::index_type<name>::type Can't the "::type" bit be dropped"? Or the _type, e.g. employee_set::nth_index<1>::type employee_set::index<name>::type 2. Do tags have to be structs? struct name{}; ... non_unique<tag<name>,member<employee,std::string,&employee::name> ... employee_set::index_type<name>::type While it looks okay in tutorial examples, I can see not wanting that in the main namespace in a real program. But then having to use a namespace each time I use the tag will be make it a bit ugly: non_unique<tag<tags::name>,member<employee,std::string,&employee::name> ... employee_set::index_type<tags::name>::type If it was a string instead is it less efficient (or maybe it does not compile)? non_unique<tag<"name">,member<employee,std::string,&employee::name> ... employee_set::index_type<"name">::type 3. I think the compose_key example will be needed enough that it should be part of the main library. 4. I think some macros would be useful to enhance readability (rather than just to handle compiler incompatibilities as currently). I'll see what I come up with as I try to use the library. Darren

2 3

Re: [boost] serialization library #17
by Robert Ramey 03 Mar '04

03 Mar '04

Jeff Garland wrote >Just so you know, the compile blows up with the CVS as of about a day ago. >I'm sure not your fault, but so you know... Well, as you can imagine, I'm happy to know that. At times during this development I used the development tree and other times I used the latest release. Basically I use the latest release rather until I need something that is only in the development tree. This happened with new iterators and mpl. When the release candidated 1.31 came out I switched back to that. My motivation for preferring the latest release is that I would like to upload something that I can expect to work and other people can test with a minimum amount of hassle. I'm mean I have enough problems with my own flakey ( er.. experimental) code with out adding in everyone else's. So as things stand now I'm inclined to work to the 1.31.0 . Having said that, it seems to me the development tree is considered "experimental" where as I would prefer that it be considered "Candidate for Release" That is, I think code is uploaded without out being fully tested in one's local environment. I think this creates a chain reaction at release time. Its not that I think anyone is really wrong, just that I think things would be better if developer's were a little more conservative. (But then, I'm getting old, I think that about everybody) In this case presumable something in new iterators has changed and caught me with my pants down (for the second time !). Oh well. I'll worry about it if we ever get to incorporating the library in a release. Robert Ramey

3 2

serialization library #17
by Robert Ramey 03 Mar '04

03 Mar '04

Fellow boosters, I have just uploaded serialization17.zip to the boost files section at Yahoo.com. A copy can also be found at www.rrsd.com This is the latest version of my serialization library. It has been built and tested in debug and release mode with VC++ 6.0, VC++ 7.0, VC++ 7.1, GCC 3.2, and GCC 3.3. It requires boost 1.31 to function. It has no known bugs. Compared to previous versions, documentation, examples, tests and portability have all been enhanced. I would like this library to be placed in the review queue. Robert Ramey

4 6

Re: [boost] Re: [Threads] Simple active object wrapper, take 2
by Mark Blewett 03 Mar '04

03 Mar '04

At 01:02 28/02/2004, you wrote: >scott <scottw <at> qbik.com> writes: > > ps: > > the sample code from mark blewett looks very promising? > > > >Yes. Although from my point of view, it has the same drawback with switching >on messages that you have. I wonder if the queue of messages in the servant >class could be a queue of fully-bound function calls, I'm halfway there, in that the queue holds callbacks, eg in Servant::dispatch the "do something with m" simply executes the callback. To give a usage example class MyServant : public Servant { public: MyServant(Scheduler* scheduler) : Servant(scheduler) {} void do_fn(int x, int y) { std::cout << x << " " << y << std::endl; } }; int main() { Scheduler scheduler; scheduler.start(1,1); MyServant my_servant(&scheduler); my_servant.post_call(new CallbackVAA<MyServant,int,int>(&my_servant, &MyServant::do_fn, 1, 2)); scheduler.stop(); return 0; } will result in the output "1 2" via one of the schedulers worker threads >generated by proxy >objects which describe interfaces? (Yes, I am quite enamoured of that >idea :)) Interesting idea... assuming I'm understanding correctly.. in that the callback is created by an object in the servant class, the above becomes; class MyServant : public Servant { public: MyServant(Scheduler* scheduler) : Servant(scheduler), fn(this, &MyServant::do_fn) {} MethodProxy<MyServant, int, int> fn; private: void do_fn(int x, int y) { std::cout << x << " " << y << std::endl; } }; int main() { Scheduler scheduler; scheduler.start(1,1); MyServant my_servant(&scheduler); my_servant.fn(1, 2); // certainly a lot easier to understand than previous example! scheduler.stop(); return 0; } Regards Mark --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.573 / Virus Database: 363 - Release Date: 28/01/2004

3 3

RE: [boost] Container Traits
by Powell, Gary 03 Mar '04

03 Mar '04

This library is an interesting concept but when I looked in it, it didn't have what I would have thought were "container traits" the way I think of "iterator traits". From the VTL library I wanted to be able to query the container to see if it was an associative container, or a sequence container or a random access container, i.e. had an operator[]() etc. Can one of the authors explain the purpose of this library? Yours, -Gary-

4 3

potential problem with indirect_iterator (GCC 3.3.2)
by Shannon Stewman 03 Mar '04

03 Mar '04

I sent this a couple days ago, but I think it became lost in the ether when the list moved machines.... apologies if it didn't. I noticed a small potential problem with indirect_iterator. I've been using it with raw pointers, and the default constructor appears broken in this case (gcc-3.3.2): #include <boost/iterator/indirect_iterator.hpp> #include <iostream> struct MyType {}; typedef MyType* MyTypeList; typedef boost::indirect_iterator< MyTypeList, MyType > Iter; int main( int argc, char** argv ) { std::cout << "Iter() == Iter() ? " << ( Iter() == Iter() ) << std::endl << "Iter(NULL) == Iter(NULL) ? " << ( Iter(NULL) == Iter(NULL) ) << std::endl; } The output is: Iter() == Iter() ? 0 Iter(NULL) == Iter(NULL) ? 1 Is this an actual bug, or am I misusing the code? If I'm misusing the code, is there some reason for this? It's inconvenient that the default constructor doesn't initialize pointers to some consistent value; the problem goes away when I change the indirect_iterator default constructor: 94c94,96 < indirect_iterator() {} --- > indirect_iterator() > : super_t( Iterator() ) > {} Best, -- Shannon Stewman | Let us walk through the waning night, Caught in a whirlpool, | As dawn-rays tickle our toes, the dew soothes A quartering act: | Our blistered soles, and damp bones stir Solitude or society? | As crimson cracks under the blue-grey sky.

3 5

RE: [boost] Assignment Library
by Powell, Gary 02 Mar '04

02 Mar '04

After a quick look at the Assignment library, it would appear that this library would benefit from a "container traits" library that it could query for things like whether to use "insert" or "push" to call for make_insertion() rather than specify each std::stl container. It just doesn't seem to be very extensible. Rather wouldn't it be better if a user could define the traits class for your container and then the assignment would pick the right one? Yours, -Gary-

2 1

RE: [boost] [Threads] Simple active object wrapper, take 2
by scott 02 Mar '04

02 Mar '04

> [mailto:boost-bounces@lists.boost.org]On Behalf Of Matthew Vogt nice! only one item of feedback really. think that i follow your machinery and can envisage the "model of execution" - its pretty slick. its also somewhat different to the pattern :-| so i would wonder at the use of "active object"? is your model of execution the one that everyone is expecting of the previously, unimplemented class? this does seem to be a class/framework for (very convenient) arrangement of concurrent method execution. which piece of the ActiveObject pattern does this map to? other than the "claiming of the name", it looks like its got legs! ps: i s'pose anything declared in the private scope of "object" is thread safe? > > // test_active_object.cpp > -------------------------------------------------- > > > #include "active_object.hpp" > > using std::cin; > using std::endl; > <big snip>

3 20

minor min/max regression
by John Maddock 02 Mar '04

02 Mar '04

The recent min max changes have caused breakages with vc7.1 + STLPort, the problem is that this configuration defines BOOST_NO_STDC_NAMESPACE (because STLPort doesn't quite manage to import everything into it's "fake" std namespace), which causes the following code: template< typename T > inline T const & std_max( T const & a, T const & b ) { #if defined(__COMO__) || defined(BOOST_INTEL) || defined(BOOST_NO_STD_MIN_MAX) using std::max; #elif defined(BOOST_NO_STDC_NAMESPACE) using ::max; // <- error here #else using std::max; #endif return max BOOST_PREVENT_MACRO_SUBSTITUTION ( a, b ); } to fail, because min and max *are* in namespace std. Now the thing is, BOOST_NO_STDC_NAMESPACE was only really designed to check for C lib functions, it was assumed that std lib functions like min and max are always in namespace std, are there any situations where that is not the case? If not we can just ditch the #elif defined(BOOST_NO_STDC_NAMESPACE) clause altogether. John.

5 5

Question regarding usage of scoped_ptr and PIMPL
by Robert Ramey 02 Mar '04

02 Mar '04

The follow little example illustrates an issue I have with scoped_ptr. I would like to use this to automatically manage destruction of a pointer to and undefined class. It seems that scope_ptr is instantiating its destructor "too early" and complaining about incomplete type for b; In my view, this should not occur as ~a() isn't defined yet. The following example fails on vc 7.1 and gcc 3.2 Note that shared_ptr works as one would hope in this context. Is there anyway to adjust scoped_ptr to work here? Robert Ramey // in my opinion this should not fail to compile under any circumstances. // however it seems that that the inline destructor of scoped_ptr // requires a complete type even though the destructor is not defined. // note: changing scoped_ptr to shared_ptr works as one would hope // note:: changing to auto_ptr still fails in with the same problem #include <boost/scoped_ptr.hpp> struct b; struct a { boost::scoped_ptr<b> pimpl; ~a(); }; int main() { a a_instance; }

3 2

RE: [boost] Re: FC++ formal review
by Rozental, Gennadiy 02 Mar '04

02 Mar '04

> > Actually the point of my remark is that would we be able to > write meta > > programs in imperative style instead of FP style > compilation would be > > much faster. > > The slowness of metaprogram compilation has almost *nothing* > to do with the FP style of metaprogramming, and almost > everything to do with the accidental nature of the > metaprogram evaluation engine (using template instantiation). And why do we have so many template to instantiate? Exactly my point: because we couldn't change type definition we could only create new one. How many helper templates gets instantiated to remove const types from the type-list? Should be none. So you are right: it has everything to do with nature of metaprogram evaluation engine, which is FP based one. > In fact, you *can* write metaprograms in an imperative > style, given an appropriate framework designed to interpret > them correctly. It'll be much slower than what we use today. You have any grounds for this statement? > > And Spirit framework would benefit from it the most. > > I doubt that. Parsing in particular has little to gain from > the use of mutable data. I meant from compilation time standpoint. Gennadiy.

2 1

FC++ -- formal review over
by Mat Marcus 02 Mar '04

02 Mar '04

The formal review period for FC++ is over. Thanks to the authors and those who submitted reviews/comments. I will now ask for your patience as I spend some time considering the discussion and preparing my decision. - Mat

1 0

Re: win32.hpp and min/max macros
by Eric Niebler 02 Mar '04

02 Mar '04

John Maddock wrote: > Would you like to make and manage the change? Remove the workarounds from > win32.hpp, and then patch all occurrences of min and max throughout boost? > > John. <recap> We agreed to make boost work in the presence of the min/max macros by wrapping all min/max function identifiers in parens, like (std::min)(a,b); </recap> I have spent some time and made the 800 or so edits throughout boost required to make it play nice with the min/max macros. I'm running regressions now. I have a couple of questions about procedure before I can commit the changes. 1) Is this a good time? I know there's talk about a 1.31.1 release. Will this be done from the 1.31.0 branch or from main? I don't want to destabilize before a release. 2) I can't test with old compilers, which are the ones most likely to have a hard time with this change. Also, I'm not a CVS guru. If all hell breaks loose as a result of this change, is there someone willing to help me back it out? 3) Is there a boost developer style guide where we can document the fact that all calls to min/max functions must be wrapped in parens? 4) This is the sort of thing developers will forget to do even if it's in a style guide. A simple way of ensuring this stays fixed would be to run the regressions with min() and max() #defined to garbage, so that violations are detected and corrected early. Is this possible? Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

13 37

RE: [boost] Re: FC++ formal review
by Rozental, Gennadiy 02 Mar '04

02 Mar '04

> > I never question usefulness of function object > (any-morphic). What I > > do seek is an example of lazy list application. > > Then you should say so. "FP has no advantages" is a far cry > from "Lazy lists have no advantages". I actually "cry" "FC++ has no advantages". Take lazy list out of FC++, what we you be left with? Polymorphic function objects? I was agree from the very beginning it should be incorporated. Maybe though not as part of FC++, but boost::function and boost::functional Gennadiy.

1 0

review manager wanted
by Thorsten Ottosen 02 Mar '04

02 Mar '04

Dear all, I'm looking for a review manager for both these two libraries (and it need not be the same person): assignment library (see http://groups.yahoo.com/group/boost/files/assignment/ ) container traits (see http://groups.yahoo.com/group/boost/files/container_traits/ ) Both libraries are fairly small, so they should be fast-track reviews. My personal calendar says that I can handle one review in Marts. There is a good possibility that there could be a 'hole' in the review process during this month where one of these fast-track reviews can be put in. Anyone interested should contact me privately. best regards Thorsten

1 0

como-win32-tools.jam changes broke my builds
by David Abrahams 02 Mar '04

02 Mar '04

The recent changes to como-win32-tools.jam completely broke my ability to use the toolset. Nobody should be calling the "flags" rule on variables indended for user customization. -- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

Re: boost::ublas and solver
by Michael Stevens 02 Mar '04

02 Mar '04

Dear Loïc, On Tuesday 02 March 2004 00:33, Loïc Joly <loic.actarus.joly(a)wanadoo.fr> wrote: > I was recently trying to convince one of my colleagues that a vector > (mathematical, not stl) and matrix library instead of raw C arrays could > be usefull for his job. An excellent decision! > I naturally turned toward boost::ublas, but then > I had one surprise: One thing I expected to find in such a library was a > collection of solvers (LU, gaussian elimination...), but I found none. The simple answer is in the name 'BLAS'. uBLAS is a library for Basic Linear Algebra. It provides storage for vectors and matrices (dense, packed, and various sparse methods) and basic linear algebra operations. Of course all this is put together in a safe and efficient C++ package! For a more complete answer have a look at http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Linear_Algeb… > Is this because they exist, but I could not find them in the > documentation (btw, I have some trouble to understand the doc, too much > code, not enough english to my taste) ? True. Feel free to contribute documentation. I am using the Boost Wiki to organise new introductory information which can eventually be merged into the official uBLAS documentation. > Is is because there was a good design decision not to include them ? > Is it because this is a very touchy domain and poeple could not agree on > generic solutions ? > Is is just an oversight ? Yes, No and No. There is no end to the number of Linear algebra algorithms. uBLAS provide efficient infrastruture for C++ to solve these problems however. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://www.sf.net/Bayes++ ___________________________________

2 1

Review Request:serialization
by Robert Ramey 02 Mar '04

02 Mar '04

I've uploaded serialization17.zip to the boost files section. There is also a copy to be found at www.rrsd.com I am requesting a formal review of this submission. I realize there's a queue. I hope that interested parties can find the time to subject this submission to a preliminary review and that at least two of those persons can second this submission. The feedback I've received from recent prior versions of this library lead me to believe that this will occur. Robert Ramey

3 2

FC++ review
by Dave Gomboc 02 Mar '04

02 Mar '04

I put about a day into looking at FC++ (reading the papers, trying to write some small examples). I didn't have a lot of success -- partly because it has been quite a while since I last programmed in a functional language, and partly because the documentation needs serious work. Therefore, I don't have a full review to provide. Much like the serialization library, I think that this is an ambitious and important library that isn't ready to pass a Boost review on its first time around. If the author is up to it, then I'm sure further work will get it there. Re argument limit of 3: I'm a bit surprised that this has never been a problem. Seeing what boost::preprocessor can do for you is probably a good idea. Naming nit-picks: "Functor" has for years been commonly used to mean "function object" (in addition to its original meaning from category theory). [http://www.dre.vanderbilt.edu/~bala/c++-function-objects.pdf; http://www.sgi.com/tech/stl/functors.html; http://en.wikipedia.org/wiki/Functor] Have no referees of your academic publications brought this up? There is no need to name anew a common concept: therefore, s/functoid/functor globally! (Global search and replace is your friend. :-) A list type is already present in ::std, and means something different. Perhaps lazy_list, or (cringe) llist. Follow the C++ standard's practice for variable naming, e.g. TheActualTypeOfTheLambdaExpressionIsNotConvertibleToItsGivenType should be the_actual_type_of_the_lambda_expression_is_not_convertible_to_its_given _type (example from lambda.hpp)

5 5

FC++: formal review
by Gennadiy Rozental 02 Mar '04

02 Mar '04

Hi, It was quite difficult to review this submission for several reasons: mostly because (from POV) it has virtually no documentation, no structure, no testing and what is most important no clear defined problem domain, where this library provide a solution (here I mean not the function objects facilities, but namely FP part of the submission). What it does have, is a several interesting ideas. In summary it my opinion this submission is unacceptable and my vote is NO. Problem domain ------------------------------------------------------------------------- Unlike my usual review I would like to start with problem domain discussion. Library position itself as a library to do FP in C++. Namely in this order. Kind of like library for crazy Haskell programmer that for whatever reason decided to use C++. Docs (and papers) in details describe how to do things one could do in Haskell using FPC++ analogs. There is even comparison of performance with Haskell compilers: not to worry we almost as fast. For me as a C++ programmer more important is to see the comparison with the same algorithm implemented with other usual C++ techniques. I did one myself. I took an example used by authors for performance testing and modified it like this: .... here is what is already in test //////////////////////////////////////////////// inline bool is_prime( int i ) { for( int c = 2; c <= i/2; ++c ) { if( i % c == 0 ) return false; } return true; } inline int nth_prime( int N ) { int i = 1; while( N > 0 ) { i++; if( is_prime( i ) ) N--; } return i; } int main() { acc_timer timer; // acc_timer is my timer class based on gettimeoftheday int NUM; cout << "Num primes = "; cin >> NUM; timer.start(); list<int> l = primes(NUM); int i = at( l, NUM-1 ); timer.stop(); cout << i << endl << "took " << timer.elapsed() << " sec" << endl; timer.start(); i = nth_prime( NUM ); timer.stop(); cout << i << endl << "took " << timer.elapsed() << " sec" << endl; } The algorithm I am using similar to the one use by original code. The only difference is that I am not using FC++ abstraction. I was using gcc 3.3.1 under cygwin on my Athlon 2000+ PC. I was using following command for compilation: g++ -O4 -I [list of include directories] tw_primes.cpp Here is the result of several runs: Num primes = 500 3571 took 4.825 sec 3571 took 0.015 sec Num primes = 750 5693 took 11.703 sec 5693 took 0.036 sec In average FC++ solution is 320 times slower. For any practical usage price of an abstraction should not exceed 10-20%. With price as high as FC++ currently shows I wouldn't even start to think in this direction. In general from my experience usage of lazy evaluation quite limited (in FP sense - I do not mean binding the arguments, which is widespread). It may be used sometimes, but I know many more other neat tricks that are more or as useful. IMO authors need to justify need in lazy list as a generic reusable components in C++ (namely in C++ not for FP which says nothing to me), but for now I do not see a place for them. Some papers does try to justify need for FP to implement common design patters in C++. But actually they only shows need for use of polymorphic functors nothing more. Design ------------------------------------------------------------------------- I with almost everything authors says about need of polymorphic functors and the way they design support for result type deduction. But I believe it should be boost-wide solution. With support in both boost::function, boost::bind and boost::lambda. I don't think we need indirect functoids (with their virtual functions and smart_pointers inside). boost::function should be made result_of aware instead. I couldn't comment on design of lazy lists since it does not described in docs. But I still not convinced that there exist a problem to justify need for this construct. Lambda facilities design is also offsite and it's difficult to comment on it by itself and on comparison with boost::lambda. In my personal opinion there should not be two different facilities dedicated to the same cause within boost. If you have any issues with boost::lambda lets resolve them. In other case it would only source of confusion to the users and make them both less useful. Monads are not covered and not commented accordingly. Explicit built-in currying (I prefer term binding) looks like convenient idea and I would vote to include this info boost::function Implicit built-in currying on the other hand like more like a source of confusion than convenience and in my opinion should not be included. It not only may confuse inexperienced user, but also may cause a conflict If I have function polymorphic not only in regards to the type of the arguments but also in regards to their number. I do not understand need for separate notion of thunks. Why couldn't we just bind all function arguments using usual means? Library supply the collection of predefined function object. While I can blindly accept polymorphic counterparts to the STL functional ones, the rest should be documented and discussed one by one (the fact they belong to mythical "prelude" says nothing to me). Also from sources it looks like many of them operate on lazy lists. Why couldn't we have them as a member functions? They are not generic to be used for different kinds of lists (like STL list) and what is an advantage to length ( ll ) vs. ll.length(). Would I need to pass this method anywhere (rare case IMO) I could use an adaptor. Infix syntax: I do not think this feature useful enough to justify weird syntax. Most probably it wouldn't be use for anything other then several functors like plus, minus. Documentation ------------------------------------------------------------------------- There two major problems I have with docs: first they are very scarce on design of the component described and second they are written for Haskell programmer who is learning C++. I believe that at least 90% of C++ practitioners never heard about Haskell. Accordingly it should not be mention in docs AT ALL. The should not be ANY references to Haskell syntax, which instead of clarifying things make it worse and left me with feeling that I did not get something. There should be a short introduction to what is a functional programming paradigm. Comparison with existent C++ paradigms, advantages and disadvantages. I don't say it should be extensive multipage work, but just an introduction for C++ programmer not familiar with FP. There should be reference documentation for any functor supplied by the library. I am not sure there is a need for old (pre boost) references in docs. It absolutely unnecessary for new users. Why existent users may use some kind of transition guide in FC++ website. The rest of docs looks in most part as a "simple overview", while I expect to see a real full documentation. Implementation ------------------------------------------------------------------------- 0. It would be much easier if you would follow recommended boost directory structure 1. BOOST_FCPP_DEFER_DEFINITIONS This does not look like a good solution. What exactly did you try to achieve? 2. definition.cpp What is this? Does it gets compiled by any compiler? 3. All implementations needs to be rewritten using Boost PP to be extendable to more then 3 arguments. 4. Why fullN does not inherit from it's parameter, but keep it as a member instead? 5 What is konst vs. const? 6. When you will eliminate implicit currying implementation became more simple 7. binderNandK...ofM facility does not look extendable. Did you look how boost::bind is implemented? 8. There are still a lot of identifiers that does not follow recommended boost naming policy 9. Why infix syntax implementation is mixed with some library supplied functors? Testing/Examples ------------------------------------------------------------------------- There is a lot of staff in fcpp_clients directory. Since there is no test/examples separation and no Jamfiles I couldn't comment in details how it looks. Regards, Gennadiy.

7 9

Win32 regressions
by Beman Dawes 02 Mar '04

02 Mar '04

One of the actions we can take to ease releases is to fix regressions as they occur, rather than waiting until just before the next release. I'm experimenting with some new reports that combine platforms, report regressions only, and make other improvements suggested by various people. Those experiments will take a while because I'm learning xslt in the process, and have some other commitments. In the meantime, I've changed the Win32 table (http://boost.sourceforge.net/regression-logs/cs-win32.html) to show diffs against February 3rd rather than just the prior day's run. Looking at the results, there is lots of good news. Tests now passing, warnings removed, etc. But there are also regressions in a number of libraries: Date-Time - Borland regressions, one VC++ 7.0 regression. Graph - Borland, Metrowerks, VC++ 6.0, one regression each. Interval - Borland, VC++ 6.0, and VC++ 7.0 regressions. Random random-test - Regression on GCC 3.3.1. Regex concept_check - Regression on VC++ 6.0. Test test_tools_test - Regressions on VC++ 6.0 and 7.0. Hopefully the developers will take a look at these soon so the regressions don't hang around until the next release. Thanks, --Beman

5 6

Error while building threads/tutorial folder
by M Shetty 02 Mar '04

02 Mar '04

Hi, I am kind of really new to boost and to jam files. I have built bjam and then libboost_thread.so by executing bjam in the boost-1.30.2/libs/thread/build folder. But building the files in the boost-1.30.2/libs/thread/tutorial folder gives me the following error: ...found 649 targets... ...updating 11 targets... gcc-Link-action ../../../libs/thread/tutorial/bin/helloworld/gcc/debug/runtime-l ink-dynamic/threading-multi/helloworld Undefined first referenced symbol in file logic_error::logic_error(basic_string<char, string_char_traits<char>, __default_ alloc_template<true, 0> > const &)../../../libs/thread/build/bin/libboost_thread .so/gcc/debug/runtime-link-dynamic/shared-linkable-true/threading-multi/libboost _thread.so runtime_error::runtime_error(basic_string<char, string_char_traits<char>, __defa ult_alloc_template<true, 0> > const &)../../../libs/thread/build/bin/libboost_th read.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/threading-multi/libb oost_thread.so ld: fatal: Symbol referencing errors. No output written to ../../../libs/thread/ tutorial/bin/helloworld/gcc/debug/runtime-link-dynamic/threading-multi/helloworl d collect2: ld returned 1 exit status Unable to understand this kindly help. Regards, Manu ___________________________________________________ Check-out GO.com GO get your free GO E-Mail account with expanded storage of 6 MB! http://mail.go.com

1 0

Re: Re: Re: [rational] why is int_type private?
by Bjorn.Karlsson＠readsoft.com 02 Mar '04

02 Mar '04

> From: Jonathan Turkanis [mailto:technews@kangaroologic.com] > > I'd be happy to contribute these changes. My thinking was, however, > that they should wait for a new maintainer of the library. What do you > think? > Yes, that sounds reasonable; I'll contact Paul to get his view (on both this change and future maintenance of Boost.Rational). Bjorn

1 0

shared_array: how to get the number of elements in it?
by Roland Richter 02 Mar '04

02 Mar '04

Boosters, I want to write a function which compares two shared_array's element-wise (operator==() compares for pointer equality). How to get the number of elements a given shared_array contains? At first glance there seems to be no possibility; am I missing something? - Roland

3 2

Re: Re: Re: [rational] why is int_type private?
by Bjorn.Karlsson＠readsoft.com 02 Mar '04

02 Mar '04

> From: Jonathan Turkanis [mailto:technews@kangaroologic.com] > > Okay, here's a patch for boost/rational.hpp. Please let me know if > it's not in a suitable format. > > Jonathan Thanks Jonathan, It would be even better with a patch for the documentation, too. Making these two typedefs public warrants more than just changing private to public in the code, in my opinion. (Note: Context diffs are preferred [diff -c] - see http:://www.boost.org/more/bugs.htm for details.) Bjorn

2 2

FC++ formal review
by Jonathan Turkanis 02 Mar '04

02 Mar '04

Here is my formal review of FC++ -- sorry to wait to the last minute. I find FC++ to be very exciting and potentially very powerful; however, I vote that it not be accepted yet, because the changes required are extensive enough that a second review is essential. (See below for full details.) There are three reasons for the second review: - Some of the proposed resolutions (particularly the extension to handle reference parameters) may turn out on closer examination not to work adequately, or may seem to work okay for FP but raise unforseen issues when FC++ is used in other C++ frameworks (e.g. STL). - This review period has tended to focus, naturally enough, on major issues; with a library the size of FC++ there are probably many (possibly a dozen or more) smaller issues which deserve discussion. For one minor example, I'll discuss the reuser syntax below. - Once extensive changes have been made, there may be many minor issues with the new code which deserve discussion but which could not possibly have been addressed by this review since the could in question doesn't exist yet. Outline I. Basic formal review questions II. detailed discussion 1. Purpose of library 2. Naming 3. Configurable max arity 4. Support for reference parameters 5. Simplifications: simpler return type deduction; eliminate full; make full-functors simple to define; 6. Lambda expressions 7. Implementation 8. Testing I. Basic formal review questions Some of the formal review questions don't fit naturally into the rest of my discussion. * What is your evaluation of the documentation? The documentation is terrible. This has been thouroghly discussed by others, so I won't say any more. * Did you try to use the library? With what compiler? Did you have any problems? I attempted to compile all the examples with VC7.1. Five test programs failed to compile (I'll send the errors to Brian separately); one compiled but caused the IDE to crash. I compiled some on Codewarrior 8.0 and 9.2, which have more problems with FC++ than VC7.1. I'll send complete reports when I get a chance. Having studied most of the implementation, I am fairly confident that it can be made to work on any highly conformant compiler, so these errors don't worry me. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Over the course of several weeks I spend many hours studying the library. I read the main documentation, plus two of the referenced papers, and parts of the monad tutorial. I also read most of the source. * Are you knowledgeable about the problem domain? Although I am familiar with explicit lambda syntax, currying, etc., I am not knowledgeable about the FP paradigm. Until recently I knew nothing about FP monads, for instance. II. Detailed Discussion 1. Purpose of the library. I think the stated aim of the library, even as a part of boost, should be to provide a platform for functional programming research in C++, parts of which can also be used to solve problems in non-FP code. Some of these uses may be known, but many more will probably be discovered. This leads me to the following ranking of criteria for evaluating FC++, in order of importance: 1. fidelity to the FP paradigm 2. usefulness of parts of FC++ in other C++ frameworks (e.g. STL) 3. consistency with the design of other Boost libraries 4. similarity to Haskell or ease of use by FP-programmers with little C++ knowledge. >From this perspective, unlike some other reviewers, I am not concerned at all if parts of FC++ ultimately end up duplicating some functionality found in other boost libraries. Since none of them have the aim of providing a platform for functional programming in C++, it would not be surpirsing to find out that existing components with a functional flavor are unsuitable for use by FC++. I said 'ultimately', however, because I believe that if after making some of the recommended changes, such as support for reference parameters, it is found that some of the current FC++ components can be replaced with existing Boost components, they defintely should be. Similarly, if it is found that with these changes parts of FC++ contain the full functionality of other boost libraries, with similar or identical interfaces, the authors of those boost libraries should be contacted to see if they are willing to make their components FC++-compatible to avoid duplication. With these qualifications, I do not see duplication as a problem. For the same reasons I am also not worried if it cannot be demonstrated, at this moment, that FC++ is the best way to solve any particular C++ problem. I am confident that it will be useful in many ways, but even if it should ultimately turn out that FC++ is never the best tool, I think accepting FC++ into boost -- with the exploration of new programming techniques and the interaction between programmers with different backgrounds which it will bring about -- would still be worthwhile. 2. Naming. A) Many of the public types and functions have obscure names. (There are also problems with the internal names, which I'll discuss under 'implementation'.) I'm willing to accept using strange names if they are standard names from FP; however many of the FC++-specific names are needlessly obscure. For example, the templates c_fun_type, fun_type and the smart_functoidn family are all helper templates designed to add functionality to a derived class, along the lines of std::unary_function. But the names give no indication what they are supposed to do. I still have no idea what the 'c' stands for in c_fun_type. (I'll suggest in (5) below how to eliminate fun_type and smart_functoidn entirely, and replace c_fun_type with 'adaptable'; I'm just using these as examples.) 'fun' should defintely be 'functoid'. 'full' is almost meaningless; I'd suggest other names, but I think full should be eliminated (see (5)). B) There are many families of functions and classes which have numerals built in to their names, e.g., funn, fulln, monomorphizen, make_fulln. In almost all cases, it is possible to leave out the numeral, and let the compiler deduce the relevant information. In some cases, unifying these families is essential to making the maximum functoid arity configurable (See (3) below). In most of the other cases, the numerals should be eliminated because they make identifiers harder to read, make programmers do more work than necessary, and may leave the impression with some programmers that there could be subtle differences between the numbered versions other than arity. (In fact, 'if0', 'if1', and 'if2' use numerals in a way completely unrelated to arity, seeming to lend credibility to the suspicion that fun0, fun1 and fun2 might be fundamentally different types of entities.) Consistency with the rest of Boost virtually requires that these changes be made. We would never say make_tuple1, make_tuple2, for instance. In the rare case that the numeral cannot be eliminated (thunkn may be one of these cases, because of prefix currying), the integer should be made a template parameter, to signal that thunk<1>, thunk<2>, .. do in fact form a parameterized sequence of functions. C) Metafunctions should follow boost conventions. The return type should be called 'type'. Type traits returning integral values should be made models of MPL.Integral Constant. Type traits should be separated so that each template provides one piece of information, unless there is some special reason to group them. D) Object generators should follow a consistent naming convention. 'funify' and 'monomorphize' are cute, but with so many names to remember I'd prefer if the name of the object generator bore a consistent relation to the name of the type being generated. E) I don't expect much agreement on this last point, but I would like to express my opinion that since Boost is enirely devoted to C++, it makes no sense to have 'C++' in the name of a Boost library. Since FC++ is already well-known under its current name, I suggest that keeping FC++ indefintely as a sort of nickname, and that the Boostified version be known as Boost.Functoid. The namespace boost::functoid would also be easier to pronounce than boost::fcpp. The name FC++ could still be used in research papers, as long as it is mentioned somewhere that it is now officially Boost.Functoid. 3. Configurability. It is essential that FC++ be reimplemented so that the maximum arity is configurable. This is particularly important if FC++ is to be integrable into other C++ frameworks. For instance, I'd like to implement some logical formalisms using FC++ functoids as atomic predicates; for this I'd need arity well above 3. Making arity configurable can be done using the Boost Preprocessor library. In some cases it will be straightforward; in other cases -- for example with currying -- a new implementation will be required, more along the lines of the current lambda implementation (though it should use MPL). 4. Support for reference parameters. It is essential that FC++ funtoids be able to handle (non-const) reference parameters. Without this, a large part of the usefulness of FC++ with the STL and other frameworks is lost. This is unacceptable to me, since usefulness of FC++ with other C++ frameworks is my 2nd most important criterion. I am very encouraged that Brian seemed to discover a way to do this (message Thursday, February 19, 2004 3:03 PM). I'm not sure the solution generalizes well to higher arities. 5. Simplifications Several major simplifications should be made to the functoid part of the library. A) fun0, fun1, ... should be replaced by a single template 'functoid' able to handle multiple arities. I'd suggest using a function type as the template parameter, as in Boost.Function. I mentioned this already under naming, but it's more than a simple name change since it would require some reimplementation. B) Rather than having users define direct functoids, then wrapping them in full functoids when they want to take advantage of 'sugar', it should be made easy to define full funtoids, so that all function objects designed for use with FC++ can be expected to be full. (One still needs adapters for foreign function objects, of course.) I think this could be done with macros, e.g.: struct plus { // declare signature. BOOST_FCPP_LAMBDA_SUPPORT(2, plus) int operator() (int, int); }; I thought I remembered several reviewers suggesting this, but looking back, I don't see it. Brian's suggestion for allowing non-const reference parameters seems to require different overloads of operator() depending on which parameter types were declared to take non-const references. If this is true, more information might have to be passed to the macro to avoid an explosion of (mostly disabled) overloads. One could still keep 'full' as an implementation detail, of course. C) The technique for handling signatures of momomorphic and polymorphic funtoids can be unified. Currently polymorphic functoids declare their signatures using a nested sig template. Monomorphic functoids declare their signatures with a nested sig template taking dummy template arguments, together with typedefs first_argument_type, second_argument_type and third_argument_type. I suggest a single, unified system. Here is one way to do it: Let a functoid's signature be represented by a nested typedef 'signature' of function type. In the monomorphic case, the argument types and return type would be concrete types (int, string, functoid<int(long)>, etc.). For polymorphic functoids, the argument types would be formal placeholders; the return type would be an MPL metafunction class or lambda expression evaluating to the return type of the functoid when invoked with arguments having a given sequence of types. I may have made it sound complicated, but it's really simple. For instance, one might define a monomorphic functoid like so: struct plus { int signature(int, int); int operator() (int i, int j) const { return i + j; } }; A polymorphic functoid, which expects a unary funtoid argument plus a value of some other type, and returns the result of applying the given functoid to the given value, could be defined like so (see below for explanation): struct apply { result_type<_1, _2> signature(any, any); template<typename F, typename T> typename result_type<apply, F, T>::type operator() (F f, T t) const { return f(t); } }; Here: * result_type is a namespace-level metafunction taking a function pointer, member function pointer or function object type, together with a sequence of argument types, and returning the appropriate result type. It should be smart enough to handle the system I am describing, plus the various other return type deduction systems one wishes to support. * the symbols _1, _2 are MPL lambda placeholder symbols * the tag struct 'any' is a formal placeholder; I could have used _1, _2, ... here instead, but this would just make the metacomputation harder. (I realise 'any' is already used by the library. One could also use 'any_type'.) This technique also provides a way for polymorphic functoids to specify that they take certain arguments by reference or const reference, if that turns out to be necessary. E.g.: result_type<_1, _2> signature(const any&, any&); It also allows for the possibility of mixed monomorphic-polymorphic functoids (although I'm not recommending it): result_type<_2> signature(int, any); If one needs genuine variable length argument lists (other than just prefix currying), an ellipsis could be used. With this technique, or something similar, one can get rid of fun_type and smart_functoid, and replace c_fun_type with 'adaptable': template<typename Signature> struct adaptable { typedef Signature signature; }; struct plus : adaptable<int(int, int)>; I'll give two more examples. >From compose2.cpp: template <class I> struct sig : public fun_type<typename RT<F,I>::result_type> {}; and template <class F, class G> struct sig: public fun_type<AddHelper<F,G> > {}; would be rewritten typedef return_type<F, _1> signature(any); typedef AddHelper<_1, _2> signature(any, any); (This last example requires SFINAE, I believe, but Brian has said that's okay.) >From the main docs: template <class F, class L> struct sig { typedef list< typename F::template sig< typename L::value_type >::result_type > result_type; }; would be rewritten typedef list< result_type<_1, _2> > signature(any, any); (I should mention that this proposal could run into (solvable) problems if some of the 'concrete' types being manipulated are simultaneously metafunctions.) 6. Lambda Expressions and other sugar When I first saw the explicit lambda notation, I disliked it. However, after reading the material on monads and looking at the sample programs, I came to see why the various explicit variable binding constructs are useful. I doubt I will find much support on this point, but I would like to urge FC++ to support both an implicit lambda and an explicit lambda mechanism. It don't think it's quite as crazy as it sounds. The explicit and implicit versions could share the underlying machinery for managing lambda variables. Implicit lambda varibales would simply be instances of lambda_var<N> for certain reserved values of N. The library would provide instances of the reserved variable types. The machinery is already in place to determine whether an expression contains an implicit variable, if so, operator overloads could be enabled liberally as in Boost.Lambda. If not, operator overloads would be restricted to allow the let, letrec syntax, etc. You could tell immediately whether an expression was an implicit lambda expression or (part or) an explicit lambda expression: you would just look for the formal placeholder symbols _1, _2, ... . The reason I urge this is that FC++ with the implicit lambda syntax would then be the most natural framework for defining anonymous function objects for use with the STL (and probably with other frameworks), assuming that an easy way to make all functoids 'full' is provided. FC++ implicit lmabda expressions would be like MPL lambda expressions, which are remarkable in that they can be used with exactly the same syntax as the ordinary use of the expressions from which they are composed; you only need to substitute placeholders where concrete types occur. FC++ is so close to being able to provide this facility that it would be a shame if it didn't take the extra steps to do so. One of the most difficult parts, I think, would just be explaining that FC++ supports two types of lambda syntax. I think if the documentation is well done, this feature could be successful. I am worried by Joel de Guzman's observation that the infix notation could cause problems with operator precedence. Because I think that C++ programmers quickly learn to read prefix notation using parentheses, and because similarity with Haskell is low on my list of priorities, I would recommend dropping the infix notation. (I deliberately avoided discussing the question of parenthesis vs.square brackets here, and also the question of whether more operator overloading should be allowed with explicit lambda expressions.) 7. Implementation Some parts of the implementation are quite clever, for instance the treatment of lazy lists. A few parts are antique; at the moment I can think only of the currying, which would lead to a combinatorial explosion if generalized to handle higher arities. The implementation of lambda expressions (using techniques like the current Boost Tuple implementation) shows that the authors know more modern tecniques. Matt Marcus mentioned in his introduction that the lambda machinery should be rewritten to use MPL; I believe more of Boost could be used profitably in many places, esp. Type Traits, MPL, Preprocessor and static assert. (I can give more details after the review if there is interest.) Most of the implementation is acceptable, but often the code seems disorganized and inconsistent. A) There are no discernable naming conventions. Some identitifers are all uppercase, some are mixed case and some are lowercase with underscores. Personally I don't care if the private names follow different conventions from the Boost conventions for public names, but there must be some convention. B) A technique used throughout the library is for non-static member functions to delegate to static member functions of helper class templates to compensate for the lack of partial function template specialization. This is a reasonable tecnique (although I would usually prefer tag-dispatch), but it is applied inconsistently. Sometimes the helper classes are defined as nested classes, sometimes they are defined at namespace scope in the vicinity of the template being implemented, sometimes they are defined in a completely different header, with no explanation. The name of the helper template often gives some clue as to how it is going to be used, but sometimes not. For example, Curryable3Helper is defined in curry.hpp, but only used in full.hpp, to implement the template full3. Why not call it Full3Helper and define it in full.hpp? C) The code contains few comments, and many of the existing comments are completely useless. For instance, in pre_lambda.hpp, we have this comment: // TE is a type environment; a list of TEPair<i,T> <snip> // BE is a value environment; a list of BEPair<i,LE> Nothing in pre_lambda.hpp is named TE or BE. Later, in lambda.hpp, we have the following: // I seem to recall that // ET - Environment Thunk // BE - Binding Environment // TE - type Environment // Yes. See pre_lambda.hpp for a little more explanation. D) Some things are public which should be hidden. For instance, funny tag structures often occur in the interfaces of public member functions. list and odd_list both have public constructors which take a single argument of type 'a_unique_type_for_nil'. odd_list has a second public constuctor which takes this tag at the second argument position. I'm aware that tags are occassionally necessary for disambiguation, but do they really need to be public? If it's used only by the implementation it should be private. If users ever need these constructors, they should be replaced with clearly named object generators. All functoids which derive from the smart_functoidn family inherit members with names 'crazy_max_args' and 'crazy_accepts'. The comments explain that these identifiers are used so that 'user don't talk to functoids directly'. The proper C++ way to acheive this is to make these names private, and grant friendship to the traits templates which use them. I'm sure the reason for many of these problems is that the library was modified many times, the most pressing concern always being to make the library work rather than to make the implementation as a whole coherent. This is a familiar situation, and quite understandable. However, since software naturally tends to become more convoluted over time, the best way to keep Boost.FC++ from becoming completely inscrutable over the course of several years is to start with completely clean, well-organized code. I said at the beginning I would discuss the reuser implementation. This is not an example of poor design, by any means; it is just an example of one of mainy details which could benefit from discussion. reuser2 is declared as follows: template <class V1, class V2, class V3, class F, class X, class Y> struct reuser2; Each of the first three arguments is expected to be one of the tag structs INV or VAR, indicating whether the the type at the corresponding position in the second half of the argument list is variant or invariant. This decouples the type being classified -- Y, for instance -- from the type providing the classification -- V3, in this case. It would make more sense to me to do something like this: template<typename T> struct inv { typedef T type; }; template<typename T> struct is_invariant { /* omitted */ }; template <class F, class X, class Y> struct reuser2; Now, instead of writing reuser2<VAR, INV, VAR, T, U, V>, you write reuser2<T, inv<U>, V>. This looks easier to use, understand, and generalize. You might even be able to drop the '2'. 9. Testing. There needs to be a comprehensive set of tests, preferably using Boost.Test, which makes it easy to tell which FC++ features work on a given platform. Many of the fcpp_client programs were instructive, but some seemed not to use FC++ at all, and for some it was unclear what the expected output was supposed to be. The fcpp_clients need to be separated into examples (in an 'example' directory -- preferably with discussions of the important examples in the documentation), and reqression tests (in a 'test' directory). I hope my negative comments do not obscure my overall positive view of this library. Jonathan

7 11

[boost]Re: Re: serialization library #17
by Robert Ramey 02 Mar '04

02 Mar '04

Neal Becker wrote: >I had a couple of problems to build with boost_1_31_0 and gcc-3.3.3: >gcc-C++-action >../../../bin/boost/libs/serialization/build/libboost_serialization.a/gcc/de bug/runtime-link-static/threading-multi/basic_iserializer.o >../../../libs/serialization/src/basic_iserializer.cpp:32: error: prototype I don't find a file named basic_iserializer.cpp in my system. Nor do I find such a file in the serialization17.zip file. I did however such a name in the jamfile.v2 - which I will remove. I just rebuilt the library with my GCC 3.2 cygwin system - note this system doesn't include wide char i/o so I can't build the corresponding part on my setup. Here is my setup: $ gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/specs Configured with: /GCC/gcc-3.3.1-3/configure --with-gcc --with-gnu-ld --with gnu- as --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexe cdir=/usr/sbin --mandir=/usr/share/man --infodir=/usr/share/info --enable-langua ges=c,ada,c++,f77,pascal,java,objc --enable-libgcj --enable-threads=posix --with -system-zlib --enable-nls --without-included-gettext --enable-interpreter --enab le-sjlj-exceptions --disable-version-specific-runtime-libs --enable-shared --dis able-win32-registry --enable-java-gc=boehm --disable-hash-synchronization --verb ose --target=i686-pc-cygwin --host=i686-pc-cygwin --build=i686-pc-cygwin Thread model: posix gcc version 3.3.1 (cygming special) Robert Ramey

1 0

[rational] why is int_type private?
by Jody Hagins 02 Mar '04

02 Mar '04

Converting to/from boost::rational I have occasion to need the underlying integer type. Why is this typedef private, and not accessible to users? I looked through the archives, but can only find a similar question from Jonathan Turkanis, with n reply. Thanks!

3 5

Re: [boost] FC++ review
by Dave Gomboc 02 Mar '04

02 Mar '04

> > A list type is already present in ::std, and means something > > different. Perhaps lazy_list, or (cringe) llist. > > Disagree. MPL has list and vector. I'd hate to see it named > it differently. mpl::slist (static-list)? Yuck! Hmm. To what extent does MPL get away with that because of the compile-time vs. run-time distinction? Incidentally, slist is taken already (SGI's singly-linked list) -- evidence that lazy_list is better than llist. ;-) I guess I was thinking that if a lazy list ever made it into the standard library, it would need a different name than list anyway. Anyway, I'll cut this short -- can't spend all my time in the bicycle shed. Dave

1 0

RE: [boost] Re: Questions about the new license
by Beman Dawes 02 Mar '04

02 Mar '04

At 05:22 PM 2/10/2004, Powell, Gary wrote: >Beman, > You can add my name to the page which lists those who agree to the new >license and can have any of their previously submitted source code modified >to use it. Done. Thanks. --Beman

1 0

RE: [boost] FC++ review
by Powell, Gary 02 Mar '04

02 Mar '04

I looked at FC++ a long time ago when I first started working on Lambda, (known as ET then), and I thought that the FC++ approach was cool but not what I needed. I guess that's still my opinion. Of course I'm really really biased as an author of Lambda. While the documentation of FC does appear to need work from all the comments from those who are using it, I think that FC should become part of boost conditional to the improvements recommended. To tell the truth, I haven't been able to make time to run the examples and it bugs me that others weren't able to. I know that when I first looked at FC++ it all worked using gcc 2.93. And I think that there is room in boost for a couple of these Expression Template languages. I think FC++ fills a different need than Lambda does and whether or not current compilers generate more efficient code, than hand coding it, isn't really the issue for me. Boost acceptance hasn't been a guarantee of code speed but one of quality of implementation, i.e. bug free and portable. When I first started work on Lambda, it was extremely difficult to get better code than hand coding on most compilers. I did read the docs, and they do make sense to me, but then I've messed with expression templates for a long time. I did look at the code and its not as clean as it once was but then when we boostifed Lambda it lost some of its cleanness too. The biggest benefit to these language/libraries, is they highlight, via a prototype, what are the problems with the core language. They allow us to play with some whatif's that otherwise would take modifications to gcc. I think its pretty clear that some sort of anonymous functions are needed in C0X++. But until they are designed and voted on and implemented, we are left with FC++ and BLL++ and FACT!. It's also clear that Variable length template arguments are needed to reduce the code bloat. And that a reference saving "typeof" is essential. So if the above ramble is in-coherent. I vote accept FC++, with the caveat that monads are out until the docs are finished and that the rest of the docs improved up. Yours, -Gary-

1 0

RE: [boost] serialization library #17
by Rozental, Gennadiy 01 Mar '04

01 Mar '04

> I would like this library to be placed in the review queue. You probably want to send separate formal request with proper subject (see recent post on procedure). Gennadiy.

1 0

boost::ublas and solver
by Loïc Joly 01 Mar '04

01 Mar '04

Dear boosters, I was recently trying to convince one of my colleagues that a vector (mathematical, not stl) and matrix library instead of raw C arrays could be usefull for his job. I naturally turned toward boost::ublas, but then I had one surprise: One thing I expected to find in such a library was a collection of solvers (LU, gaussian elimination...), but I found none. Is this because they exist, but I could not find them in the documentation (btw, I have some trouble to understand the doc, too much code, not enough english to my taste) ? Is is because there was a good design decision not to include them ? Is it because this is a very touchy domain and poeple could not agree on generic solutions ? Is is just an oversight ? -- Loïc

1 0

RE: [boost] Re: boost::any: explicit constructor?
by Glen Knowles 01 Mar '04

01 Mar '04

>I guess I don't understand the whole concept now. T* -> void* sounds >like "narrowing", since it loses information. int -> long never loses >information, so "widening" makes sense to me. What is the criterion? This is why I like C++'s choice of base and derived, there's never any confusion. You have the concepts of narrowing and widening correct but backwards. You narrow a type to a more specific derived type and widen one to a more general base type. Glen

3 4

Re: The art of naming namespaces [was: Re: algorithms namespace]
by Bjorn.Karlsson＠readsoft.com 01 Mar '04

01 Mar '04

> From: Thorsten Ottosen [mailto:nesotto@cs.auc.dk] > > I'd say that for boost::filesystem, Dave's suggestion > "files" would be a > > great compromise. > > Why plural? We seldom name class in plural. Good question, and I'm not really sure I can answer it very well (but I'll try): * It can be mentally expanded to files...ystem. * Some names work "best" in plural (like signals, type_traits, iterators, operators); this is of course very much IMHO. * Just "file" seems a bit restrictive to me, but when I think about the namespace "files" I read "files 'n other related stuff, too". (Come to think about it, that Boost.Thread uses the singular form is actually quite funny!) As this is a highly subjective matter, I don't consider these arguments/reasons to be anything else than personal opinions. Bjorn

7 16

Math constants - update & files removed
by Paul A Bristow 01 Mar '04

01 Mar '04

As requested by Beman, I have purged all my math constants proposals, except the latest version, from the files section. I have also updated the copyright notices on the macro (36 decimal digit) constants values, and posted these zipped. Until we can agree a better method of presenting math constants, these may save users surfing the net for individual values. (Since some people seem to find the files section inaccessible, should they be copied to the CVS sandbox too?) Since the two files (to #define and #undef) are quite short, they are also attached for your convenience. Please tell me of any mistakes you find. Paul PS If anyone has any suggestions on solving the presentation problem please say so. Daniel Frey seems close to a portable solution, but "a miss is a good as a mile" :-( Type deduction seems the nub of the problem: can anything from FC++ help? Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow(a)hetp.u-net.com

4 4

algorithms namespace
by Pavol Droba 01 Mar '04

01 Mar '04

Hi, During the review of the string algorithm library, an issue was raised about the namespaces for algorithmic libraries in the boost. The issue has not been sufficiently resolved, and I would like to bring it up to the discussion again. Current proposal looks like this: boost - algorithm - common algorithm related stuff - string - string algorithms - container - container algorithm etc. Although this seems clear enough, there are some open questions. 1.) Namespace path is quite long. It is not really reasonable to await from a user to always type boost::algorithm::string::trim. "using namespace" directive is not always a viable solution. And even if it would be, a user would have to specify several of them to use whole algorithm library (what could not so uncommon, in my opinion) Namespace aliasing is one of possible solutions, but again, one would have to alias every algorithm sub namespace. 2.) It is not clear if what should go into boost::algorithm namespace and what to more specific ones (like boost::algorithm::string). This is specificaly an issue of algorithms, that logicaly belong to various categories. An example would be "all" algorithm. It is generic enough to not be contained in the string library. But on the other hand, together with classification predicate, it is essencial for the string processing. Should it go to algorithm::string, algorithm::container, plain algorithm or somewhere else? Suggestions: 1.) One possibility would be to relieve the idea of algorithm subnamespace and put everything into boost::algorithm namespace. Benefit would be simplier namespace specification and less suprises about where is a particular algorithm. Disadvantage can be a possibility of nameclashes and poluted namespace. 2.) Another option would be to use subnamespaces, but to propagate user-level interface names to boost::algorithm using "using" directive. In this alternative, there is still an open question (2). (i.e. to define more precisely the policy for putting algorithms/classes into namespaces) 3.) Let everything in subnamespaces and identifying the problem(1) as irelevant. 4.) Some other idea, I don't know yet about. Your ideas/optinions are welcome. Regards, Pavol

17 41

shared_ptr: policy for usage_count lock
by Slawomir Lisznianski 01 Mar '04

01 Mar '04

I apologize if my observation has already been discussed and course agreed. When using Boost with multi-threaded programs, shared_ptr synchronizes access to internal usage count variable. I understand the rationale for guarding the shared resource as default behavior in MT environment, however I think users might appreciate the ability to override it. Currently, users either ignore, or are unaware of, performance cost imposed by locking, or choose, with all it's implications, an option of using non-owning observer of an object owned by shared_ptr. During tests involving manipulations of shared_ptr variables similar to those performed by algorithms on container elements – their copying and removal – a significant overhead was measured. During tests, care was taken to assure that timing did not include creation of new objects managed by shared_ptrs nor their destruction. One way to customize the shared_ptr without breaking existing code would be to introduce an optional template parameter stating locking policy. Attached you will find test code used on a win32 platform that produced the following results on Intel Pentium 4 2.66Mhz single processor machine. Each line represents separate testing iteration, so averages can be calculated: BOOST_HAS_THREADS is: TRUE Elapsed time: 845605 microseconds Elapsed time: 817763 microseconds Elapsed time: 802840 microseconds Elapsed time: 790676 microseconds Elapsed time: 790839 microseconds Elapsed time: 793012 microseconds Elapsed time: 790474 microseconds Elapsed time: 788396 microseconds Elapsed time: 794611 microseconds Elapsed time: 792640 microseconds Press any key BOOST_HAS_THREADS is: FALSE Elapsed time: 87914 microseconds Elapsed time: 87753 microseconds Elapsed time: 88958 microseconds Elapsed time: 86546 microseconds Elapsed time: 86437 microseconds Elapsed time: 86520 microseconds Elapsed time: 86433 microseconds Elapsed time: 88519 microseconds Elapsed time: 86420 microseconds Elapsed time: 87535 microseconds Press any key The time overhead mentioned above is meant to serve as an example from a particular win32 platform. Results will vary across platforms and hardware configurations. Regards, Slawomir Lisznianski; [ www.rhapsodia.org ] /* * Copyright (C) 2003-2004 * Slawomir Lisznianski <slisznianski(a)asyncnet.com> * * Permission to use, copy, modify, distribute and sell this software * and its documentation for any purpose is hereby granted without fee, * provided that the above copyright notice appear in all copies and * that both that copyright notice and this permission notice appear * in supporting documentation. Slawomir Lisznianski makes no * representations about the suitability of this software for any * purpose. It is provided "as is" without express or implied warranty. * */ #include <string> #include <iostream> #include <stdexcept> #include <boost/shared_ptr.hpp> #include <Windows.h> // VC++ 6 library doesn't define it. // std::ostream& operator<<(std::ostream& os, __int64 i ) { char buf[20]; sprintf(buf,"%I64d", i ); os << buf; return os; } struct Timer { Timer(std::ostream& out) : _M_out(out) { if (!::QueryPerformanceFrequency(&_M_frequency)) throw std::runtime_error("Unable to retrieve frequency of the high-resolution performance counter."); if (!::QueryPerformanceCounter(&_M_startEvent)) throw std::runtime_error("Unable to retrieve value of the high-resolution performance counter."); } ~Timer() { if (!::QueryPerformanceCounter(&_M_endEvent)) _M_out << "Unable to retrieve value of the high-resolution performance counter."; else { LONGLONG elapsedTicks__ = _M_endEvent.QuadPart - _M_startEvent.QuadPart; double elapsedTime__ = 0; _M_out << "Elapsed time: "; if (_M_frequency.QuadPart > 1000000) { elapsedTime__ = (elapsedTicks__ / (_M_frequency.QuadPart / 1000000)); _M_out << elapsedTime__ << " microseconds" << std::endl; } else if (_M_frequency.QuadPart > 1000) { elapsedTime__ = (elapsedTicks__ / (_M_frequency.QuadPart / 1000)); _M_out << elapsedTime__ << " miliseconds" << std::endl; } else { _M_out << elapsedTicks__ << " ticks (tick: 1/" << _M_frequency.QuadPart << " of second)" << std::endl; } } } std::ostream& _M_out; LARGE_INTEGER _M_startEvent; LARGE_INTEGER _M_endEvent; LARGE_INTEGER _M_frequency; }; void run() { boost::shared_ptr<int> ptrA__(new int(0)), ptrB__, ptrC__; Timer timer__(std::cout); for (int i=0; i<4000000; ++i) { ptrB__ = ptrA__; ptrC__ = ptrB__; } } int main(int, char**) { try{ std::cout << "BOOST_HAS_THREADS is: "; #if !defined(BOOST_HAS_THREADS) std::cout << "FALSE" << std::endl; #else std::cout << "TRUE" << std::endl; #endif for (int i=0; i<10; ++i) run(); } catch (std::exception& e) { std::cerr << e.what() << std::endl; } return 0; }

4 4

smart_ptr: missing documentation link
by Slawomir Lisznianski 01 Mar '04

01 Mar '04

Browser: Mozilla 1.6 When trying to access documentation for smart_ptr I'm getting: Not Found The requested URL /libs/smart_ptr/index.htm was not found on this server. Apache/1.3.26 Server at www.boost.org Port 80 The link came from (referring page): http://www.boost.org/libs/libraries.htm Target page: http://www.boost.org/libs/smart_ptr/index.htm Note: Problem occurs on IE as well, but after a very brief moment, browser redirects to http://www.boost.org/libs/smart_ptr/smart_ptr.htm where page is found. Regards, Slawomir Lisznianski; [ www.rhapsodia.org ]

2 1

mistake in "libs/libraries.htm"
by Li Lirong 01 Mar '04

01 Mar '04

"quaterion" should be "quaternion". Regards, Lirong

2 1

shared_array: how to get the number of elements in it?
by Roland Richter 01 Mar '04

01 Mar '04

Boosters, I want to write a function which compares two shared_array's element-wise (operator==() compares for pointer equality). How to get the number of elements a given shared_array contains? At first glance there seems to be no possibility; am I missing something? - Roland

2 1

RE: [boost] Re: algorithms namespace
by Powell, Gary 01 Mar '04

01 Mar '04

I'm siding with Dave A and the longer names. You can always shorten it in your code with an alias. For me it's a matter of future expansion, and maintenance, we have boost::bind, and boost::lambda::bind, and perhaps soon boost:fcpp::lambda which is the namespace which the function? If we use apprev. 4 everythg, thn, we lose contx. boost::fs =? "FileSystem", "FastSort", "FirstSearch", "FloatingSymbols".... yes these are a bit contrived but you can usually use "using namespace", or a namespace alias safely within a function scope. Then when you leave the company the next poor maintainer of your code has a chance. Also a global search is easier if the letters to be searched for are more or less a unique set. Yours, -Gary- -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Monday, February 23, 2004 11:44 AM To: Boost mailing list Subject: Re: [boost] Re: algorithms namespace At 03:28 PM 2/18/2004, Peter Dimov wrote: >> I think it's a fuzzy line in the sand, so all I really know is that I do >> like "ref" and don't like "fs" :) > >Yes, is seems that it comes down to personal preference. Dave likes to say >filesystem, and you don't like fs... I never liked either. "filesystem" is too long and sounds affected. "fs" is too short and non-specific. Those names just escaped because nothing better surfaced. Maybe if the LWG likes the library enough to standardize it we can come up with a better name. --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

9 15

Solution to Windows' min/max problem?
by Daryle Walker 01 Mar '04

01 Mar '04

I learned some new stuff from another post about the min/max macros given in the Windows headers. Can the following suppositions and solution work? 1. The MS Windows headers define "min" and "max" macros 2. But nothing in those headers _actually needs_ those macros 3. These macros prevent STL from working 4. A "NOMINMAX" #define can be created to turn off the macros 5. Using the #define will fix STL _without_ breaking the MS stuff 6. The #define would break user code that uses the macros, though 7. If an user with that breakage includes STL, they have an alternate "min" and "max" available! 8. Boost pretty much requires STL So why can't we add: #if defined(min) || defined(max) #error Define NOMINMAX and use the alternates in <algorithm> #endif -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 2

[config] [patch] Fix support for OpenBSD
by larsbj＠gullik.net 01 Mar '04

01 Mar '04

We just got a mail from a LyX user telling us that this patch is needed to compile on OpenBSD. Would be nice if this could be included in Boost (and in 1.31.1 when that is released.) TIA. --- boost/boost/config/platform/bsd.hpp.orig 2002-05-21 19:39:55.000000000 -0400 +++ boost/boost/config/platform/bsd.hpp 2004-02-22 02:24:05.000000000 -0500 @@ -44,7 +44,9 @@ // // The BSD <ctype.h> has macros only, no functions: // -#define BOOST_NO_CTYPE_FUNCTIONS +#if !defined(__OpenBSD__) +# define BOOST_NO_CTYPE_FUNCTIONS +#endif -- Lgb

2 2

[Boost-bugs] [ boost-Bugs-907299 ] Miss " = ParserT()"
by SourceForge.net 01 Mar '04

01 Mar '04

Bugs item #907299, was opened at 2004-02-29 21:54 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=907299&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Miss " = ParserT()" Initial Comment: \boost\spirit\core\scanner\skipper.hpp 101 skip_parser_iteration_policy( 102 ParserT const& skip_parser, 103 base_t const& base = base_t()) 104 : base_t(base), subject(skip_parser) {} "no_node_d" can't be used. Fixed: 101 skip_parser_iteration_policy( 102 ParserT const& skip_parser = ParserT(), 103 base_t const& base = base_t()) 104 : base_t(base), subject(skip_parser) {} All right! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=907299&group_i… ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Boost-bugs] [ boost-Bugs-907276 ] ha ha very funy........idiots!
by SourceForge.net 01 Mar '04

01 Mar '04

Bugs item #907276, was opened at 2004-02-29 20:25 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=907276&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ha ha very funy........idiots! Initial Comment: you have a neat site, but it says you are not authorized to view this file. very amusing...corporation...bast...idiots! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=907276&group_i… ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Date_time currently broken with Borland and cygwin?
by John Maddock 01 Mar '04

01 Mar '04

Title says it all, see http://boost.sourceforge.net/regression-logs/cs-win32.html Thanks, John.

2 1

FC++ Formal review is now in progress (2/13-2/23)
by Mat Marcus 01 Mar '04

01 Mar '04

The formal review of fcpp by Brian McNamara and Yannis Smaragdakis is now in progress, runiing from Friday February 13th at 12 noon, PST and and run to Monday, February 23rd, 12 noon PST. The library is currently available at <http://www.cc.gatech.edu/~yannis/fc++/boostpaper/> Here is a brief introduction to the library: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order polymorphic functions, currying, lazy evaluation, and lambda. In addition to the framework, FC++ also provides a large library of useful functions and data types. The main utility of the library comes from its ability to implement functional programming designs, especially those which use higher-order polymorphic functions or lazy evaluation in significant ways. The library also contains a number of ancillary components that implement features like currying and lambda for function objects; these features are also useful in their own right. For information about submitting a Formal Review, see <http://www.boost.org/more/formal_review_process.htm> Please try out the library and read the documentation and say whether or not you think the library should be accepted by Boost and why. Compiler notes: This library has been tested with icc7 and with gcc-3.1.1 (and various other gcc-3.x.y versions) on Solaris and Linux. The library is also likely to compile on VC++7.1 and Comeau (prior versions of the library succeeded with these compilers, but this particular snapshot has not been tested with them). The library covers a great deal of the C++ language and thus requires a high degree of standard conformance; compilers like gcc-2.95.x and VC++6 will not be able to compile the library. Getting started: The web page http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ mentions all the basics: The zip file will expand into these subdirectories: fcpp/fcpp/ # the library (.hpp) files fcpp/fcpp_clients/ # the example (.cpp) files Running the examples just involves invoking the complier with the right #include paths; for example, # in the fcpp_clients directory g++ -I/path/to/boost -I../fcpp some_example.cpp There is also a gnu-style Makefile included with the clients (examples), which will compile all of the examples in batch (you will have to edit a tiny bit at the top of the Makefile). The examples in the clients directory are a mix of both (regression-type) tests cases which cover the features of the library and example applications which demonstrate some of the library's utility. The README file in the client directory gives a short explanation of some of the more interesting clients. The documentation at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ provides a walkthrough and reference for most of the main features of the library. There are also some pointers out to other papers and documentation on the main FC++ web site: http://www.cc.gatech.edu/~yannis/fc++/ Conformance to Boost guidelines: The library meets most of the requirements described at http://www.boost.org/more/lib_guide.htm Here are a few notable exceptions: - the current library headers are too "monolithic"; you #include "prelude.hpp" and suck in all of the library - some of the lambda internals should be rewritten to use MPL rather than hand-rolled metaprogramming code - only a few of the example programs utilize the Boost testing framework (to automate regression testing) Should the library be accepted into Boost, Brian will remedy these deficiencies. (If you notice other major problems along these lines, please bring them to Brian's attention during the review.) The Formal Review manager is Mat Marcus.

25 138

Proxy --- an indirect container adaptor
by Christian Engström 29 Feb '04

29 Feb '04

Is the following design valid, and if so, would it make a useful addition to the Boost library? I enclose a draft implementation, and look forward to any comments. /Christian - - - It can quite often be of interest to convert a program that uses a direct container into using an indirect container of smart pointers to the objects instead, either just temporarily to see what happens to performance, or permanently if it turns out to be beneficial. Unfortunately, this normally means that the program has to be modified in many different places, even for programs that are not affected as such by the slightly different semantics that indirect containers have. The proxy indirect container header file makes it possible to switch between direct and indirect containers by changing a single typedef in any such program. For example, the following test program was modified to use an indirect vector instead of a direct one by just changing the type declaration from std::vector<person> to proxy_vector<person>::self. //=================================================================== #include <boost/operators.hpp> #include "proxy.hpp" int calls_to_copy_constructor = 0; //=================================================================== class person : boost::totally_ordered<person> //------------------------------------------------------------------- { public: string name; int age; person() {} person(const string& in_name, int in_age); person(const person& other) : name(other.name), age(other.age) { ++calls_to_copy_constructor; } // Compares first name, then age friend bool operator== (const person& a, const person& b); friend bool operator< (const person& a, const person& b); bool read(istream& in_file); }; ostream& operator<< (ostream& out_file, const person& x); //=================================================================== int main (int argc, char* argv[]) //------------------------------------------------------------------- { person a_person; person someone_special("Alice", 27); ifstream in_file("test_proxy.in"); // typedef std::vector<person> buf_type; // <---- typedef proxy_vector<person>::self buf_type; // <---- buf_type buf(5, person("Undefined", -1)); buf.front() = person("First", 1); *(buf.begin() + 1) = person("Second", 2); buf[2] = person("Third", 3); (buf.begin() + 3)->name = "Incomplete"; while (a_person.read(in_file)) { buf.push_back(a_person); } std::sort(buf.begin(), buf.end()); for (buf_type::iterator it = buf.begin(); it != buf.end(); ++it) { cout << *it; if (it->age < 0) cout << " Not a proper age"; if (*it == someone_special) cout << " Someone special"; if (it != buf.begin() && (*it == *(it – 1))) cout << " Duplicate record"; cout << endl; } buf_type::iterator end_it = std::unique(buf.begin(), buf.end()); cout << "\nNumber of unique records: " << (end_it - buf.begin()); cout << "\n\nCalls to 'person's copy constructor: " << calls_to_copy_constructor << endl; return 0; } //=================================================================== So how does this work? First of all, the declaration proxy_vector<T>::self is short for proxy_container< std::vector< proxy<T> > > There are convenience templates like this for the basic container types in STL, but by using the general form the proxy container adaptor can be used on any container that has an STL compliant interface. Class proxy At the very center of the design is the proxy template class. A proxy<T> object is a smart pointer that has a boost::shared_ptr<T> as its only data member. It constructs, assigns, and takes responsibility for deleting the object in the same way as a shared_ptr. It does not support any pointer arithmetic, however, so the ++ and -- operators are undefined. Without pointer arithmetic, there is very little use for the comparison operators as they are defined for shared_ptr, so these are instead given the semantics of element_compare, which means that they compare the two objects as such rather than the pointers. (There is a conversion function to shared_ptr that can be used to test the pointers as such if necessary.) With these definitions, we can use the STL algorithms directly on any Container< proxy<T> >, and they will produce the same results as they would for a Container<T>. This applies both to algorithms like std::sort, which depends on the < operator for comparisons, and algorithms like unique, which relies on the == operator. The proxy class also contains an implicit conversion operator from proxy<T> to T&. This means that we can use a proxy<T> as the actual parameter to any function that expects a T for input or output, or, to put it another way, that the proxy is automatically “cashed in” for a T object as soon as this is required. In particular, this means that we can copy T objects from a Container< proxy<T> > into T variables, in exactly the same way as if it had been a Container<T>, since the proxy<T> object that the iterator delivers will be automatically converted to a T if it is assigned to a T variable. If we assign it to a proxy<T> variable, it will of course remain a proxy. To handle assignments to proxy variables, the default assignment operator is supplemented by operator=(const T&). This operator will create a proxy that points at a new copy of the T object, and assign it to the left hand variable. This means that we now have a Container< proxy<T> > that behaves like a Container<T> for comparisons, and when we retrieve whole objects from the container. Class proxy_iterator To get operator-> working in the same way as for a Container<T>, we define the classes proxy_iterator and const_proxy_iterator. A proxy_iterator is publicly derived from the iterator of the underlying Container< proxy<T> >. It works just like standard iterator in all respects except one, which is that operator-> does a double dereferencing, so that it will deliver a pointer to the T object itself. This lets us use the -> operator in the same way that we would with a direct container. operator* is not changed, however, and retains its single dereferencing semantics. Are we really allowed to define these operators like this? --Yes, we are. While it is true that this means that the semantics will be different for (*x).y and x->y, this does not affect the STL algorithms in any way, since they don’t make any use of the -> operator. (How could they, when they’re supposed to work on the built-in types as well?) The proxy iterators can be mixed freely with the underlying standard iterators, since the derived-to-base-class conversion will convert in one direction, and the proxy iterators have have a conversion constructor that converts in the other direction. Since the compiler will prefer a derived-to-base conversion over a user-defined conversion, the ambiguity problems that are normally associated with having two types that can be implicitly converted in both directions are eliminated. Class proxy_container The class proxy_container, finally, inherits from the underlying Container< proxy<T> > and overrides the definitions for iterator and const_iterator so that the proxy iterators are used instead. It also redefines the standard container member functions that return an iterator so that they return the appropriate proxy iterator. In order to be able to insert T objects directly into the proxy container, the class proxy_container also redefines all members that insert an object into the container so that there are two versions of each function: one that takes a proxy<T> as input and inserts a new proxy that points at the same object, and one that takes a T object and inserts a proxy that points at a newly created copy of the object. Taken together, these classes let us emulate the interface of a Container<T> with something that is actually an indirect container. Since it is only a single type declaration that has to be changed to switch between direct and indirect containers, it becomes practical to do this for testing purposes. The indirect containers still retain the full interface of a traditional container of smart pointers, so the additional capabilities of an indirect container are available in the usual way. - - - I have uploaded the full source code for the draft implementation, as well as and the test program shown here, to the files section at Yahoo, and I have tested it with MSVC6 and gcc 3.3 on Windows XP. For MSVC6 there is the problem that the implementation of std::vector::iterator is just a plain pointer and not a standards compliant iterator, so proxy_vector uses a deque rather than a vector as a workaround. File proxy.hpp: (slightly abridged) //================================================================== // 20-feb-2004 Christian Engström (christian.engstrom(a)glindra.org) //------------------------------------------------------------------ #include <vector> #include <deque> #include <list> #include <boost/smart_ptr.hpp> //================================================================== // 'proxy' //------------------------------------------------------------------ template <class T> class proxy { private: typedef proxy<T> self; boost::shared_ptr<T> m_sp; public: // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Types typedef T element_type; // "Inherited" from 'boost::shared_ptr' typedef T value_type; // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Constructors proxy() {} template<class Y> proxy(const proxy<Y>& other) : m_sp(other.as_shared_ptr()) {} template<class Y> explicit proxy(const boost::shared_ptr<Y>& other) : m_sp(other) {} template<class Y> explicit proxy(const boost::weak_ptr<Y>& other) : m_sp(other) {} template<class Y> explicit proxy(std::auto_ptr<Y>& other) : m_sp(other) {} template<class Y> explicit proxy(Y* other) : m_sp(other) {} // Assignment self& operator=(const self& other) {m_sp = other.m_sp; return *this;} self& operator=(const T& other) {*this = proxy<T>(new T(other)); return *this;} // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Conversions operator T&() const {return **this;} // Implicit conversion to T bool is_null() const {return !m_sp;} boost::shared_ptr<T>& as_shared_ptr() {return m_sp;} const boost::shared_ptr<T>& as_shared_ptr() const {return m_sp;} // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Comparisons are made on the value, never the pointer. bool operator== (const self& other) const {return **this == *other;} bool operator!= (const self& other) const {return **this != *other;} bool operator< (const self& other) const {return **this < *other;} bool operator> (const self& other) const {return **this > *other;} bool operator<= (const self& other) const {return **this <= *other;} bool operator>= (const self& other) const {return **this >= *other;} // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Dereferencing T& operator*() const {return *m_sp;} T* operator->() const {return m_sp.get();} T* get() const {return m_sp.get();} T* as_ptr() const {return m_sp.get();} }; //================================================================== // 'proxy_iterator' //------------------------------------------------------------------ template <class MutableBaseIterator> class proxy_iterator : public MutableBaseIterator { private: typedef proxy_iterator<MutableBaseIterator> self; typedef MutableBaseIterator base; typedef typename base::value_type::element_type T; public: // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Types typedef typename base::difference_type difference_type; // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Constructors proxy_iterator() {} proxy_iterator(const MutableBaseIterator& it) : base(it) {} // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Standard operators for iterators T* operator-> () {return (**this).get();} // Indirect self& operator++ () {base::operator++ (); return *this;} self& operator-- () {base::operator-- (); return *this;} self operator++ (int) {return base::operator++ (0);} self operator-- (int) {return base::operator-- (0);} self& operator+= (difference_type n) {base::operator+= (n); return *this;} self& operator-= (difference_type n) {base::operator-= (n); return *this;} self operator+ (difference_type n) const {return base::operator+ (n);} self operator- (difference_type n) const {return base::operator- (n);} friend self operator+ (difference_type n, self x) {return x + n;} friend difference_type operator- (self x, self y) {return base(x) - base(y);} }; //================================================================== // 'const_proxy_iterator' //------------------------------------------------------------------ { // Analagous to proxy_iterator, and with a conversion constructor from proxy_iterator. ... }; //================================================================== // 'proxy_container' //------------------------------------------------------------------ template <class BaseProxyContainer> class proxy_container : public BaseProxyContainer { private: typedef proxy_container self; typedef BaseProxyContainer base; typedef typename BaseProxyContainer::value_type value_type; typedef typename BaseProxyContainer::value_type::element_type T; public: // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Constructors proxy_container() {} proxy_container(const base& c) : base(c) {} template <class InputIterator> proxy_container(InputIterator first, InputIterator last) : base(first, last) {} explicit proxy_container(typename base::size_type n, const value_type& x = value_type()) : base(n, x) {} proxy_container(typename base::size_type n, const T& x) { for (typename base::size_type i = 0; i < n; ++i) { push_back(proxy<T>(new T(x))); } } // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Iterators redefined typedef proxy_iterator<typename base::iterator> iterator; typedef const_proxy_iterator<typename base::iterator, typename base::const_iterator> const_iterator; typedef std::reverse_iterator<iterator> reverse_iterator; typedef std::reverse_iterator<const_iterator> const_reverse_iterator; // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Container members that either return an iterator or take a value_type parameter (or both) iterator begin() {return base::begin();} const_iterator begin() const {return base::begin();} iterator end() {return base::end();} const_iterator end() const {return base::end();} reverse_iterator rbegin() {return base::rbegin();} const_reverse_iterator rbegin() const {return base::rbegin();} reverse_iterator rend() {return base::rend();} const_reverse_iterator rend() const {return base::rend();} void push_front(const value_type& x) {base::push_front(x);} void push_front(const T& x) {base::push_front(proxy<T>(new T(x)));} void push_back(const value_type& x) {base::push_back(x);} void push_back(const T& x) {base::push_back(proxy<T>(new T(x)));} iterator insert(iterator position, const value_type& x) {return base::insert(x);} iterator insert(iterator position, const T& x) {return base::insert(position, proxy<T>(new T(x)));} void insert(iterator position, typename base::size_type n, const value_type& x) {base::insert(position, n, x);} void insert(iterator position, typename base::size_type n, const T& x) ; // Not yet implemented template<typename InputIterator> void insert(iterator position, InputIterator first, InputIterator last) {base::insert(position, first, last);} iterator erase(iterator position) {return base::erase(position);} iterator erase(iterator first, iterator last) {return base::erase(first, last);} void resize(typename base::size_type new_size, const value_type& x) {base::resize(new_size, x);} void resize(typename base::size_type new_size, const T& x) ; // Not yet implemented // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Special list operations void remove(const value_type& value) {base::remove(value);} void remove(const T& value); // Not yet implemented }; //================================================================== // The standard contaiers //------------------------------------------------------------------ template <class T> struct proxy_vector #if !defined(BOOST_MSVC_STD_ITERATOR) {typedef proxy_container< std::vector< proxy<T> > > self;}; #else {typedef proxy_container< std::deque< proxy<T> > > self;}; // MSVC workaround #endif template <class T> struct proxy_deque {typedef proxy_container< std::deque< proxy<T> > > self;}; template <class T> struct proxy_list {typedef proxy_container< std::list< proxy<T> > > self;}; // Associative containers are not yet implemented

3 4

Re: [boost] Re: Review schedule too slow?
by JOAQUIN LOPEZ MU?Z 29 Feb '04

29 Feb '04

----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> > cleared.(We > > need at least two reviews a month. The most we can have is > three, unless > we > > allow overlap and/or shorten the review time.) > > > circular_buffer review should start on March 5th. > indexed_set will follow likely although no date is set yet. > Regarding indexed_set review, any date following circular_buffer suits me fine, provided the review finishes before Apr 5th (holidays here in Spain.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

What happened to the minmax library?
by Jeff Garland 29 Feb '04

29 Feb '04

I've been updating the review results and I notice that minmax was accepted into boost in Oct 2002, but I can't find it in the 1.31 distribution. Did it just get dropped or is it hiding somewhere? Jeff

1 0

Review schedule too slow?
by Daryle Walker 29 Feb '04

29 Feb '04

With the backlog we currently have, the current one-review-a-month, and the rate of review submissions, we are going to have some reviews pushed into 2005. I think any wait over four months is unacceptable. We going to have to speed up the review schedule, at least until the backlog is cleared. (We need at least two reviews a month. The most we can have is three, unless we allow overlap and/or shorten the review time.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 2

[python] separating the "C++ exposing" part?
by Pavel Vozenilek 29 Feb '04

29 Feb '04

It was suggested some time ago by Daniel Wallin to refactor part of Boost.Python generating class description into separate library. The result could be reused by Luabind. Is such separation possible and technically feasible at all? It may find use to implement RTTI-like mechanism, e.g. for GUI toolkits. /Pavel

3 3

Intel 8.0 on Windows now passes all Boost regression tests
by Beman Dawes 29 Feb '04

29 Feb '04

A bug fix version of Intel 8.0 for Windows has been posted on their web site. This new version passes all Boost regression tests. See http://boost.sourceforge.net/regression-logs/ Congratulations to Intel, and thanks for fixing several bugs which were causing Boost tests to fail! --Beman

3 2

[administrative] Formal review procedure
by Thomas Witt 29 Feb '04

29 Feb '04

Hi, here is my next try at an improved formal review procedure. I did away with the additional mailing list. The outlined process tries to reduce the burden on all involved as far as possible. Procedure --------- * The author posts a prereview request to the list. Subject line must contain "[prereview request]". * The author posts review request to review wizard. Subject line must contain "[review request]" and the message should contain a link to the prereview request. The review request must be seconded by two boost members. To second a review request does not imply a positive review. A person who seconded a review request can act as a review manager. If nobody has volunteered so far the review wizard helps finding a review manager. * The review manager checks whether the library is suitable and ready for review. * The review manager sends a schedule request to the review wizard. The subject line must contain "[schedule request]". * The review wizard schedules the review. Reviews will be scheduled on a first come first serve basis, based on the schedule request. * The review manager announces the review. ... Comments? Questions? Thomas Boost Review Wizard

6 8

RE: [boost] boost::any: explicit constructor?
by Bjorn.Karlsson＠readsoft.com 29 Feb '04

29 Feb '04

> From: Vladimir Prus [mailto:ghost@cs.msu.su] > Hi, > I just had a couple of bugs caused by the fact that > constructor of boost::any > is not explicit. For example: > > void do_something(boost::any& v) { ... } > > class variable { > ///// > boost::any& value() {} > }; > > variable v; > do_something(v); > > The intention was to call do_somethin on 'v.value()' but > non-explicit ctor is > happy to accept 'variable', after which 'do_something' breaks. > > Anybody has an opinion? Is non-explicit ctor really necessary? (Note that the example above avoids the issue of implicit conversion (it won't compile), because it takes the parameter by non-const reference. With the current implementation, this is a good trick to use.) I agree that the constructor should be made explicit. I seem to recall that we discussed this on the list about a year ago, and the main objection against an explicit constructor was that the behavior across different compilers wasn't consistent (some compilers didn't like explicit template constructors at all). But now, a year later, perhaps it's time to go ahead and make the change? It's unfortunate that it's a change that will break code; perhaps some legacy mode needs to be provided. Anyway, there have been several requests for this and thus far no strong opinions against it. Bjorn

6 9

Customization via Overloading in Namespace
by David Abrahams 28 Feb '04

28 Feb '04

Unless I'm just observing a bug in Comeau, I've just discovered something. In http://www.boost-consulting.com/writing/qn.html I note that, as a means of algorithm customization... library writers are unlikely to invite users to overload functions in the library's namespace, since: a. It is syntactically heavy and inconvenient for users to define overloads in other namespaces: // user.hpp namespace user { class my_class; } // * Extra commented lines required to // * produce overloads in lib:: and namespace lib // * return to user::. Moves f() away { // * from my_class. void f(user::my_class) // also explicit qualification of my_class } // * // * namespace user // * { // * b. Qualified lookups of names from function templates are subject to dangerous order dependencies, since qualified names bind at the point of definition. // lib.hpp namespace lib { template <class T> void f(T); template <class T> void g(T x) { lib::f(x); // binds only to visible fs } } // user.cpp #include "lib.hpp" #include "user.hpp" // defines f overload too late int main() { user::my_class x; lib::g(x); // calls lib::f(), not user::f()! } It seems that's true for qualified names, but when ADL is disabled with parentheses, names aren't bound until the point of instantiation: // lib.hpp namespace lib { template <class T> void f(T); template <class T> void g(T x) { (f)(x); // not bound here } } // user.cpp #include "lib.hpp" #include "user.hpp" // defines some user::f overload int main() { user::my_class x; lib::g(x); // calls user::f() } This hardly removes all the problems with namespaces and ADL, but maybe it restores "overloading in the library's namespace" to viability as a customization technique? -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 13

Proxy --- an indirect container adaptor
by Christian Engström 28 Feb '04

28 Feb '04

Is the following design valid, and if so, would it make a useful addition to the Boost library? I enclose a draft implementation, and look forward to any comments. /Christian - - - It can quite often be of interest to convert a program that uses a direct container into using an indirect container of smart pointers to the objects instead, either just temporarily to see what happens to performance, or permanently if it turns out to be beneficial. Unfortunately, this normally means that the program has to be modified in many different places, even for programs that are not affected as such by the slightly different semantics that indirect containers have. The proxy indirect container header file makes it possible to switch between direct and indirect containers by changing a single typedef in any such program. For example, the following test program was modified to use an indirect vector instead of a direct one by just changing the type declaration from std::vector<person> to proxy_vector<person>::self. //=================================================================== #include <boost/operators.hpp> #include "proxy.hpp" int calls_to_copy_constructor = 0; //=================================================================== class person : boost::totally_ordered<person> //------------------------------------------------------------------- { public: string name; int age; person() {} person(const string& in_name, int in_age); person(const person& other) : name(other.name), age(other.age) { ++calls_to_copy_constructor; } // Compares first name, then age friend bool operator== (const person& a, const person& b); friend bool operator< (const person& a, const person& b); bool read(istream& in_file); }; ostream& operator<< (ostream& out_file, const person& x); //=================================================================== int main (int argc, char* argv[]) //------------------------------------------------------------------- { person a_person; person someone_special("Alice", 27); ifstream in_file("test_proxy.in"); // typedef std::vector<person> buf_type; // <---- typedef proxy_vector<person>::self buf_type; // <---- buf_type buf(5, person("Undefined", -1)); buf.front() = person("First", 1); *(buf.begin() + 1) = person("Second", 2); buf[2] = person("Third", 3); (buf.begin() + 3)->name = "Incomplete"; while (a_person.read(in_file)) { buf.push_back(a_person); } std::sort(buf.begin(), buf.end()); for (buf_type::iterator it = buf.begin(); it != buf.end(); ++it) { cout << *it; if (it->age < 0) cout << " Not a proper age"; if (*it == someone_special) cout << " Someone special"; if (it != buf.begin() && (*it == *(it – 1))) cout << " Duplicate record"; cout << endl; } buf_type::iterator end_it = std::unique(buf.begin(), buf.end()); cout << "\nNumber of unique records: " << (end_it - buf.begin()); cout << "\n\nCalls to 'person's copy constructor: " << calls_to_copy_constructor << endl; return 0; } //=================================================================== So how does this work? First of all, the declaration proxy_vector<T>::self is short for proxy_container< std::vector< proxy<T> > > There are convenience templates like this for the basic container types in STL, but by using the general form the proxy container adaptor can be used on any container that has an STL compliant interface. Class proxy At the very center of the design is the proxy template class. A proxy<T> object is a smart pointer that has a boost::shared_ptr<T> as its only data member. It constructs, assigns, and takes responsibility for deleting the object in the same way as a shared_ptr. It does not support any pointer arithmetic, however, so the ++ and -- operators are undefined. Without pointer arithmetic, there is very little use for the comparison operators as they are defined for shared_ptr, so these are instead given the semantics of element_compare, which means that they compare the two objects as such rather than the pointers. (There is a conversion function to shared_ptr that can be used to test the pointers as such if necessary.) With these definitions, we can use the STL algorithms directly on any Container< proxy<T> >, and they will produce the same results as they would for a Container<T>. This applies both to algorithms like std::sort, which depends on the < operator for comparisons, and algorithms like unique, which relies on the == operator. The proxy class also contains an implicit conversion operator from proxy<T> to T&. This means that we can use a proxy<T> as the actual parameter to any function that expects a T for input or output, or, to put it another way, that the proxy is automatically “cashed in” for a T object as soon as this is required. In particular, this means that we can copy T objects from a Container< proxy<T> > into T variables, in exactly the same way as if it had been a Container<T>, since the proxy<T> object that the iterator delivers will be automatically converted to a T if it is assigned to a T variable. If we assign it to a proxy<T> variable, it will of course remain a proxy. To handle assignments to proxy variables, the default assignment operator is supplemented by operator=(const T&). This operator will create a proxy that points at a new copy of the T object, and assign it to the left hand variable. This means that we now have a Container< proxy<T> > that behaves like a Container<T> for comparisons, and when we retrieve whole objects from the container. Class proxy_iterator To get operator-> working in the same way as for a Container<T>, we define the classes proxy_iterator and const_proxy_iterator. A proxy_iterator is publicly derived from the iterator of the underlying Container< proxy<T> >. It works just like standard iterator in all respects except one, which is that operator-> does a double dereferencing, so that it will deliver a pointer to the T object itself. This lets us use the -> operator in the same way that we would with a direct container. operator* is not changed, however, and retains its single dereferencing semantics. Are we really allowed to define these operators like this? --Yes, we are. While it is true that this means that the semantics will be different for (*x).y and x->y, this does not affect the STL algorithms in any way, since they don’t make any use of the -> operator. (How could they, when they’re supposed to work on the built-in types as well?) The proxy iterators can be mixed freely with the underlying standard iterators, since the derived-to-base-class conversion will convert in one direction, and the proxy iterators have have a conversion constructor that converts in the other direction. Since the compiler will prefer a derived-to-base conversion over a user-defined conversion, the ambiguity problems that are normally associated with having two types that can be implicitly converted in both directions are eliminated. Class proxy_container The class proxy_container, finally, inherits from the underlying Container< proxy<T> > and overrides the definitions for iterator and const_iterator so that the proxy iterators are used instead. It also redefines the standard container member functions that return an iterator so that they return the appropriate proxy iterator. In order to be able to insert T objects directly into the proxy container, the class proxy_container also redefines all members that insert an object into the container so that there are two versions of each function: one that takes a proxy<T> as input and inserts a new proxy that points at the same object, and one that takes a T object and inserts a proxy that points at a newly created copy of the object. Taken together, these classes let us emulate the interface of a Container<T> with something that is actually an indirect container. Since it is only a single type declaration that has to be changed to switch between direct and indirect containers, it becomes practical to do this for testing purposes. The indirect containers still retain the full interface of a traditional container of smart pointers, so the additional capabilities of an indirect container are available in the usual way. - - - I have uploaded the full source code for the draft implementation, as well as and the test program shown here, to the files section at Yahoo, and I have tested it with MSVC6 and gcc 3.3 on Windows XP. For MSVC6 there is the problem that the implementation of std::vector::iterator is just a plain pointer and not a standards compliant iterator, so proxy_vector uses a deque rather than a vector as a workaround. File proxy.hpp: (slightly abridged) //================================================================== // 20-feb-2004 Christian Engström (christian.engstrom(a)glindra.org) //------------------------------------------------------------------ #include <vector> #include <deque> #include <list> #include <boost/smart_ptr.hpp> //================================================================== // 'proxy' //------------------------------------------------------------------ template <class T> class proxy { private: typedef proxy<T> self; boost::shared_ptr<T> m_sp; public: // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Types typedef T element_type; // "Inherited" from 'boost::shared_ptr' typedef T value_type; // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Constructors proxy() {} template<class Y> proxy(const proxy<Y>& other) : m_sp(other.as_shared_ptr()) {} template<class Y> explicit proxy(const boost::shared_ptr<Y>& other) : m_sp(other) {} template<class Y> explicit proxy(const boost::weak_ptr<Y>& other) : m_sp(other) {} template<class Y> explicit proxy(std::auto_ptr<Y>& other) : m_sp(other) {} template<class Y> explicit proxy(Y* other) : m_sp(other) {} // Assignment self& operator=(const self& other) {m_sp = other.m_sp; return *this;} self& operator=(const T& other) {*this = proxy<T>(new T(other)); return *this;} // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Conversions operator T&() const {return **this;} // Implicit conversion to T bool is_null() const {return !m_sp;} boost::shared_ptr<T>& as_shared_ptr() {return m_sp;} const boost::shared_ptr<T>& as_shared_ptr() const {return m_sp;} // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Comparisons are made on the value, never the pointer. bool operator== (const self& other) const {return **this == *other;} bool operator!= (const self& other) const {return **this != *other;} bool operator< (const self& other) const {return **this < *other;} bool operator> (const self& other) const {return **this > *other;} bool operator<= (const self& other) const {return **this <= *other;} bool operator>= (const self& other) const {return **this >= *other;} // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Dereferencing T& operator*() const {return *m_sp;} T* operator->() const {return m_sp.get();} T* get() const {return m_sp.get();} T* as_ptr() const {return m_sp.get();} }; //================================================================== // 'proxy_iterator' //------------------------------------------------------------------ template <class MutableBaseIterator> class proxy_iterator : public MutableBaseIterator { private: typedef proxy_iterator<MutableBaseIterator> self; typedef MutableBaseIterator base; typedef typename base::value_type::element_type T; public: // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Types typedef typename base::difference_type difference_type; // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Constructors proxy_iterator() {} proxy_iterator(const MutableBaseIterator& it) : base(it) {} // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Standard operators for iterators T* operator-> () {return (**this).get();} // Indirect self& operator++ () {base::operator++ (); return *this;} self& operator-- () {base::operator-- (); return *this;} self operator++ (int) {return base::operator++ (0);} self operator-- (int) {return base::operator-- (0);} self& operator+= (difference_type n) {base::operator+= (n); return *this;} self& operator-= (difference_type n) {base::operator-= (n); return *this;} self operator+ (difference_type n) const {return base::operator+ (n);} self operator- (difference_type n) const {return base::operator- (n);} friend self operator+ (difference_type n, self x) {return x + n;} friend difference_type operator- (self x, self y) {return base(x) - base(y);} }; //================================================================== // 'const_proxy_iterator' //------------------------------------------------------------------ { // Analagous to proxy_iterator, and with a conversion constructor from proxy_iterator. ... }; //================================================================== // 'proxy_container' //------------------------------------------------------------------ template <class BaseProxyContainer> class proxy_container : public BaseProxyContainer { private: typedef proxy_container self; typedef BaseProxyContainer base; typedef typename BaseProxyContainer::value_type value_type; typedef typename BaseProxyContainer::value_type::element_type T; public: // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Constructors proxy_container() {} proxy_container(const base& c) : base(c) {} template <class InputIterator> proxy_container(InputIterator first, InputIterator last) : base(first, last) {} explicit proxy_container(typename base::size_type n, const value_type& x = value_type()) : base(n, x) {} proxy_container(typename base::size_type n, const T& x) { for (typename base::size_type i = 0; i < n; ++i) { push_back(proxy<T>(new T(x))); } } // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Iterators redefined typedef proxy_iterator<typename base::iterator> iterator; typedef const_proxy_iterator<typename base::iterator, typename base::const_iterator> const_iterator; typedef std::reverse_iterator<iterator> reverse_iterator; typedef std::reverse_iterator<const_iterator> const_reverse_iterator; // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Container members that either return an iterator or take a value_type parameter (or both) iterator begin() {return base::begin();} const_iterator begin() const {return base::begin();} iterator end() {return base::end();} const_iterator end() const {return base::end();} reverse_iterator rbegin() {return base::rbegin();} const_reverse_iterator rbegin() const {return base::rbegin();} reverse_iterator rend() {return base::rend();} const_reverse_iterator rend() const {return base::rend();} void push_front(const value_type& x) {base::push_front(x);} void push_front(const T& x) {base::push_front(proxy<T>(new T(x)));} void push_back(const value_type& x) {base::push_back(x);} void push_back(const T& x) {base::push_back(proxy<T>(new T(x)));} iterator insert(iterator position, const value_type& x) {return base::insert(x);} iterator insert(iterator position, const T& x) {return base::insert(position, proxy<T>(new T(x)));} void insert(iterator position, typename base::size_type n, const value_type& x) {base::insert(position, n, x);} void insert(iterator position, typename base::size_type n, const T& x) ; // Not yet implemented template<typename InputIterator> void insert(iterator position, InputIterator first, InputIterator last) {base::insert(position, first, last);} iterator erase(iterator position) {return base::erase(position);} iterator erase(iterator first, iterator last) {return base::erase(first, last);} void resize(typename base::size_type new_size, const value_type& x) {base::resize(new_size, x);} void resize(typename base::size_type new_size, const T& x) ; // Not yet implemented // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - // Special list operations void remove(const value_type& value) {base::remove(value);} void remove(const T& value); // Not yet implemented }; //================================================================== // The standard contaiers //------------------------------------------------------------------ template <class T> struct proxy_vector #if !defined(BOOST_MSVC_STD_ITERATOR) {typedef proxy_container< std::vector< proxy<T> > > self;}; #else {typedef proxy_container< std::deque< proxy<T> > > self;}; // MSVC workaround #endif template <class T> struct proxy_deque {typedef proxy_container< std::deque< proxy<T> > > self;}; template <class T> struct proxy_list {typedef proxy_container< std::list< proxy<T> > > self;}; // Associative containers are not yet implemented

4 17

Re: boost::any: explicit constructor?
by Kevlin Henney 28 Feb '04

28 Feb '04

In message <uznb55omh.fsf(a)boost-consulting.com>, David Abrahams <dave(a)boost-consulting.com> writes > >The conversion to boost::any isn't a widening conversion in the usual >sense, though, is it? Normally, a widening conversion preserves not >only the information but the *interface* of the original data -- you >wouldn't consider an implicit conversion from int to string a widening >conversion, would you? Your assumption is not quite correct: most widening conversions are not interface preserving. Kevlin -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________

1 0

RE: [boost] Proxy indirect container adaptor: 4 claims
by Victor A. Wagner Jr. 28 Feb '04

28 Feb '04

At Thursday 2004-02-26 09:13, you wrote: > > -----Original Message----- > > From: christian.engstrom(a)glindra.org > > [mailto:christian.engstrom@glindra.org] > > Sent: Thursday, February 26, 2004 4:40 PM > > To: boost(a)lists.boost.org > > Subject: [boost] Proxy indirect container adaptor: 4 claims > > > > --Is there a way to define a package for indirect containers, so that > > one can take a program that uses a direct container, and > > convert it to > > using an indirect container just by changing the definition of the > > container type? > >You could define a container adaptor that takes a container, and modifies >the begin()/end() iterators to return indirect iterators to the original >begin()/end(). Then instead of: > typedef some_container container_type; >you would have: > typedef adaptor<some_container> container_type; > > > --Would it be any useful to be able to switch containers like that? > > > > The problem here is of course that "usefulness" is very much > > in the eye > > of the beholder, so all that I can say with certainty is that I > > personally would find it quite useful, and that I don't see why other > > people as well shouldn't sometimes find themselves in situations when > > they would want to change container types easily. After all, > > isn't one > > of the great benefits of the STL containers that they have > > (reasonably) > > uniform interfaces, so that it's easy to switch between the different > > container types, often by just changing a typedef? > >You might want to read "Beware the Illusion of container-independent >code", by Scott Meyers in his book: >http://www.awprofessional.com/isapi/content/images/0201749629/items/item2-2… >The full book is at: >http://www.awprofessional.com/catalog/product.asp?product_id={AA4735AF-4407… I've read it and am considering writing an article explaining that although he's correct, part of the problem lies directly with "the Committee". Scott writes about how things _are_, not as they could(should?) be. Many of the restrictions are completely artificial. I've said it before, and I'll continue saying it. One of the big problems of the "C heritage" is that too many people think that syntax implies implementation. >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

[Boost-bugs] [ boost-Bugs-906289 ] uBLAS on Borland C++ 5.5.1 - 9 compile errors
by SourceForge.net 28 Feb '04

28 Feb '04

Bugs item #906289, was opened at 2004-02-28 03:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=906289&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Valentin Lavrinenko (vlavrinenko) Assigned to: Nobody/Anonymous (nobody) Summary: uBLAS on Borland C++ 5.5.1 - 9 compile errors Initial Comment: Compiling the test program provided in boost_1_31_0/libs/numeric/ublas/doc/matrix.htm with bcc32 5.5.1 gives the following output: Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland test.cpp: Error E2479 c:\bcc55\include\algorith.h 97: Cannot have both a template class and function named 'find' Error E2479 c:\bcc55\include\algorith.cc 71: Cannot have both a template class and function named 'find' Error E2479 c:\bcc55\include\complex.h 1158: Cannot have both a template class and function named 'arg' Error E2401 C: \BCC55\boost\include\boost-1_31\boost/numeric/ublas/tr aits.hpp 1011: Invalid template argument list Error E2040 C: \BCC55\boost\include\boost-1_31\boost/numeric/ublas/tr aits.hpp 1012: Declaration terminated incorrectly Error E2479 C: \BCC55\boost\include\boost-1_31\boost/numeric/ublas/ra w.hpp 25: Cannot have both a template class and function named 'size' Error E2479 C: \BCC55\boost\include\boost-1_31\boost/numeric/ublas/ra w.hpp 29: Cannot have both a template class and function named 'size' Error E2479 C: \BCC55\boost\include\boost-1_31\boost/numeric/ublas/ra w.hpp 428: Cannot have both a template class and function named 'size' Error E2479 C: \BCC55\boost\include\boost-1_31\boost/numeric/ublas/ra w.hpp 434: Cannot have both a template class and function named 'size' I've managed it by making some changes in the .hpp files (changed files are attached here in a zip archive, the lines I've added are marked with //LVU). And now the matrix test programs run perfectly. Unfortunately, I've failed to build regression test suite and cannot tell the test results. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=906289&group_i… ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Proxy indirect container adaptor: 4 claims
by Yitzhak Sapir 27 Feb '04

27 Feb '04

> -----Original Message----- > From: christian.engstrom(a)glindra.org > [mailto:christian.engstrom@glindra.org] > Sent: Thursday, February 26, 2004 4:40 PM > To: boost(a)lists.boost.org > Subject: [boost] Proxy indirect container adaptor: 4 claims > > --Is there a way to define a package for indirect containers, so that > one can take a program that uses a direct container, and > convert it to > using an indirect container just by changing the definition of the > container type? You could define a container adaptor that takes a container, and modifies the begin()/end() iterators to return indirect iterators to the original begin()/end(). Then instead of: typedef some_container container_type; you would have: typedef adaptor<some_container> container_type; > --Would it be any useful to be able to switch containers like that? > > The problem here is of course that "usefulness" is very much > in the eye > of the beholder, so all that I can say with certainty is that I > personally would find it quite useful, and that I don't see why other > people as well shouldn't sometimes find themselves in situations when > they would want to change container types easily. After all, > isn't one > of the great benefits of the STL containers that they have > (reasonably) > uniform interfaces, so that it's easy to switch between the different > container types, often by just changing a typedef? You might want to read "Beware the Illusion of container-independent code", by Scott Meyers in his book: http://www.awprofessional.com/isapi/content/images/0201749629/items/item2-2… The full book is at: http://www.awprofessional.com/catalog/product.asp?product_id={AA4735AF-4407…

2 1

Formal review queue
by Thomas Witt 27 Feb '04

27 Feb '04

Hi, Following is a draft of the list of outstanding reviews. It's perfectly possible that I missed a request or messed up lib or author names. Request Date / Name / Author / Review Manager 2003-09-10 / Indexed Set / Joaquín M López Muñoz / (Pavel Vozenilek) 2003-09-16 / Assignment / Thorsten Ottosen 2003-09-28 / Container Traits / Thorsten Ottosen 2003-10-03 / Tribool / Douglas Gregor 2003-11-27 / More IO / Daryle Walker 2003-11-28 / Iostreams / Jonathan Turkanis / 2003-11-28 / Output Formatters / Reece Dunn 2003-12-22 / Pointer Containers / Thorsten Ottosen 2004-01-17 / Named Params / David Abrahams Daniel Wallin 2004-01-25 / Wave / Hartmut Kaiser / Could those involved please check and mail corrections to me directly. The website will be updated shortly. Almost all of the libs don't have a review manager assigned, so I am looking for review managers as well. Anybody who is are interested in being review manager for any of these libraries can contact me directly. Thanks Thomas Boost Review Wizard

11 17

[mpl?] loki -> boost
by Jody Hagins 27 Feb '04

27 Feb '04

I have a bunch of code that uses loki. I am trying to convert it to use boost instead. However, I am having a very difficult time finding concepts in boost to replace those in loki. I have looked for something to help in this, but I have not had much success. I have read through the MP documentation, and I am even more confused. For example, I use Loki::Int2Type, and according to a loose interpretation of section 2.3.6, mpl::int_c<> may be what I am looking for (at least for this one specific case). However, when I went to look at the source to make sure it does what I think it does, I could not find it anywhere. I have 1.31.0, extracted from the tar.gz file, and did a complete find, but the only place I can find reference to it is in .sgml files. Anyone know what this became, or how to correct my brain-dedness? shandalle:jody> md5sum boost_1_31_0.tar.gz c19ed169de6e76de91f2a1602fb1c688 boost_1_31_0.tar.gz shandalle:jody> find . | xargs egrep 'int_c[:space:]*<' ./libs/mpl/doc/paper/src/lambda.sgml: mpl::less< mpl::sizeof_<_1>, mpl::int_c<16> > ./libs/mpl/doc/paper/src/lambda.sgml: , mpl::int_c<16> ./libs/mpl/doc/paper/src/lambda.sgml: , mpl::bind< mpl::less<>, mpl::bind<mpl::sizeof_<>,_1>, mpl::int_c<16> > ./libs/mpl/doc/paper/src/lambda.sgml: mpl::less< mpl::sizeof_<_>,mpl::int_c<16> > ./libs/mpl/doc/paper/src/lambda.sgml: mpl::less< mpl::sizeof_<_>,mpl::int_c<16> > ./libs/mpl/doc/paper/src/lambda.sgml: mpl::less< mpl::sizeof_<_>,mpl::int_c<16> > ./libs/mpl/doc/paper/src/sequences.sgml: mpl::int_c<1> ./libs/mpl/doc/paper/src/sequences.sgml: , mpl::int_c<2> ./libs/mpl/doc/paper/src/sequences.sgml: , mpl::int_c<3> ./libs/mpl/doc/paper/src/sequences.sgml: , mpl::int_c<4> ./libs/mpl/doc/paper/src/sequences.sgml: , mpl::int_c<5> ./libs/mpl/doc/src/howtos.sgml:typedef mpl::lower_bound<types, mpl::int_c<5>, mpl::less<_1,_2> >::type iterator; ./libs/mpl/doc/src/howtos.sgml:typedef mpl::upper_bound<types, mpl::int_c<5>, mpl::less<_1,_2> >::type iterator; ./libs/mpl/doc/src/howtos.sgml:typedef mpl::binary_search<types, mpl::int_c<5>, mpl::less<_1,_2> >::type iterator; -- Jody Hagins What did Mickey Mouse get for Christmas? A Dan Quayle watch. -- heard from a Mike Dukakis field worker

7 8

Re: [boost] Proxy indirect container adaptor: 4 claims
by Jesse Booher 26 Feb '04

26 Feb '04

>> Christian Engström <christian.engstrom(a)glindra.org> writes: > 1) By using a proxy object, which is essentially a shared_ptr with the > pointer arithmetic removed and with the comparison operators redefined > to compare the elements, and storing such proxy objects in an STL > compatible container, we can use all the algorithms in the STL on the > Container< proxy<T> >, and get the same result as with a Container<T>. > (This works even with the standard STL iterators and in the absence of > any of the other components of the package, so it could be used as a > standalone feature if desired.) > 2) By making proxy<T> implicitly convertible to T&, a proxy<T> can be > used (almost) as a T when it comes to assignments and argument passing. > In the situations when it doesn't work, such as if a function takes a > U argument and was expecting another user-defined conversion from T to U > to let it handle a T arguments as well, the compiler will generate a > type error. > 3) By letting proxy_container define an extra variant for each member > function that would normally take a proxy<T> argument, and letting the > extra variant accept a T instead, we complete the last part of the > symmetry with direct containers as far as entire T objects are concerned. > 4) By defining operator-> in for proxy_container's iterators to do a > double dereferencing, the meaning of that expression remains the same > for a proxy_container iterator as it would for the direct container > iterator. operator* keeps its normal semantics and does a single > dereferencing. This definition is necessary to keep Claim 1 valid, and > to keep the proxy_container working as one would expect from an indirect > container in general. Your Proxy discussion has intrigued me and I took a look at the issue thinking I could come up with a quick solution. The problem is much more subtle than it appears at first blush, however. The main problem is that existing container classes have a fixed concept of what types of iterators that they process. There is no way to tell std::vector that its begin() method should return anything other than std:vector::iterator. If there were an easy way to change this behavior then your proxy problem would become trivial. Imagine for a moment that Iterator Types were part of vector's template arguments then vector<T, allocator<T>, vector<T>::default_iterator, vector<T>::default_reverse_iterator> and vector<S, allocator<S>, indirect_iterator<vector<S>::default_iterator>, indirect_iterator<vector<S>::default_reverse_iterator> >, with S being shared_ptr<T>, would be duals the first for direct access and the second for proxy access. Wonder what it would take to make this happen. Could perhaps be a solution worthy of standards submission. Regards, Jesse Booher

1 0

FC++ Formal review half way over today (ends 2/23)
by Mat Marcus 26 Feb '04

26 Feb '04

Reminder: the formal review for the FC++ functional programming library is now at the half way point - only 5 days remain. If you have an interest in the FC++ library now would be a good time to prepare a review. It would be useful to hear your opinion even if you are not an expert in the functional programming domain or you don't know what a monad is. You are not required to spend a lot of time with the code (although it can be helpful). Some seed questions, in addition to the usual ones referred to below (and at <http://www.boost.org/more/formal_review_process.htm>): Can you understand the intent of the library from the documentation and example code? What are your ideas about the relationship between FC++ and existing boost components? Would some or all of the facilities FC++ (lazy lists, monads, lambda, "prelude") make a useful, relevant addition to boost? Why or why not? If not, do you believe that the author should rework parts of the lib for possible later acceptance? Individual reviews are an essential part of the review process, so please consider spending some time with FC++ this week and then post your thoughts. Thanks, Mat The original notice is reproduced below for your convenience. ### The formal review of fcpp by Brian McNamara and Yannis Smaragdakis is now in progress, running from Friday February 13th at 12 noon, PST and and run to Monday, February 23rd, 12 noon PST. The library is currently available at <http://www.cc.gatech.edu/~yannis/fc++/boostpaper/> Here is a brief introduction to the library: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order polymorphic functions, currying, lazy evaluation, and lambda. In addition to the framework, FC++ also provides a large library of useful functions and data types. The main utility of the library comes from its ability to implement functional programming designs, especially those which use higher-order polymorphic functions or lazy evaluation in significant ways. The library also contains a number of ancillary components that implement features like currying and lambda for function objects; these features are also useful in their own right. For information about submitting a Formal Review, see <http://www.boost.org/more/formal_review_process.htm> Please try out the library and read the documentation and say whether or not you think the library should be accepted by Boost and why. Compiler notes: This library has been tested with icc7 and with gcc-3.1.1 (and various other gcc-3.x.y versions) on Solaris and Linux. The library is also likely to compile on VC++7.1 and Comeau (prior versions of the library succeeded with these compilers, but this particular snapshot has not been tested with them). The library covers a great deal of the C++ language and thus requires a high degree of standard conformance; compilers like gcc-2.95.x and VC++6 will not be able to compile the library. Getting started: The web page http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ mentions all the basics: The zip file will expand into these subdirectories: fcpp/fcpp/ # the library (.hpp) files fcpp/fcpp_clients/ # the example (.cpp) files Running the examples just involves invoking the complier with the right #include paths; for example, # in the fcpp_clients directory g++ -I/path/to/boost -I../fcpp some_example.cpp There is also a gnu-style Makefile included with the clients (examples), which will compile all of the examples in batch (you will have to edit a tiny bit at the top of the Makefile). The examples in the clients directory are a mix of both (regression-type) tests cases which cover the features of the library and example applications which demonstrate some of the library's utility. The README file in the client directory gives a short explanation of some of the more interesting clients. The documentation at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ provides a walkthrough and reference for most of the main features of the library. There are also some pointers out to other papers and documentation on the main FC++ web site: http://www.cc.gatech.edu/~yannis/fc++/ Conformance to Boost guidelines: The library meets most of the requirements described at http://www.boost.org/more/lib_guide.htm Here are a few notable exceptions: - the current library headers are too "monolithic"; you #include "prelude.hpp" and suck in all of the library - some of the lambda internals should be rewritten to use MPL rather than hand-rolled metaprogramming code - only a few of the example programs utilize the Boost testing framework (to automate regression testing) Should the library be accepted into Boost, Brian will remedy these deficiencies. (If you notice other major problems along these lines, please bring them to Brian's attention during the review.) The Formal Review manager is Mat Marcus.

10 20

Proposal: type-promoting arithmetics for derivative types
by Max Motovilov 26 Feb '04

26 Feb '04

This is a long post, so please let me know if making it into a Web page and posting the URL is a better idea. ======================= [Terminology] Since I am not sure whether there is an accepted term for this kind of types, let me introduce one - "derivative arithmetic type": - D.A.T. is a templatized ADT with at least some arithmetic operations defined - D.A.T. is parameterized with a single type-parameter which has at least some arithmetic operations defined (usually it is a built-in numeric type, but not necessarily) - Arithmetic operations on D.A.T. are defined in terms of arithmetic operations on the base type - There is a conversion available between differently parameterized instances of D.A.T. The above certainly isn't a good "standardese" concept definition but it should be enough to illustrate the proposal. Examples of D.A.T.s are std::complex<>, boost::rational<>, boost::math::quaternion<> etc. However, the motivation for this proposal came from my experience with implementing geometric types such as point, rectangle etc. along with operations on them. [Proposal, Part I] Providing a facility that simplifies arithmetic type promotions for D.A.T.s. None of the examples above currently provide it, which means that you cannot expect std::complex<float>( 1, 0 ) + std::complex<double>( 0, 1 ) to yield std::complex<double>( 1, 1 ). So, expressions on D.A.T.s with mixed base types do not really behave the way the built-in numeric types do, even though the individual values can be converted from one instance of the same D.A.T. to another. In the ideal world, one should be able to write: template< typename T1, typename T2 > foo< typeof( T1() + T2() ) > operator+( const foo<T1>&, const foo<T2>& ); and then implement operator+ the way it is normally implemented for foo<T>, first converting foo<T1> and foo<T2> to foo< typeof< T1() + T2() >. I intentionally leave out the optimization issues such as defining operator+ in terms of operator+= etc. However, without typeof(), it would be nice to have a library solution yielding similar result, for example: template< typename T1, typename T2 > foo< promoted_type< T1, T2, std::plus > > operator+( const foo<T1>&, const foo<T2>& ); The third argument of promoted_type<> could be any kind of tag value or type associated with the type of arithmetic operation. Templates std::plus, std::minus, std::multiplies, std::divides and std::modulus do not cover the entire range of C++ arithmetic operations so some other tags may work better. The implementation of promoted_type will obviously be based on partial specializations along with a limited typeof() facility with the assumption that T1 op T2 always yields either T1 or T2 (which is the case for built-in base types). Here is a quick and dirty implementation for only one operation, operator+: template< typename T1, typename T2 > struct typeof_one_of_two { template<int N> struct select_type; template<> struct select_type<1> { typedef T1 type; }; template<> struct select_type<2> { typedef T2 type; }; static char (&typeof_fun( const T1& ))[1]; static char (&typeof_fun( const T2& ))[2]; }; template< typename T > struct typeof_one_of_two<T,T> { template<int N> struct select_type { typedef T type; }; static char typeof_fun( const T& ); }; template< typename T1, typename T2, template< typename _ > class Tag > struct promoted_type; template< typename T1, typename T2 > struct promoted_type< T1, T2, std::plus > { enum { tag = sizeof( typeof_one_of_two<T1,T2>::typeof_fun( T1() + T2() ) ) }; typedef typename typeof_one_of_two<T1,T2>::select_type< tag >::type type; }; (I tried it on MSVC++ 7.1 and it works, though for some reason it doesn't compile if I drag the expression for promoted_type<>::tag into the declaration for promoted_type<>::type. With the intermediate enum value it works fine - a compiler bug?) Note that promoted_type<> may be used not just in binary operators but in any external function or a D.A.T. method, possibly with different D.A.T. parameters, as long as one can make a reasonable deduction of the result type based on certain arithmetic operation over base type values. Also note that all built-in binary operators defined for a pair of built-in numeric types produce results of the same type. This means we wouldn't really need 3rd parameter for promoted_type<> if the base types were always built-in numerics, but user-defined base types may break this assumption. [Proposal, Part II] Going further, we might want to add type-promoting arithmetics to existing DATs that do not provide it. The best I could think of so far is introducing overly generic template operators into global namespace, along with a mechanism based on boost::enable_if to restrict their use to specific parameter templates. The model implementation follows. I find it ugly, but perhaps a better one may be immediately obvious to somebody else. template< template< typename _ > class DAT > struct promote_sum { typedef void tag; }; template< typename P, typename E=void > struct do_not { enum { value = false }; }; template< typename P > struct do_not< P, typename P::tag > { enum { value = true }; }; template< typename T1, typename T2, template< typename _ > class DAT > inline typename boost::disable_if_c< do_not< promote_sum< DAT > >::value, DAT< typename promoted_type<T1,T2,std::plus>::type > >::type operator+( const DAT<T1>& a, const DAT<T2>& b ) { typedef typename DAT< promoted_type<T1,T2,std::plus>::type > T; return T( a ) + T( b ); } To enable promoted-type operator+ for a specific DAT (that already has some flavor of operator+ though without mixing base types), write: template<> struct promote_sum< MyDAT > {}; The use, but not implementation, is similar to the technique suggested by David Abrahams in boost::operators. This one is uglier but, I believe, standard-compliant. Template do_not<> does a SFINAE trick of its own because I couldn't figure out how to do the same thing with enable_if. And again, MSVC++ 7.1 swallows it whole. Here's what I used to test it: template<typename T> struct MyDAT_1 { friend MyDAT_1<T> operator+ ( const MyDAT_1<T>&, const MyDAT_1<T>& ); MyDAT_1( T ); template<typename T1> explicit MyDAT_1( const MyDAT_1<T1>& ); }; template<typename T> struct MyDAT_2 { friend MyDAT_2<T> operator+ ( const MyDAT_2<T>&, const MyDAT_2<T>& ); MyDAT_2( T ); template<typename T1> explicit MyDAT_2( const MyDAT_2<T1>& ); }; template<> struct promote_sum<MyDAT_1> {}; Here MyDAT_1 and MyDAT_2 are identical types; both define an operator+ for uniform arguments. Promoted operator+ is only enabled for MyDAT_1. Now, MyDAT_1<double> a(( MyDAT_1<int>( 1 ) + MyDAT_1<float>( 2.0 ) )); compiles, while MyDAT_2<double> b(( MyDAT_2<int>( 1 ) + MyDAT_2<float>( 2.0 ) )); produces the following error: e:\tmp\t.cpp(77): error C2678: binary '+' : no operator found which takes a left-hand operand of type 'MyDAT_2<T>' (or there is no acceptable conversion) with [ T=int ] which looks rather on-the-money to me. The example implementation above only covers operator+( Foo<T1>, Foo<T2> ). It has an obvious extension to all operator@( Foo<T1>, Foo<T2> ) as well as to other things, for example: template<> struct promote_product2< Matrix, Vector > {}; which can be implemented in the same way. An important special case is support for things like operator*( Matrix<T1>, T2 ) where T2 is presumed to be a scalar type and Matrix<T1>*T2 is expected to yield a Matrix< promoted_type< T1, T2, std::multiplies > >. A generic operator* can be provided for this case but it will only discriminate based on its first argument, which may be dangerously generic for a general-purpose facility... ================================= Well, if anybody got this far, I have to confess that I'm not sure what to do with all this. The first part looks so trivial I may have well overlooked an equivalent facility in one of the existing Boost libraries. If I haven't, it hardly deserves a separate library, but I'm not sure which existing one would be a good place for it. The second part looks like it belongs in boost::operators, assuming that its benefits outweigh the dangers of introducing very generic operators into global namespace (or is there a way to do it otherwise and still get C++ to find the operator definitions?). Let me know whether it will be worthwhile to develop proposed facilities for subsequent Boostification. Regards, ...Max...

4 11

small bug in [date_time] library
by John Torjo 26 Feb '04

26 Feb '04

In date_time library, compiler_config.hpp, at line 53: // workaround for errors associated with wide string output // modifications. compilers affected are: // Borland 551, gcc295 (not stlport), msvc6, mingw // Any of these compilers *should* work if used with StlPort's streams #if ((defined(__GNUC__) && (__GNUC__ < 3)) || \ (defined(_MSC_VER) && (_MSC_VER <= 1200)) || \ (defined(__MINGW32__)) || \ (defined(__BORLANDC__) && (__BORLANDC__ <= 0x0551))) && \ !defined(_STLP_OWN_IOSTREAMS) #define BOOST_DATE_TIME_NO_WSTRING_CONVERSIONS #endif As a side note, the bug appears for VC7.1 as well, so you should update for this as well. Best, John

2 1

Re: boost::any: explicit constructor?
by Bjorn.Karlsson＠readsoft.com 26 Feb '04

26 Feb '04

> From: Vladimir Prus [mailto:ghost@cs.msu.su] > > The experience in my case is very simple. I had two bugs > because constructor > is not explicit. I've just made it explicit locally, > recomplied and got no > complication errors, so convenience was not hurted. Yes, an explicit constructor is safer because it would cause those bugs to be detected at compile time, but convenience *is* hurt: std::vector<boost::any> vec; vec.push_back(5); With an explicit constructor, the above won't work. Bjorn

4 4

Please disregard this test message
by Larry Meehan 26 Feb '04

26 Feb '04

test

1 0

RE: [boost] Proxy indirect container adaptor: 4 claims
by Yitzhak Sapir 26 Feb '04

26 Feb '04

> -----Original Message----- > From: christian.engstrom(a)glindra.org > [mailto:christian.engstrom@glindra.org] > Sent: Thursday, February 26, 2004 4:40 PM > To: boost(a)lists.boost.org > Subject: [boost] Proxy indirect container adaptor: 4 claims > > --Is there a way to define a package for indirect containers, so that > one can take a program that uses a direct container, and > convert it to > using an indirect container just by changing the definition of the > container type? You could define a container adaptor that takes a container, and modifies the begin()/end() iterators to return indirect iterators to the original begin()/end(). Then instead of: typedef some_container container_type; you would have: typedef adaptor<some_container> container_type; > --Would it be any useful to be able to switch containers like that? > > The problem here is of course that "usefulness" is very much > in the eye > of the beholder, so all that I can say with certainty is that I > personally would find it quite useful, and that I don't see why other > people as well shouldn't sometimes find themselves in situations when > they would want to change container types easily. After all, > isn't one > of the great benefits of the STL containers that they have > (reasonably) > uniform interfaces, so that it's easy to switch between the different > container types, often by just changing a typedef? You might want to read "Beware the Illusion of container-independent code", by Scott Meyers in his book: http://www.awprofessional.com/isapi/content/images/0201749629/items/item2-2… The full book is at: http://www.awprofessional.com/catalog/product.asp?product_id={AA4735AF-4407…

1 0

Re: Very odd Comeau C++ behavior
by Comeau Computing 26 Feb '04

26 Feb '04

Just a follow up that in addition to the work around previously sent below, there is now a patch that fixes the underlying problem. Holler if you need a revised compiler. - Greg At 08:40 PM 1/26/2004 +0200, Peter Dimov wrote: >While implementing operator== for boost::mem_fn, I found that the following >program, which I expected to print '1' six times, mysteriously outputs 1 0 1 >1 0 1 under Comeau C++, causing all mem_fn equality tests to fail: > >#include <iostream> > >struct X >{ > int mf0_1() { return 0; } > int mf0_2() { return 0; } >}; > >struct mf0 >{ > typedef int (X::*F) (); > F f_; > > explicit mf0(F f): f_(f) {} > > bool operator==(mf0 const & rhs) const > { > return f_ == rhs.f_; Thanks for the report, it appears you've uncovered a problem. It's being looked into further. For now, this should work: return f_ == rhs.f_ ? true : false; > } > > bool operator!=(mf0 const & rhs) const > { > return f_ != rhs.f_; As well as here: return f_ != rhs.f_ ? true : false; > } >}; > >int main() >{ > std::cout << ( &X::mf0_1 == &X::mf0_1 ) << std::endl; > std::cout << ( mf0(&X::mf0_1) == mf0(&X::mf0_1) ) << std::endl; > std::cout << ( mf0(&X::mf0_1).f_ == mf0(&X::mf0_1).f_ ) << std::endl; > > std::cout << "--\n"; > > std::cout << ( &X::mf0_1 != &X::mf0_2 ) << std::endl; > std::cout << ( mf0(&X::mf0_1) != mf0(&X::mf0_2) ) << std::endl; > std::cout << ( mf0(&X::mf0_1).f_ != mf0(&X::mf0_2).f_ ) << std::endl; >} > >Output: > >C:\Documents and Settings\pdimov\My Documents\Projects\testbed>como >testbed.cpp >Comeau C/C++ 4.3.0.1 (Aug 21 2002 15:45:32) for MS_WINDOWS_x86 >Copyright 1988-2002 Comeau Computing. All rights reserved. >MODE:strict errors C++ > > >C:\Documents and Settings\pdimov\My Documents\Projects\testbed>aout.exe >1 >0 >1 >-- >1 >0 >1 > >Is this a known issue with Comeau C++ 4.3? Or is there something wrong with >the code? ------- Comeau C/C++ 4.3.3: Offering core language support for C++03 Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries. Have you tried it? comeau(a)comeaucomputing.com http://www.comeaucomputing.com

1 0

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 26 Feb '04

26 Feb '04

> From: David Abrahams [mailto:dave@boost-consulting.com] [snip] > > Sorry, during shortening my previous mail before posting, > one sentence > > got lost :) I was suggesting to add is_iterator, > > If you can figure out how to do that, you will be a hero to many. [snip] One way would be to check if the required iterator_traits are defined for the type, i.e. iterator_traits<T>::difference_type etc, using BOOST_MPL_HAS_XXX_TRAIT_DEF. Too fragile? Bjorn

2 1

Re: boost::any: explicit constructor?
by Bjorn.Karlsson＠readsoft.com 26 Feb '04

26 Feb '04

> From: Kevlin Henney [mailto:kevlin@curbralan.com] > I have yet to see a convincing reason to make it explicit. Autoboxing > has been a part of boost::any's design from day 1, which > existed before > Boost -- and, indeed, the "autoboxing" terminology. Supporting such > conversions was intentional. There is no more reason to make the > converting constructor of boost::any explicit than there is > to make the > converting constructor of std::string explicit, or the conversion from > int to long explicit, or the conversion from T * to void *, or indeed > any other widening conversion. Perhaps you could add this design decision as a FAQ in the documentation for any? Something like this (assuming a faq.xml among the any docs): <qandaentry> <question><para>Why isn't the parameterized constructor for <classname>boost::any</classname> explicit?</para></question> <answer> <para>The most important reason is that <classname>boost::any</classname> favors the convenience of implicit widening conversions over the additional safety of an explicit constructor. This design decision is fundamental for <code><classname alt="boost::any">any</classname></code>, so making the constructor explicit would require very convincing reasons. </para> <para>One useful idiom when the implicit construction of <code><classname alt="boost::any">any</classname></code> is considered a problem is to always pass <classname>boost::any</classname> by reference rather than by reference to <code>const</code>, or by value. This avoids implicit conversions of arguments to functions accepting <classname>boost::any</classname>. For example, the following example shows how to disable autoboxing for calls to the function <code>sample</code>: </para> <programlisting name="any.faq.pass_by_reference">void sample(boost::any& a) {} int main() { boost::any a(5); sample(a); // This works sample(5); // This won't compile }</programlisting> </answer> </qandaentry> If you like it, I'll update the docs. Bjorn

1 0

[utility] question on prior(x,n)
by Daniel Frey 26 Feb '04

26 Feb '04

Consider: // A strange way to retrieve my_container.begin(): boost::prior( my_container.end(), my_container.size() ); Is that legal? The second template parameter of boost::prior is deduced to an unsigned(!) type, which IMHO means that -n is undefined, right? Do we need to fix this? Maybe: template <class T> T prior(T x, typename T::difference_type n) { std::advance(x, -n); return x; } or shall we document that it's illegal/undefined to call boost::prior() with an unsigned second parameter? Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey(a)aixigo.de, web: http://www.aixigo.de

5 17

small addition to functional
by John Torjo 26 Feb '04

26 Feb '04

Hi all, I think since member functions can be wrapped up as functors, why not same for member data? Therefore, I think this could be a useful addition to functional: // wraps a member data into a functor // // very useful with boost::bind template<class type, class member_type> class mem_data_t { typedef member_type type::*data; public: // FIXME allow also having non-const result-type typedef const member_type & result_type; mem_data_t( data d) : m_data(d) {} const member_type & operator()( const type & val) const { return val.*m_data; } member_type & operator()( type & val) const { return val.*m_data; } private: data m_data; }; template<class type, class member_type> mem_data_t<type,member_type> mem_data(member_type type::*data) { return mem_data_t<type,member_type>(data); } It can be improved, but roughly, that's it. What do you think? Best, John

1 1

RE: [Boost-users] Re: about license
by Darryl Green 26 Feb '04

26 Feb '04

Cross posted from boost-users... > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Wednesday, 25 February 2004 11:43 AM > Marleny Rafferty <marleny(a)rafferty.net> writes: > > > Hi- > > > > I am considering using boost in my applications, but I have > a question > > about the boost license at > http://www.boost.org/LICENSE_1_0.txt . It > > says (edited) > "Permission is hereby granted, free of charge, to ... > > use [and] reproduce ... the Software". > > > > It also says that any derivative works must also have the > same license > > grant. > > > > If my application uses boost libraries unchanged, is it considered a > > derivative work? > > Yes. Really? The ligitimacy of this stance seems questionable (but ianal etc). Further I did not see it as being part of the objectives for the license. Quite the opposite in fact. > > > If so, does that mean that if I distribute my compiled software, I > > must allow free of charge use and distribution? > > No, the license gives an explicit exemption for compiled code > (emphasis mine): [let me just re-insert some additioanl context here] ! The copyright notices in the Software and this entire statement ! ... ! must be included in all copies of the Software, in whole or in part, and > > all derivative works of the Software, UNLESS SUCH COPIES OR DERIVATIVE > WORKS ARE SOLELY IN THE FORM OF MACHINE-EXECUTABLE OBJECT > CODE GENERATED BY > A SOURCE LANGUAGE PROCESSOR. > I took this to mean that nobody can delete/change the copyright/license in the sources if they copy or produce a derivative work but that there is no need to include the license in a binary distribution. It did not occur to me that leaving the license in place somehow forms a viral attachment to other source in a source distribution. It potentially makes this license incompatible with the intent of other (open and closed) source licenses eg. // some_gpled_source_file.cpp // this file is distributed under the gpl // changed some stuff so we use boost libs #include <some_boost_lib> // oops - now it is some boost/gpl hybrid?????? I thought avoiding this sort of thing was precisely why the boost license was developed. I also thought this interpretation of "derived work" was somewhat contentious anyway. In a commercial context, this interpretation appears to make this license hopeless - anyone obtaining a copy of source code which uses boost (which you appear to be claiming is automatically a derivative work), appears to be free to do what they like with it. It is hardly reasonable that this occur if a company distributes source code with some particular intent/license for its use. That is even without considering the issue of copies obtained without the company/authors permission, whether the copy was obtained accidentally or criminally, and then redistributed. I'm keen to stop people copying my commercial executables, but I'm a lot more keen to stop them running off with the source code! A bit of digging through the archives finds http://aspn.activestate.com/ASPN/Mail/Message/boost/1686928 Which seems to explain why I thought the intent was what I understood it to be. Whatever the conclusion I think this needs to be in the FAQ. Regards Darryl Green. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

1 0

Small update to bibliography
by Fredrik Blomqvist 26 Feb '04

26 Feb '04

Hi, This patch adds a couple of references to the bibliography. // Fredrik Blomqvist begin 666 bibliography.patch M26YD97@Z(&UO<F4O8FEB;&EO9W)A<'DN:'1M; T*/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T] M/3T]/3T]/0T*4D-3(&9I;&4Z("]C=G-R;V]T+V)O;W-T+V)O;W-T+VUO<F4O M8FEB;&EO9W)A<'DN:'1M;"QV#0IR971R:65V:6YG(')E=FES:6]N(#$N- T* M9&EF9B M=2 M<C$N-"!B:6)L:6]G<F%P>2YH=&UL#0HM+2T@;6]R92]B:6)L M:6]G<F%P>2YH=&UL"3(R($IA;B R,# T(#$Y.C,V.C$X("TP,# P"3$N- T* M*RLK(&UO<F4O8FEB;&EO9W)A<'DN:'1M; DQ,"!&96(@,C P-" Q.3HT-SHP M.2 M,# P, T*0$ @+3(V,2PV("LR-C$L,3(@0$ -"B )"0D)/"]T9#X-"B ) M"0D\+W1R/@T*( D)"3Q44CX-"BL)"0D)/%1$('9!;&EG;CTB=&]P(B!A;&EG M;CTB;&5F="(@=VED=&@](C$V)2(^/&(^6SQA(&YA;64](D)U<FYA<%\P,B(^ M0G5R;F%P(# R/"]A/ET\+V(^/"]41#X-"BL)"0D)/%1$('9!;&EG;CTB=&]P M(B!A;&EG;CTB;&5F="(@=VED=&@](C@T)2(^4W1E=F5N(%(N($)U<FYA<"P@ M/&D^0F]O<W0Z.F%N>3PO:3XL( T**PD)"0D)2W5R;S5H:6XL($UA>2 Q+" R M,# R+B \02!H<F5F/2)H='1P.B\O=W=W+FMU<F\U:&EN+F]R9R]S=&]R>2\R M,# R+S4O,2\Q-#(S,C$O.34Q,R(^#0HK"0D)"0D)=W=W+FMU<F\U:&EN+F]R M9R]S=&]R>2\R,# R+S4O,2\Q-#(S,C$O.34Q,SPO03X\+U1$/@T**PD)"3PO M5%(^#0HK"0D)/%12/@T*( D)"0D\5$0@=D%L:6=N/2)T;W B(&%L:6=N/2)L M969T(B!W:61T:#TB,38E(CX\8CY;/&$@;F%M93TB0V%R8F]N7S R(CY#87)B M;VX@,#(\+V$^73PO8CX\+U1$/@T*( D)"0D\5$0@=D%L:6=N/2)T;W B(&%L M:6=N/2)L969T(B!W:61T:#TB.#0E(CY$879I9"!3/RP@/&D^0F]O<W0@.B!4 M:&4@:&%N9'D@;&EB<F%R>2!O9B -"B )"0D)"0EH86YD>2!L:6)R87)I97,\ M+VD^+B!+=7)O-6AI;BP@2G5L>2 Q."P@,C P,BX@/$$@:')E9CTB:'1T<#HO M+W=W=RYK=7)O-6AI;BYO<F<O<W1O<GDO,C P,B\W+S$X+S,S,3,O,#$T,CDB M/@T*0$ @+3(X,"PV("LR.#8L,34@0$ -"B )"0D)"0EW:71H('1H92!";V]S M="!'<F%P:"!,:6)R87)Y/"]I/BX@26YF;W)M250L($UA<F-H(#$L(#(P,#(N M(#Q!(&AR968](FAT=' Z+R]T:6YY=7)L+F-O;2\R-F1W:B(^#0H@"0D)"0D) M=&EN>75R;"YC;VTO,C9D=VH\+T$^/"]41#X-"B )"0D\+U12/@T**PD)"3Q4 M4CX-"BL)"0D)/%1$('9!;&EG;CTB=&]P(B!A;&EG;CTB;&5F="(@=VED=&@] M(C$V)2(^/&(^6SQA(&YA;64](DQI<V-H;F5R7S S(CY,:7-C:&YE<B P,SPO M83Y=/"]B/CPO5$0^#0HK"0D)"3Q41"!V06QI9VX](G1O<"(@86QI9VX](FQE M9G0B('=I9'1H/2(X-"4B/@T**PD)"0D)/% ^4F%Y($QI<V-H;F5R+" \:3Y# M*RLZ($)E>6]N9"!T:&4@4W1A;F1A<F0@3&EB<F%R>3PO:3XN($\G4F5I;&QY M($YE='=O<FLL($UA>2 V+" -"BL)"0D)"0DR,# S+B \02!H<F5F/2)H='1P M.B\O=W=W+F]R96EL;'EN970N8V]M+VQP="]A+S,V.#,B/G=W=RYO<F5I;&QY M;F5T+F-O;2]L<'0O82\S-C@S/"]!/CPO4#X-"BL)"0D)"3Q0/DUE;G1I;VYS M(#Q#3T1%/G1U<&QE<RP@<VAA<F5D7W!T<BP@;&%M8F1A+"!S<&ER:70\+T-/ M1$4^+@T**PD)"0D)/"]0/@T**PD)"0D\+U1$/@T**PD)"3PO5%(^#0H@"0D\ M+W1A8FQE/@T*( D)/&@R/DAO=R!T;R \82!N86UE/2)U<&1A=&4B/G5P9&%T M93PO83X@=&AI<R!P86=E/"]H,CX-"B )"3QP/E!L96%S92!H96QP('5S(&ME M97 @=&AI<R!P86=E('5P9&%T960@+2!U<V5R<R!C86X@<&]S="!N97<@8VET M871I;VYS('1O('1H92 -"D! ("TS,#0L,3 @*S,Q.2PQ,"! 0 T*( D)/&@R M/CQA(&YA;64](D%C:VYO=VQE9&=E;65N=',B/D%C:VYO=VQE9&=E;65N=',\ M+V$^/"]H,CX-"B @(" @(" @(#QP/D9R961R:6L@0FQO;7%V:7-T('!R;W9I M9&5D(&UA;GD@;V8@=&AE(&EN:71I86P@8VET871I;VYS+CPO<#X-"B )"3QH M<CX-"BT)"3QP/E)E=FES960@,C$@2F%N=6%R>2 R,# T/"$M+7=E8F)O="!B M;W0](E1I;65S=&%M<"(@96YD<W!A;B!I+6-H96-K<W5M/2(S,C(W-R(@+2T^ M/"]P/@T**PD)/' ^4F5V:7-E9" Q,"!&96)R=6%R>2 R,# T/"$M+7=E8F)O M="!B;W0](E1I;65S=&%M<"(@96YD<W!A;B!I+6-H96-K<W5M/2(S,C(W-R(@ M+2T^/"]P/@T*( D)/' ^J2!#;W!Y<FEG:'0@0F5M86X@1&%W97,@,C P,SPO M<#X-"B )"3QP/E5S92P@;6]D:69I8V%T:6]N+"!A;F0@9&ES=')I8G5T:6]N M(&%R92!S=6)J96-T('1O('1H92!";V]S="!3;V9T=V%R92!,:6-E;G-E+" - M"B )"0E697)S:6]N(#$N,"X@*%-E92!A8V-O;7!A;GEI;F<@9FEL92 \02!H M<F5F/2(N+B],24-%3E-%7S%?,"YT>'0B/DQ)0T5.4T5?,5\P+G1X=#PO03X- M"B )"0EO<B!C;W!Y(&%T(#QA(&AR968](FAT=' Z+R]W=W<N8F]O<W0N;W)G M+TQ)0T5.4T5?,5\P+G1X="(^=W=W+F)O;W-T+F]R9R],24-%3E-%7S%?,"YT M>'0\+V$^*3PO<#X-"B )/"]B;V1Y/@T*+3PO:'1M;#X-"EP@3F\@;F5W;&EN <92!A="!E;F0@;V8@9FEL90T**SPO:'1M;#X-"@`` ` end

2 2

Host IP changing Thursday
by Beman Dawes 26 Feb '04

26 Feb '04

The system administrators at Indiana University are planning to change the Boost mailing lists to a new host IP address Thursday. Although the changeover itself will happen very quickly, it will take some time for the DNS change to propagate. Boost's DNS usually specifies 6 hour refreshes and 12 hour "Time to Live". We will cut that to 1 hour each from now until it is clear the change is working well. So you should see no more than a two hour outage. The last time we did something like this it went pretty smoothly, but a few people had trouble with cached copies of the IP address for a few days. Anyhow, be aware that change is coming Thursday, and that mailing list response time will be longer than usual during the changeover. Thanks, --Beman

1 0

Informal review for RTL
by Arkadiy Vertleyb 25 Feb '04

25 Feb '04

Dear Boosters, We would like to ask for an informal review of our Relational Template Library (RTL). In particular we would like to find out whether you think that: 1) relational algebra is a useful instrument for C++ programmers; 2) The solution based on template meta-programming is suitable for such library; 3) RTL itself is a good start, and, with some changes and corrections, can expect to eventially become part of Boost (if not -- why?). Another question we woulld like to ask is which areas do you think might benefit from such library, like, maybe, games, firewalls, etc. The library has been tested with VC7.1 and GCC 3.3. It is located at: http://groups.yahoo.com/group/boost/files/tables.zip Thanks, Arkadiy _________________________________________________________________ Dream of owning a home? Find out how in the First-time Home Buying Guide. http://special.msn.com/home/firsthome.armx

5 6

Re: [boost] [administrative] Formal review procedure
by Cromwell Enage 25 Feb '04

25 Feb '04

Will the procedure be the same for proposed extensions to a library already in Boost (e.g. new algorithms for BGL)? If not, what are the differences? Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools

1 0

RE: [boost] Announcement: Upcoming formal review of FC++
by Powell, Gary 25 Feb '04

25 Feb '04

A quick comment regarding the documentation on monads. If the authors think that the monad stuff is ready for boost, the documentation should come with it and not reside on the FC++ web site. Other than that the documents look good... on to the code.. -Gary-

1 0

borland workaround needed
by Gennadiy Rozental 25 Feb '04

25 Feb '04

Hi, Could anybody suggest workaround for Internal error I am getting when trying to compile using Borland command line tools with following code: template<class PropertyType> class class_property { protected: PropertyType value; }; template<class PropertyType> class readwrite_property : public class_property<PropertyType> { typedef class_property<PropertyType> base; using base::value; // <------- right here }; Gennadiy.

2 3

RE: [boost] Re: boost::any: explicit constructor?
by Bjorn.Karlsson＠readsoft.com 25 Feb '04

25 Feb '04

> From: Edward Diener [mailto:eddielee@tropicsoft.com] > > The intention was to call do_somethin on 'v.value()' but > non-explicit > > ctor is happy to accept 'variable', after which > 'do_something' breaks. > > This is a programming error, not an error in boost::any. Absolutely, but it's an error that could have been detected by the compiler given an explicit constructor. [snip] > While I am not against syntactic sugar which make it > easier to use > C++ constructs, I am against making a constructor explicit > just to keep > programmers from making errors. Isn't keeping programmers from making errors a Good Thing? For me, that's exactly the reason why boost::any's constructor _should_ be explicit. Bjorn

1 0

Re: The art of naming namespaces [was: Re: algorithms namespace]
by Bjorn.Karlsson＠readsoft.com 25 Feb '04

25 Feb '04

> From: Thorsten Ottosen [mailto:nesotto@cs.auc.dk] > > * Some names work "best" in plural (like signals, > type_traits, iterators, > > operators); this is of course very much IMHO. > > are they the names of namespaces? Signals is (and type_traits has such a namespace [albeit only in detail]), the others are the library names (living in the root boost:: namespace). > > * Just "file" seems a bit restrictive to me, but when I > think about the > > namespace "files" I read "files 'n other related stuff, too". > > then maybe it should be namespace io? Just like a big namespace for > algorithms, io > could hold file handling, zip streams, formatters etc. Yes, that's definitely an interesting option. Bjorn

1 0

boost::any: explicit constructor?
by Vladimir Prus 25 Feb '04

25 Feb '04

Hi, I just had a couple of bugs caused by the fact that constructor of boost::any is not explicit. For example: void do_something(boost::any& v) { ... } class variable { ///// boost::any& value() {} }; variable v; do_something(v); The intention was to call do_somethin on 'v.value()' but non-explicit ctor is happy to accept 'variable', after which 'do_something' breaks. Anybody has an opinion? Is non-explicit ctor really necessary? - Volodya

2 1

[config] fix for BCB and BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by Pavel Vozenilek 25 Feb '04

25 Feb '04

I believe config macro BOOST_NO_MEMBER_TEMPLATE_FRIENDS should be defined for BCB 6. Currently it is defined only for BCB 5.5.1 and less but with BCB 6: - compiling test file boost_no_mem_templ_frnds.cxx fails, - the problem shows in Serialization library too. So I recommend to change borland.hpp to define this macro for BCB 6 (and likely for Kylix which is simply BCB6 ported to Linux). BCB6 patch 4 == 0x564 Kylix = 0x570 /Pavel

2 3

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 25 Feb '04

25 Feb '04

> From: Daniel Frey [mailto:daniel.frey@aixigo.de] > > > > Well, you came up with the 2-arg version. > > That was Daniel Wallin (too many Daniels error?). I guess this also > explains why I had the feeling we were talking past each > other a bit :) Heh, according to the docs it was Daniel Walker. This name-calling is getting interesting. ;-) Bjorn

1 0

Re: [utility] question on prior(x,n)
by Bjorn.Karlsson＠readsoft.com 25 Feb '04

25 Feb '04

> From: David Abrahams [mailto:dave@boost-consulting.com] > > See counting_iterator for inspiration as to why this might be useful. Got it, thanks. Perhaps these type requirements should be spelled out in the docs (proposed patch below)? And maybe is_full_iterator_traits in detail/iterators.hpp could be slightly changed and turned into a first-class traits "is_iterator", which would then be used for dispatching next/prior calls to std::advance when applicable? Although this would work, I'm not sure that the added dependencies and complexity are worth it - if possible, I think that dropping the two-argument versions of next and prior would be best. Bjorn [Note: The most interesting change to the doc are the following four lines. <p>The one-argument version of next() and prior() can be used with any type that provides operator++() and operator--(), respectively. The two-argument version of next() and prior() can be used with any type that provides operator+() and operator-(), with the exception of iterator types, which only require operator++() and operator--() for both versions.</p> ] *** utility.htm.orig Wed Feb 25 11:47:07 2004 --- utility.htm Wed Feb 25 11:48:17 2004 *************** *** 41,61 **** T next(T x) { return ++x; } template <class T, class Distance> ! T next(T x, Distance n) ! { ! std::advance(x, n); ! return x; ! } template <class T> T prior(T x) { return --x; } template <class T, class Distance> ! T prior(T x, Distance n) ! { ! std::advance(x, -n); ! return x; ! }</pre> </blockquote> <p>Usage is simple:</p> <blockquote> --- 41,54 ---- T next(T x) { return ++x; } template <class T, class Distance> ! T next(T x, Distance n); template <class T> T prior(T x) { return --x; } template <class T, class Distance> ! T prior(T x, Distance n); ! </pre> </blockquote> <p>Usage is simple:</p> <blockquote> *************** *** 66,71 **** --- 59,68 ---- <p>The distance from the given iterator should be supplied as an absolute value. For example, the iterator four iterators prior to the given iterator <code>p</code> may be obtained by <code>prior(p, 4)</code>.</p> + <p>The one-argument version of next() and prior() can be used with any type that provides + operator++() and operator--(), respectively. The two-argument version of next() and prior() + can be used with any type that provides operator+() and operator-(), with the exception of + iterator types, which only require operator++() and operator--() for both versions.</p> <p>Contributed by <a href="../../people/dave_abrahams.htm">Dave Abrahams</a>. Two-argument versions by Daniel Walker.</p> <h2><a name="Class_noncopyable">Class noncopyable</a></h2> <p>Class <strong>noncopyable</strong> is a base class.  Derive your own class

1 0

XSL regression reporting changes
by Misha Bergal 25 Feb '04

25 Feb '04

I have checked in the modifications to split the failed test logs HTML file (links.html) into on HTML file per test log. The regression testers using xsl_reports will need to update their upload scripts. -- Misha Bergal MetaCommunications Engineering

1 0

warning when using borland toolset
by Gennadiy Rozental 25 Feb '04

25 Feb '04

I am getting following warning when I try to compile using Borland toolset: ...boost\tools/build\v1\borland-tools.jam:182: in include-tools warning: unknown rule W32_GETREG ...boost\tools/build\v1\boost-base.jam:760: in relevant-features ...boost\tools/build\v1\boost-base.jam:828: in select-properties ...boost\tools/build\v1\boost-base.jam:799: in variant ...boost\tools/build\v1\features.jam:179: in boost-build ...boost\boost-build.jam:16: in module scope ...boost\tools/build\v1\borland-tools.jam:182: in include-tools (actually repeated multiple times) any suggestions? Gennadiy

2 1