- Boost - lists.preview.boost.org

[gsoc 2008] A C++ Remote Method Invocation Framework using Boost.Asio
by salinda h 01 Apr '08

01 Apr '08

Hi All, For the google summer of code 2008, I wish to build a Cross Platform Remote Method Invocation Framework for C++ using Boost.Asio, similar to Java's remote method invocation (RMI). I will provide some macro definitions to create the proxy code. Please provide me your comments to adjust this idea to best suit the interests of boost community. I higly appreciate your suggestions. A sample code that will use this framework wold look like, account.h -------------- DECLARE_BEGIN_PROXY(account) DECLARE_METHOD_1(deposit, void, double); DECLARE_METHOD_0(get_balance, double); DECLARE_END; class account { .......... ......... } Server Code ----------------- account acc = new account("Foo", 250); Server s = new server(server::TCP, 19000); s.attach("Foo", acc); s.run(); Client Code ---------------- account_proxy acct = account_proxy::get_proxy("172.25.44.195", server::TCP, 19000, "Foo"); acct.deposit(100); double balance = acct.get_balance(); Thank You, Salinda

7 6

Two 1.35 Issues
by Jared McIntyre 01 Apr '08

01 Apr '08

Has something changed in the way you build libraries? I'm building using the following command: bjam --build-dir=builddir --toolset=msvc-8.0 stage This no longer builds any of the libboost* versions, nor any debug builds when run against 1.35. bjam version is 03.1.16. I'm not having any issues with gcc builds. Secondly, is there a link on the website to the 1.35 Getting Started docs? I ended up finding it through the searc on the site. It might be nice if that was linked to from the documentation section. Maybe even listed at the top. Thanks, Jared

10 12

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

01 Apr '08

...skipped the beginning which appears to be duplication of the previous email > Could you clarify if the base implementation pointer can or can not be > initialized with a pointer to the implementation of the derived class? There > is something wrong in > > 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" > Base::Base(int k) : base(null()) > { > reset(new BaseImpl(k)); > } > > Derived1::Derived1(int k, int l) : Base(null<Base>()) > { > reset(new Derived1Impl(k, l)); > } > > Could a class inherit privately from pimpl? > > class A : private pimpl<A>::value_semantics {...} Well, I guess it can... although I am yet to see a compelling case to actually do that. It'll deny all the functionality that is in pimpl_base to the derived class(es). > There is something that seams extrange to me. If the pimpl is there to mask > the implementation, doesn't adds the public inheritance of > pimpl<A>::value_semantics some implemtation constraints? I cannot think of any particular implementation constraints > Note that public inheritance adds to the class interface the null() > function, bool type conversion and ! operator, and adds also all the > protected functions to the derevied classes. I am not sure I understand. Is it a bad thing? > Can we found always a null object for every class when pimpl is not used? null<T>() has boost::enable_if_c<is_pimpl<T>::value, T>::type so my implementation only kicks in for pimpls. > Can a class that inherits from a non pimpl class has its own private impl? > > class A; > > class B : A, public pimpl<B>::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. > 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<B>::implementation : public A { } That certainly makes sense (to me anyway). > 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). > Can we manage with multiple inheritance? > class A : public pimpl<A>::value_semantics {...}; > class B : public pimpl<B>::value_semantics {...}; > class C : public A, public B {...}; Sure... with all the relevant multiple-inheritance perks/drawbacks. > 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. > 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). > 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. :-) > I hope that you will find good solutions to these problems. So, do you find my answers to your satisfaction? > In any case, I > will apreciate that you include in the library documentation the limitations > of the approach, if there are any. Thanks, Vladimir.

2 1

Bug in 1.35: header inclusion order dependency introduced between recursive_mutex.hpp and asio.hpp on Windows
by James Talbut 01 Apr '08

01 Apr '08

recursive_mutex.hpp include windows.h, which includes winsock.h. asio.hpp barfs if winsock.h has been included. Clearly it's not boost's fault that windows.h and winsock2.h have inclusion order problems, but this change will break code that currently uses them both. Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________

7 8

[smart_ptr] shared_from_this in constructor potential pitfalls
by Frank Mori Hess 01 Apr '08

01 Apr '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It has occurred to me, constructors which throw exceptions might cause difficulties with the new support for calling shared_from_this() from constructors. If a constructor uses shared_from_this(), then throws an exception, it may result in dangling shared_ptrs (or the BOOST_ASSERT in the enable_shared_from_this destructor getting triggered). The problem can be avoided by not calling shared_from_this until you are sure your constructor won't throw. However, suppose you have a hierarchy such as "U derived from T derived from enable_shared_from_this<T>". Then if the constructor of U throws, it could be difficult to clean up any shared_ptr objects created by shared_from_this calls in the T constructor. Another tactic would be to restrict oneself to storing weak_ptrs when using shared_from_this() in constructors, and not locking any of them until the object is fully constructed. An exception thrown later in a constructor would cause the weak_ptrs to expire. This kind of tactic might be enforced by dropping support for shared_from_this in constructors. Instead, we would have a method in enable_shared_from_this which, instead of returning a shared_ptr like shared_from_this(), returns some object (call its class "shared_from_that" for the moment) with a method (say, shared_from_that::get()) that will return a shared_ptr to the original object when one is available. If the object is not owned by a shared_ptr yet, then shared_from_that::get could return an empty shared_ptr. If the object has destructed without ever being owned by a shared_ptr, or its owning shared_ptrs have expired, then shared_from_that::get() could throw bad_weak_ptr. Then client code would be able to distinguish between the two possible failures of either the shared_ptr not being available yet, or being expired, and act accordingly. An slightly different formulation might be a "weak_from_that" class, with a get() method that returns a weak_ptr and throws if the original object doesn't have an owning shared_ptr yet. I'm still on the fence as to whether shared_from_that would be an improvement or not. It seems more honest and safer than shared_from_this in constructors, but less convenient and a more complicated interface. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH8oHq5vihyNWuA4URAuDiAJ4j2MAP8JvdOWf1neQifNzQXJxLvwCffUsf /atoUpoioLgDMtbvS2bKeRI= =MkM6 -----END PGP SIGNATURE-----

1 0

Re: [boost] [gsoc 2008] A C++ Remote Method Invocation Framework using Boost.Asio
by salinda h 01 Apr '08

01 Apr '08

Hi, Thaks for your replies. > Interesting. Have you checked that there isn't something available already on > asio...not sure, but I think someone might have already done something like > this. That said, AFAIK it's not in Boost so this would be a nice extension. Thanks to Paolo Coletta's reply, I found the CodeProject article by Jarl Lindrud "RCF - Interprocess communication for C++". It is similar to what I suggested. Since it is not in a Boost library form Paulo suggests possible integration between this library and boost.interface. > Have a look at Boost.Interface http://www.cdiggins.com/bil.html > This library was never fully proposed for Boost, but it has alot of the same > ideas/needs as you do w.r.t. binding with C++ interfaces. Thanks for making my attention on this. After looking at the article, I understood that the Boost.Interface library will releive me from the burden of writing a custom Macro library. However I couldn't find a link on that page to get the source code of that library. Please tell me where can I get the source code. > Also, a totally different way to go would be to support an IDL like language > and write a tool to generate the needed C++. Yes. Internet Communication Engine (http://www.zeroc.com/ice.html) (Where I got the inspiration for this project.) uses an IDL. Since this is a C++ only project I thought I can avoid the additional step of code generation by using Macros. ( I likek the macro bindings in boost.python. It is so simple & smart than SWIG.) > What do you have in mind for the transport protocol? Both TCP and UDP. (Option is given to the user.) Thanks! Salinda

2 2

Re: [boost] type_with_alignment.hpp VC8 error
by Ralf W. Grosse-Kunstleve 01 Apr '08

01 Apr '08

Hi John, just to confirm: your svn revision 43984 fixes my problem. Thanks for the fast response! Ralf ----- Original Message ---- From: John Maddock <john(a)johnmaddock.co.uk> To: boost(a)lists.boost.org Sent: Tuesday, April 1, 2008 9:51:46 AM Subject: Re: [boost] type_with_alignment.hpp VC8 error Juergen Hunold wrote: >> I've managed to strip our code down to the attached example. I hope >> this >> is small enough and helps... >> >>> This is certainly deeply annoying: in >>> order to fix one bug it appears I've introduced another - but >>> without seeing the instantiation context and working out what >>> Boost.Python is doing it's hard to say whether this should be fixed >>> in type_traits or Boost.Python. >> >> My testcase does not use Boost.Python, so I think the problem should >> be >> in type_traits. Please note: this only affects 32-bit builds, 64-bit >> builds using Visual Studio or address-model=64 when using bjam work. Confirmed: that looks like a valid use case to me! ;-) I hope this is now fixed in Trunk: note however, you can still generate types with type_with_alignment<> which can't be passed through a function by value - but only if no other "ordinary" type is available - previously type_with_alignment<> wouldn't have compiled in these cases anyway. Regards, John.

1 0

[Proto] Review
by David Abrahams 01 Apr '08

01 Apr '08

First, let me say that I enthusiastically vote for acceptance! - What is your evaluation of the design? Excellent. I would change some names here and there. - What is your evaluation of the implementation? I didn't look at the implementation much, but I am familiar with Eric's work and I have no doubt that it's stellar. - What is your evaluation of the documentation? A valiant effort, but still needs work. This is a difficult domain to explain, but I hope that Eric will keep trying :-) - What is your evaluation of the potential usefulness of the library? Extremely useful. I'm already looking forward to using it in at least two projects. - Did you try to use the library? With what compiler? Did you have any problems? I tried out a few of the early examples with G++ 4.1.3. The only problem I had is noted in the attached user guide walkthrough, and I very much doubt it was a compiler dependency. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 12 hours of careful reading through the user guide. - Are you knowledgeable about the problem domain? Reasonably knowledgeable. I have lots of experience with expression templates but very little with the domain of generalized ET libraries. The attached document contains many more comments. -- Dave Abrahams Boost Consulting http://boost-consulting.com

6 31

[1.35.0] Going live with the new web site
by Beman Dawes 01 Apr '08

01 Apr '08

What has to be done to go live with the new web site? I assume this should happen as soon as the release packages go up on Sourceforge. Thanks, --Beman

7 28

[Type Traits] - broken link from new website docs?
by Jeff Flinn 01 Apr '08

01 Apr '08

Or at least an empty page comes up. Jeff Flinn

3 5

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

01 Apr '08

[ 248 open bugs today, 245 yesterday ] 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 20 grafik 15 vladimir_prus 14 dave 13 dgregor 12 doug_gregor 12 bemandawes 11 no-maintainer 11 agurtovoy 8 anthonyw 7 turkanis 7 jsiek 6 matias 5 witt 5 igaztanaga 4 johnmaddock 4 ebf 3 rogeeff 3 ramey 3 nesotto 3 nasonov 3 kaalus 3 danielw 3 danieljames 3 None 2 shammah 2 samuel_krempp 2 pdimov 2 pavol_droba 2 marshall 2 jmaurer 2 hkaiser 2 aaron_windsor 1 urzuga 1 t_schwinger 1 speedsnail 1 garcia 1 fcacciola 1 dlwalker 1 chris_kohlhoff 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 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 jsiek 1531 segfault in dynamic_bitset::reference assign operator jsiek 1540 Poisson distribution very slow for large mean (and may also overflow). 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. marshall 1493 SVN files making it through to install 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 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<U> 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 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 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 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

[mp_math] a multi precision signed integer library
by Kevin Sopp 01 Apr '08

01 Apr '08

Hi all, I've been busy with porting the public domain C library libtommath to C++. The code is quite usable as it is and some simple documentation exists in the libs/mp_math/doc/html subfolder. I've implemented all C++ operators for the mp_int<> type and it can thus be used just like a built-in integer type. Some things like random number generation and primality testing have not been documented yet. Please have a look, I'm looking for feedback at the moment so that I can plan on how to proceed. http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… alternatively go to boost vault /math - numerics subfolder and download mp_math_v01.zip Kevin

7 19

Boost C++
by manuel shibin 01 Apr '08

01 Apr '08

Hi every one. I am Manuel AJ Can anybody provide information about multi precision signed integer class library . I am interested in doing very long int class (digits up to 100) is both the project is same

2 1

[steve@sumost.ca: [Boost-build] help with boost 1.35 variant specification]
by Steve M. Robbins 01 Apr '08

01 Apr '08

Anyone here know the answer? Thanks, -Steve ----- Forwarded message from "Steve M. Robbins" <steve(a)sumost.ca> ----- Date: Mon, 31 Mar 2008 15:07:49 -0500 From: "Steve M. Robbins" <steve(a)sumost.ca> To: boost-build(a)lists.boost.org Subject: [Boost-build] help with boost 1.35 variant specification Reply-To: "Boost.Build developer's and user's list" <boost-build(a)lists.boost.org> Hi, We have been building boost (up to 1.34.1) for Debian/linux using $(JAM) variant=release,debug threading=single,multi where $(JAM) is the path to bjam (built from the boost sources) together with the options -d2, --user-config and -sHAVE_ICU=1. The user config file contains: using gcc : 4.2 : g++-4.2 : <define>_REENTRANT ; using python : 2.4 : /usr ; using python : 2.5 : /usr ; This always resulted in four static libraries and four shared libraries for, say, the date-time library. With 1.35, however, I get the four shared libs but only one static lib: steve@riemann{boost_1_35_0}grep 'gcc.link.dll.*date' ../boost_1.35.0-1_i386.build gcc.link.dll bin.v2/libs/date_time/build/gcc-4.2/release/libboost_date_time-gcc42-1_35.so.1.35.0 gcc.link.dll bin.v2/libs/date_time/build/gcc-4.2/release/threading-multi/libboost_date_time-gcc42-mt-1_35.so.1.35.0 gcc.link.dll bin.v2/libs/date_time/build/gcc-4.2/debug/libboost_date_time-gcc42-d-1_35.so.1.35.0 gcc.link.dll bin.v2/libs/date_time/build/gcc-4.2/debug/threading-multi/libboost_date_time-gcc42-mt-d-1_35.so.1.35.0 steve@riemann{boost_1_35_0}grep 'gcc.archive.*date' ../boost_1.35.0-1_i386.build gcc.archive ../../../bin.v2/libs/date_time/build/gcc-4.2/release/link-static/threading-multi/libboost_date_time-gcc42-mt-1_35.a How do I get all 8 library builds back? I have read a couple of posts about --build-type=complete, so I tried adding that to $(JAM), but this gives a completely inpenetrable error: Skipping build of: ./headers <build>no in common properties Skipping build of: ./build_all <build>no in common properties Skipping build of: libs/regex/build/icucore <build>no in common properties Skipping build of: libs/regex/build/icuin <build>no in common properties Skipping build of: libs/regex/build/icudata <build>no in common properties /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/kernel/class.jam:93: in new *** argument error * rule object(searched-lib-target)(a)2059.__init__ ( name : project : shared ? : search * : action ) * called with: ( icudata icui18n icuuc : object(project-target)@212 : true : : object(null-action)@2058 : : : : ) * extra argument icui18n /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/tools/builtin.jam:349:see definition of rule '__init__' being called /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/tools/builtin.jam:592: in searched-lib-generator.run /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/tools/unix.jam:113: in object(unix-searched-lib-generator)(a)25.run /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/generators.jam:859: in try-one-generator-really /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/generators.jam:920: in try-one-generator /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/generators.jam:1131: in construct-really /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/generators.jam:1204: in generators.construct /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/tools/builtin.jam:496: in object(lib-generator)(a)5.run /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/generators.jam:859: in try-one-generator-really /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/generators.jam:920: in try-one-generator /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/generators.jam:1131: in construct-really /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/generators.jam:1204: in generators.construct /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/targets.jam:1368: in construct /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/targets.jam:1206: in object(typed-target)(a)224.generate /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/targets.jam:742: in generate-really /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/targets.jam:715: in object(main-target)(a)655.generate /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/targets.jam:254: in object(project-target)(a)212.generate /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/targets.jam:858: in targets.generate-from-reference /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/targets.jam:1129: in generate-dependencies /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/targets.jam:1179: in object(alias-target-class)(a)114.generate /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/targets.jam:742: in generate-really /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/targets.jam:715: in object(main-target)(a)376.generate /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build/targets.jam:254: in object(project-target)(a)70.generate /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/build-system.jam:658: in load /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/kernel/modules.jam:267: in import /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/tools/build/v2/kernel/bootstrap.jam:132: in boost-build /usr/local/src/Packages/boost/upstream/1.35/boost_1_35_0/boost-build.jam:11: in module scope make: *** [build-stamp] Error 1 What does this mean: did I invoke bjam incorrectly or is some jam file broken? Thanks, -Steve _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build ----- End forwarded message -----

1 0

[shifted_ptr] <T []> support, VC 8 certified, bug fix
by Phil Bouchard 01 Apr '08

01 Apr '08

Greetings: I got slowed down by a bug but fortunately I put my hands on it; - I fixed and updated the version in the Vault. - I have also made the headers compile fine under VC 8 but I haven't checked out the executable (missing objects). - I added safer support for array objects by limiting to access operator [] - I have replace "make_shifted_ptr" with "make_shifted_ptee" for efficiency reasons. It is possible to fall it back to its predecessor but requires some work, - I wanted to change the way sets are merge and did so. Todo: - Documentation. BTW I think Shifted Pointer got removed from the review schedule. I thought I didn't need documentation at that point but this is a short notice. Regards, -Phil

1 0

[gsoc 2008] JSON Archives for Boost.serialization
by Esteve Fernandez 01 Apr '08

01 Apr '08

Hi all, I'm new to this list but have been tracking Boost development for a long time. Never thought I could contribute something new to Boost, but after seeing this year's GSoC Boost proposal, I changed my mind and decided to take a deeper look at the JSON proposal. I've used the Boost.serialization library extensively and always end up needing something more portable than the binary archive and less heavyweight than the XML archive. Also, I spend a lot of time developing with Boost.Python and a format already supported by Python would be great, so seeing there was interest in a JSON archive was the perfect opportunity to join. Anyway, I've some points regarding this project before I apply, don't know if I should send them to Jeff (who suggested the idea) or to Robert (who implemented Boost.serialization). Instead of just bothering them, I'll bother all the subscribers to boost(a)lists.boost.org :-) - the JSON spec is quite simple, but given that it's a subset of YAML (actually Syck parses JSON as well), should it support it in the future as well? - what about Unicode? I know that Boost.Regex supports Unicode if compiled against ICU and the JSON spec states that everything must be in Unicode (correct me if I'm wrong) - TinyJSON and JSON.Spirit both use a MIT-like license (JSON.Spirit is licensed under CPOL). The Boost license is compatible with them but, could it pose a problem? There's JSONcpp [1] as well, which is public domain. - wading through the Boost mailing list archives, I found a message [2] by Daryle Walker in which he expressed interest in a JSON serializer some while ago (2005), but I think it wasn't discussed any further. Eric Newhuis wrote again about having a JSON archive just a few weeks ago [3] - which platforms must be supported? I can only provide support to GCC under Linux, but I guess it has to support MSVC and some other platforms. Will it have to be available for all the platforms supported by Boost at the end of the summer or is it more of a process? That is, given that one of the purposes of GSoC is to involve more people into free software/open source projects, whoever (I hope it's me :-)) implements the JSON serializer, will become its maintainer too and will take care of all the tasks related to accept patches, track bugs, add support for future/incomplete platforms, etc. - I thought of adding JSON support to Boost.Spirit as well. Currently it has support for printing ASTs in XML (see tree_to_xml). A JSON dumper would be quite useful for manipulating ASTs in a high level language, such as Python through Boost.Python Cheers. 1 - http://jsoncpp.sourceforge.net/ 2 - http://lists.boost.org/Archives/boost/2005/09/94438.php 3 - http://lists.boost.org/boost-users/2008/03/34336.php

5 6

[shifted_ptr] Now supports <void>, multithread roots & preprocessor code
by Phil Bouchard 01 Apr '08

01 Apr '08

Greetings: Ok, this a nice feature that just got added to the pointer. I just added support for "void" pointers and works perfectly. We can see the object being deleted correctly after the shifted_ptr<void> is destructed. Furthermore a very nice property shifted_ptr_base has is that it can be casted to a regular pointer and back again to a shifted_ptr_base and the pointee will still be correctly deallocated. I never saw any production code using perfect C++ coding and sometimes it happens we rely on "working undefined behaviors". Multithreaded support has been added but unfortunately I didn't see any function returning the current thread id. Was this disregarded? Finally I am using cleaner preprocessor coding for variadic function templates: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Thanks, -Phil

3 8

Interest in static initialization library
by Sean Hunt 01 Apr '08

01 Apr '08

Hi Boosters! I was wondering if there is any interest for a static initialization library. The idea I currently have might look something like this: #include <iostream> #include <boost/init.hpp> using namespace boost; using namespace std; class myType { myType(int i) { cout<<"myType constructed with parameter "<<i<<endl; } }; void myFunc (int i) { cout<<"myFunc called with parameter "<<i<<endl; } extern init::variable<myType> myVar (42); init::function<void (), myVar> myInitFunc (myFunc, 35); init::variable<myType> myVar; int main () { init::init(); } The extern declaration of myVar simulates a global defined in a different translation unit - in this case, function is by the standard guaranteed to be initialized first, but if myVar is in a different TU, then the output is undefined. By passing myVar as a parameter to the function template, the library will ensure that the function is called after the variable (I was originally considering using a before<myVar> and after<myVar> syntax, but it would be too difficult to implement an algorithm that would be guaranteed to get the order right, whereas it's quite easy like this). The idea would be to allow an easy relationship for static initialization. I'm thinking that the variable class should act as a near-transparent wrapper by overloading all the operators. Since operator . is not overloadable, I would probably allow it to act through ->, unless the member is a pointer-like type (the exact definition of pointer-like could be controlled using template specializations). A member function would obviously be provided for accessing the object directly (such as to call a smart pointer's functions). Another idea is to have two separate classes (say, variable and wrapper), and only one has the wrapping behavior - the other has to have explicit access each time. The init function serves as the trigger for all the static initialization to occur (earlier actual initializations serve only to add the initializer to the queue) Functors would be provided to defer a function call (to get a constructor or function parameter) until the time that the initialization of the object takes place, rather than the initializer. If an exception is thrown, the initialization library will remember its state and then a subsequent call would take it off where it stopped. (adding new objects to the queue once initialization has begun would be allowable, allowing the initializer to be reused). Someone will no doubt at some point argue that I should wrap the functionality in a class to handle the initialization in order for different code to simultaneously take advantage of the facility, but I will dismiss that because it would fall prey to static initialization order and not work as intended. Perhaps later I will add a system that allows user code to store the current initialization list/state, but I don't think it would be worth the effort. One last question: Should I write this using C++09 variadic templates or the standard boost preprocessor techniques? I think that code written for variadic templates is more easily convertible to the preprocessor than vice versa, but I don't know. Thanks for your comments! Sean Hunt

2 1

1.35] Please remove \libs\filesystem\src\exception.cpp.
by Joe Gottman 31 Mar '08

31 Mar '08

Instead of using bjam, I compile the boost libraries on my own. I recently tried to compile the new version of boost::filesystem, and failed with exception.cpp. I had a scary few minutes until I realized I no longer needed this file since filesystem now uses errors from the system library. With header files, especially ones that the user never uses directly, there is no problem with leaving them in the directory after they are no longer needed, since they will never be included. However, users generally expect to have to compile source files, and so one that is included but no longer valid can cause major problems for people who compile without using bjam. Therefore, I would appreciate it if you would remove \libs\filesystem\src\exception.cpp. Joe Gottman

1 0

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

31 Mar '08

"vicente.botet" <vicente.botet(a)wanadoo.fr> wrote in message news:<014201c8937c$c1380180$0301a8c0@viboes1>... > Hello, > > First of all, I think that a pimpl library should have a place in boost, but > I think that the pimpl idiom do not scale very well (see below). > > Even if your library is usable in simple cases, I would like to see how it > can manage more complex cases. And if no satisfactory solution to this case > is possible, that the library states explicitly when it can not be used. Would it be possible to elaborate that exactly you mean by "more complex cases"? Inheriting from a pimpl-based class? I think it covered. What else? Not like my own deployment experience is of any guidance but still I've been using this idiom in my every-day development for about a year and have not come across something that I felt was not a good fit for that idiom. I'd rather say that the pimpl idiom in general does not handle well simple (rather than complex) cases where the overhead of creating private implementation on the heap is not affordable. > > Do you think to write the library documentation before the review? Even if > there is a tutorial in DDJ, IMHO, you should spend some time on the > documentation of the library before the review. In addition to the tutorial I have API documented in the header in the format for doxygen. Although I have to confess when I did run it through doxygen it did not seem to produce anything I saw valuable so I did not include that doxygen-generated file. Will look into it again though. Thanks, Vladimir.

1 0

Re: [boost] GSoC Ideas
by Cristianno Martins 31 Mar '08

31 Mar '08

Thanks for comments and advices, Doug. I really appreciate it. On Sun, 2008-03-30 at 21:14 -0300, Cristianno Martins wrote: > I'm Cristianno Martins, I'm starting master degree at State University of > Campinas (Brazil), and I'm very interested in participate of a Google Summer > of Code Project. Welcome! > This is the first time that I'm intending to develop some open source code. > There are many projects listed in GSoC home page, and I almost read all of > them, choosing two or three to write a propose. Usually, it is best to focus your energy on a single project that you're very interested in. Take the time to write a detailed proposal for that project to give it the best chance of success. > So, I really liked two ideas between the boost potential projects: > - safe integer -> basically, a creation of a template class to safely access > values in the memory; > - parallelizing Boost.Math -> using OpenMP to enable the source of > Boost.Math to run in multicore systems. > > I actually believe that I can do anyone of them, and I wanna propose a > project to each one. I only needed to know if anything is being done about > some of those. I also wanna know if someone have ideas to be done in these > projects and aren't listed at the Boost projects list. We often receive several applications for projects listed on the Boost projects list. That's why it is best to write a solid proposal that makes you stand out. - Doug -- 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

1 0

[serialization][1.36] ktmap contains extended_type_info with m_key == 0
by Felipe Magno de Almeida 31 Mar '08

31 Mar '08

Hi Robert, I'm hitting a assertion with m_key == 0. With my debugger I can find lots and lots of items with m_key == 0. None are one of my types, there are shared_ptr_1_32 with m_key == 0 and others. Do you have a newer 1.36 version? Am I doing something wrong? I'm using the 1.36 version for use with DLLs (export in a DLL and serialize/deserialize in another). Thanks, -- Felipe Magno de Almeida

3 18

[GSoC 2008] Deadline for student applications extended
by Hartmut Kaiser 31 Mar '08

31 Mar '08

FYI... > Hello everyone, > > This year, we experimented with the program timeline providing one > week for students to discuss project ideas with their mentors and then > a single week to submit applications. We have heard feedback from the > community that it would be beneficial to provide more time for > students to submit their applications, so we've done just that. > > > The new deadline for student applications is Monday, April 7, 2008. > > > For full details, you can check out the program timeline. Please note > that our engineers are working on the required updates to both > http://code.google.com/soc/2008/ and the FAQs to reflect the extended > deadline, and we will post to this list when the changes have gone > live. > > > In the meantime, get those applications in and nag your friends to > apply. :) > > > Cheers, > LH > > > Leslie Hawthorn > Program Manager - Open Source > Google Inc. > > > http://code.google.com/opensource/

1 0

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

31 Mar '08

"Mathias Gaunard" <mathias.gaunard(a)ens-lyon.org> wrote in message news:<fsptpe$peo$1(a)ger.gmane.org>... > > I have only quickly gone through your documentation on DDJ, so my > comments may be off. Feel free to correct me if I misunderstood something. > > Personally, I fail to see the advantage over a shared_ptr member. > The only differences I could notice are > - implementation class is not user-declared but rather is a > specialization of a template. Well, the pimpl idiom is certainly not a shared_ptr.as pimpl's main purpose is separation of interface and implementation and imlemetation hiding. shared_ptr does not provide the latter. I was hoping I covered all that in the article. > - the null pointer is called null (by the way, I think we shouldn't > allow a null value, the private implementation should always be > initialized somehow, if lazily) The private implementation is always initialized by default. Nowever, null() is certainly needed for many things. And Foo::null() is certainly not a pointer but a proper (but invalid :-)) Foo instance. > There doesn't seem to be any useful help for allocating the private > implementation. What exactly are your expectations? If you'd like private implementation to be allocated for you, then it's simply not possible as ity is called private for a reason. > Such potentially interesting allocation schemes, like stack allocation, > seem also to be impossible. I have not seen one single implementation of pimpl allocating private implementation on the stack and I do not believe it is possible as in order to allocate on the stack we/compiler have to know the size of the class (private implementation class) which is again private. > Being able to replace the private implementation of a base with the > private implementation of a derived class certainly is a necessity. > I have to admit, though, I do not understand your solution. > You're passing a null<Widget>() to the Widget constructor, but the > constructor wasn't written to take any kind of special argument. null<Widget>() is an instance of Widget. Therefore, the copy constructor is called. > I'm not really sure of the point (and validity) of having pointer > semantics. Do you really want your implementation details to be shared > by some of your different instances? (maybe there is a point in sharing > implementation details with all instances or all equivalent instances, > but some?) I am not sure about your usage patterns but my usage of pimpl::pointer_semantics vs. pimpl::value_semantics is 100:1. What is the point (and validity) of having shared_ptr<Foo>? Same is applicable to pimpl::pointer_semantics. > It seems more logical to me to have the same semantics for the object > and its private implementation. If the object itself has pointer > semantics, then you won't copy it. Using one or the other for the > implementation makes no difference, then. You might as well use the > value semantics, which would even be more lightweight in that case. I personally do not see logic the same semantics for the object and its private implementation because the object is the interface and its private implementation is implementation detail (which is private as well). They serve different purpose, have different visibilities et al. What is the advantage of them having the same semantics? Thanks, Vladimir.

1 0

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

31 Mar '08

"Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> wrote in message news:<47F12E07.4060205(a)aaronwl.com>... > Vladimir.Batov(a)wrsa.com.au wrote: > > The code is in the Boost Vault called Pimpl.zip > > I haven't looked at your library, but one thing you need to do to get > buy-in for this library is provide a comparison with the pimpl_ptr > library that was proposed and rejected. > > My perception of the primary reason the library failed is that, despite > being a basically sound library, it didn't work in the ways people > wanted it to. Yes, I looked at that proposed implementation. Unfortunately, the major deficiency of it IMHO was that it was sacrificing implementation hiding (the main pimpl property) for the sake of generalization. I think I cover that in the docs at http://www.ddj.com/cpp/205918714. > It would be useful if you could summarize the vital details of your > library, along with a comparison to the previous proposal, and other > similar libraries, in your announcement message. I hope I cover that at http://www.ddj.com/cpp/205918714 Thanks, Vladimir.

1 0