- Boost - lists.boost.org

1.33.1 Final Release Plan
by Doug Gregor 14 Nov '05

14 Nov '05

Boost 1.33.1 Final will be released on December 5, 2005. Not "around" December 5, 2005; not "a week after" December 5, 2005; on December 5, 2005. As with the other releases in the 1.33.x series, it will come from the RC_1_33_0 branch. Minor bug fixes and documentation patches can be committed to the branch with my approval. If a change causes new failures, it will be reverted. A timeline: November 8: Boost 1.33.1 Beta released November 9: RC_1_33_0 open for bug fixes, documentation updates with prior approval November 28: RC_1_33_0 branch completely frozen. Final regression test results. December 2: Boost 1.33.1 release candidate. December 5: Boost 1.33.1 release. Doug

2 1

shared_ptr - allocator template argument
by Michael Schneider 14 Nov '05

14 Nov '05

Is there a reason why shred_ptr does not accept an allocator? shared_ptr seems to allocate sp_counted_impl_p<...> using new, it it took in an allocator, then the allocator could be assigned the responsibility to allocate the memory for sp_counter_impl_p. We have an application requirement that all application memory must be managed by our memory allocation system. We have a secondary requirement that we can't replace global new and delete. It seems like this requirement could be satisfied by adding an allocator to shared_ptr. I could make this change locally, but it seems like this would be a common requirement that would be useful for several application domains. Couple of quick questions: - am I off in the weeds with this suggestion? Is there a simple way to meet our memory requirement without modifying shared_ptr?? - If a change is required, what can I do to help make this change in boos (I am new to the boost community)? If this is not useful to the community, please let me know. I can code this in internal code if that is best for the boost community. Thanks Mike -- The greatest performance improvement occurs on the transition of from the non-working state to the working state.

3 2

Proposal: XML APIs in boost
by Stefan Seefeld 14 Nov '05

14 Nov '05

Some years ago I proposed a XML-related APIs for inclusion into boost (http://lists.boost.org/Archives/boost/2003/06/48955.php) Everybody agreed that such APIs would be very useful as part of boost. Unfortunately, though, after some weeks of discussing a number of details, I got distracted, and so I never managed to submit an enhancement. I'v now started to look into this topic again, and wrote down a start of a DOM-like API as I believe would be suitable for boost. Here are some highlights: * User access dom nodes as <>_ptr objects. All memory management is hidden, and only requires the document itself to be managed. * The API is modular to allow incremental addition of new modules with minimal impact on existing ones. This implies that implementations may only support a subset of the API. (For example, no validation.) * All classes are parametrized around the (unicode) string type, so the code can be bound to arbitrary unicode libraries, or even std::string, if all potential input will be ASCII only. * The Implementation uses existing libraries (libxml2, to be specific), since writing a XML DOM library requires substantial efford. A first sketch at a XML API is submitted to the boost file vault under the 'Programming Interfaces' category. It contains demo code, as well as some auto-generated documentation. I'm aware that this requires some more work before I can attempt a formal submission. This is simply to see whether there is still any interest into such an API, and to get some discussion on the design. Regards, Stefan

19 93

Re: [boost] Compilation problems on VC7 of code uses boost 1.31.0
by Miko Nahum 14 Nov '05

14 Nov '05

Thanks John. Your answer helped us great deal. I have removed the allocator stuff and problem solved. Concerning the 'collate' issue, still considering if to make changes to boost enum. Regards, Miko -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Thursday, November 10, 2005 1:05 PM To: boost(a)lists.boost.org Subject: Re: [boost] Compilation problems on VC7 of code uses boost 1.31.0 > We have the following piece of code that uses boost (copy/paste): I'm afraid I don't have a copy of 1.31 lying around anymore, but your problems are almost certainly allocator related. Can you remove the allocator related code? As it stands your code doesn't actually "do" anything. Or or you actually using a custom allocator? As for the HP aCC problem: it's very similar to one that occurs with VC7 when there's a "using namespace std;" declaration before including regex: the compiler is then unable to differentiate between std::collate (the template) and boost::collate (the constant), and it's a compiler bug. Otherwise your workaround is as good as any I guess. Are you in a position to upgrade to Boost-1.33.1 ? The bad news is that your code as it stands will likely need some porting to make the change (reg_expression has been deprecated in favour of basic_regex for example, but the typedefs like boost::regex boost::wregex etc are all the same). The good news is that the regex matching code has been substantially re-written to be much faster, and hardly does any memory allocation at all (or even none at all under ideal conditions), so custom allocators are very much a thing of the past. It would simplify your code to: #include "boost/regex.hpp" using namespace boost; using namespace std; typedef boost::regex re_type; long example_func(long pos, const std::string& regE, long& reslen, long max) { long res; boost::match_results <PData::iterator> m; re_type e; e.assign (regE, regbase::normal); if (regex_search (begin (), end (), m, e, match_not_dot_newline | match_not_dot_null)) { res = pos + m.position(); reslen = m.length(); return res; } Sorry I can't be more helpful about this: diagnosing these kinds of deep template instantiation errors are next to impossible sometimes, but are almost always errors in the template argument list. Hope this helps a little at least, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Static Member declaration GCC
by Bernd Martin Wollny 14 Nov '05

14 Nov '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello, I tried to declare a boost:shared_ptr as a static member of a template function. If I compile the program with Visual Studio all are Ok. If I try to compile the code with gcc, gcc failed with: t1.cpp:71: error: too few template-parameter-lists t1.cpp:72: error: too few template-parameter-lists There is a small mistake in my code but I can't find the error. Can someone help me? Bye Bernd - ------------------ code ----------------------------- #include <boost/thread/mutex.hpp> #include <boost/shared_ptr.hpp> template <class T> class SimpleSingleton { public: SimpleSingleton() { } ~SimpleSingleton() { } T * instance() { boost::mutex::scoped_lock sp_lock(inst_mutex); if (!as.get()) { boost::shared_ptr<T> temp(new T); as=temp; } return as.get(); } protected: static boost::shared_ptr<T>(as); static boost::mutex inst_mutex; }; class test { protected: test(void) { a_=0; } public: ~test(void) { } int Get(void) { return a_; } void Set(int a) { a_ = a; } protected: int a_; friend class SimpleSingleton<test>; }; boost::shared_ptr<test> SimpleSingleton<test>::as; boost::mutex SimpleSingleton<test>::inst_mutex; int main(void) { SimpleSingleton<test> t; t.instance()->Set(45); int b=t.instance()->Get(); return b; } - ------------------ code ----------------------------- - -- TRIOPTICS GmbH Bernd Martin Wollny Software Designer Hafenstrasse 39, 22880 Wedel/GERMANY phone / fax: +49 (0)4103 18006-26 /-20 e-mail: bm.wollny(a)trioptics.com All E-Mails from bm.wollny(a)trioptics.com are digital signed. If you get a unsigned E-Mail, this E-Mail are a fake. Look at http://www.gnupg.org . -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDdKc4CjfVnTPD3b4RA+0HAKC4jcBEeYvc75ZqJj4q2cNALGFElwCfZANJ X2i8t+fFa5o/rQQyha0KDqs= =BUfl -----END PGP SIGNATURE-----

3 3

RTL and example are updated in the file vault
by Arkadiy Vertleyb 14 Nov '05

14 Nov '05

Hi all, I spent some time optimizing the RTL example discussed some time ago, as well as related parts of the library. The result (according to my estimate) is almost 10 times increase in performance. Jose, if you could time it again on your PC, we would have more accurate result. Among other optimizations, I also switched to a faster but less accurate formula for distance calculations, which lead to a slight change in the result -- apparently two stations are located at the distance of almost exactly 5 km. The library and example are at their usual place in the file vault, http://tinyurl.com/8lbmg. As always, comments are welcome. Regards, Arkadiy

1 0

Re: [boost] Gender neutral documentation
by Martin Bonner 13 Nov '05

13 Nov '05

Angus Leeming wrote: > > Returning to the original example: > This means for example that the client can completely > discard Bind if she does not need it. > I'd suggest rewriting it as: > This means that the user can discard Bind completely > if it is not needed. > > That would get rid of a split infinitive too, but that's a whole other > ball game :) a) I don't see a split infinitive in the original. b) Your rewrite has transformed a clause in the active voice ("she does not need it") to the passive voice ("it is not needed"). The problem with documentation in the passive voice is that it doesn't make clear /who/ doesn't need Bind. My rewrite would be: This means, for example, that the client can completely discard Bind if they don't need it. -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

9 10

singleton and active objects
by Jason Hise 13 Nov '05

13 Nov '05

It occurred to me recently that having the option to make a singleton an active object may be vital in order to make an efficient multi-threaded singleton viable. By having function calls on the singleton enqueue requests and return future variables, threads should be able to access the singleton reasonably often without creating a bottleneck. The question is, should I try to develop and submit an active object library before trying to get singleton accepted? I suspect that having an efficient multi-threaded solution available would help the next singleton review substantially. -Jason

2 1

Boost Test - yet more mostly spurious warnings.
by Paul A Bristow 13 Nov '05

13 Nov '05

To get quiet compilations (MSVC 8.0 release 140050727, level 4, no MS extensions), I have had to disable persistent warnings from boost\test\detail\test_tools.hpp by adding to supress_warning.hpp # pragma warning(disable: 4127) // conditional expression is constant. Entirely correct and expected. # pragma warning(disable: 4180) // qualifier applied to function type has no meaning; ignored at: const_string message() const { return !m_message ? const_string() : const_string( m_message->str() ); } ^^ const not useful? but not wrong. # pragma warning(disable: 4224) // nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(385) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(427) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(427) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(427) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(427) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type i:\boost_1_33_0\boost/test/test_tools.hpp(427) : warning C4224: nonstandard extension used : formal parameter 'tool_level' was previously defined as a type Is it complaining about re-using the name tool_level? void check_impl( predicate_result const& pr, wrap_stringstream& check_descr, const_string file_name, std::size_t line_num, tool_level tool_level, check_type ct, <<<<<<<<<<<<<< std::size_t num_args, ... ); Of these, only the latter might be worth worrying about? Still works fine, but if you are tidying up sometime... Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow(a)hetp.u-net.com www.hetp.u-net.com

2 4

Boost regression notification (2005-11-13 [RC_1_33_0])
by Douglas Gregor 13 Nov '05

13 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-13T13:51:12Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_33_0/developer/i… 0 failure in 0 library:

1 0