- Boost - lists.preview.boost.org

[program_options, function] vc7 problem
by Vladimir Prus 25 Jun '04

25 Jun '04

The regression logs show this error message from vc7 http://tinyurl.com/39fgc which says that pointer to function can be converted to boost::function The relevant code is: int stored_value; void notifier(const vector<int>& v) { stored_value = v.front(); } void test_semantic_values() { .... ("int", po::value< vector<int> >()->notifier(notifier)) ; } Where the 'notifier' member function is defines as: typed_value* notifier(function1<void, const T&> f) and in this case, T = vector<int>. Any ideas what I can do to make this work? - Volodya

3 3

The Test Tools Docs, Concept Checking
by Andy Little 25 Jun '04

25 Jun '04

Hi, I have been reading the Test Tools docs. Would it be a good idea to add ConceptChecking to the list of alternative methods of reporting errors, in /test/doc/index.html#introduction ? A recent post on boost alluded to the fact that Concepts (ie What is a concept? ) can be difficult to understand. Well ... ConceptChecks are the medium for pinning down Concepts in C++ code and are probably the most effective means of error reporting at compile time, but are not used as much as they could be. The Boost Test Library would seem to be as good a place as any to promote them, which could help to remove some of the mystery. regards Andy Little

1 0

(no subject)
by Robert Ramey 25 Jun '04

25 Jun '04

BOOST_STATIC_ASSERT - On occasion I find it convenient to use: BOOST_STATIC_ASSERT(false) In templated code that should be unreachable. However, its doesn't work with compilers that are too smart for their own good. In order to make this work I need something like: BOOST_STATIC_ASSERT(boost::false_<T>::value) Where boost::false<T> is a type that yields false for any type T. Am I correct here? Where should such a code snippet be placed? Could it be added to mpl, type_trait or what? Robert Ramey

4 3

Re: [boost] 1.32 release preparation
by Reece Dunn 25 Jun '04

25 Jun '04

Mathew Robertson wrote: > > > To allow the autoconf tools (ie configure) to detect the presence of >the various Boost libs and header file versions, would it be possible to >add a C-linkage function to each libraries' source file(s). This would >allow users to add a configure check which detects if a particular library >instance is installed. For example, we add the following code to each >library instance: > > > > > > extern "C" boost_autoconf() {} > > > > > > This allows autoconf users to add a test to their configure.in script: > > > > > > AC_CHECK_LIB(boost_regex,boost_autoconf,...,[Boost::Regex library >not found]) > > > > I don't see why you need a function with C linkage for this to work. > > The behavior of autoconf depends on the current language specified > > in configure.ac at the point where you call AC_CHECK_LIB. If that >language > > is C++, you should well be able to test for functions with C++ linkage. > > See >http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_chapter/auto… > >Yeah - thats what I'm trying to do. Specifically, I'm trying to detect if >"libboost_regex..." is installed, so I have the following: > >AC_CHECK_LIB(boost_regex-gcc,<somefunc>,,AC_ERROR([Must have the >Boost::Regex library installed]) > >Now the problem is, 'What do I put in for <somefunc>?' All other C++ >libraries I have used, specifically contain a C-linkage function to allow >configure to detect it. I am not familiar with the autoconf tool, but is it possible to have something like this: // include_test.cpp #include <boost/regex.hpp> int main() { // simple regex use here return( 0 ); } //--end That way, you'd get a compile error if regex.hpp is not found (Boost is not on the system) or a link error if the library is not available (library hasn't been built or configured). I am not sure how this translates to autoconf: have you had a look to see how GCC checks for stdio.h, etc.? Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Boost.Variant concepts and LessThanComparable documentation
by Guillaume Melquiond 25 Jun '04

25 Jun '04

Hi, Looking through the documentation of Boost.Variant (both 1.31 and cvs versions), I see that "variant is itself LessThanComparable if and only if every one of its bounded types meets the requirements of the concept". The documentation directly hyper-links to the concept part of Boost and this concept description explains that "LessThanComparable types must have <, >, <=, and >= operators". Unfortunately, boost::variant implementation only defines operator<. So here we have a contradiction between the implementation and the interface. The same kind of problem arises with operator!= and the EqualityComparable concept. I am not sure what the best solution is: - define the missing operators in boost::variant, - remove any reference to LessThanComparable and EqualityComparable concepts from boost::variant documentation, - correct the concepts so they only speak about operator< and operator==. The last solution corresponds to the way the concepts are defined in the [lib.utilities] part of the C++ standard. But I would rather see the missing operators defined in boost::variant if possible. Regards, Guillaume

2 1

Child processes
by Angus Leeming 25 Jun '04

25 Jun '04

I am in the process of writing a little library to control the interaction of a parent program with any child processes that it spawns. Would there be any interest in such a library here? Assuming that there would, please excuse me diving in at the deep end. I'm currently mulling over how best to ensure that system resources are cleaned up automatically when the child exits and would value some advice. Under unix, I've defined a handler for SIGCHLD signals. The handler does two things only: * reaps the zombie * stores the return status in a std::map<pid_t, int> completed_children; variable. Each time a new child is spawned, the pid of the child process is registered in the map, so the handler needs do nothing other than find the entry. namespace { std::map<pid_t, int> completed_children; int status; sig_atomic_t pid; } extern "C" void child_handler(int) { pid = wait(&status); std::map<pid_t, int>::iterator it = completed_children.find(pid); if (it != completed_children.end()) it->second = status; } I'm pretty sure that the above is safe code. It does the absolute minimum in the handler routine. wait() is guaranteed to be async-safe. Moreover, the handler receives only SIGCHLD signals and so cannot receive multiple calls simultaneaously. However, I'm unsure whether it Ok to search the map like this. Any advice? My one other worry is that the SIGCHLD handler could be redefined elsewhere in the code, but AFAICS there's nothing that I can do about that. Furthermore, it means only that the user of my Child library won't be able to ascertain the exit status of child processes launched using it. (If the zombie is reaped elsewhere then a subsequent call to waitpid(pid, &status, WNOHANG); will result in errno being set to ECHILD. Ie, I'll know that the child process has ended but just won't know its exit status.) Under windows, I'm proposing to use a separate thread to wait() for each child process. This seems to be the standard way of dealing with the problem, but I'm a total novice when it comes to Windows programming so know only what I've read. Again, any advice would be greatly appreciated. Regards, Angus

9 24

[1.32 Plan] uBLAS preperation
by Michael Stevens 24 Jun '04

24 Jun '04

Hi Aleksey, Thanks for the clear plan. The current status of uBLAS is that it has been relatively untouched in the Boost CVS single 1.30.0. The active development takes place on a separate CVS. Therefore now would be a good time to bring in the latest code which as some quite significant improvements. The code is relatively stable and tested on core compilers. Issues: On exotic (old) compiler the code is relatively untested and expected to fail. Therefore the real need with regard to 1.32 is to get feedback from extensive regression testing results in good time. As ever the documentation could do with further work to bring it up to date with the to be release version. Thanks, Michael ___________________________________ Michael Stevens Systems Engineering 34128 Kassel, Germany Phone/Fax: +49 561 5218038 Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

Numeric Conversions Library added to CVS
by Fernando Cacciola 24 Jun '04

24 Jun '04

Hi All, In preparation for the upcoming 1.32 release I added this library to CVS. The code and docs have been changed according to the extensive review results. I still need to extend the documentation adding examples and motivating cases though, which I plan to do before the release. I haven't yet changed "boost/cast.hpp" to use the new stuff, I will as soon as I see the code stablilized among different compilers. In the meantime, new users can use "boost/numeric/conversion/cast.hpp" which contains the new version of numeric_cast<> Best Fernando Cacciola SciSoft

2 1

RE: [boost] (no subject)
by Michiel Salters 24 Jun '04

24 Jun '04

Would BOOST_STATIC_ASSERT( (T*) 0 ) work for you ? Regards, Michiel Salters. > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Robert Ramey > Sent: donderdag 3 juni 2004 22:29 > To: boost(a)lists.boost.org > Subject: [boost] (no subject) > > > BOOST_STATIC_ASSERT - > > On occasion I find it convenient to use: > > BOOST_STATIC_ASSERT(false) > > In templated code that should be unreachable. However, its > doesn't work > with compilers that are too smart for their own good. In > order to make this > work I need something like: > > BOOST_STATIC_ASSERT(boost::false_<T>::value) > > Where boost::false<T> is a type that yields false for any type T. > > Am I correct here? Where should such a code snippet be > placed? Could it be > added to mpl, type_trait or what? > > Robert Ramey > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Any scheduled date for Boost 1.32?
by Joaquín Mª López Muñoz 24 Jun '04

24 Jun '04

Aleksey talked about June 28th: http://lists.boost.org/MailArchives/boost/msg62871.php but seems like there has been no activity wrt to releasing Boost 1.32 since. Is that date still valid? I guess it is not, for the one week remaining is probably to little time to arrange everything. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

7 7

Boost.Python / Graph library problem after cvs update
by Ralf W. Grosse-Kunstleve 24 Jun '04

24 Jun '04

With the latest Boost CVS compilation of boost/libs/python/src/object/inheritance.cpp with the old IRIX MIPSpro compiler (EDG 238) fails for this code in boost/boost/graph/properties.hpp: namespace detail { template<typename VertexBundle, typename EdgeBundle> type_traits::yes_type is_vertex_bundle_helper(VertexBundle*); template<typename VertexBundle, typename EdgeBundle> type_traits::no_type is_vertex_bundle_helper(EdgeBundle*); template<typename VertexBundle, typename EdgeBundle, typename Bundle> struct is_vertex_bundle { BOOST_STATIC_CONSTANT(bool, value = ((sizeof(is_vertex_bundle_helper<VertexBundle, EdgeBundle>((Bundle*)0)) == sizeof(type_traits::yes_type)))); }; } The error is: cc-1278 CC: ERROR File = /txusr/rwgrosse/hot/boost/boost/graph/properties.hpp, Line = 363 No instance of overloaded function "boost::detail::is_vertex_bundle_helper" matches the argument list. The argument types are: (Bundle *). BOOST_STATIC_CONSTANT(bool, value = ((sizeof(is_vertex_bundle_helper<VertexBundle, EdgeBundle>((Bundle*)0)) ^ I tried to rearrange the code a bit: namespace detail { template<typename VertexBundle, typename EdgeBundle> struct is_vertex_bundle_helper { static type_traits::yes_type get(VertexBundle*); static type_traits::no_type get(EdgeBundle*); }; template<typename VertexBundle, typename EdgeBundle, typename Bundle> struct is_vertex_bundle { typedef is_vertex_bundle_helper<VertexBundle, EdgeBundle> helper_t; BOOST_STATIC_CONSTANT(bool, value = ((sizeof(helper_t::get((Bundle*)0)) == sizeof(type_traits::yes_type)))); }; } This still compiles with other compilers (gcc 3.4 and EDG 245), but not with the old EDG 238: cc-1108 CC: ERROR File = /txusr/rwgrosse/hot/boost/boost/graph/properties.hpp, Line = 368 The indicated expression must have pointer-to-function type. BOOST_STATIC_CONSTANT(bool, value = ((sizeof(helper_t::get((Bundle*)0)) == sizeof(type_traits::yes_type)))); ^ It doesn't even compile if I simplify the code like this: cc-1108 CC: ERROR File = /txusr/rwgrosse/hot/boost/boost/graph/properties.hpp, Line = 371 The indicated expression must have pointer-to-function type. static const std::size_t value1 = sizeof(helper_t::get((Bundle*)0)); ^ 1 error detected in the compilation of "/txusr/rwgrosse/hot/boost/libs/python/sr I am lost here. Suggestions for workarounds are very much appreciated. It used to compile with the CVS from a couple of days ago. It is important to us to get the IRIX build working again. Thanks in advance, Ralf P.S.: inheritance.cpp compiles if I simply set BOOST_STATIC_CONSTANT(bool, value = false); Therefore I was hopeful that the problem can be fixed by rearranging the code fragments shown above. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

3 5

Boost.Threads inconsistency question
by Michael Glassford 23 Jun '04

23 Jun '04

The Boost.Threads documentation states that the ScopedTimedLock concept is a refinement of the ScopedTryLock concept; however, the boost::timed_mutex::scoped_timed_lock class, which is supposed to be a model of the ScopedTimedLock concept, doesn't define the various try_* methods. In your opinion, should the documentation be changed to state that the ScopedTimedLock concept is a refinement of the ScopedLock (rather than ScopedTryLock) concept, or should the boost::timed_mutex::scoped_timed_lock class implement the various try_* methods? (FYI: a similar situation applies to boost::recursive_timed_mutex::scoped_timed_lock and boost::timed_read_write_mutex::scoped_timed_lock). Mike

2 3

problem with boost::thread
by Janusz Piwowarski 23 Jun '04

23 Jun '04

Hello. After latest cvs update, i've got errors like: gcc-C++-action bin\boost\libs\thread\build\boost_thread.dll\mingw\debug\threading-multi\con dition.obj In file included from d:/sources/boost/libs/thread/src/condition.cpp:18: d:/sources/boost/libs/thread/src/timeconv.inl: In function `void <unnamed>::to_time(int, boost::xtime&)': d:/sources/boost/libs/thread/src/timeconv.inl:24: error: template-argument ` boost::<anonymous enum>' uses anonymous type d:/sources/boost/libs/thread/src/timeconv.inl: In function `void <unnamed>::to_duration(boost::xtime, int&)': d:/sources/boost/libs/thread/src/timeconv.inl:92: error: template-argument ` boost::<anonymous enum>' uses anonymous type d:/sources/boost/libs/thread/src/timeconv.inl: In function `void <unnamed>::to_microduration(const boost::xtime&, int&)': d:/sources/boost/libs/thread/src/timeconv.inl:114: error: template-argument ` boost::<anonymous enum>' uses anonymous type "g++" -c -Wall -ftemplate-depth-100 -DBOOST_THREAD_BUILD_DLL=1 -g -O0 -f no-inline -mthreads -mthreads -mno-cygwin -I"bin\boost\libs\thread\build" -I"d:\sources\boost" -o "bin\boost\libs\thread\build\boost_thread.dll\mingw\debug\threading-multi\co ndition.obj" "d:\sources\boost\libs\thread\build\../src/condition.cpp" Error lines in timeconv.inl file contains: assert(res == boost::TIME_UTC) where res is int, and boost::TIME_UTC is enum. When i changed it to assert(res == static_cast<int>(boost::TIME_UTC)); it starts to compile. But I don't understand what's happend, there aren't changes in boost::thread. Any ideas? WinXP, mingw 3.3.1 Regards, Janusz

3 5

shared_ptr with dynamic_cast
by Yuval Ronen 23 Jun '04

23 Jun '04

Hi, I'm new to boost, so this post might seem silly to some of you, and I apologize if this is the case. I have a tiny performance suggestion: The c'tor template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::dynamic_cast_tag): px(dynamic_cast<element_type *>(r.px)), pn(r.pn) { if(px == 0) // need to allocate new counter -- the cast failed { pn = detail::shared_count(); } } should be changed to: template<class Y> shared_ptr(shared_ptr<Y> const & r, detail::dynamic_cast_tag): px(dynamic_cast<element_type *>(r.px)), pn(px ? r.pn : detail::shared_count()) { } The difference is when the dynamic_cast fails and returns NULL. In such cases the existing code copies the shared_count object, including mutex locking, only to discover later that it was unnecessary (the 'if(px == 0)' statement). The suggested code saves this copy of the shared_count object, which also saves some mutex lockings. Hope I'm not talking nonsense, Yuval

2 1

min/max, reloaded
by Eric Niebler 23 Jun '04

23 Jun '04

I have ripped out the std_min/std_max functions. They were a less-than-perfect solution to the problems caused by the min/max macros defined by some platform headers. I have fixed all the places in the Boost affected by this change, and I have also updated the coding guidelines. For your references, the guidelines are reproduced here: Make sure your code compiles in the presence of the min() and max() macros. Some platform headers define min() and max() macros which cause some common C++ constructs to fail to compile. Some simple tricks can protect your code from inappropriate macro substitution: If you want to call std::min() or std::max(): If you do not require argument-dependent look-up, use (std::min)(a,b). If you do require argument-dependent look-up, you should: #include <boost/minmax.hpp> Use BOOST_USING_STD_MIN(); to bring std::min() into the current scope. Use min BOOST_PREVENT_MACRO_SUBSTITUTION (a,b); to make an argument-dependent call to min(a,b). If you want to call std::numeric_limits<int>::max(), use (std::numeric_limits<int>::max)() instead. If you want to call a min() or max() member function, instead to doing obj.min(), use (obj.min)(). If you want to declare or define a function or a member function named min or max, then you must use the BOOST_PREVENT_MACRO_SUBSTITUTION macro. Instead of writing int min() { return 0; } you should write int min BOOST_PREVENT_MACRO_SUBSTITUTION () { return 0; } This is true regardless if the function is a free (namespace scope) function, a member function or a static member function, and it applies for the function declaration as well as the function definition. Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

3 4

Boost.Config defect macro proposal
by Joaquín Mª López Muñoz 23 Jun '04

23 Jun '04

Some months ago I proposed to include a defect macro to detect some defficiencies by several compilers regarding the ability to handle pointers to data members as template parameters. The name we came up with is BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS I include a little test case that successfully detects the bug in three out of the four compilers checked to show the problem * MSVC 6.5 (MSKB article ##249045), * MSVC 7.0 (***) * ICC 7.0/7.1 for Windows (support issue #207321), * VisualAge 6.0 for AIX (internal defect #288539.) The compiler marked with (***) does fail with the test, but only under certain compiler settings that I've not been able to isolate properly. When last discussed, it was argued that a new defect macro would only make sense if some lib needed it: now Boost.MultiIndex can take advantage of it (actually, the lib assumes the macro even if not currently supported by Boost.Config), and the problem has turned out to be more prevalent than the original MSVC-constrained case hinted at. Is it OK to add this to Boost.Config? Comment? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo *** BEGIN TEST CODE*** #include <iostream> struct pair { int x,y; pair(int x_,int y_):x(x_),y(y_){} }; template<int pair::* PtrToPairMember> struct foo { int bar(pair& p){return p.*PtrToPairMember;} }; int main() { pair p(0,1); foo<&pair::x> fx; foo<&pair::y> fy; if(fx.bar(p)!=0||fy.bar(p)!=1)std::cout<<"KO"<<std::endl; else std::cout<<"OK"<<std::endl; return 0; } ***END TEST CODE***

4 5

Generalized Iterator Ranges
by Dale Muchow 23 Jun '04

23 Jun '04

Here is a paper I wrote discussing the notion of generalizing an iterator defined range. It includes the proposal and definition of a new concept, Range. It was written as a masters research paper for graduate work I did at North Dakota State University. http://www.lycanth.com/dmuchow/GeneralizedIteratorRanges.doc.zip _________________________________________________________________ >From will you? to I do, MSN Life Events is your resource for Getting Married. http://lifeevents.msn.com/category.aspx?cid=married

2 1

[Graph] Bundled properties, take 2
by Douglas Paul Gregor 23 Jun '04

23 Jun '04

Good evening, I've just checked in version 2 of the "bundled properties" patch for the BGL, which allows one to stick various vertex/edge properties into a class to be stored within adjacency_list/adjacency_matrix. Accessing these properties is easier and more convenient. This patch completes support for bundled properties. Both of the major graph types are supported, bundled properties play nice with other property maps (get/put support added), and bundled properties work with graph adaptors. The documentation now strongly urges users to adopt bundled properties instead of property lists :) Doug

2 1

RE: [boost] Child processes
by Glen Knowles 23 Jun '04

23 Jun '04

> I don't know how java deals with this but on posix platforms > a sub-process holds some resources that have to be claimed > back by the parent process. > This includes (but is not restricted to) the result of the > process, i.e. > its return value. In case you are familiar with (posix) > threads: there you have to join a thread after it terminated. > It's conceptually the same thing here. > If you find yourself joining posix's threads only for this reason you should consider setting the detachstate attribute to PTHREAD_CREATE_DETACHED instead. Glen

1 0

RE: [boost] Re: static sized strings
by Reece Dunn 22 Jun '04

22 Jun '04

John Nagle wrote: >Reece Dunn wrote: >>John Nagle wrote: >>The problems arise in the interation with basic_string_impl and how to >>implement swap and functions that require constructing a string object. >Why do you need to construct a string object to swap? >Just swap one character at a time. There were 3 things I was cxonsidering when moving to the non-virtual implementation: [1] How do I pass the buffer and capacity to the implementation while allowing both fixed_string_base and fixed_string access to the basic_string interface? I have chosen to route the data through one of the basic_string constructors, requiring a const_cast. This is the best approach AFAICS. [2] How do I implement the swap function? The solution I arrived at is the one you suggest: to swap the data character-by-character. What you have to consider when doing this is that the strings don't exceed capacity, resulting in additional logic. [3] How do I approach the substr function and the + operators? Although it is now possible to construct a fixed_string_base object from a fixed_string object, you will run into problems when constructing from a temporary (because the fixed_string temporary will have been destroyed, invalidating the buffer). Given this, the implementation of these functions are still in fixed_string and thus not accessible to [w]char_string. I have replaced the old implementation with this one in the sandbox if you want to take a look. Also, feel free to adapt it to your version if you want. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 2

Re: [boost] Re: static sized strings
by Reece Dunn 22 Jun '04

22 Jun '04

Rob Stewart wrote: >From: "Reece Dunn" > > John Nagle wrote: > > >Reece Dunn wrote: > > >>John Nagle wrote: > > >>The problems arise in the interation with basic_string_impl and how to > > >>implement swap and functions that require constructing a string >object. > > >Why do you need to construct a string object to swap? > > >Just swap one character at a time. > > > > [2] How do I implement the swap function? The solution I arrived at is >the > > one you suggest: to swap the data character-by-character. What you have >to > >Unfortunately, that makes swap() O(N), but it does allow it to be >nothrow. Unfortunately. To swap the impl members would make it O(1), but would lead to unpredictable behaviour since the two strings swap pointers to their fixed_string buffers. The approach I use is the best I could find. > > consider when doing this is that the strings don't exceed capacity, > > resulting in additional logic. > >That should fail, shouldn't it? Yes, that would mean a swap() >that throws, but the strings aren't really swapped if you only >swap some characters. The same is true though of all the other functions (e.g. assign): what happens if the string doesn't fit? >I'm not sure which is worse: a swap() that throws or only >partially swapping. The former violates exception safety >guarantee assumptions made by other code, but the latter means >that swap() may not really swap, which violates semantics. I have gone for a clip to capacity design for all the fixed_string functions. Thus: fixed_string< 5 > str; str.assign( "Hello there!" ); // str == "Hello" Any error handling policy that is implemented has it's own advantages and disadvantages. Another problem with using exceptions is adapting C code: there may not be any try-catch blocks in the code, resulting in unhandled exceptions. The clip strategy is not ideal either, but I believe it is the best approach considering the code it is abstracting: you will usually have a buffer large enough for the application you are using it for (filenames/paths, command line strings, URLs, etc.) One possibility is making the error handling a policy class so it can be adapted to suit the users needs with the current behaviour as default. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

RE: [boost] [test] [minmax] failure on gcc 2.95
by Rozental, Gennadiy 21 Jun '04

21 Jun '04

> As shown in http://tinyurl.com/3xdyq, > Boost.Test fails to build on gcc 2.95 with stlport. The error > message is: > > /boost/head-regression/boost/boost/minmax.hpp: In function > `const size_t & boost::std_min<size_t>(const size_t &, const > size_t &)': > > /boost/head-regression/boost/libs/test/build/../src/test_tools > .cpp:375: instantiated from here > /boost/head-regression/boost/boost/minmax.hpp:26: `min' > undeclared (first use this function) > > Is it possible that authors of either Boost.Test or > boost/minmax.hpp take care of this error? I'd prefer it to be addressed on minmax.hpp level. After all it's the header responsible for min and max. Gennadiy.

3 3

Typo in boost/graph/properties.hpp
by Janusz Piwowarski 20 Jun '04

20 Jun '04

Hello, I'm attaching patch, as in subject. Also, there isn't undefined variable x in boost/graph/graph_test.hpp (test_readable_vertex_property_graph and test_vertex_property_graph templates). I have no idea what it is. Regards, Janusz

2 1

threads
by val salamakha 20 Jun '04

20 Jun '04

Dear William E. Kempf, I installed the latest version of the boost-1.31.0 on Win xp pro with vc7.1 and tried to use the thread library. During the first build of several samples, MSVS(vc71) gave me a warning about the errors. However I ignored the errors and select option to proceed(the same result is in other case). It seems to me the samples work correctly in spite of errors and warning located below my message. I had no warning or errors on the next build of the same sample at all. Would you please tell me what is going on? And how do I fix it? Thanks Valery Salamakha VC71_ROOT\include\stdexcept(14): see declaration of 'std::logic_error' c:\Boost\include\boost-1_31\boost\thread\exceptions.hpp(28) : see declaration of 'boost::lock_error' c:\Boost\include\boost-1_31\boost\thread\thread.hpp(78): warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' with [ _Ty=boost::thread * ] c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(36): warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::mutex' c:\Boost\include\boost-1_31\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(35) : see declaration of 'boost::mutex' c:\Boost\include\boost-1_31\boost\thread\thread.hpp(38): warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread' c:\Boost\include\boost-1_31\boost\thread\thread.hpp(67): warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread_group' c:\Boost\include\boost-1_31\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(114): warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::timed_mutex' c:\Boost\include\boost-1_31\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(113) : see declaration of 'boost::timed_mutex' c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(74): warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::try_mutex' c:\Boost\include\boost-1_31\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\Boost\include\boost-1_31\boost\thread\mutex.hpp(73) : see declaration of 'boost::try_mutex' c:\Boost\include\boost-1_31\boost\thread\exceptions.hpp(29): warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' c:\Boost\include\boost-1_31\boost\thread\exceptions.hpp(35): warning C4275: non dll-interface class 'std::runtime_error' used as base for dll-interface class 'boost::thread_resource_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(136) : see declaration of 'std::runtime_error' c:\Boost\include\boost-1_31\boost\thread\exceptions.hpp(34) : see declaration of 'boost::thread_resource_error' __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

5 10

RE: [boost] Re: static sized strings (struct hack)
by Reece Dunn 20 Jun '04

20 Jun '04

John Nagle wrote: >Reece Dunn wrote: >>John Nagle wrote: >>> I think we're back to using an abstract base class. >>>The hacks to get around it introduce worse problems. >>I would agree. I have been trying to find a way around the problem and >>have (sortof) by having a base class: >> >> template< typename CharT > >> class string_base >> { >> private: >> size_t len, cap; // length & capacity >> CharT * buf; // data buffer >> public: >> string_base( CharT * b, size_t c, size_t l ): >> len( l ), cap( c ), buf( b ){} >> // non-virtual implementation >> }; >> >> template< size_t n, typename CharT > >> class fixed_string: public string_base >> { >> private: >> CharT data[ n + 1 ]; >> public: >> fixed_string(): string_base( data, n + 1 ){} >> }; >That's a much better approach than the previous one. >It's sound C++, and it's simple. >All the operations go in string_base. fixed_string >need only allocate space. Where do you hit a problem? The problems arise in the interation with basic_string_impl and how to implement swap and functions that require constructing a string object. Both string_base and fixed_string must operate through basic_string_impl to allow basic_string operations. I suppose this should be done in a heirarchy similar to the current one, having swap virtual (you don't want to swap internal pointers!) and using the current system for the object construction functions, but it may be possible to have substr virtual, I'm not sure yet. I shall have a go at this and report back when I have a working implementation. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

[Boost-bugs] [ boost-Bugs-976241 ] Compiler error for tokenizer on Solaris
by SourceForge.net 20 Jun '04

20 Jun '04

Bugs item #976241, was opened at 2004-06-20 13:51 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=976241&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tom Aratari (stosys) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler error for tokenizer on Solaris Initial Comment: When trying to upgrade to boost 1_31, Forte 8.0 (CC: Sun C++ 5.5 Patch 113817-03 2003/10/14) gives the following error for the code snip: typedef boost::tokenizer<boost::char_separator<char> > tokenizer; boost::char_separator<char> seperator (sDroppedDelimiters, sKeptDelimiters, boost::keep_empty_tokens); tokenizer tokens( sString, seperator ); for (tokenizer::iterator tok_iter = tokens.begin(); tok_iter != tokens.end(); ++tok_iter) vInVector.push_back( *tok_iter ); Copiler error: "/home/dev/cm/THIRD_PARTY/boost/include/boost/iterat or/iterator_facade.hpp", line 623: Error: Could not find a match for boost::iterator_core_access::equal<boost::iterator_core _access::Facade1, boost::iterator_core_access::Facade2>(const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::is_convertible<boost::token_iterator<boost::char _separator<char, std::char_traits<char>>, const char*, std::string>, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>>). "MDSStringHelpers.cxx", line 183: Where: While instantiating "boost::operator! =<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string,boost::forward_traversal_tag, const std::string &, int, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>(const boost::iterator_facade<boost::token_iterator<boost::cha r_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>&, const boost::iterator_facade<boost::token_iterator<boost::cha r_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>&)". "MDSStringHelpers.cxx", line 183: Where: Instantiated from non-template code. Has anyone else complianed about this? Thanks Tom ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=976241&group_i… ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Another BoostBook/Doxygen bug?
by Angus Leeming 18 Jun '04

18 Jun '04

Is it possible to get the BoostBook/Doxygen documentation system to include my commentary? This is the header file #include <boost/child/detail/pipe_mode.hpp> namespace boost { namespace child { /// A stateless class providing constants and typenames. struct pipes_base { /// A type used to specify how to communciate with the child process. typedef detail::pipe_mode pipe_mode; /// Write to the child's standard input stream. static const pipe_mode child_stdin = pipe_mode(1); /// Read from the child's standard output stream. static const pipe_mode child_stdout = pipe_mode(2); /// Read from the child's standard error stream. static const pipe_mode child_stderr = pipe_mode(4); /// Redirect the child's stderr to its stdout. static const pipe_mode redirect_child_stderr = pipe_mode(8); /// No pipes are to be used. static const pipe_mode no_pipes = pipe_mode(16); }; } // namespace child } // namespace boost And below is the generated documentation. See how all the descriptions of the constants have dissappeared. Also see how the typedef has been 'modified'. Regards, Angus Struct pipes_base boost::child::pipes_base ? A stateless class providing constants and typenames. Synopsis struct pipes_base { // types typedef unspecified pipe_mode; // A type used to specify how to communciate with the child process. static const pipe_mode child_stdin; static const pipe_mode child_stdout; static const pipe_mode child_stderr; static const pipe_mode redirect_child_stderr; static const pipe_mode no_pipes; };

2 3

[Test] Link problems
by David B. Held 18 Jun '04

18 Jun '04

unit_test_log.o: In function `boost::unit_test::unit_test_log::unit_test_log[not-in-charge]()': /usr/include/c++/3.3.2/bits/stl_heap.h:221: undefined reference to `boost::unit_test::ut_detail::msvc65_like_log_formatter::msvc65_like_log_for matter[in-charge] (boost::unit_test::unit_test_log const&)'unit_test_log.o: In function `void std::__adjust_heap<__gnu_cxx::__normal_iterator<std::pair<boost::unit_test:: basic_cstring<char const>, boost::unit_test::output_format>*, std::vector<std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format>, std::allocator<std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format> > > >, int, std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format>, boost::unit_test::fixed_mapping<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format, boost::unit_test::case_ins_less<char const> >::p2>(__gnu_cxx::__normal_iterator<std::pair<boost::unit_test::basic_cstrin g<char const>, boost::unit_test::output_format>*, std::vector<std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format>, std::allocator<std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format> > > >, int, int, std::pair<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format>, boost::unit_test::fixed_mapping<boost::unit_test::basic_cstring<char const>, boost::unit_test::output_format, boost::unit_test::case_ins_less<char const> >::p2)': /usr/include/c++/3.3.2/bits/stl_heap.h:197: undefined reference to `boost::unit_test::ut_detail::msvc65_like_log_formatter::msvc65_like_log_for matter[in-charge] (boost::unit_test::unit_test_log const&)' unit_test_log.o: In function `boost::unit_test::unit_test_log::set_log_format(boost::unit_test::basic_cst ring<char const>)': /usr/local/boost/libs/test/src/unit_test_log.cpp:381: undefined reference to `boost::unit_test::ut_detail::msvc65_like_log_formatter::msvc65_like_log_for matter[in-charge](boost::unit_test::unit_test_log const&)' /usr/local/boost/libs/test/src/unit_test_log.cpp:383: undefined reference to `boost::unit_test::ut_detail::xml_log_formatter::xml_log_formatter[in-charge ](boost::unit_test::unit_test_log const&)' collect2: ld returned 1 exit status Do I need the latest CVS snapshot or what? This worked a few days ago, so I don't know what happened. I'm using the unit test framework. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.701 / Virus Database: 458 - Release Date: 6/7/2004

2 2

[CVS] Problem
by David B. Held 18 Jun '04

18 Jun '04

cvs update: Updating boost/format/detail cvs update: failed to create lock directory for `/cvsroot/boost/boost/boost/form at/detail' (/cvsroot/boost/boost/boost/format/detail/#cvs.lock): No space left o n device cvs update: failed to obtain dir lock in repository `/cvsroot/boost/boost/boost/ format/detail' cvs [update aborted]: read lock failed - giving up Looks like an SF issue to me. Is this going to get fixed by itself, or should someone send them a note? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.701 / Virus Database: 458 - Release Date: 6/7/2004

3 2

Re: [boost] program_options with mingw
by Janusz Piwowarski 18 Jun '04

18 Jun '04

Janusz Piwowarski wrote: > BTW, i successfully compile program_options library and examples with > stlport 4.6.2; but my program, where i use boost::thread, don't want to > link. Sorry, i check it now - examples also don't link. Regards, Janusz

2 2

program_options with mingw
by Janusz Piwowarski 18 Jun '04

18 Jun '04

Hello, I attach a patch that allows use of program_options with mingw compiler. There isn't support for utf-8 conversion - maybe it is possible to convert without use of wstring? Regards, Janusz

3 5

Boost.Test
by Jagmohan S Nanaware 18 Jun '04

18 Jun '04

Hi, Is it possible to just carve out Boost.test package separately from entire Boost? regards, Jagmohan

2 1

Documentation
by David B. Held 18 Jun '04

18 Jun '04

Ok, if the Boost style documentation is too simple, and docs like Spirit are too cute, what is a nice, happy median? If we're going to demand uniformity in licensing, should we also demand more uniformity in documentation? I think a single documentation style across Boost would make it even easier to learn new libraries. I recently found it very difficult to find the information I wanted about the Boost.Test library, as well as Boost.Preprocessor. What can be done about these issues? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.701 / Virus Database: 458 - Release Date: 6/7/2004

8 20

physical quantities
by Andy Little 17 Jun '04

17 Jun '04

The next version of my physical quantities libary pqs-1-01-04 is available on my site at: http://www.servocomm.freeserve.co.uk/Cpp/pqs-1-01-04/download.html The original type has now been augmented by another. The original type has now been renamed as a 'ct-quantity' representing a physical quantity whose units cannot be modified at run-time. The other type is the 'rt-quantity', whose units can be modified at run-time. The two types are of course compatible and the rt-quantity in particular is useful for further derivation, for instance into a physical quantity whose units can be set and interrogated via strings ie "mm, kgf" etc of which there is an example in the examples directory. The first question many will ask about such a library is : "How does the run-time speed/memory performance compare with using inbuilt types?." That is an important question, but to me not the most important one. (The answer is that this is implementation dependent and the current implementation is not optimal) Having used the library for some time its power seems to lie in the fact that it models a concept quite accurately from a programmers point of view. IOW what you can do with the type is restricted (by the compiler) to (some subset of) the entity that it models. The reason that this is powerful is difficult to define, but can be summed up in the saying: " a picture is worth a thousand words" I now see more clearly what those who wanted to see currency conversion and number of apples per kumquat or whatever where driving at. However these are not physical-quantities. C++ does have the ability to express those concepts, but they lie outside the remit of the concept that this library models. Nontheless such concepts would be useful. So in a network model a byte, packet etc would be a concept which would be modelled by a C++ type. Strongly enforcing the rules by which entities interact is satisfying , I guess, because it clarifies the mental picture of a program. Modelling everything by a double or an int (should number_of_bytes_received be convertible to double ... probably not etc) means everything is mush. So on a personal note designing the library has been very rewarding. As I spend much time GUI programming, it strikes me that the next useful concepts are those of model-space, view-space, paper-space etc. Here a point in space would be represented by different types which could only exist in the relevent space, but have the intelligence to perform transforms from one space to another. Similarly where one is modelling (say) magnetic flux density at a point x, y, z , the role of the view-space would be to convert form the entity in model-space to 'some representation ' in the view-space or the paper-space. The obvious candidates for the types in model-space being the ct-quantity of course. regards Andy Little

2 3

Using the Boost license
by Geoff Leyland 17 Jun '04

17 Jun '04

Hi, I have a couple of small libraries I'm "releasing" to a few other people (well, anybody really, but so far only a few). Can I use the BSL on my software even though it's not part of boost? Do I have to make any changes? thanks for your time, Geoff

2 2

RE: [boost] Re: static sized strings (non-virtual implementation)
by Reece Dunn 17 Jun '04

17 Jun '04

John Nagle wrote: >That's a much better approach than the previous one. >It's sound C++, and it's simple. >All the operations go in string_base. fixed_string >need only allocate space. I have now checked in a working implementation of the approach I suggested. It uses a trick to pass the information to the implementation via the basic_string_impl class and has a complicated implementation of swap (non-virtual :)!). The only functions not available to [w]char_string are substr and +, but these are available in fixed_string itself. I have also fixed the problems with fsstring.hpp and Borland, since Borland may make strcpy, etc macro functions to its intrinsic versions (__strcpy__, etc.) Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

type_traits for checking derived type
by D-Swat 17 Jun '04

17 Jun '04

Hi, some code: template <typename DerivedT> class A { BOOST_STATIC_ASSERT((boost::is_convertible<A<DerivedT>*, B*>::value)); [...] }; class B : public A { }; I want to check if the template parameter really specifies a derived type. But the assert is always false. How can i solve this? bye

5 5

Re: Boost Digest, Vol 756, Issue 1
by Eric Ford 17 Jun '04

17 Jun '04

> The next version of my physical quantities library pqs-1-01-04 is > available on my site at: > > http://www.servocomm.freeserve.co.uk/Cpp/pqs-1-01-04/download.html > ... Andy, Thank you for your work on this very important area of development. From just quickly looking at the examples, it appears that you choose to use different types for quantities that have the same dimensions but different units. I don't think that is a good idea. You can search the archives for the discussions several of us had about similar issues, mostly a few years ago. If you still disagree, I'd like to hear why. Perhaps, you could summarize the main similarities and difference between your library and other similar libraries. For example, there's Walter Brown's SIUnits, as well as a couple of drafts that have been uploaded to the boost vault. I know I posted ebf_units a while back to give people something to work from. And I believe there were one or two others there as well. Thanks, Eric

2 1

applied patch to boost::tuple
by Toon Knapen 17 Jun '04

17 Jun '04

I just applied the patch below to boost/tuple/detail/tuple_basic.hpp to port it to IBM/VisualAge. I tried to contact Jaako Jarvi but the email address listed in the copyright statement is not valid anymore ;-( Index: tuple_basic.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/tuple/detail/tuple_basic.hpp,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- tuple_basic.hpp 28 Oct 2003 09:42:43 -0000 1.23 +++ tuple_basic.hpp 17 Jun 2004 07:01:13 -0000 1.24 @@ -43,6 +43,8 @@ #include "boost/type_traits/cv_traits.hpp" #include "boost/type_traits/function_traits.hpp" +#include "boost/detail/workaround.hpp" // needed for BOOST_WORKAROUND + namespace boost { namespace tuples { @@ -97,12 +99,22 @@ template<class RET, class HT, class TT > inline static RET get(const cons<HT, TT>& t) { +#if BOOST_WORKAROUND(__IBMCPP__,==600) + // vacpp 6.0 is not very consistent regarding the member template keyword + // Here it generates an error when the template keyword is used. + return get_class<N-1>::get<RET>(t.tail); +#else return get_class<N-1>::BOOST_NESTED_TEMPLATE get<RET>(t.tail); +#endif } template<class RET, class HT, class TT > inline static RET get(cons<HT, TT>& t) { +#if BOOST_WORKAROUND(__IBMCPP__,==600) + return get_class<N-1>::get<RET>(t.tail); +#else return get_class<N-1>::BOOST_NESTED_TEMPLATE get<RET>(t.tail); +#endif } }; @@ -194,11 +206,17 @@ typename element<N, cons<HT, TT> >::type >::non_const_type get(cons<HT, TT>& c BOOST_APPEND_EXPLICIT_TEMPLATE_NON_TYPE(int, N)) { - return detail::get_class<N>::BOOST_NESTED_TEMPLATE +#if BOOST_WORKAROUND(__IBMCPP__,==600 ) + return get_class<N>:: +#else + return get_class<N>::BOOST_NESTED_TEMPLATE +#endif get< typename access_traits< typename element<N, cons<HT, TT> >::type - >::non_const_type>(c); + >::non_const_type, + HT,TT + >(c); } // get function for const cons-lists, returns a const reference to @@ -209,11 +227,17 @@ typename element<N, cons<HT, TT> >::type >::const_type get(const cons<HT, TT>& c BOOST_APPEND_EXPLICIT_TEMPLATE_NON_TYPE(int, N)) { +#if BOOST_WORKAROUND(__IBMCPP__,==600) + return detail::get_class<N>:: +#else return detail::get_class<N>::BOOST_NESTED_TEMPLATE +#endif get< typename access_traits< typename element<N, cons<HT, TT> >::type - >::const_type>(c); + >::const_type, + HT,TT + >(c); } // -- the cons template --------------------------------------------------

2 1

RE: [boost] Boost.Test
by Roman Yakovenko 17 Jun '04

17 Jun '04

Jagmohan wrote: > Is it possible to just carve out Boost.test package > separately from entire > Boost? Yes, bcp utility is your friend. >From bcp documentation: "The bcp utility is a tool for extracting subsets of Boost, it's useful for Boost authors who want to distribute their library separately from Boost, and for Boost users who want to distribute a subset of Boost with their application." Roman --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.707 / Virus Database: 463 - Release Date: 6/15/2004

1 0

RE: [boost] Re: static sized strings (struct hack)
by Reece Dunn 17 Jun '04

17 Jun '04

John Nagle wrote: > I think we're back to using an abstract base class. >The hacks to get around it introduce worse problems. I would agree. I have been trying to find a way around the problem and have (sortof) by having a base class: template< typename CharT > class string_base { private: size_t len, cap; // length & capacity CharT * buf; // data buffer public: string_base( CharT * b, size_t c, size_t l ): len( l ), cap( c ), buf( b ){} // non-virtual implementation }; template< size_t n, typename CharT > class fixed_string: public string_base { private: CharT data[ n + 1 ]; public: fixed_string(): string_base( data, n + 1 ){} }; The problems with this revolve around swapping/construction/copying and interfacing with (in my case) basic_string_impl. I cannot find a way around these problems without sacrificing something. > Take a look at my approach at >http://www.animats.com/source/index.html > >That's a straightforward approach. The only >fundamental objection is that you take a virtual function >call overhead on some operations. That's the same with both approaches. Both designs are fundamentally the same and I don't see a way around this. It would be interesting to do a comparison with the 3 approaches (raw strcpy, etc on a char[ n ] buffer; your approach and mine) in virtual and non-virtual situations to compare performance. >What needs to be done to that? Are you aiming at supporting basic_string operations? If so, the class needs more work (all the find functions, for instance). If, however, you are just going for C-string replacement it is fine. One point on naming: the wide-character operations are wcscpy (strcpy), wcscat (strcat), wcscmp (strcmp), wcslen (strlen) and [v]swprintf (sprintf). >Should I check it into the Boost sandbox, and >if so, how? Comments, please. Thanks. Go for it! You need a sourceforge account with CVS write access to the boost-sandbox. There is documentation at the sourceforge site for setting it up and pointers to the various tools. You will need to contact an administrator for write access once you have the sourceforge stuff setup. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 3

Two bugs generating docs using bjam --v2
by Angus Leeming 16 Jun '04

16 Jun '04

I have been following Douglas Gregor's prescriptions on how to generate boostbook docs, outlined on the boost web pages. All works beautifully, so many thanks. However, I find that generating reference docs using bjam and doxygen results in a couple of errors in the docs. I don't know whether the problem lies in bjam or in doxygen, but thought you should have a heads up. This is all with boost-jam-3.1.9-1 doxygen-1.3.4-1 Example 1 A header file containing: template <typename DataT> class process_base { protected: process_base(); process_base(process_base const &); }; results in docs: template<typename DataT> class process_base { public: // construct/copy/destruct process_base(); process_base(process_base const }; Note the change from 'protected' to 'public'. Example 2. This class: struct pprocess_data { /// Type used for file descriptors. typedef int fd_t; /// Pipe used to write to child process' stdin. fd_t wpipe; /// Two pipes to read from child process' stdout and stderr. fd_t rpipe[2]; }; results in these docs: struct pprocess_data { // types typedef int fd_t; // Type used for file descriptors. // public member functions fd_t wpipe; fd_t rpipe; }; Note that the 'rpipe' is no longer an array. Also, shouldn't the 'public member functions' comment be supressed? bjam warning messages are: Cannot handle sectiondef with kind=private-type Cannot handle sectiondef with kind=private-attrib Cannot handle sectiondef with kind=related Cannot handle sectiondef with kind=protected-type Cannot handle sectiondef with kind=protected-attrib I can supply header files and jamfile if required. Regards, Angus

2 2

[bind] Patch that enables pass-by-value
by Lars Rune Nøstdal 16 Jun '04

16 Jun '04

Hi, I'm a new user of this library, so not sure if this is a good idea or the best way to do this. void f(int x) { cout << "f(int): " << x << endl; } int x = 0; bind(f, _1)(x); //bind(f, _1)(1); // Does not work. bind(f, _1)(val<int>(1)); // But this does after patching. This enables the user to pass-by-value if he specifies it explicitly, here is the patch: Index: boost/bind.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/bind.hpp,v retrieving revision 1.36 diff -u -c -d -r1.36 bind.hpp *** boost/bind.hpp 8 Jun 2004 13:43:03 -0000 1.36 --- boost/bind.hpp 15 Jun 2004 19:13:43 -0000 *************** *** 27,32 **** --- 27,33 ---- #include <boost/type.hpp> #include <boost/bind/arg.hpp> #include <boost/detail/workaround.hpp> + #include <boost/val.hpp> // Borland-specific bug, visit_each() silently fails to produce code Index: boost/bind/bind_template.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/bind/bind_template.hpp,v retrieving revision 1.4 diff -u -c -d -r1.4 bind_template.hpp *** boost/bind/bind_template.hpp 7 Mar 2004 16:39:15 -0000 1.4 --- boost/bind/bind_template.hpp 15 Jun 2004 19:13:43 -0000 *************** *** 27,32 **** --- 27,38 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1> result_type operator()(val<A1> a1) + { + list1<A1> a(a1); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1> result_type operator()(A1 & a1) { list1<A1 &> a(a1); *************** *** 39,44 **** --- 45,56 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2> result_type operator()(val<A1> a1, val<A2> a2) + { + list2<A1, A2> a(a1, a2); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2> result_type operator()(A1 & a1, A2 & a2) { list2<A1 &, A2 &> a(a1, a2); *************** *** 51,56 **** --- 63,74 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3) + { + list3<A1, A2, A3> a(a1, a2, a3); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3> result_type operator()(A1 & a1, A2 & a2, A3 & a3) { list3<A1 &, A2 &, A3 &> a(a1, a2, a3); *************** *** 63,68 **** --- 81,92 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4) + { + list4<A1, A2, A3, A4> a(a1, a2, a3, a4); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4) { list4<A1 &, A2 &, A3 &, A4 &> a(a1, a2, a3, a4); *************** *** 75,80 **** --- 99,110 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5) + { + list5<A1, A2, A3, A4, A5> a(a1, a2, a3, a4, a5); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5) { list5<A1 &, A2 &, A3 &, A4 &, A5 &> a(a1, a2, a3, a4, a5); *************** *** 87,92 **** --- 117,128 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6) + { + list6<A1, A2, A3, A4, A5, A6> a(a1, a2, a3, a4, a5, a6); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6) { list6<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &> a(a1, a2, a3, a4, a5, a6); *************** *** 99,104 **** --- 135,146 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6, val<A7> a7) + { + list7<A1, A2, A3, A4, A5, A6, A7> a(a1, a2, a3, a4, a5, a6, a7); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6, A7 & a7) { list7<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &, A7 &> a(a1, a2, a3, a4, a5, a6, a7); *************** *** 111,116 **** --- 153,164 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6, val<A7> a7, val<A8> a8) + { + list8<A1, A2, A3, A4, A5, A6, A7, A8> a(a1, a2, a3, a4, a5, a6, a7, a8); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6, A7 & a7, A8 & a8) { list8<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &, A7 &, A8 &> a(a1, a2, a3, a4, a5, a6, a7, a8); *************** *** 123,128 **** --- 171,182 ---- BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8, class A9> result_type operator()(val<A1> a1, val<A2> a2, val<A3> a3, val<A4> a4, val<A5> a5, val<A6> a6, val<A7> a7, val<A8> a8, val<A9> a9) + { + list9<A1, A2, A3, A4, A5, A6, A7, A8, A9> a(a1, a2, a3, a4, a5, a6, a7, a8, a9); + BOOST_BIND_RETURN l_(type<result_type>(), f_, a, 0); + } + template<class A1, class A2, class A3, class A4, class A5, class A6, class A7, class A8, class A9> result_type operator()(A1 & a1, A2 & a2, A3 & a3, A4 & a4, A5 & a5, A6 & a6, A7 & a7, A8 & a8, A9 & a9) { list9<A1 &, A2 &, A3 &, A4 &, A5 &, A6 &, A7 &, A8 &, A9 &> a(a1, a2, a3, a4, a5, a6, a7, a8, a9); *** /dev/null Thu Jan 1 01:00:00 1970 --- boost/val.hpp Tue Jun 15 22:00:29 2004 *************** *** 0 **** --- 1,35 ---- + #ifndef BOOST_VAL_HPP_INCLUDED + #define BOOST_VAL_HPP_INCLUDED + + // val.hpp - Usefull helper functions + // + // Copyright (C) 2004 Lars Rune Nøstdal (larsnostdal(a)organizer.net) + // + /* + 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) + */ + + + namespace boost { + + template<typename T> + struct val { + val(T t) + :value(t) + { + } + + operator T&() + { + return(value); + } + + private: + T value; + }; // val + + } // namespace boost + + #endif // #ifndef BOOST_VAL_HPP_INCLUDED Thanks, Lars Rune Nøstdal

3 3

[tuple] problem with global tuples::get() in vacpp 6.00
by Joaquín Mª López Muñoz 16 Jun '04

16 Jun '04

Seems like Visual Age is having trouble deducing some implicit template parms inside tuples::get(). This is currently breaking Boost.MultiIndex and a test of Boost.Iterator. Please find below a very simple and totally conformant fix. This has not actually been tested with vacpp, but I checked it does not break anything with some other compilers. 1. Could anybody check locally if this solves the aforementioned problems in vacpp? 2. If 1 is positive, can I commit this to the CVS? Anyone sees a problem? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo **************DIFF************** 201c201,203 < >::non_const_type>(c); --- > >::non_const_type, > HT,TT > >(c); 216c218,220 < >::const_type>(c); --- > >::const_type, > HT,TT > >(c);

4 11

Geometric Algebra Library
by Jaap Suter 16 Jun '04

16 Jun '04

Hi, This is a follow-up to my original email from June 9th, see: http://tinyurl.com/3defq [again crossposted to oo-numerics and boost-developers] After this email, several people expressed interest in my geometric algebra library. Unfortunately I cannot address each email individually, so thanks to everybody that replied. First, I want to introduce a new feature I added this week.. It's what I like to call the "auto_element" feature. Within the Clifford framework it works like a "typeof" or "auto" feature. Consider the following: typedef algebra<float, 4, 1> conformal_space; element<list_c<int, 0, 2>, conformal_space> a; element<list_c<int, 1, 2, 4>, conformal_space> b; some_type c = left_contraction(a, b) * outer_product(some_vector, some_bi_vector); People familiar with Clifford algebra know that sometimes it is hard to decude what grades appear in the resulting element of a complicated expression. E.g., in the above example, who can tell me what grades appear in the left_contraction of a conformal-spinor and an element that has grade 1, 2 and 4. Let alone if you multiply that with the outer_product of some vector and some bivector. In other words, what is the type of c? Most other libraries solve this by just using a full multivector (consisting of 32 floats) in this case, which is often redundant. In fact, perhaps the above expression results in just a single scalar. That's a lot of calculation and storge for just one number then. This library allows you to write: auto_element(conformal_space, c, left_contraction(a, b) * outer_product(some_vector, some_bi_vector) ); [indention weird, because of the line-ending limit] which will declare an multi-vector of a type that contains the bare-minimum of grades necessary to capture all the information available in the expression. This has big performance improvements, but more interesting, it makes generic programming with arbitrary elements of an algebra a lot of fun. You don't have to know what types are involved in an expression anymore, but still get all the benefits of static type-checking and the associated performance analysis. Who said C++ was statically typed? :) By the way, for those wondering how I did it, obviously auto_element is a macro that does some (compile-time) stuff. It's not that hard, but a technique I hadn't seen before (let me know if it does exist somewhere else, or if there's a better way of doing this). Come to think of it, other libraries that involve dimensional-types (matrix libraries, etc.) could possible benefit from this as well. Anyway, enough about that... I have now uploaded a package to http://www.jaapsuter.com containing all the header files, some of my unit-tests, and the MSVC 7.1 project file. For reasons outside of my control I cannot upload all of the unit-tests yet. This will be resolved shortly. If you consider porting this to GCC, I would still recommend trying to compile the project in MSVC first and play around with it. It's some really heavy code internally. Hopefully (this is for you to judge) the client-side (see the unit-tests) are very friendly though. So please browse the tests before you dive into the implementation. Comments are welcome. There is still some bugs with certain expressions (as a consequence of not being able to deal with unsorted grade-lists), this will be fixed shortly. I am working on the library on-going, but I am hoping somebody will join. Then, somebody mentioned the interoperability with std::complex and Hubert Holin's Quaternion and Octonion library. I have some tests that test whether Clifford and these libraries behave the same (and inter-operate). As for implementing these types in terms of a geometric algebra? It depends. Sometimes it's worthwhile to specialize and keep things simple (think about scoped_ptr not being implemented in terms of a policy_ptr). But then again, if you have a clifford library in your project already anyway, you might as well use it for complex numbers, quaternions, etcetera. Otherwise, using clifford to provide these basic components is probably overkill. Regards, Jaap Suter

2 1

Geometric Algebra Library
by Jaap Suter 16 Jun '04

16 Jun '04

Hi, [crossposted to oo-numerics and boost-developers] About 20 months back, I asked if there was any interest in a geometric or Clifford algebra library written in C++. Despite some positive replies, I got the impression that there were not a lot of people in the Boost community who saw any practical uses for such library. Back then I had a rudimentary proof-of-concept for a Clifford algebra library that used meta-programming techniques to gain significant performance benefits over other existing libraries (Gaigen, nKlein, CLU, etcetera). Over the past few months I have put a lot more work into this library. The bulk of the work consisted of adding more unit-tests, proving many of the theorems in some of the papers by David Hestenes et al. I also added expression templates to improve performance. To give an idea of what the library is capable of: #include <boost/math/clifford/clifford.hpp> #include <boost/mpl/list_c.hpp> #include <cassert> using namespace boost::math::clifford; using namespace boost::mpl; typedef algebra<4, 1> conformal_model; typedef blade<float, 0, conformal_model> scalar; typedef blade<float, 1, conformal_model> vector; typedef blade<float, 5, conformal_model> pseudo_scalar; typedef blade<float, 2, conformal_model> bi_vector; // same as: // typedef element<float, list_c<int, 1>, conformal_model> bi_vector; typedef list_c<int, 0, 2> spinor_grades; typedef element<float, spinor_grades, conformal_model> spinor; typedef list_c<int, 0, 1, 2, 3, 4, 5> multi_vector_grades; typedef element<float, multi_vector_grades, conformal_model> multi_vector; int main() { assert(sizeof(scalar) == sizeof(float)); assert(sizeof(vector) == 5 * sizeof(float)); assert(sizeof(bi_vector) == 10 * sizeof(float)); assert(sizeof(pseudo_scalar) == sizeof(float)); assert(sizeof(spinor) == 11 * sizeof(float)); assert(sizeof(multi_vector) == 32 * sizeof(float)); vector e_plus; e_plus[3] = 1.0; vector e_min; e_min[4] = 1.0; e_star = e_min - e_plus; e_star *= -std::sqrt(2.0); e_star /= 2.0f; e [noalias] = e_plus * std::sqrt(2.0) - e_star; bi_vector E = outer_product(e, e_star); // geometric product between bi_vector and vector multi_vector v = E * e_star; // geometric product between two vectors, generating a spinor vector a, b; spinor s = a * b; // doing a spinor rotation vector c; c [noalias] = reverse(s) * a * s; } Each product always does the bare minimum of additions, multiplications and subtractions to calculate the result on the left-hand-side of an expression. Thus, if you do the full geometric product of two multi_vectors but assign it to a scalar, it will only do those calculations that are involved in grade 0. Also, unlike other existing libraries, no dynamic allocations are being done ever. Currently, the following operations are supported, between any two random elements of an algebra (blades and composite multi_vectors): geometric_product = operator * inner_product outer_product fat_dot_product left_contraction right_contraction scalar_product of course, all the normal operations (scalar multiplication, addition of elements, etcetera) are supported, as well as reversion, involution and conjugates. Adding more operators is trivial. They can either be implemented in terms of existing operators, or by implementing an appropriate grade-predicate. For example, this is what the implementation of the outer_product looks like: struct outer_product_predicate { template <class ResultGrade, class LhsGrade, class RhsGrade> struct apply { typedef typename mpl::if_ < typename mpl::equal_to < ResultGrade, typename mpl::plus<LhsGrade,RhsGrade>::type >::type, mpl::true_, mpl::false_ >::type type; }; }; BOOST_MATH_CLIFFORD_PRODUCT_IMPL( outer_product, impl::outer_product_predicate ) which for somebody that knows the definition of the outer_product is easy to understand. I have unit-tests for 2, 3 4 and 5 dimensional algebras, but more is possible if your compiler supports it. Currently I have only tested the library on MSVC 7.1. I tried 7.0 but couldn't get it to work (excessive use of MPL). GCC and Intel compiled it at one point, but because I only use MSVC I dropped support. Of course, if anybody is interested I'd be trying other compilers again. You will need a compiler that does aggresive inlining though. On MSVC I am using the force_inline feature to get the release performance I need. Anyway, let me know if anybody is interested, and I'll put together a package to upload somewhere. Cheers, Jaap

7 6

[Boost-bugs] [ boost-Support Requests-973424 ] boost::optional<enum> fails with /CLR
by SourceForge.net 15 Jun '04

15 Jun '04

Support Requests item #973424, was opened at 2004-06-15 11:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=973424&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost::optional<enum> fails with /CLR Initial Comment: ----- #include <boost\optional.hpp> #using <mscorlib.dll> #include <tchar.h> using namespace System; enum Numbers { Zero, One, Two, Three }; // This is the entry point for this application int _tmain(void) { boost::optional<Numbers> num; return 0; } ----- optional.hpp(347): error C2300: 'System::Enum' : class does not have a destructor called '~T' I'm using boost 1.31.0; this fails in both VC7.0 and VC7.1. Removing "#using <mscorlib.dll>" and "using namespace System;" gets rid of the compiler error, but then you can't use things like System::String* Thanks, Dan sourceforge.net(a)jdanielsmith.org ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=973424&group_i… ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Announcing a New C++ Zine
by Chuck Allison 15 Jun '04

15 Jun '04

brlbo> This is very impressive, but from the standpoint of the reader it brlbo> appears very much to be a direct competitor to CUJ's Experts' Forum. Do brlbo> you think there is room for both initiatives? Don't get me wrong, I do brlbo> hope there is, but I'm afraid there might not be. brlbo> Cheers, brlbo> Nicola Musatti If you look at the members of the Editorial Board, please keep in mind that we all have been discussing the kind of Zine *they* would like to see, in the hopes that such a thing would be of value to other C++ enthusiasts. This makes it, IMO, very different than CUJ. I can say no more about this here, but it will be different than CUJ indeed. There is room for both venues (some people strongly prefer print), but I think Boost folks will prefer what will appear over time in The C++ Source. If I (and the Board) didn't, we wouldn't waste our time. Having been instrumental in both publications, I know the difference. The fact that *for now* no one is getting paid should lend some credibility to the effort (but see below for more on that). In addition, anyone can contribute, not just "experts". This is an important distinction. (Besides, even Andrei Alexendrescu was an unknown until Scott Meyers "discovered" him. Latent experts need a venue to precede their notoriety). brlbo> If there's only room for one, I would prefer the one that is explicitly brlbo> peer reviewed, myself. I understand that programming in C++ is brlbo> an engineering pursuit, and not an academic/scientific one, but I brlbo> don't see that as a reason to hold it to a lesser standard. brlbo> Dave (Held) It won't be an academic journal, only peer reviewed. The articles will be written by and for C++ practitioners. The reviewing makes for better content, clearly. I see it sort of a publication equivalent of Boost - a place for peer-reviewed articles instead of software. FYI, the funds at CUJ dwindled so terribly (note the current minimized page count and disappearance of certain columns, letters, etc.) that I had to depend on the gracious kindness of my colleagues to review articles gratis. I don't know what the current arrangements are there (I have reason to believe that no one reviews articles there except the editor-in-chief, but that will have to be a private discussion), but the only people reviewing articles at CUJ besides myself for 2002-2003 were David Abrahams, Bjorn Karlsson, and Kevlin Henney. I managed to get a (very) few pennies for only one of them. When the holding company fired everyone but me and folded production into the DDJ machine, I left. That was October 2003. I tested the waters for a new Zine, a place with quality you can trust, by emailing those whose names appear on the Editorial Board of The C++ Source. The response was overwhelmingly positive - I can provide you moving quotes for the value of an online, peer-reviewed Zine from these experts we revere. The fact that things incubated until now shows our careful and good intentions. It is important to me that you (the Boost Community) understand this. brlbo> Actually I like the idea that people should get paid for their efforts, brlbo> while at the same time I do very much appreciate the efforts of those who brlbo> don't get paid such as the Boost developers in putting out free software. brlbo> My suggestion for a subscription to the C++ Zine was to help those who were brlbo> willing to put out the effort of writing articles, and developing software brlbo> based on them, to get paid. (Eddie) A valid point, with which I agree, but they *will* get paid, just not immediately. We have some advertising lined up and some other hopefuls. I think we'll get to the point where the remuneration will be worthwhile. We ourselves are professionals, and want to get paid, and don't want to slight anyone. The difference between The C++ Source and other venues is that we are not owned by a holding company needing to make Wall Street happy, and who from an uninformed distance may fire an entire long-standing family of fruitful employees to fill investors' pockets. [The people in Lawrence, Kansas, who made CUJ what it is over the last 20 years, were all given their walking papers - I mean, who needs *them*, after all?!] Hats off to the pioneers who have donated initial articles and other contributions to this new endeavor. Now that we've all had a chance to express opinions (thank you!), may I once again just invite you to read and contribute to The C++ Source, a peer-reviewed Zine created by and for people such as yourselves. Please send proposals, articles, and other offers of service to me at chuck(a)freshsources.com. Thank you! -- Best regards, Chuck Allison

1 0

[Boost-bugs] [ boost-Bugs-973310 ] jam_src build scripts need como --c
by SourceForge.net 15 Jun '04

15 Jun '04

Bugs item #973310, was opened at 2004-06-15 10:16 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=973310&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Larry Evans (cppljevans) Assigned to: Nobody/Anonymous (nobody) Summary: jam_src build scripts need como --c Initial Comment: Without the como --c option, the command: build.sh como results in several .c files. For example: "execunix.c", line 225: error: identifier "vfork" is undefined if ((pid = vfork()) == 0) ^ Also, on debian, PATH_MAX is undefined in pwd.c. Output of como -c --list pwd.l pwd.c shows: N#include <limits.h> L 1 "/usr/lib/gcc-lib/i386-linux/2.95.4/include/limits.h" 1 N/* This administrivia gets added to the beginning of limits.h N if the system has its own version of limits.h. */ N N/* We use _GCC_LIMITS_H_ because we want this not to match N any macros that the system's limits.h uses for its own purposes. */ N#ifndef _GCC_LIMITS_H_ /* Terminated in limity.h. */ N#define _GCC_LIMITS_H_ N N#ifndef _LIBC_LIMITS_H_ S/* Use "..." so that we find syslimits.h only in this same directory. */ S#include "syslimits.h" N#endif indicating that syslimits.h is skipped. Maybe that's part of the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=973310&group_i… ------------------------------------------------------- This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Re: Geometric Algebra Library
by Johannes Brunen 15 Jun '04

15 Jun '04

Hi, Jaap Suter wrote: >> Despite some >> positive replies, I got the impression that there were not a lot >> of people in the Boost community who saw any practical uses for >> such library. Ken Hagan wrote: > For a full geometric algebra, I suspect the target market is going > to be limited to a few thousand people worldwide, This may currently be correct. However, IMHO GA will gain a lot of importance. E.g. I'm working in the CAD industry and we are beginning to be aware of GA's strength against the classic mathematical toolset. I see a time comming that you learn GA in high school. Every physics student will be learning GA once it has found its way to the theoretical courses. Thereafter GA will gain room in the engineering fields. > most of whom have > never heard of boost and are unwilling to learn C++. I don't share this opinion. C++ has its place in the world, and a lot of applications which are a target to GA are programmed in C++. I think that people are willing to learn C++ if they see that the language and its tools (like boost) can help them to solve their problems (e.g. GA, CAD, robotics,...) better than other languages and tools. This was exactly the way I found myself at this place. > I wrote some GA classes for the 3D case about a decade ago, and I'm > still using them, but they are a very minor part of my work and I've > no reason to "upgrade" to a boost version, no matter how yummy it looks. > I'd like to be more positive, but I have to be honest. If you are pleased with your tools that is fine. But there are other people which could benefit a lot from a well shaped GA package. And more importantly, there will be new applications written which have to decide about the tools they use to solve there math. They probably won't write a new GA package and will stick with the classic tools. However, if available they may make the transition to a boost GA package. > However, you may be asking the wrong question. There are reasonable > arguments for using only one library for all your geometric algebra > and the demand for complex numbers is demonstrably large enough to > justify including it in the language standard. At first I wrote 'I second that!', but I have a problem with the part about complex numbers. GA is not a replacement for std::complex. > Given that GA is a superset of these, could your library replace > these two? It would need to be syntactically compatible, since we > can't break existing clients of std::complex, but since all such > libraries try to follow standard mathematical notation this might > not be too difficult. And IMHO GA should not try to supersede the classic tools since there still will be demand for them. I think they can perfectly coexists. People shoud choose the tools which best serve their needs. Finally, I strongly encourage Jaap Suter as well as Paul Leopardi (http://lists.boost.org/MailArchives/boost-users/msg06695.php , http://glucat.sourceforge.net/) to bring their libraries into the boost review process. With kind regards Johannes

3 2

Request for small test in CW 9.2
by Joaquín Mª López Muñoz 15 Jun '04

15 Jun '04

During the porting of my library, I found the following compiler bug in CW 8.3: **BEGIN PROGRAM** #include <iostream> struct foo { foo(){} foo(const foo&){} ~foo() { std::cout<<"~foo"<<std::endl; } }; template<typename T> struct A { static void bar() { const foo& f=foo(); std::cout<<"inside A::bar"<<std::endl; } }; struct B { static void bar() { const foo& f=foo(); std::cout<<"inside B::bar"<<std::endl; } }; int main() { std::cout<<"calling A::bar"<<std::endl; A<int>::bar(); std::cout<<"calling B::bar"<<std::endl; B::bar(); return 0; } **END PROGRAM** *Without* enabling the option "ISO C++ Template Parser", everything works dandy and the program output is: calling A::bar inside A::bar ~foo calling B::bar inside B::bar ~foo But if I enable the "ISO C++ Template Parser", the output becomes: calling A::bar ~foo inside A::bar calling B::bar inside B::bar ~foo Which is AFAICS a flagrant bug (note that ~foo() is called before A::bar() scope ends.) Fortunately, I know how to patch this in CW 8.3 with some pragmas. I'd be grateful if someone with access to CW 9.2 can check whether the error persists in this newer version of the compiler, so as to extend (or not) the patch to cover it as well. Remember, the problem only shows when the "ISO C++ Template Parser" is turned on. Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

[program_options] vc6 and vc7: explicit function template arguments
by Vladimir Prus 15 Jun '04

15 Jun '04

Hello, it appears that both vc6 and vc7 don't understand explicit function template arguments, like this: value<string>()->implicit() where 'value' is a function. Anybody can suggest a workaround? One possible approach would be to make 'value' a class which overloaded operator->, but that's a lot of work. TIA, Volodya

2 2

CVS problem
by Janusz Piwowarski 15 Jun '04

15 Jun '04

Hello, >From yesterday evening to now, there's agurtovoy's lock in /cvsroot/boost/boost/boost/python/converter. Regards, Janusz

2 2

RE: [boost] Re: Announcing a New C++ Zine
by Glen Knowles 15 Jun '04

15 Jun '04

>From: David Abrahams [mailto:dave@boost-consulting.com] >>>>>Has William reappeared? >>>> >> As last resort, his phone number is listed ;-) > >But I forgot what state he lives in. >From http://www.boost.org/people/william_kempf.htm Bill Kempf lives in Omaha, NE with his wife Bonnie, his cat Dexter and his two Chinchillas, Chimney and Minuet. He married on Oct. 30, 1999 where he and his wife held a Halloween costume reception. If that doesn't give you an idea of what kind of guy he is, nothing will. Glen

2 1

Re: Announcing a New C++ Zine
by Chuck Allison 14 Jun '04

14 Jun '04

Jeff Flinn wrote: > Has William reappeared? Actually, I haven't heard from him for a while. This is not the final list. I will soon do a final query of those who want their names to remain on the Editorial Board (and of course, others can be added). The list I sent contains those who have participated in the forming of The C++ Source since last October. You might want to ping him with a private message. I should add here that I forgot to mention in my original post that for now, contributing to The C++ Source is a "labor of love". None of us are getting paid. As we get sufficient advertising, we will share the wealth. We are starting small, but I predict a gradual swelling until this becomes a mainstay for the majority of C++ developers. Someone has suggested a subscription basis, but with today's Internet culture, I think we'll do the most good if we keep it free. That can change, but for now, that's the way it is. After all, Boosters are very familiar with this model :-). -- Chuck Allison

7 12

Announcing a New Online C++ Zine
by Chuck Allison 14 Jun '04

14 Jun '04

Hello Boosters, David Abrahams suggested I could send you an announcement on this list. For some time now (since last October, actually) a group of C++ luminaries have been discussing the virtues and possibilities of a peer-reviewed source for the C++ community. We have decided on the name "The C++ Source", and a preliminary page is available for viewing at http://www.artima.com/cppsource. The idea is to have seasoned C++ professionals review submissions to ensure that the publications are of high quality and of interest. There will also be tutorials, news, lots of stuff. The Editorial Board currently is: David Abrahams J. Stephen Adamczyk Andrei Alexandrescu Matthew Austern Pete Becker Walter Bright Steve Clamage Greg Colvin Jim Coplien Stephen Dewhurst Howard Hinnant Bjorn Karlsson William Kempf Andrew Koenig Martha Masinton Scott Meyers Thomas Plum Dan Saks Jerry Schwarz Jeremy Siek Bjarne Stroustrup Herb Sutter Matthew Wilson Leor Zolman (Like, wow!) I am writing to invite you to consider writing for The C++ Source. In fact, the first installments to appear later this month include an article by Booster Bjorn Karlsson. The chances that anything of interest to you will be of interest to the C++ community at large, and will make a positive contribution to daily C++ development. If you have any ideas, proposals, or suggestions, please email me at chuck(a)freshsources.com. Thanks! -- Best regards, -- Chuck Allison

5 5

RE: [boost] Re: Documentation
by Reece Dunn 14 Jun '04

14 Jun '04

John Nagle wrote: >Robert Ramey wrote: >>As far as writing documentation is concerned I found the the "standard" >>boost position at: >> >>C:\boost_1_31_0\more\writingdoc\index.html > > I'm having trouble reading your C: drive. Try replacing "C:\boost_1_31_0" with either http://www.boost-consulting.com/boost or the directory where your copy of Boost is located, e.g.: http://www.boost-consulting.com/boost/more/writingdoc/index.html HTH Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

RE: [boost] Documentation
by Reece Dunn 14 Jun '04

14 Jun '04

David B. Held wrote: >Ok, if the Boost style documentation is too simple, and docs like >Spirit are too cute, what is a nice, happy median? Have you looked at the BoostBook generated docs :). Let me know what you think of the current L&F: I have updated this a while ago to try and bridge the gap between the two looks (the docs now have Spirit-style navigation). See http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/doc/html/ind… for the new-stle docs. >If we're going >to demand uniformity in licensing, should we also demand more >uniformity in documentation? I agree on this. At the moment, we have the docs written in HTML, those in BoostBook format (like Boost.Any and the BBv2 docs) and the Spirit docs which have their own format. As far as I understand it, the BoostBook tool is relatively new and has a learning curve, so it will take some time to migrate the docs to this format. As for the Spirit docs, they have their own sourceforge area as well as being a part of Boost, so forcing them to change doc format wouldn't be fair. However, since the Spirit docs are in a special text format that is "compiled" into HTML using Spirit, it should be easy to create a BoostBook back-end and have the docs in boost in this format and the ones on the sourceforge area in the existing format. With this in mind, it might be beneficial to create a HTML to BoostBook converter (possibly using Spirit) to allow easier migration to the BoostBook format. >I think a single documentation style >across Boost would make it even easier to learn new libraries. I >recently found it very difficult to find the information I wanted about >the Boost.Test library, as well as Boost.Preprocessor. What can >be done about these issues? I think the BoostBook format would go a long way to resolving these issues, once the docs are all in this uniform format. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

6 6

config tests breaking change imminent
by John Maddock 14 Jun '04

14 Jun '04

Following our recent discussion on file naming conventions, I've submitted a Sourceforge support request to have all the *.cxx files in libs/config/test renamed to *.ipp. When this change takes place the config tests will be broken until further notice (but probably only for a day or two). Regards, John.

2 1

Re:[boost] Re: Re: config and .cxx extensions
by Robert Ramey 14 Jun '04

14 Jun '04

Jeff Flinn wrote: > If it's VisualStudio, you can add the extensions to the registry to act > like headers or source(compilable) files. I would bet most others have a > similar facility. Please tell us how to do that. I looked for this and couldn't find it. I would like to tell my Visual.Net IDE to treat *.ipp file like *.hpp and *.cpp for editing purposes. Robert Ramey

3 2

Re: Documentation
by Robert Ramey 14 Jun '04

14 Jun '04

As far as writing documentation is concerned I found the the "standard" boost position at: C:\boost_1_31_0\more\writingdoc\index.html To be very helpful. I think it goes a long way to providing a common look and feel the boost docs. By providing a skeleton document for a boost library it also saves a lot of work. I tried to follow it as closely as possible for the boost serialization library. I think the discussions around boost documentation should focus on how this "document" document (meta-document?) should be updated. So it might a) Be a little more specific re tutorial and reference documentation sections. This is not quite as easy as one would first think as the requirements for formatting/tables of overloads are different from from function calls, etc. b) Suggest a common navigation facility. I actually liked the navigation pane used by the BOOST_PP library and have incorporated something similar in the new serialization library documentation. I find it very helpful. Robert Ramey

2 1

[Boost-bugs] [ boost-Bugs-972406 ] Tokenizer.hpp doesn't work with BOOST_ENABLE_ASSERT_HANDLER
by SourceForge.net 14 Jun '04

14 Jun '04

Bugs item #972406, was opened at 2004-06-13 22:35 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=972406&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Tokenizer.hpp doesn't work with BOOST_ENABLE_ASSERT_HANDLER Initial Comment: Using boost-1.31.0 Tokenizer.hpp has #include <cassert> on line 23 - this prevents a custom assert function from working properly when trying to use BOOST_ENABLE_ASSERT_HANDLER. It looks like token_iterator.hpp and token_functions.hpp also do the same thing. It would be nice if these used the common boost assert mechanism instead of directly #including <cassert>. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=972406&group_i… ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: BGL: Shadow Warnings
by Perry Kundert 14 Jun '04

14 Jun '04

The -Wshadow warnings also affect the "spirit" parser. Attached is a patch that fixes up a number of quite verbose warnings about shadowing variables... David A. Greene wrote: > Jeremy Siek wrote: > >> Hi David, <snip> > > The option seems to be a little flaky in that it flags some things > that I don't think it should, but it's still a good debugging tool. > >> I'm currently extremely busy with school work, so it may take a while >> for me to get to this. If you want to send me a patch to fix these >> problems I'd be thankful. > > > I feel your pain. :) I'll see what I can do, but no guarantees. > > -Dave > --- boost_1_31_0-stock/boost/spirit/core/impl/match.ipp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/impl/match.ipp 2004-06-09 09:05:20.000000000 -0600 @@ -17,12 +17,12 @@ : len(-1), val() {} template <typename T> - inline match<T>::match(std::size_t length) - : len(length), val() {} + inline match<T>::match(std::size_t length_) + : len(length_), val() {} template <typename T> - inline match<T>::match(std::size_t length, ctor_param_t val_) - : len(length), val(val_) {} + inline match<T>::match(std::size_t length_, ctor_param_t val_) + : len(length_), val(val_) {} template <typename T> inline bool @@ -64,11 +64,11 @@ inline match<nil_t>::match() : len(-1) {} - inline match<nil_t>::match(std::size_t length) - : len(length) {} + inline match<nil_t>::match(std::size_t length_) + : len(length_) {} - inline match<nil_t>::match(std::size_t length, nil_t) - : len(length) {} + inline match<nil_t>::match(std::size_t length_, nil_t) + : len(length_) {} inline bool match<nil_t>::operator!() const --- boost_1_31_0-stock/boost/spirit/core/non_terminal/parser_id.hpp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/parser_id.hpp 2004-06-09 09:17:33.000000000 -0600 @@ -100,7 +100,7 @@ : parser_id(reinterpret_cast<std::size_t>(this)); } - void set_id(parser_id id) { tag = id; } + void set_id(parser_id id_) { tag = id_; } private: --- boost_1_31_0-stock/boost/spirit/core/non_terminal/rule.hpp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/rule.hpp 2004-06-09 09:42:46.000000000 -0600 @@ -157,8 +157,8 @@ return ptr.get(); } - rule(abstract_parser_t const* ptr) - : ptr(ptr) {} + rule(abstract_parser_t const* ptr_) + : ptr(ptr_) {} scoped_ptr<abstract_parser_t> ptr; }; --- boost_1_31_0-stock/boost/spirit/core/non_terminal/impl/rule.ipp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/impl/rule.ipp 2004-06-09 09:43:51.000000000 -0600 @@ -224,7 +224,7 @@ template <typename ParserT, typename ScannerT, typename AttrT> struct concrete_parser : abstract_parser<ScannerT, AttrT> { - concrete_parser(ParserT const& p) : p(p) {} + concrete_parser(ParserT const& p_) : p(p_) {} virtual ~concrete_parser() {} virtual typename match_result<ScannerT, AttrT>::type --- boost_1_31_0-stock/boost/spirit/core/scanner/scanner.hpp 2004-01-19 16:15:56.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/scanner/scanner.hpp 2004-06-09 09:44:41.000000000 -0600 @@ -240,22 +240,22 @@ bool at_end() const { - typedef typename PoliciesT::iteration_policy_t iteration_policy_t; - return iteration_policy_t::at_end(*this); + typedef typename PoliciesT::iteration_policy_t iteration_policy_t_; + return iteration_policy_t_::at_end(*this); } value_t operator*() const { - typedef typename PoliciesT::iteration_policy_t iteration_policy_t; - return iteration_policy_t::filter(iteration_policy_t::get(*this)); + typedef typename PoliciesT::iteration_policy_t iteration_policy_t_; + return iteration_policy_t_::filter(iteration_policy_t_::get(*this)); } scanner const& operator++() const { - typedef typename PoliciesT::iteration_policy_t iteration_policy_t; - iteration_policy_t::advance(*this); + typedef typename PoliciesT::iteration_policy_t iteration_policy_t_; + iteration_policy_t_::advance(*this); return *this; } --- boost_1_31_0-stock/boost/spirit/dynamic/stored_rule.hpp 2004-01-19 16:15:56.000000000 -0700 +++ boost_1_31_0/boost/spirit/dynamic/stored_rule.hpp 2004-06-09 09:45:53.000000000 -0600 @@ -109,8 +109,8 @@ private: #endif - stored_rule(shared_ptr<abstract_parser_t> const& ptr) - : ptr(ptr) {} + stored_rule(shared_ptr<abstract_parser_t> const& ptr_) + : ptr(ptr_) {} shared_ptr<abstract_parser_t> ptr; }; --- boost_1_31_0-stock/boost/spirit/core/non_terminal/subrule.hpp 2004-01-19 16:15:55.000000000 -0700 +++ boost_1_31_0/boost/spirit/core/non_terminal/subrule.hpp 2004-06-09 09:48:16.000000000 -0600 @@ -209,7 +209,7 @@ subrule_list< subrule_parser<ID2, DefT2, ContextT2>, nil_t> > - operator,(subrule_parser<ID2, DefT2, ContextT2> const& rhs) const + operator,(subrule_parser<ID2, DefT2, ContextT2> const& rhs_) const { return subrule_list< self_t, @@ -219,7 +219,7 @@ *this, subrule_list< subrule_parser<ID2, DefT2, ContextT2>, nil_t>( - rhs, nil_t())); + rhs_, nil_t())); } typename DefT::embed_t rhs; @@ -257,10 +257,10 @@ parse_main(ScannerT const& scan) const { typedef typename parser_result<self_t, ScannerT>::type result_t; - result_t result; + result_t result_; impl::parse_subrule<result_t, ScannerT, ID>:: - do_(result, scan); - return result; + do_(result_, scan); + return result_; } template <typename ScannerT> --- boost_1_31_0-stock/boost/spirit/symbols/symbols.hpp 2004-01-19 16:15:57.000000000 -0700 +++ boost_1_31_0/boost/spirit/symbols/symbols.hpp 2004-06-09 09:49:14.000000000 -0600 @@ -114,13 +114,13 @@ { typedef typename ScannerT::iterator_t iterator_t; iterator_t first = scan.first; - typename SetT::search_info result = SetT::find(scan); + typename SetT::search_info result_ = SetT::find(scan); - if (result.data) + if (result_.data) return scan. create_match( - result.length, - symbol_ref_t(*result.data), + result_.length, + symbol_ref_t(*result_.data), first, scan.first); else

2 1

BOOST_DEBUG like macros: current state overview
by Pavel Vozenilek 13 Jun '04

13 Jun '04

Some time ago I suggested to add support for BOOST_DEBUG and BOOST_NDEBUG macros into guidelines. I searched how individual libraries (1.31) handle debug support: ------------------------------------- * lexical_cast - uses assert() * dynamic_bitset - uses assert() * filesystem - uses assert() * graph - uses assert() * interval - uses assert() * thread - uses assert() * tokenizer - uses assert() * random - uses assert() * lambda - uses assert() * multi_array - uses assert() * signals - uses assert() * format - uses BOOST_ASSERT() * function - uses BOOST_ASSERT() * variant - uses BOOST_ASSERT * optional - uses BOOST_ASSERT * smart_ptr - uses BOOST_ASSERT and macro with somewhat misleading name BOOST_SP_ENABLE_DEBUG_HOOKS * concept_check - uses NDEBUG directly * ublas - uses its own macro BOOST_UBLAS_CHECK depending on NDEBUG. Documented * python - uses its own macro BOOST_PYTHON_INDEXING_CHECK_INVARIANT depending on NDEBUG and also NDEBUG directly. Not documented * regex - uses assert() based on BOOST_REGEX_DEBUG and jm_assert (macro too). Uses also BOOST_REGEX_DEBUG directly. No dependence on NDEBUG. Not documented. * spirit - uses macro BOOST_SPIRIT_ASSERT depending on assert() as well as handful of other library specific debug macros. Well documented. Circular Buffer, Multi Index Container and likely Serialization contain (documented) extensive support for debug mode with their specifi macros and different level modes. ------------------------------------- Documentation usually doesn't mention if/how debug support is implemented. Maybe common macros would make life of Boost user easier. /Pavel

2 2

config and .cxx extensions
by David Abrahams 13 Jun '04

13 Jun '04

Is there a good reason that the config library needs to use a "creative" choice of file extensions rather than the boost standard of ".*pp"? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

7 14

Can anyone help with this one?
by Thomas Don Aratari 12 Jun '04

12 Jun '04

Hello, I'm trying to upgrade my boost to 1_31 but I keep getting the following tokenizer error. I am using Forte 8.0 (CC: Sun C++ 5.5 Patch 113817-03 2003/10/14). Here is the code snip: (passing in sString to be tokenized) typedef boost::tokenizer<boost::char_separator<char> > tokenizer; boost::char_separator<char> seperator(sDroppedDelimiters, sKeptDelimiters, boost::keep_empty_tokens); tokenizer tokens( sString, seperator ); for (tokenizer::iterator tok_iter = tokens.begin(); tok_iter != tokens.end(); ++tok_iter) vInVector.push_back( *tok_iter ); "/home/dev/cm/THIRD_PARTY/boost/include/boost/iterator/iterator_facade.hpp", line 623: Error: Could not find a match for boost::iterator_core_access::equal<boost::iterator_core_access::Facade1, boost::iterator_core_access::Facade2>(const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, const boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::is_convertible<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>>). "MDSStringHelpers.cxx", line 183: Where: While instantiating "boost::operator!=<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int, boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>(const boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>&, const boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char>>, const char*, std::string>, std::string, boost::forward_traversal_tag, const std::string &, int>&)". "MDSStringHelpers.cxx", line 183: Where: Instantiated from non-template code. Any ideas how to fix or has anyone else seen this? Thanks Tom

1 0

Re: New C++ Zine (Print version?)
by Chuck Allison 12 Jun '04

12 Jun '04

Hello Dave, Saturday, June 12, 2004, 11:01:35 AM, you wrote: brlbo> "Chuck Allison" <chuck(a)freshsources.com> wrote in message brlbo> news:15110019883.20040611130022@freshsources.com... >> [...] >> David Abrahams suggested I could send you an announcement >> on this list. For some time now (since last October, actually) a >> group of C++ luminaries have been discussing the virtues and >> possibilities of a peer-reviewed source for the C++ community. brlbo> Is it likely there will be a print edition in the future? If so, is there a brlbo> timetable for it's appearance? brlbo> Dave We have discussed having a periodic (annual?) print anthology (a la C++ Gems), but of course, we haven't even launched yet, so we're getting ahead of ourselves. With sufficient success/resources, the answer is "yes". -- Best regards, Chuck

1 0

Re: Announcing a New C++ Zine
by Chuck Allison 12 Jun '04

12 Jun '04

Hello Alexander, I'm sorry, but that page is just a sample page. Bjarne's article is not an official posting. We haven't launched yet. If you want to discuss the content of Bjarne's comments, you can email him directly, but it has nothing to do with The C++ Source. Sorry if I didn't make it clear that that page was just a sample. I meant to. Saturday, June 12, 2004, 11:01:35 AM, you wrote: brlbo> Chuck Allison wrote: brlbo> [...] >> viewing at http://www.artima.com/cppsource. The idea is to have brlbo> Quoting from http://www.artima.com/intv/elegance.html. Few comments brlbo> follow. brlbo> <quote author=Bjarne Stroustrup> brlbo> I don't put in specific features for concurrency, because you can put brlbo> them in a library. brlbo> </quote> brlbo> You can't do that without threaded memory model, to begin with. brlbo> <quote> brlbo> C was designed with the principle that you should be able to write brlbo> its standard library in the language itself. That same principle brlbo> guided the design of C++. brlbo> </quote> brlbo> Show me the the standard C++ impl of atomic<> for a rather simple brlbo> thing like brlbo> class swap_based_mutex_for_windows { // noncopyable brlbo> atomic<int> m_lock_status; // 0: free, 1/-1: locked/contention brlbo> auto_reset_event m_retry_event; // "slow" bin sema/gate brlbo> public: brlbo> // ctor/dtor [w/o lazy event init] brlbo> void lock() throw() { brlbo> if (m_lock_status.swap(1, msync::acq)) brlbo> while (m_lock_status.swap(-1, msync::acq)) brlbo> m_retry_event.wait(); brlbo> } brlbo> bool trylock() throw() { brlbo> return !m_lock_status.swap(1, msync::acq) ? brlbo> true : !m_lock_status.swap(-1, msync::acq); brlbo> } brlbo> bool timedlock(absolute_timeout const & timeout) throw() { brlbo> if (m_lock_status.swap(1, msync::acq)) { brlbo> while (m_lock_status.swap(-1, msync::acq)) brlbo> if (!m_retry_event.timedwait(timeout)) brlbo> return false; brlbo> } brlbo> return true; brlbo> } brlbo> void unlock() throw() { brlbo> if (m_lock_status.swap(0, msync::rel) < 0) brlbo> m_retry_event.set(); brlbo> } brlbo> }; brlbo> regards, brlbo> alexander. -- Best regards, Chuck

1 0

Re: static sized strings (struct hack)
by Bill Seymour 12 Jun '04

12 Jun '04

Rob Stewart: > > From: John Nagle <nagle(a)animats.com> > > > From: "Reece Dunn" <msclrhd(a)hotmail.com> > > > > >> class fs_base > > >> { > > >> size_t len; > > >> szie_t capacity; // needed for buffer-safe operations > > >> CharT str[ 1 ]; > > >> // string manipulation functions > > >> > > >> fs_base( size_t c ): capacity( c ){} > > >> }; > > >> > > >> template< size_t n > > > >> class fixed_string: public fs_base > > >> { > > >> CharT data[ n ]; > > >> fixed_string(): fs_base( n ){} > > >> }; > > > > Are you assuming that "data[n]" physically follows > > "str[1]" in memory, and that "data[n]" can be addressed > > by subscripting "str[1]" out of range? ... > > Oh, right. It was C99 that blessed the struct hack. Oh well. > Well, yes; but the struct hack is not what the code above tries to do. What C99 says is that you can malloc sizeof(fs_base) plus some extra, then address str[2] to str[whatever up to malloc'd size]. Even in C99 (and even if C understood the C++-specific stuff in the above), there is no relationship between fs_base::str and fixed_string::data (except that they don't overlap). --Bill Seymour

2 1

More Math Functions
by Paul A Bristow 12 Jun '04

12 Jun '04

|-----Original Message----- |From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf |Of Tom Brinkman |Sent: 03 June 2004 00:54 |To: boost(a)lists.boost.org |Subject: [boost] Boost Mathematicians |What is the current status of all Boost mathmatical, |statistical and econometric libraries currently in |development? |The collection of boost math libraries that are |currently included in the library are world-class and |provide a wonderful foundation to build-upon. |However, many areas of advanced statistical and |mathmatical inference are not currently being \addressed by any of the boost libraries. I have been off-line for some time, but have now caught up with this discussion a bit. Strongly support your views and need these things yesterday ;-) Apart from messing about with Microsoft Windows problems, I have been preparing a formal proposal for C and C++ Standard Library TR-2 of a list of Math 'Special' Functions (additional to those from Walter Brown which have been accepted into TR-1). This list will include all the usual statistical suspects - including Student's t, Chi sqr, and F, so that at last it will be possible easily write C++ to provide the probability that means of two series of measurements differ. (The key function is the incomplete beta; it is also the most difficult to write well). Fortunately I have persuaded Stephen Moshier, author of the Cephes function library (in C) to make this available under Boost licence terms. So implementors will have no excuse to hide behind (the reason why these functions were omitted by Walter Brown). It should be possible to produce a working (and I believe rather good) implementation with little more than renaming the functions. This might be submitted for a Boost library. I hope to expose a revised draft to the rigours of Boost and C++.std newsgroup Real Soon Now. Paul Paul A. Bristow Prizet Farmhouse, Kendal UK LA8 8AB +44 1539 561830 07714 33 02 04 pbristow(a)hetp.u-net.com

1 0

Paul Mensonides:
by Vesa Karvonen 12 Jun '04

12 Jun '04

[boost] Re: Some remarks on PP docs Date: Fri, 11 Jun 2004 16:36:19 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Paul Mensonides: >Chaos, as opposed to Order, intentionally encourages better >understanding of the actual language being used (which is not Chaos, but >the preprocessor) rather than trying to hide it as much as possible. I've discussed this with you earlier, but I'd still like to point out that the intention behind the design of Order has not been to "hide as much as possible" or to discourage "better understanding", but rather to *provide* a language that definitely *is* easy to understand and convenient to use. A person unfamiliar with Boost.PP should be able to learn to use something like Order and use it for productive, even non-trivial, work (which is usually C or C++ code generation) in significantly shorter period of time than it takes to learn how to do similar things with Boost.PP (or Chaos). I also noticed other, IMO, misleading comments on Order [vs Chaos], but I don't have the time to comment on those at the moment. -Vesa Karvonen _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Re: Some remarks on PP docs
by Vesa Karvonen 12 Jun '04

12 Jun '04

David Abrahams: >I'm writing an appendix on the PP lib for the MPL book today. I think >that'll demonstrate that it's possible to provide a reasonable gentle >and high-level introduction without exposing too many ugly details. That would be great! >- Fundamental PP Abstractions > - Macros > - Non function > - Function macros > - Tokens > - Sequences of tokens not including un-parenthesized commas Data structures are an important topic and their representation isn't fundamentally PP *library* specific. You might want to present the information on the representation of data structures (and simple macros like a projection operator for tuples and some sequences operations) here when you discuss fundamental PP abstractions. I would also probably discuss how to implement primitives like IF and WHILE using preprocessor macros at this point. The purpose being to show that the preprocessor is capable of significant computation. I would also emphasize that the purpose of explaining the techniques is not that people would roll their own versions, but simply to deepen their understanding of the preprocessor. >Well, if you really have a conforming C99 preprocessor, you could use >Paul M's Chaos, which I think is both easier to use and *way* more >efficient than the current Boost PP. >From what I know, Chaos is essentially an extended Boost.PP (meaning that Chaos is essentially a combinator library), with a single recursion backend (enabled by stricter requirements on preproprecessor conformance), which makes it more orthogonal. However, Chaos still shares many problems with Boost.PP, the main issues being that code will be highly verbose and very intricate. The verbosity and intricacy probably do not matter that much when one only performs simple repetition using the canned library macros. -Vesa Karvonen _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

3 5

Some remarks on PP docs
by David Abrahams 12 Jun '04

12 Jun '04

techniques.html: It is usually okay to use a standard macro name like BOOST_PP_DEF for this kind of code because the macro is both defined and undefined in the immediate site of its use. I was really confused by the use of the word "standard". This would be clearer: It is usually okay to reuse a single generic macro name like BOOST_PP_DEF throughout your code because the macro is both defined and undefined very close to its point of use. Although I don't know why you'd want to advocate that over using a descriptive name. ------ A clearer divider between examples would be a *huge* help visually. An <hr> would be enough, for example. Example - Use BOOST_PP_EMPTY as an unused parameter in local macro instantiations. #define BOOST_PP_DEF(cv) /* ... */ \ template<class base> \ cv() typename implement_subscript_using_begin_subscript<base>::value_type& \ implement_subscript_using_begin_subscript<base>::operator[](index_type i) cv() { \ return base::begin()[i]; \ } \ /**/ ?? Where is BOOST_PP_EMPTY used in this example? I think I know what you mean, but really, you need to show it! How: BOOST_PP_EMPTY() expands to nothing and can be used as an unused parameter. Note: BOOST_PP_EMPTY with the () never gets expanded. This sounds self-contradictory. Just above you said it expands (to nothing)! The () is necessary to invoke a function-like macro. No duh; I think stating the obvious that way only adds confusion. Caveat: You cannot safely use concatenation while using BOOST_PP_EMPTY(). That's way too vague and general. I certainly can use concatenation and BOOST_PP_EMPTY "together", for many reasonable definitions of that word! I think you need to be more specific, or strike it. ------ The BOOST_PP_ENUM_PARAMS example could benefit greatly from a side-by-side format in a table showing the expansion on the right. In fact, that would help all the examples, but in particular if you're just getting acquainted with the library at this point you may not have any idea what some of those macros do. You're advocating that people use them here, but unless the reader has some idea of what they generate, it's lost on her. Showing not-even-correct details of BOOST_PP_REPEAT's implementation doesn't help here. I'd strike it. Furthermore, BOOST_PP_ENUM_PARAMS and its variations use BOOST_PP_REPEAT. BOOST_PP_COMMA_IF(I) expands to a comma if I != 0. BOOST_PP_INC(I) essentially expands to "I+1," and BOOST_PP_DEC(I) essentially expands to "I-1.". I'd strike that too. You haven't said a word about BOOST_PP_INC/DEC yet, so the reader is left wondering why you're giving their implementation details. ----- Example - Use BOOST_PP_REPEAT and a token look-up function to eliminate categorical repetition. Is this really better than iterating over a SEQ of categories in any way other than efficiency? ----- Example - Use BOOST_PP_REPEAT to avoid O(n*n) repetition. It's unclear to me how that example avoids O(n*n) repetition. It certainly seems to have that complexity, and that appears to be intrinsic to the code it generates. Maybe you mean Example - Use BOOST_PP_REPEAT for O(n*n) repetition. Or something? ----- BOOST_PP_IF enables convenient generation of lists using BOOST_PP_REPEAT. This statement, without an example, is too vague to be helpful. ----- Implementation details of BOOST_PP_IF don't help: How: BOOST_PP_IF is defined for the entire repeat range (psuedo code): #define BOOST_PP_IF(c, THEN, ELSE) BOOST_PP_IF ## c(THEN, ELSE) #define BOOST_PP_IF0(THEN, ELSE) ELSE #define BOOST_PP_IF1(THEN, ELSE) THEN #define BOOST_PP_IF1(THEN, ELSE) THEN ^ especially since they appear to be wrong. I think the point is that BOOST_PP_IF works on first arguments other than 0 or 1. If so, you should just say that it works on numeric arguments up to N (whatever N is). --------- Example: Use arithmetic, logical, and comparison operations when necessary. With no commentary, and no generated code, this example is really useless. I mean, of course you'd use arithmetic, logical, and comparison operations "when neccessary". -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

4 6

RE: [boost] Re: Documentation
by Reece Dunn 11 Jun '04

11 Jun '04

David Abrahams wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> writes: > > David Abrahams wrote: > >>"Reece Dunn" <msclrhd(a)hotmail.com> writes: > >> > David B. Held wrote: > > It should be fairly easy to adapt the ReST/SpiritDoc/whatever > > translation phase to generate BoostBook instead of HTML. > >Yeah, especially since docutils (ReST) already contains a DocBook >generating backend. It can also be done with XSLT from the ReST XML >generator. But ReST doesn't contain ways to represent many of the >C++-specific logical elements of BoostBook, IIUC. These could always be added in by the author after the BoostBook files have been generated, if you are planning to migrate from ReST/SpiritDocs to BoostBook. This was the idea, to give the user a tool/toolset to help migrate to the BoostBook format. > >> > As far as I understand it, the BoostBook tool is relatively new and > >> > has a learning curve, so it will take some time to migrate the docs >to > >> > this format. > >> > >>And it requires writing in XML :-( or translating to it :-|. > > > > XML is essentially a stricter version of HTML. > >I thought the main thing was that it is extensible. It is. You can have any element and attribute structure you want; this is how it is extensible. What I was referring to is that XML emposes stricter formatting rules than HTML, requiring attributes to be quoted and all tags to have corresponding closing tags (the open/close tag being a special case). This might be new to people familiar only with HTML and so may make mistakes, resulting in an invalid XML file. Automating this conversion process will help ensure a valid XML file to work from. > > The main problem I see is porting the existing HTML-based docs to > > BoostBook. The others can be generated using a BoostBook generator > > (not sure how easy it will be for each format). > >There's no advantage to translating into BoostBook, AFAICT, unless >we're going to stick in its special logical elements. We can always >just use a common .css if you just want a similar look. I thought one of the ideas behind BoostBook was to have a documentation format that will eventually become Boost-wide. If this is the case, then having tools like what I'm suggesting will help speed up the migration process. If not, then what you are suggesting is also fine. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Thread lib (good reason for static)
by Peter Danford 11 Jun '04

11 Jun '04

[This is from an email about the impact of not having a static Threads lib available anymore. I wanted to post this here to see if anyone else has similar experiences since I have only seen posts about the problem of distributing RTL dlls so far - not computation time impact.] Hello, I was reading some some of the posts about your thread implementation and the removal of the static RTL option. I understand the technical reason for this, but I wanted to submit another compelling reason (for me) for the need for static RTL linkage even if this means loosing some of the features under win32. Some of the software I develop deals with different types of analysis (such as scientific and financial). The runs can take as much as 20 hours to complete. If I do nothing but change to link with dynamic RTL, the run time is increased on average of 35%. This means and additional 7 hours of run time! So dynamic RTL is really undesirable. Do you see any way of making a more limited static Boost.threads available in the next Boost release? [Above I say "limited" because some of the features of the Thread lib must be implemented via dll to work under win32.] Peter --------------------------------- Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger

10 46

RE: [boost] Re: Documentation
by Reece Dunn 11 Jun '04

11 Jun '04

David Abrahams wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> writes: > > David B. Held wrote: > >>If we're going to demand uniformity in licensing, should we also > >>demand more uniformity in documentation? > > > > I agree on this. At the moment, we have the docs written in HTML, > > those in BoostBook format (like Boost.Any and the BBv2 docs) and the > > Spirit docs which have their own format. > >And others; we used ReST for the iterator library. It should be fairly easy to adapt the ReST/SpiritDoc/whatever translation phase to generate BoostBook instead of HTML. > > As far as I understand it, the BoostBook tool is relatively new and > > has a learning curve, so it will take some time to migrate the docs to > > this format. > >And it requires writing in XML :-( or translating to it :-|. XML is essentially a stricter version of HTML. The main problem I see is porting the existing HTML-based docs to BoostBook. The others can be generated using a BoostBook generator (not sure how easy it will be for each format). I have a Spirit-based HTML parser that does basic correction (not as good as HTMLTidy) that is event based (like SAX for XML) and can be used to generate XHTML. It should be possible to adapt this to generate a BoostBook document that can be used as the basis for migrated docs. The SpiritDoc processor tool is freely available and should be easy to migrate to BoostBook output. Other generators can be produced for ReST, etc. NOTE: The output of these should be seen as a basis for the actual docs as they won't be able to properly detect things like the licence info, author name or library name/category; these will need to be edited by the document provider. (It all depends on how this information is encoded in the base text. If there is a markup pattern, then it should be possible to identify this and extract the information.) Let me know if I should take a look into seeing how feasible this is. Having a common document format will help maintain a consistent navigation/look. Also, it should be possible to generate frames as an alternate look by editing the BoostBook stylesheets and with a little wizardry it should be possible ot turn this on or off, depending on your preferences like it is currently possible to select Spirit or DocBook navigation styles. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

feature request: file lock
by Jordi Vilar 11 Jun '04

11 Jun '04

Hi, I propose the inclussion of the following set of private members to the boost::filesystem::fstream class: private: void do_lock(); bool do_trylock(); bool do_timedlock(const xtime& xt); void do_unlock(); void do_lock(cv_state& state); void do_unlock(cv_state& state); this will enable additional classes: namespace boost { namespace filesystem { class scooped_lock; class scooped_try_lock; class scoped_timed_lock; } } with an interface like boost::thread::scooped_lock and sccoped_try_lock. What do you think about this? If you want to proceed and need help, please let me know, I can provide an implementation for Windows (NT and above) and posix (I'm currently working on this functionality). Cordially, Jordi Vilar

1 0

program_options and optional
by Neal D. Becker 11 Jun '04

11 Jun '04

Seems natural to use boost::optional with program_options. Has anyone tried this? For example, consider this: int main (int argc, char** argv) { namespace po = boost::program_options; optional<double> x; po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("x", po::value<double>()->notifier (var(x)=_1)) ; To set the optional<double> x, this uses boost::lambda. Is there a more direct approach?

2 1

Re:[boost] [serialization18] conflict definition of "is_abstract" with type traits library(in cvs)
by Robert Ramey 11 Jun '04

11 Jun '04

Allen Yao wrote: > The file is_abstract.hpp in serialization18 and is_abstract.hpp in type > traits library (in cvs) have conflict definitions of "boost::is_abstract". > May Ramey fix this. For now, I just comment out the latter in order to use > serialization18. I am aware of this. serialization #18 is meant to be compatible with boost 1.31. >In addition, I am confused with the ".ipp" files in libs/serialization/src/ >in serialization18. It is strange to write >#include <libs/serialization/src/basic_binary_oprimitive.ipp> // for serialization18 >in user code instead of >#include <boost/serialization/basic_binary_oprimitive.ipp> // for serialization17 >I wonder why these files can not be just named ".hpp" It is my practice to distinguish between header files containing declarations to be included by "users" of the library (*.hpp) from function implementations (*.cpp) and template implementations (*.ipp). I moved the *.ipp files to the src directory because they seemed no need for library users to ever include them when building with the library. Since then it has occurred to me that they may be included when one makes a new archive when deriving from an existing one. Accordingly, these *.ipp files will be moved to boost/archive/impl in the next version. This system is helpful to me - I don't know what other peoples views are on this. > when will we see the serialization library in boost cvs, please? I have made changes to address all issues raised in the recent review. I'm now making changes to permit builds on all the compilers I have. I hope to upload a version compatible with 1.31 "real soon now". I will then build against my cvs tree. Then I will request authorization to check in. It will take a little time. Robert Ramey

1 0

MSVC 7.1 and BOOST_NO_MEMBER_TEMPLATE_FRIENDS
by Maxim Yegorushkin 11 Jun '04

11 Jun '04

I think the following condition in visualc.hpp is incorrect #if _MSC_VER <= 1310 # define BOOST_NO_MEMBER_TEMPLATE_FRIENDS #endif I've checked that MSVC 7.1 supports memeber template syntax. And, AFAIR, MSVC 7.0 supports it too, but I haven't got it to check. Should the condition for BOOST_NO_MEMBER_TEMPLATE_FRIENDS macro here and in other places in visualc.hpp be changed to #if _MSC_VER < 1300? Or am I missing something? -- Maxim Yegorushkin

2 1

Re: Some remarks on PP docs
by Vesa Karvonen 11 Jun '04

11 Jun '04

Dave Abrahams: >I am not even trying to cover the whole PP library in this appendix, >much less the topic of PP metaprogramming in general. [...] [...] >... but, thanks for the suggestions. I don't mean to sound >ungrateful, but I'm really trying to limit this to a small-scale >practical overview of the things you need to know in order to get >started with the PP library. I see your point, but... >"Understanding the preprocessor and PP metaprogramming" is beyond the >scope of the book. ...while understanding all the consequences of the PP design is obviously not necessary for basic PP metaprogramming, I think that it is almost impossible to be able to use the PP (and the Boost.PP library) profitably (beoyond trivial use of macros like ENUM_PARAMS and REPEAT) without having a fairly good understanding of the capabilities and limitations of the PP. -Vesa Karvonen _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

2 1

RE: [boost] Geometric Algebra Library
by Johannes Brunen 11 Jun '04

11 Jun '04

Hi Jaap, fine to hear that you are still working on your GA library. I'm eager to see such a library in the boost pool. So I'm very interested in the library. One point however, Paul Leopardi is still working on GluCat and I have the impression that he is also targeting boost. It would be fine if you could bundle together your efforts in oder to get the best of each GA libraries. With best regards, Johannes

1 0

[serialization18] conflict definition of "is_abstract" with type traits library(in cvs)
by Allen Yao 11 Jun '04

11 Jun '04

The file is_abstract.hpp in serialization18 and is_abstract.hpp in type traits library (in cvs) have conflict definitions of "boost::is_abstract". May Ramey fix this. For now, I just comment out the latter in order to use serialization18. In addition, I am confused with the ".ipp" files in libs/serialization/src/ in serialization18. It is strange to write #include <libs/serialization/src/basic_binary_oprimitive.ipp> // for serialization18 in user code instead of #include <boost/serialization/basic_binary_oprimitive.ipp> // for serialization17 I wonder why these files can not be just named ".hpp" Ramey, when will we see the serialization library in boost cvs, please? Thank you:)

1 0

[thread] Thread specific pointer cleanup handlers
by Malcolm Noyes 11 Jun '04

11 Jun '04

During my 'research' into different ways to implement thread specfic storage (tss) on Win32, I needed to implement custom cleanup handlers. The thread_dev branch allows for a custom cleanup handler on the basis of 'one cleanup handler per global object instance'. This is *not* the same as 'one cleanup handler per tss object instance' since with tss there is of course one object instance per thread. Consider: void no_cleanup(int*) { // do nothing } thread_specific_ptr p(no_cleanup); int main(int, char*[]) { int some_number = 42; // leaving aside why someone might want to do this, it's // the mechanincs that we're interested in! p.reset(&some_number); // fine p.reset(new int(0)); // leak - 'p' has no cleanup! return 0; } The theoretical alternative would be to allow (enforce?) a different cleanup handler per thread object, e.g.: void no_cleanup(int*) { // do nothing } void delete_cleanup(int* pd) { delete pd; } thread_specific_ptr p; int main(int, char*[]) { int some_number = 42; // this time call reset with a specfic handler for this thread //object instance p.reset(&some_number, no_cleanup); // fine p.reset(new int(0), delete_cleanup); // ok now, will call delete return 0; } My feeling is that boost::thread should only allow the first form and document that the use above leads to unspecified behaviour (it may not be a memory leak, we don't know what the cleanup handler may do). My only reason for this however is that allowing the latter case is probably not a frequent use and makes the implementation much complicated. Does anyone think the latter is required ? Malcolm Malcolm Noyes

1 0

[Test] Linking
by David B. Held 11 Jun '04

11 Jun '04

What is the canonical way to link the Boost.Test library? Is it better to just include the sources in the project, or to try to link to a built library? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.701 / Virus Database: 458 - Release Date: 6/7/2004

2 1

boost::transform_iterator and boost::lambda functors
by Maxim Yegorushkin 10 Jun '04

10 Jun '04

Is there a way to make a boost::lambda functor adaptable, that is to make it define result_type? There is a ret<> function template that lets one specify the result type, but the returned functor still does not have result_type typedef. I've encountered the problem trying to use boost::transform_iterator with a boost::lambda functor: std::vector<int> intVect; boost::make_transform_iterator(intVect.begin(), boost::lambda::_1 / 2); transform_iterator<> does not compile comlaining the functor does not have result_type. As a workaround I had to write something like: template<class R, class T> struct result_type_wrapper : T { typedef R result_type; result_type_wrapper(T const& t) : T(t) {} }; template<class R, class T> inline result_type_wrapper<R, T> result_type(T const& t) { return t; } boost::make_transform_iterator(intVect.begin(), result_type<int>(boost::lambda::_1 / 2)); Am I missing something? Is there a way to avoid using result_type_wrapper<>? -- Maxim Yegorushkin

4 6

Re: Some remarks on PP docs
by Vesa Karvonen 10 Jun '04

10 Jun '04

David B. Held: >It's hard enough getting one's head around the PP lib without having to >be an expert in it already. [...] >It's a shame, because there's a lot of code that would benefit from the >PP lib that almost certainly isn't because of the difficult learning >curve. Learning Boost.Preprocessor is like learning a rather verbose and intricate programming language. It is not really surprising that it can be difficult to learn, although the documentation, at least the parts that I wrote, could certainly be improved. It is possible to implement a language using the C99 (or even the less capable C++97) preprocessor that would be much less verbose and intricate and would be significantly easier to use (see http://groups.yahoo.com/group/boost/files/Order/ for details), but it would come at some cost in efficiency (on some compilers the cost would probably be prohibitive and on some compilers the cost is insignificant). -Vesa Karvonen _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

2 2

Re: Some remarks on PP docs
by Vesa Karvonen 10 Jun '04

10 Jun '04

>techniques.html: Since I initially wrote the document, I might as well comment. >I was really confused by the use of the word "standard". This would >be clearer: > > It is usually okay to reuse a single generic macro name like > BOOST_PP_DEF throughout your code because the macro is both defined > and undefined very close to its point of use. Yeah, there is probably a better way to convey the idea. >Although I don't know why you'd want to advocate that over using a >descriptive name. Because those macros are essentially [used like] lambda expressions: ad hoc, short, local functions that you usually do not even want to name. There is also an additional benefit of using a single generic name. If you forget to write the #undef, you will more likely get a warning (or an error) from the preprocessor. #undefining local macros helps to avoid macro replacement related problems. >A clearer divider between examples would be a *huge* help visually. >An <hr> would be enough, for example. Looking at an old revision in CVS, this used to be the case. >?? Where is BOOST_PP_EMPTY used in this example? I think I know what >you mean, but really, you need to show it! Looking at old revisions in CVS, it used to be there (use of BOOST_PP_EMPTY). > Note: BOOST_PP_EMPTY with the () never gets expanded. > >This sounds self-contradictory. Just above you said it expands (to >nothing)! Again, looking old revisions in CVS, it used to read "without". > The () is necessary to invoke a function-like macro. > >No duh; I think stating the obvious that way only adds confusion. Perhaps. The point is to point out the reason why the macro does not get expanded. The idea of passing the "name" of a function like macro as a parameter may not be obvious to all. > Caveat: You cannot safely use concatenation while using >BOOST_PP_EMPTY(). > >That's way too vague and general. I certainly can use concatenation >and BOOST_PP_EMPTY "together", for many reasonable definitions of that >word! I think you need to be more specific, or strike it. Agreed. >The BOOST_PP_ENUM_PARAMS example could benefit greatly from a >side-by-side format in a table showing the expansion on the right. There used to be a page that contained all the examples of the tutorial after preprocessing (and formatting). You could then simply click the title of the example to see the preprocessed code. >Showing not-even-correct details of BOOST_PP_REPEAT's implementation >doesn't help here. I'd strike it. You are probably right. I suppose when I wrote that, I wanted to give an idea to the reader how such macros might be actually be implementable (so that it doesn't seem as magical as it otherwise might). Looking back, I think that it was a mistake, because I have seen several people inventing their own REPEAT-style macros rather than using the generic macros in the library. Although, it might be the case even if the tutorial were different (nothing would have prevented those same people from looking at the actual implementation and learning the same information). >Furthermore, > > BOOST_PP_ENUM_PARAMS and its variations use BOOST_PP_REPEAT. > BOOST_PP_COMMA_IF(I) expands to a comma if I != 0. BOOST_PP_INC(I) > essentially expands to "I+1," and BOOST_PP_DEC(I) essentially > expands to "I-1.". > >I'd strike that too. You haven't said a word about BOOST_PP_INC/DEC >yet, so the reader is left wondering why you're giving their >implementation details. I agree that the comment should be removed. I think that the comment has probably been more relevant at some stage (CVS would probably reveal it if this was the case), but the context was lost during editing. That ''BOOST_PP_DEC(I) essentially expands to "I-1"'' is hardly an implementation detail. >Is this really better than iterating over a SEQ of categories in any >way other than efficiency? At the time when the example was written, SEQ had not yet been invented and even lists were not as efficient and convenient as they are today. Unfortunately, the example was never updated. Today, I would generally advocate using a sequence (or some other data structure). > Example - Use BOOST_PP_REPEAT to avoid O(n*n) repetition. > >It's unclear to me how that example avoids O(n*n) repetition. The point is to avoid manual, source code time, repetition and replace it with automated, preprocessing time, repetition. The code that you will edit after using REPEAT will be only O(1) (and not O(n*n)). It is the same as using a high level language to avoid programming in machine language. Sure, the compiler translates the high level code to machine language (well, not exactly, but close enough), but this doesn't mean that (because of the translation) you would not be avoiding programming in machine language as you seem to suggest. > Example - Use BOOST_PP_REPEAT for O(n*n) repetition. > >Or something? That might be a better way to convey the idea. > BOOST_PP_IF enables convenient generation of lists using > BOOST_PP_REPEAT. > >This statement, without an example, is too vague to be helpful. I agree. >Implementation details of BOOST_PP_IF don't help: > > How: BOOST_PP_IF is defined for the entire repeat range (psuedo code): > #define BOOST_PP_IF(c, THEN, ELSE) BOOST_PP_IF ## c(THEN, ELSE) > > #define BOOST_PP_IF0(THEN, ELSE) ELSE > #define BOOST_PP_IF1(THEN, ELSE) THEN > #define BOOST_PP_IF1(THEN, ELSE) THEN > ^ >especially since they appear to be wrong. Again, looking at an old version in CVS, this used to be correct. >I think the point is that BOOST_PP_IF works on first arguments other >than 0 or 1. If so, you should just say that it works on numeric >arguments up to N (whatever N is). That is probably a better way to put it. Again, the idea was to show how IF might actually be implemented (to dispell the magic), but it was probably a mistake. > Example: Use arithmetic, logical, and comparison operations when > necessary. > >With no commentary, and no generated code, this example is really >useless. I mean, of course you'd use arithmetic, logical, and >comparison operations "when neccessary". Looking at an old [...], there used to be a comment: "The PREPROCESSOR library supports saturated arithmetic, logical and comparison operations on decimal integer literals in the range [0,BOOST_PP_LIMIT_MAG]. Suppose that you want to generate a numbered lists with a special element inserted at a desired position. For example: E0, E1, S, E2. Consider the following example:" The point of the example was really just to let the reader know that the library does contain macros for arithmetic, logic, etc... The example is admittedly weak and only designed to use some of the mentioned classes of macros. -Vesa Karvonen _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Re:[boost] Some remarks on PP docs
by Robert Ramey 10 Jun '04

10 Jun '04

David Abrahams wrote ..... While your at it, it would be really helpful to have a section for each compiler indicating which BOOST_PP... macros they don't support. I would hope this just be started and as users (like me) could just send in notes according to their experience. Here's the first line: BOOST_PP_CAT doesn't work with VC 6. Robert Ramey

1 0

Re: [boost] Geometric Algebra Library
by Tim Stevenson 10 Jun '04

10 Jun '04

Hi Jaap, I'm very interested in something like your library. I've only just started to wrap my head around geometric algebra and I've been confining myself so far to just playing with simple problems on paper to see how it removes special boundary case handling for some simple algorithms. The computational complexity of the higher dimensions has always concerned me but it sounds like you are doing a lot of compile-time optimisation to save wasted calculations at run-time. In a few months I'm planning to devote a considerable amount of time to investigating Geometric Algebra in a lot more detail and your library sounds like a good tool to "play" with. I use both VC++ and GCC and I would be willing to devote some time to investigate porting your library to the latest version of GCC. Tim.

1 0

Re: [boost] Problem with mpl::iter_fold_if.hpp in vacpp 6.0
by Toon Knapen 10 Jun '04

10 Jun '04

Joaquín Mª López Muñoz wrote: > Hi Toon, maybe we have advanced a little, since, if I'm ont wrong, the > error triggers at the second argument of the ctor. I've applied a > similar patch to this as well. Could you please try the attached file? This seems to solve the problem in the multi_index library ;-) but now compilation is aborted due to errors encountered while including the tuple library in the multi_index library ;-( See the compiler-messages in attachment: ...found 1065 targets... ...updating 72 targets... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_basic.test/vacpp/debug/test_basic.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 82.25: 1540-0095 (W) The friend function declaration "operator/" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 83.25: 1540-0095 (W) The friend function declaration "operator%" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_basic.cpp", line 40.25: 1540-0700 (I) The previous message was produced while processing "test_basic()". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/multi_index/test" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_basic.test/vacpp/debug/test_basic.o" "../../../libs/multi_index/test/test_basic.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_basic.test/vacpp/debug/test_basic.o... ...skipped <@boost!libs!multi_index!test/test_basic.test/vacpp/debug>test_basic for lack of <@boost!libs!multi_index!test/test_basic.test/vacpp/debug>test_basic.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_capacity.test/vacpp/debug/test_capacity.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 82.25: 1540-0095 (W) The friend function declaration "operator/" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 83.25: 1540-0095 (W) The friend function declaration "operator%" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> >(const cons<boost::multi_index::identity<employee>,boost::tuples::cons<std::less<employee>,boost::tuples::null_type> > &)". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<1,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 451.10: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 214.12: 1540-0711 (S) Too few template arguments have been specified. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/tuple/detail/tuple_basic.hpp", line 211.1: 1540-0700 (I) The previous message was produced while processing "boost::tuples::get<0,boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::tuples::null_type> >(const cons<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,boost::tuples::cons<std::less<std:...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 450.9: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::age>,std::less<int>,boost::multi_index::detail::sequenced_index<boost::multi_index::detail::index_bas...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index/ordered_index.hpp", line 443.5: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::detail::ordered_index<boost::multi_index::identity<employee>,std::less<employee>,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,&employee::name>,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,boost::multi_index::detail::ordered_index<boost::multi_index::member<employee,int,&employee::...". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/multi_index_container.hpp", line 130.12: 1540-0700 (I) The previous message was produced while processing "boost::multi_index::multi_index_container<struct employee,struct boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<employee>,boost::multi_index::detail::null_arg,boost::multi_index::detail::null_arg>,boost::multi_index::ordered_non_unique<boost::multi_index::tag<name,by_name,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl::void_,boost::mpl...". "../../../libs/multi_index/test/test_capacity.cpp", line 22.16: 1540-0700 (I) The previous message was produced while processing "test_capacity()". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/multi_index/test" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_capacity.test/vacpp/debug/test_capacity.o" "../../../libs/multi_index/test/test_capacity.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_capacity.test/vacpp/debug/test_capacity.o... ...skipped <@boost!libs!multi_index!test/test_capacity.test/vacpp/debug>test_capacity for lack of <@boost!libs!multi_index!test/test_capacity.test/vacpp/debug>test_capacity.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/multi_index/test/test_comparison.test/vacpp/debug/test_comparison.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 82.25: 1540-0095 (W) The friend function declaration "operator/" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/mpl/set/aux_/item.hpp", line 83.25: 1540-0095 (W) The friend function declaration "operator%" will cause an error when the enclosing template class is instantiated with arguments that declare a friend function that does not match an existing definition. The function declares only one function because it is not a template but the function type depends on one or more template parameters.

3 2

uBLAS regression tests
by Vladimir Prus 10 Jun '04

10 Jun '04

Hello, currently uBLAS regression tests are defined in status/Jamfile directly. Will it be OK if I move them to libs/numeric/ublas? The reason I'd need that is that Boost.Build V2 version of uBLAS tests that was contributed by Michael Stevens lives in libs/numeric/ublas, and with the current setup its hard for me to automatically verify that V1 and V2 test results are the same. - Volodya

2 1

[bind] vc6 problem
by Vladimir Prus 10 Jun '04

10 Jun '04

Hello, when I try to compiler the following code snippet on vc6 I get a lot of errors: #include <locale> #include <boost/bind.hpp> void aux(const std::codecvt<wchar_t, char, mbstate_t>& cvt) { boost::bind(boost::mem_fn(&std::codecvt<wchar_t, char, mbstate_t>::in), &cvt, _1, _2, _3, _4, _5, _6, _7); } The errors are: vc-C++ ..\..\..\bin\boost\libs\program_options\build\libboost_program_options.lib\msvc\debug\convert.obj convert.cpp H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::?$bind_t@ABVtemplate-parameter-BAB@V?$dm@$DBAB@$DBAC@@_mfi@boost@@V?$list1@V?$value@$DBAB@@_bi@boost@@@_bi@3@ __cdecl boost::bind(R T::*,A1)' : expects 2 arguments - 9 provided H:\Work\boost-rc\boost/bind.hpp(1487) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf8<R,T,B1,B2,B3,B4,B5,B6,B7,B8>,class boost::_bi::list9<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7,B8) const,A1,A2,A3,A4,A5,A6,A7,A8,A9)' : expects 10 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(223) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::mf8<R,T,B1,B2,B3,B4,B5,B6,B7,B8>,class boost::_bi::list9<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7,B8),A1,A2,A3,A4,A5,A6,A7,A8,A9)' : expects 10 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(212) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2784: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf7<R,T,B1,B2,B3,B4,B5,B6,B7>,class boost::_bi::list8<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7) const,A1,A2,A3,A4,A5,A6,A7,A8)' : could not deduce template argument for '<Unknown>' from 'struct boost::_mfi::cmf7<int,class std::codecvt<unsigned short,char,int>,int &,char const *,char const *,char const * &,unsigned short *,unsigned short *,unsigned short * &>' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2784: 'class boost::_bi::bind_t<R,struct boost::_mfi::mf7<R,T,B1,B2,B3,B4,B5,B6,B7>,class boost::_bi::list8<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6,B7),A1,A2,A3,A4,A5,A6,A7,A8)' : could not deduce template argument for '<Unknown>' from 'struct boost::_mfi::cmf7<int,class std::codecvt<unsigned short,char,int>,int &,char const *,char const *,char const * &,unsigned short *,unsigned short *,unsigned short * &>' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf6<R,T,B1,B2,B3,B4,B5,B6>,class boost::_bi::list7<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6) const,A1,A2,A3,A4,A5,A6,A7)' : expects 8 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(175) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::mf6<R,T,B1,B2,B3,B4,B5,B6>,class boost::_bi::list7<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5,B6),A1,A2,A3,A4,A5,A6,A7)' : expects 8 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(164) : see declaration of 'bind' H:\Work\boost-rc\libs\program_options\build\../src/convert.cpp(14) : error C2780: 'class boost::_bi::bind_t<R,struct boost::_mfi::cmf5<R,T,B1,B2,B3,B4,B5>,class boost::_bi::list6<class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R>,class boost::_bi::value<R> > > __cdecl boost::bind(R (__thiscall T::*)(B1,B2,B3,B4,B5) const,A1,A2,A3,A4,A5,A6)' : expects 7 arguments - 9 provided H:\Work\boost-rc\boost/bind/bind_mf_cc.hpp(151) : see declaration of 'bind' And so on. Any ideas what I can do to workaround this? The code itself works fine on every other compiler. - Volodya

2 2

RE: [boost] Re: Thread lib (good reason for static)
by Hurd, Matthew 09 Jun '04

09 Jun '04

> Behalf Of scott > Assume use of a technique like the following (think this has been > presented as "object shim"?); > > T & > anastasia() > { > static T *p = new T; > return *p; > } > > as a means of dealing with global construction issue, i.e. instead > of expressions like "anastasia.data_member" the usage is > "anastasia().data_member". Also assume that some of these global > objects (i.e. shims) deploy mutexes for MT reasons. What happens > when there is more that one thread running around making calls > to shims? Instantiation of the global itself becomes an MT issue. That's what the double-checked locking pattern for singletons is for. Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ 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.

4 3

regression test tools ported to vacpp
by Toon Knapen 09 Jun '04

09 Jun '04

The regression test tools are finally ported to vacpp version 6 and the regression test status will again be updated every day at 6am CET (unless new changes break the compilation again). Please don't hesitate to contact me when you want some help porting your boost library to the IBM/VisualAge platform. toon

3 5

CVS temporarily disabled
by David Abrahams 09 Jun '04

09 Jun '04

http://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1#1086711… ( 2004-06-08 09:17:17 - Project CVS Service ) As of 2004-06-08 at 09:16 Pacific, developer CVS services have been disabled for some unplanned maintenance. We do not currently have an ETA for the duration of this outage but we do hope to minimize it as much as possible. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

RE: [boost] Re: Thread lib (good reason for static)
by Hurd, Matthew 09 Jun '04

09 Jun '04

> Behalf Of Eric Niebler > Sent: Wednesday, 9 June 2004 9:15 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Thread lib (good reason for static) > > Hurd, Matthew wrote: > >>Behalf Of scott > >>Assume use of a technique like the following (think this has been > >>presented as "object shim"?); > >> > >>T & > >>anastasia() > >>{ > >> static T *p = new T; > >> return *p; > >>} > >> > >>as a means of dealing with global construction issue, i.e. instead > >>of expressions like "anastasia.data_member" the usage is > >>"anastasia().data_member". Also assume that some of these global > >>objects (i.e. shims) deploy mutexes for MT reasons. What happens > >>when there is more that one thread running around making calls > >>to shims? Instantiation of the global itself becomes an MT issue. > > > > > > That's what the double-checked locking pattern for singletons is for. > > > > Regards, > > > > Matt Hurd. > > > No, the double-checked locking pattern is only good as the subject of > talks describing why it's not good for anything. > > http://www.nwcpp.org/Downloads/2004/DCLP_notes.pdf Thanks. They are good notes. I'm aware of the portability issues. Doesn't mean you can't have valid platform specific singleton implementations that use the double checked locking pattern. The performance of the approach is too important to give up. Locking is slow. There are a lot of things you can't do portability in C++ which is one rationale for having libraries :-) Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ 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

boost::any question
by Trey Jackson 08 Jun '04

08 Jun '04

All, I just started looking at boost::any, pretty nice. I looked at the implementation, and it uses (as you know) a pointer to an object (w/virtual methods) on the heap, and typeid to determine if conversion is possible. I understand the memory implications (a new object copied on heap). But I'd like to get a better handle on performance, namely: I'm unfamiliar with typeid - and how it's implemented. Does anyone have good pointers to how typeid is generally implemented? Or even specifically: I'm using gcc3.x on RH Linux. I'd just like to avoid/guarantee I'm not going to be hit by some O(N) look-up for using typeid a lot. thanks, TJ -- Trey Jackson tjackson(a)ichips.intel.com "Her hair glistened in the rain like nose hair after a sneeze." -- Chuck Smith, Woodbridge

3 3

Problem with mpl::iter_fold_if.hpp in vacpp 6.0
by Joaquín Mª López Muñoz 08 Jun '04

08 Jun '04

Regression tests show the following at different locations: "/home/tk/boost_regression/boost/boost/mpl/iter_fold_if.hpp", line 104.11: 1540-0038 (S) The name "typename result_::state" is not a type. I don't know how easy to fix this can be (for those who know the internals of MPL). Currently, the problem breaks uBLAS and multi_index. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 4

Problem building bjam executable
by Bart Garst 08 Jun '04

08 Jun '04

I'm trying to build the bjam executable by running build.bat from the boost/tools/build/jam_src directory. Here's what I get: C:\BOOST\TOOLS\BUILD\JAM_SRC>build.bat vc7 ### ### "Unknown toolset: vc7" ### ### You can specify the toolset as the argument, i.e.: ### .\build.bat msvc ### ### Toolsets supported by this script are: borland, como, gcc, gcc-nocygwin, intel-win32, metrowerks, mingw, msvc, vc7 ### I also tried running vcvars32 prior to build.bat and got this: C:\BOOST\TOOLS\BUILD\JAM_SRC>"e:\program files\microsoft visual studio .net\vc7\bin\vcvars32" C:\BOOST\TOOLS\BUILD\JAM_SRC>"E:\Program Files\Microsoft Visual Studio .NET\Common7\Tools\"vsvars32.bat Setting environment for using Microsoft Visual Studio .NET tools. (If you also have Visual C++ 6.0 installed and wish to use its tools from the command line, run vcvars32.bat for Visual C++ 6.0.) C:\BOOST\TOOLS\BUILD\JAM_SRC>build.bat vc7 Setting environment for using Microsoft Visual Studio .NET tools. (If you also have Visual C++ 6.0 installed and wish to use its tools from the command line, run vcvars32.bat for Visual C++ 6.0.) The system is Windows NT 4.0 SP6. I'm using a fresh cvs checkout of the entire boost source tree. I'd appreciate any help I can get with this. Thx, Bart

3 4

[assignment library post review]
by Thorsten Ottosen 08 Jun '04

08 Jun '04

Dear All, The post review version can be downloaded from http://tinyurl.com/38c7d Since the review this has changed: 1. insert()/assign() functions has been renamed to reflect which function that is called. So now push_back() is used for vector etc. 2. One header for each standard container. 3. New functions to allow for direct initialization: vector<int> v = list_of(1)(2)(3)(4)(5); map<string,int> m = map_list_of( "Foo", 1 )( "Bar", 2 ); 4. New heavily improved documentation 5. Support for arbitrary functions s.t. new types can benefit from the syntax easily. 6. removal of all half-backed stuff that nobody wanted 7. arguments are forwarded by value instead of const-reference. Reference is a pain to deal with when it comes to string literals. 8. A real test-suite has been added 9. portability has suffered a bit, but that can be solved later. Any comments about docs/implementation are welcome. There is one major isssue we must resolve: What should we call this library. Here are some choices: 1. Initialization library 2. Assignment library 3. Populate library 4. List library I personally would like Boost.List because the library is all about making list for use in various context. best regards Thorsten

3 3

[prereview request][fsm]
by Andreas Huber 07 Jun '04

07 Jun '04

Dear Boosters I think boost::fsm has finally reached a state that is worthy of a formal review. The .zip can be found here: http://boost-sandbox.sf.net/fsm.zip The docs are also available online: http://boost-sandbox.sf.net/libs/fsm As always: Feedback is highly welcome. Regards, Andreas

20 187

[spirit] rule<> and copying
by Thorsten Ottosen 07 Jun '04

07 Jun '04

Hi, I've been using spirit for some config-file parsing. I have some questions: 1. why can we not copy a rule<> ? 2. if we shouldn't copy a rule, why is copying not disabled? It has been a source of errors in my code that I forgot & on my return value. br Thorsten

8 23

token_iterator comments, suggestions
by Gennadiy Rozental 07 Jun '04

07 Jun '04

Hi, For long time in my daytime projects I was using my class token_iterator designed based on old iterator_adaptor design (adopted for old compilers). Now when need arose for such functionality in Boost.Test. I looked in direction of boost::token_iterator. After some struggle I end up adopting my version to new design. Here some of comments and issues that made me opt so. 1. token_iterator follows in a sense a Policy-based design (PBD). Where TokenizerFunc is a Policy that implements most of the functionality. The problem here IMO (unfortunately you see it now quite frequently), that I do not see a reason to use such a design. PBD makes sense it your generic component do a lot of work, provide common interface, combine several independent policies. In this case most what token_iterator does is just a forwarding (it become especially clear if you switch to use input_iterator_adaptor). It wouldn't be that bad, but PBD in this case causes significant usability inconvenience. Instead of plain and simple: token_iterator it( "a:b", ":" ); I have to write something like: token_iterator<char_delimiters_separator<char> > it( char_delimiters_separator<char>( ":" ), "a:b" ). All of that just because we have separate notion of Tokenizer function. IMO it too big price to pay. My suggestion is to get rid of the TokenizerFunction notion. Just implement many different iterators with the same scope of interest: tokenization. We will need to find proper names for iterators and instead of TokenizerFunc model description we may have page explaining how to write custom token iterators (if necessary, which I doubt). 2. token_iterator deals with begin/end iterators. I understand that in some rare cases there is need to iterate over range of iterators (BTW, std::input_iterator gonna be bad example - did you ever tried to use token_iterator over it?). But in most case we want to tokenize a string. And in most cases it either std::string or [char|wchar_t] const*. The fact that Iterator is a template parameter makes token_iterator usage quite inconvenient. In most cases the only template parameter that is required is IMO character type. My suggestion: lets have 2 different types if token iterators: one to iterate over string and separate to iterate over range of iterators. 3. I found it confusing in many cases how delimiters gets specified in token_iterator: token_iterator( "...", ":", " " ) Which string represent dropped delimiters, which kept? And what if I just want empty tokens? I need to write token_iterator( "...", "", "", keep_empty_tokens ) What are these two empty strings doing here?My suggestion is to use named parameters scheme. Like this: token_iterator( "...", dropped_delimiters = ":", kept_delimiters = " " ); 4. 2 Tokenizer functions use Traits as *policy* parameter. What actually is required in Compare predicate, that may or may not be implemented using char_traits. While std::basic_string references inside tokenizer function implementation should refer to traits by name std::char_traits 5. What if I want to use isspace as kept delimiters policy? There is no way to specify that. IMO delimiter policy should be separated (as runtime policy). 6. You use iterator_category as a selector of assigner. It's better to use traversal instead 7. In many places you use #if !defined(BOOST_MSVC) || BOOST_MSVC > 1300 typename #endif use BOOST_DEDUCED_TYPENAME instead 8. What is the purpose of token_iterator_generator. I do not see a need for one with new iterator facade design. 9. Why would we need all the access methods? Iterator base()const{return begin_;} Iterator end()const{return end_;}; TokenizerFunc tokenizer_function()const{return f_;} Type current_token()const{return tok_;} bool at_end()const{return valid_;} I couldn't imagine why do we need them. 10 Token iterator asserts in attempts to dereference or iterate end iterator. I don't believe it's correct. In many cases (mostly in design that assumes some optional tokens in the end) it's much more convenient this does not happened. My suggestion is to return empty token on dereference and stay quite on iteration. 11. In simpler design there won't be need in template copy constructor for token_iterator 12. Documentation need to be updated IMO, cause even as things stands now it dies not represent the best practice moved from type generators usage. 13. Files under libs/tokenizer lacks any structure required by boost standards. 14. There is no real test suite only some small examples supplied. 15. Why escaped_list_separator was named this way. It seems strange to emphasize in a name the fact that it use escape symbols, while major separations is that it is CSV list iterator - and this is how I would name it I implemented string_token_iterator and range_token_iterator for use in Boost.Test. See here (in a couple hours) http://tinyurl.com/28db9 for implementation and here http://tinyurl.com/287uk for test suite. Regards, Gennadiy.

5 16

Serializer and when to stop
by Darren Cook 07 Jun '04

07 Jun '04

I'm using boost::serializer between two programs: the first creates the data then serializes it, the second loads that data in and analyzes it. When I had just 420 data samples it all worked fine: I create a vector<Sample> in memory, serialized it and loaded it in the other side. When I moved to 7000 data samples the first program, the creator, sucked all the memory from the machine and then some. So I moved to serializing each data sample as it was created. To read it back in I changed my code from this: std::ifstream input_file(fname,std::ios::binary); boost::archive::binary_iarchive archive(input_file); std::vector<Sample> samples; archive>>samples; input_file.close(); Into this: std::ifstream input_file(fname,std::ios::binary); boost::archive::binary_iarchive archive(input_file); std::vector<Sample> samples; samples.reserve(8000); while(!input_file.eof()){ Sample s; archive>>s; samples.push_back(s); } input_file.close(); But every time it fails with an assert [1]. This seems to be when it has reached end of file. I cannot know in advance how many data samples I'll write to disk, so it seems I have three options: A: Make a special "zero" version of Sample to mark end of file B: At end of program 1 write the number of samples to a special file, and read that in before starting the above loop, so I know when to stop. C: Alter the serializer class to throw exception instead of an assert; I can then catch it and carry on. What is the best way? Is adding a terminator byte to boost::serializer an option (i.e. so I don't have to make a terminator version of each data structure I want to serialize). Incidentally my above loop does a copy of each sample as it adds it to the vector. Is the above code going to be common enough to make it worth including into boost::serializer as a helper function, which could then be optimized with in-place construction or something clever like that? (And then it could handle the termination handling itself as well.) Darren [1]: /usr/local/src/boost_1_31_0/boost/archive/basic_binary_iprimitive.hpp:119: void boost::archive::basic_binary_iprimitive<Archive, IStream>::load_binary(void*, unsigned int) [with Archive = boost::archive::binary_iarchive, IStream = std::basic_istream<char, std::char_traits<char> >]: Assertion `count == static_cast<size_t>(is.gcount())' failed.

2 1

RE: [boost] Re: regression test tools ported to vacpp
by Rozental, Gennadiy 07 Jun '04

07 Jun '04

> Gennadiy Rozental wrote: > > > "Toon Knapen" <toon.knapen(a)fft.be> wrote in message > > news:40BF16BA.8080009@fft.be... > > > >>The regression test tools are finally ported to vacpp version 6 and > >>the > > > > I just spend half an hour to clean my code after this port. I do > > understand that you just wanted to make it work on your > compiler. But > > lets in a future first discuss it here on a list before you commit > > this kind of modifications. > > > > There was a discussion about all these issues for about a > week now with > clearly marked in the header that it was about the test > library. Since > you only responded to the last of the series of mails, I thought you > were OK with the other modifications. Yes. I was Ok with basic_cstring modification. Not the rest. I was actually hoped you (somebody familiar with PP) find a fix to IBM VA issues with BOOST_PP. As it stands now I simply disable access control for this compiler, what is wrong. > Generally I always contact the developer personally before > commiting a > change. However, I already have tried to contact you privately but I > never got a reply. It could be. I had to abandon three of my accounts lately. One because I moved. One because it's no longer free. One because it became unusable due to spam. Use gennadiy <dot> rozental <at> thomson <dot> com. > Anyway, in the future I will again try to contact you before > committing > soth. > > May I also ask to elaborate on what you found not to be clean > about the > port and how and why you changed these changes. This might be > interesting information for future ports. You couldn't just manually unfold macro definition all over the code. It makes code look like a mess IMO. See, what I did in cvs. Regards, Gennadiy.

1 0

Borland and BOOST_NO_FUNCTION_TEMPLATE_ORDERING
by Robert Ramey 07 Jun '04

07 Jun '04

Using Borland 5.5 I compile the following: #ifdef BOOST_NO_FUNCTION_TEMPLATE_ORDERING #error "NO function template ordering supported" #else #error "YES function template ordering supported" #endif And I get: Fatal F1003 c:\boost_1_31_0\libs\serialization\test\test_zmisc.cpp 4: Error directive: "YES function template ordering supported" Yet C:\boost_1_31_0\more\borland_cpp.html seems to suggest that I should get NO. What am I missing here? Robert Ramey

2 1

RE: [boost] Re: input_iterator_facade (was: Re: [iterator facade] Why isdereference const?)
by Rozental, Gennadiy 07 Jun '04

07 Jun '04

> I guess we're back to your old disagreements about > flexibility. Flexibility is > fine, but it adds complexity, both for implementors and the user, so > flexibility should be added only when absolutely necessary. > The eof_iterator > is intented to be as simple as possible. > > - Volodya Actually after some consideration I incline to agree with you on most points. Look in cvs on how my version looks now. Gennadiy.

2 1

[assign library post review again]
by Thorsten Ottosen 07 Jun '04

07 Jun '04

Dear all, a new zip file can be downloaded in the files section in the assignment folder: http://f3.grp.yahoofs.com/v1/4NHBQHrGLW_kAudslwozEsdMfU_iY8Ja3CZu5N40ZMlffd… or http://tinyurl.com/27ldw We still need to find a name. If nobody else besides Pavel and Tom has an opinion, I will go for Boost.Assignment with a majority vote of 2 to 1. br Thorsten

3 3

Re:[boost] Serializer and when to stop
by Robert Ramey 06 Jun '04

06 Jun '04

Darren Cook wrote: > I'm using boost::serializer between two programs: the first creates the > data then serializes it, the second loads that data in and analyzes it. > When I had just 420 data samples it all worked fine: I create a > vector<Sample> in memory, serialized it and loaded it in the other side. > When I moved to 7000 data samples the first program, the creator, sucked > all the memory from the machine and then some. 7000 samples? That doesn't seem very large in today's environment. I can't see why creating an archive should consume any significant memory at all. Nothing significant is constructed. Perhaps is a bug somewhere. In any case, you do raise in interesting issue which would crop up if serialization were used in something like data logging. > So I moved to serializing each data sample as it was created. > To read it back in I changed my code from this: > std::ifstream input_file(fname,std::ios::binary); > boost::archive::binary_iarchive archive(input_file); > std::vector<Sample> samples; > archive>>samples; > input_file.close(); > Into this: > std::ifstream input_file(fname,std::ios::binary); > boost::archive::binary_iarchive archive(input_file); > std::vector<Sample> samples; > samples.reserve(8000); > while(!input_file.eof()){ > Sample s; > archive>>s; > samples.push_back(s); > } > input_file.close(); > But every time it fails with an assert [1]. This seems to be when it has > reached end of file. I cannot know in advance how many data samples I'll > write to disk, so it seems I have three options: > A: Make a special "zero" version of Sample to mark end of file > B: At end of program 1 write the number of samples to a special file, > and read that in before starting the above loop, so I know when to stop. > C: Alter the serializer class to throw exception instead of an assert; > I can then catch it and carry on. I think I changed the assert/exception to check before loading rather than after for the next version. This would permit your code above to work as you expect. I'll have to double check. > What is the best way? Is adding a terminator byte to boost::serializer an > option (i.e. so I don't have to make a terminator version of each data > structure I want to serialize). > Incidentally my above loop does a copy of each sample as it adds it to > the vector. Is the above code going to be common enough to make it worth > including into boost::serializer as a helper function, which could then > be optimized with in-place construction or something clever like that? > (And then it could handle the termination handling itself as well.) The default implementation of STL collections create a new element on the stack and copy into the collection. Its as clever as I can make it without getting tripped up in things like exception safety, objects without default constructors, etc. Robert Ramey

2 1

Wave/flex_string and replace< InputIterator > bug
by Reece Dunn 05 Jun '04

05 Jun '04

Hi all, I am implementing test cases to validate the implementation of my fixed_string class and basic_string_impl (based on flex_string) and noticed a defect in the implementation of: template< typename InputIterator > inline string_type & replace( iterator i1, iterator i2, InputIterator j1, InputIterator j2 ); It handles the Integral case fine, but when the InputIterators are actually iterators, it asserts false, where the standard dictates it returns: replace( i1, i2, basic_string( j1, j2 )); or equivalent behaviour, e.g. in the implementation I'm using: replace( i1, i2, std::distance( j1, j2 ), char_type()); std::copy( j1, j2, i1 ); Is there any specific reason for this, or is it an implementation bug? Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

3 2

Re: [Boost-announce] Formal Review Tribool
by Haim Cohen 05 Jun '04

05 Jun '04

Hi, I am happy to contribute my review for the tribool library. I am a software engineer developing EDA (Electronic Design Automation) software, so I think I can contribute my 2 cents to the review of tribool, as I think EDA tools will benefit from this library. I did not compile the library. I have made a quick reading of this library, but an in-depth study of this problem domain before. First of all, my first comment is about the library's name, as well as the class name. In logic circuit simulation, there are 4 values : 0, 1, x ( which is tribool referred to as undetermine ), and z ( represents high impedance - or disconnection, and sometime referred to as "tri state" ). So, I think users will find it quite confusing when they see the 'tri' in the library's name. Since the library implements a logic value which has some value that is unknown, I would suggest 'unknown bool' or 'x bool'. Now to the interface. I think that a macro which enables renaming of the x value should not be supplied. This will make people's code less standard. Same as we all know what 'true' and 'false' mean, we should adopt a unique name for 'unknown yet quite determined logic value'. I think the default 'undetermine' name is not a good name. My suggestions : logic_x, x_value, x_logic, unknwon_bool . I also think the default tribool constructor should create a tribool object which is 'undetermine'. (Not false, as in the documentation) Besides the above, I think the interface of the class is good and succinct. Some point for thought : Users might want arrays of tribools, with all the support of bitwise operations. Is this should be a part of tribool as well ? I do not know. Now I will refer to the implementation. In real-life problems, programs might make a heavy usage of the tribool class for simulations of logic circuits. A logic circuit (at least the combinatoric part) is a DAG where nodes are logic gates, and directed archs are wires. This graph might be the result of a synthesis process, where a high level language for hardware description (e.g Verilog) is compiled into this DAG. Note : This is a very general and simple description of the process. Life are much more difficult. So, outputs will be calculated by performing lexicographic order of the DAG, and calculating from inputs to outputs. I am telling this, to convince that performance is *very* important here. With a quick look at the implementation code, I think that calculating the value using branches (if else) will not result with good performance. Calculations with true/false values only is fast - CPU vendors dedicate special hardware for this, so calculation can be made in one machine cycle. Even bitwise calculation (up to some word width) is done in one machine cycle. Compilers are making use of this, and (hopefully) compiles boolean and bitwise operators to the appropriate instruction. Unfortunately, I did not see any CPU which supports built in true/false/X arithmetic. And even if there are such CPUs available, we will not be able to use it, since boost libraries should be portable. So, it is very tempting to think - how can we implement efficient true/false/X arithmetic using the existing boolean arithmetic ? One tempting idea is to represent true/false/X with some integers, and use bitwise arithmetic to get the right results. It seems there are no such integer values. I think I even managed to proof this. Since there is already a library implementing 4 values logic (0,1,x,z) - which is SystemC - I took a quick look on how they do it with their 4-states logic data type called sc_logic. They use an approach which I think should be also used in tribool. It seems that they maintain lookup tables for each operation: AND, OR, NOT, XOR (!=) and XNOR (==). As the internal representation of tribool is enumerated type, we can use the integer value of this enumerated type to access the lookup tables (primitive 2D fixed-size and fixed-values arrays) and get the result of the calculation. This will be much faster since most CPUs has a special addressing mode for accessing arrays. So, I suggest to change implementation to use class-static fixed array to perform calculations. I know that the spirit of Boost is portability and not performance, but since what is suggested here is actually very similar to a primitive data type which might be heavily used in applications, I think it is important to consider performance as well. I hope this review would be found useful. Haim -- _____________________________________________________ Haim Cohen Software Engineer haim.cohen(a)analog.com / haimcohen2002(a)hotmail.com Analog Devices Israel (972) - 9 - 9715 406

4 4

Re:RE: [boost] serialization request
by Robert Ramey 05 Jun '04

05 Jun '04

Jeff Garland wrote: > > Robert Ramey wrote: > > > > >Russell Balest wrote > > > > > >>Does someone know where in the code I can implement this easily. > > >>I just want to ignore the comments. > > >> > > >easy to accommodate. Just create a use the following in your > > >serialize > > >functions: > > > > > >Template<class Archive> > > >Void serialize(Archive, my_class & t){ > > > std::string comment; > > > ar & BOOST_NVP("comment", comment); > > > ar & BOOST_NVP("myclass_data", t);; > > >} > > > > > >In which case your XML output will look like: > > > > > >... > > ><comment></comment> > > ><myclass_data>..contents of t</myclass_data> ... > > > > > > > > > > > Good idea. I'll probably do that. > Another approach would be to preprocess your input files and strip the > added comments using XSLT, perl, or a simple regex program. That way you > don't have to modify the data structures under test. Someone might complain that my original method has 2 inconvenience features a) it requires modification to the serializations b) it includes the (null) comment string place holder in all the archives including the binary one. So another alternative would be to derive from the included xml_?archive classes included in the package and redefine the override for named-value pair so that it inserts/extracts  before or after every tag. This method has the following features: a) doesn't require any kluging up of class serializations b) has the advantage of automatically includes the  for all object instances c) has the disadvantage of automatically includes the  for all object instances d) doesn't add any overhead in other archives. If c) above is intolerable you would have the option of making your own wrapper similar to NVP - (NVT) that you would use in your serializations rather than NVP whenever you wanted a comment place holder. That's really a variation on my first suggestion. Take your pick and good luck Robert Ramey

1 0

question about logging into CVS
by Robert Ramey 05 Jun '04

05 Jun '04

I'm trying to build/update the CVS development tree on my machine and I can't get in. Here is my command line and response. What magic am I missing here? It seemed I had this problem some time ago and it just went away after a time. This time I've tried a few times over the lat 24 hours with always the same result. Robert Ramey cvs -d :pserver:anonymous@cvs.boost.sourceforge.net:/cvsroot/boost login Logging in to :pserver:anonymous@cvs.boost.sourceforge.net:2401:/cvsroot/boost cvs [login aborted]: connect to cvs.boost.sourceforge.net:2401 failed: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

2 1

Formal Review Tribool
by Thomas Witt 05 Jun '04

05 Jun '04

The review of Douglas Gregor's Tribool library begins now and runs through Saturday, May 29. Here is a short introduction to the library: The 3-state boolean library contains a single class, boost::logic::tribool, along with support functions and operator overloads that implement 3-state boolean logic. The tribool class acts like the built-in bool type, but for 3-state boolean logic. The three states are true, false, and indeterminate, where the first two states are equivalent to those of the C++ bool type and the last state represents an unknown boolean value (that may be true or false, we don't know). When reviewing the library, please remember to include: * What is your evaluation of the design? * What is your evaluation of the implementation? * What is your evaluation of the documentation? * What is your evaluation of the potential usefulness of the library? * Did you try to use the library? With what compiler? Did you have any problems? * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? * Are you knowledgeable about the problem domain? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. The library is available in the Boost files area as tribool-20031026.tgz Thank you, Thomas Witt -- Thomas Witt witt(a)acm.org

6 6

Re:[boost] Re: Re:A question on serialization library
by Robert Ramey 05 Jun '04

05 Jun '04

Virendra Verma wrote: > Library woundn't care but the user would. For example, how would user > delete or modify the object (pointed by pointer in the class) once > loaded since user has no way of knowing how the object was allocated? My > understanding is that the library creates and owns the object (using some > kind of class factory) when loading from input stream unless user keeps a > common allocator and somehow binds it to library's serializer. > > > If a class has a pointer to an object, how does class know that the > > > pointer was created by library or the class itself before > > > serialization? > > > It doesn't. Why would it need to? > > > Robert Ramey The guiding principle behind saving/loading pointers is that the loaded set of C++ structures is exactly equivalent to the original ones that were saved. So issues regarding pointer ownership don't change. That is, whatever ownership policy that was used when the pointer was saved will be the same one that can be used for the set of C++ structures recovered. The only problem would be where the there are pointers that are not included in the set of serialized data. As long as the serialized set is complete and self-contained there should be no problem. That is, there should be no pointers pointing into the serialized data that are themselves not serialized. Robert Ramey

1 0

boost::ref implicit conversion operator overload problems
by Jonathan Graehl 05 Jun '04

05 Jun '04

If I pass a boost::ref to a template function that calls operator() with one argument, the conversion to T& isn't used to find matching functions. The problem seems to also exist for other overloaded operators. What should I do in this case? I thought the idea was for the ref to be transparent to the template code you pass it to. As a stopgap, I wrote template functions "deref" that must be applied at the calling site (these just cast using unwrap_reference). This code works, but if you remove the "deref", doesn't compile under GCC or visual c++: #include <boost/ref.hpp> #include <cassert> template <class T> inline typename boost::unwrap_reference<T>::type & deref(T& t) { return t; } template <class T> inline const typename boost::unwrap_reference<T>::type & deref(const T& t) { return t; } struct Setter { int i; void operator()(int j) { i=j; } Setter() : i(0) {} Setter(int j) : i(j) {} }; template <class F> void apply1(F f) { deref(f)(1); } int main() { Setter s; apply1(s); assert(s.i == 0); apply1(boost::ref(s)); assert(s.i == 1); }

2 1

bug - function.hpp missing include guard - see sourceforge patch
by Nicolas Desjardins 05 Jun '04

05 Jun '04

Dear Boost Developers, I've submitted a patch to your sourceforge patch section - item # 966723. The patch is also attached to this mail. Summary: function.hpp missing include guard patch function.hpp does not have an #ifndef/#endif include guard. This patch adds #ifndef BOOST_FUNCTION_HPP at the top of the file and #endif at the bottom. Thanks, Nicolas Desjardins Software Developer Orthosoft Inc. *** function.hpp.original 2004-06-04 13:54:25.000000000 -0400 --- function.hpp 2004-06-04 13:53:54.000000000 -0400 *************** *** 10,15 **** --- 10,16 ---- // William Kempf, Jesse Jones and Karl Nelson were all very helpful in the // design of this library. + #ifndef BOOST_FUNCTION_HPP #include <boost/preprocessor/iterate.hpp> #include <boost/detail/workaround.hpp> *************** *** 62,64 **** --- 63,67 ---- # include BOOST_PP_ITERATE() # undef BOOST_PP_ITERATION_PARAMS_1 #endif + + #endif // BOOST_FUNCTION_HPP

2 1

Re:[boost] serialization request
by Robert Ramey 05 Jun '04

05 Jun '04

Russell Balest wrote > My request is support for xml  in the serialization > xml archive. I believe it currently chokes if I add a comment in an xml > archive. > The application is for QA to compose test objects in xml and then > read them into applications with boost serialization. > It would be nice to annotate the test object 'templates' with comments > so QA can know what values are valid. > Does someone know where in the code I can implement this easily. > I just want to ignore the comments. Hmmm - my question is: What program is generating the XML archive in the first place? It its being generated by something other than the serialization library itself, its not going to be easy to generate such an archive that is guaranteed to be compatible with the C++ data structures of the reading program. (The organization of the data in the C++ program is what dicates the XML schema). At best it would be a maintenance pain in the neck to keep the reading program based on serialization in sync with some other program that doesn't use serialization to generate the XML archive. On the other hand, if the original XML archive is generated by the serialization library and just modified with comments, your request is very easy to accommodate. Just create a use the following in your serialize functions: Template<class Archive> Void serialize(Archive, my_class & t){ std::string comment; ar & BOOST_NVP("comment", comment); ar & BOOST_NVP("myclass_data", t);; } In which case your XML output will look like: ... <comment></comment> <myclass_data>..contents of t</myclass_data> ... After the archive is created you can edit the space between <comment> and </comment> with anything you want - it would be just thrown away. Generally I wouldn't encourage the practice of editing an archive but in this circumstance I could see it as an acceptable practice. But then this raises the question if the comments are so important, why are they being thrown them away? Shouldn't they be data read by the program? Robert Ramey

3 2

Re: Boost Mathematicians
by Michael D. Crawford 05 Jun '04

05 Jun '04

I have a bachelor's degree in physics, with the intention to go back to school and get a PhD someday. One thing I've had in mind for quite some time is to improve the state of high-energy physics software. Maybe it's improved since I was last in school, but when I did my senior thesis in 1993 the software I worked with was an awful mess. At the time I became convinced that bogus results were being published in the peer-reviewed journals because of undetected software bugs. Mike -- Michael D. Crawford GoingWare Inc. - Expert Software Development and Consulting http://www.goingware.com crawford(a)goingware.com Tilting at Windmills for a Better Tomorrow. "I give you this one rule of conduct. Do what you will, but speak out always. Be shunned, be hated, be ridiculed, be scared, be in doubt, but don't be gagged." -- John J. Chapman, "Make a Bonfire of Your Reputations" http://www.goingware.com/reputation/

4 3

Filesystem patch
by John Maddock 05 Jun '04

05 Jun '04

Beman, I'm committing a patch (below) for my last filesystem patch, basically I've found another reason why GetFileAttributes can fail when the file does not exist. John. $ cvs diff -u johnmaddock(a)cvs.sourceforge.net's password: cvs diff: Diffing . Index: operations_posix_windows.cpp =================================================================== RCS file: /cvsroot/boost/boost/libs/filesystem/src/operations_posix_windows.cpp, v retrieving revision 1.33 diff -u -r1.33 operations_posix_windows.cpp --- operations_posix_windows.cpp 30 Mar 2004 15:19:58 -0000 1.33 +++ operations_posix_windows.cpp 5 Jun 2004 11:47:23 -0000 @@ -321,10 +321,12 @@ # else if(::GetFileAttributesA( ph.string().c_str() ) == 0xFFFFFFFF) { - if((::GetLastError() == ERROR_FILE_NOT_FOUND) || (::GetLastError() == ERROR_PATH_NOT_FOUND)) + UINT err = ::GetLastError(); + if((err == ERROR_FILE_NOT_FOUND) || (err == ERROR_PATH_NOT_FOUND) || (err == ERROR_INVALID_NAME)) return false; // GetFileAttributes failed because the path does not exist // for any other error we assume the file does exist and fall through, // this may not be the best policy though... (JM 20040330) + return true; } return true; # endif

1 0

Recent changes to minimal.hpp break dynamic_bitset and other libraries
by Gennaro Prota 05 Jun '04

05 Jun '04

Sorry for not investigating this myself, but I really don't have time to. It seems that the recent changes to boost/test/minimal.hpp (line 99, invocation of BOOST_READONLY_PROPERTY) cause troubles on IBM AIX. Many library tests seem to fail for that reason: http://boost.sourceforge.net/regression-logs/cs-AIX.html Genny.

2 1

scoped_ptr<T, D>
by Robert Ramey 05 Jun '04

05 Jun '04

Why isn't there a version of boost::scoped_ptr<T> that takes a deleter? That is, why isn't there scoped_ptr<T, D> ? It would be useful to me. Robert Ramey

3 3

FSM idea injetion
by Alexander Nasonov 05 Jun '04

05 Jun '04

Although my idea is supposed to solve multimethod support for dynamic_any it might be useful in FSM library. What I'm trying to build in last two weeks is some sort of typelists for overloaded function set. Each function is identified by overload_id<N> class with unique N. For example: struct read_number_transitions { // Signatures has the form NewState (OldState, Char) Positive operator()(overload_id<0>, StartState, Plus) const; Negative operator()(overload_id<1>, StartState, Minus) const; Positive operator()(overload_id<2>, StartState, Digit) const; Positive operator()(overload_id<3>, Positive, Digit) const; Negative operator()(overload_id<4>, Negative, Digit) const; static std::size_t const max_overload_id = 4; }; This approach has advantage over typelists in some cases because things are right in their places. In the example, every transition, on one hand, is represented by a call operator (this is natural, because transition is a function that takes old state and a char and returns a new state); on the other hand, argument types and return type (a signature) can be retrieved from the call operator. The retrieval is a bit problematic but I'm working on this. The problem is a lack of typeof in C++. If it were available you could write: template<int N, class C, class R, class T> mpl::identity<R(T)> tester(R (C::*)(overload_id<N>, T) const); typedef typeof(tester<0>(&read_number_transitions::operator()))::type sig0; Without typeof you know signature R(T) only inside tester<0>. This means in particular, that, in order to accumulate all signatures you have to call tester<N> recursively: call tester<0> => Positive(StartState, Plus) call tester<1> => Negative(StartState, Minus) call tester<2> => Positive (StartState, Digit) call tester<3> => Positive (Positive, Digit) call tester<4> => Negative (Negative, Digit) For other compile-time algorithms we need something similar. Even worse, often we need chain of algorithms, for example: find a first occurrence of StartState as a first argument, get a return type from that signature, find that type among first arguments and so on. We have to go deeper and deeper. In my stress tests I use 1000 functions. Can you imagine a call stack as deep as 1000 multiplied by a length of algorithms chain? Fortunately, sometimes it's possible to make it plain. 1. Predicates have boolean result, therefore, we can use sizeof/yes_type/no_type to calculate their result: template<class Predicate, int N, class C, class R, class T> typename yes_type_if< Predicate::template apply<R(T)>::type // mpl::apply style >::type tester(R (C::*)(overload_id<N>, T) const); // Example bool const result = sizeof( tester<is_same<Positive(Positive,Digit), _1>, 3>(&read_number_transitions) ) == sizeof(yes_type); I already implemented several variants of *contains* algorithm. You can take a look at g++ 3.4.0 performance here: http://cpp-experiment.sourceforge.net/overloads_contains.png This is a performance plot (in seconds) of various strategies for *contains* algorithm which is applied to a function set of length 1000. Worst case takes 80+ seconds to compile for *one-at-once linear* basic strategy while optimized strategy completes its job in 12 seconds. It's really fast. I doubt that typelist of length 1000 can ever exist without compiler panic ;-) Similar work can be done for find/find_if // returns bool contains<read_number_transitions, Negative(Negative,Digit)>::value; // returns index of Negative(Negative,Digit) find<read_number_transitions, Negative(Negative,Digit)>::value; // returns -1 because int isn't even a signature find_if<read_number_transitions,is_same<int, _1> >::value; 2. Pair comparisons. It's not yet done. The sizeof trick can be modified slightly: template<class Predicate, int N, int M, class C, class R1, class R2, class T1, class T2> typename yes_type_if< Predicate::template apply<R1(T1), R2(T2)>::type >::type tester( R1 (C::*)(overload_id<N>, T1) const, R2 (C::*)(overload_id<M>, T2) const ); Suppose, you have this cool type: typedef is_base_and_derived< function_arg<1, _1>, // first argument of signature _1 function_arg<1, _2> // first argument of signature _2 > cool; Then you can check whether a first argument of overload N is a base of a first argument of overload M: bool const result = sizeof( tester<cool,N,M>(&read_number_transitions, &read_number_transitions) ) == 1; -- Alexander Nasonov

2 3

default version of STLport
by Gennadiy Rozental 05 Jun '04

05 Jun '04

Why don't we switch to 4.6.2 as default version of STLport? Which version is used in regression tests? Gennadiy.

1 0

Re: [boost] Re: iostreams library review
by slavek.f.kuzniar＠jpmorgan.com 05 Jun '04

05 Jun '04

I downloaded the library from the yahoo link you mentioned in the review request. When trying to use 'filtered_stream' I ran into some compilation issues (RedHat 9, g++ 3.3) and before looking into it I wanted to know the review status. Knowing that the library is in the review pipeline I will give it another try. Some time ago I developed simple iostream adapter 'library' that allows to wrap IO device (sockets, pipes, etc) in std::[i,o,io]stream that is very similar to your sink/source technique. One difference is that the adapter is a template class parameterized by the source/sink types. Since your library offers this functionality (plus much more) I am very pleased it will become part of boost soon. technews@kangarool ogic.com To: boost(a)lists.boost.org Sent by: cc: boost-bounces@list Subject: [boost] Re: iostreams library review s.boost.org 05/29/04 06:41 PM Please respond to boost <slavek.f.kuzniar(a)jpmorgan.com> wrote in message news:OFF5E3130C.48F086BB-ON85256EA2.004FA2A3@ny.jpmorgan.com... > On Boost mailing archives I found a review request for Iostreams Library > by Jonathan Turkanis. I did not see any follow-up and the library is not > part of latest release so I suspect the review did not happen. Anyone knows > what is the fate of this library? Thanks for your interest! The previous version available at http://www.xmission.com/~turkanis/iostreams/. I've since made some major simplifications and improvements, and am scrambing to update the docs. It now contains support for memory-mapped files (from Craig Henderson) and for compression and decompression in the zlib, gzip and bzip2 formats. Jonathan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.

3 9

Re: [boost] Re: New utility at boost/detail/allocator.hpp
by JOAQUIN LOPEZ MU?Z 04 Jun '04

04 Jun '04

----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Viernes, Junio 4, 2004 8:39 pm Asunto: Re: [boost] Re: New utility at boost/detail/allocator.hpp > From: Joaquin M Lopez Munoz <joaquin(a)tid.es> > > Rob Stewart <stewart <at> sig.com> writes: > > > From: Joaquin M Lopez Munoz <joaquin <at> tid.es> > > > > > > > > For these reasons, I think allocator_rebind is not an > > > > appropriate name. Anyone suggesting a better name than > > > > allocator_helper? (Andreas? you wanted to use this stuff) > > > > > > Why not simply allocator_utilities.hpp? > > > > Yes, sounds good. Same name for the namespace > > (boost::detail::allocator_utilities)? Isn't it > > a little long? > > Any reason why the ns can't be "allocator?" This code will > coexist with any allocator library that may appear, I should > think, and these should interoperate with such a library; it > might even become part of such a library. I can't see a problem > with them sharing a ns. (That also suggests that the directory > for the header is boost/allocator/detail.) > That's too bold IMHO. We don't even know how a potential future allocator library might look like to impose it to receive this: more than a bequest to that library, this stuff could be an inconvenient burden. So, I propose boost/detail/allocator_utilities.hpp boost::detail::allocator Later on, we're still free to move (or alias) this into boost::allocator if it fits into that future allocator lib. What do you think? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] static sized strings
by Reece Dunn 04 Jun '04

04 Jun '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Martin wrote: > > >2. Substrings > > >------------- > > >One of the applications I can see for fixed_string is when you want to > > >avoid > > >dynamic allocation but still want to use the std::string interface and > > >algorithms. In that perspective it seems strange that substr returns a > > >std::string instead of a fixed_string. > >Agreed. I agree too. It is just that the current implementation cannot create an instance of boost::char_string (because of the ABC - necessary to allow operations on variable-capacity strings). Also, you cannot get at the fixed_string type/length at compile time so it is not possible to derive the *return type* at compile time. > > This is related to the above problem. You cannot create an instance of > > boost::char_string, etc. and as such cannot implement substr in the >usual > > way (this is the proplem I was having with operator+). The solution >would be > > to defione an alternate substr function in fixed_string, but this would >not > > solve the problem for boost::char_string, etc. > > > > The alternative would be to use a ranged string (pointer to the >fixed_string > > buffer and length), but the problem with this is null-termination. > > > > I do not see an easy way around this without removing the ABC design, >since > > it is not possible to do fixed_string< length() > or something similar. > >Couldn't substr() be a pure virtual function in char_string that >deferred to the derived class to create a copy of itself? The >derived class can just create a duplicate of itself, including >the current capacity. That capacity is guarranteed to be >sufficient to hold any substring requested. The return type cannot be boost::fixed_string_base because of the whole ABC issue. Therefore, the return type needs to be a reference or a pointer. It is possible to do this, and have: class fixed_string { inline fixed_string_base & substr_( size_type pos, size_type n ) { return( this_type( *this, pos, n )); } }; This is problematic because of returning the address of a temporary - and leads to unpredictable output. I am looking for a better solution to this. I am also thinking about how to remove the ABC from the implementation using a technique pointed out by someone on this thread (can't remember who): class fs_base { size_t len; szie_t capacity; // needed for buffer-safe operations CharT str[ 1 ]; // string manipulation functions fs_base( size_t c ): capacity( c ){} }; template< size_t n > class fixed_string: public fs_base { CharT data[ n ]; fixed_string(): fs_base( n ){} }; I'll need to look into this, to see what effect this will have, to see if it is a possible replacement for the ABC. What do other people think? Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

3 3

more_io_4 in Files area
by Daryle Walker 04 Jun '04

04 Jun '04

The latest version of More-I/O is in our YahooGroups Files area at <http://groups.yahoo.com/group/boost/files/more_io_4.zip>. This should be the version to be used for the upcoming (second) review. I built this version before my recent hard-drive reformat and OS upgrade, and I haven't tested it yet on my new system. Quick portability checks would be appreciated. I noticed that some reviewed libraries put their code up on the (login-free) web space SourceForge reserved for the Sandbox CVS. How is that done? Does an administrator need to give me special access? (I already have read and write access to the CVS part of the Sandbox.) Contents: * I/O Manipulators * expansions of endl The "new line then flush" function was generalized with optional flushing, repeat amounts, and selectable breaking characters. Streams can output characters belonging to their character type, but also of type "char" (no matter what "char_type" is). The "multi_basic_newer" class template works with a specific "char_type", but any "traits_type". The "multi_newer" class works only with "char" values, but any "char_type" and "traits_type". The "multi_newl" works as an easy way to use "multi_newer". And "newl" encapsulates the most common case of "endl" - "flush". * input-oriented variations of endl Instead of writing a new line, these manipulators read (and ignore) lines instead. These work similarly to their output-oriented counterparts: "multi_basic_skipper", "multi_skipper", "multi_skipl", and "skipl". * basic non-oriented The "resetios" manipulator defaults most of a stream's formatting attributes. * complex non-oriented The "basic_ios_form" class template can encapsulate several simultaneous formatting changes in a potentially reusable object. Configurations of such objects can be done in a progressive manner. * Stream-buffer wrappers Creating new stream types generally involving making a custom stream buffer class, then connecting it to a generic stream class shell. The wrappers "basic_wrapping_istream", "basic_wrapping_ostream", and "basic_wrapping_iostream" help with the latter. These are used by all of the streams given later in this library. * Elementary streams * null-stream ("onullstream", etc.) Acts as an infinite character destination and an empty character source, like "/dev/null" * value-stream ("ivaluestream", etc.) Acts as an empty character destination and an infinite character source, like "/dev/zero" (The returned character is configurable.) * Character buffer streams (legacy of strstream) The std::basic_stringstream family works as an modernized substitute for std::strstream most of the time, but it's overkill when the dynamic memory nature isn't needed. The following class templates fill in the missing modes of the (surprisingly overloaded) std::strstream family. * run-time specified character buffer ("pointerstream", etc.) Only uses the character buffer given to it at construction time, gives EOF instead of going to dynamic memory management when full. There is a variant for constant buffers (read-only, of course). These classes are essential when an existing buffer can be used without forcing a copy (e.g. larger than 50% of RAM). * compile-time specified fixed-size character buffer The "basic_array_streambuf" class template uses an internally contained array as the character buffer. More convenient than the previous class when the maximum buffer size is fixed at compile time and there is little need for sharing the buffer. Changes from the last interim version (called "more_io_3b.zip"): * split the manipulator header into several headers * refined the license statements in some already-affected files Changes from the first formal review (called "more_io.zip"): * refined the interface and implementation of array-streams and stream-buffer wrappers (including a wrapping example) * added the null-stream, value-stream, and pointer-stream headers * added generalizations to the new-line and skip-line manipulators * added the non-oriented 'reset' and 'form' manipulators * split the manipulator header into several headers * changed the license statements -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 2

Re: [boost] Re: New utility at boost/detail/allocator.hpp
by JOAQUIN LOPEZ MU?Z 04 Jun '04

04 Jun '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> > Joaquín Mª López Muñoz <joaquin(a)tid.es> writes: [...] > > is in boost::detail::allocator), I don't have any problem with > renaming to > > allocator_helper (it's a better name, actually.) If no one else > objects (which > > I doubt) I'll apply the name change tomorrow. > > I think allocator_rebind would be a much better name than > allocator_helper. > Ummm, the problem with allocator_rebind is that the header contains some other stuff not strictly related to rebinding: * partial_std_allocator_wrapper * construct (allocator-independent construction function) * destroy (allocator-independent destruction function) ?? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

[iterator + lambda] transform_iterator and lambda expression
by Vladimir Prus 04 Jun '04

04 Jun '04

I'm again trying to use FP in C++, and having problems. What I wanted to do was: for_each(predecesor(v, g), /* BLL expression */ ); where predecessor(..) returns a pair of 'transform_iterator' instances. The simplest example which illustrates the problem is: struct functor { typedef int result_type; int operator()(int i) const { return i+1; }; }; transform_iterator<functor, vector<int>::iterator> it(v.begin()); (cout << _1)(*it); This does not compile, because operator* of transform_iterator return rvalue which can't be bound to non-const reference that operator() of the lambda expression accepts. Of all workarounds suggsted on BLL docs, only break_const is applicable to my case (I want to pass non-const references to the lambda, so const_parameters won't do), and break_const is scary. It looks like a serious problem with using FP, so I wonder what can be done. Maybe, transform_iterator should have yet another template parameter telling if it should store a value internally, and return reference (i.e. lvalue) in that case? It need not be enabled by default, but functions like my 'predecessor' above would make use of that extra template parameter. - Volodya

4 8

Re:[boost] A question on serialization library
by Robert Ramey 04 Jun '04

04 Jun '04

Virendra Verma wrote: > If a class has a pointer to an object, how does class know that the > pointer was created by library or the class itself before serialization? It doesn't. Why would it need to? Robert Ramey

2 1

transform_iterator( Iterator const& x ) ???
by David Abrahams 04 Jun '04

04 Jun '04

I'm not sure why I never saw this on the list, but since I saw the moderation request and I figure you deserve a reply... boost-owner(a)lists.boost.org writes: > From: "Sascha" <vudu(a)gmx.net> > Subject: boost::transform_iterator( Iterator const& x ) ??? > To: <boost(a)lists.boost.org> > Date: Thu, 3 Jun 2004 00:22:18 +0200 > > hi > > a simple question about the construction of > boost::transform_iterator. > > currently there are two ctors implemented: > > transform_iterator(); > transform_iterator(Iterator const& x, UnaryFunction f); > > why does boost::transform_iterator(Iterator const& x) not exist leaving > the function object default constructed? Are you looking at the source code or the documentation? Oh, I see you're doing as you should and looking at the documentation! Well it turns out that the source code actually contains this constructor: explicit transform_iterator(Iterator const& x) : super_t(x) { // don't provide this constructor if UnaryFunction is a // function pointer type, since it will be 0. Too dangerous. BOOST_STATIC_ASSERT(is_class<UnaryFunction>::value); } > can I add it without getting in trouble? No, but we can fix the documentation ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[Boost-bugs] [ boost-Bugs-966496 ] [BGL] Asymmetry between read_graphviz() and write_graphviz()
by SourceForge.net 04 Jun '04

04 Jun '04

Bugs item #966496, was opened at 2004-06-04 06:02 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=966496&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: [BGL] Asymmetry between read_graphviz() and write_graphviz() Initial Comment: During some experiments with the BGL-GraphViz interface, I observed a significant asymmetry between a given DOT graph input with boost::read_graphviz() and output with boost::write_graphviz() (without changing any attributes). Given the input DOT file <metro.dot> (which is, of course, much longer with the full set of information), the elementary BGL program <metro.cxx> transforms this into the output DOT file <metro_boost.dot> (the three files are attached to this submission). It seems that somewhere on the way, the graph and node (and edge) attributes get clobbered. Note that even the graph name "metro" gets replaced by the name of the (last) subgraph "ligne_1", and /all/ node attributes get mixed up. This seems to be somewhat similar to the recent edge-related problem posted by Hideaki Hiraki to the boost-users list. I have not (yet) tried to mess with the graphviz parser code, so I am asking here for help. Thanks. Greetings, Andreas <andreas dot scherer at rb-its dot de> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=966496&group_i… ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

BOOST_NO_STDC_NAMESPACE and LIBCOMO
by Robert Ramey 04 Jun '04

04 Jun '04

Commeau I'm building with como-win32 with the libcomo library. It seems that BOOST_NO_STDC_NAMESPACE is set to true with this combination and that it should be set to false for this combination. Robert Ramey

3 2

RE: [boost] Re: Re: Re: Boost Mathematicians
by Hurd, Matthew 04 Jun '04

04 Jun '04

> Behalf Of Thorsten Ottosen > > > "Hurd, Matthew" <hurdm(a)sig.com> wrote in message <snip> > See Type-Based Alias Analysis: > > http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm?temp=fXniOPb1aS Thanks for the link. > > I my suggestion for Design by Contract I mentioned that aliasing (or lack of > it) > could be expressed by a function precondition: > > void foo( T* l, T* r, size_t sz ) > precondition() { > std::less<T*>( l + sz, r ) || std::less<T*>( r + sz, l ); > }; That's ok for simple contiguous spaces but it becomes intractable with complex object collections, but then perhaps the efficiency probably ain't so important as you've lost the locality anyway. > | You still need to wrap as you can't hope, nor should you try, to offer > | all algorithms from all languages. > > probably not. But simply wrapping stuff is not always an option. For eaxample, > in the > statistics lib I'm working on, I need to invert matrices. If I write wrappers, > I will > probably only be ably to support float,double,complex leaving out higher > precsion > datatypes. Yup. Generic interface first. Implementation with ublas where possible. Other generic implementations. Specialize for performance I guess. I haven't looked at uBLAs for a while but there was an interface to ATLAS for performance and also a partial wrapper for LAPACK. Not sure if the use of ATLAS or otherwise is or can be made to be automatic at compile time, but this would give us most of what we need. Generic implementations with pluggable special high performance specializations wherever possible. Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ 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] Proposed Boost Library for Data Series Analysis
by Hurd, Matthew 04 Jun '04

04 Jun '04

> Behalf Of Tom Brinkman > Sounds very powerful. Is there any additional web > information to help me incorporate > these ideas. Not that I know of, but it isn't overly original in approach. Most interactive tools, such as a spreadsheet, will have something like a DAG structure at their core to represent a model-view type dependency thingo. Wish I had more time to play with this stuff... Regards, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ 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] [assignment library post review]
by Rozental, Gennadiy 04 Jun '04

04 Jun '04

> The post review version can be downloaded from > http://tinyurl.com/38c7d Could you please clean archive from garbage in test directory. Gennadiy.

2 1

RE: [boost] [assignment library post review]
by Max Khesin 04 Jun '04

04 Jun '04

Thorsten, link's dead. > -----Original Message----- > From: Thorsten Ottosen [mailto:nesotto@cs.auc.dk] > Sent: Thursday, June 03, 2004 1:08 PM > To: boost(a)lists.boost.org > Subject: [boost] [assignment library post review] > > > Dear All, > > The post review version can be downloaded from > > http://tinyurl.com/38c7d This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

Proposed Boost Library for Data Series Analysis
by Tom Brinkman 04 Jun '04

04 Jun '04

I've created a library for data series calculation and analysis. I've received permission to open-source the library and I would like to submit it for review to the boost if there is sufficient interest. Simple Example 1: Calculate the 10-day simple-moving-average of the 15 exponential-moving-average. (Demonstrates: boost::algorithm::compose). std::vector<double> v1; v1 += 3,4,4,6,7,8,4,7,8,3,2,3,2,5; typedef boost::algorithm::compose<double, boost::function<double (double)>, boost::function<double (double)> > COMPOSE; std::vector<double> v; std::transform(v1.begin(), v1.end(), std::back_inserter(v), COMPOSE(moving_average(15), exponential_moving_average(10))); Simple Example 2 (contrived): * Add 100 to the results from above. * then divide by 100, * then subtract by 100, * then multiply by 100. std::vector<double> v1; v1 += 3,4,4,6,7,8,4,7,8,3,2,3,2,5; typedef boost::algorithm::compose<double, boost::function<double (double)>, boost::function<double (double), boost::function<double (double), boost::function<double (double)> > COMPOSE2; std::vector<double> v2; std::transform(v.begin(), v.end(), std::back_inserter(v2), COMPOSE2(_1 += 100, _1 /= 100, _1 -= 100, _1 *= 100)); Here is a paritial list of functors currently provided by the library. Many additional functors have been written but are fairly specific to our problem domain. moving_average triangle_moving_average rate_of_change momentum vertical_horizontal_filter volatility weighted_moving_average exponential_moving_average variable_moving_average accumulate_n relative_strengh_index cumulative_sum max_numeric_limit variance standard_deviation correlation z_score Please tell me if there is any interest in this library. I will boostify it and submit it for review if there is sufficient interest. Regards, Tom Brinkman __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

5 4

boost/format/format_class.hpp workaround for aC++
by DY, JERRY U (SBCSI) 03 Jun '04

03 Jun '04

Would the experts let me know if there's a better way of accomplishing the same effect below? I have modified boost/format/format_class.hpp and added a line 93 (See attached) && !BOOST_WORKAROUND( __HP_aCC, != 0) <<format_class.hpp>> Thanks! -Jerry

1 0

RE: [boost] [assignment library post review]
by Rozental, Gennadiy 03 Jun '04

03 Jun '04

> The post review version can be downloaded from > > http://tinyurl.com/38c7d Does not work Gennadiy

1 0

RE: [boost] static sized strings
by Reece Dunn 03 Jun '04

03 Jun '04

Martin wrote: >I have tested the sandbox version of the static sized strings. It works >fine >but there are a few inconveniences that I want to point out. I have been writing a series of test cases (boost-sandbox/libs/test) and fixing several bugs. Have you tried these? Also, what compiler(s) are you using? >1. The abstract base class. >--------------------------- >Having an ABC to handle fixed strings of various lengths is a good idea but >it >is not very practical. I understand that the main purpose is to allow fixed >strings to be passed to functions without using templates. > >int countwords(const boost::char_string & str); > >unfortunatly the ABC makes it difficult to pass anything but fixed strings. >If >you want to pass a string literal, a character array or a std::string you >must >create a temporary fixed_string<>. > >countwords(boost::fixed_string<20>("The quick brown fox")); This is an unfortunate side-affect of using the ABC technique that affects John's implementation as well. Your proposed solution looks interesting, but I don't know how practical it will be for the string manipulation operations (w.r.t. buffer safety). Rob proposed a "make_string" function, which would simplify this a little. >2. Substrings >------------- >One of the applications I can see for fixed_string is when you want to >avoid >dynamic allocation but still want to use the std::string interface and >algorithms. In that perspective it seems strange that substr returns a >std::string instead of a fixed_string. This is related to the above problem. You cannot create an instance of boost::char_string, etc. and as such cannot implement substr in the usual way (this is the proplem I was having with operator+). The solution would be to defione an alternate substr function in fixed_string, but this would not solve the problem for boost::char_string, etc. The alternative would be to use a ranged string (pointer to the fixed_string buffer and length), but the problem with this is null-termination. I do not see an easy way around this without removing the ABC design, since it is not possible to do fixed_string< length() > or something similar. >3. resize >--------- >Still missing a method to update the length to reflect the current string >length. I think a resize without arguments would be a good solution. > >boost::fixed_string str<10> >strtime(str.buffer()); >str.resize(); I'll add this soon. I have mainly been focusing on getting documentation and the test cases up. >4. operator[] >------------------------- >I don't have the standard basic_string interface available but I am pretty >sure that operator[] doesn't throw an exception if the argument is outside >max_size(). This is a deviation from the standard. If i > capacity() then the index will be out of the string buffer range and a buffer overrun can occur. This generates an exception to prevent the overrun. I should add this to the docs. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Re: [boost] Re: static sized strings
by Reece Dunn 03 Jun '04

03 Jun '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Rob Stewart wrote: > > >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > > > John Nagle wrote: > > [snip] > > I think you misunderstand what I am trying to say. See my comments >below. > >Actually, I think you misunderstood my points. ok. > > [1] You need to specify the size of the buffer. You cannot declare an >object > > of type fixed_string_base (as it is abstract), you can only have >references > > and pointers to it so you can operate on variable-capacity strings. > >Ah, but you missed that I was declaring a fixed_string_base, >where string capacity is not known. I was relying on >make_fixed_string() to deduce the array length and create an >appropriate fixed_string for it. I didn't miss it, just misunderstood what you intended. > > [2] This is the point that we are discussing. Should this line be: > > > > fixed_string< LENGTH > t; > > > > as will work with the current sandbox implementation (my suggestion #2), >or > > should it be: > > > > fixed_string< LENGTH + 1 > t; > >And that's exactly my point. It should be the former as shown by >my equivalencies. > > > Different programmers favour the different semantics, so I ask: why not > > parameterise it, providing a default behaviour. > >I'm not so sure they do and I'm not sure you need to allow for >it. If you do, I suspect you'll encourage off-by-one mistakes. >Granted, those mistakes won't result in overruns, but they will >be annoying. Furthermore that will result in different >fixed_string types; will you provide for conversions among them? >(That is, for example, from a fixed_string that adds one to the >capacity to one that doesn't?) It is the former in the implementation I have, but if you have char data[ 100 ]; // manipulate and use the data buffer in this example, the buffer is 100 characters, but only 99 are writable, with the 100th being a null character (assuming this is a C-style string). Using the current implementation, this would lead to fixed_string< 100 > data; having an extra character. This would transfer to the other model. > > >(I know there is no make_fixed_string() -- yet -- but such a > > >facility would be appropriate.) > > > > Er... the fixed_string constructors! When you declare the object, you >should > > know the size of the buffer you are using, e.g.: > > > > fixed_string< 100 > data; > >The problem is that you don't know the length of the string. >That is, with this code: > > char s[] = "1234"; > >s is a fixed size array of char with five elements. The >programmer didn't have to write: > > char s[5] = "1234"; > >Instead, the compiler figured out the length. > >That's what I'm trying to provide an equivalence for: > > fixed_string_base & s = make_fixed_string("1234"); > >With that approach, the client doesn't need to precompute the >length of the literal and can rely on the compiler (and template >magic) to deduce it and use it to create a fixed_string<5>. > >I've shown returning by value (with the temporary bound to the >reference s), but it could return a smart pointer just as well. Your original example didn't have fixed_string_base as a reference. It should be easy to implement a make_fixed_string function. > > >I think this clearer reveals that fixed_string's size parameter > ^^^^^^^ >That should have been "clearly." > > > >should specify the number of characters. Remember, one can use > > >boost::array to manage a fixed size, non-string buffer. If > > >buffer overrun protection is insufficient in boost::array, that > > >should be fixed (or a new class should be added to Boost). Thus, > > >fixed_string can ignore that usage. I am not disputing this. The question is, is the null terminator counted as a character. For the example you show, it is, but for buffers (see the example above) it isn't. I haven't got a conversion between the two models because I am only implementing the one model at the moment, but conversion would be automatic because the functions that take strings as arguments take fixed_string_base & arguments, so they should be usable regardless, consider: boost::fixed_string< 20 > str1( "This is a long string!" ); boost::fixed_string< 10 > str2; str2.assign( str1 ); This will work (cutting the string short in str2) even though the strings are of different capacities. Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

3 5

A question on serialization library
by Virendra Verma 03 Jun '04

03 Jun '04

If a class has a pointer to an object, how does class know that the pointer was created by library or the class itself before serialization?

1 0

Re:[boost] NEW lib: Named Variable - safe & convenient output of expressions together with their name
by Robert Ramey 03 Jun '04

03 Jun '04

M G wrote: > the "Named Variable Lib" is a lightweight macro & > template library which allows you to write: This looks equivalent to the Name-Value Pair implemented as part of the serialization library already accepted into boost. It not documented separately as other candidates for separate boost components are - maybe it should have been. I don't see this as a problem. The one in the serialization library only has the functionality required to support serialization and I have often expressed the desire that appropriate pieces be moved out of the serialization library and into boost generally - along with the responsibilities of maintenance, documentation, testing, etc. So please look at the serialization library one and see if you can reconcile all of this. Robert Ramey

1 0

Bug, signals, use of default Combiner
by Ville Varis 03 Jun '04

03 Jun '04

Hi, The next piece of code fails with assertion when calling signals without any connections attached to it. <code> #include <boost/signal.hpp> void test_signaling() { ::boost::signal0<int> sig; /* Next call asserts in boost/last_value.hpp line 29 assert(first != last); */ sig(); } </code> This is due to usage of default Combiner boost::last_value<R>. The problem occures when using non-void return values in signals. I use boost version 1.30.0 but I didn't noticed any changes for this in version 1.31.0. Quick workaround is to use other Combiner as default, where this problem is removed. for example <code> ... last_value .... T operator()(InputIterator first, InputIterator last) const { if (first == last) return T(); ... </code> best regards, Ville Varis ville.varis(a)bonum.biz mail.bonum.biz

2 1

[Boost-bugs] [ boost-Support Requests-965747 ] problem with debug builds on Solaris
by SourceForge.net 03 Jun '04

03 Jun '04

Support Requests item #965747, was opened at 2004-06-03 06:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=965747&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: problem with debug builds on Solaris Initial Comment: When I build an application with -g option (Solaris, Forte compiler), I get undefined symbol errors when it tries to link with Boost. I've tried rebuilding boost with -g, but get undefined sybols at link time from within boost - failing to find symbols in other parts of boost. Without -g option everything is fine Boost version 1.28.0 dlowry_uk(a)yahoo.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=965747&group_i… ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

NEW lib: Named Variable - safe & convenient output of expressions together with their name
by M G 03 Jun '04

03 Jun '04

Greetings BOOST developers, the "Named Variable Lib" is a lightweight macro & template library which allows you to write: os << NV(character) << NV(std_string); os << NV(array_char_text) << NV(array_char_null); os << NV(p_float)<< NVP(p_float); p_float = 0; os << NVP(p_float); os << NV(the_answer_over_pi); os << NVB(((p_device==0) || f > 1.2) && name=="rsd0a"); to get e.g. character='A' std_string="test" array_char_text[]="text" array_char_null=NULL p_float=0012FD9C *p_float=1.234 p_float=NULL the_answer_over_pi=13.36901522 (((p_device_name==0) || f > 1.2) && name=="rsd0a")=1 written to the std::ostream os (" << std::endl" in C++ source omitted for better readability). Its main goal is to standardize the 5 macros NV,NVP,NVB,NVM,NVMP to let one output variable/expression together with their names conveniently (just one very short macro per expression) and safely (e.g. prevents os << "x1=" << x2;). Apart from that the NV concept could be used for other applications, where one needs a variable/expression and its name as a string. For more info & download of the library goto http://groups.yahoo.com/group/boost/files/Named%20Variable/ Feel free to try & comment ;-) Markus __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

weak_ptr doc problem
by Daniel Wallin 03 Jun '04

03 Jun '04

The weak_ptr docs says this: weak_ptr(); Effects: Constructs an **empty** weak_ptr. Postconditions: use_count() == 0. long use_count() const; Returns: if *this is **empty**, an unspecified nonnegative value; otherwise, the number of shared_ptr objects that share ownership with *this. use_count() seems underspecified and contradicts weak_ptr(). It should return exactly 0 when *this is empty. -- Daniel Wallin

2 1

RE: [boost] Proposed Boost Library for Data Series Analysis
by Tom Brinkman 03 Jun '04

03 Jun '04

Response to Matthew Hurd post: >> Efficiency is often paramount with these types of apps. Being able to do finite difference approaches, backwards and forwards, and in absolute terms is important (often you only want the latest data point). Agreed. >> You have the incremental case covered in your notes. Being able to calculate it at a point in an absolute sense, optional caching of results, working with series of unknown lengths and accuracy / validity enabling would be nice too. Agreed. >> By accuracy / validity enabling I mean, for say, your example of a 5 step moving average, it is not valid for the first four points as these are not an accurate average, so there is a length modification for the result. The value for the first four elements is invalid. The user has to adjust for this when they iterate over the returned vector. Example: (three day moving average) std::vector<double> out; std::transform(in.begin(), in.end(), std::back_inserter(out), moving_average(3)); out[0] = NA out[1] = NA out[2] = NA out[3] = NA std::transform(out.begin()+4, out.end(), std::cout << _1 << "\n"); >> Another simple example would be an exponential moving average where the number of significant digits required will determine how far back you need to go in the series. At another level, quality of service for some functors, the fast or accurate spectrum, is often appropriate. >> Perhaps expression templates might help here. Compile time results for validity calcs for series of known lengths would be helpful where possible. Agreed. Expression templates could be used very effecitively here. I will look into this. >> It would be nice if the algorithms could be simply specified, similar to your approach, and then "mounted" into the appropriate framework. Perhaps SFINAE or another technique could be used to determine an algorithm's capabilities. That is, the framework could juggle the most appropriate methods to use based on the results required. E.g. use incremental if you can otherwise absolute. >> Based on what I've done the past you also end up wanting arbitrary n-dimensional structures with other data types flowing through as well. Being able to associate ids/names with data items and keeping them associated through sorting/ranking. E.g. tag the series with data codes, rank them, and you can get the code for the best. You also want grouping n dimensional constructs and splitting dimensions and "slicing" operators that operate across the current dimension, which, with the appropriate framework, are one in the same. E.g. choose the minimum or sum the results of a bunch of functions. >> Then soon you want to split the computation amongst processors and machines and you want treat the computation as a dataflow graph and parallelise it some way, which I did a few years ago with BGL's precursor the GGCL. A topological sort gets you most of the way there... Also, you can then use things like Metis to partition your computation graph in nice ways. >> I think a way approach it would be an expression template approach with some adaptability in terms of absolute and incremental analytics with some accuracy (at least something like the number of points being chewed up and not valid or some such). Everything else could come on top of this. Sounds very powerful. Is there any additional web information to help me incorporate these ideas. >> You need to ensure that you can easily reuse code out there. No one wants to spend their life writing the zillions of numerical algorithms already out there. If you want a vector ARMA model, there are only a couple out there I think, and they are in FORTRAN, for example, wrap it, don't write it, I'd hope. Agreed. Thank you for your comments and spending the time to look at the library. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

Re: Boost Mathematicians
by Tom Brinkman 03 Jun '04

03 Jun '04

http://mathworld.wolfram.com/ Tens of thousands of visitors view MathWorld each day, and thousands of denizens of the mathematical and internet communities have contributed material over the last five years. As a result of this collaboration, MathWorld has grown to become the web's most extensive single source of educational and reference material about mathematics. If you havn't checked out this site you should take a quick look. I propose that we utilize the MathWorld community as the primary resource for ideas about our boost::math::algorithm library. __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

static sized strings
by Martin 03 Jun '04

03 Jun '04

I have tested the sandbox version of the static sized strings. It works fine but there are a few inconveniences that I want to point out. 1. The abstract base class. --------------------------- Having an ABC to handle fixed strings of various lengths is a good idea but it is not very practical. I understand that the main purpose is to allow fixed strings to be passed to functions without using templates. int countwords(const boost::char_string & str); unfortunatly the ABC makes it difficult to pass anything but fixed strings. If you want to pass a string literal, a character array or a std::string you must create a temporary fixed_string<>. countwords(boost::fixed_string<20>("The quick brown fox")); Don't really have a good solution but maybe the base class could use an external buffer with constructors from char* and std::string. class char_string { const char* const extbuf; size_t len; protected: char_string() : extbuf(NULL) {} // not used since derived implements its own buffer public: char_string(const char* c) : extbuf(c), len(strlen(c)) {} char_string(const std::string& str) : extbuf(str.c_str()), len(str.length()) {} ... // virtual basic_string interface } Don't know how to handle non-const char[]. 2. Substrings ------------- One of the applications I can see for fixed_string is when you want to avoid dynamic allocation but still want to use the std::string interface and algorithms. In that perspective it seems strange that substr returns a std::string instead of a fixed_string. 3. resize --------- Still missing a method to update the length to reflect the current string length. I think a resize without arguments would be a good solution. boost::fixed_string str<10> strtime(str.buffer()); str.resize(); 4. operator[] ------------------------- I don't have the standard basic_string interface available but I am pretty sure that operator[] doesn't throw an exception if the argument is outside max_size(). I also looked at the alternative fixed_string implemenatation but since that version doesn't have full std::string interface I didn't test it. I am not sure I like the lazy length calculation for two reasons. - In my view, strlen is normally a "cheap" operation comparable to a function call. If the lazy evaluation prevents a function from being inlined, the benefit is lost. - It is tricky to detect when the length is invalid. With the current implementation, I can't say if the length is valid or not after "str[4] = str [5]" since that depends on the order of evaluation of "str[4]" and "str[5]".

1 0

RE: [boost] Re: Re: Boost Mathematicians
by Hurd, Matthew 03 Jun '04

03 Jun '04

> Behalf Of Thorsten Ottosen > Sent: Thursday, 3 June 2004 4:25 PM > > > "Reid Sweatman" <drunkardswalk(a)earthlink.net> wrote in message > > | Oddly enough, scientists is usually pretty > | conservative folk; they like what they know. > > Is that so odd? Yesterday I talked with a matematician here in Sydney about > Fortran. > He uses Fortran because it is good enough for what he is doing. It would > probably take quite some > time for him to learn C++, so why should he? > > br > > Thorsten There is an often seen misconception that C/C++ should be as fast as it gets as the programming model is close to the instruction model of the machine. In practice FORTRAN is usually faster. At one level, in C++ this slowness this is usually because of temporaries and expression templates and modern optimizing compilers can often mitigate this for typical math calcs. Other abstraction penalties apply. Another level is the fundamental differences in aliasing between the language definitions. FORTRAN as a language does not allow aliasing ambiguities which makes the optimizers job a lot easier and the code can be a lot faster. C/C++ assumes aliasing potential which makes optimizing very hard. A C/C++ compiler may allow aliasing to be disabled for a section of code or for the whole program, but you need to be confident in what you are doing. Very clever global analysis is needed to cure the aliasing problem, and given the potential for run time gymnastics, it may not be possible at all. Have a look at these benchmarks judging Todd V's blitz to FORTRAN: http://www.oonumerics.org/blitz/benchmarks/ Boost's equivalent to Blitz++ is uBLAs. More discussion on C++ versus FORTRAN speed can be found here: http://osl.iu.edu/~tveldhui/papers/iscope97/ I do think it is worthwhile writing C++ to do this stuff as the abstraction is much better for the library client IMO. At some levels the implementation may be tougher for the library writer, as some of the optimizer gymnastics ends up in the expression templates, but given the right framework it may be simply extensible and suitable for even relatively unsophisticated mathematicians to contribute library components. You still need to wrap as you can't hope, nor should you try, to offer all algorithms from all languages. Another lobbed $0.005, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna Sydney _______________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

[test] [minmax] failure on gcc 2.95
by Vladimir Prus 03 Jun '04

03 Jun '04

As shown in http://tinyurl.com/3xdyq, Boost.Test fails to build on gcc 2.95 with stlport. The error message is: /boost/head-regression/boost/boost/minmax.hpp: In function `const size_t & boost::std_min<size_t>(const size_t &, const size_t &)': /boost/head-regression/boost/libs/test/build/../src/test_tools.cpp:375: instantiated from here /boost/head-regression/boost/boost/minmax.hpp:26: `min' undeclared (first use this function) Is it possible that authors of either Boost.Test or boost/minmax.hpp take care of this error? Thanks, Volodya

1 0

Borland settings different between Boost and IDE ?
by Nicola Musatti 03 Jun '04

03 Jun '04

Hallo, is it possible that Boost libraries use a different setting for enum handling than the BCB IDE default one? I'm having problems which seem related to enums and the inclusion of some Boost headers in precompiled headers. Cheers, Nicola Musatti

2 2

[program_options] Darwin failure help?
by Vladimir Prus 03 Jun '04

03 Jun '04

The program options library now fails a single test on Darwin, with this output: ../libs/program_options/test/parsers_test.cpp(205): fatal error in "call_test_main": test p.options.size() == 1 failed *** 1 failure detected in test case "call_test_main" The code in question is: putenv("PO_TEST_FOO=1"); parsed_options p = parse_environment(desc, "PO_TEST_"); BOOST_REQUIRE(p.options.size() == 1); So, it seems that after "putenv", the string is is not available in the 'environ' variable. The variable is declared like this: #if defined(__APPLE__) && defined(__DYNAMIC__) #include <crt_externs.h> static char** environ = *_NSGetEnviron(); #else extern char** environ; #endif The Darwin-specific conditinal was sent by Michael LaSpina, so I don't know what it really does, and so don't know why the test fails. I'd appreciate any suggestions. Thanks in advance, Volodya

2 2

RE: [boost] Proposed Boost Library for Data Series Analysis
by Hurd, Matthew 02 Jun '04

02 Jun '04

> -----Original Message----- > Behalf Of Tom Brinkman > Subject: [boost] Proposed Boost Library for Data Series Analysis > > I placed a small tutorial and motivating example for > the proposed boost::data_series library. > > http://groups.yahoo.com/group/boost/files/data_series/ > > Working examples for you to criticize will be added > within the week. Cute code. Nice job. Efficiency is often paramount with these types of apps. Being able to do finite difference approaches, backwards and forwards, and in absolute terms is important (often you only want the latest data point). You have the incremental case covered in your notes. Being able to calculate it at a point in an absolute sense, optional caching of results, working with series of unknown lengths and accuracy / validity enabling would be nice too. By accuracy / validity enabling I mean, for say, your example of a 5 step moving average, it is not valid for the first four points as these are not an accurate average, so there is a length modification for the result. Another simple example would be an exponential moving average where the number of significant digits required will determine how far back you need to go in the series. At another level, quality of service for some functors, the fast or accurate spectrum, is often appropriate. Perhaps expression templates might help here. Compile time results for validity calcs for series of known lengths would be helpful where possible. It would be nice if the algorithms could be simply specified, similar to your approach, and then "mounted" into the appropriate framework. Perhaps SFINAE or another technique could be used to determine an algorithm's capabilities. That is, the framework could juggle the most appropriate methods to use based on the results required. E.g. use incremental if you can otherwise absolute. Based on what I've done the past you also end up wanting arbitrary n-dimensional structures with other data types flowing through as well. Being able to associate ids/names with data items and keeping them associated through sorting/ranking. E.g. tag the series with data codes, rank them, and you can get the code for the best. You also want grouping n dimensional constructs and splitting dimensions and "slicing" operators that operate across the current dimension, which, with the appropriate framework, are one in the same. E.g. choose the minimum or sum the results of a bunch of functions. Then soon you want to split the computation amongst processors and machines and you want treat the computation as a dataflow graph and parallelise it some way, which I did a few years ago with BGL's precursor the GGCL. A topological sort gets you most of the way there... Also, you can then use things like Metis to partition your computation graph in nice ways. I think a way approach it would be an expression template approach with some adaptability in terms of absolute and incremental analytics with some accuracy (at least something like the number of points being chewed up and not valid or some such). Everything else could come on top of this. You need to ensure that you can easily reuse code out there. No one wants to spend their life writing the zillions of numerical algorithms already out there. If you want a vector ARMA model, there are only a couple out there I think, and they are in FORTRAN, for example, wrap it, don't write it, I'd hope. You end up with run time versus compile time issues. People want to interact with this kind of stuff. However, my take on that now is do it at compile time and include the compiler as part of your interactive tools set if need be :-) Anyhow, it is nice to see a start on this. Good luck. $0.005, Matt Hurd. _______________ Matt Hurd +61.2.8226.5029 hurdm(a)sig.com Susquehanna _______________ 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: Re: iostreams library review
by Robert Ramey 02 Jun '04

02 Jun '04

>> Question, have you tried to combine the streaming with boost >> serialization? > I think Robert Ramey has already done the work to combine serialization > with iostreams, since his archive types are constructible from arbitrary > streams -- that means it's already possible to create archives based on > streams from the iostreams library, e.g. memory-mapped file streams. > There may be other interactions I haven't considered. I've only read the > documentation; I haven't actually tried to use the serialization library > yet. The serialization library archives use streams and make no special assumptions regarding them. It works with all the streams I've happened to try. I will be taking a close look at the iostreams library proposal. In the course of implementing the serialization library I've had to become much more familiar with locales, facets, codecvt, element types, EOF, etc than I wanted to. Oh - and that fact that different versions of the standard library have myriad minor quirks that have to be considered. This was necessary in order to avoid dependence on the stream in the wrong way. I'm very interested in this but have come to the conclusion that there might be more here than meets the eye. - Of course that's why we have the review process. Robert Ramey

2 1

boost::optional - Include none.hpp instead of none_t.hpp?
by Schalk_Cronje＠NAI.com 02 Jun '04

02 Jun '04

Was it intentional to include none_t.hpp instead of none.hpp in boost/optional.hpp? Otherwise it seems that the user must resort to including boost/detail/none.hpp

3 3

thread, line endings
by Janusz Piwowarski 02 Jun '04

02 Jun '04

Hello In files: libs/thread/src/mutex.cpp libs/thread/src/recursive_mutex.cpp libs/thread/src/mutex.inl boost/thread/mutex.hpp boost/thread/recursive_mutex.hpp there is CR+CR+LF used as line separator. Also, in recursive_mutex constructor if defined(BOOST_HAS_WINTHREADS) m_critical_section should be initialized before m_count (it's compiler warning) Regards, Janusz

3 4

New utility at boost/detail/allocator.hpp
by Joaquín Mª López Muñoz 02 Jun '04

02 Jun '04

Hi all, As requested by some at the mailing list, I've migrated allocator.hpp from boost/multi_index/detail/ to boost/detail/ (with some obvious namespace changes.) I'd like to remark the following: * This allocator.hpp has nothing to do with a header of the same name who was sitting there and John Maddock kindly removed a few days ago. * The header provides some utilities to do rebinding of allocators even in MSVC++ 6.0 (where the std syntax for rebind does not work), and also exposes a tiny wrapper over defective std::allocators, providing some missing template members to make them std compliant. * I'd appreciate if those of you who were originally interested in using this header can do some sanity checks to make sure everything works for you (it does for Boost.MultiIndex). We have some room for improvements and fixes until Boost 1.32 is branched for release. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

RE: [boost] Re: Re: BOOST_READONLY_PROPERTY macro
by Rozental, Gennadiy 02 Jun '04

02 Jun '04

> Can you just please tell me what BOOST_READONLY_PROPERTY ( > bool, (epv) ) > will become once it is preprocessed ? Something like this: class readonly_property123 : public boost::unit_test::readonly_property<bool> { typedef boost::unit_test::readonly_property<bool> base; friend class epv; // <-- here BOOST_PP is used typedef base::write_param_t write_param_t; public: readonly_property123() {} explicit readonly_property123( write_param_t init_v ) : base( init_v ) {} } > > P.S. Paul should know the answer > I don't think Paul knows about _all_ libraries that _use_ the > PP library. This has something to do with specific compiler bug in regards of PP.

1 0

Test failure for basic_cstring_test
by Martin Wille 02 Jun '04

02 Jun '04

Hello, basic_cstring_test fails on gcc-3.2.3 in a way that causes the test post processing to fail, too. The basic_cstring_test related lines from the log file are appended to this message. The full log for gcc-3.2.3-linux can be found at http://tinyurl.com/34ltq Regression log post processing fails with this message: **** exception(205): std::exception: boost::filesystem::path: invalid name "basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x757):.." in path: "bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x757):../libs/test/test" ******** errors detected; see standard output for details ******** Regards, m gcc-C++-action ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o /boost/head-regression/boost/boost/test/test_tools.hpp: In function `bool boost::test_tools::detail::equal_and_continue_impl(const Left&, const Right&, boost::wrap_stringstream&, boost::unit_test::basic_cstring<const char>, unsigned int, boost::unit_test::log_level, unsigned int) [with Left = size_t, Right = int]': ../libs/test/test/basic_cstring_test.cpp:82: instantiated from `void constructors_test(CharT*) [with CharT = wchar_t]' ../libs/test/test/basic_cstring_test.cpp:124: instantiated from `static void meta_constructors_test::execute(T*) [with T = wchar_t]' /boost/head-regression/boost/boost/test/test_case_template.hpp:60: instantiated from `void boost::unit_test::detail::test_case_template_instance<TestCaseTemplate, TestType>::do_run() [with TestCaseTemplate = meta_constructors_test, TestType = wchar_t]' /boost/head-regression/boost/boost/utility/value_init.hpp:49: instantiated from here /boost/head-regression/boost/boost/test/test_tools.hpp:430: warning: comparison between signed and unsigned integer expressions gcc-Link-action ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x657): In function `void find_test<char const>(char const*)': ../libs/test/test/basic_cstring_test.cpp:470: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x757):../libs/test/test/basic_cstring_test.cpp:368: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0x8ac):../libs/test/test/basic_cstring_test.cpp:432: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0xa1a):../libs/test/test/basic_cstring_test.cpp:433: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIhEvPT_+0xb93):../libs/test/test/basic_cstring_test.cpp:480: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z16data_access_testIhEvPT_+0xb8): In function `void data_access_test<unsigned char>(unsigned char*)': /boost/head-regression/boost/boost/test/detail/basic_cstring/basic_cstring.hpp:539: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z16data_access_testIhEvPT_+0x1e7): In function `void data_access_test<unsigned char>(unsigned char*)': /boost/head-regression/boost/boost/test/test_tools.hpp:446: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z14asignment_testIhEvPT_+0xea):/usr/local/gcc-3.2.3/include/c++/3.2.3/bits/basic_string.tcc:155: more undefined references to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' follow ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0x757): In function `void find_test<char const>(char const*)': ../libs/test/test/basic_cstring_test.cpp:368: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0x8ac):../libs/test/test/basic_cstring_test.cpp:432: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0xa1a):../libs/test/test/basic_cstring_test.cpp:433: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z17constructors_testIKhEvPT_+0xb93):../libs/test/test/basic_cstring_test.cpp:480: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z23constructors_const_testIKhEvPT_+0x114): In function `void constructors_const_test<unsigned char const>(unsigned char const*)': ../libs/test/test/basic_cstring_test.cpp:195: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z20asignment_const_testIKhEvPT_+0x11f): In function `void asignment_const_test<unsigned char const>(unsigned char const*)': /usr/local/gcc-3.2.3/include/c++/3.2.3/bits/basic_string.tcc:160: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._Z20asignment_const_testIKhEvPT_+0x258):../libs/test/test/basic_cstring_test.cpp:353: more undefined references to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' follow ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIhEC1EPh+0x37): In function `boost::unit_test::basic_cstring<unsigned char>::basic_cstring[in-charge](unsigned char*)': /boost/head-regression/boost/boost/detail/shared_count.hpp:150: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testltIhEEbRKNS0_13basic_cstringIT_EES6_+0x7c): In function `bool boost::unit_test::operator< <unsigned char>(boost::unit_test::basic_cstring<unsigned char> const&, boost::unit_test::basic_cstring<unsigned char> const&)': /boost/head-regression/boost/boost/test/detail/basic_cstring/compare.hpp:51: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIhE4findES2_+0xab): In function `boost::unit_test::basic_cstring<unsigned char>::find(boost::unit_test::basic_cstring<unsigned char>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIhE10trim_rightES2_+0x8d): In function `boost::unit_test::basic_cstring<unsigned char>::trim_right(boost::unit_test::basic_cstring<unsigned char>)': ../libs/test/test/basic_cstring_test.cpp:260: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIhE9trim_leftES2_+0x8b): In function `boost::unit_test::basic_cstring<unsigned char>::trim_left(boost::unit_test::basic_cstring<unsigned char>)': /boost/head-regression/boost/boost/detail/shared_count.hpp:345: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIhE5rfindES2_+0xab): In function `boost::unit_test::basic_cstring<unsigned char>::rfind(boost::unit_test::basic_cstring<unsigned char>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIKhEC1EPS2_+0x37): In function `boost::unit_test::basic_cstring<unsigned char const>::basic_cstring[in-charge](unsigned char const*)': /boost/head-regression/boost/boost/detail/shared_count.hpp:150: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNSbIhSt11char_traitsIhESaIhEEC1EPKhRKS1_+0x13): In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::basic_string[in-charge](unsigned char const*, std::allocator<unsigned char> const&)': /boost/head-regression/boost/boost/test/detail/basic_cstring/basic_cstring.hpp:531: undefined reference to `std::char_traits<unsigned char>::length(unsigned char const*)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testltIKhEEbRKNS0_13basic_cstringIT_EES7_+0x7c): In function `bool boost::unit_test::operator< <unsigned char const>(boost::unit_test::basic_cstring<unsigned char const> const&, boost::unit_test::basic_cstring<unsigned char const> const&)': /boost/head-regression/boost/boost/test/detail/basic_cstring/compare.hpp:51: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIKhE4findES3_+0xab): In function `boost::unit_test::basic_cstring<unsigned char const>::find(boost::unit_test::basic_cstring<unsigned char const>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIKhE10trim_rightES3_+0x8d): In function `boost::unit_test::basic_cstring<unsigned char const>::trim_right(boost::unit_test::basic_cstring<unsigned char const>)': ../libs/test/test/basic_cstring_test.cpp:260: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_test13basic_cstringIKhE9trim_leftES3_+0x8b): In function `boost::unit_test::basic_cstring<unsigned char const>::trim_left(boost::unit_test::basic_cstring<unsigned char const>)': /boost/head-regression/boost/boost/detail/shared_count.hpp:345: undefined reference to `std::char_traits<unsigned char>::find(unsigned char const*, unsigned, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNK5boost9unit_test13basic_cstringIKhE5rfindES3_+0xab): In function `boost::unit_test::basic_cstring<unsigned char const>::rfind(boost::unit_test::basic_cstring<unsigned char const>) const': ../libs/test/test/basic_cstring_test.cpp:329: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testeqIhhEEbRKNS0_13basic_cstringIT_EERKNS2_IT0_EE+0x5c): In function `bool boost::unit_test::operator==<unsigned char, unsigned char>(boost::unit_test::basic_cstring<unsigned char> const&, boost::unit_test::basic_cstring<unsigned char> const&)': /boost/head-regression/boost/boost/test/test_tools.hpp:434: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNKSbIhSt11char_traitsIhESaIhEE5c_strEv+0x2e): In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::c_str() const': /usr/local/gcc-3.2.3/include/c++/3.2.3/bits/stl_algobase.h:240: undefined reference to `std::char_traits<unsigned char>::assign(unsigned char&, unsigned char const&)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZN5boost9unit_testeqIKhS2_EEbRKNS0_13basic_cstringIT_EERKNS3_IT0_EE+0x5c): In function `bool boost::unit_test::operator==<unsigned char const, unsigned char const>(boost::unit_test::basic_cstring<unsigned char const> const&, boost::unit_test::basic_cstring<unsigned char const> const&)': /boost/head-regression/boost/boost/test/test_tools.hpp:434: undefined reference to `std::char_traits<unsigned char>::compare(unsigned char const*, unsigned char const*, unsigned)' ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o(.gnu.linkonce.t._ZNSbIhSt11char_traitsIhESaIhEE13_S_copy_charsEPhPKhS5_+0x20): In function `std::basic_string<unsigned char, std::char_traits<unsigned char>, std::allocator<unsigned char> >::_S_copy_chars(unsigned char*, unsigned char const*, unsigned char const*)': /boost/head-regression/boost/boost/detail/shared_count.hpp:100: undefined reference to `std::char_traits<unsigned char>::copy(unsigned char*, unsigned char const*, unsigned)' collect2: ld returned 1 exit status set -e LD_LIBRARY_PATH=/usr/local/gcc-3.2.3/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH "/usr/local/gcc-3.2.3/bin/g++wrap" --limit-memory=600 --limit-cpu=1800 -g -o "../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test" -L"../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-3.2.3-linux/debug" -L"/usr/local/gcc-3.2.3/lib" "../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test.o" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-3.2.3-linux/debug/libboost_unit_test_framework.a" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-3.2.3-linux/debug/libboost_unit_test_framework.a" -Wl,-rpath-link,. ...failed gcc-Link-action ../bin/boost/libs/test/test/basic_cstring_test.test/gcc-3.2.3-linux/debug/basic_cstring_test... ...skipped <@boost!libs!test!test/basic_cstring_test.test/gcc-3.2.3-linux/debug>basic_cstring_test.run for lack of <@boost!libs!test!test/basic_cstring_test.test/gcc-3.2.3-linux/debug>basic_cstring_test...

4 6

port of library to vacpp (item 2)
by Toon Knapen 02 Jun '04

02 Jun '04

I stumble on another problem when trying to compile the test library with IBM/VisualAge (vacpp). Apparantly vacpp has a problem on lines 97,98 and 99 of boost/test/detail/basic_cstring/basic_cstring.hpp. Basically the problem is this: this file declares a class template < class CharT > class basic_string { public: typedef basic_string<CharT> self_type ; self_type& trim_left(self_type exclusions = self_type() ) ; // line 97 } ; If I now remove the default initializer, vacpp does not choke anymore (same situation on lines 98 and 99). I tried to isolate this problem in small test but in a small test vacpp seems to deal with the situation just fine. Thus AFAICT this is a compiler-bug but would anyone mind if I remove the default initializers or just remove them in the vacpp compilation to get one step closer to running the regression tests on vacpp again.

5 8

Proposed Boost Library for Data Series Analysis
by Tom Brinkman 02 Jun '04

02 Jun '04

I placed a small tutorial and motivating example for the proposed boost::data_series library. http://groups.yahoo.com/group/boost/files/data_series/ Working examples for you to criticize will be added within the week. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

RE: [boost] Re: BOOST_READONLY_PROPERTY macro
by Rozental, Gennadiy 02 Jun '04

02 Jun '04

> > BOOST_CLASS_PROPERTY is used like this: > > > > BOOST_CLASS_PROPERTY( int, (class1)(class2)...(classN) ) property; > > How is that relevant? Sorry supposed to be BOOST_READONLY_PROPERTY in both places. Gennadiy.

3 3

RE: [boost] Re: iostreams library review
by Brian Braatz 02 Jun '04

02 Jun '04

"""""""" > what is the fate of this library? Thanks for your interest! The previous version available at http://www.xmission.com/~turkanis/iostreams/. """""""""" I downloaded the library from the yahoo link you mentioned in the review request. When trying to use 'filtered_stream' I ran into some compilation issues (RedHat 9, g++ 3.3) and before looking into it I wanted to know the review status. Knowing that the library is in the review pipeline I will give it another try. Some time ago I developed simple iostream adapter 'library' that allows to wrap IO device (sockets, pipes, etc) in std::[i,o,io]stream that is very similar to your sink/source technique. One difference is that the adapter is a template class parameterized by the source/sink types. Since your library offers this functionality (plus much more) I am very pleased it will become part of boost soon. """""""""" A quick look your page is very interesting. (looks very cool) I was thinking (also) along the same lines for some work I am currently doing, but you beat me to it. Question, have you tried to combine the streaming with boost serialization?

2 1

Re: [boost] Re: static sized strings
by Reece Dunn 01 Jun '04

01 Jun '04

Rob Stewart wrote: >Subject: Re: [boost] Re: static sized strings >Date: Tue, 1 Jun 2004 17:13:38 -0400 (EDT) > >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > John Nagle wrote: > > > I've done some cleanup on my version of fixed_string at > > > http://www.animats.com/source > > >[snip] > > > We're approaching convergence on this. > > > > We are both working on variations of the same idea. As such, I have >fixed > > several errors in my code making it operate better as a basic_string > > interface and have seperated the safe_string.hpp file into the >appropriate > > headers (fsstring.hpp for string.h, fsstdio.hpp for stdio.h and >fswchar.hpp > > for wchar.h). I have also posted BoostBook format documentation to the >libs > > section. > > > > However, we are still no closer to deciding which implementation to >choose. > > We can either: > > [1] Choose one implementation and drop the other (possibly collaborate); > > [2] Continue both and put them against each other to see which is >better; > > [3] Drop both and develop one together from scratch. > > > > Option [3] is not viable, since a lot of the hard work has already been >done > > (size issues, etc.). I would like the implementation we use to be mine >and > > I'm sure John feels the same way about his. I am also getting to the >stage > > where I am considering putting mine up for review (once I get the tests > > written). > >John hasn't fleshed out his design quite as completely as you >have yours, but he's close. John just raised a new point: >accessing the N + 1'st element. That may not have been apparent >had he not been working on his own version -- or have you already >dealt with that? -- so both implementations remain useful. My s[ i ] throws if i > capacity() which shouldn't cause a problem. s.at( i ) throws if i > length(). >I laid out a plan previously for how to judge between the >implementations. I suggest waiting to have either reviewed until >you can both run your code through the same tests -- with and >without errors -- to see if there is a clear winner. Sure. I have been writing tests for my library (boost-sandbox/fixed_string/test/*.cpp) with a BBv2 file to do the testing. I have the C-style functions test cases posted and have made a start with the basic_string cases [21.3.1-4]. There still need to be tests for when the operations will cause buffer overflow on unprotected code, and generate exceptions for functions like s.at( i ), but I am waiting until I have written the basic test cases. The tests currently use my naming conventions, but I am sure they can be adapted for John's versions as well for comparisons. I could also implement bench marcking tests for performance analysis. >Another possible means to judge between the two is to find >real-world C code using strings, that compiles with a C++ >compiler. Then, each library author can translate the code >according to the needs of the libraries. Diffs will reveal the >extent of the changes needed, and copious notes could illustrate >common mistakes made and error messages encountered during the >translation. That information can clarify which design makes the >translation of C string code into fixed_string code easiest >(performance will have already been ascertained, so needn't be >reassessed). That would be a good idea. >If that doesn't reveal a clear winner, I've a suggestion for >breaking the tie: I can pass the options through a coworker of >mine. He was a C programmer for a very long time and has been >writing C++ code for less time. He still thinks like a C >programmer in a lot of ways, so he might have insights we're >missing. Also a good idea. Regards, Reece _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

1 0

RE: [boost] Re: static sized strings
by Reece Dunn 01 Jun '04

01 Jun '04

John Nagle wrote: > I've done some cleanup on my version of fixed_string at > http://www.animats.com/source >[snip] > We're approaching convergence on this. We are both working on variations of the same idea. As such, I have fixed several errors in my code making it operate better as a basic_string interface and have seperated the safe_string.hpp file into the appropriate headers (fsstring.hpp for string.h, fsstdio.hpp for stdio.h and fswchar.hpp for wchar.h). I have also posted BoostBook format documentation to the libs section. However, we are still no closer to deciding which implementation to choose. We can either: [1] Choose one implementation and drop the other (possibly collaborate); [2] Continue both and put them against each other to see which is better; [3] Drop both and develop one together from scratch. Option [3] is not viable, since a lot of the hard work has already been done (size issues, etc.). I would like the implementation we use to be mine and I'm sure John feels the same way about his. I am also getting to the stage where I am considering putting mine up for review (once I get the tests written). What do other people think? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Re: [boost] Re: [prereview request][fsm]
by eegg＠comcast.net 01 Jun '04

01 Jun '04

--- Rob Stewart <stewart(a)sig.com> wrote: > From: "E. Gladyshev" <eegg(a)comcast.net> > > From: "Rob Stewart" <stewart(a)sig.com> > > > From: "E. Gladyshev" <eegg(a)comcast.net> > > > > From: "Rob Stewart" <stewart(a)sig.com> > > [...] > > 1. Some platforms pose non-C++ exceptions as normal C++ exception. > > You don't always want those platfrom specific exceptions trigger > > a whole bunch of stuff in your program. > > The only platform I know of that does that is Windows/MSVC It makes it pretty common, doesn't it. :) > you can handle structured exceptions specially. Perhaps it > means that boost::fsm needs to provide a means to install an > exception handler for those exceptions not already recognized by > the library: > > try { throw; } > catch (...) { boost::fsm::detail::handle_exception(); } > > void boost::fsm::detail::handle_exception() > { > try { throw; } > catch (type1 const &) { ... }; > catch (type2 const &) { ... }; > catch (type3 const &) { ... }; > catch (...) { user_handler(); } > } > where user_handler is a pointer to function that's initialized to > std::unexpected() and can be overridden by the library user. Adding user_handler() doesn't stop stack unwinding. I think you are missing the point. The issue is not in how to process SEH exceptions (or any other unhandled exception) the issue is in how not to trigger stack unwinding (for all exceptions) and still be able discriminate user exception types generically in FSM. Your solution doesn't solve this problem. > > It may also be that SEH can be configured to intervene before a > C++ exception is generated by the RTL so those never become C++ > exceptions that can muck up the works. It is not trivial... but it is out of the FSM topic. > > 2. Your design assumes that all possible exceptions are known > > and you handle them. So any unhandled exception is a bug. > > Not quite. What I was showing would rethrow any unknown > exception, leaving to clients to determine how to handle it. > > > It is not safe to trigger stack unwinding in a buggy environment. > > If you say so. Every application and platform with which I work > is buggy and yet I manage to use exceptions and stack unwinding > works. What do you mean by "stack unwinding works". Do you mean that even if the exception is caused by a bug, stack unwinding didn't make things worse or less safer? Well, it's a long shot... [...] > This is just another case of things not being as pretty > as one might like but that doesn't mean stack unwinding is > faulty. Sorry, who said that stack unwinding is faulty? Eugene

5 8

Re: [boost] [Serialization] Errors when compiling using GCC 3.4
by Robert Ramey 01 Jun '04

01 Jun '04

Allen Yao wrote: > I just updated my gcc from 3.3.3 to 3.4, and found that the > serialization17 and serialization18 cannot compile. There are many error > messages, some of them seem to caused by lack of "typename", others are > very strange, for example, about using boost::noncopyable. > Does someone try serialization library on GCC 3.4? Can it be compiled? > I suspect I am missing something. Otherwise, I would like to try to "fix" > the "bugs" myself. Hmmm, I just checked. I'm currently using gcc 3.3.1 ? Should I upgrade to gcc 3.4.? I seem to recall information on the list that suggested it would be better to wait a little bit. If upgrading is a good thing - now is a good time for me to do it as I'm just finalizing all the changes for next version and just starting the "torture test torture" procedure of reconciliation of compiler quirks. Robert Ramey

4 5

BOOST_READONLY_PROPERTY macro
by Toon Knapen 01 Jun '04

01 Jun '04

This is the next item in the continuing sage about porting the test-library to IBM/VisualAge. The use of the BOOST_READONLY_PROPERTY macro results in error messages (see attached file) when compiling the test library with vacpp. I tried to have a look at this macro but it is not documented anywhere (neither in the source files where the macro is defined) and thus I would appreciate help from someone more knowledgeable about the test and preprocessor library. Additionally I would like to remark again that the test tools should not have too many dependencies. If the test tools depend on almost all boost libraries, there's no use in having test tools that verify if all libraries compile, is there ? toon ...found 838 targets... ...updating 273 targets... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_tools.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_tools.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_tools.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_log.o xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_monitor.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_monitor.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_monitor.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_monitor.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_result.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_result.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_result.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_result.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_suite.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_suite.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/unit_test_suite.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/unit_test_suite.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/supplied_log_formatters.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/supplied_log_formatters.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/supplied_log_formatters.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/supplied_log_formatters.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_main.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 72.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 74.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/unit_test_suite.hpp", line 84.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DBOOST_TEST_NO_AUTO_LINK=1 -qNOOPTimize -qnoinline -g -qfullpath -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_main.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_main.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/debug/test_main.o... ...skipped <@boost!libs!test!build/libboost_test_exec_monitor.so/vacpp/debug>libboost_test_exec_monitor-xlc-d-1_31.so for lack of <@boost!libs!test!build/libboost_test_exec_monitor.so/vacpp/debug>test_tools.o... ...skipped <@boost!libs!test!build!stage!lib>libboost_test_exec_monitor-xlc-d-1_31.so for lack of <@boost!libs!test!build/libboost_test_exec_monitor.so/vacpp/debug>libboost_test_exec_monitor-xlc-d-1_31.so... MkDir1 /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release/execution_monitor.o xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release/test_tools.o "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp". "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/test/test_tools.hpp", line 188.6: 1540-0861 (S) Too few arguments are specified for macro "BOOST_PP_IIF_0". Empty arguments are used. "/home/tk/ext_projects/boost/boost_tknapen/boost/boost/preprocessor/control/iif.hpp", line 32.10: 1540-0425 (I) "BOOST_PP_IIF_0" is defined on line 32 of "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp". xlC -c -I/home/tk/ext_projects/boost/boost_tknapen/boost -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 -O3 -qstrict -qinline -qnotempinc -qfuncsect -qeh -qrtti -I"/home/tk/cvstop/DO/bin/boost/libs/test/build" -I"/home/tk/ext_projects/boost/boost_tknapen/boost" -o "/home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release/test_tools.o" "/home/tk/ext_projects/boost/boost_tknapen/boost/libs/test/build/../src/test_tools.cpp" ...failed xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release/test_tools.o... xlc-C++-action /home/tk/cvstop/DO/bin/boost/libs/test/build/libboost_test_exec_monitor.so/vacpp/release/unit_test_parameters.o

3 2

Re: [boost] Re: [Boost-announce] Formal Review Tribool
by Haim Cohen 01 Jun '04

01 Jun '04

Sorry if this is a repost - I am almost sure my last post did not reached out. Rob Stewart wrote: > meaning "arbitrary value." However, "indeterminate" leaves no > doubt as to the meaning of the value and doesn't depend upon > one's experience with electronics. Another possibility would be I agree. Although I see the highest potential of the library in EDA applications, the meaning of the value should not depend on any problem domain - like electronics. I guess I was little bit biased here by my problem domain. > As I've already rejected the "x" notion, that leaves > "unknown_bool" or, by extension, "indeterminate_bool." While > these names suggest that there is an unknown or indeterminate > Boolean value, they don't suggest to me a type that includes > true, false, *and* unknown/indeterminate. "tribool," OTOH, I disagree. IMHO, The name unknown_bool hints that in addition to the 2 traditional values of bool, there is also an unknown bool. I am not a native user of the English language, but this is what the name unknown_bool hints *me*. Haim -- _____________________________________________________ Haim Cohen Software Engineer haim.cohen(a)analog.com / haimcohen2002(a)hotmail.com Analog Devices

1 0

[Formal review request] policy_ptr
by David B. Held 01 Jun '04

01 Jun '04

I am formally requesting that policy_ptr be added to the review queue. The version to be reviewed is different from the version currently in the sandbox, but will be available long before the current queue is exhausted. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.691 / Virus Database: 452 - Release Date: 5/26/2004

3 3

Boost Software License & GPL
by Alex Vinokur 01 Jun '04

01 Jun '04

<QUOTE from http://www.boost.org/more/lib_guide.htm#License> License requirements The preferred way to meet the license requirements is to use the Boost Software License. See license information. If for any reason you do not intend to use the Boost Software License, please discuss the issues on the Boost developers mailing list first. </QUOTE> I am thinking of submission some software to Boost. However I put this software in several sites under GPL. Boost requires Boost Software License. How to solve this problem? -- Alex Vinokur mailto:alexvn@connect.to http://mathforum.org/library/view/10978.html

3 3

bjam - adding includes
by John Torjo 31 May '04

31 May '04

Hi all, Is there a way to add an <include> to bjam, by specifying it on command line? In particular, I'm trying to build a non-boost library, which needs boost ;) Therefore, I need to specify the path where boost headers are. Since I want to distribute this library, I don't think that adding an <include> in the jamfile, specifying where my boost is installed is the way to go ;) So, is it possible? If so, how? Thanks. Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

3 2

[multi_index] Volunteer to help porting to VC7.0?
by Joaquín Mª López Muñoz 31 May '04

31 May '04

Regression tests for VC7.0 show a recurrent problem throughout the library with a specific facility in boost/multi_index/detail/allocator.hpp. My hunch is that this should be easy to fix, but it is not productive to try variations on the main CVS and wait for the regression tests outputs. Anyone with VC7.0 volunteering to help with porting of Boost.MultiIndex to VC7.0? If so please contact me and I'll provide you with all the relevant info and some suggestions of things to try. I think this souldn't be to hard to fix. Thanx in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Volunteer for a little test in MSVC 7.0?
by JOAQUIN LOPEZ MU?Z 31 May '04

31 May '04

I'm trying to make Boost.MultiIndex work for MSVC 7.0 an the regression tests show some weird results. I'm suspicious this can be related with a similar problem in MSVC 6.0 having to do with pointers to members being used as template prams. Would any kind soul with access to MSVC 7.0 run the following test and report the result? TIA Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ****************** struct pair { int x,y; pair(int x_,int y_):x(x_),y(y_){} }; template<int pair::* PtrToPairMember> struct foo { int bar(pair& p){return p.*PtrToPairMember;} }; int main() { pair p(0,1); foo<&pair::x> fx; foo<&pair::y> fy; if(fx.bar(p)!=0||fy.bar(p)!=1)return -1; return 0; } *****************

5 5

Metrowerks: member template specialization problem
by Vladimir Prus 31 May '04

31 May '04

I get the following error from metrowerks: http://tinyurl.com/2z6st It seems that given: template<> bool basic_config_file_iterator<wchar_t>::getline(std::string& s); template<class charT> bool basic_config_file_iterator<charT>::getline(std::string& s) { return std::getline(*is, s); } Metrowerks decides to use the second, unspecialized version, even for basic_config_file_iterator<wchar_t>, and this surely fails to compile. Anybody knows what could be the reason? The entire header which causes the error can be found at: http://tinyurl.com/2rapj Thanks in advance, Volodya

3 6

[Formal review result] Collection Traits Library
by Hartmut Kaiser 30 May '04

30 May '04

Hi all, after working through the pile of mails submitted for the review of the Collection Traits Library from Thorsten Ottosen, it is obvious, that it is ACCEPTED to Boost. All of the reviewes voted YES to include the library. Congratulations Thorsten! Most of the issues brought up during the review (mainly documentation nitpicks) were resolved already by Thorsten (or Thorsten agreed to fix them). Here are the open ones: 1) There were some discussions, whether the library should be renamed and/or incorporated with other ongoing efforts. There was no definitive consensus, how to achieve this. But the discussions showed that it seems to be good, if the collection traits library could be integrated with other libraries, existing and currently developed, to make it a part of a future Boost.Range library. I'm sure, that we'll see a lot of corresponding discussions in the future. 2) The strong requirement that end() should have constant complexity rules out the integration of C-strings into the library. Additionally special threatment of char[] arrays is needed, so they behave in the same way as their char* conterparts. The problem, that end(char[]) pointed to the byte after the '\0' was corrected already. Regards Hartmut Review Manager

2 1

dynamic_bitset tests and help request to Metrowerks users
by Gennaro Prota 30 May '04

30 May '04

Hi everybody, as promised the dynamic_bitset tests are being _slowly_ settled. My apologies for the very "calm" pace but that's all that my spare time allows me. This morning I've fixed an error caused by VC6's Dinkum Lib. Since the library in this case affects the dynamic_bitset behavior I'd like to ask for you opinion. Try the following program, which attempts to read a string from an *empty* file: #include <iostream> #include <ostream> #include <fstream> #include <string> int main() { using namespace std; ofstream of("a_temporary_file"); of.close(); ifstream f("a_temporary_file"); string s = "help"; f >> s; std::cout << "The string is now " << s << '\n'; std::cout << "(length = " << s.length() << ")\n"; } With VC6's library the string is erase()d. That's because the code in the sentry constructor fails to set an error bit in the stream state if the file is empty. With all other libraries at least eofbit is set (according to lib issue 195 failbit should be set too but many implementations deliberately avoid that; see for instance: http://gcc.gnu.org/ml/libstdc++/2000-q1/msg00086.html) thus bool(sentry_object) is false and the string remains untouched. With dynamic_bitset the situation is exactly the same, as the extractor relies on the underlying library to construct a sentry. Now, the question is: do you see any problems in this? Note that it means attempting to extract a dynamic_bitset from an empty file clears the bitset with VC6's Dinkum while leaves it unchanged on (all) other implementations; however the behavior is consistent with extractions of other types (std::strings) on each platform. Fixing the behavior at the dynamic_bitset extractor level to make it consistent across different standard libraries would be, I think, quite tricky (and ugly). Secondly, a help request. There are some MW errors which I won't be able to fix, as I don't have access to that compiler: http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/output/bin-b… If anyone wants to submit a patch I'd be more than happy to integrate it. Thanks, Genny.

3 6

RE: [boost] Re: changing aCC-Link-action
by DY, JERRY U (SBCSI) 30 May '04

30 May '04

I have attached the updated acc-tools.jam file located in boost_1_31_0/tools/build/v1. I added the following option to the compile line: +z - to make the compiler generate PIC (position independent code) -- required for shared libraries. -w - suppresses warning messages And to the link line: -b - to tell the linker to generate a shared library instead of an executable. I'm assuming that aCC-Link-action is only used for generating shared library? Do you happen to know which thread functions where missing? -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Tuesday, May 11, 2004 1:50 PM To: boost(a)lists.boost.org Subject: [boost] Re: changing aCC-Link-action "DY, JERRY U (SBCSI)" <jd2419(a)sbc.com> writes: > I would like to add options to the compile and link line used for > building the threads library. I have added as follows but not sure if > it's the proper place for it. With these changes, I'm able to cleanly > compile and build the threads shared lib using aC++ 3.55 compiler. > Credit to the HP aC++ team for their help on hpux.hpp changes. > > boost_1_31_0/tools/build/v1/acc-tools.jam:105 > $(acc.bin-directory)$(CXX) -AA -mt +z -w -c +W823 -I$(BOOST_ROOT) > -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDR > S)" -I"$(STDHDRS)" -o "$(<)" "$(>)" > > boost_1_31_0/tools/build/v1/acc-tools.jam:82 > $(acc.bin-directory)$(CXX) $(LINKFLAGS) -AA -mt -b -o "$(<[1])" > -L$(LIBPATH) -L$(STDLIBPATH) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" > -l$(FINDLIBS) > > boost_1_31_0/boost/config/platform/hpux.hpp:63 > #define BOOST_HAS_PTHREADS Hi Jerry, Thanks for the info. I don't think we want to define BOOST_HAS_PTHREADS unconditionally, because IIRC at least some versions of HPUX's headers don't contain one or two of the functions used by Boost.Threads It's more effective to post a patch as an attachment, so there's no ambiguity about how mailers have mangled it, and so it can be automatically applied. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 7

iostreams library review
by slavek.f.kuzniar＠jpmorgan.com 29 May '04

29 May '04

On Boost mailing archives I found a review request for Iostreams Library by Jonathan Turkanis. I did not see any follow-up and the library is not part of latest release so I suspect the review did not happen. Anyone knows what is the fate of this library? This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.

4 4

RE: [boost] Re: [prereview request][fsm]
by Brian Braatz 29 May '04

29 May '04

My 2 cents """""""""""""""""" This is certainly doable. However, I'm unsure whether the current > design allows a you-don't-pay-for-what-you-don't-use implementation of > such a feature. Plus, I'm still not convinced that this feature would > be used more than rarely. Do you have some real-world use cases in mind? [David Abrahams] Unfortunately I'm not so familiar with what exit actions in FSMs are typically used for, but from an abstract point of view I don't think of resource releasing as an "action". If you were writing this stuff in a GC'd language, for the most part, you wouldn't devote any exit action code to resource releases. """""""""""""""""' I think this is a very good point as MS seems (IMO\whether I like it or not) to be driving us down a managed GC path for future C++ efforts. This is something to deeply consider. Not that MS is "everything", but they do have a lot of C++ developers using their tools and os's.

3 4

Re: [prereview request][fsm]
by Darryl Green 29 May '04

29 May '04

Andreas, I have looked more thoroughly at the fsm library and have this specific problem I would like advice on. The source state (as well as all the rest of the active direct and indirect inner states of the innermost common outer state) is destructed before the transition action runs. This means the actin doesn't have access to any of this context, considerably reducing the utility of state local storage. The stopwatch example shows the storage being used in the exit action, which is fine. A more complex example would be likely to have separate actions for multiple transitions. It seems that if actions need access to the state local storage of a state being left one must do the following: 1) Have states with only one transtion. 2) Be prepared to execute the actual "work" done by the system (the actions) in the exit action (which is a destructor). I don't find either of these attractive. Alternatively, a custom reaction can be used. The react function can do processing in the context of the source state (it is a member of the source state). I'm not sure how easy it is to access other active (inner or outer) states at this point? So I end up with a "pre exit" action. User defined exception handling can be used here (that is, it is possible to: 1) map an exception to an event 2) make (or not) an immediate transtion to an arbitrary state based on an exception 3) terminate 4) let the fsm framework deal with it This seems reasnably ok, but doesn't make for a nice transition table representation (the transition information is "hidden" in the react() function). Another option is: Keep a shared_ptr<my_local_storage> in the state. Construct a my_local_storage in the state constructor. In the react member function, take a copy of teh shared_ptr. This should keep my storage "alive" until the transition is complete and the new state has been entered (actually a bit longer than I would like). Am I missing something or doing something wrong? Can you recommend an approach to deal with this? Thanks Darryl Green.

2 1

Re: [boost] port of test library to vacpp
by JOAQUIN LOPEZ MU?Z 29 May '04

29 May '04

Hi Daryle ----- Mensaje original ----- De: Daryle Walker <darylew(a)hotmail.com> Fecha: Sábado, Mayo 29, 2004 6:36 pm Asunto: Re: [boost] port of test library to vacpp > On 5/27/04 5:14 AM, "Joaquín Mª López Muñoz" <joaquin(a)tid.es> wrote: > > [SNIP] > > Maybe the following is a good compromise > > > > #if defined(BOOST_NO_INCLASS_MEMBER_INITIALIZATION) > > enum npos_type { npos = (size_type)-1 } > > #else > > static const size_t npos = (size_type)-1; > > #end > > Doesn't the BOOST_STATIC_CONSTANT macro cover this? > Not quite. BOOST_STATIC_CONSTANT generates an *unnamed* enum, which is pecisely what was causing the error that originated this thread. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Quick question on XCode
by Daryle Walker 29 May '04

29 May '04

In case you're wondering where I've been, I was formatting my computer and installing Mac OS X 10.3 Panther on it. It comes with the "Project Builder" replacement, "XCode". Unfortunately, it completely changed its project configuration philosophy. Does anyone know how to add (project specific) search directories? I would need configurations that would use Boost-CVS, the latest Boost archive, the Sandbox CVS + Boost CVS, or the Sandbox CVS + Boost archive. (The sandbox would need to be searched first.) I haven't reinstalled by copy of Metrowerks CodeWarrior Pro 8.3 yet. I should get a new copy of more-I/O uploaded to Yahoo soon. (I noticed that the latest library under review jumped more-I/O's spot in the queue. [There were no definite schedule after the review before this one.] I let my e-mailbox overflow and missed all the mail on May 22nd. Did the rescheduling happen then?) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

port of test library to vacpp
by Toon Knapen 29 May '04

29 May '04

( Currently the regression status pages for IBM and SGI are not updated for two weeks because I'm unable to even compile the regression test tools. And more and more libraries are braking (on vacpp) so here's another shot at getting them to run again. ) In boost/test/detail/basic_cstring/basic_cstring.hpp contains following line: "enum npos_type { npos = (size_type)-1 }" Now size_type is previously defined as a size_t. The IBM is a 64 bit machine and size_t is 64 bits wide whereas an int is 32 bits wide. Therefore VisualAge does not accept this line. Would soth break if we change this to "enum npos_type { npose = -1 }"

8 13

[OT][fsm] I'm overwhelmed
by Andreas Huber 29 May '04

29 May '04

Dear Boosters I'm pretty much overwhelmed by the sheer volume of posts. I will try to answer every post during the weekend, but I cannot guarantee that I will not miss one or the other. If, by Sunday night you still have no answer/statement to a post you made before Saturday night then please repost your question. Thank you, Andreas

2 1

MPL for_each
by Mohammed Iqbal 29 May '04

29 May '04

Where is the documentaion of for_each? Mohammed

1 0

Re: [boost] Re: static sized strings
by Reece Dunn 29 May '04

29 May '04

Rob Stewart wrote: >From: John Nagle <nagle(a)overbot.com> > > (And you have to supply conversions.) Most strings are sized a bit too > > big, anyway. > >Oh, it just occurred to me that when the two have the same size, >there should be a cctor and copy assignment operator to avoid the >virtual function call overhead. The cctor also fixes a bug that caused a pure virtual function run-time error with VC when you have the following: template< size_t n, class C, class CSP > inline fixed_string< n, C, CSP > runtime_error() { fixed_string< n, C, CSP > res( "oops!" ); return( res ); // pure virtual call here } Thanks! >You might even be able to do >some metaprogramming to determine whether the capacity of the >source string is less than or equal to the capacity of the >destination string and avoid the virtual function call overhead >for an entire class of copies. I'll look into this. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

metacomm regressions: which borland version
by Vladimir Prus 28 May '04

28 May '04

The metacomm regression result show an error for borland compiler: http://tinyurl.com/2ql6s which reads: Assertion failed ..... config_file.cpp(144) : isTmplSpecSym(sym) .... I've just installed CBuilderX Personal, and tried to compile the library with that compiler. The interesting thing is that compiler has 5.6.4 as version string, the symbol __BORLANDC__ is defined to be 0x0564, but I don't get that error, and get some other errors. What could be the reason? - Volodya

2 3

RE: Manaed C++ (was: [boost] Re: Re: [prereview request][fsm])
by Randy Bowen 28 May '04

28 May '04

> The next version of managed C++, circa 2005, has promised > support for C++ templates. > This is probably getting off topic for Boost, but: Are you sure on this point? My understanding was that there would be general support for "generics" in managed languages, but that this is specifically not the current the C++ template mechanism. Randy Bowen Stamps.com

5 5

RE: [boost] static sized strings
by Reece Dunn 28 May '04

28 May '04

Martin wrote: >Not sure what the problem is but construction or assigment from operator+ >doesn't work int VC++2002. > >boost::fixed_string<20> xxx, yyy, zzz = xxx + yyy; > >gives the following error >[snip] The problem is that I need operator+ overloads for fixed_string: the obes for basic_string_impl will not work! I shall have a fix posted shortly. >And another thing: > >One of the find overloads doesn't check the pos argument so it might create >an >endless loop. > >inline size_type find( char_type c, size_type pos = 0 ) const { > const_iterator last( end() ); > for( const_iterator first( begin() + pos ); first != last; ++first ) Thanks! This has been corrected. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

Should std::allocator::rebind be used with std::map?
by Andreas Huber 28 May '04

28 May '04

Dear Boosters Some old implementations of std::allocator don't provide the rebind member template (e.g. MSVC6.0 stdlib). This keeps code as the following from compiling: typedef std::map< const state_base_type *, event_queue_type, std::less< const state_base_type * >, typename allocator_type::template rebind< // *** here *** std::pair< const state_base_type * const, event_queue_type > >::other > deferred_map_type; However, this map will internally not allocate objects of the type std::pair< const state_base_type * const, event_queue_type > anyway but rather of some implementation-defined tree node type. So, the above typedef could also be written as follows, ... typedef std::map< const state_base_type *, event_queue_type, std::less< const state_base_type * >, allocator_type > deferred_map_type; which should work with just about any implementation of the std library, as long as the used container is a list, (multi)set or (multi)map. Now, the questions are: - Does the standard allow the second variant (I haven't found anything pro or contra)? - Even if the standard does not allow it or is silent on it, would anyone bother to write the technically more correct first variant? If yes, even at the expense of making the code compileable on fewer compilers (or having to clutter the code with more #ifdefs)? Thanks & Regards, Andreas

4 7

Re: [boost] Re: static sized strings
by Reece Dunn 28 May '04

28 May '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > John Nagle wrote: > > > The big question is whether the size specified in the > > >declaration (as in "char_string<80>") includes the > > >trailing null. > > > > > I have modified the sandbox implementation to make it easy to switch >between > > the two models; it is currently using the 2nd model (adding space for >the > > null). One possibility is putting the choice of models as a template > > parameter (e.g. bool need_null -- see comments in the sandbox code for >an > > implementation), that way the decision is up to the programmer and not >the > > library implementor. > >This is overkill. I think you misunderstand what I am trying to say. See my comments below. >The purpose of fixed_string is to replace >arrays of characters, otherwise, std::string would be the right >replacement, right? correct. >Given that assumption, look to the syntax you're replacing: > > char s[] = "1234567890"; > assert(10 == strlen(s)); > size_t const LENGTH = 3; > char t[LENGTH + 1]; > strncpy(t, "ABCEFGHIJKLMNOP", LENGTH); > assert(LENGTH == strlen(t)); > >Now do the same with the new class: The equivalent would be: fixed_string< 15 > s( "1234567890" ); // [1] assert( 10 == strlen( s )); // C-style assert( 10 == s.size()); // C++-style const size_t LENGTH = 3; fixed_string< LENGTH > t; // [2] t = "ABCEFGHIJKLMNOP"; assert( LENGTH == strlen( t )); // C-style assert( LENGTH == t.length()); // alternate C++-style [1] You need to specify the size of the buffer. You cannot declare an object of type fixed_string_base (as it is abstract), you can only have references and pointers to it so you can operate on variable-capacity strings. [2] This is the point that we are discussing. Should this line be: fixed_string< LENGTH > t; as will work with the current sandbox implementation (my suggestion #2), or should it be: fixed_string< LENGTH + 1 > t; as in my suggestion #1. The code calculates the correct storage and capacity values at the top of the fixed_string class, because buffer overrun checks rely on these values: template< size_t n, typename CharT = char, class CharStringPolicy = std::char_traits< CharT > > class fixed_string: public fixed_string_base< CharT, CharStringPolicy > { BOOST_STATIC_CONSTANT( size_t, storage_c = n + 1 ); // = needs_null ? n + 1 : n BOOST_STATIC_CONSTANT( size_t, capacity_c = n ); // = needs_null ? n : n - 1 // ... }; Different programmers favour the different semantics, so I ask: why not parameterise it, providing a default behaviour. >(I know there is no make_fixed_string() -- yet -- but such a >facility would be appropriate.) Er... the fixed_string constructors! When you declare the object, you should know the size of the buffer you are using, e.g.: fixed_string< 100 > data; but when operating on them, you want to use any capacity buffers, so you either need a template (not good for existing code or code that needs to be in a static/dynamic library), so you use fixed_string_base, or [w]char_string if you want to save typing :). E.g. inline size_t strlen( const char_string & s ) { return( s.length()); } >I think this clearer reveals that fixed_string's size parameter >should specify the number of characters. Remember, one can use >boost::array to manage a fixed size, non-string buffer. If >buffer overrun protection is insufficient in boost::array, that >should be fixed (or a new class should be added to Boost). Thus, >fixed_string can ignore that usage. This is not what we are discussing. See above. The need_null name was to indicate that an extra charcter be reserved for the null, not whether to add a null terminator or not. Sorry for the confusion. I have started work on documentation, but it is currently in text form. I will post the documentation in BoostBook format within the next day or so. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

3 3

RE: [boost] input_iterator_facade (was: Re: [iterator facade] Why is dereference const?)
by Rozental, Gennadiy 28 May '04

28 May '04

> I still don't understand which design, yours or mine, is better. It seems mine > allows to create iterators with smaller number of lines, but maybe there's > something else. Why do you think so? I would say vice versa, since I do not require constructor in derived class to call found_eof(). Gennadiy.

3 3

RE: [boost] Re: static sized strings
by Reece Dunn 28 May '04

28 May '04

John Nagle wrote: >Reece Dunn wrote: >>Different programmers favour the different semantics, so I ask: why not >>parameterise it, providing a default behaviour. > > As with "do we null-terminate", I think we have to pick a >behavior and stick to it. I could live with either set of >semantics, but adding a parameter makes the issue more confusing. >(And you have to supply conversions.) Most strings are sized a bit too >big, anyway. Ok. I'll stick with the existing "add an extra character for null", since there seems to be more people wanting that style semantics. > On a related subject, we should have unconditional null termination. >"fixed_string" items are always null-terminated. "snprintf", >"strncat", etc. have hazardous semantics: if you overflow the string, >it is not null terminated. (This is a bug in my >current version, incidentally.) We should guarantee null >termination in all cases. The whole point of this >class is improved safety, after all. My implementation ensures this. If it does not, then it is a bug. Regards, Reece _________________________________________________________________ Get a FREE connection, FREE modem and one month's FREE line rental, plus a US or European flight when you sign up for BT Broadband! http://www.msn.co.uk/specials/btbroadband

1 0

static sized strings
by Martin 28 May '04

28 May '04

Not sure what the problem is but construction or assigment from operator+ doesn't work int VC++2002. boost::fixed_string<20> xxx, yyy, zzz = xxx + yyy; gives the following error error C2679: binary '=' : no operator found which takes a right-hand operand of type 'boost::detail::basic_string_impl<Base,ErrorPolicy>' (or there is no acceptable conversion) with [ Base=boost::detail::fixed_string_iface<char,std::char_traits<char>>, ErrorPolicy=boost::detail::noerror_string_policy ] And another thing: One of the find overloads doesn't check the pos argument so it might create an endless loop. inline size_type find( char_type c, size_type pos = 0 ) const { const_iterator last( end() ); for( const_iterator first( begin() + pos ); first != last; ++first ) ...

1 0