- Boost - lists.preview.boost.org

Re: [boost] Bugs in regression/library_status.cpp on Windows
by Robert Kawulak 24 Jul '11

24 Jul '11

Hi, Could anybody please apply that patch or suggest what can I do (or whom to contact directly) to get this fixed? BTW, I wonder how it's possible that most of the bugs were introduced in one commit half a year ago and nobody even noticed - it would suffice to run this app on any platform to get obvious errors while on Windows it wouldn't even compile. Am I really the only person using this tool? :P I've also found another minor problems: - when building it, "$(BOOST_ROOT)\tools\regression\build\bin" directory is created but it's not marked with "ignore" in SVN; - char_xlate functor only translates '/' character in URLs while on Windows the character used is '\' (and it also causes problems in some browsers). The solution is very simple - add "|| c = '\\'" in line 75. I'm attaching a patch file combining the previous fixes and the '\' translation. Best regards, Robert > -----Original Message----- > From: Robert Kawulak [mailto:Robert.Kawulak@gmail.com] > Sent: Saturday, July 09, 2011 11:35 PM > To: 'boost(a)lists.boost.org' > Cc: 'bdawes(a)acm.org'; 'blelbach(a)cct.lsu.edu' > Subject: Bugs in regression/library_status.cpp on Windows > > Hello, > > I've stumbled upon several bugs in > tools/regression/src/library_status.cpp when compiling on Windows with > gcc 4.5 and msvc 10.0. I'm attaching a patch file with all necessary > fixes. The bugs are: > > - using path::native() instead of path::string() - the former is > wstring on Windows, > - calling path::string() twice to obtain begin() and end() iterators - > on Windows path::string() returns a temporary, so the iterators point > to different objects, > - using whole path for each node in build_node_tree() instead of only > the directory name, > - using whole path instead of only the test name in do_table_body(), > - the link to links file is relative to test directory, not to the > results output directory, > - generation of closing "</a>" without opening "<a>". > > Best regards, > Robert

1 0

[filesystem] home_directory_path
by Jeff Flinn 24 Jul '11

24 Jul '11

In looking at implementing a portable home_directory_path function a few questions arise. Based on http://en.wikipedia.org/wiki/Home_directory, POSIX and other UNIX flavors 'appear' to be a straight forward use of the "HOME" environment variable. Does anyone have any experience where the "HOME" variable is not the proper source of the user's home directory? Windows NT and above have the "USERPROFILE" environment variable. Using this would be the easiest to use. But I've seen discussion that this may not always be properly defined, in particular if the user has reset their home directory to a non-system drive. I haven't tracked down it's availability on WinCE. Does anyone have experience with this platform? There is the windows GetUserProfileDirectory api function also available since NT4. This is in the Userenv.lib/dll, obviously adding a link dependancy. How are these sorts of system link dependencies handled? Through bjam? Or is it acceptable/better to use #pragma comment(lib,"Userenv.lib")? In looking at some client code using home_directory_path, I see that they generally are looking for the user's Desktop directory(Mac & Windows). Obviously this only makes sense on GUI platforms. The issue with merely getting this path via home_directory_path() / "Desktop" is IIRC, that at least on windows "Desktop" is localized and may not exist with that name on non-english localized systems. Windows has the SHGetFolderPath api. I need to look into Mac's native support. Any thoughts on the general usefulness of a portable desktop_directory_path? Thanks, Jeff

16 60

[Geometry] Problem with assign
by Hartmut Kaiser 24 Jul '11

24 Jul '11

The following fails to compile: #include <boost/geometry.hpp> #include <boost/geometry/geometries/point_xy.hpp> #include <boost/geometry/geometries/polygon.hpp> int main() { typedef boost::geometry::model::d2::point_xy<int> int_point_type; typedef boost::geometry::model::polygon<int_point_type> int_polygon_type; typedef boost::geometry::model::d2::point_xy<double> double_point_type; typedef boost::geometry::model::polygon<double_point_type> double_polygon_type; int_polygon_type ip; double_polygon_type dp; boost::geometry::assign(dp, ip); return 0; } Shouldn't it actually compile? Regards Hartmut --------------- http://boost-spirit.com

2 5

[graph] gcc visibility support patch
by Jürgen Hunold 23 Jul '11

23 Jul '11

Hi, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.Graph For more information, please see http://gcc.gnu.org/wiki/Visibility Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

[General] Treat narrow strings as UTF-8 (compilation flag)
by Yakov Galka 23 Jul '11

23 Jul '11

Hello All, About half a year ago there was a long discussion titled "Always treat std::strings as UTF-8". The only objection to the proposal was that making an instant switch by assuming UTF-8 by default will give surprising results to those who're unaware of the convention (or prefer using legacy encodings instead of UTF-8). This applies almost only to Windows developers. However, there are already many projects and organizations that switched to UTF-8 even for Windows programming. The company I work in is one of them. Nowadays: ========== All the libraries that accept narrow strings assume the system encoding by default. * filesystem::path — Can be configured through static imbue() function. * system_error_category (windows error description), interprocess (object names)... more? — Don't support Unicode at all. They use the narrow API on Windows. * program_options — Assumes UTF-8 for internal data (Good!), but uses system encoding for paths (parse_config_file) and for environment variables (Bad...) . Note that, e.g. path::imbue(), is a painful solution for two reasons: Any global state initialization is problematic in dynamically-linked, multi-threaded systems (like the one I'm maintaining now). In such cases a compile time configuration is more attractive. I really don't want to have such a function in each boost library (can be solved by having a global boost::imbue though). Proposal: ======== Add a compile-time configuration flag that causes boost to treat all narrow strings as UTF-8. The flag will be off by default. For example, in filesystem it's a matter of setting `codepage` to CP_UTF8 in just two places. Rationale: ========== Those who are ready to move to the UTF-8 future, they can do it by simply setting a compilation flag.. Those who don't care about Unicode correctness are not affected by the addition. There won't be any complaints to boost, like: "Hey! I use boost with these libraries and it doesn't work. Your encoding is wrong!". -- Yakov Galka

4 5

[Config] Cray compiler
by Marshall Galbraith 23 Jul '11

23 Jul '11

Hello, I am using a few boost libraries for a research code that I am developing. I currently have access to a Cray XE6 machine (http://www.cray.com/Products/XE/Specifications.aspx) along with the Cray Compiler Environment. I would like to compile my code with the Cray compiler so I can use their Cray PAT utilities for performance testing. I was able to generate a user.hpp file for the Cray compiler, but it is automatically generated and I am not verse enough with the compilation of boost to ensure that it is correct. If there is any interest in developing a Cray configuration for compiling boost, I am more than interested in helping. I can also get in touch with the Cray compiler developers for assistance with any compiler issues. Looking through the history of this mail list there was an initiative to do this back in 2003, but it did not seem to come to fruition. Thank you for all your help, Marshall Galbraith

2 1

[TTI] Why add to boost namespace?
by Noah Roberts 23 Jul '11

23 Jul '11

Why do the macros add templates to the boost::tti namespace rather than the current one? One thing I get from the way MPL create the has_xxx metafunctions is that I can do this: template < typename T > struct obeys_xxx_concept { BOOST_MPL_HAS_XXX_TRAIT_DEF(some_trait) ... etc... enum { value = etc_checks<T>(0).... && has_some_trait<T>::value }; typedef boost::mpl::bool_<value> type; }; That wouldn't work with the TTI library it appears. What does putting the templates in the boost::tti namespace do for me to make up for this loss?

3 2

Can't check out from sandbox
by Noah Roberts 22 Jul '11

22 Jul '11

I want to do some review or at least experimenting with TTI but I can't get it. Every time I try I get this message: Checkout from http://svn.boost.org/svn/boost/sandbox/tti, revision HEAD, Fully recursive, Externals included REPORT of '/svn/boost/!svn/vcc/default': Could not parse chunk size (http://svn.boost.org) There a workaround?

2 2

Boost 1.44.0 - Problem with optional matching
by programmer1 22 Jul '11

22 Jul '11

I'm attempting to match a floating point literal which can contain several optional tokens. Even though the rule succeeds, it doesn't return all the symbols which make up the token. Example Consider the following. Even though the parser succeeds, it returns only "Km" in the match string. Why is that? I expect "-666.0e-45km". std::string phrase = "-666.0e-45km"; std::string val; std::cout << "res: " << parse_number(phrase.begin(), phrase.end(), val) << std::endl; /* prints "1" */ std::cout << val << std::endl; /* prints "km" */ grammar Here is the grammar which I'm trying to express in Spirit. Notice how it is slightly different from the built-in rule "double_" <number> := <decimal> | "INF" | "-INF" | "NaN" <decimal> := ["-"] <digits> ["." <digits>] [<exp>] [<unit>] <exp> := ("e"|"E") ["+"|"-"] <digits> <digits> := <digit> (<digit> | "_")* <digit> := ('0' - '9') <unit> := <unitChar>* <unitChar> := <alpha> | "%" | "_" | "/" | "$" | any char > 128 // see sys::Unit Code namespace qi = boost::spirit::qi; namespace ascii = boost::spirit::ascii; namespace phoenix = boost::phoenix; template <typename Iterator> struct number_grammar : qi::grammar<Iterator, std::string(), ascii::space_type> { number_grammar() : number_grammar::base_type(number, "number") { using qi::lit; using ascii::char_; using qi::digit; using ascii::string; using qi::alpha; using qi::on_error; using qi::fail; using phoenix::construct; using phoenix::val; unitChar = alpha | char_('%') | char_('_') | char_('/') | char_('$') ; // | any char > 128 // see sys::Unit unit = *unitChar ; digits = digit > *( digit | lit('_') ) ; exp = ( char_('e') | char_('E') ) > -( char_('+') | char_('-') ) > digits ; decimal = -char_('-') > digits > -( char_('.') > digits ) > -exp > -unit ; number = string("INF") | string("-INF") | string("NaN") | decimal ; on_error<fail> ( number, std::cout << val("Error! Expecting ") << qi::_4 // what failed? << val(" here: \"") << construct<std::string>(qi::_3, qi::_2) // iterators to error-pos, end << val("\"") << std::endl ); } qi::rule< Iterator, std::string(), ascii::space_type > number; qi::rule< Iterator, std::string() > decimal; qi::rule< Iterator, std::string() > exp; qi::rule< Iterator, std::string() > digits; qi::rule< Iterator, std::string() > unit; qi::rule< Iterator, char() > unitChar; }; template <typename Iterator> bool parse_number(Iterator first, Iterator last, const std::string& val) { using qi::phrase_parse; using ascii::space; number_grammar<Iterator> grammar; bool r = phrase_parse ( first, /*< start iterator >*/ last, /*< end iterator >*/ grammar, /*< the parser >*/ space, /*< the skip-parser >*/ val ); std::cout << val << std::endl; if (first != last) // fail if we did not get a full match return false; return r; } -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-44-0-Problem-with-optional-match… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

[TR1] clang patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi John, the current clang (version 3.0 (trunk 135764)) is still emulating gcc-4.2.1 which leads to a lot of the tr1-tests failing with: boost/boost/tr1/detail/config_all.hpp:158:12: fatal error: '../4.2.1/utility' file not found # include BOOST_TR1_STD_HEADER(utility) ^ boost/boost/tr1/detail/config_all.hpp:100:44: note: expanded from: # define BOOST_TR1_STD_HEADER(name) <../__GNUC__.__GNUC_MINOR__.__GNUC_PATCHLEVEL__/name> ^ 1 error generated. if your installed gcc is not 4.2.1. The attached patch fixes this by introducing a special case for clang. This fixes all but eight tr1-tests for clang trunk. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 3

[iostreams] gcc visibility support patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.IOStreams For more information, please see http://gcc.gnu.org/wiki/Visibility Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0

[Thread] Assertion on mutex when using multiple threads and mutexes
by Tim van den Kerkhof 22 Jul '11

22 Jul '11

Hi all, As a part of a project I'm writing a logger function. This logger function sends an e-mail when the program wants to log something. Since it has happened that the SMTP server was non responsive, I've decided to do the sending of the mails in a separate thread. This thread reads messages from an std::deque which is filled by the logging function. The thread is setup as follows: while (!boost::this_thread::interruption_requested()) { EmailItem emailItem; { boost::unique_lock<boost::mutex> lock(mMutex); while (mEmailBuffer.empty()) mCond.wait(lock); bufferOverflow = mBufferOverflow; mBufferOverflow = false; nrOfItems = mEmailBuffer.size(); if (nrOfItems > 0) { emailItem = mEmailBuffer.front(); mEmailBuffer.pop_front(); } } if (nrOfItems > 0) { bool sent = false; while(!sent) { try { ..... Do something with the message ..... { boost::this_thread::disable_interruption di; boost::lock_guard<boost::mutex> lock(mLoggerMutex); mLogFile << emailItem.mMessage << std::endl; } sent = true; } catch (const std::exception &e) { // Unable to send mail, an exception occurred. Retry sending it after some time sent = false; boost::this_thread::sleep(boost::posix_time::seconds(LOG_WAITBEFORE_RETRY)); } } } } The function log() adds a new message to the deque (mEmailBuffer) as follows: { boost::lock_guard<boost::mutex> lock(mMutex); mEmailBuffer.push_back(e); mCond.notify_one(); } When the main program exits, the destructor of the logger object is called. This is where it goes wrong, the application crashes with an error: /usr/include/boost/thread/pthread/mutex.hpp:45: boost::mutex::~mutex(): Assertion `!pthread_mutex_destroy(&m)' failed. The destructor merely calls an interrupt on the thread and then joins it: mQueueThread.interrupt(); mQueueThread.join(); In the main program, I use multiple different classes which make use of boost threading and mutex as well, could this cause this behaviour? Not calling the destructor of the logger object results in no errors, as does using the logger object and not doing anything else. My guess is I am doing something very wrong, or there is a bug in the threading library when using multiple threads divided over several classes. Does anyone have a idea what the reason for this error might be? Regards, Tim van den Kerkhof

1 0

[date_time] gcc visibility support patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for Boost.DateTime For more information, please see http://gcc.gnu.org/wiki/Visibility Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

[C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string
by Beman Dawes 22 Jul '11

22 Jul '11

I'm starting to fold in Boost.Filesystem support for the new C++0x character types. Support is emulated for compilers and standard libraries not currently supporting the 0x features. The emulation is working fine, with tests passing on Windows for GCC 4.5 and 4.6, and VC++ 8, 9, and 10. Haven't tested on non-Windows systems yet. This is the same emulation approach Microsoft ships in VC++ 10. It seems to me that all Boost libraries that want to emulate these 0X features should use the a unified approach. Otherwise we could get into a situation where libraries A and B worked fine in isolation, but had symbol or ODR clashes when used together. The header I'm using is attached. I propose to place this in <boost/string_0x.hpp> rather than, say, <boost/filesystem/detail/string_0x.hpp>, and providing a simple doc page. Does this make sense? --Beman

6 15

[program_options] gcc visibility support patch
by Jürgen Hunold 22 Jul '11

22 Jul '11

Hi Volodya, I've found some patches for https://svn.boost.org/trac/boost/ticket/2114 This one enables visibility support for program_options. Tested locally for too long. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 1

[Review] Lockfree review starts today, July 18th
by Hartmut Kaiser 22 Jul '11

22 Jul '11

Hi all, The review of Tim Blechmann's Boost.Lockfree library starts today, July 18th 2011, and will end on July 28th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! ----------------------------------------------------- About the library: Boost.Lockfree provides implementations of lock-free data structures. Lock-free data structures can be accessed by multiple threads without the necessity of blocking synchronization primitives such as guards. Lock-free data structures can be used in real-time systems, where blocking algorithms may lead to high worst-case execution times, to avoid priority inversion, or to increase the scalability for multi-processor machines. The following data structures are provided: - boost::lockfree::fifo, a lock-free fifo queue - boost::lockfree::stack, a lock-free stack - boost::lockfree::atomic_int, an atomic integer class The library is accessible from here: http://tim.klingt.org/boost_lockfree.tag.gz. Boost.Lockfree depends on C++0x atomics. They are not well supported with current compilers yet. For this reason Boost.Lockfree depends on the *unreviewed* Boost.Atomic library, that emulates C++0x atomics for C++98. This review is about Boost.Lockfree and not about Boost.Atomic, although it is included in the tarball and the git repository. If Boost.Lockfree will be accepted, it won't be merged into trunk before Boost.Atomic is accepted. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

9 17

[fusion] html docs woes
by Eric Niebler 21 Jul '11

21 Jul '11

I'm merging [72977] to release (<https://svn.boost.org/trac/boost/changeset/72977>) and am given a headache by the fact that Fusion has its HTML docs checked in. The docs are automatically generated from the qbk files so committing them to svn is strictly unnecessary, AFAICT. Why is this a problem? - Any change to any qbk file results in a huge number of diffs to the HTML docs (due to changed ids), resulting in a huge commit, long upload times, long download times, long merge times. - It makes viewing a changeset all but impossible because the meaningful changes are lost in the noise of meaningless diffs to automatically generated files. - It leads to unnecessary merge conflicts when merging commits from trunk to release. I'm going to have to regenerate the docs on the release branch and upload them all ... for no benefit! Can Fusion be changed to build its html docs as a normal part of Boost's doc build procedure like other Boost libraries? Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

8 27

[lexical-cast] Help with documentation required
by Antony Polukhin 21 Jul '11

21 Jul '11

I've added Qickbook documentation for lexical_cast to libs/conversion/doc/lexical_cast.qbk and a Jamfile.v2 file to build it. Meanwhile, there is an old HTML documentation for lexical_cast in libs/conversion/lexical_cast.htm and file libs/conversion/index.html references it. The question is: How shall I update the lexical_cast.htm/index.html, doc/html/ folder? Best regards, Antony Polukhin

3 8

Re: [boost] [C++0x] Emulate C++0x char16_t, char32_t, std::u16string, and std::u32string
by Artyom Beilis 21 Jul '11

21 Jul '11

--- On Thu, 7/21/11, Beman Dawes <bdawes(a)acm.org> wrote: > From: Beman Dawes <bdawes(a)acm.org> > > You can't create working > > > > std::basic_ostringstream<char16_t> stream; > > > > Because stream << 1245 would not work due to > lack of std::locale facets. > > > > You can't create requires facets as for example they > are specialized > > in many standard libraries. > > Emulation via simple uint16_t and uint32_t typedefs doesn't > work for > all use cases. So only use it when it does work. > And Boost.Filesystem.v3 is one of these specific use cases. Boost.Filesystem uses codecvt facet? You can't create them, at least with gcc/linux because existing codecvt facets are specialized for each type of character - and you have to derive from it. For example this code would not link with Linux/gcc-4.6 #include <locale> class real_facet : public std::codecvt<char16_t,char,std::mbstate_t> { }; class simulated_facet : public std::codecvt<unsigned short,char,std::mbstate_t> { }; int main() { std::locale l1(std::locale::classic(),new real_facet()); std::locale l2(std::locale::classic(),new simulated_facet()); } With errors like: undefined reference to `std::codecvt<char16_t, char, __mbstate_t>::do_in(__mbstate_t&, char const*, char const*, char const*&, char16_t*, char16_t*, char16_t*&) const' --- : undefined reference to `std::codecvt<unsigned short, char, __mbstate_t>::do_max_length() const' > > Even existing Microsoft's VC2010 does not work if you > compile application > > with /MD or /MDd > > I'll retest just to be sure, but I'm fairly sure that some > of my tests > have used those switches. > MSVC2010 does not provide specialization for std::locale::id for these new facets and they are undefined in the dll. If you want I'll provide a fault case for MSVC10 as well. And all these with compilers that **declare** support of charXX_t. So you may try to put an effort in implementing some emulation but at these points char16_t/char32_t are broken with modern compilers. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

1 0

[interprocess][1.47] Mismatched PP directives?
by John Maddock 20 Jul '11

20 Jul '11

While building the PDF docs for 1.47 I noticed a bunch of Doxygen warnings about mismatched PP directives in the Boost.Interprocess source - warning messages below - should I/we be concerned, or this just a Doxygenism? Thanks, John. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:55: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:68: warning: Found an #else without a preceding #if. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:70: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:96: warning: Found an #else without a preceding #if. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:98: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:109: warning: Found an #else without a preceding #if. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:111: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/permissions.hpp:131: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/containers/containers_fwd.hpp:40: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/smart_ptr/intrusive_ptr.hpp:294: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/smart_ptr/scoped_ptr.hpp:168: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/smart_ptr/shared_ptr.hpp:388: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_barrier.hpp:115: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_mutex.hpp:148: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_recursive_mutex.hpp:158: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/interprocess_semaphore.hpp:119: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/named_mutex.hpp:235: warning: More #endif's than #if's found. M:/data/boost/branches/release/boost/interprocess/sync/named_semaphore.hpp:242: warning: More #endif's than #if's found.

2 1

RFC: type erasure
by Steven Watanabe 20 Jul '11

20 Jul '11

AMDG Over the last few months I've re-done my type erasure library from scratch, fixing a lot of the bad design decisions I made originally. Here's a basic sample of what you can do with it: simulate boost::any: type_erasure::any< mpl::vector<copy_constructible<>, typeid_<> > > x(10); simulate boost::function<void(int)>: type_erasure::any< mpl::vector<copy_constructible<>, typeid_<>, callable<void(int)> > > f(foo); The code is available from the Vault: http://tinyurl.com/3z9jcwp The library is nearly complete. I've included pre-built html documentation in the zip. Questions, comments, and criticism are welcome. In Christ, Steven Watanabe

7 22

Re: [boost] [Boost-users] [Review] Lockfree review starts today, July 18th
by Klaim - Joël Lamotte 20 Jul '11

20 Jul '11

On Wed, Jul 20, 2011 at 18:51, Tim Blechmann <tim(a)klingt.org> wrote: > >> If Boost.Lockfree will be accepted, it won't be merged into trunk before > >> Boost.Atomic is accepted. > > > > That seems unnecessary. Can't Boost.Lockfree simply include (a version > > of) Boost.Atomic as an implementation detail for now? > > this would somehow mean to fork boost.atomic, move everying to a `namespace > detail'. might introduce some maintenance overhead to keep it in sync with > the > original library. > > Excuse me if it's common knowledge around here, but I've seen several libraries relying on boost.atomic that have been reviewed, so may I ask : why haven't Boost.Atomic been reviewed yet? It looks like it's already finished and reliable... Joël Lamotte

2 1

[fusion] make_fused arity > 10
by Mario Mulansky 20 Jul '11

20 Jul '11

Hi We are using Boost.Fusion quite heavily in our library [odeint] and I just came across some problem that took me several hours to solve so I decided to let you know about the issue. We use boost::fusion::make_fused to make functor applicable to fusion sequences and as we occasionally deal with long vectors we increased the limits as described here: http://www.boost.org/doc/libs/1_47_0/libs/fusion/doc/html/fusion/functional… At first we used 10 as maximum (also changing FUSION_MAX_VECTOR_SIZE and the ..INVOKE.. constants, of course). However, today I extended the library and had to increase these values to 16. Unfortunately, that did not work - compiling still failed at functors with arity 11. So I digged into Boost.Fusion and after quite some time I realized that it relies on boost::result_of which has an upper limit of 10. So additionally changing BOOST_RESULT_OF_NUM_ARGS to 16 made everything work, eventually. I think the point here is that defining BOOST_FUSION_UNFUSED_MAX_ARITY > 10 without also defining BOOST_RESULT_OF_NUM_ARGS accordingly will break the code in a rather confusing way - I think at least adding a note in the docs could be very helpful here. Regards, Mario

3 2

FW: On #5644 (tellg returns different results for gnu libstd++ and others standard libraries for codecvt_null)
by Michael Kochetkov 20 Jul '11

20 Jul '11

I am terribly sorry for reposting this message but the situation with the https://svn.boost.org/trac/boost/ticket/5644 issue problem becomes urgent for me as the time is passing away. Please could anyone just comment on the issue if it is valid defect or not? Thank you in advance, -- Michael Kochetkov -----Original Message----- From: Michael Kochetkov [mailto:Michael.Kv@gmail.com] Sent: Wednesday, July 06, 2011 1:17 AM To: 'boost(a)lists.boost.org' Subject: On #5644 (tellg returns different results for gnu libstd++ and others standard libraries for codecvt_null) Hello, please can anyone comment on https://svn.boost.org/trac/boost/ticket/5644 issue? I am really stuck with the problem and need just a resolution if it is a defect or not. And if it is then I would appreciate an approximate estimate when it is to be fixed. Thank you in advance, -- Michael Kochetkov

2 1

Boost Asio io_service as global?
by Philip Bennefall 20 Jul '11

20 Jul '11

Hi all, I am just beginning to learn how to use Boost Asio in a multithreaded environment, and one thing struck me when looking at the various examples. I have not been able to find an answer to this in the documentation, but in case it is explained somewhere that I've missed I apologize in advance. Taking the asynchronous echo server as my base I am writing a multithreaded server that handles connections in a thread pool. My question is simply, why is the io_service object always passed around between class instances as a reference in the constructor? Why can one not store it as a global variable? I cannot see how this makes a difference, and a global seems to make things a lot easier. Is there a particular reason why I should not do this? Thanks in advance for any help. Kind regards, Philip Bennefall

3 3