- Boost - lists.boost.org

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

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

13 Nov '05

Boost regression test failures ------------------------------ Report time: 2005-11-13T06:00:08Z This report lists all regression test failures on release platforms. WARNING: The following libraries have failing regression tests but do not have a maintainer on file. Once a maintainer is found, add an entry to libs/maintainers.txt to eliminate this message. io Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 223 failures in 13 libraries: concept_check (12) date_time (2) graph (2) io (1) mpl (1) python (56) serialization (30) spirit (8) thread (4) tr1 (71) tuple (1) typeof (18) xpressive (17) |concept_check| stl_concept_covering: cw-9_4 gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 vc-7_1 |date_time| testwcustom_time_zone: mingw-3_4_2 testwposix_time_zone: mingw-3_4_2 |graph| graphviz_test: vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |mpl| size_t: gcc-4_0-darwin |python| andreas_beyer: vc-7_1 args: vc-7_1 auto_ptr: vc-7_1 back_reference: vc-7_1 ben_scott1: vc-7_1 bienstman1: vc-7_1 bienstman2: vc-7_1 bienstman3: vc-7_1 builtin_converters: vc-7_1 callbacks: vc-7_1 const_argument: vc-7_1 crossmod_exception: vc-7_1 data_members: vc-7_1 defaults: vc-7_1 dict: vc-7_1 docstring: vc-7_1 enum: vc-7_1 exception_translator: vc-7_1 extract: vc-7_1 implicit: vc-7_1 injected: vc-7_1 iterator: vc-7_1 keywords: vc-7_1 list: vc-7_1 long: vc-7_1 map_indexing_suite: vc-7_1 minimal: vc-7_1 multi_arg_constructor: vc-7_1 nested: vc-7_1 numpy: vc-7_1 object: vc-7_1 opaque: vc-7_1 operators: vc-7_1 pearu1: vc-7_1 pickle1: vc-7_1 pickle2: vc-7_1 pickle3: vc-7_1 pickle4: vc-7_1 pointer_vector: vc-7_1 polymorphism: vc-7_1 polymorphism2: vc-7_1 polymorphism2_auto_ptr: vc-7_1 properties: vc-7_1 raw_ctor: vc-7_1 return_arg: vc-7_1 shared_ptr: vc-7_1 slice: vc-7_1 staticmethod: vc-7_1 stl_iterator: vc-7_1 str: vc-7_1 test_pointer_adoption: vc-7_1 try: vc-7_1 tuple: vc-7_1 vector_indexing_suite: vc-7_1 virtual_functions: vc-7_1 wrapper_held_type: vc-7_1 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin |spirit| action_tests_debug: gcc-3_4_3-sunos distinct_tests_debug: gcc-3_4_3-sunos escape_char_parser_tests_debug: gcc-3_4_3-sunos grammar_def_test_debug: gcc-3_4_3-sunos switch_problem_debug: gcc-3_4_3-sunos switch_tests_single_debug: gcc-3_4_3-sunos traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |thread| test_condition: gcc-3_4_3-sunos test_mutex: gcc-3_4_3-sunos test_tss: gcc-3_4_3-sunos gcc-3_4_3-sunos |tr1| run_complex_overloads: gcc-2.95.3-linux std_run_complex_overloads: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 mingw-3_4_2 std_run_random: gcc-2.95.3-linux mingw-3_4_2 std_test_bind: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_boost: gcc-2.95.3-linux std_test_complex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_function: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_hash: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_mem_fn: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_reference_wrapper: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 std_test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_shared_ptr: gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_tr1_include: gcc-2.95.3-linux mingw-3_4_2 std_test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux intel-win32-9_0 std_test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_complex: gcc-2.95.3-linux test_hash: gcc-2.95.3-linux test_ios: gcc-2.95.3-linux test_istream: gcc-2.95.3-linux test_iterator: gcc-2.95.3-linux test_limits: gcc-2.95.3-linux test_locale: gcc-2.95.3-linux test_ostream: gcc-2.95.3-linux test_regex: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_result_of: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_streambuf: gcc-2.95.3-linux test_tr1_include: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 test_tuple: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_type_traits: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3_3-darwin test_utility: gcc-2.95.3-linux tr1_remove_bounds_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin intel-win32-9_0 mingw-3_4_2 vc-7_1 |tuple| tuple_test_bench: gcc-3_4_3-sunos |typeof| data_member_native: cw-9_4 function_native: cw-9_4 function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 member_function_native: cw-9_4 modifiers_emulation: cw-9_4 modifiers_native: cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 template_type_native: cw-9_4 type_native: cw-9_4 |xpressive| misc1: mingw-3_4_2 test1: mingw-3_4_2 test2: mingw-3_4_2 test3: mingw-3_4_2 test3u: gcc-3_3-darwin test4: mingw-3_4_2 test4u: gcc-3_3-darwin test5: mingw-3_4_2 test5u: gcc-3_3-darwin test6: mingw-3_4_2 test6u: gcc-3_3-darwin test7: mingw-3_4_2 test8: mingw-3_4_2 test9: mingw-3_4_2 test9u: gcc-3_3-darwin test_cycles: mingw-3_4_2 test_non_char: mingw-3_4_2

1 0

Re: [boost] serialization performance
by David Abrahams 13 Nov '05

13 Nov '05

bwood <brass(a)mailvault.com> writes: > Hi, Dave, Hi Brian > I work on www.webEbenezer.net. I noticed today that Robert > Ramey said "So far so good" regarding some performance tests > he is doing. You might want to encourage him to consider > some of the competition as far as performance. You should probably be doing that, actually ;-) I'm helpfully cross-posting this reply to the Boost developers' list, but next time, please do it yourself so that you get "in the mix" there. Having these kinds of reports in the public record, and having people like you involved in the ensuing discussion, are crucial for the Boost process. Thanks again for writing. > Some recent tests I've done that compare Ebenezer Enterprises > and Boost.serialization's performance show the > Boost.serialization approach to be 7 to 9 times slower than the > Ebenezer Enterprises approach. I'm using Linux 2.6.12, > gcc 4.0.2 (with -O3) and a Boost.serialization library from the > release tree. A test that compared the times to serialize/send > a list<int> took 7.4 times longer with Boost than Ebenezer. > I timed the following > Boost: > oArch & lst; // oArch is a binary_oarchive > > Ebenezer: > msgs.Send(buffer, lst); // In order to compare apples to apples, > // I removed a section of code at the end > > // of the Send function that flushes the > buffer. > > > In a second test I added a deque of int... > Boost: > oArch & lst; > oArch & dq; // std::deque<int> dq; > > Ebenezer: > msgs.Send(buffer, lst, dq); > > In this case Boost took 9.1 times longer than Ebenezer Enterprises > approach. If you want to run these tests with other compilers I > think that would be helpful. I've been warned not to put too much > emphasis on numbers from gcc. > > Regards, > Brian Wood -- Dave Abrahams Boost Consulting www.boost-consulting.com

4 11