- Boost - lists.preview.boost.org

[website] [filesystem] How to update HTML page on website?
by Beman Dawes 04 Dec '10

04 Dec '10

I'd like to fix a very misleading documentation bug in Boost.Filesystem. How do I update a single HTML page on the server? Were is this documented? Thanks, --Beman

3 4

[Bug Sprint] Status for Friday, December 3rd
by Marshall Clow 03 Dec '10

03 Dec '10

There were only 13 changes to the trac database yesterday. [ I'd like to say "13 tickets were changed", but some tickets were changed more than once. ] The decrease in activity continues. It's time to ramp it up - there are only three more days in the Bug Sprint. In the last bug sprint, we closed almost 200 tickets (not 100 - I misremembered). So far this time, we're down a (net) 13 tickets from the start of the sprint! If you think it's too late to get involved - you're wrong! If you're looking for things to do, there are several patches for Date-Time waiting to be reviewed (thx to ktchan): #2956 is very old and need review #3651 is simple documentation changes #4057 appears at a glance simple changes #4411 & #4754 is simple update to time zone data file #4475 #4798 is a simple change #4845 is simple documentation changes #4870 #4920 is simple update to date_time examples and there are a bunch of program-options bugs that can be looked at: #850 program_options strips off escaped quotes in some situations #1132 zero_tokens doesn't work #3813 program_options::options_description.add() permits duplicate options #3909 parse_command_line has bad declaration #3992 Example in documentation for program_options doesn't compil #4040 Program Options has issues with options that support multiple tokens when using multiple parsers #4133 std::logic_error as a base class for program_options::error #4137 boost::program_options::value_semantic missing 's' at the end #4149 exceptions thrown by typed_value::default_value() are not documented #4150 bool_switch() is exception-unsafe #4151 option_description::option_description(3 args) is exception-unsafe #4267 validation_error documentation #4469 Bugs in program_options implementation #4510 [program_options]: implicit_value and positional options conflict #4597 options_description should be defined as noncopyable #4656 program_options parse_config_file() set iostream failbit even if the parse result is ok #4858 Documentation error - Responsefile example code can crash (You all know the drill: develop a fix, test it locally, make a patch, attach it to the ticket) A couple of notes: 1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up. 2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4, etc) and it worked fine/didn't work/etc" General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) December 1: 929 December 2: 930 December 3: 933 (ouch!) Activities on the trac system yesterday: jim.bell@ 4 viboes 2 jaredgrubb@ 2 --others-- 5 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone

2 2

Boost development calendar
by David Bellot 03 Dec '10

03 Dec '10

Hi developers, is it my configuration or the Boost Developer Google Calendar is not updated anymore ? As this calendar is shared, it would be nice to have the next important events (like closing 1.46, 1.47, 1.48...) in it. (but if I misconfigured something, then forget about my email :-D ). Cheers, David *____________________ David Bellot, PhD **http://david.bellot.free.fr http://ai-owl.blogspot.com*

4 3

pimpl library proposal
by Michael Bailey 03 Dec '10

03 Dec '10

I have created a pimpl library that I use on a regular basis which sits on top of boost and was wondering if there was any interest in my providing it to the community. It is quite simple, but has been extremely useful personally. The library has two basic components. For starters, it uses a boost::shared_ptr to hide the implementation in the cpp file. The forwarding of the public interface is accomplished through some simple macros. The macros declare each public method, with an appropriate signature, and forward the call onto the implementation class. It would be easier to show an example of it in action: my_object.hpp class my_object : public boost::pimpl<class my_object_impl> { public: my_object() {} void do_something(); int do_other_thing( double ) const; void lots_of_args( int, int, int, int ); }; my_object.cpp class my_object_impl { public: void do_something() {...} int do_other_thing( double a1 ) const {...} void lots_of_args( int, int, int, int ) {...} private: ... }; BOOST_PIMPL_CTOR( my_object ); BOOST_PIMPL_METHOD( 0, my_object, do_something ); BOOST_PIMPL_METHOD( 1, my_object, do_other_thing, const ); BOOST_PIMPL_METHOD( 4, my_object, lots_of_args ); If this seems like it would be of any use to others, let me know. I'd be happy to share.

3 2

[Bug Sprint] Status for Thursday, December 2nd
by Marshall Clow 03 Dec '10

03 Dec '10

There were 33 changes to the trac database yesterday. [ I'd like to say "33 tickets were changed", but some tickets were changed more than once. ] The decrease in activity continues. It's time to ramp it up - there are only four more days in the Bug Sprint. In the last bug sprint, we closed almost 100 tickets. So far this time, we've closed 16. If you think it's too late to get involved - you're wrong! If you're looking for things to do, there are several patches for Date-Time waiting to be reviewed (thx to ktchan): #2956 is very old and need review #3651 is simple documentation changes #4057 appears at a glance simple changes #4411 & #4754 is simple update to time zone data file #4475 #4798 is a simple change #4845 is simple documentation changes #4870 #4920 is simple update to date_time examples and there are a bunch of program-options bugs that can be looked at: #850 program_options strips off escaped quotes in some situations #1132 zero_tokens doesn't work #3813 program_options::options_description.add() permits duplicate options #3909 parse_command_line has bad declaration #3992 Example in documentation for program_options doesn't compil #4040 Program Options has issues with options that support multiple tokens when using multiple parsers #4133 std::logic_error as a base class for program_options::error #4137 boost::program_options::value_semantic missing 's' at the end #4149 exceptions thrown by typed_value::default_value() are not documented #4150 bool_switch() is exception-unsafe #4151 option_description::option_description(3 args) is exception-unsafe #4267 validation_error documentation #4469 Bugs in program_options implementation #4510 [program_options]: implicit_value and positional options conflict #4597 options_description should be defined as noncopyable #4656 program_options parse_config_file() set iostream failbit even if the parse result is ok #4858 Documentation error - Responsefile example code can crash (You all know the drill: develop a fix, test it locally, make a patch, attach it to the ticket) A couple of notes: 1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up. 2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4, etc) and it worked fine/didn't work/etc" General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) December 1: 929 December 2: 930 Activities on the trac system yesterday: bemandawes 7 ktchan 4 jim.bell@ 4 --others-- 18 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone

5 5

compiling boost optimizations
by Mag Gam 03 Dec '10

03 Dec '10

Currently, I compile with "./bootstrap.sh --with-toolset=intel-linux stage" and then "bjam variant=release link=shared install" Since I am compiling it with the Intel C compiler. I was wondering if there are any known optimizations I can try. tia

1 0

[Bug Sprint][filesystem/io] Path streaming operator
by Richard Hazlewood 03 Dec '10

03 Dec '10

The filesystem path streaming operator (>>) has a bug, documented here: https://svn.boost.org/trac/boost/ticket/4716 A patch was provided, and was implemented on the trunk, detailed here: http://lists.boost.org/boost-commit/2010/08/27576.php The fix was not merged to the Release branch, so missed the 1.45 release. Please can this be merged, so it gets into the 1.46 release? [.../boost/io/detail/quoted_manip.hpp]

1 0

Probing interest in a typed XML traversal library
by Sumant Tambe 02 Dec '10

02 Dec '10

Hello boosters! I'm interested in gauging interest in a typed XML traversal library that combines the succinctness of XPath with the type-safety of XML data-binding tools. I've been developing one such library called LEESA: Language for Embedded Query and Traversal <http://www.dre.vanderbilt.edu/LEESA>. LEESA has several capabilities: 1. Succinct and expressive XPath-like notation for writing object structure traversals 2. Supports child, parent, sibling, descendant, ancestor axes 3. Compile-time schema conformance checking 4. Supports GOF visitors and hierarchical visitors 5. Strategic Programming ... and more! Here are two quick examples comparing XPath and LEESA. More examples are available on the LEESA homepage. XPath expression: "/catalog/book/author/name/text()" LEESA expression: *std::vector<name> author_names = evaluate(root, catalog() >> book() >> author() >> name()); * XPath expression: "//name/text()" LEESA Expression: *std::vector<name> names = evaluate(root, catalog() >> DescendantsOf(catalog(), name())); * The above expressions are checked for schema-conformance at compile-time. LEESA builds these capabilities on top of existing XML data binding tools that generate C++ code from .xsd files. The general process of using LEESA is as follows: 1. Generate C++ classes using your favorite XML data binding tool 2. A python script that comes with LEESA adds a few functions in every generated C++ class. It generates a lot of typedefs and helper functions, which invoke tool generated code. This creates a bridge between LEESA and the code generated by the xml data binding tool. Currently it supports Code Synthesis's xsd and Universal Data Model (UDM) from Vanderbilt University as the underlying code generators. 3. The user includes LEESA.h in his/her C++ program (it is header-only), uses its programming model, compiles, and links with the tool generated code and libraries. So folks, please speak up if you are interested in having such a library in Boost. Thanks, Sumant

3 5

Variadic_macro_data library update
by Edward Diener 02 Dec '10

02 Dec '10

I have updated the variadic_macro_data librfary in the sandbox to version 1.2. The update does not change the functionality of the library, but adds better documentation, better-looking documentation, and updated jamfiles that allow the documentation and tests to be done in a local directory without having to move the library under a Boost distribution. See the readme.txt file in the doc sub-directory for more information. The variadic_macro_data library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Comments, questions, and suggestions are always welcome.

1 0

[Bug Sprint] [Date Time] Anyone want to review and commit some of the existing patches?
by KTC 02 Dec '10

02 Dec '10

Hi, Jeff Garland does not seems to have been around for the last few months. As such, could someone review and commit to trunk (and then release) some of the patches on trac? #2956 is very old and need review #3651 is simple documentation changes #4057 appears at a glance simple changes #4411 & #4754 is simple update to time zone data file #4475 #4798 is a simple change #4845 is simple documentation changes #4870 #4920 is simple update to date_time examples KTC

2 1

[Bug Sprint] The November bug sprint starts tomorrow!
by Marshall Clow 02 Dec '10

02 Dec '10

The Boost bug sprint starts tomorrow Saturday, November 27, 2010 and runs through Sunday December 5th. The goal of the bug sprint is to make Boost better; the way we measure this is to look at the open tickets in the Trac system. In the last bug sprint (back in June), we closed over 200 tickets. However, in the past five months, the number of open tickets has crept back up, so that we once again have more than 900 open tickets. (the count was down under 800 at the end of the previous sprint). General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone -- Marshall

11 25

Easy ticket to close: #4532 make_adaptable undocumented
by Daniel Trebbien 02 Dec '10

02 Dec '10

Ticket #4532 (make_adaptable undocumented; https://svn.boost.org/trac/boost/ticket/4532) should be an easy ticket to close because it only affects the documentation. Would someone please review or commit the patch that I submitted three days ago?

2 1

Getting volunteers' changes back to trunk
by Jim Bell 01 Dec '10

01 Dec '10

Say you have a team of volunteers attacking failed regressions and tickets. They're creating (hopefully) good trunk patches. They can't commit to the trunk, but can modify tickets. If maintainers are active, they could review and incorporate them. But this increased activity may be more of a strain for them. If maintainers are MIA, it won't happen. So we need at least one person to bring these changes back into the trunk. Changes to libraries they're not familiar with. What's the best way for the volunteers to signal to these trunk-authority people to pick up their change? A Ticket keyword and corresponding report should work. Is there a better way? Should we look for a person or two from the volunteers for this role? A regular schedule (say, twice a week) to run the report and patch would be good, I think. Trunk regressions need time to bake. Thoughts?

6 29

Is merging to the release branch allowed again?
by Hartmut Kaiser 01 Dec '10

01 Dec '10

Since I hate holding back merging to the release branch to the last minute before the next release I would like to start doing this asap. Any idea when this might be allowed again? Regards Hartmut --------------- http://boost-spirit.com

6 7

[mpl-cf] [RFC] MPL Real Numbers using Continued Fractions
by Hal Finkel 01 Dec '10

01 Dec '10

Hello, A few months ago, I created an MPL extension type for representing real numbers. The indented use is for compile-time generation of floating-point constants, although it could also be used for MPL-based graph algorithms, etc. The primary design requirement was that almost any compiler would be able to completely inline the conversion to floating-point (which means no functional recursion can be used), and I think I've achieved that. The current implementation uses a modified version of MPL's vector type (modified to add the conversion to floating point, add "overloads", and to remove the typeof-based implementation variant (which is incompatible with the floating-point conversion)). I've posted the code to the Boost vault under the "Template Metaprogramming" section; the file name is boost-mpl-cf-20100531.zip Continued fractions were chosen for the representation because the associated algorithms are simple, and simple proved important for keeping down compilation times. Even so, the compilation times might be too long for practical use. You can decrease the compilation time by using a shorter maximum cf-length by defining BOOST_MPL_LIMIT_CF_SIZE to be 10 instead of 20. The current default is 20 to allow an effective precision near that of a double. Also, continued fractions, being "based on" rational numbers, can exactly represent any rational (for example, 1/3) so the computations can be more accurate than those using a floating-point representation. If you don't know what a continued fraction is, and would like to know, you can check out the wikipedia page: http://en.wikipedia.org/wiki/Continued_fraction The current implementation supports addition, subtraction, multiplication and division, comparison ops, some constants like pi, and I've included sin()/cos() as well. I've not yet written any real documentation, but the archive has a couple of test programs; the usage is pretty simple. Each test program has many individual tests, so its compilation time will be representative of a more-complicated computation, if you just need to do a few things, it would be much faster. If there is interest, I'll add support for generating numbers using metafunctions, write some documentation, jam files, etc. Let me know what you think, and I welcome suggestions, criticisms, etc. Also, I've currently tested using only the GNU and Intel compilers, so let me know whether it does or does not work when using something else. Thanks again, Hal P.S. I know that there is a mpl_math archive on the vault from back in 2007. I did not discover this until after I had almost finished writing my mpl-cf implementation, but, the mailing-list messages from the time indicate that it was too slow to be used practically, since I think the continued fractions algorithms are simpler, mpl-cf might be better, but I've not tested it to find out.

6 11

[Bug Sprint] Status for Wednesday, December 1st
by Marshall Clow 01 Dec '10

01 Dec '10

There were 30 changes to the trac database yesterday. [ I'd like to say "30 tickets were changed", but some tickets were changed more than once. ] That's a notable decrease in activity from the last few days. In the last bug sprint, we closed almost 100 tickets. So far this time, we've closed 17. If you think it's too late to get involved - you're wrong! A couple of notes: 1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up. 2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4, etc) and it worked fine/didn't work/etc" General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) December 1: 929 Activities on the trac system yesterday: avibahra@ 3 marshall 3 hkaiser 3 jwellico 3 --others-- 18 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone

1 0

Conversion operator for boost any
by Leonid Frenkel 01 Dec '10

01 Dec '10

Hello, I found adding the following conversion operator to Boost.Any was very helpful in some cases: (specially when using macros inside functions) template <typename ValueType> operator ValueType() { return any_cast<ValueType>(*this); }

1 0

Re: [boost] Boost 1.45 compile error
by Eric Niebler 01 Dec '10

01 Dec '10

(bringing in boost dev...) This sounds bad. Can anybody confirm? -- Eric Niebler BoostPro Computing http://www.boostpro.com On 11/19/2010 4:35 PM, gast128 wrote: > Hello all, > > just tried out Boost 1.45 on VStudio 2003 but I got a compile error by only > including type_traits: > > #include <boost/type_traits.hpp> > > int main() > { > return 0; > } > > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error C2027: > use of undefined type '<Unknown>' > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(143) : see > declaration of '<Unknown>' > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : see > reference to class template instantiation '<Unknown>' being compiled > C:\Work Sdk\boost_1_45_0\boost\type_traits\common_type.hpp(121) : see > reference to class template instantiation '<Unknown>' being compiled > C:\Work Sdk\boost_1_45_0\boost\type_traits\common_type.hpp(123) : see > reference to class template > instantiation 'boost::type_traits_detail::common_type_2<T,U>' being compiled > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error C2146: > syntax error : missing ';' before identifier 'wrapped_type' > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(160) : error > C2501: '<Unknown>' : missing storage-class or type specifiers > C:\Work Sdk\boost_1_45_0\boost\typeof\msvc\typeof_impl.hpp(161) : error > C2653: 'wrapped_type' : is not a class or namespace name > > afaik it seems located on 121 in 'boost/type_traits/coomon_type.hpp' > > Anyone can help?

12 27

[gil] New IO release
by Christian Henning 30 Nov '10

30 Nov '10

Hi there, a new gil IO extension is ready for download. Here is the link: http://code.google.com/p/gil-contributions/downloads/detail?name=boost_revi… This is the final version that will be used for the boost review. Could someone try to build documentation on Linux? Thanks to all people that have helped me out. Regards, Christian

5 18

Sandbox cleanup
by Vladimir Prus 30 Nov '10

30 Nov '10

Folks, it appears that at present, our SVN sandbox is in fairly confused state. A fresh checkout contains objects of very different kinds, in particular: - 'boost' directory, that has assorted headers supposedly meant for future. - 'libs' directory, with various libraries - Pile of top-level directories for libraries-in-development, each containing 'boost' and 'libs' subfolders. - Subdirectory SCons, with a copy of entire Boost tree, buildable with scons. - Subdirectory 'win32-doc-tools', which surely does not contain a library - Some directories named after specific people. It's not clear whether those directories contain a single future library, or several, or what. It seems that a straight-forward approach to fix that is to have two separate areas in sandbox, as follows: [using fixed font to read the below might work better] /sandbox /libraries /proposed-lib1 /boost /libs .... /branches /jrhacker-assorted-fixes [complete branch of trunk, with changes] /SCons [complete branch of trunk, with SConstruct, etc] Comments? -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

8 9

[Bug Sprint] Status for Tuesday, November 30th
by Marshall Clow 30 Nov '10

30 Nov '10

There were 59 changes to the trac database yesterday. [ I'd like to say "59 tickets were changed", but some tickets were changed more than once. ] A couple of notes: 1) Please log into the Trac system before you add/modify a ticket. "Anonymous said:" is hard to follow up. 2) It is perfectly OK to add a comment to a ticket that says "I tested this patch on my system (foo, gcc 1.2.3.4, etc) and it worked fine/didn't work/etc" General information about the bug sprint is here: https://svn.boost.org/trac/boost/wiki/BugSprintNov2010 General information about how the Trac system works is here: https://svn.boost.org/trac/boost/wiki/TicketWorkflow Overall bug count: November 26: 946 November 27: 939 November 28: 930 November 29: 934 (whoops, that's the wrong direction!) November 30: 931 (better, but the delta is too small) If you want to contribute, I would suggest looking at the old tickets, and seeing what you can do with them: Here are the tickets by milestone: Milestone Tickets To Be Determined 362 Boost 1.43.0 100 Boost 1.44.0 94 Boost 1.42.0 74 Boost 1.36.0 48 <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Boost 1.40.0 48 Boost 1.39.0 43 <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Boost 1.41.0 39 <blank> 36 Boost 1.38.0 30 <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Boost 1.37.0 25 <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Boost 1.45.0 13 Boost 1.46.0 12 Website 1.X 4 Boost 1.47.0 1 Boost.Jam 3.1.18 1 Boost.Jam 4.0.0 1 Activities on the trac system yesterday: viboes 16 anonymous 12 ramey 7 mikhailberis 3 marshall 3 --others-- 18 Useful reports: https://svn.boost.org/trac/boost/report/1 -- full list of tickets https://svn.boost.org/trac/boost/report/18 -- ticket counts by owner https://svn.boost.org/trac/boost/report/19 -- ticket counts by component https://svn.boost.org/trac/boost/report/20 -- ticket counts by ticket type https://svn.boost.org/trac/boost/report/21 -- ticket counts by milestone

3 2

virtual protected inheritance and default constructors
by gzp 30 Nov '10

30 Nov '10

Hello, This might be an off-topic question, but there must be here some clever guy who can answer my question. class Impl { public: Impl() { std::cout << "j"; } // want to eliminate, but cannot :( Impl(int j) { i = j; std::cout << "i"; } int i; }; template<typename TImpl> class A : virtual protected TImpl { public: void geti() const { std::cout << "gi" << i << "\n"; } }; template<typename TImpl> class B : public A<TImpl> { public: void seti(int a) { this->i = a; } }; class CA : public A<Impl> { public: CA() : Impl(3) { std::cout << "ca " << i;} }; class CB : public B<Impl> { public: CB() : Impl(2) { std::cout << "cb " << i;} }; //abuse of interfaces template<typename TImpl> void foo( A<TImpl>& p_a ) { p_a.geti(); } template<typename TImpl> void foo( B<TImpl>& p_a ) { p_a.seti( 2 ); } template<typename TImpl> void foo2( A<TImpl>& p_a ) { p_a.geti(); } int main( int, char*[] ) { CA a; std::cout << "\n"; CB b; std::cout << "\n"; foo(a); foo(b); foo2(a); foo2(b); return 0; } The basic concept was that: there is a simple implementation class and using some interfaces (bridge classes) the appropriate function call (foo) can be ensured using compile time type checking. The implementation might provide implementation to multiple interfaces (bridge classes) and these interfaces guarantee the required operation for each (template)functions. The role of A and B is to provide the interface and bridge it to the implementation. The only missing part was, how to construct a CA and CB object. They might have completely different construction parameters and the virtual protected inheritance partially solved the problem. BUT the default constructor is always required (VC2008) even tough it gets never called (I don't want to create any object from A,B (who are missing these default ctors) but I couldn't tell it to the compiler) "The declare and don't define" doesn't solve the problem either as the linker requires the default Impl ctor even though it never gets called. For example: impl1: a range iterator for an 1D array: ctor requires the array.begin, array.end impl2 a random generator range: ctor requires the random seed CA: isEmpty, front, popFront CB: put, mutable front copy from random range to array is valid (template foo(A,B)), but not the other way (no template foo(B,A)) Thanks, Gzp -- View this message in context: http://boost.2283326.n4.nabble.com/virtual-protected-inheritance-and-defaul… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[1.45][filesystem3] utf8 support
by Jochen Wilhelmy 30 Nov '10

30 Nov '10

Hi! now I switched to filesystem3. Everything works, but there is one issue on windows. I'd like to use utf8 in my application. I can imbue an utf8-locale to path. But if I have legacy libraries that take only 8 bit strings then I would pass utf8 instead of ansi (e.g. latin1). Therefore filesystem::path can be seen as a gateway between the application and the operating system and therefore needs two locales, one for the application and one for the operating system. Or an additional method utf8() that returns utf8 regardless of the locale. What do you think? -Jochen

2 1

[thread] On shared_mutex
by Howard Hinnant 30 Nov '10

30 Nov '10

Three years ago I wrote N2406 "Mutex, Lock, Condition Variable Rationale" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2406.html) for the C++ committee in an attempt to explain the combined proposed std::mutex/std::unique_lock package and how it fit together with the tr2-targeted shared_mutex/shared_lock package. This paper also proposed an upgrade_mutex and upgrade_lock. Since that time, the std-proposed stuff has been accepted with some name changes, and a reworking of the timed-locking interface. Additionally Anthony Williams has implemented much of the shared-locking functionality in boost (and done a very nice job with it). That being said, I disagree with some fairly major design changes between N2406 and what is now in the boost library. Four of the major changes are: 1. upgrade_mutex has been dropped. 2. Some, but not all of the functionality in upgrade_mutex has been moved into shared_mutex. 3. Some of the upgrade_mutex functionality is missing completely. The missing functionality is summarized in the "Ownership Modes" charts in the form of red arrows. 4. boost allows implicit conversions between the lock types. N2406 made these conversions explicit. Rationale: changing the ownership mode of a mutex is something that should be well documented in the code. I have an updated implementation of <shared_mutex> (under the boost license) here: http://home.roadrunner.com/~hinnant/mutexes/shared_mutex http://home.roadrunner.com/~hinnant/mutexes/shared_mutex.cpp There is a tutorial-style description of this library here: http://home.roadrunner.com/~hinnant/mutexes/locking.html The tutorial includes a brief description of the use of most of the components, complete synopses, and an examples section. It also notes where this design differs from the boost design and explains why I believe the boost design is in error. Comments appreciated, and all are welcome to use this code under the boost license. I will likely update this document in response to comments and its date at the top will correctly reflect the last time it was updated. This library, or a variation of it, will probably be submitted to TR2, and so getting feedback on the differences between this and the boost implementation is important. Thanks, Howard

5 17

Re: [boost] Moving Boost.Geometry to trunk (was: Sandbox cleanup)
by Hartmut Kaiser 30 Nov '10

30 Nov '10

> > 1. Declare that /sandbox should follow<library>/{boost,libs} layout. > > 2. Move everything else into /sandbox-branches > > Boost.Geometry follows <library>/{boost,libs,other} layout where other > contains small programs not fitting within libs. I hope this is permitted. > I'm quite dependent on the current place and so are many users. I will > remove the (now obsolete) ggl folder which is still there. > > Maybe it is also possible (now or in the future) to make a distinction > between already-accepted-but-not-yet-incorparted libraries (such as > Boost.Geometry) and proposed libraries. > > Finally there is also /sandbox-tags, of which the structure is also not so > clear to me. I've taken the freedom to create a "geometry" folder there, > and below that are our tags. > > So the there structure is for me: > /sandbox-tags/<library>/<tagname>/{boost,libs} > > And I propose that as a convenient layout. Barend, not really related but a question anyways: why don't you move your overall activities to the trunk? I know you're not satisfied with certain details of your library. However, doing the development on trunk (and Boost.Geometry is an accepted library) gives you more exposure to potential users and full integration with the regression tests. Additionally, having the library on trunk doesn't mean you need to merge it to the release branch for any release in the near future... Regards Hartmut --------------- http://boost-spirit.com

2 1