- Boost - lists.boost.org

Gcc and -Wundef
by Gennaro Prota 14 Jun '06

14 Jun '06

Hi guys, I tried a couple of compilations on the CVS trunk and it appears that gcc's -Wundef option is basically unusable, due to most usages of BOOST_WORKAROUND not being prefixed by a corresponding "defined expression". Now, I'm thinking: if a suitable pragma exists (I'll look it up) could we just disable that warning at the config system level? I know this impacts non-boost user code as well but, whatever that implies, we have a precedent for Visual C++: // turn off the warnings before we #include anything #pragma warning( disable : 4503 ) // warning: decorated name length exceeded Opinions? --Gennaro.

1 1

Boost.Test - misc observations
by Robert Ramey 14 Jun '06

14 Jun '06

Dear Gennadiy Rozental, I've converted my local copy of the serialization library tests to use test/minimal.hpp in the hope that I can use it in the future as the "lowest common denominator" to permit testing against a wider array of platforms. Boost Test for support of msvc is scheduled to be remove in the near future. I've had problems testing the serialization library with comeau compilers because both the seriailzation library and boost test include instantiated code for string output and the comeau "pre-linker" fails here. I've felt the need for a "lighter weight" version of boost test. Recently on a contract job of mine I used some headers from boost. I didn't need to compile any boost libraries in this case. The existence of test/minimal.hpp permitted me to use boost test without going building the libraries which turned out to be very convenient for a number of reasons. So - I'm happy with test/minimal.hpp - But - in order to make it work with the serialization library I had to make a couple of tweaks which I would like to submit in the hope that they can be incorporated into the official boost test version. Change # 1 A small change to permit commeau to be tested with the serialization library. This is obviously a crude hack but perhaps it can be fine tuned to make it acceptable. RCS file: /cvsroot/boost/boost/boost/test/impl/unit_test_parameters.ipp,v retrieving revision 1.10 diff -r1.10 unit_test_parameters.ipp 204,205c204,205 < const_string rs_str = retrieve_framework_parameter( RANDOM_SEED, argc, argv ); < s_random_seed = rs_str.is_empty() ? 0 : lexical_cast<unsigned int>(rs_str ); --- > // const_string rs_str = retrieve_framework_parameter( RANDOM_SEED, > argc, argv ); > // s_random_seed = rs_str.is_empty() ? 0 : lexical_cast<unsigned > int>( rs_str ); Change #2 I added some test tool macros for test/minimal.hpp . I would like to see these incorporated but of course could life without them if I have to. Index: minimal.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/test/minimal.hpp,v retrieving revision 1.19 diff -r1.19 minimal.hpp 17a18,19 > #define BOOST_TEST_INCLUDED > 22a25,29 > #define BOOST_WARN(exp) \ > ( (exp) \ > ? static_cast<void>(0) \ > : boost::minimal_test::report_message(#exp,__FILE__,__LINE__, > BOOST_CURRENT_FUNCTION, true) ) > 27a35,62 > #define BOOST_CHECK_MESSAGE(exp, msg_) \ > ( (exp) \ > ? static_cast<void>(0) \ > : boost::minimal_test::report_error(msg_,__FILE__,__LINE__, > BOOST_CURRENT_FUNCTION) ) > > #define BOOST_WARN_MESSAGE(exp, msg_) \ > ( (exp) \ > ? static_cast<void>(0) \ > : boost::minimal_test::report_message(msg_,__FILE__,__LINE__, > BOOST_CURRENT_FUNCTION) ) > > #define BOOST_REQUIRE_MESSAGE(exp, msg_) \ > ( (exp) \ > ? static_cast<void>(0) \ > : > boost::minimal_test::report_critical_error(msg_,__FILE__,__LINE__,BOOST_CURRENT_FUNCTION)) > > #define BOOST_WARN_EQUAL( left, right ) \ > BOOST_WARN((left) == (right)) > #define BOOST_CHECK_EQUAL( left, right ) \ > BOOST_CHECK((left) == (right)) > #define BOOST_REQUIRE_EQUAL( left, right ) \ > BOOST_require((left) == (right)) > > #define BOOST_TEST_CHECKPOINT(msg_) \ > boost::minimal_test::report_message( (msg_),__FILE__,__LINE__, > BOOST_CURRENT_FUNCTION, true ) > > #define BOOST_TEST_MESSAGE(msg_) \ > boost::minimal_test::report_message( (msg_),__FILE__,__LINE__, > BOOST_CURRENT_FUNCTION, true ) > 29a65 > 32a69,70 > #define BOOST_TEST_DONT_PRINT_LOG_VALUE( ArgumentType ) > 36c74,75 < #include <boost/test/detail/global_typedef.hpp> --- > #define BOOST_DISABLE_WIN32 > //#include <boost/test/detail/global_typedef.hpp> 38c77 < #include <boost/test/utils/class_properties.hpp> --- > //#include <boost/test/utils/class_properties.hpp> 42c81 < #include <boost/cstdlib.hpp> // for exit codes#include <boost/cstdlib.hpp> // for exit codes --- > //#include <boost/cstdlib.hpp> // for exit codes#include > <boost/cstdlib.hpp> // for exit codes 47c86 < #include <string> // std::string --- > //#include <string> // std::string 63c102 < report_error( const char* msg, const char* file, int line, const_string func_name, bool is_msg = false ) --- > report_message( const char* msg, const char* file, int line, const_string > func_name, bool is_msg = false ) 65d103 < ++errors_counter(); 79a118,124 > report_error( const char* msg, const char* file, int line, const_string > func_name, bool is_msg = false ) > { > ++errors_counter(); > report_message(msg, file, line, func_name, is_msg); > } > > inline void Thank you very much - I should say that one of your boost articles - maybe its still in there about how testing can change your life had a great effect on me. It has been very helpful to me personally. The "testing philosophy" expounded there - along with the instant availability of test/minimal.hpp - has made a night / day difference in the quality of code produced at one of my customers. Though off topic, I never really thanked you for your in depth review of the my original serialization library submission. Except for one tiny slip ("... contains this gem"), it was an exhaustive point by point critique of every aspect of it. Not that I enjoyed being on the receiving end of such criticism, it was clear to me that it was basically correct and well thought out.. After I recovered from the rejection I went back and re-did it using your critique as a checklist and was eventually successful in getting the library accepted. So, for better or worse, this library is part of boost only because of your six hour investment. Robert Ramey

6 10

[1.34.0]When will it be released?
by Sean Huang 14 Jun '06

14 Jun '06

I was very optimistic back in February that we were able to synchronize our development tool upgrade with Boost 1.34 but now I am not sure any more. I understand the burden is mostly on library maintainers. But please let us know if there is anything that the rest of boost users can do to help. Best regards, Sean

1 0

[1.34.0] Required platforms
by Thomas Witt 14 Jun '06

14 Jun '06

Hi, Here is the final list of required platforms I could come up with given our current testing resources. borland-5_8_2 cw-9.4 vc-6_5 vc-6_5-stlport vc-7_0 vc-7_1-stlport msvc-7.1 msvc-8.0 mingw-3_4_2 mingw-3_4_5 gcc-3.3.6 gcc-3.4.4 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux gcc-3.4.5_linux gcc-4.0.3_linux gcc-4.1.0_linux gcc-3.4.5_linux_x86_64 gcc-4.1.0_linux_x86_64 gcc-3_4_4_tru64 gcc-4_0_3_tru64 gcc-3.4.3_sunos darwin-4.0.1 qcc-3.3.5_cpp qcc-3.3.5_gpp intel-win-9.1 intel-linux-9.0 hp_cxx-71_006_tru64 sun-5.8 Please tell me if you think there are serious omissions or something should not be on the list. Please note that a library maintainer may always decide to mark the more esoteric platforms (for any suitable definition for 'more esoteric') as expected failures. As John had mentioned earlier the toolset names have changed so you might have to fix up old expected failures. Thanks for your help Thomas Release Manager -- Thomas Witt witt(a)acm.org

8 18

Re: [boost] [Review][PQS] Concept names?
by Jeremy Graham Siek 14 Jun '06

14 Jun '06

I'd just like to amplify what Dave is saying. It's our responsibility as the boost group to get the documentation right, especially concerning concepts, because others will emulate the documentation and coding styles that we use in boost libraries. Cheers, Jeremy > David Greene <greened_at_[hidden]> writes: > > >> E. Is the documentation good enough for a boost library? > > > > This has been made very clear and Andy has graciously accepted > > the suggested documentation changes. > > Andy has indeed graciously accepted criticism of the documentation, > for which I commend him. > > What's missing for me is a clear intention to actively pursue better > docs himself, as opposed to being willing to accept specific edits > that other people happen to suggest. If we leave the quality of our > documentation (or code, for that matter) up to people who rewrite it > for us, we won't have much quality at all. IMO the library author > has to be willing to take responsibility for making the docs work; any > help from the outside is a bonus. > > <soapbox> > Learning to write good documentation isn't easy, and we need to work > hard at helping people to learn that skill. That said, it *has* to be > a "teach a man to fish" sort of thing, because at the end of the day, > there are just too many docs to be written. > </soapbox> > > > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com

3 2

[Boost-bugs] [ boost-Patches-1489352 ] evc4 port: Interlocked*-functions without volatile
by SourceForge.net 14 Jun '06

14 Jun '06

Patches item #1489352, was opened at 05/16/06 00:20 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489352&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: None Group: None >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Michael Fink (vividos) Assigned to: Peter Dimov (pdimov) Summary: evc4 port: Interlocked*-functions without volatile Initial Comment: This patch fixes the definition of the Interlocked*-functions when using Windows CE (_WIN32_WCE is defined). The functions use the "old" (VC6 without platform SDK) forms of the functions without the volatile keyword. The patch can be applied to both CVS HEAD and the 1_34 branch, since the file wasn't modified since then. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 06/13/06 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Peter Dimov (pdimov) Date: 05/17/06 15:41 Message: Logged In: YES user_id=305912 Applied to 1.34 and HEAD. ---------------------------------------------------------------------- Comment By: Michael Fink (vividos) Date: 05/17/06 00:57 Message: Logged In: YES user_id=124874 I added a new version of the patch that avoids WINAPI (replaced by __cdecl, as used by the BOOST_MSVC part of the file. Including <windows.h> is not needed here, I think. In evc4 there are no intrinsics for the Interlocked-functions and the pragmas produce errors telling so. The _WIN32_WCE part of the file provides the BOOST_INTERLOCKED_ macros in its own section now. ---------------------------------------------------------------------- Comment By: Peter Dimov (pdimov) Date: 05/16/06 03:42 Message: Logged In: YES user_id=305912 The patch doesn't look correct to me. Using WINAPI would require inclusion of <windows.h>; in this case just defining BOOST_USE_WINDOWS_H would be a better approach. It also patches the intrinsic section without also declaring the functions as intrinsics; is this intended? Does evc4 have intrinsic support for these functions? If it doesn't, we need to disallow the intrinsic path for _WIN32_WCE and patch the WIN32 section instead. ---------------------------------------------------------------------- Comment By: Michael Fink (vividos) Date: 05/16/06 00:40 Message: Logged In: YES user_id=124874 Changed summary: it's only evc4 of course, since evc3 is too non-standard to support boost. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=307586&aid=1489352&group_… _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Boost bit_integer library
by Dr MaaTt 13 Jun '06

13 Jun '06

hi! I am trying to use the boost::big_integer library. I include the line #include "boost/big_integer.hpp" in a toy program (as I have with the others) but it generated hundreds of lines of linker-error messages. I have boost (path) set up properly and have dumped the relevant files / folders into the boost and libs folders accordingly.... what am I doing wrong? Thanks for your help in advance Matt

1 0

[Iostreams] Possible minor bug
by Dave Odell 13 Jun '06

13 Jun '06

When I run the following program (under Windows XP, Visual C++ 8), the BOOST_ASSERT statement fails (If you want to run it, make sure there's a file named temp.cpp in the same folder): #include <boost/iostreams/device/mapped_file.hpp> #include <iostream> int main() { try { boost::iostreams::mapped_file file; file.open("temp.cpp", std::ios_base::in); file.close(); BOOST_ASSERT(!file.is_open()); } catch(const std::exception &exc) { std::cout << exc.what() << std::endl; } return 0; } I think the problem is in mapped_file.cpp, line 124: bool mapped_file_source::is_open() const { return !!pimpl_ && pimpl_->handle_ != 0; } Since mapped_file_impl::close() sets handle_ to INVALID_HANDLE_VALUE (mapped_file.cpp, line 65), I would guess that is_open() should say pimpl_->handle_ != INVALID_HANDLE_VALUE. Dave Odell dmo2118(a)gmail.com

1 0

[Review][PQS] Review ends
by fred bertsch 13 Jun '06

13 Jun '06

Hello, boosters! Any given day exists for 50 hours, but it does end at some point. Likewise, the PQS review ends at some point. I will arbitrarily say midnight UTC and the timezone of the author. However, it will take me roughly a week to collate all of the reviews and reach an official decision, so don't feel shy about posting or mailing me additional reviews. I thank the reviewers very much for reviewing the library, and I thank Andy Little even more for all of his work responding to the reviews and for writing the library in the first place! -Fred Bertsch

8 23

[shmem-interprocess] Shmem 0.93 and update on Interprocess
by Ion Gaztañaga 13 Jun '06

13 Jun '06

Hi to all, I've just uploaded to Boost Vault a new Shmem bugfix version (0.93) with bugfixes to make Shmem MinGw friendly (props to Jan Stetka). Library and documentation download: http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=M… Online documentation: http://ice.prohosting.com/newfunk/boost/libs/shmem/ //////////////////////////////////////////////////////////// Update on Interprocess: -> Due to Shmem problems with shared memory/named mutex/name semaphore lifetime between POSIX/Windows. I've decided to change Shmem approach (emulation of Windows lifetime behavior in POSIX with reference counting) to a POSIX lifetime (explicit unlinking shared memory). This means that I have to rework all main classes to achieve POSIX persistence semantics in Windows even when a process crashes. This will require using memory mapped files to emulate shared memory (with some tricks to avoid performance problems with file-memory synchronization if it's possible). I think that this approach will be much more portable than the Shmem approach. -> I'm also experimenting with a new allocator with expand-in place capabilities to allow realloc-like features in shared memory containers. The first results are encouraging both in size savings and speed improvements. This expand in place features are based on a paper I plan to present as a ISO C++ proposal based on N1953. You can find the current draft here, if you want to make some comments: http://ice.prohosting.com/newfunk/proposals/nXXXX%20Improving%20STL%20Alloc… -> I'm also experimenting with a new reduced mutex interface (basically condensing shared_mutex, shared_try_mutex and shared_timed_mutex in a single interprocess_mutex type. Something in the line of the draft "Simplifying And Extending Mutex and Scoped Lock Types For C++ Multi-Threading Library" that you can find here: http://ice.prohosting.com/newfunk/proposals/ I'm also trying to implement a process-shared version of Howard Hinnant's upgradable_mutex class described here: http://home.twcny.rr.com/hinnant/cpp_extensions/rw_perf.html http://home.twcny.rr.com/hinnant/cpp_extensions/threads_move.html I still have some bugs in my upgradable_mutex implementation that I plan to solve soon. I think that this enhazed rw mutex is a winner for Interprocess. -> I'm adding a new mutex type: file_lock. The classic UNIX fcntl / Windows FileLockEx file locking is an interesting addition to Interprocess since both in POSIX and Windows, the lock is automatically unlocked by the OS when the process ends/crashes. This can help problematic Shmem atomic creation+initialization functions if the process crashes executing the atomic code. File locking is also many times easier to use than named mutexes or shared memory + process shared mutexes, specially for simple locking. That's all. Thanks for your patience! Regards, Ion

5 11