- Boost - lists.preview.boost.org

RFC: interest in Unicode codecs?
by Graham 12 Feb '09

12 Feb '09

Dear Cory, Your UTF standard conversion class looks very interesting. It does however, not give access to the unicode data for grapheme or glyph work. I posted a full unicode character support library at http://www.boostpro.com/vault/ unicode_lib.zip but Rogier and I ran out of time before completing the string class to go with it. If you feel up to it and want to develop a full Unicode support library in addition to your codec, feel free ! Yours, Graham Barnett >Is there interest in having a Unicode codec library submitted to Boost? > >Here is what I have (only tested with GCC 4.3 on Debian, and VC++ 2008): >http://svn.int64.org/viewvc/int64/snips/unicode.hpp > >Right now it is pretty simple to use: > >transcode<utf8, utf16le>(forwarditerator, forwarditeratorend, >outputiterator, traits [, maximum]); >transcode<wchar_encoding, utf32be>(inputrange, outputrange, traits [,maximum]); > >There is also a codecvt facet which supports any-to-any. > >Supports UTF-8, UTF-16, and UTF-32, in little or big endian. Has a >special wchar_encoding that maps to UTF-16 or UTF-32 depending on your >platform. A traits class controls error handling. > >-- >Cory Nelson

1 0

Review Request: Introduction of boost::string namespace and string-conversion functions
by Vladimir.Batov＠wrsa.com.au 12 Feb '09

12 Feb '09

Based on the previous string-conversion-related discussion that revolved around lexical_cast (started with http://lists.boost.org/Archives/boost/2009/01/147013.php) and Dave's suggestion (http://lists.boost.org/Archives/boost/2009/02/147995.php) I would like to propose to create a new boost::string namespace where I'd expect all string-related functionality might be logically housed. Dave already mentioned that "Jeff Garland had a really nice set of proposed extensions to std::string that could live in the same space". My immediate interest/proposal in that namespace would be the string-conversion functionality. The basics of that functionality are currently handled by lexical_cast but need extended and unambiguously tagged as *string*-related conversions. During discussion I've got a strong impression that the majority of people, the lexical_cast author (Kevlin) and the maintainer (Alex) strongly favor leaving lexical_cast as-is and having a fresh start capitalizing on the past experiences. Therefore I'd like to propose the string-conversion functionality that'd be housed inside that mentioned boost::string namespace. This proposal of mine probably is not as conventional as I have no implementation code to show. That is because before committing to it any further (or dragging someone else into it) I would initially like to see if we can agree on 1) creating boost::string (or some other as descriptive name) namespace; 2) the interface for that proposed string-conversion functionality. After that I expect the implementation to be largely a technical issue. >From the user point the interface I'd like to propose might look like the following: int i; std::string s; 1) int i_from_s = boost::string::to<int>(s); // throws 2) std::string s_from_i = boost::string::from<int>(i); 3) bool s_is_i = boost::string::is<int>(i); The above convert a string to an integer (#1), an integer to a string (#2) and check if conversion is possible (#3). #1 and #2 behave like lexical_cast currently does (throw on failure). #3 is a non-throwing check if #1 will succeed (to avoid handling an exception thrown by #1). For example, int i_from_s = boost::string::is<int>(s) ? boost::string::to<int>(s) // safe to request conversion : some-failure-value; I like to/from names as they allow me to read the code as it was merely English -- "string to int", "string from int". I expect string::to() and string:;from() to return a helper object as Dave suggested namespace string { template <class T> struct value { operator T() const; // throws iff parse unsuccessful bool good() const; // true iff parse will succeed ... }; } That'll allow as to make the interface consistent and extendable/chainable: 4) int i_from_s = boost::string::to<int>(s)(-1); The above is a non-throwing variation of #1 with the default value provided for failed conversion. 5) int i_from_s = boost::string::to<int>(s)(std::hex); 6) std::string s_from_i = boost::string::from<int>(i)(std::hex); The above is variations of #1 and #2 with the std::hex manipulator/formatter applied. That "chained" approach would allow to keep the interface consistency without sacrificing the flexibility. For example, 7) int i_from_s = boost::string::to<int>(s)(-1)(std::hex)(yet-another-manipulator); or add some other features when the need arises. Off the cuff the actual conversion might look something along the following lines: template<class T, class Char> boost::string::value::operator T() { std::basic_istringstream<Char> stream(string_); if (manipulators) stream >> manipulator_ >> ... >> value_; else stream >> value_; if (stream.fail()) if (no_default) throw something; else return default_value_; return value_; } Thanks, Vladimir.

12 19

[future] @Tom -> review result?
by k-oli＠gmx.de 12 Feb '09

12 Feb '09

Hello, as Vicente lready ask - what is the result of the future review?! @Tom could you confirm that you are still working on the review summary? Oliver

1 0

Profiling template instantiations
by Steven Watanabe 12 Feb '09

12 Feb '09

AMDG Over the last few days, I've been working on a tool that counts the number of class template instantiations in a translation unit. To use it from a jamfile import profile_templates : : directory of the tool ; template-profile result : some_file.cpp : <include>some_directories ; If everything works, this will create a file with the extension .tp which will contain the number of times each class template was instantiated, with the most common templates at the top. I've put a zip of a rough version in the vault. http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Caveats: I've only tested with Visual C++ 9.0 and gcc 3.4.4 on cygwin so far. Other compilers won't work, yet. Other versions of these compilers may or may not work. It may be necessary to add link=static to the bjam command line. In Christ, Steven Watanabe

6 20

[trac] Type of ticket: "Bugs", "Patches", or "Feature Requests"?
by Niels Dekker - mail address until 2010-10-10 12 Feb '09

12 Feb '09

https://svn.boost.org/trac/boost/newticket has a Type dropdown-list that has "Bugs" as default. When my report has a patch file attached, should I set the Type to "Patches" instead? If fact, the report I have in mind is mainly a performance issue. I would like boost::array::swap to internally call boost::swap, instead of std::swap_ranges, mainly because some C++03 implementations of std::swap_ranges exchange the elements by doing element-wise copy operations, even when there is a custom swap for the element type. The new boost::swap utility takes care of calling the appropriate custom swap, whenever found by argument-dependent lookup (ADL). My report will have a patch. So is the type of such a report considered a "Feature Request", a "Bug", or a "Patch"? Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

2 2

Re: [boost] [log] Review-ready version in the Vault
by Vladimir.Batov＠wrsa.com.au 12 Feb '09

12 Feb '09

Andrey, Thank you for your contribution. I do not think I'll be participating in trial-runs or review as such. However, I read through the documentation and looked at the interface and I thought I'll give you my first (well, second, I looked at your lib. before) impression. I realize that everyone probably has something to say about logging and such a debate can get hot. So, I want to say beforehand that my reply is merely my impression (not a review or criticism of any kind). Firstly, it certainly seems very rich in features and configurable. That is certainly a huge plus for such a library as logging. However, I was truly overwhelmed by the documentation, the interface and the deployment examples. I seemed to be reading about familiar concepts -- severity levels, sinks, filters, formatters, streams/channels. However, after all that I did not feel an inch closer to actually deploying your library. I consider myself a moderately intelligent person but the seeming complexity felt quite intimidating. Somehow other implementations I read about (J.Torjo's, log4cpp, log4j, a bunch of loggers at SourceForge) went down much easier. Roughly, as a user I'd expect something as straightforward as boost::log log(name); // Create a log boost::log::sink sink = boost::log::sink(file)(stdout)(event_log); // Set up sinks boost::log::formatter fmt = boost::log::formatter(date)(thread_id)(name); // Set up the formatter boost::log channel = log.channel(channel-name); // Create a channel log(sink)(fmt); // Associate sinks and formatting if (log) log << "Hello, main world"; if (channel) channel << "Hello, channel world"; Maybe that's what your interface does. I just did not get that warm and fuzzy easiness/familiarity feeling after reading the docs and looking at the deployment examples. I feel there is a considerable room for improvement here. In particular I was left puzzled how you actually create a log instance (I think in the docs it is boost::src::logger). I'd expect to be able to create a log instance with a name and to be able to retrieve that same instance by the name anywhere in the program. That is, boost::log log1(name); boost::log log2(name); would be referring to the same log instance (pointer semantics). That'd be very liberating. Best, Vladimir.

8 18

Re: [boost] Profiling template instantiations (Steven Watanabe)
by PORKOLAB Zoltan 12 Feb '09

12 Feb '09

Hi Steven, We have created a framework for debugging/profiling template metaprograms in 2006. It might give you a few tips. It works based on the same idea you have. We instrument all template codes, both at the begining and at the end of each template we insert a special piece of code emitting warning messages of a well-defined form. Before instrumentation we create an XML file to remember the template positions in the source file. When we parse the warning, using this information we can reconstruct the instantiation stack knowing the original line numbers, identifiers, etc.. At the end we produce another XML for possible front-ends. The framework uses boost::spirit and boost::wave. We have also implemented and tested a visual studio plug-in. An overview of the whole idea: http://gsd.web.elte.hu/templight/ There is also a GPCE article about the framework, you can find it here: http://portal.acm.org/citation.cfm?id=1173746&coll=portal&dl=ACM&CFID=47731… or here: http://gsd.web.elte.hu/contents/articles/gpce06.pdf You can download both the VS binaries and the source from: http://people.inf.elte.hu/pocok Please feel free to use the code or any of the ideas. For technical question you can find Jozsef: jmihalicza(a)gmail.com or me. Regards, Zoltan

4 3

[TR1] Problems with TR1 include paths with Mingw?
by Richard Webb 12 Feb '09

12 Feb '09

Hi, I've got some code that i've been building with MSVC that uses the TR1 lib by adding the boost/tr1/tr1 dir to the include path, which i'm now trying to build using Mingw/msys. It seems to build ok using the code on the release branch, but using the current trunk i get: d:/Boost/BoostSVN/boost/tr1/detail/config_all.hpp:162:41: error: ../4.3.2/utility: No such file or directory Am i doing something silly, or have the recent changes to the include logic broken something for Mingw? For reference, i'm using the GCC 4.3.2 build from http://www.tdragon.net/recentgcc/ Thanks, Richard Webb -- View this message in context: http://www.nabble.com/-TR1--Problems-with-TR1-include-paths-with-Mingw--tp2… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[any] implement reset for direct constructing (adapt to noncopyable)
by nowake＠fiercewinds.net 12 Feb '09

12 Feb '09

Hi All. I modified boost::any to adapt noncopyable object. The boost::any can use noncopyable object like this: _____________________________________________________________ struct B : boost::noncopyable { B() : v1(), v2() {}; B(unsigned int value1, unsigned int value2) : v1(value1) ,v2(value2) {}; unsigned int v1, v2; }; BOOST_AUTO_TEST_CASE(test02) { any test; //test = B(); // compile error //test.reset<B>(10, 20); // compile error test.reset<B, false>(10, 20); //any test2(test); // throw //any test2; //test2 = test; // throw BOOST_CHECK_EQUAL(any_cast<B&>(test).v1, 10); BOOST_CHECK_EQUAL(any_cast<B&>(test).v2, 20); } _____________________________________________________________________ If you are interested in this, please see #2748 for detail. https://svn.boost.org/trac/boost/ticket/2748 Thanks, Nowake

1 0

Boost 1.38.0 released
by Beman Dawes 12 Feb '09

12 Feb '09

Boost 1.38.0 has been released and is available from SourceForge. See http://sourceforge.net/projects/boost/ This release includes three new libraries: Flyweight, ScopeExit, and Swap. Updated Libraries: Accumulators, Any, Asio, Config, Date_Time, Exception, Filesystem, Graph, Hash, Interprocess, Intrusive, Lexical Cast, Math, Multi-index Containers, Proto, Regex, Thread, TR1, Type Traits, Unordered, and Xpressive. Other Changes: Experimental CMake build system. You can read the full release announcement here: http://www.boost.org/users/news/version_1_38_0 The release managers were Beman Dawes, Daniel James, Eric Niebler, and Rene Rivera. --Beman Dawes

7 9

Is it a bug in old version of boost?
by Bill David 12 Feb '09

12 Feb '09

I have the following code in my application. But I find it causes a serious memory leak with a product we are using. Our application is a plug-in to this product. But we are not sure what's the boost version included by this product. The following is the code (On Windows, the product should be written with Visual Studio 2003/2005): /** * @brief Convert modify time string to time_t for easy internal handling * @param str Modify time string returned by HTTP server, e.g. "Fri, 18 Jul 2008 11:53:14 GMT" * @return Corresponding time_t result */ time_t parseDate(const string& str) { ptime p; stringstream ss(str.c_str()); time_input_facet* timefacet = new time_input_facet("%a, %d %b %Y %H:%M:%S %z"); // will be automatically deleted by related locale object ss.imbue(locale(locale::classic(), timefacet)); ss >> p; tm t = to_tm(p); return mktime(&t); } And we find the problem is caused by time_input_facet* timefacet = new time_input_facet("%a, %d %b %Y %H:%M:%S %z"); ss.imbue(locale(locale::classic(), timefacet)); it seems related memory has not been released by locale or some memory is leaked by time_input_facet. We have tested above code separately with boost 1.35.0, 1.37.0, it's OK. So can anybody tell me if it's any problem in above code? Or is it a bug in old version of boost date_time or MS Visual Studio 2003/2005? Or how can I work around it?

1 0

[parameter] function types as named template parameters?
by Frank Mori Hess 11 Feb '09

11 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does Boost.Parameter support function types as named template type parameters? I'm trying to write a metafunction which lets you use Boost.Parameter to specify the template types for a boost::signals2::signal using named type parameters, as was suggested during the review. But it doesn't seem to work for the "Signature" function type. I get errors like: /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:264: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:270: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:352: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:359: error: function returning a function /home/fhess/svn/boost/boost/parameter/aux_/arg_list.hpp:365: error: function returning a function I can get it to work if I don't use Boost.Parameter for the "Signature" type, but only use it for the other 6 types. Also, I noticed BOOST_PARAMETER_MAX_ARITY defaults to 5, but signals2::signal has 7 parameters. I can't reliably redefine BOOST_PARAMETER_MAX_ARITY in my library header, since it must be defined before boost/parameter/config.hpp gets included. You can't redefine the arity and then re-include the parameter library headers like you can with Boost.Function. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJeO/v5vihyNWuA4URAtVIAJ9iHlncV/+QON81+qYYWzmzex3yDACg48Kc 2il7aidDE0Xj7tVUMmZaxLw= =eqjh -----END PGP SIGNATURE-----

2 6

Gauging interest in a thread-safe containers library
by Eric Greveson 11 Feb '09

11 Feb '09

Hi all, I've recently been doing some work that required thread-safe containers (queue, channel) and I found that in addition to these, a locking_ptr with similar semantics to boost::shared_ptr (except being thread-safe too) allowed me to perform all my threaded operations without needing to worry about synchronisation outside the container/locking_ptr code, and without a major impact on performance compared to coding locks in a slightly less generic (== paranoid) way. These have been re-used with some success by others, and a couple of containers (specifically the queue and channel) seem to be used commonly enough to be worthy of an inclusion in Boost.Thread or similar. This discussion has been had in the past, on this thread: http://lists.boost.org/Archives/boost/2004/09/71454.php Someone else mentioned it later, but there doesn't seem to be much else said here: http://lists.boost.org/Archives/boost/2005/11/96991.php I was wondering if there is more interest now, a few years on. Some of the pros I can think of are: * Writing correct thread-safe code can be tricky (I messed up the first time I wrote my queue). * Use of multithreading is perhaps more prevalent now, with many-core CPUs, than it was 4 years ago * Queues / channels in particular are very useful for building threaded pipelines etc, and more people might be tempted to use such programming techniques if a safe option was available "out-of-the-box" * A thread-safe shared pointer provides a lazy but effective way of synchronising data in many scenarios (my implementation supports the usual boost::shared_ptr stuff except for get(), -> and *: dereferencing is provided by calling an acquire() function which returns a scoped_lock object on which you can call * and ->.The destructor of the scoped_lock releases the lock.) * The thread-safe shared pointer means you could use a pop-copy queue without significant overhead (depending on use) * The code length for these class templates on a single platform is actually quite short (a hundred lines of code or so) Some cons: * Need to support all the platforms Boost works on * Not much interest for these containers last time * More code to maintain * Questions about how re-usable a synchronised queue is due to performance worries (I believe this not to be a major problem for a major class of problems - e.g. pipelining fairly long operations, such as in image and video processing) I'm sure I've missed some things, but I'd be interesting in hearing whether there's a positive or negative reaction to this. I'd be happy to contribute code for this - it wouldn't be the fastest possible code, but I believe that robust, lightweight, maintainable code is better than nothing in this case, even if it's not the very best lock-free implementation. Thanks for reading! Eric

6 10

[signals2] post-review rfc before moving to trunk
by Frank Mori Hess 11 Feb '09

11 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I've made some changes to Boost.Signals2 in response to some of the suggestions made during the review. Unless there is are show-stopper objections, I'd like to move Signals2 from the sandbox to the trunk in a week or two. For context, Stjepan Rajko's review summary is here: http://lists.boost.org/boost-announce/2008/11/0211.php The current Signals2 documentation is online here: http://www.comedi.org/projects/signals2/libs/signals2/doc/html/ Here is a summary of most of the changes made since the review: *Added a signals_vs_signals2_benchmark.cpp to the signals2/test subdirectory, and made some optimizations to signal invocation speed. *Made sure all macros were prefixed with BOOST_SIGNALS2_. *Added tests for boost::signals2::mutex and dummy_mutex. *Brought back boost::signals2::trackable class to ease porting of single-threaded code from Boost.Signals. *Deprecated deconstruct_ptr/postconstructible/predestructible in favor of deconstruct, a factory function similar to make_shared, which supports postconstructors and predestructors via ADL, similar to how the sp_accept_owner stuff works in boost smart_ptr trunk. *Expanded FAQ entry on differences between Signals and Signals2 by adding some notes on how to deal with the changes while porting. Changed the faq entry into a section. *Added documentation section on thread-safety which describes how the library uses its mutexes internally. *Added boost::signals2::signal_type metafunction which uses Boost.Parameter to allow named template type parameters for signals. *Added sections to the tutorial on postconstructors, extended slots, and signal_type. *Added examples section to docs, with compilable example programs extracted from tutorial, plus a few new ones. *Added a couple paragraphs to the design rationale section about optional_last_value and the signals2 mutex classes. *Added a small description to the optional_last_value reference page. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJkzY45vihyNWuA4URAivcAKCSGti3YkLGnzjmTr3EfAeN3FfiUwCg13S4 Jp54J65svUx6MVKNOsW31nU= =U39m -----END PGP SIGNATURE-----

1 0

[function] bug
by Okko Willeboordse 11 Feb '09

11 Feb '09

Applies for 1.37 and 1.38. Using VS2008, SDK 6.1 See ...\function\function_template.hpp 945 #if !defined(BOOST_NO_EXCEPTIONS) 946 try { 947 #endif 948 if (!f.empty()) { 949 this->vtable = f.vtable; 950 f.vtable->manager(f.functor, this->functor, 951 boost::detail::function::move_functor_tag); 952 f.vtable = 0; 953 #if !defined(BOOST_NO_EXCEPTIONS) 954 } else { 955 clear(); 956 } 957 } catch (...) { 958 vtable = 0; 959 throw; 960 } 961 #endif 962 } Line 953 #if !defined(BOOST_NO_EXCEPTIONS) must be moved 3 lines down like; 945 #if !defined(BOOST_NO_EXCEPTIONS) 946 try { 947 #endif 948 if (!f.empty()) { 949 this->vtable = f.vtable; 950 f.vtable->manager(f.functor, this->functor, 951 boost::detail::function::move_functor_tag); 952 f.vtable = 0; 953 } else { 954 clear(); 955 } 956 #if !defined(BOOST_NO_EXCEPTIONS) 957 } catch (...) { 958 vtable = 0; 959 throw; 960 } 961 #endif 962 }

3 4

[Date-Time] local date time "+=" Bug?
by Michael Mathews 11 Feb '09

11 Feb '09

Hi Folks, Here is the issue. If you have a local_date_time before the change in daylight saving time to Standard time or vice versa if you add one day to it the answer is incorrect. Here is a short example: #include "boost/date_time/local_time/local_time.hpp" #include "boost/date_time/posix_time/posix_time.hpp" #include "boost/date_time/local_time_adjustor.hpp" using namespace boost; using namespace local_time; using namespace gregorian; using namespace boost::posix_time; int main(){ typedef boost::date_time::local_adjustor<boost::posix_time::ptime, -6,boost::posix_time::us_dst> local_adj; std::string bryan_string = "CST-06:00:00CDT+01:00:00,M3.2.0/02:00:00,M11.1.0/02:00:00"; boost::local_time::time_zone_ptr tzptr(new boost::local_time::posix_time_zone(bryan_string)); boost::local_time::local_date_time fallback(local_adj::local_to_utc(ptime(date(2008,11,2), minutes(0))),tzptr); std::cout<<fallback<<std::endl; fallback+=days(1); std::cout<<fallback<<std::endl; fallback-=days(1); std::cout<<fallback<<std::endl; boost::local_time::local_date_time springahead(local_adj::local_to_utc(ptime(date(2008,3,9), minutes(0))),tzptr); std::cout<<std::endl; std::cout<<springahead<<std::endl; springahead+=days(1); std::cout<<springahead<<std::endl; springahead-=days(1); std::cout<<springahead<<std::endl; } this code produces the following output with 1.37 and 1.38 2008-Nov-02 00:00:00 CDT 2008-Nov-02 23:00:00 CST 2008-Nov-02 00:00:00 CDT 2008-Mar-09 00:00:00 CST 2008-Mar-10 01:00:00 CDT 2008-Mar-09 00:00:00 CST michael

1 0

Interest in a protected pointer
by Ray Logel 11 Feb '09

11 Feb '09

Is there any interest in pointer wrapper similar to scoped_ptr or shared_ptr which can be used for pointer member variable which can the referenced value can't be modified by non const functions? This class wouldn't be responsible for any memory management and could have a shared pointer version as well. For example: template<typename T> class protected_ptr { T * ptr; // ... T * get(); const T * get() const; // ... including operator* and operator-> } class Foo { protected_ptr<Bar> _bar; void Func1() { _bar->NonConstFunc(); _bar->ConstFunc(); } void Func2() const { _bar->NonConstFunc(); // Compile error _bar->ConstFunc(); // Ok } } Ray Logel

6 6

[1.39.0] Open for merging
by Beman Dawes 11 Feb '09

11 Feb '09

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but only with the permission of a release manager. In other words, except for new libraries, merging changes *does not* need permission from a release manager. I.e. just do it! The release schedule: * March 13, 2009: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * March 20, 2009: Release managers start QA checks. * April 3, 2009: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * April 10, 2009: branches/release closed for all library changes except when specific permission given by release manager(s). * April 17, 2009: Beta release target date. Further betas and/or release candidates as feedback dictates. * May 1, 2009: Release ship date. Links relating to this release: * Google Calendar with the release schedule: <http://www.boost.org/development/index.html>. * Release schedule explanation: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>. * Release practices for developers: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>. --Beman Dawes, Daniel James, Eric Niebler, Rene Rivera

1 0

Re: [boost] Boost 1.38.0 released
by Daniel James 11 Feb '09

11 Feb '09

2009/2/10 Marshall Clow <marshall(a)idio.com>: > Done. > And Boost 1.39.0 as a milestone for "to be fixed" We also need a few new components: https://svn.boost.org/trac/boost/ticket/2702 thanks, Daniel

3 2

[thread][repost] too many unnoticed posts
by vicente.botet 11 Feb '09

11 Feb '09

Hi Anthony, I have made a ticket of each one of the unnoticed post. #2742 Why the at_thread_exit cleanup function is const? Bugs Problem #2741 proposal to manage portable and non portablethread attributes Feature Requests Not Applicable #2740 thread_group::size complexity Feature Requests Optimization #2739 shouldn't at_thread_exit work on the main thread? Bugs Showstopper #2738 at_thread_exit move overloading Feature Requests Optimization #2664 Add unique_lock constructor taking a Duration Feature Requests Problem I can understand that you are very busy. Let me know if I can help you with these tickets. Best, Vicente

2 2

Trac system Milestone
by vicente.botet 11 Feb '09

11 Feb '09

Hi, I see in the Trac system that there are bugs with Milestone 1.36, 1.37. 1.38 and To be determined. As we will not have 1.36.x, 1.37.x releases, and possibly neither 1.38, shouldn't we change the Milestone to 1.39? For the To be determined, shouldn't we change to the corresponding Milestone Boost 1.39, Boost.Jam 3.1.18 Boost.Jam 4.0.0, Website 1.X. Maybe the ToBeDetermined Milestone is not a good idea. I have not counted the tickets without a Milestone, I don't know how to do. BTW, Should'nt the version be a mandatory field? As there are 196 + 97 + 156 + 181= 630 tickets to change it would be great if there is an easy way to do that. Best, Vicente Milestone: Boost 1.36.0 Completed 6 months ago (08/15/08) 62% Closed tickets: 324 Active tickets: 196 / Total tickets: 520 Milestone: Boost 1.37.0 Completed 3 months ago (11/02/08) 55% Closed tickets: 120 Active tickets: 97 / Total tickets: 217 Milestone: Boost 1.38.0 Completed 7 hours ago (02/10/09) 38% Closed tickets: 96 Active tickets: 156 / Total tickets: 252 Milestone: To Be Determined 61% Closed tickets: 279 Active tickets: 181 / Total tickets: 460

1 0

Futures Review Starts Today - January 5, 2009
by Tom Brinkman 11 Feb '09

11 Feb '09

Futures Review Starts Today - January 5, 2009 Braddock Gaskill http://braddock.com/~braddock/future Anthony Williams http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp Please review one or both libraries for submission to boost. Apparently, Anthony Williams' submission has also been sumbitted the C++ standards committee. Status unknown. As always, here are some questions you might want to answer in your review(s): What is your evaluation of the design(s)? What is your evaluation of the implementation(s)? What is your evaluation of the documentation? What is your evaluation of the potential usefulness of the library(s)? Did you try to use the library? With what compiler(s)? Did you have any problems? How much effort did you put into your evaluation(s)? A glance? A quick reading? In-depth study? Are you knowledgeable about the problem domain? Do you think the libraries should be accepted into Boost as-is or should they be merged? Apparently, there has been various discussions about these two libraries last six months. The authors will need to bring us up to date as to why they want their libraries to be reviewed seperately. Also, each author should evaluate each others library and point out the differences in their implentations. These will serve as useful discussion points. The ideal outcome in my mind would be a resubmitted submission, incorporating the best ideas from each. Tell me if you share this view or what is your preferred result. As always, your reviews will certainly assist the authors in improving their libraries even further. Thank you in advance. Please feel free to participate in any discussion even if your not going to provide a full review. Review Manager Tom Brinkman

13 61

[test] como failures
by Steven Watanabe 11 Feb '09

11 Feb '09

AMDG See for instance http://tinyurl.com/anwyuk Simply switching from setenv to putenv in boost/test/utils/runtime/putenv.hpp seems to solve the problem. Since libcomo just inherits putenv from the C library, I don't understand what this workaround is supposed to be doing. In Christ, Steven Watanabe

2 1

Detecting reuslt_of support - Error with VC 9
by Joel Falcou 11 Feb '09

11 Feb '09

I've developepd this code snippet to detect if a type has the proper inner types for supporting result_of protocol : http://codepad.org/mcY4K7Sf It works fine under gcc and icc but fail under VC 9 with the following error : error C2903: 'result' : symbol is neither a class template nor a function template error C3202: 'result' : invalid default argument for template parameter '<Unknown>', expected a class template error C2976: 'has_result_impl' : too few template arguments seems I can't make VC to accept an unspecified template type as a template template parameter. Is there any known workaround for this situation I can implement to make this traits works in VC 9 ?

4 4

libraries dependencies
by Konstantin Litvinenko 10 Feb '09

10 Feb '09

I am working on a "yet another" build tool :) and as part of performance testing I am doing boost modularization. Boost was chosen because I work with it more then 5 years and it big enough and known to me. Modularization of boost 1.34.1 was successful and 31 (not all yet) libraries was tested. That was easy. But when I tried to modularize boost 1.36.0 I faced circular dependencies that I can't break. Some old part of boost that have enormous interheader dependencies I separated in /boost/core library(mpl + preprocessor + bind + utility + many small .hpp + details). For boost 1.34.1 I decided that throw_exception.hpp must reside in /boost/core library. For 1.36.0 I decided to put it in /boost/exception because it is natural place for that functionality. But /boost/exception is dependent on /boost/smart_ptr that dependent on /boost/exception. And ooops - we have circular dependency. I can place both /boost/exception and /boost/smart_ptr into /boost/core but that seams really wrong to me. I known that some folks working on CMake build system and also need modularize boost. So my question is: Is there any plans to do refactoring/cleaning/reorganizing/... to make boost have more clean inter-libraries dependencies? Thanx

2 1