June 2004 - Boost - lists.preview.boost.org

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