May 2006 - Boost - lists.boost.org

[filesystem] introduce wide-only mode?
by Michael Fink 11 May '06

11 May '06

Hi, while porting Boost to evc4 I noticed that Boost.Filesystem makes heavy use of the Ansi Win32-API functions such as CreateFileA etc. There is a mode that can be enabled with the define BOOST_FILESYSTEM_NARROW_ONLY so that only Ansi APIs are used. Is it thinkable to introduce a BOOST_FILESYSTEM_WIDE_ONLY mode, e.g. when BOOST_NO_ANSI_APIS is defined? Should I try to implement such a mode, or is it too complicated? bye Michael

5 5

[Boost-bugs] [ boost-Bugs-1486232 ] memry leak with boost::gregorian::date_facet
by SourceForge.net 11 May '06

11 May '06

Bugs item #1486232, was opened at 2006-05-11 06:29 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=1486232&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: date_time Group: None Status: Open Resolution: None Priority: 5 Submitted By: Serge (mandryka000) Assigned to: Jeff Garland (az_sw_dude) Summary: memry leak with boost::gregorian::date_facet Initial Comment: the following snippet causes a segmentation fault: using namespace boost::gregorian; date_facet * facet = new date_facet("%D"); //OK delete facet; //sergmentation error, here! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1486232&group_… ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[Range] patched: boost/range/iterator.hpp
by David Abrahams 11 May '06

11 May '06

Hi Thorsten, I took the liberty of checking this patch into the HEAD: Please let me know if you have any objections. -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 14

Re: [boost] Building and testing filesystem library on AIX
by chris.grayson＠database-brothers.com 10 May '06

10 May '06

Beman, thanks for the reply. > Boost.Filesystem doesn't directly do any multi-threading, but it does use > shared_ptr. Are the shared_ptr tests working for you? If not, you need to > resolve those problems before trying Boost.Filesystem. I ran the tests in libs/smart_ptr/test, including the longer test of "shared_ptr_alloc_test", and they passed with flying colors (except the two intentional compile failures; those threw me for a minute :-). >> ../../../bin/boost/libs/filesystem/test/path_test.test/gcc/debug/path_test.run >> ====== BEGIN OUTPUT ====== >> Platform is POSIX >> /data2/cgrayson/boost_1_33_1/boost/test/minimal.hpp(122): exception >> "signal: SIGABRT (application abort requested)" caught in function: >> 'int main(int, >> char**)' >> >> **** Testing aborted. >> **** 1 error detected >> >> EXIT STATUS: 201 >> ====== END OUTPUT ====== > > Any chance of getting a call stack trace at time of abort? > The crash is happening when running the "path_test.cpp" test, in particular in the call to "path::default_name_check(fs::no_check);" in the try block below: 77 BOOST_CHECK( path::default_name_check_writable() ); 78 BOOST_CHECK( path::default_name_check() == fs::portable_name ); 79 BOOST_CHECK( !path::default_name_check_writable() ); 80 bool default_name_check_threw = false; 81 try { path::default_name_check( fs::no_check ); } 82 catch ( const fs::filesystem_error & ) { default_name_check_threw = true; } 83 BOOST_CHECK( default_name_check_threw ); Execution never reaches the catch, or the last BOOST_CHECK listed. Thanks, Chris

1 0

Building and testing filesystem library on AIX
by chris.grayson＠database-brothers.com 10 May '06

10 May '06

I'm trying to build and test Boost on AIX 5.3, with gcc 3.3.2, but not getting very far. I'm focusing on the filesystem library, using the following build command: $ bjam "-sTOOLS=gcc" "-sBUILD=release debug <threading>single/multi <runtime-link>static/dynamic <linkflags>-pthread" --without-python --with-filesystem stage Without "<linkflags>-pthread", it fails with errors like "Undefined symbol: .pthread_mutex_lock". So, this command seems to work okay, although I do get the following linker warnings for all four .so links: ld: 0711-224 WARNING: Duplicate symbol: _GLOBAL__F_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: ._GLOBAL__I_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: ._GLOBAL__D_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: _GLOBAL__I_thread_creds_t ld: 0711-224 WARNING: Duplicate symbol: _GLOBAL__D_thread_creds_t Then I want to verify the build, so I cd down into libs/filesystem/test, and try to run the test there by executing the following (the <linkflags>-pthread still seems to be required): $ bjam "-sBUILD=<linkflags>-pthread" The first problem I run into is this: ld: 0706-006 Cannot find or open library file: -l boost_filesystem-gcc-d-1_33_1 In the only "-L" directory listed in the g++ command line printed out after that ("../../../bin/boost/libs/filesystem/build/libboost_filesystem.so/gcc/debug/shared-linkable-true"), there is a libboost_filesystem-gcc-d-1_33_1.so, but no libboost_filesystem-gcc-d-1_33_1.a. So I manually copy the built libboost_filesystem-gcc-d-1_33_1.a from "../../../stage/lib", and try the same bjam command again. This time, the build part seems to work, though it gives the same linker warnings shown above for 2 of the 7 links ("../../../bin/boost/libs/filesystem/test/path_test_dll.test/gcc/debug/path_test_dll" and "../../../bin/boost/libs/filesystem/test/operations_test_dll.test/gcc/debug/operations_test_dll"). Then it tries to run the first test, but immediately crashes: execute-test ../../../bin/boost/libs/filesystem/test/path_test.test/gcc/debug/path_test.run ====== BEGIN OUTPUT ====== Platform is POSIX /data2/cgrayson/boost_1_33_1/boost/test/minimal.hpp(122): exception "signal: SIGABRT (application abort requested)" caught in function: 'int main(int, char**)' **** Testing aborted. **** 1 error detected EXIT STATUS: 201 ====== END OUTPUT ====== Any help would be greatly appreciated - thanks. Chris Grayson Database-Brothers, Inc. Austin, TX

2 1

Re: [boost] [filesystem][program_options][serialization][test] from comp.lang.c++.moderated
by Ames Andreas 10 May '06

10 May '06

Hello, > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams > Sent: Tuesday, May 09, 2006 1:18 PM > > I agree with that; no question about it. I think a few more degrees > of classification than you've outlined could be useful: > > core vs. optional > > I hate "optional" but can't think of a better term right now. > This is the distinction between, e.g., type traits and > serialization I think, the distinction between 'boost.core' and 'boost.optional' (or 'dependent' or sth.) could also be useful to release the strong requirements concerning dependencies between boost libs. While core could still be (almost) free of lib interdependencies, 'optional' libs could freely link to others (possibly even third party, i.e. XML parsers etc.). IIRC, property tree was critisised because of its dependencies, but when libs get more complex (and more directly related to applications), such dependencies may be inevitable and even useful, while it's still nice to have a core of independent libs. > fluidity > > "frozen" == Only bugfixes, in principle. A library can move out > of "frozen" to stable at the whim of its maintainer. > > "stable" == Only bugfixes and extensions. > > "active" == backwards-incompatible changes avoided with extreme > prejudice, and made only after one release of deprecation. A > strong bias is given towards preserving availability of old > interfaces under the same name, even if they've been superceded by > newer ones. > > "fluid" == whether we should have such a category is open to > debate. Sounds like a lot of work for the maintainers and the release managers. Maybe it would be sufficient to let every lib have ist own version (aside from the boost version) and use the usual versioning scheme, where changes of the minor version denote downward compatible APIs while new majors indicate API breakage (versionwise). Just my 0.02EUR as a lurker. cheers, aa -- Andreas Ames | Programmer | Comergo GmbH | Voice: +49 69 7505 3213 | ames AT avaya . com

3 2

Problem with shared_ptr in MSVC8.0 (only when compiled in /clr mode ?)
by Loïc Joly 10 May '06

10 May '06

Hello everybody, In boost::shared_ptr, there is a trick to get a type convertible to bool that is not a bool... unspecified_bool_type is a function pointer. However, with MSVC8.0, and at least when I compile with /clr, I seem to have some problem with it : The null fct ptr seems to be coded 0xffffffff. That is just fine in non /clr compilation, where it gets evaluated as false when converted in boolean. But in /clr mode, it is converted to true. I guess this is a problem with the compiler, but would it not be possible to use a not so clever unspecified_bool_type with this compiler as a work-around ? Best regards, -- Loïc

2 5

Re: [boost] [review] Fusion review begins
by Martin Bonner 10 May '06

10 May '06

----Original Message---- From: Powell, Gary > Oleg> I propose to change tuple manipulators to be: > Oleg> 1) tuple_bounds("(", ")") // if need to specify one bound, I > Oleg> need to specify both. > Oleg> 2) tuple_delimiter(",") // I'm happy with bounds, but > Oleg> delimiter should be specified. > Oleg> 3) tuple_punc("(", ",", ")") // I should specify all > punctuation. >> > > The issue is that if you use a facet to do punct, it's tied to the > type of container. > > I apologize for not looking at what the current code does, but the > stuff I wrote orginally was tied directly to the tuples. > > Also, you probably want to stick with 'C' not "C"; I don't think you should rule out: tuple_punc("<tuple>", "\n", "</tuple>") -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

2 1

[string_convert] efficiency of to_string_classic
by Alexander Nasonov 10 May '06

10 May '06

I played with to_string_classic from vault / Strings - Text Processing / string_convert.zip It's faster then ostringstream but not much: Intel 8.1.028 on FreeBSD 6.1, -O2: ostream-based implementations (best of three runs) | ---------------------------------------------------- to_string_classic | 26.091 seconds | ---------------------------------------------------- ostringstream | 32.335 seconds | ---------------------------------------------------- GNU gcc 3.4.4 on FreeBSD 6.1, -O2: ostream-based implementations (best of three runs) | ---------------------------------------------------- to_string_classic | 25.126 seconds | ---------------------------------------------------- ostringstream | 31.333 seconds | ---------------------------------------------------- This is very slow compared to integral2str function defined in vault / Strings - Text Processing / integral2str.hpp Unlike to_string_classic which returns std::string, integral2str function returns boost::array<char,N>. I wrap it into std::string for more accurate comparison with to_string_classic. Here are the results: Intel 8.1.028 on FreeBSD 6.1, -O2: integral2str (worst of three runs) | ------------------------------------ std::string | 5.690 seconds | ------------------------------------ boost::array | 0.734 seconds | ------------------------------------ GNU gcc 3.4.4 on FreeBSD 6.1, -O2: integral2str (worst of three runs) | ------------------------------------ std::string | 5.763 seconds | ------------------------------------ boost::array | 1.247 seconds | ------------------------------------ // // Code that measure performance of ostream-based implementations // #include "to_string.hpp" #include <locale> #include <sstream> std::string slow(int n) { std::ostringstream out; out.imbue(std::locale::classic()); out << n; return out.str(); } int main() { using namespace string_convert; char volatile x = 0; for(int i = 0; i < 10000000; ++i) x += to_string_classic(i)[i % 2]; //x += slow(i)[i % 2]; return x; } // // Code that measure performance of integral2str // #include "integral2str.hpp" #include <string> int main() { char volatile x = 0; for(int i = 0; i < 10000000; ++i) x += integral2str(i)[i % 2]; //x += std::string(integral2str(i).data())[i % 2]; return x; } -- Alexander Nasonov Project Manager http://www.akmosoft.com

2 1

portable C++ signal handlers?
by Ryan Gallagher 10 May '06

10 May '06

Gennadiy Rozental wrote: > SIGNAL catching is optional and doesn't constitute portabiltiy issues per se, > whether to use it's up to you. Out of curiousity, what is a good (portable?) way of dealing with signals in C++? C signal handling seems to force globals on you, which is a pain especially when signal handling is a late requirement. Doing a bit of online research recently I read that some people prefer to translate signals to exceptions. As a co-worker of mine has pointed out this is how python deals with it (with python exceptions that is). >From what I've read though this is not portable, and, besides, is often not the control flow I would desire. Further reading suggested the use of singletons for registration of handlers. This (glorified global) seemed to make sense to me and I came up with the attached code for this. However, I do refer to statics here, which also may be non-portable. It does work with msvc-7.1 though. (Is it the case of multi-processors that makes this non-portable?) (Perhaps this should move to comp.lang.c++.moderated? This code is welcomed to be used by the boost community though. Distributed under boost software licence and all that...) Please feel free to critique in discussing this issue as I'm fairly inexperienced with dealing with signals outside of C. If possible I'd like to see a solution like this that works on boost's supported platforms and released as part of boost. -Ryan /// Singleton class to register and dispatch to handlers for c-style signals. /// @note Because the signal_registry::dispatch handler refers to the static /// instance of this class, which is not of type sig_atomic_t, this /// class is technically incurring undefined behavior. In practice /// compiler implementation support this action (at least better so /// that throwing an exception from the handler). /// class signal_registry : boost::noncopyable { private: typedef boost::signal<void (int)> signal_type; typedef boost::shared_ptr<signal_type> signal_pointer; typedef std::map<int, signal_pointer> signal_id_to_handler_map_type; public: /// Access to the singleton instance. /// @return The singleton instance. static signal_registry& instance() { static signal_registry meyers_singleton_instance; return meyers_singleton_instance; } /// Register a new handler to call on the given signal. /// When signaled, the handlers are called in the reverse order registered. /// @note previous handlers are not replaced. /// @param signal_id The id of the signal for which to register the handler /// (e.g. SIGINT). /// @param handler The callback for handling the given signal. It's /// argument will be the signal_id. boost::signals::connection register_handler(int signal_id, boost::function<void (int)> const& handler) { if(m_signals.count(signal_id) == 0) { std::signal(signal_id, &signal_registry::dispatch); m_signals[signal_id] = signal_pointer(new signal_type()); } return m_signals[signal_id]->connect(handler, boost::signals::at_front); } /// Dispatch the given signal to the stored handlers, if any. /// @param signal_id The id of the signal raised (e.g. SIGINT). /// @retval true If a handler was called. /// @retval false Otherwise. static void dispatch(int signal_id) { instance().dispatch_impl(signal_id); } private: void dispatch_impl(int signal_id) const { signal_id_to_handler_map_type::const_iterator handler_iter = m_signals.find(signal_id); if(handler_iter != m_signals.end() && !((handler_iter->second)->empty())) { (*(handler_iter->second))(signal_id); } } signal_id_to_handler_map_type m_signals; ~signal_registry() {} };

4 7