- Boost - lists.preview.boost.org

shared_ptr 1.35.0 problem on SPARC
by Peter Dimov 03 Apr '08

03 Apr '08

Joe Gottman reports in: http://svn.boost.org/trac/boost/ticket/1758 that 1.35.0 fails to build with gcc 3.4 on SPARC Solaris. The problem is that there is no way to autodetect whether the V9 instruction set has been selected in 32 bit mode, because GCC only defines __sparcv8 for compatibility reasons. Since most (all?) SPARCs where Boost runs are UltraSPARCs, which do support V9, we can fix this by making the V9 instruction set default. I see in gcc.jam the following lines: cpu-flags gcc OPTIONS : sparc : c3 : -mcpu=c3 : default ; cpu-flags gcc OPTIONS : sparc : v7 : -mcpu=v7 ; cpu-flags gcc OPTIONS : sparc : cypress : -mcpu=cypress ; cpu-flags gcc OPTIONS : sparc : v8 : -mcpu=v8 ; cpu-flags gcc OPTIONS : sparc : supersparc : -mcpu=supersparc ; cpu-flags gcc OPTIONS : sparc : sparclite : -mcpu=sparclite ; cpu-flags gcc OPTIONS : sparc : hypersparc : -mcpu=hypersparc ; cpu-flags gcc OPTIONS : sparc : sparclite86x : -mcpu=sparclite86x ; cpu-flags gcc OPTIONS : sparc : f930 : -mcpu=f930 ; cpu-flags gcc OPTIONS : sparc : f934 : -mcpu=f934 ; cpu-flags gcc OPTIONS : sparc : sparclet : -mcpu=sparclet ; cpu-flags gcc OPTIONS : sparc : tsc701 : -mcpu=tsc701 ; cpu-flags gcc OPTIONS : sparc : v9 : -mcpu=v9 ; cpu-flags gcc OPTIONS : sparc : ultrasparc : -mcpu=ultrasparc ; cpu-flags gcc OPTIONS : sparc : ultrasparc3 : -mcpu=ultrasparc3 ; The default instruction set seems to be "c3", which results in -mcpu=c3. What is -mcpu=c3? It's not documented anywhere. Can we move the "default" to the v9 line?

2 1

Re: [boost] [1.36.0] High priority compilers for this release?
by Boris Gubenko 03 Apr '08

03 Apr '08

John Maddock wrote: > [...] Incidently, it's good to have at least one > EDG based front end in our official support list, even if it does > emulate > the MSVC bugs ;-) HP aC++ (toolset acc) is EDG based compiler. So is cxx on Tru64, but the latter is not an officially supported compiler in 1.35 (it is in 1.34). Boris

1 0

[shifted_ptr] new_sh
by Phil Bouchard 03 Apr '08

03 Apr '08

Greetings: This is a short notice to let you know I changed "make_shifted_ptee" function call to "new_sh" because it deosn't make sense to use "make_" series in that situation because "shifted_ptee" isn't a valid object. I think "new_sh" is acceptable. Regards, -Phil

1 0

GSoC Ideas: Optimizing Boost libraries for multi-core machines
by Cristianno Martins 03 Apr '08

03 Apr '08

Hello everybody, As I said in last e-mails, I'm interested in Boost projects to GSoC. Now, I have write a proposal and submit it to GSoC, but I'll really appreciate if anyone comment my idea. (I can change something wrong or strange yet) Well, I'm proposing to parallelize one or more libraries in Boost, using OpenMP to do this. Basically, I'll choose a library, review its source code, identify and parallelize the bottlenecks, and document the strategy and results. These steps will be done iteratively during the project. Any comment is welcome. Best, -- Cristianno Martins Mastering in Computer Science State University of Campinas cristianno.martins(a)students.ic.unicamp.br skype:cristiannomartins g-Talk: cristiannomartins msn: cristiannomartins(a)hotmail.com (rarely used)

7 10

[extension] Replace LoadLibrary with LoadLibraryA
by Boris 03 Apr '08

03 Apr '08

Is this the right place to discuss (Boost.)Extension (using a parenthesis as I'm not sure if this library has been accepted or even been reviewed)? In file extension/impl/library_impl.hpp, line 37, LoadLibrary needs to be replaced with LoadLibraryA. Otherwise if you use Unicode you get a compiler error (as LoadLibrary is then defined as LoadLibraryW which expects a const wchar_t* and not a const char*). Boris

5 9

CGI/FastCGI library preview
by Darren Garvey 03 Apr '08

03 Apr '08

Hi everyone, Some of you may remember the CGI library that was being worked on for last year's GSoC. It still needs *loads* of work before it could be considered ready for review, but I think it's moved on far enough since I last updated this list that some more feedback would be very useful. Pre-built docs are online: http://cgi.sf.net/doc Current source is at: *http://tinyurl.com/2bsbsf* (browser-friendly) *http://tinyurl.com/2xcye2* (check-out) ** This is alpha-grade source: functional and ugly ** The examples there have been tested on ubuntu with gcc 4.1.2 and gcc 4.2 and on windows with MSVC 9. The FastCGI examples will only work on linux for now. I've not managed to get it working with lighttpd as-is but it seems to work fine on Apache 2.2 with mod_fastcgi or mod_fcgid (and shows some healthy benchmarking results). Any and all comments/suggestions/criticisms are welcome. Kind regards, Darren

2 3

Trac open bugs - by assignee
by Marshall Clow 03 Apr '08

03 Apr '08

[ 256 open bugs today, 245 Tuesday ] There's been an upsurge of reported bugs (probably due to increased interest in the 1.35.0 release). If any of these are yours, please take a look at them. Thanks! If you are maintaining a library, and have not logged into the trac system at <http://svn.boost.org/trac/boost/>, please do so ASAP. Until you do that, no tickets can be assigned to you, and will remain under "None". Instructions on working with tickets can be found at: <http://svn.boost.org/trac/boost/wiki/TicketWorkflow> and a mapping of user names to "real names" can be found at: <http://svn.boost.org/trac/boost/report/16> Bug summary 24 djowel 23 az_sw_dude 21 grafik 15 vladimir_prus 14 dave 13 dgregor 12 doug_gregor 12 bemandawes 11 no-maintainer 11 agurtovoy 8 turkanis 8 jsiek 8 anthonyw 6 matias 5 witt 5 nesotto 5 johnmaddock 5 igaztanaga 4 rogeeff 4 ramey 4 ebf 3 nasonov 3 kaalus 3 danielw 3 danieljames 3 None 2 shammah 2 samuel_krempp 2 pdimov 2 pavol_droba 2 jmaurer 2 hkaiser 2 aaron_windsor 1 urzuga 1 t_schwinger 1 speedsnail 1 marshall 1 garcia 1 fcacciola 1 dlwalker 1 chris_kohlhoff 1 <Blank> <Blank> 1750 Autolink library name not in sync with actually build lib None 1644 Boost.Test missing documentation file BOOST_CHECK_CLOSE_FRACTION.html None 1736 Headers containing non ASCII characters cause MS VC to issue warning 4819 in some locales None 1744 No information on building static libraries with bjam under Windows aaron_windsor 1622 Adjacency list needs to handle self-edges correctly aaron_windsor 778 top-level configure is broken agurtovoy 1001 gcc 4.1.2 segfaults on mpl/test/apply.cpp agurtovoy 1051 MPL header ordering triggers bug agurtovoy 1099 unable to iterate through a "non-explicitly-declared" mpl::set agurtovoy 1215 Boost 1.34.1_ mpl: Wrong workaround detection using MinGW32 (or.hpp_ line #33) agurtovoy 1317 has_xxx randomly broken in msvc agurtovoy 1469 [mpl] nested typedef of set has two different meanings agurtovoy 1476 always<> is not nullary. agurtovoy 1528 g++ 4.3.0 reports error because of redeclaration of next agurtovoy 1549 Boost.MPL: 'index_of' algorithm is not documented agurtovoy 1568 duplicate include guards agurtovoy 588 mpl::remove compile error with gcc 4.1.0 anthonyw 1154 tss destruction segfaults in conjunction with dlopen/dlclose anthonyw 1168 [thread] tss crashes randomly anthonyw 1268 xtime_cmp changes to deal with overflow were reverted anthonyw 1470 Boost.Thread: Compilation errors with non-__cdecl calling convention anthonyw 1657 Bug in boost::threads sample anthonyw 1713 no definitions for copy ctor and assignment operator for basic_condition_variable anthonyw 876 xtime documentation incomplete anthonyw 881 errors when build with Apache stdcxx az_sw_dude 1028 typo in boost header: date_time/time_defs.hpp az_sw_dude 1078 from_iso_string cannot read the output from to_iso_string az_sw_dude 1098 Urgent libboost-date-time1.33.1 : bugs on ia64 ? az_sw_dude 1147 date_time library contains global #define ERROR az_sw_dude 1160 warning: month_format shadows a member of this az_sw_dude 1162 warning: ticks shadows a member of this az_sw_dude 1289 posix_time::time_facet forgets to pass a_ref argument to base class az_sw_dude 1299 change in typedef stringstream_type in format_date_parser.hpp causing compilation error az_sw_dude 1306 invalid docbook in date_period.xml az_sw_dude 1384 Linking problem with date_time library on Visual C++ 2008 Express az_sw_dude 1386 date_time documentation Jamfile breaks building of boost docs az_sw_dude 1524 format_date_parser.hpp(221) : cannot convert parameter 1 az_sw_dude 1574 operator<< for boost::posix_time::ptime ignores ostream flags az_sw_dude 1674 date_time::date_formatting.hpp: incorrectly formats year using global locale az_sw_dude 1695 add correct namespace to class to fix compilation bug az_sw_dude 1726 boost/date_time/posix_time/time_formatters.hpp incorrectly formats fractional seconds using global locale az_sw_dude 1740 date_time includes <windows.h> az_sw_dude 287 wrong usage of ios_base::narrow az_sw_dude 316 date_time type conversion warning az_sw_dude 604 from_ftime incorrectly processes FILETIME filled with zeros az_sw_dude 642 operator<< for gregorian::date_duration not found az_sw_dude 889 Insane Dependencies az_sw_dude 890 date_time library supports only the current dst rule bemandawes 1378 filesystem path invalid name for hidden files (LINUX) bemandawes 1389 filesystem::ostream << boost::format generates operator ambigious error (in MSVC++) bemandawes 1458 Darwin Tiger throws std::runtime_error: locale::facet::_S_create_c_locale name not valid bemandawes 1578 bug in readdir_r_simulator() in a multi-threaded environment bemandawes 1583 Serious flaw in boost::filesystem filename handling (opensuse) bemandawes 1589 [filesystem] 'mbstate_t' : is not a member of 'std' bemandawes 1606 filesystem/src/exception.cpp doesn't build with gcc bemandawes 1613 Link Errors against file_system on OS X with Intel Version 10.1 C++ compilers bemandawes 1682 path_traits needs imbue() bemandawes 1701 boost::filesystem::remove_all - segmentation fault with wpath on Linux bemandawes 1711 Boost Serialization export facility broken on gcc 4.1_ 4.2 bemandawes 752 directory_iterator doesn't work with catch chris_kohlhoff 1703 [asio] Compiler warnings on VC8/9 + warning level 4 danieljames 1554 When BOOST_HASH_NO_EXTENSIONS is defined hash doesn't support new string types. danieljames 1555 When BOOST_HASH_NO_EXTENSIONS is defined hash doesn't support boost::system::error_code danieljames 1705 [boostbook] Spaces in reference file names for types like 'long long' danielw 1044 Argument pack inaccessable in a functions return type danielw 1054 Parameter takes an "infinite" amount of time to compile with the Intel compiler. danielw 1097 keyword.hpp generates many warnings C4180: qualifier applied to function type has no meaning; ignored dave 1010 linking boost.python on freebsd dave 1019 iterator_facade::pointer should be the return type of operator-> (DR 445) dave 1085 Python rules for compiling in Mac OS X dave 1179 [boost.python] can not export a union in VC2005sp1 dave 1181 [boost.python] can modify enum value dave 1387 Review / update docs to reflect changes dave 1460 Python classes with multiple bases are convertible only to the first class in the lists dave 1482 boost::python::throw_error_already_set should be marked noreturn dave 1516 [python] Failing VC9 regression tests dave 1599 [python] '_set_se_translator': identifier not found dave 1697 [utility][noncopyable] ADL barrier broken by msvc-9.0 dave 1730 No debug libs on Windows by default dave 865 Use of C++0x keyword as identifier dave 910 gcc strict-aliasing problems with python dgregor 1009 Improper overflow handling in shortest paths algorithms dgregor 1164 Floyd Warshall broken with unsigned edge weights dgregor 1192 [boostbook] problem when two files have the same name dgregor 1199 configure doesn't work with path containing whitespaces (MacOS X) dgregor 1310 [result_of] const-qualified function pointer doesn't work dgregor 1326 Unable to check graph isomorphism using LEDA adapter dgregor 1391 dominator_tree_test on Borland/CodeGear outputs overly long line dgregor 1395 Write Tests for Python Bindings dgregor 1630 gcc-4.3: adjacency_list.hpp includes deprecated header dgregor 1680 long long and wchar_t support in MPI dgregor 556 Bundled graph properties dgregor 732 Johnson All-Pairs needs better "no path" information dgregor 736 Const correctness violation djowel 1170 Emit Warnings instead of # symbols in the syntax highlighter djowel 1171 Quickbook title output djowel 1172 non-utf djowel 1176 Space after inline code djowel 1206 Escaping from within code? djowel 1273 CR+LF newlines in position_iterator djowel 1276 spirit problem with _GLIBCXX_DEBUG djowel 1277 Closing section like [pre with } causes Quickbok to crash djowel 1280 sections in imported source files get put inside <para> elements in docbook output djowel 1281 Quickbook produces invalid BoostBook/DocBook XML djowel 1324 tuple should have a swap() that operates element-by-element djowel 1396 wrong result_of invocation around transform_view djowel 1436 [quickbook] inline code inside headings djowel 1484 Quickbook produces illegal docbook for some docinfo fields. djowel 1500 [Spirit/Phoenix] C4512 Compiler warnings from VC8 djowel 1570 Some boost headers aren't ready for gcc 4.3 djowel 1600 duplicate include guard djowel 1601 distane of boost::tuple djowel 1607 Tuple Library Documentation Changes djowel 1610 [MSVC/STLport] [tree/common.hpp] Standard library requirements violation(incomplete type as vector parameter) djowel 1614 vector workaround needed for MSVC9 djowel 1617 spirit gcc-4.3 fix djowel 1619 [Fusion] C4512 warnings from VC9 (Visual Studio 2008) djowel 1722 [TR1/Fusion] Conflict between TR1 and Fusion headers dlwalker 613 boost/crc.hpp uses non-standard conforming syntax doug_gregor 1021 [Graph][reverse_graph] Problem using reverse_graph adapter with an adapted user defined graph doug_gregor 1076 compile error: disconnecting struct with operator()() doesn't work in VS2005 SP1 doug_gregor 375 LEDA graph adaptors do not handle hidden nodes properly doug_gregor 402 random_vertex/random_edge are unnecessarily inefficient doug_gregor 403 Document copy_component doug_gregor 447 reverse_graph and constness of property maps doug_gregor 708 Dijkstra no_init version should not require VertexListGraph doug_gregor 733 Numbered headers don't work with "preferred" syntax doug_gregor 735 Fruchterman-Reingold grid performance can be improved doug_gregor 738 Memory leaks with signal::connect? doug_gregor 829 Implicit graph not implement doug_gregor 852 Problem with Boost and GCC 4.1 ebf 1507 [variant] C4512 warnings from VC8.0 ebf 1548 [variant][docs]typo: formal arg_ operand_ should be v in times_two arglist ebf 1654 recursive variants do not handle nested variants correctly. ebf 993 Variant should use least common multiple of alignments_ rather than maximum fcacciola 1666 Visualizer for boost::optional garcia 1581 Boost.MultiArray: Resizing bug if the index is not 0-based grafik 1041 Cygwin requires PATH setting. grafik 1322 trac rejects patch attachment as spam grafik 1417 Regresson tests hang in Darwin (Tiger) grafik 1430 Regression fails under Cygwin grafik 1433 Trac's spam detection rejects too many valid messages grafik 1512 Broken link to vacpp in bjam docs. grafik 1513 Broken link to bcpp in bjam docs. grafik 1576 cannot read non-ASCII output messages grafik 1577 Some commands don't work because hStdInput == 0 grafik 1663 build.bat cannot set/reset ERRORLEVEL grafik 1731 Website 'bugs' grafik 1733 Website layout overlays on IE7 grafik 1735 [website] Wrong HTML on main documentation page. grafik 1738 Boost Jam details and download link grafik 1739 Search box and Google link grafik 1741 Review schedule out of date grafik 1742 Some bugs in http://www.boost.org/doc/libs/1_35_0 grafik 1753 Python docs: bad link to the Jamroot grafik 616 Boost Jam_ and non english directorys grafik 959 linking fails when Boost is compiled with STLport 5.1.* on Linux (names mismatch) grafik 986 Problem building Python modules on boost 1.34.0 hkaiser 1079 boost-1.34.0 fails to compile. concept checks not satisfied. hkaiser 1670 wave almost unusably slow on real-world input igaztanaga 1080 boost::interprocess win32 global file mapping issue igaztanaga 1210 interprocess::barrier hangs during second use under linux (boost 1.33.1) igaztanaga 1390 Interpocess: managed shared memory failing completely under OS X igaztanaga 1634 boost::interprocess::vector cannot contain volatile int igaztanaga 1635 Incomplete include guard in boost/intrusive jmaurer 351 Diff in state of mersenne_twister gen between GCC3.41 & CW9 jmaurer 599 uniform_01 copies engine instead of using a reference johnmaddock 1081 Empty string rejected as perl-style regex johnmaddock 1411 Fix BOOST_PARTIAL_SPECIALIZATION_EXPLICT_ARGS johnmaddock 1446 POSIX API doesn't use C locale johnmaddock 1451 error: use of C99 long long integer constant johnmaddock 1749 regex_match on filesystem iterator.leaf () leads to strange results in what[] jsiek 1531 segfault in dynamic_bitset::reference assign operator jsiek 1540 Poisson distribution very slow for large mean (and may also overflow). jsiek 1755 Boost.tokenizer is broken for wide characters - patch attached jsiek 575 Calling subgraph::global_to_local on a root graph jsiek 636 strange compiling problem for transitive_closure jsiek 815 remove_edge core dumps on self-circle jsiek 875 No iterator based constructor for adjacency_matrix jsiek 900 graphml reader namespace handling is broken kaalus 1184 property_tree assignment (operator) bug kaalus 1604 property_tree xml parser doesn't compile with gcc kaalus 1678 Boost.property_tree::read_xml does not parse UNICODE file with BOMs marshall 1252 [pool] severe overhead with unaligned sizes. matias 1406 Understanding the Tables outdated matias 1651 incorrect typedefs in examples matias 1676 Dead links on Boost.Test example documentation. matias 1707 small typos in Boost.serialization documentation matias 1727 Sample code in documentation does not compile_ has namespace errors. matias 1743 Documentation has incorrect Build & Link settings for some libraries nasonov 1220 lexical_cast requires RTTI nasonov 1704 [any] 4512 warning from VC8/9 on warning level 4 nasonov 754 boost::any - typeid comparison across shared boundaries nesotto 1629 range/iterator_range.hpp bug nesotto 1675 [range] VC8 - compiler warnings when including range/array headers nesotto 1694 NDEBUG vs. BOOST_ASSERT in iterator_range.hpp nesotto 1748 [ptr_container] compiler warnings from VC9 nesotto 1754 Illegal HTML in range docs. no-maintainer 1068 Mersenne twister disables streaming for Visual C++ no-maintainer 1222 lambda::ret<T> should declare result_type. no-maintainer 1270 uniform_smallint doesn't compile with lagged_fibonacci random number generators no-maintainer 1515 [lambda] C4512 warnings from VC8.0 no-maintainer 1544 uniform_01 w/ref template param causes ref to ref error no-maintainer 1546 Method boost::random::uniform_int::operator()(engine_ value) is missing no-maintainer 1572 [lambda] smart pointer const-ness affects its contents no-maintainer 1632 Default Interval rounding policies incomplete no-maintainer 1691 [Random] Brokem MSVC workaround no-maintainer 781 Lambda: (_1 + "y")(string("x")) Doesn't Compile no-maintainer 819 uniform_int<> with type's maximum availaible range error pavol_droba 1152 rle_example fails pavol_droba 1385 begin must be boost-qualified pdimov 1106 shared_ptr<T> should not convert to shared_ptr when T* doesn't convert to U* pdimov 1719 [addressof] Can't obtain the address of an instance of an anonymous struct ramey 1285 [serialization] problem when including shared_ptr_132.hpp ramey 1708 Can't serialize class with private destructor ramey 1734 BOOST_STATIC_WARNING can't be passed a dependent expression ramey 1747 [serialization] unreferenced formal parameter warnings from VC9 rogeeff 1383 signal.h features not found on Mac OS rogeeff 1542 [test] compiler errors when building with stdcxx library rogeeff 1723 No subprocess can be started in init_unit_test_suite rogeeff 1746 Online documentation for 1.35.0 is out of date for current lib version samuel_krempp 1699 Compile warning about initialization order. samuel_krempp 859 boost::format ignores a user defined locale shammah 290 perfomance: memory cleanup for pool takes too long shammah 386 boost::pool_allocator breaks with vector of vectors speedsnail 1138 Problems with TSS and static thread library t_schwinger 1653 wave executable erroneously required for build of function_types lib turkanis 1523 [iostreams] VC8/VC9 compiler warnings turkanis 1545 [boost/rational.hpp] 'noskipws' is not a member of 'std' turkanis 1579 gzip compressor should model DualUseFilter turkanis 1580 Add static assert to prohibit instantiating a chain with mode dual_use turkanis 1649 Fix definition of JavaScript menu to avoid long chains of functions turkanis 1656 Consider implementing flush() for symmetric filters turkanis 1671 type mismatch of buffer size parameter causes overload resolution to fail turkanis 1757 Online docs have lost the menu contents in the left frame of the page urzuga 574 [boost::lambda] Compile error with libstdc++ debug mode vladimir_prus 1132 program_options documentation error. vladimir_prus 1165 more quoting problems vladimir_prus 1274 Useless error message vladimir_prus 1321 invalid docbook in tool documentation vladimir_prus 1527 [program_options] Second (and subsequent) lines in tabbed text not aligned correctly vladimir_prus 1530 Program options documentation - Overview - Syntactic Information example typo vladimir_prus 1537 no value given in 'mysql_password =' vladimir_prus 1584 cryptic bbv2 error building quickbook vladimir_prus 1587 [program_options] crashes if value part missing in external configuration file vladimir_prus 1588 [program_options] crashes if value part missing in external configuration file vladimir_prus 1645 Invalid unicode support for default_value vladimir_prus 1679 added 4-way universal binary support from mac osx (ppc_ ppc64_ i386_ x86_64) vladimir_prus 469 multitoken broken vladimir_prus 689 [program_options] Endless loop with long default arguments vladimir_prus 850 program_options strips off escaped quotes in some situations witt 1046 Boost.Python quickstart instructions mention nonexistent target witt 583 Fixes for build on IBM pSeries for AIX and Linux witt 834 Homepage regression links witt 957 The "Getting Started" page does not mention the stdlib option witt 973 zip_iterator has value_type == reference -- -- Marshall Marshall Clow Qualcomm, Inc. <mailto:mclow@qualcomm.com> The famous British scientist, Lord Kelvin, said: "When you measure what you are speaking about and express it in numbers, you know something about it, but when you cannot (or do not) measure it, when you cannot (or do not) express it in numbers, then your knowledge is of a meagre and unsatisfactory kind."

1 0

[thread] Interest in a locking pointer and lockable concept
by klaus triendl 03 Apr '08

03 Apr '08

Hi, is there any interest in something like a locking pointer and a type that I call "lockable" that pairs any type with a mutex? Inspired by Andrei Alexandrescu's article "volatile - Multithreaded Programmer's Best Friend" on ddj I implemented a concept similar to a locking pointer called "lock_acquirer" that collects acquisition of a mutex and a volatile cast of the locked type. It is even more threadsafe to use than a locking pointer. Additionally I made a class "lockable" that pairs a (volatile) type with a mutex type, wrapping both in a distinct type, which has first the advantage that the type to protect and the mutex are glued together, and second that it encapsulates volatile qualifier correctly. Also, the locked type in a lockable can, if wanted, by a restricted interface only be accessed by a lock_acquirer thus forcing the programmer to a very threadsafe programming style. I can post my implementation along with a simple example to the boost vault. Klaus

6 25

Regression in Multi-index, 1.35?
by Amit 03 Apr '08

03 Apr '08

Hi, I am trying to migrate my project to 1.35. The following used to compile and work with 1.34.1: bmx::multi_index_container<wstring, bmx::indexed_by<bmx::ordered_unique<bmx::identity<wstring> >, bmx::random_access<> >, boost::fast_pool_allocator<wstring> > But refuses to compile with 1.35 (I use Intel compiler 10.1 with MSVC7.1 STL). Something to do with allocator rebind. I am including some of the compiler output below. Can someone please suggest a resolution (hopefully keeping the pool allocator intact)? Thanks Amit C:\DevLibraries\Boost\include\boost-1_35_0\boost/pool/pool_alloc.hpp(130): error: reference to void is not allowed typedef value_type & reference; ^ detected during: instantiation of class "boost::fast_pool_allocator<T, UserAllocator, Mutex, NextSize> [with T=void, UserAllocator=boost::default_user_allocator_new_delete, Mutex=boost::details::pool::default_mutex, NextSize=32U]" at line 149 of "C:\Boost\include\boost-1_35_0\boost/detail/allocator_utilities.hpp" instantiation of class "boost::detail::allocator::rebinder<Allocator>::result<Type> [with Allocator=boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>, Type=boost::multi_index::detail::random_access_index_node_impl< boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>>]" at line 158 of "C:\Boost\include\boost-1_35_0\boost/detail/allocator_utilities.hpp" instantiation of class "boost::detail::allocator::compliant_allocator_rebind_to<Allocator, Type> [with Allocator=boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>, Type=boost::multi_index::detail::random_access_index_node_impl< boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>>]" at line 62 of "C:\Boost\include\boost-1_35_0\boost/mpl/eval_if.hpp" instantiation of class "boost::mpl::eval_if_c<C, F1, F2> [with C=false, F1=boost::detail::allocator::partial_std_allocator_rebind_to< boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>, boost::multi_index::detail::random_access_index_node_impl< boost::fast_pool_allocator<void, boost::default_user_allocator_new_delete, boost::details::pool::default_mutex, 32U>>>,

4 4

Re: [boost] Review Request: Generalization of the Pimpl idiom
by Vladimir.Batov＠wrsa.com.au 03 Apr '08

03 Apr '08

... > > That requirement to have > > > > Derived1::Derived1(implementation*) > > > > is unreasonable as it is clearly not related to to the Derived1 *public* > > interface. On the other hand reset()-based approach works fine and scales > > fine. > > > > ... > > I understand now. This will force to add an artifial *protected* constructor > to > Derived1. Do you really think that this is a real problem for the developer > of Derived1? > If I understand your library forbids this to the developper because > pimpl_base do not have the following protected constructor. > pimpl_base (implementation* impl) : impl_(impl) {} > > I think that this will be a good adding to the pimpl_base class. Respectfully I have to disagree. The reason is that it has been long established precedent in C++ not to provide alternative mechanisms/tools/interfaces if the existing already does that. An immediate example OTOH is that an introduction of "superclass" keyword was rejected because a typedef would do the same thing. Granted, tediously and not as elegantly but still. Here IMHO it's the same story -- we are not talking about missing functionality but rather questionale interface sugar-coating which BTW requires the user to do more than he really have to ("force to add an artifial *protected* constructor"). ... > > I am not sure what that is supposed to demonstrate. You use infrastructure > > to help you to do your job. If you decide that the infrastructuere does > > not help you and discard that, you'll obviously have to re-implement > > whatever functionality from that infrastructure you managed to deploy. If > > one uses std::list and then for whatever reason goes ahead with his own > > list implementation or merely swaps it for std::vector, he'll likely to > > face the same issue. Trade-offs of the pimpl idiom are well-known -- > > another indirection and memory allocation. In the end, one can deal with > > memory-allocation by writing a custom allocator for > > pimpl<Foo>::implementation. > > If pimpl is here to hide the implementation, why it needs to extends the > interface of the initial class? > Why the user of my class should suffer from the trade-offs of the pimpl > idiom at the inteface level? Pimpl extend the interface so that the user does not have to provide those methods. Like comparison and validity check, etc. That does not come at the user's expence and, therefore, how exactly the user suffers from that escapes me. > >> Do you really think that the pimpl idiom is helping me to hide my > >> implementation. If I want to hide my implementation I need to restrict > > to > >> private inheritance. > > > > I cannot say about you but I do really think that the pimpl idiom is > > helping me to hide the implementation. Private inheritance restricts > > access but not hides the implementation. > > I was talking about private inheritance from pimpl!!! If you try deploying pimpl in applications, you'll quickly see that you'll need public inheritance. I do. Having said that, if you insist on inheriting privately, there is nothing stopping you. We are not discussing missing pimpl functionality or crooked implementation, right? > > struct Base { int k; }; > > class Derived : Base {} > > > > Here Base::k is not accessible in Derived but not hidden. More, if that > > stuff is a commercial library, I can easily circumvent that restriction by > > modifying Derived declaration. Pimpl really hides the implementation. See > > for more about the idiom > > > > 1. Guru of the Week #24. http://www.gotw.ca/gotw/024.htm > > 2. Herb Sutter. Exceptional C++ (Addison-Wesley, 1999) > > 3. J. Carolan. Constructing bullet-proof classes. In Proceedings C++ at > > Work'89 (SIGS Publications, 1989) > > 4. James O. Coplien. Advanced C++ Programming Styles and Idioms > > (Addison-Wesley, 1992) > > 5. Eric Gamma et al. Design Patterns (Addison-Wesley,1995) > > This is why I suggested to remove the null object and bool type conversion > operators for pimpl<A>::value_semantics. Maybe it will be a good idea to > give them protected acces. I admit that "This is why" escpes me. Invalid objects are all over -- nullptr, shared_ptr(), -1, etc. Pimpl extends that concept onto actual classes and gives it uniform and proper implementation. I've been using this extensively and I do indeed need that... public. If one does not need that, he won't use that. That feature won't kick in by accident. > >> Once we remove the public inheritance from pimpl, it is not eassy to > >> implement all these extra functions and operators. > > > > Then do not remove public inheritance. I am far from being convinced that > > insistence on private inheritance is justified. > > Conveinced or not this is a way to mask the pimpl functions, and it seams to > me the best way to use pimpl<A>::value_semantics. This is not the case with > pimpl<A>::pointer_semantics from which it is better to inherit publically > giving acces to the null object and the bool type conversion operators. > This is only a comment on how I will use it :-) Yes, that makes sense. Although if my usage experience is of any guidance, you'll swap private for public fairly soon. I guess, we'll see. ... > >> >> Could we inherit publicly from A and privatly from pimpl<B, > >> >> A>::value_semantics? > >> > > >> > Cannot comment on this one as I am not convinced we need that (see > > above). > >> Imagine A3ppClass is a 3pp class ( we can not modify it), and before > > using > >> the > >> your pimpl class we had: > >> > >> class MyClass : public A3ppClass {}; > >> > >> How can we use pimpl without changing the interface of MyClass, neither > >> adding nor removing any function? > >> > >> May be we can resume: do not use the pimpl library is you can not master > > the > >> complete inheritance hierarchy. ... > In any case I don't see a real benefit of using pimpl when the base class is > 3pp class and we can not change it. Well, if you build a run-time polymorphic hierarchy on top of an existing 3rd-party base class, then I tend to agree with you as you have to follow the design and strategy outlined by the base class designer. I do not feel like it is a pimpl inherent weakness. Havind said that, I'd shy away from coming to your generic conclusion based on that particular case. Unless I have to write deep run-time polymorphic hierarchies (like Widgets, etc.), I tend to cut inheritance short and I believe it is the strong current programming trend in C++. Therefore, in your case I'd try pimpl<MyClass>::implementation : public A3ppClass {} then in MyClass I'd bridged to A3ppClass only the interface that MyClass needed: MyClass::foo() { (*this)->A3ppClass::foo(); } It might not be applicable in your particular case -- no one claims to have the silver bullet. ... > >> class A : private pimpl<A>::value_semantics {...}; > >> class B : private pimpl::value_semantics {...}; > >> class C : public A, public B {...}; > >> > >> May be we can resume: do not use the pimpl library if you need multiple > >> inheritance. > > > > I cannot see anything drastically wrong with the code above even though I > > probably would not do it that way. So, I'll have to disagree with your > > conclusion. > > Anyway, we will do the same, don't use pimpl with multiple inheritance. I would not say that I will not. If/when the time comes for me to deploy multiple inheritance, I cannot see myself hesitating because of the pimpl. ... > > I have to disagee as I find that view over-simplified and in fact > > incorrect. Pimpl or no pimpl in general no objects beyond value-semantics > > PODs can be safely (or without additional effort) put into shared memory. > > I hope so, and I expect that you will do what is needed to achiev this. I > tried only to help you. And it is much appreciated. > Pointers are emulated in Boost.Interprocess with the smart pointer > offet_prt. > You can yet have inheritance without virtual functions. Well, I would not insist on that without severe reservations, numerous ifs and buts. > Please, could you take a look to the Boost.Interprocess, Boost.Intrusive and > Boost.MultiIndex libraries. > Even if not standards they are portable. :-) Yep, had a quick look at boost.interprocess. Seems like it takes care of shared memory hasssle. Cool. I presume he managed it for UNIXes and Windows. Super cool. And I see boost.multiindex supporting boost.interprocess allocators. Now I get it. Still I do not feel like rushing to support the feature. :-) We'll get the bridge when we get there. I'll keep it iin mingd though. Thanks for your patience and insistence. You see, I not THAT thick after all. :-) > > Then, you'll have to provide custom allocators. The issue just > > keeps more and more complicated. Do you actually have that setting or we > > are talking hypothetically? If the former, then pimpl will not be your > > primary concern. :-) If it is the latter, then I find it too ephemeral to > > discuss effectively. > > I insist. This is not hypothesis. I have to manage a lot of data shared > between process, I use specific allocators, and synchronization mechanisms. > I wanted only to know if I can hide the implementation of this classes with > the pilm classes. That's all. OK, I see you need that. :-) It'll take me sometime to get up to speed with boost.interprocess. Worse, for various reasons I cannot use un-official boost. So, go and figure. > > If you do not have several processes accessing the same data and, > > therefore, do not care for inter-process data-access synchronization, > > inter-process vtbl pointer correction, etc., then I'd be wondering why you > > use shared memory in the first place. > > Who has said that I have no several process sharing the same data? No, you certainly did not say you did not have several processes. Have you noticed there was 'if' at the beginning of my sentence? :-) > But the data has no virtual functions. This is not a raison to don't want to > hide its implementation. Fair enough. You convinced me. Honestly, Unfortunately, or reasons beyond my influence I won't be able to extend pimpl support onto boost.interprocess in a short timeframe. Apologies. .. > Thank you very much for your time and good luck for your review. > I promise I'll try your library. Thanks for your input. Much appreciated. Thanks, Vladimir.

2 1

Removing copyright symbols from files.....
by Marshall Clow 03 Apr '08

03 Apr '08

Unless anyone objects, I am going to remove the copyright symbol "©" from source and header files (in response to support request #597). I will not touch anything that's not in a comment. ;-) It looks like about 37 header files, and 24 source files. I'll do this tonight, unless anyone objects. Example transformation: In file "boost/archive/detail/auto_link_archive.hpp", on line #12: // © Copyright Robert Ramey 2004 will become: // (c) Copyright Robert Ramey 2004 -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

3 5

[1.35] VC8 compiler bug makes boost spill types into global namespace, which breaks IntelTBB
by Marcus Lindblom 03 Apr '08

03 Apr '08

Hi all, This is with VC8 SP1. We tried to compile our app with boost 1.35.0 and got errors in Intel TBB that int32_t was already defined. After some debugging, we have boiled it down to the following repro case, which shouldn't compile. It compiles on VC8 but not on VC9. Just run cl on the following: ========================= namespace bzt { typedef long fiddle; } namespace foo { using namespace bzt; // removing using makes it work too class baz { public: virtual void meep() // removeingvirtual makes it fail { } }; namespace foobar { void geronimo() { throw baz(); } } // namespace foobar } // namespace foo fiddle dummy; // should not compile, but does ========================= For boost, the actual names used are namespace bzt = boost fiddle = int32_t foo = boost_132 baz = bad_weak_ptr meep = bad_weak_ptr::what foobar = detail geronimo = bad_weak_ref throw baz() = boost::throw_exception(bad_weak_ptr) and can be reproduced using boost code with simply: ========================= #include <boost/cstdint.hpp> #include <boost/detail/workaround.hpp> #include <boost/serialization/detail/shared_count_132.hpp> int32_t dummy; // Should not compile, but does. ========================= The function throwing is boost_132::detail::sp_counted_base::add_ref_lock() which does boost::throw: void add_ref_lock() { if(use_count_ == 0) boost::throw_exception(bad_weak_ptr()); ++use_count_; } Where bad_weak_ptr have a virtual function. I suppose a fix/workaround would be to not use the boost_132 namespace which imports boost. This is a pretty bad bug, so we're thinking of switching to VC9 to avoid this. Cheers, /Marcus P.S. Great work on getting Boost 1.35 out! We really appreciate all the effort spent and will try harder to find time to test the RCs at root these things out earlier. Hope this helps somewhat in improving boost though.

1 0

gsoc prposal
by Inosh Goonewardena 03 Apr '08

03 Apr '08

Hi, I have send a proposal to gsoc regarding the JSON Archives for Boost.serialization. I have attached my propsoal with this e mail

3 2

Re: [boost] GSoC Ideas: Optimizing Boost libraries for multi-core machines
by Cristianno Martins 02 Apr '08

02 Apr '08

Hi, >In my experience, there are very few instances where parallelism can be >usefully concealed behind a library interface. OpenMP has very high >overhead and will help only for very long-running functions -- at least >under Microsoft's compiler on x86 and x64 platforms. Right, but this is something that depends of the algorithm. For example, let's take the regular expression library implementation in Boost (Xpressive). Pattern matching is an expensive task and it's a kind of thing that comes in a library set like Boost. Researchers have tried parallelize regular expression matching ( http://ieeexplore.ieee.org/iel5/10901/34300/01636074.pdf) So, I guess there would be researches that are based on parallel libraries construction. >Algorithms that >are likely to be applied to very large datasets could have the OMP >pragmas inserted optionally but they would need to be protected by >#ifdef logic (or given distinct names) because otherwise the overhead >will destroy programs that make more frequent calls on smaller datasets. Ok, but the feasibility study of the parallel version of an algorithm should be a part of the parallelization task. Not all of the parallelizable tasks would be really interesting running in parallel. >Also consider that, in an application that is >already parallelized, there are no extra cores for the library to use >internally. Well, but what if the library is already parallelized? Maybe the extra task generated by parallelize the real application would be dispensable. >On a smaller scale, adding "vectorized" and/or "streaming >producer-consumer" interfaces for selected libraries may help a lot by >encouraging use of vector instruction / execution units, unrolling of >loops and improving instruction and data locality. This is a pretty good idea. Best, -- Cristianno Martins Mastering in Computer Science State University of Campinas cristianno.martins(a)students.ic.unicamp.br skype: cristiannomartins gTalk: cristiannomartins msn: cristiannomartins(a)hotmail.com

1 0

Re: [boost] GSoC Ideas: Optimizing Boost libraries for multi-core
by Cristianno Martins 02 Apr '08

02 Apr '08

Hello again, first of all, thank you for comments. That is certainly an interesting project. When you submit your GSoC > application, please identify exactly which library you plan to > parallelize with OpenMP, and which parts of that library you will > parallelize. > > - Doug Well, I enumerated three libraries that I could parallelize with OpenMP in the project. Therefore, I did't specify how I'd parallelize them, because (in the project) one of the tasks to be done after choose a library is to identify the bottlenecks. So, I thought I should do this at that moment. Furthermore, if I have opportunity to parallelize more than three libraries, it'll be necessary to do this step for the others libraries; so, why mustn't I do it for all of them? > Just a quick question. Wouldn't be TBB the better choice instead of > > OpenMP? > > > I can see good reasons for both options. TBB will make it easier to > implement task-oriented parallel algorithms, but it brings with it a > dependency on a non-Boost library. OpenMP is reasonably good at data > parallelism (and can require fewer changes to algorithms where it > applies), and depends on features available in many compilers, but it > isn't as widely applicable as TBB. I think you choice will be dictated > mainly by the library you choose, and how you think you will need to > parallelize that library. > > - Doug > The use of TBB is a really good idea, so I could parallelize each chosen library in Boost with the best library to that case (between OpenMP and TBB). What do you think about it? Best, -- Cristianno Martins Mastering in Computer Science State University of Campinas cristianno.martins(a)students.ic.unicamp.br skype: cristiannomartins gTalk: cristiannomartins msn: cristiannomartins(a)hotmail.com (rarely used)

1 0

[range] Proposal to add make_view
by Andrey Semashev 02 Apr '08

02 Apr '08

Hi, I propose to add a simple helper function to create an iterator range of boost::transform_iterators. This would effectively create a view over a different range or a container. Currently this is possible to do with considerable code duplication: make_iterator_range( make_transform_iterator(vec.begin(), fun), make_transform_iterator(vec.end(), fun)); Here "fun" could be a rather complex lambda or bind expression. What I propose is to wrap these calls into a simple generator make_view. The above code would look much better: make_view(vec.begin(), vec.end(), fun); or make_view(vec, fun); I've attached a sample implementation of the make_view function. Do you think this could be useful? #ifndef BOOST_RANGE_VIEW_HPP_INCLUDED_ #define BOOST_RANGE_VIEW_HPP_INCLUDED_ #include <boost/iterator/transform_iterator.hpp> #include <boost/range/iterator_range.hpp> #include <boost/range/begin.hpp> #include <boost/range/end.hpp> #include <boost/range/iterator.hpp> namespace boost { template< typename IteratorT, typename FunT > inline iterator_range< transform_iterator< FunT, IteratorT > > make_view(IteratorT const& begin, IteratorT const& end, FunT const& fun) { return make_iterator_range( make_transform_iterator(begin, fun), make_transform_iterator(end, fun)); } template< typename RangeT, typename FunT > inline iterator_range< transform_iterator< FunT, typename range_iterator< const RangeT >::type > > make_view(RangeT const& range, FunT const& fun) { return make_view(begin(range), end(range), fun); } } // namespace boost #endif // BOOST_RANGE_VIEW_HPP_INCLUDED_

4 5

#pragma warning (dsiable : 4996) ineffective?
by Roland Schwarz 02 Apr '08

02 Apr '08

I have seen some attempts from library authors, e.g. boost/thread/win32/conditiona_variable.hpp to get rid of the annoying MSVC warnings. However this seems not to work (at least on my machine). There seems to be some unintended interdependence with _SCL_SECURE_NO_DEPRECATE. I was not able to find out what exactly is causing the warnings not go away. Hoever, compiling with _CRT_SECURE_NO_DEPRECATE and _SCL_SECURE_NO_DEPRECATE quiets the build. Couldn't this issue be handled by the boost config headers? Is this something wrong with my setup only, or do others experience the same problem? Thank you, to anyone who cares. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

6 7

[1.35] Documentation of Boost.Range incomplete
by Boris 02 Apr '08

02 Apr '08

The webpage http://www.boost.org/doc/libs/1_35_0/libs/range/doc/range.html is empty (or missing?). I got there by clicking on a range concept at http://www.boost.org/doc/libs/1_35_0/libs/range/index.html. Boris

2 2

Re: [boost] CORBA iimplementation for Boost interest?
by Stefano Delli Ponti 02 Apr '08

02 Apr '08

(Duplicated post, the previous one was not complete - sorry) Hello Jon, Jonathan Biggar wrote: > I've been working on a C++ CORBA implementation for a long time. I've > considered making it open source in the past, but I hadn't seen the > exact niche for it to fill. > > Now that Boost 1.35 is out, including ASIO and the new Threads > implementation, I'm considering retargeting my implementation to only > use boost libraries for underlying services. > > I'd be quite happy to contribute my implementation to boost, if there's > enough interest for me to proceed. > > So, what do you all think? > That's wonderful! (I am so happy also because I know, being a long-time CORBA user, the expertise of Jonathan and his contributions to the standard). Some considerations: - I think that many on this list underestimate the importance that CORBA has still today. For large client-server/distributed applications there aren't yet many valid alternatives. - The main benefit of CORBA is its cross-platform, cross-language nature: our C++ distributed application is accessible through C++, Java, Python, COM, .Net in Solaris, Windows, Mac OS X and Linux. - There are very good open-source implementations, like TAO and OmniORB, with great support facilities. - The main drawback of CORBA is probably its awkward C++ binding (as Jon said, there were many /historic/ reasons). I know that an effort for a new binding began some months ago at OMG: I am not updated on that one. TAO is a robust implementation based on ACE. ACE is a large C++ framework, which implements many network-related pattens. Boost is now entering the ACE's territory with a much more modern C++ perspective but it still lacks many features (waiting for pion-net/cpp-netib, log et al.). But, as Jon said, Boost has now the functionalities needed to build an ORB. I see many benefits about a Boost ORB: - A modern C++ implementation - A place to experiment with new bindings and other things - A large piece of code that reuse and test a lot of other Boost libraries I would use such a beast immediately on the client-side. So, let's do it. I would be glad to contribute. Regards, Stefano

2 1

[thread] Missing initializer warnings from gcc in 1.35.0
by Colin Caughie 02 Apr '08

02 Apr '08

I just tried moving to 1.35.0 (from 1.34.0) and am getting the following warnings: /usr/local/boost/1.35.0/x86/include/boost-1_35/boost/thread/pthread/ timespec.hpp: In function 'timespec boost::detail::get_timespec(const boost::system_time&)':/usr/local/boost/1.35.0/x86/include/boost-1_35/boost/ thread/pthread/timespec.hpp:18: warning: missing initializer for member 'timespec::tv_nsec' /usr/local/boost/1.35.0/x86/include/boost-1_35/boost/thread/xtime.hpp: In function 'boost::xtime boost::get_xtime(const boost::system_time&)': /usr/local/boost/1.35.0/x86/include/boost-1_35/boost/thread/xtime.hpp:59: warning: missing initializer for member 'boost::xtime::nsec' We compile with -Wall and -Werror, and would like to continue doing so. Anyone know of a way of suppressing this warning? We're using gcc 4.1 and 4.2.1. Thanks, Colin

3 2

Re: [boost] Review Request: Generalization of the Pimpl idiom
by Vladimir.Batov＠wrsa.com.au 02 Apr '08

02 Apr '08

> >> Base::Base(int k) : base(new BaseImpl(k)){} > >> Derived1::Derived1(int k, int l) : Base(new Derived1Impl(k, l)) > > > > No, this initialization method is not allowed. One needs to use reset() > > instead as you show below. I considered the syntax above and rejected it > > on the grounds that it does not add new functionality (as reset() already > > does that) and it is not generic enough as it won't work for "Derived2 : > > public Derived1" > > Why this syntax could not work? Could you elaborate more? For that syntax to work with a hierarchy every class needs to explicitly declare a constructor taking "implementation*". That is, in the following hierarchy Base : pimpl<Base> {} Derived1 : public Base {} Derived2 : public Derived {} pimpl, Base and Derived1 need to have those mentioned constructors so that the following could work Derived2::Derived2(int) : Derived1(new Derived2Implementation()) { } That requirement to have Derived1::Derived1(implementation*) is unreasonable as it is clearly not related to to the Derived1 *public* interface. On the other hand reset()-based approach works fine and scales fine. ... > > I cannot think of any particular implementation constraints > > Imagine that after using the your pimpl class which will do an extra > allocation, and due to performance I need to come back to a traditional > class. If my class inherits publicaly from pimpl I will need to provide the > same interface as when using the pimpl class. > > Before > class A : public pimpl<A>::value_semantic ... > > After > class A { > public: > // needs to implement publicaly the null function, bool_type operator, > // and the ! operator. > protected: > // needs to implement all the protected part inherithed from > pimpl<A>::value_semantic > > } I am not sure what that is supposed to demonstrate. You use infrastructure to help you to do your job. If you decide that the infrastructuere does not help you and discard that, you'll obviously have to re-implement whatever functionality from that infrastructure you managed to deploy. If one uses std::list and then for whatever reason goes ahead with his own list implementation or merely swaps it for std::vector, he'll likely to face the same issue. Trade-offs of the pimpl idiom are well-known -- another indirection and memory allocation. In the end, one can deal with memory-allocation by writing a custom allocator for pimpl<Foo>::implementation. > Do you really think that the pimpl idiom is helping me to hide my > implementation. If I want to hide my implementation I need to restrict to > private inheritance. I cannot say about you but I do really think that the pimpl idiom is helping me to hide the implementation. Private inheritance restricts access but not hides the implementation. struct Base { int k; }; class Derived : Base {} Here Base::k is not accessible in Derived but not hidden. More, if that stuff is a commercial library, I can easily circumvent that restriction by modifying Derived declaration. Pimpl really hides the implementation. See for more about the idiom 1. Guru of the Week #24. http://www.gotw.ca/gotw/024.htm 2. Herb Sutter. Exceptional C++ (Addison-Wesley, 1999) 3. J. Carolan. Constructing bullet-proof classes. In Proceedings C++ at Work'89 (SIGS Publications, 1989) 4. James O. Coplien. Advanced C++ Programming Styles and Idioms (Addison-Wesley, 1992) 5. Eric Gamma et al. Design Patterns (Addison-Wesley,1995) ... > Once we remove the public inheritance from pimpl, it is not eassy to > implement all these extra functions and operators. Then do not remove public inheritance. I am far from being convinced that insistence on private inheritance is justified. ... > >> class A; > >> > >> class B : A, public pimpl::value_semantics {...} > >> > >> How the B implementation has access to A? > > > > I am not sure it is a good (from pimpl perspective) design. Pimpl is about > > separation of interface and implementation and implementation hiding. By > > inheriting from A we just threw all that out the window. So, doing that > > for B implementation does not seem to have much value. Having said that, > > if one indeed needs access to A inside B implementation, then keeping B* > > inside B implementation seems to solve the problem. With regard to > > handling polymorphic hierachies the Bridge description from GoF would be a > > good start. That'll be fully applicable to the proposed pimpl. > > Keeping a A* inside B implementation will complicate a bit the B > implementation, isn't it? It depends. Even if it does, it'll be truly just a bit. > >> maybe we need something like that > >> > >> class B : public pimpl<B, A>::value_semantics {...} > >> > >> making the implementation of B inherit from A. > > > > "making the implementation of B inherit from A" is > > > > struct pimpl::implementation : public A > > { > > } > > > > That certainly makes sense (to me anyway). > > How do you ensure this way that B inherits from A? It feels like you want two separate hierarchies -- for interface and implementation. The application of the Pimpl idiom to polymorphic class hierarchies is well described in the "Bridge" section of GoF. > >> Could we inherit publicly from A and privatly from pimpl<B, > >> A>::value_semantics? > > > > Cannot comment on this one as I am not convinced we need that (see above). > Imagine A3ppClass is a 3pp class ( we can not modify it), and before using > the > your pimpl class we had: > > class MyClass : public A3ppClass {}; > > How can we use pimpl without changing the interface of MyClass, neither > adding nor removing any function? > > May be we can resume: do not use the pimpl library is you can not master the > complete inheritance hierarchy. I am not sure how relevant it is to the technical side of things. We are not in a legal profession where for legal reasons they write "may contain traces of nuts" on a packet of nuts. I see infrastructure as providing a service. Decision about applicability of that service for a particular situation is application developer's responsibility. I dot thin the time of the infrastructure developer will be well spent trying to think of every situation where his code *cannot* be used. > >> Can we manage with multiple inheritance? > >> class A : public pimpl<A>::value_semantics {...}; > >> class B : public pimpl::value_semantics {...}; > >> class C : public A, public B {...}; > > > > Sure... with all the relevant multiple-inheritance perks/drawbacks. > > Imagine that I have up to now > class A; > class B; > class C : public A, public B {}; > > and that I have no problems with multiple-inheritance because I have no > common class on the inheritance hierarchy (even if I don't like it very > much). > Now I'd like to use your pimpl classes and now a found a common class, or > atleast some common functions or operators. Does it means that again I need > to > use private inheritance. Yes, I understand what you describe and 'no' I do not think it'll be an issue. And, no, again, in my view private inheritance does not help you one bit. (Just admit you like "her", don't you. :-) ) > > class A : private pimpl<A>::value_semantics {...}; > class B : private pimpl::value_semantics {...}; > class C : public A, public B {...}; > > May be we can resume: do not use the pimpl library if you need multiple > inheritance. I cannot see anything drastically wrong with the code above even though I probably would not do it that way. So, I'll have to disagree with your conclusion. > >> How pimpl interacts with STL containers? > >> > >> stl::list<A> al; > >> B b; > >> al.push_back(b); > >> // ...somewhere else > >> A a =al.pop_back(); > >> > >> How 'a' should behaves? like a A or like a B? > > > > I presume > > > > struct A : pimpl<A>::... {} > > struct B : public A {} > > > > Then the result depends if A is of value_semantics or pointer_semantics. > > With pointer_semantics it behaves as, say, boost::shared_ptr would behave. > > Otherwise, during copying B part will be chopped off. So, "A a" will > > behave as A. > > OK, I have missed that. Does it means that only pimpl<A>::value_semantic > is sustitable for a class which was already used with STL containers? No, it does not. I am overwhelmingly using pimpl::pointer_semantics and those are happily in various containers. And those objects behave polymorphically because they have pointer semantics. If it is not the desired behavior, then value_semantics should be used instead. It is up to the class designer to decide. > >> The STL container user that > >> shouldn't knowns nothing about A implementation, expect that it will > > behaves > >> as a A, but it think that 'a' will behaves like a B. How can we protect > > from > >> this situation? > > > > I probably do not understand something as I still do not see what it is to > > protect from. A pimpl-based class behaves as any ordinary class (as it is > > in fact an ordinary class). > > > > May be we can resume: do not use the pimpl pointer semantics if your class > has value semantics. Well, I probably can agree with this conclusion... although I am temped to argue that in that case we'll have to put similar "warnings" everywhere. Like "do not use knife when you actually need a spoon", etc. > > In order to understand better your purpose: > * Could you give an example in which the object has value semantics and the > implementation pointer semantics? > * Could you give an example in which the object has pointer semantics and > the implementation value semantics? Private implementation does not have any particula semantics. It is the interface (pimpl-derived) class who has pointer_ or value_semantics... meaning how it treats the implementation -- aloows to share it or copies it. > > >> Could we store a non polymorph pimpl object in shared memory? > >> Could we store non polymorph pimpl objects in a container in shared > > memory? > > > > I am not convinced these special cases require anything from the pimpl. > > Although these certainly need more effort from the developer. Issues and > > means to deal with those seem to be the same as if one tried to store a > > pointer or std::auto_ptr or a boost::shared_ptr in shared memory. Given > > it's all in the developer's hands (implementation can be allocated > > explicitly and then associated via reset()) it'll be the developer's pain. > > This seems to be merely part of overall painful experience of dealing with > > shared memory. :-) > > You are right, auto_ptr and shared_ptr do not work on shared_memory. The > difference is that as you state a pimpl is not a pointer, and so we should > not suffer from the pointer liabilities. When a user use std::auto_ptr or > boost::shared_ptr he knows that there are some pointers not too far. In the > case of the pimpl the user has nothing to be with the pimpl classes and its > pointers. I have to disagee as I find that view over-simplified and in fact incorrect. Pimpl or no pimpl in general no objects beyond value-semantics PODs can be safely (or without additional effort) put into shared memory. > Imagine that you are using a class A in shared memory and even a container > of A in shared memory and you want now to use your pimpl class to hide the > implementation of A. What I can do? Shared memory is a delicate area. It's like embedded programming where not all language resources are readily available. If your A class can live in shared memory, then it is essentially a POD. Say, consisting of a few integers, no pointers, no inheritance. Otherwise, two processes cannot access/manipulate that same object in shared memory (not easily anyway). Still, those processes must have access synchronization issues resolved. More so, you mention a container in shared memory. Is it a standard container? Then, you'll have to provide custom allocators. The issue just keeps more and more complicated. Do you actually have that setting or we are talking hypothetically? If the former, then pimpl will not be your primary concern. :-) If it is the latter, then I find it too ephemeral to discuss effectively. If you do not have several processes accessing the same data and, therefore, do not care for inter-process data-access synchronization, inter-process vtbl pointer correction, etc., then I'd be wondering why you use shared memory in the first place. > Do not forget that you have two pointer member? > > template<class Interface> > template<class Implementation> > class pimpl<Interface>::impl_ptr > { > ... > traits const* traits_; > Implementation* p_; > }; > > May be you need to add some policies to your class in order to manage with > this (see for example void_pointer in Boost.Intrusive)? > > May be we can resume: pimpl library can not be used for classes that can be > stored in shared memory (atleast in his current state). Well, again I am not sure we should rush with conclusions based purely on hypothetical assumptions without trying. I admit I did not try using pimpl with shared memory as I do not use shared memory these days. It's almost not portable, limiting, hard to handle, and most (all?) of the time is better implemented as a multi-threaded app anyway. > > >> I hope that you will find good solutions to these problems. > > > > So, do you find my answers to your satisfaction? > > > > Not completly, but I hope that this discusion will serv to construct a > better > pimpl library or atleast to show the limits where this library is not really > adequated. Well, I certainly biased :-) but I am trying to keep an open mind and so far I do not see anything that I'd consider as a limitation. Call me a stubborn nut if you like. ... > The question is, can we subtitute a class A by a class A : public > pimpl<A>::xxx_semantics? I think that it will be better to restrict the null > object and the bool type operator to the pointer semantics. > > What do you think? I consider value- or pointer-semantics to be the behavior when null() is clearly a functionality. They are very much orthogonal to each other. Foo::null() clearly declares an invalid (unusable) object regardles of its semantics. I see value in it. If one does not need that functionality, he probably won't use it. As simple as that. I did not hear compellling arguments *not" to provide that functionality for value-semantics classes. Thanks, Vladimir.

2 1

type_with_alignment.hpp VC8 error
by Ralf W. Grosse-Kunstleve 02 Apr '08

02 Apr '08

Hi, svn revision 43952 broke my VC8 build: C:\AUTOBU~1\sources\boost\boost/python/converter/as_to_python_function.hpp(21) : error C2719: 'unnamed-parameter': formal parameter with __declspec(align('8') ) won't be aligned The compilation command is attached. Ralf cl /nologo /D_SECURE_SCL=0 /D_CRT_SECURE_NO_DEPRECATE /wd4996 /Zm800 /MD /GR /EH sc /DBOOST_DISABLE_THREADS /DNDEBUG /Ox -DBOOST_ALL_NO_LIB -DBOOST_PYTHON_MAX_ BASES=2 /IC:\AUTOBU~1\sources /IC:\AUTOBU~1\sources\boost /IC:\AUTOBU~1\build\ base\python\include /c C:\AUTOBU~1\sources\boost_adaptbx\optional_ext.cpp /Fob oost_adaptbx\optional_ext.obj

5 5

BoostCon'08 Early Registration Deadline
by David Abrahams 02 Apr '08

02 Apr '08

Reminder: early registration for BoostCon'08 closes Monday, April 7. It's still not too late to avoid the late registration fee for what may be the finest C++ event of 2008. For the 2nd annual Boost C++ libraries conference, we've put together a fantastic program crowned by a keynote address from Bjarne Stroustrup. In addition to existing Boost libraries, we're covering technology of interest to any C++ developer trying to stay on the cutting edge, including hands-on sessions with features from the upcoming 2nd version of the C++ standard. This year we've also added a collection of short "author's corner" sessions for those of you who want an inside perspective on how advanced libraries are developed. See http://www.boostcon.com/program for details. BoostCon 2008 will be hosted at Aspen Center for Physics, one of the most beautiful meeting sites in the world, and a great venue for collaboration and discovery. The combination of a relaxed pace and intense inquiry made BoostCon'07 an event to remember, and we expect no less for this year. Please visit http://www.boostcon.com/registration to register. Thanks! -- The BoostCon Planning Committee David Abrahams Joel de Guzman Jeremy Siek Beman Dawes Eric Niebler Matthias Troyer Jeff Garland Sean Parent

1 0

issue #1694
by David Grüner 02 Apr '08

02 Apr '08

Hi, I'm not sure why this track is set to Milestone 1.36 / No Version. This bug is there since at least 1.35 RC1 and not fixed in 1.35 Release. AFAIR i set the version or milestone to something like 1.35*. If that's impossible :) and nobody changed it, i'm really sorry. However, this needs to be addressed soon (IMHO), and it's easy to fix anyway. #define NDEBUG #define BOOST_ENABLE_ASSERT_HANDLER #include <boost/range.hpp> void reproduce() { boost::iterator_range<char const*>("early").end(); }

1 0

[bind] VC8 warning
by Ralf W. Grosse-Kunstleve 01 Apr '08

01 Apr '08

Hi, Coincidentally, I just noticed this VC8 warning when compiling the Boost.Python tests (using the current boost svn trunk): C:\home\rwgk\hot\boost\boost/bind.hpp(1639) : warning C4180: qualifier applied to function type has no meaning; ignored The full warning + cl command line is attached. What's the best way to resolve this warning? Ralf

2 1