- Boost - lists.preview.boost.org

[preprocessor] #elif behaviour in gcc 4.4
by Daniel James 12 Jul '08

12 Jul '08

Hello, A recent change to the development version of the gcc preprocessor changes the way it processes '#elif' directives and breaks a common use of the preprocessor library. We've already had reports of this causing problems in MPL, and it might also affect: variant, function_types, python, fusion, xpressive and phoenix. Details of the change are at: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36320 With this change, the argument to an '#elif' directive is processed even if a previous '#if'/'#elif' directive was true. This causes the example use of BOOST_PP_ITERATION_DEPTH to break: http://www.boost.org/doc/libs/1_35_0/libs/preprocessor/doc/ref/iteration_de… In this example, the first time the header is included, BOOST_PP_ITERATION_DEPTH is not yet defined, so it causes the develoment gcc to fail when the #elif directives are evaluated (which are skipped with existing versions, because the first #if directive evaluates to true). Looking at the standard, I think their interpretation is correct (although I'm not familiar with it and could be missing something) but it isn't clear that this was the intent of the authors. Any opinions on this? I think it's quite easy to work around, we can replace: #if !BOOST_PP_IS_ITERATING // .... #elif BOOST_PP_ITERATION_DEPTH() == 1 // .... #elif BOOST_PP_ITERATION_DEPTH() == 2 // .... #endif with: #if !BOOST_PP_IS_ITERATING // .... #else # if BOOST_PP_ITERATION_DEPTH() == 1 // .... # elif BOOST_PP_ITERATION_DEPTH() == 2 // .... # endif #endif So that the calls to BOOST_PP_ITERATION_DEPTH are skipped - or we could just include the necessary header before including the file. But it does seem a pity that any code which uses this technique might need to be changed for gcc 4.4. We should probably write to them about this (it doesn't look like they realised this would be a problem), but I'm writing here first in case anyone has any ideas. Daniel

2 1

Re: [boost] [pool] segfault (fun with static initialization ordering)
by JOAQUIN M. LOPEZ MUÑOZ 12 Jul '08

12 Jul '08

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de JOAQUIN M. LOPEZ MUÑOZ [joaquin(a)tid.es] Enviado el: viernes, 11 de julio de 2008 17:35 Para: boost(a)lists.boost.org Asunto: Re: [boost] [pool] segfault (fun with static initialization ordering) _______________________________________ > The following is a case where the precende rule *cannot* be applied > for logical reasons: > > template<typename T> > struct foo{ > static int x; > }; > > template<typename T> > int foo<T>::x=T::x; > > struct bar > { > static int x; > }; > > int bar::x=666; > > static int x=foo<bar>::x; Please disregard this example, it is flawed because bar::x is statically initialized an because ultimately the compiler is not required to perform the dependency analysis suggested above. I've been playing with the following: #include <iostream> #if defined(CASE1) struct bar{static int x;}; static int f(){return 666;} int bar::x=f(); template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; #elif defined(CASE2) template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; struct bar{static int x;}; static int f(){return 666;} int bar::x=f(); #endif int main() { std::cout<<"bar::x: "<<bar::x<<std::endl; std::cout<<"foo<bar>::x: "<<foo<bar>::x<<std::endl; } Using GCC in Cygwin the output is the same for both CASE1 and CASE2: bar::x: 666 foo<bar>::x: 666 Using MSVC++ 8.0 I observed a light-shedding behavior: When compiling with a fresh project, the output is the same for CASE1 and CASE2 and coincides with GCC: bar::x: 666 foo<bar>::x: 666 But after that I changed the code to the following: #elif defined(CASE2) template<typename T>struct foo{static int x;}; template<typename T>int foo<T>::x=T::x; struct bar{static int x;}; static int x=foo<bar>::x; // NEW LINE static int f(){return 666;} int bar::x=f(); #endif This forces foo<bar>::x evaluation to be done at a prior monent and the result is (for CASE2): bar::x: 666 foo<bar>::x: 0 Now, the funny thing is that if I revert to the original code (i.e. I delete the line comented as // NEW LINE) then MSVC++ 8.0 outputs the following both for CASE1 and CASE2 bar::x: 666 foo<bar>::x: 0 which is different than my early runs! The compiler seems to reuse some intermediate files from prior compilations that set a particular initialization order: confirming this hypothesis, if I clean the project and rebuild again then we're back at the original output for both CASE1 and CASE2: bar::x: 666 foo<bar>::x: 666 So, you see how one cannot actually rely on any particular initialization order for class template statis data. The standard explicitly leaves this initialization order unspecified (see the rest of 3.6.2). With respect to the rest of my previous post I maintain the explanation for the problem with pool you're having and contend that referring to singleton_pool<...> inside fast_pool_allocators ctors is the proper fix. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Suggestion: keep the trunk stable
by Daryle Walker 12 Jul '08

12 Jul '08

Based on reading the various posts on releasing Boost 1.36.... Maybe we should promote the idea that the trunk of our Subversion repository should be as stable as possible as an official policy. I think a lot of open source projects do this; because it brings a big benefit: fast turn-around times for releases. With a stable trunk, the release manager makes a branch for release from the trunk, has everyone help in testing and making sure the branch is otherwise fully stable, then ship out the final version of that branch. After that, the changes on that branch have to be merged into the trunk to make it more stable. (And the branch can be removed.) Realize that the release branch preparation is _only_ for stabilization (i.e. bugs); anyone who was late for adding a new OR revised feature has to wait for the next release cycle. I think we're trying to do releases every three months, here's a possible timeline: 1. For the first two months, we're just updating the trunk with bug- fixes, revised features, and new features/libraries. Bug-fix releases come out during this time as needed. Any fix has to be based on a commit on the trunk. The bug release manager just makes a branch off the last bug release tag (or the last major release tag if we're doing the first bug release) and applies the selected bug fix change-sets, then ships after the group's testing. (The branch is re- merged then removed.) The release team would (generally) do the bug- fix incorporation; the libraries' developers did their parts by adding the fixes in the trunk in distinct change-sets. Hopefully, this would take a week for branching and fix-merging, then another week or so for testing. 2. Work on the trunk has to be kept stable. Incorporate changes into the trunk in distinct steps that do not break the build. Huge changes, like ones that could cause merge & conflict hell, especially if done during release time, should be kept on a branch until ready to be incorporated. Branchers should keep their branch current with the trunk as far as unrelated files (and pieces of related files) are concerned. (Alternatively, if a big change can be broken into steps that individually don't break the build, then that should work too.) Note when a distinct step is committed, it's not just code; the corresponding documentation and tests for that step need to go in too. 3. For the last month, work on the next major release begins. If we follow the always-stable-trunk ideal, then this will be like case [1]. We pick a deadline. On the deadline day, the release manager branches off the trunk on the most stable revision around that time. There's a week-long period where incomplete big changes either need to be finished to an acceptable cut-off (which may be 100% if it was nearly done) or get back-tracked to a previous acceptable cut-off. The release team and the library developer discuss which focused revision the cut-off will be cherry-picked from (either backward or forward). The remainder of the procedure happens like [1], probably even to the point of the short completion times (1 to 2 weeks). 4. The branches here are transitory. They should be created as needed and removed when they're not necessary. The major release branch would be called "release" and the bug fix branch called "bug- release". They may be around simultaneously. There should be a special branch called "hotness" (or whatever) that is an alias to the "trunk" most of the time, but to "release" or "bug-release" when those branches exist. (If both exist, "bug-release" takes priority; but bug releases have to be quick so the release isn't bogged down.) Our test crew can just park on "hotness" and make sure to update and test regularly, preferably on automatic. The branch points will be tagged ("1_37_origin", "1_37_0", "1_37_1", "1_38_origin", etc.) so we don't forget them, of course. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

Is there a helper function for boost::fusion::vector just as std::make_pair to std::pair?
by Peng Yu 11 Jul '08

11 Jul '08

Hi, Is there a helper function for boost::fusion::vector just as std::make_pair to std::pair? boost::fusion::vector<very_loooooooooooooooooong_type,...,very_loooooooooooooooooong_type> v(...,,...); Suppose I have the above case, where the declaration is very long, I would like a helper function to simplify the above definition. Thanks, Peng

3 2

[serialization][portable-binary archive] Data not byte-swapped across architectures
by Jon Kroll 11 Jul '08

11 Jul '08

Hello: I am attempting to use the boost serialization portable-binary archive. The 2 architectures I am working on are: 1. Intel on MS-Windows/Mac OS X 2. PowerPC on Mac OS X The attached sample code shows that an integer I serialize on PPC and then unserialize on Intel is not byte-swapped. And similarly, an integer I serialize on Intel is not byte-swapped on PPC. It does not appear to be a OS issue, because the data is unserialized properly from a MS-Windows Intel system to a Mac OS X Intel system, and vise versa. Another manifestation of this occurs when I serialize a large container, like a vector for example. The code has an exception because the size of the container is not byte-swapper. I can provide example code for this as well. This experience leads me to believe either: 1. The portable binary is not functioning properly with Mac OS X PPC or 2. I am not using the portable-binary archive properly, either configuration or code. Advise on this issue would be greatly appreciated. Best regards, Jon Kroll Ann Arbor Michigan ========================================================================= BUILD: Windows: MS-Visual Studio 2005 Mac OS X: g++ test_portable_binary.cpp portable_binary_iarchive.cpp portable_binary_oarchive.cpp -o test_portable_binary -I/Volumes/..../boost_1_35_0/ -L/Volumes/..../boost_1_35_0/stage/lib/ -lboost_serialization-mt-1_35 CODE: ======================================================== #include "boost/archive/portable_binary_oarchive.hpp" #include "boost/archive/portable_binary_iarchive.hpp" #include <vector> #include <sstream> #include <fstream> #include <iostream> #include <string> namespace { bool isIntelArch() { char endianTest[2] = { 1, 0 }; return (*(short *) endianTest == 1); } bool isPPCArch() { return !isIntelArch(); } } int main(int argc, char* argv[]) { if (false) // generate test file { std::string fileName; if (isPPCArch()) fileName = "PPC_portableBinaryLargeInt.ser"; else if (isIntelArch()) fileName = "Intel_portableBinaryLargeInt.ser"; int val = 16000; // 0x3E80 std::ofstream os(fileName.c_str(), std::ios::binary); portable_binary_oarchive oa(os); oa & val; return 0; } int unserializedVal = 0; { std::string fileName; if (isPPCArch()) fileName = "Intel_portableBinaryLargeInt.ser"; else if (isIntelArch()) fileName = "PPC_portableBinaryLargeInt.ser"; std::ifstream is(fileName.c_str(), std::ios::binary); portable_binary_iarchive ia(is); ia & unserializedVal; } if (0x3E80 == unserializedVal) { return 0; // This is the correct result! } if (0x803E == unserializedVal) { return -1; // This is an error, the value is not byte-swapped } if (0 == unserializedVal) { return -1; // This is an error, nothing got unserialized } return 0; }

2 4

Concept based overloading and the ODR
by Steven Watanabe 11 Jul '08

11 Jul '08

AMDG I'm looking at two recent posts: http://comments.gmane.org/gmane.comp.lib.boost.devel/177370 http://comments.gmane.org/gmane.comp.lib.boost.user/37476 Either of these is fine by itself, but putting them both together makes it very easy to cause silent ODR problems. For example in translation unit a.cpp we #include "boost/tuple/tuple_io.hpp" and translation unit b.cpp we forget. Then, along comes boost::any which detects operator<< in translation unit a.cpp, but uses its default in translation unit b.cpp. Ka-Boom. This is not a huge problem at the moment, because it's quite difficult to make the detection bullet-proof, but I'm very concerned because C++0x concepts are supposed to make such overloading easy. In Christ, Steven Watanabe

2 6

How to convert a vector of base classes to template based code?
by Peng Yu 11 Jul '08

11 Jul '08

Hi, The following program uses virtual functions. Essentially I need to go through all the pairs in 'v'. Since I have already know what are in v at compile time. I would like to convert the dynamic polymorphism to template. Therefore, the runtime would be better. I think this should be done with the help of boost::mpl. But I'm not sure how to do it. Would you please help me? Thanks, Peng #include <iostream> #include <vector> #include <boost/shared_ptr.hpp> struct shape { virtual void show_me() const = 0; virtual ~shape() { } }; struct square : public shape { void show_me() const { std::cout << "square"; } }; struct circle : public shape { void show_me() const { std::cout << "circle"; } }; struct triangle : public shape { void show_me() const { std::cout << "triangle"; } }; int main() { std::vector<boost::shared_ptr<shape> > v; { boost::shared_ptr<shape> s(new square); v.push_back(s); } { boost::shared_ptr<shape> s(new circle); v.push_back(s); } { boost::shared_ptr<shape> s(new square); v.push_back(s); } { boost::shared_ptr<shape> s(new triangle); v.push_back(s); } for(std::vector<boost::shared_ptr<shape> >::const_iterator it = v.begin(); it != v.end(); ++ it) { for(std::vector<boost::shared_ptr<shape> >::const_iterator it2 = it + 1; it2 != v.end(); ++ it2) { (*it)->show_me(); std::cout << " vs. "; (*it2)->show_me(); std::cout << std::endl; } } }

3 5

Review Wizard Status Report for May 2008
by Ronald Garcia 11 Jul '08

11 Jul '08

========================================== Review Wizard Status Report for May 2008 ========================================== News ==== December 7, 2007 - Forward Library Accepted - Awaiting SVN December 16 - Unordered Containers Library Accepted - In SVN December 21 - Factory Library Accepted - Awaiting SVN January 13, 2008 - Switch Library Accepted Provisionally - Awaiting submission for mini review January 18 - Singleton Library Rejected - Awaiting resubmission, John Torjo has already volunteered to manage the next review January 30 - Flyweight Library Accepted - Awaiting SVN February 13 - Logging Library Rejected - Awaiting resubmission for new review, John Torjo has already resubmitted and Gennadiy Rozental has again volunteered to manage the review February 27 - Floating Point Utilities Library Accepted - Awaiting SVN March 14 - Proto Library Accepted - Exists as a component in Xpressive, but not yet as a separate library April 20 - Egg review completed - Results pending May 7 - Scope Exit Library Accepted - Awaiting SVN Older Issues ============ The binary_int library, accepted in October 2005 has not yet been submitted to SVN. The authors are strongly encouraged to contact the review wizards The Quantitative Units library, accepted in April 2007 has not yet been submitted to SVN The Globally Unique Identifier library, accepted provisionally in May 2007 has not yet been submitted for mini-review and full acceptance The Time Series Library, accepted in August 2007 has not yet been submitted to SVN The Accumulators library, accepted in February 2007 is in SVN The Exception library, accepted in October 2007 is in SVN The Scope Exit review report had not been submitted by the review manager. John Phillips stepped in as substitute review manager and produced a report For libraries that are still waiting to get into SVN, please get them ready and into the repository. The developers did some great work making the libraries, so don't miss the chance to share that work with others. Also notice that the review process page has been updated with a section on rights and responsibilities of library submitters. For the Scope Exit review, we would like to publicly apologize to Alexander Nasonov for how long this has languished without a report. The review wizards will work to make sure this doesn't happen any more. General Announcements ===================== As always, we need experienced review managers. In the past few months there have been a large number of reviews, but the flow of high quality submissions is just as big, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants or library contributors. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "garcia at cs dot indiana dot edu" and "phillips at mps dot ohio-state dot edu" respectively. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. If you're a library author and plan on submitting a library for review in the next 3-6 months, send Ron or John a short description of your library and we'll add it to the Libraries Under Construction below. We know that there are many libraries that are near completion, but we have hard time keeping track all of them. Please keep us informed about your progress. Review Queue ============ * Finite State Machines * Property Map (fast-track) * Graph (fast-track) * Lexer * Thread-Safe Signals * Boost.Range (Update) * Shifted Pointer * DataFlow Signals * Logging * Futures (Braddock Gaskill) * Futures (Anthony Williams) * Join (Yigong Liu) * Pimpl (Vladimir Batov) -------------------- Finite State Machines --------------------- :Author: Andrey Semashev :Review Manager: Martin Vuille :Download: `Boost Sandbox Vault <http://tinyurl.com/yjozfn>`__ :Description: The Boost.FSM library is an implementation of FSM (stands for Finite State Machine) programming concept. The main goals of the library are: * Simplicity. It should be very simple to create state machines using this library. * Performance. The state machine infrastructure should not be very time and memory-consuming in order to be applicable in more use cases. * Extensibility. A developer may want to add more states to an existing state machine. A developer should also be able to specify additional transitions and events for the machine with minimum modifications to the existing code. Property Map (fast-track) ------------------------- :Author: Andrew Sutton :Review Manager: Jeremy Siek :Download: http://svn.boost.org/svn/boost/sandbox/graph-v2 :Description: A number of additions and modifications to the Property Map Library, including: * A constant-valued property map, useful for naturally unweighted graphs. * A noop-writing property map, useful when you have to provide an argument, but just don't care about the output. * See `ChangeLog <http://svn.boost.org/trac/boost/browser/sandbox/ graph-v2/libs/property_map/ChangeLog>`__ for details. Graph (fast-track) ------------------ :Author: Andrew Sutton :Review Manager: Jeremy Siek :Download: http://svn.boost.org/svn/boost/sandbox/graph-v2 :Description: A number of additions and modifications to the Graph Library, including: * Two new graph classes (undirected and directed) which are intended to make the library more approachable for new developers * A suite of graph measures including degree and closeness centrality, mean geodesic distance, eccentricity, and clustering coefficients. * An algorithm for visiting all cycles in a directed graph (Tiernan's from 1970ish). It works for undirected graphs too, but reports cycles twice (one for each direction). * An algorithm for visiting all the cliques a graph (Bron&Kerbosch). Works for both directed and undirected. * Derived graph measures radius and diameter (from eccentricity) and girth and circumference (from Tiernan), and clique number (from Bron&Kerbosch). * An exterior_property class that helps hides some of the weirdness with exterior properties. * run-time and compile-time tests for the new algorithms. * a substantial amount of documentation * Graph cores, implemented by David Gleich (@Stanford University) * Deterministic graph generators - capable of creating or inducing specific types of graphs over a vertex set (e.g., star graph, wheel graph, prism graph, etc). There are several other specific types that could be added to this, but I haven't had the time just yet. Lexer ----- :Author: Ben Hanson :Review Manager: Eric Neibler :Download: `Boost Sandbox Vault <http://boost-consulting.com/vault/ index.php? action=downloadfile&filename=boost.lexer.zip&directory=Strings%20-% 20Text%20Processing&>`__ :Description: A programmable lexical analyser generator inspired by 'flex'. Like flex, it is programmed by the use of regular expressions and outputs a state machine as a number of DFAs utilising equivalence classes for compression. Thread-Safe Signals ------------------- :Author: Frank Hess :Review Manager: Need Volunteer :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?&direction=0&order=&directory=thread_safe_signals>`__ :Description: A thread-safe implementation of Boost.Signals that has some interface changes to accommodate thread safety, mostly with respect to automatic connection management. Boost.Range (Update) -------------------- :Author: Neil Groves :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=range_ex.zip&directory=>`__ :Description: A significant update of the range library, including range adapters. Shifted Pointer --------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?&direction=0&order=&directory=Memory>`__ :Description: Smart pointers are in general optimized for a specific resource (memory usage, CPU cycles, user friendliness, ...) depending on what the user need to make the most of. The purpose of this smart pointer is mainly to allocate the reference counter (or owner) and the object itself at the same time so that dynamic memory management is simplified thus accelerated and cheaper on the memory map. DataFlow Signals ---------------- :Author: Stjepan Rajko :Review Manager: Needed :Download: http://dancinghacker.com/code/dataflow/ :Description: Dataflow is a generic library for dataflow programming. Dataflow programs can typically be expressed as a graph in which vertices represent components that process data, and edges represent the flow of data between the components. As such, dataflow programs can be easily reconfigured by changing the components and/or the connections. Logging ------- :Author: John Torjo :Review Manager: Gennadiy Rozental :Download: http://torjo.com/log2/ :Description: Used properly, logging is a very powerful tool. Besides aiding debugging/testing, it can also show you how your application is used. The Boost Logging Library allows just for that, supporting a lot of scenarios, ranging from very simple (dumping all to one destination), to very complex (multiple logs, some enabled/some not, levels, etc). It features a very simple and flexible interface, efficient filtering of messages, thread-safety, formatters and destinations, easy manipulation of logs, finding the best logger/filter classes based on your application's needs, you can define your own macros and much more! Futures ------- :Author: Braddock Gaskill :Review Manager: Needed :Download: http://braddock.com/~braddock/future/ :Description: The goal of the boost.future library is to provide a definitive future implementation with the best features of the numerous implementations, proposals, and academic papers floating around, in the hopes to avoid multiple incompatible future implementations in libraries of related concepts (coroutines, active objects, asio, etc). This library hopes to explore the combined implementation of the best future concepts. Futures ------- :Author: Anthony Williams :Review Manager: Needed :Download: http://www.justsoftwaresolutions.co.uk/files/ n2561_future.hpp (code) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/ n2561.html (description) :Description: This paper proposes a kind of return buffer that takes a value (or an exception) in one (sub-)thread and provides the value in another (controlling) thread. This buffer provides essentially two interfaces: * an interface to assign a value as class promise and * an interface to wait for, query and retrieve the value (or exception) from the buffer as classes unique_future and shared_future. While a unique_future provides move semantics where the value (or exception) can be retrieved only once, the shared_future provides copy semantics where the value can be retrieved arbitrarily often. A typical procedure for working with promises and futures looks like: * control thread creates a promise, * control thread gets associated future from promise, * control thread starts sub-thread, * sub-thread calls actual function and assigns the return value to the promise, * control thread waits for future to become ready, * control thread retrieves value from future. Also proposed is a packaged_task that wraps one callable object and provides another one that can be started in its own thread and assigns the return value (or exception) to a return buffer that can be accessed through one of the future classes. With a packaged_task a typical procedure looks like: * control thread creates a packaged_task with a callable object, * control thread gets associated future from packaged_task, * control thread starts sub-thread, which invokes the packaged_task, * packaged_task calls the callable function and assigns the return value, * control thread waits for future to become ready, * control thread retrieves value from future. Notice that we are in the unusual position of having two very different libraries with the same goal in the queue at the same time. The Review Wizards would appreciate a discussion of the best way to hold these two reviews to produce the best possible addition to Boost. Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: `Boost Sandbox Vault <http://www.boost-consulting.com/ vault/index.php?action=downloadfile&filename=Pimpl.zip&directory=&>`__ http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Libraries under development =========================== Please let us know of any libraries you are currently developing that you intend to submit for review.

3 4

Interest in properties library?
by Sergey Sadovnikov 11 Jul '08

11 Jul '08

Hello All, Would there be any interest in another C++ properties implementation? I know that boost sandbox already contains properties library. But I can offer another implementation of such library with some advantages like this: - Simple properties set initialization. Only one call from the constructor: class SomeClass { public: //... SomeClass() : properties__(this) {/*...*/} //... }; - Many kins of properties. Now implemented: Simple properties similar to datamembers. Properties bindable to getter/setter methods of container class. Properties bindable to arbitrary methods. Index properties with up to three levels of indirection. - Properties could be "abstract" and need implementation in derived classes - In-place initialization of simple properties. For example: PROPERTY_I(int, ContainerSize, 10) - Generic runtime access to the properties via names: SomeClassWithProps c; int val; c.properties__.invoke_get("ContainerSize", var(val) = boost::lambda::_1); c.properties__.invoke_set("ContainerSize", 20); - Runtime enumeration of properties: // Property visitor function template<typename P> void PropertyEnumerator(const std::string& propertyName, P SomeClassWithProps::* propInfo) { //... ] // Properties enumeration: SomeClassWithProps::properties__::enum_s(PropertyEnumerator); - Simple serialization of properties: template<typename Ar> void serialize(Ar& ar, const unsigned int ver) { ar & properties__; } - Quite simple definition in class. A piece of code from real project: // Example of abstract properties definition in the base class: class IPlayerCraft : public IAirObject { public: IPlayerCraft() : properties__(this) {;} virtual ~IPlayerCraft(){} // Craft status enum ECRAFTSTATUS { csREADY =0, csFLYING, csREPAIRING, csREFUELING, csREARMING, csTRANSFERING, csMAXCOUNT }; PROPERTIES(IPlayerCraft, // Craft name ABSTRACT_RW_PROPERTY(std::wstring, Name) // Static craft info ABSTRACT_RO_PROPERTY(SCraftInfo const*, Info) // Craft home base ABSTRACT_RO_PROPERTY(IBase const*, HomeBase) // Is craft on the base? ABSTRACT_RO_PROPERTY(bool, IsOnTheBase) // Craft status ABSTRACT_RO_PROPERTY(ECRAFTSTATUS, Status) // Current craft speed ABSTRACT_RO_PROPERTY(TPARAM, Speed) // Craft weapon ABSTRACT_INDEX_PROPERTY(IItem*, CraftWeapon, 1, (CraftSlotCoord)) // Craft weapon ammo ABSTRACT_RO_INDEX_PROPERTY(TPARAM, CraftWeaponAmmo, 1, (CraftSlotCoord)) ); //... }; // Implementation class class PlayerCraft : public IPlayerCraft { public: PlayerCraft(SCraftInfo const*, Player* player); ~PlayerCraft(); PROPERTIES(PlayerCraft, IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY(std::wstring, Name)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY(SCraftInfo const*, Info)) IMPLEMENT_PROPERTY(IPlayerCraft, RO_PROPERTY(IBase const*, HomeBase, GetHomeBase)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY(bool, IsOnTheBase)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY_I(ECRAFTSTATUS, Status, csTRANSFERING)) IMPLEMENT_PROPERTY(IPlayerCraft, PROPERTY_I(TPARAM, Speed, 0)) IMPLEMENT_PROPERTY(IPlayerCraft, INDEX_PROPERTY(IItem*, CraftWeapon, 1, (CraftSlotCoord), GetCraftWeapon, SetCraftWeapon)) IMPLEMENT_PROPERTY(IPlayerCraft, RO_INDEX_PROPERTY(TPARAM, CraftWeaponAmmo, 1, (CraftSlotCoord), GetCraftWeaponAmmo)) ); // ... IBase const* GetHomeBase() const {return m_HomeBase;} private: // ... IItem* GetCraftWeapon(int slotId) const; void SetCraftWeapon(int slotId, IItem* weapon); TPARAM GetCraftWeaponAmmo(int slotId) const; }; As you can see, properties definition based on boost::preprocessor. It allows to implement quite complex background (with many special abilities) for quite simple front-end. It is assumed what access to the properties in many cases is same as access to the datamember: PlayerCraft craft; std::string craft_name = craft.Name; //... IItem* weapon = craft.CraftWeapon[1]; And there is special access form needs in some cases: craft.Name(); or craft.Name.get(); If there is an interest in such properties implementation I could start prepare code for formal library review. -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru

2 1

Recursive iterator/range adaptors
by Mathias Gaunard 11 Jul '08

11 Jul '08

The traversal library that has been discussed allows tree-like traversal of structures using a functional approach. I suggest an alternative approach: a range-based one. It certainly has limitations: ranges are monomorphic. So you can only do it if is_same< typename range_value<Range>::type, typename range_value< typename range_value<Range> >::type >. However, it would be very practical to use, since you could simply use a foreach loop to perform depth-first search and stop iteration whenever you like. Also, it is lazy and you can combine it easily with other range adaptors (filtering, transforming...) or algorithms. For performance, one would need to provide a way to get the father range of a given range. Maybe that's the occasion to create a new concept. Otherwise iterators will need to have their own stack. Did anyone ever work on that? Does it look like a good idea?

2 3

[pool] segfault
by Phil Bouchard 11 Jul '08

11 Jul '08

I was testing my own "shifted_ptr_test2.cpp" on RHEL 4.5 using Gcc 3.4.6 and the following object declared in "sh_owned_base_nt.hpp" caused a segmentation violation inside its destructor. It doesn't seem to happen on Windows, just Linux: pool owned_base::pool_; // derives from boost::pool<> Thanks, -Phil

3 7

[graph] generating CSR graph from undirected
by Mojmir Svoboda 11 Jul '08

11 Jul '08

hello, i suspect there is something wrong with assign routine in compressed_sparse_row_graph.hpp. when i am constructing directed csr from undirected one via // From any graph (slow and uses a lot of memory) // Requires IncidenceGraph, a vertex index map, and a vertex(n, g) function // Internal helper function template<typename Graph, typename VertexIndexMap> void assign(const Graph& g, const VertexIndexMap& vi, vertices_size_type numverts, edges_size_type numedges) { inherited_vertex_properties::resize(numverts); m_rowstart.resize(numverts + 1); m_column.resize(numedges); it overwrites non-allocated memory, because the number of edges is in fact doubled.. is it an imperfection or am i doing something stupid? have a nice day, mojmir

1 0

Boost DateTime package question
by Mohnish Kodnani 10 Jul '08

10 Jul '08

Hi All, I have a question regarding the boost DateTime package. In our application we have to support storing time from various time zone in UTC and we need to know DST of various timezones. We are currently using standard C runtime libraries for this purpose on various platforms like windows , linux, aix, hpux. My question, Recently there has been a need to store dates prior to epoch in our system and this causes problems since none of the standard C runtime libraries support dates prior to EPOCH. We are also interested in DST settings prior to EPOCH, since in our experiments it looks like Java knows DST till 1942 or in its vicinity, however C only deals with dates after epoch. Our server is in C++ and client in Java, so we have issues here when client sends a date prior to 1942 and we have to store its UTC value, we cannot do this since C runtime mktime like functions dont work. Does Boost DateTime package provide this functionality, if not is that in the plans. >From what I read so far it looks like this package does not have this functionality, but has the functionality to create our own rules, however this is difficult considering all countries around the world, it would be good if we had something similar to C runtime. Please let me know. thanks Mohnish

1 0

[constrained_value] Formal review request
by Robert Kawulak 10 Jul '08

10 Jul '08

Dear Boosters, I'm glad to say the Boost Constrained Value library is finally ready for a formal review. To remind what this library is about, an excerpt from the motivation section of the documentation is attached at the bottom of this message. Jeff, you volunteered to be the review manager - is your proposition still up to date? If so, I'd be thankful if you could do the work. ;-) The code and documentation can be downloaded here: http://rk.go.pl/f/constrained_value.zip The documentation is also available online here: http://rk.go.pl/r/constrained_value The only thing that's missing is test programs - I will try to add them during/after the review. The changes made since previous version: - rewritten the documentation at some points and added tutorial, - no more value generators - direct types or MPL integral constants are used instead, - bounded types use bounds exclusion instead of inclusion (so bounds are included by default in all cases), - changed order and default values of some of template parameters, - removed throw_verbose_exception error policy, - made other minor fixes and improvements. As always, feedback is welcome. Best regards, Robert Kawulak FROM THE MOTIVATION SECTION OF THE DOCUMENTATION: The Boost Constrained Value library contains class templates useful for creating constrained objects. A simple example is an object representing an hour of a day, for which only integers from the range [0, 23] are valid values: bounded_int<int, 0, 23>::type hour; hour = 20; // OK hour = 26; // exception! Behavior in case of assignment of an invalid value can be customized. For instance, instead of throwing an exception as in the example above, the value may be adjusted to meet the constraint: wrapping_int<int, 0, 255>::type buffer_index; buffer_index = 257; // OK: adjusts the value to fit in the range by wrapping it assert( buffer_index == 1 ); The library doesn't focus only on bounded objects as in the examples above -- virtually any constraint can be imposed by using a predicate: // constraint (a predicate) struct is_odd { bool operator () (int i) const { return (i % 2) != 0; } }; // and the usage is as simple as: constrained<int, is_odd> odd_int = 1; odd_int += 2; // OK ++odd_int; // exception! The library has a policy-based design to allow for flexibility in defining constraints and behavior in case of assignment of invalid values. Policies may be configured at compile-time for maximum efficiency or may be changeable at runtime if such dynamic functionality is needed.

4 5

[test][sun-5.7 -5.8][trunk] regressions for Boost.Test starting at revision 47170
by JOAQUIN M. LOPEZ MUÑOZ 10 Jul '08

10 Jul '08

Hello, Recent updates to the trunk version of Boost.Test have resulted in a massive number of regressions for Sun 57 and 5.8, as shown for instance in: http://tinyurl.com/5lm7ha http://tinyurl.com/66qcze The error message is "../boost/test/utils/iterator/input_iterator_facade.hpp", line 56: Error: Multiple declaration for input_iterator_facade. After examining the updates to Boost.Test in the last days I think I found the change that's causing the regressions: http://svn.boost.org/trac/boost/changeset/47170/trunk/boost/test The change in line 26 of boost/test/impl/unit_test_main.ipp causes the header <boost/test/utils/iterator/token_iterator.hpp> to be included where previously that was not the case. This in turns includes <boost/test/utils/iterator/input_iterator_facade.hpp>, which contains the following problematic code (for Sun 5.7-8) around line 25: #if defined(BOOST_NO_MEMBER_TEMPLATE_FRIENDS) || BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x551)) public: #else template <class I, class V, class R, class TC> friend class input_iterator_facade; #endif This perfectly correct friend declaration is not processed properly by Sun 5.7 and 5.8 hence the error. May I ask that the problem be fixed by applying either one of the following? 1. Add a workaround for Sun 5.7-8 at line 35 of boost/test/utils/iterator/input_iterator_facade.hpp 2. Add a !workaround for Sun 5.7-8 at line 26 of boost/test/impl/unit_test_main.ipp Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[inspect] A few issues in non-ASCII checker
by Gennaro Prota 10 Jul '08

10 Jul '08

Hi, I had a summary look at the changes made to Boost.Inspect (since I last saw it) and noticed a few issues: * the "*A*" marker is used either for broken links, invalid urls etc. *and* non-ASCII chars * "non-ASCII" itself looks like a misleading name: see the string gPunct, defined in ascii_check.cpp * non portable (though widely portable :-)) code: if ( c >= 'a' && c <= 'z' ) return false; if ( c >= 'A' && c <= 'Z' ) return false; if ( c >= '0' && c <= '9' ) return false; If there aren't problems with standard library support I'd suggest replacing the above with if ( std::isalnum( static_cast< int >( c ), std::locale::classic() ) ) Similarly for the subsequent isspace-like tests * again in ascii_check.cpp there's some scaffolding to get a line number from a file position; this is needed in other inspector classes as well, and is done much differently. I think it is worth unifying this part and make it available in one place -- Genny

3 3

public beta test ?
by Ruediger Berlich 10 Jul '08

10 Jul '08

Hi there, I'd like to suggest a public beta test as part of the release procedure. >From what I can see, while the trunk version is available to everybody, there is no formal call for external testing. But this would increase visibility of Boost and would likely reveal a number of additional bugs. Best, Ruediger

2 2

a little imperfection in options_description.cpp example (program options)
by Guido Ziliotti 10 Jul '08

10 Jul '08

// A helper function to simplify the main part. template<class T> ostream& operator<<(ostream& os, const vector<T>& v) { copy(v.begin(), v.end(), ostream_iterator<T>(cout, " ")); /* this is line 21 */ return os; } SHOULD BE REPLACED WITH // A helper function to simplify the main part. template<class T> ostream& operator<<(ostream& os, const vector<T>& v) { copy(v.begin(), v.end(), ostream_iterator<T>(os, " ")); /* this is line 21: "os" replaces "cout" */ return os; }

2 1

[1.36.0] Unmerged SVN Properties
by Beman Dawes 10 Jul '08

10 Jul '08

There are a whole bunch (see below) of messages from the unmerged changes analysis that look like this: Property changes on: tr1/tr1/valarray ___________________________________________________________________ Name: svn:eol-style + native Name: svn:mime-type + text/plain I guess these need to be merged from trunk to branches/release like any other change. --Beman Here is the full list: Property changes on: archive/detail/polymorphic_iarchive_route.hpp Property changes on: archive/detail/polymorphic_oarchive_route.hpp Property changes on: archive/xml_archive_exception.hpp Property changes on: compatibility/cpp_c_headers/cassert Property changes on: compatibility/cpp_c_headers/cctype Property changes on: compatibility/cpp_c_headers/cerrno Property changes on: compatibility/cpp_c_headers/cfloat Property changes on: compatibility/cpp_c_headers/climits Property changes on: compatibility/cpp_c_headers/clocale Property changes on: compatibility/cpp_c_headers/cmath Property changes on: compatibility/cpp_c_headers/csetjmp Property changes on: compatibility/cpp_c_headers/csignal Property changes on: compatibility/cpp_c_headers/cstdarg Property changes on: compatibility/cpp_c_headers/cstddef Property changes on: compatibility/cpp_c_headers/cstdio Property changes on: compatibility/cpp_c_headers/cstdlib Property changes on: compatibility/cpp_c_headers/cstring Property changes on: compatibility/cpp_c_headers/ctime Property changes on: compatibility/cpp_c_headers/cwchar Property changes on: compatibility/cpp_c_headers/cwctype Property changes on: config/warning_disable.hpp Property changes on: detail/lightweight_thread.hpp Property changes on: detail/sp_convertible.hpp Property changes on: detail/sp_counted_base_spin.hpp Property changes on: detail/spinlock.hpp Property changes on: detail/spinlock_gcc_arm.hpp Property changes on: detail/spinlock_nt.hpp Property changes on: detail/spinlock_pool.hpp Property changes on: detail/spinlock_pt.hpp Property changes on: detail/spinlock_sync.hpp Property changes on: detail/spinlock_w32.hpp Property changes on: detail/yield_k.hpp Property changes on: graph/edmonds_karp_max_flow.hpp Property changes on: graph/r_c_shortest_paths.hpp Property changes on: iostreams/detail/execute.hpp Property changes on: iostreams/detail/file_handle.hpp Property changes on: iostreams/detail/file_times.hpp Property changes on: iostreams/detail/functional.hpp Property changes on: iostreams/detail/path.hpp Property changes on: iostreams/filter/grep.hpp Property changes on: make_shared.hpp Property changes on: math/distributions/detail/generic_mode.hpp Property changes on: math/distributions/detail/generic_quantile.hpp Property changes on: math/distributions/non_central_beta.hpp Property changes on: math/distributions/non_central_chi_squared.hpp Property changes on: math/distributions/non_central_f.hpp Property changes on: math/distributions/non_central_t.hpp Property changes on: math/special_functions/detail/lanczos_sse2.hpp Property changes on: math/special_functions/detail/round_fwd.hpp Property changes on: math/special_functions/expint.hpp Property changes on: math/special_functions/modf.hpp Property changes on: math/special_functions/next.hpp Property changes on: math/special_functions/pow.hpp Property changes on: math/special_functions/round.hpp Property changes on: math/special_functions/trunc.hpp Property changes on: math/special_functions/zeta.hpp Property changes on: math/tr1.hpp Property changes on: memory_order.hpp Property changes on: pool/detail/for.m4 Property changes on: pool/detail/pool_construct.inc Property changes on: pool/detail/pool_construct.m4 Property changes on: pool/detail/pool_construct_simple.inc Property changes on: pool/detail/pool_construct_simple.m4 Property changes on: property_tree/detail/exceptions_implementation.hpp Property changes on: property_tree/detail/file_parser_error.hpp Property changes on: property_tree/detail/info_parser_error.hpp Property changes on: property_tree/detail/info_parser_read.hpp Property changes on: property_tree/detail/info_parser_utils.hpp Property changes on: property_tree/detail/info_parser_write.hpp Property changes on: property_tree/detail/info_parser_writer_settings.hpp Property changes on: property_tree/detail/json_parser_error.hpp Property changes on: property_tree/detail/json_parser_read.hpp Property changes on: property_tree/detail/json_parser_write.hpp Property changes on: property_tree/detail/path_implementation.hpp Property changes on: property_tree/detail/ptree_implementation.hpp Property changes on: property_tree/detail/ptree_utils.hpp Property changes on: property_tree/detail/pugxml.hpp Property changes on: property_tree/detail/rapidxml.hpp Property changes on: property_tree/detail/translator_implementation.hpp Property changes on: property_tree/detail/xml_parser_error.hpp Property changes on: property_tree/detail/xml_parser_flags.hpp Property changes on: property_tree/detail/xml_parser_read_pugixml.hpp Property changes on: property_tree/detail/xml_parser_read_pugxml.hpp Property changes on: property_tree/detail/xml_parser_read_rapidxml.hpp Property changes on: property_tree/detail/xml_parser_read_spirit.hpp Property changes on: property_tree/detail/xml_parser_read_tinyxml.hpp Property changes on: property_tree/detail/xml_parser_utils.hpp Property changes on: property_tree/detail/xml_parser_write.hpp Property changes on: property_tree/detail/xml_parser_writer_settings.hpp Property changes on: property_tree/info_parser.hpp Property changes on: property_tree/ini_parser.hpp Property changes on: property_tree/json_parser.hpp Property changes on: property_tree/ptree.hpp Property changes on: property_tree/ptree_fwd.hpp Property changes on: property_tree/ptree_serialization.hpp Property changes on: property_tree/xml_parser.hpp Property changes on: serialization/assume_abstract.hpp Property changes on: serialization/factory.hpp Property changes on: serialization/singleton.hpp Property changes on: serialization/vector_134.hpp Property changes on: statechart/detail/reaction_dispatcher.hpp Property changes on: swap.hpp Property changes on: test/utils/lazy_ostream.hpp Property changes on: tr1/tr1/algorithm Property changes on: tr1/tr1/array Property changes on: tr1/tr1/bitset Property changes on: tr1/tr1/complex Property changes on: tr1/tr1/deque Property changes on: tr1/tr1/exception Property changes on: tr1/tr1/fstream Property changes on: tr1/tr1/functional Property changes on: tr1/tr1/iomanip Property changes on: tr1/tr1/ios Property changes on: tr1/tr1/iostream Property changes on: tr1/tr1/istream Property changes on: tr1/tr1/iterator Property changes on: tr1/tr1/limits Property changes on: tr1/tr1/list Property changes on: tr1/tr1/locale Property changes on: tr1/tr1/map Property changes on: tr1/tr1/memory Property changes on: tr1/tr1/new Property changes on: tr1/tr1/numeric Property changes on: tr1/tr1/ostream Property changes on: tr1/tr1/queue Property changes on: tr1/tr1/random Property changes on: tr1/tr1/regex Property changes on: tr1/tr1/set Property changes on: tr1/tr1/sstream Property changes on: tr1/tr1/stack Property changes on: tr1/tr1/stdexcept Property changes on: tr1/tr1/streambuf Property changes on: tr1/tr1/string Property changes on: tr1/tr1/strstream Property changes on: tr1/tr1/tuple Property changes on: tr1/tr1/type_traits Property changes on: tr1/tr1/typeinfo Property changes on: tr1/tr1/utility Property changes on: tr1/tr1/valarray Property changes on: tr1/tr1/vector Property changes on: utility/swap.hpp

1 0

[extension] Problem with reference types
by Robert Dailey 10 Jul '08

10 Jul '08

I have the following exported factory function in a DLL I'm building on Windows: extern "C" void BOOST_EXTENSION_EXPORT_DECL export_aspects( boost::extensions::factory_map& fm ) { using namespace vfx::aspects; using namespace vfx::messenger; fm.get<Aspect, MessageReader&, unsigned int>()[0].set<Appearance>(); fm.get<Aspect, MessageReader&, unsigned int>()[1].set<Health>(); } As you can see, I am specifying that each class accepts a single construction parameter- a reference to a MessageReader object. However, this isn't compiling because I don't think that it likes reference types. How can I specify that the constructor takes a reference? boost::ref? I would post the compiler warnings & errors I'm getting, however they're exceedingly large. Most of the warnings and errors are coming from std::map, basically complaining that it's trying to create a map of reference types, which can't possibly work. Help is appreciated. As an unrelated note, I would really like to see the template parameters cleaned up. There's at least 5 places I've had to redundantly specify the same 3 template parameters (like in the example above). I already brought this up in another thread, but I can't tell you how important it is. If I ever change the number of construction parameters my Appearance or Health classes take (mapped above), I will have to shift through 5 or more files simply to adjust all of the template parameters to make everything compile.

1 1

[asio] std::ostream request_stream
by simonvifr＠voila.fr 09 Jul '08

09 Jul '08

Good morning, In the examples that illustrate the use of Boost.Asio in more complex applications, there is the "boost_asio/example/http/client/sync_client.cpp" example. In this example, the following code is written : boost::asio::streambuf request; std::ostream request_stream(&request); request_stream << "GET " << argv[2] << " HTTP/1.0\r\n"; request_stream << "Host: " << argv[1] << "\r\n"; request_stream << "Accept: */*\r\n"; request_stream << "Connection: close\r\n\r\n"; I would like to use the POST method with parameters instead of GET method, and to set the "Content-Type" property. But I do not how to do. Could you tell me more about using the POST method and setting the "Content-Type" property ? Could you also tell me where I can find documentation about it ? Thank you for your response, Regards. ____________________________________________________ Sur le mail Voila, vous pouvez personnaliser l’anti-spam ! http://mail.voila.fr

1 0

An elegant way to initialize an instance of boost::any with a C-style string constant
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I would like to improve usage of boost::any with text (char*) constants. This would be the goal: boost::any foo("foo"); boost::any bar; bar = "bar"; Currently the compiler (MSVC 2008 in my case) complains about it: ...\boost\any.hpp(117) : error C2536: 'boost::any::holder< ValueType>::boost::any::holder<ValueType>::held' : cannot specify explicit initializer for arrays There are more ways to make it compiled, all of them either with an extra cast or object construction: boost::any foo(static_cast<const char *>("foo")); boost::any foo((const char *) "foo"); boost::any foo(std::string("foo")); Supposing there is no way to persuade the compiler to consider the constant not to be an array but just a pointer I would suggest adding support for arrays to boost::any. I am sorry if it has been discussed already. I found just one thread without a conclusion (http://lists.boost.org/Archives/boost/2003/01/43460.php) I asked about it in boost.users and got a nice proposal from Niels Dekker (http://thread.gmane.org/gmane.comp.lib.boost.user/37189/focus=37414) I replaced the member "held" in holder<> by a wrapper specialized for arrays: template<typename ValueType> struct wrapper { ValueType data; explicit wrapper(const ValueType & value) : data(value) {} }; template<typename ElementType, std::size_t NumberOfElements> struct wrapper<ElementType[NumberOfElements]> { typename remove_const<ElementType>::type data[NumberOfElements]; explicit wrapper(const ElementType (& value)[NumberOfElements]) { std::copy(value, value + NumberOfElements, data); } }; A new constructor in boost::any makes use of it: template<typename ElementType, std::size_t NumberOfElements> any(const ElementType (& value)[NumberOfElements]) : content(new holder<ElementType[NumberOfElements]>(value)) {} This solution is more complicated but it makes the instance of boost::any own the copy of array just like its for scalar objects. Alternatively, instead of wrapping a copy of the array, I could store just a pointer to it without any other changes in bost::any (I want to use just constants in my example): template<typename ElementType, std::size_t NumberOfElements> any(const ElementType (& value)[NumberOfElements]) : content(new holder<const ElementType*>(value)) {} I am attaching a patch to any.hpp from boost 1.35.0. I could provide a test for it too. What do you think about it? Shall I create a feature request for it? Thank you, Ferda

4 5

Re: [boost] How do you make MPL-compatible template meta-functions?
by joaquin＠tid.es 09 Jul '08

09 Jul '08

Hi Daryle Daryle Walker escribió: > Here's what I'm trying (to redo integer_test.cpp) [...] > BOOST_STATIC_ASSERT > ( (boost::is_same<distinct_integral_bit_counts, > boost::mpl::list_c<int, 8, 16, 32, 64> >) ); > } > I think there are two problems with this: 1. You're passing a *type* (boost::is_same<...>) to BOOST_STATIC_ASSERT when you should be passing a numeric contanst. Append ::value to the type. 2. Even with the correction above the thing won't work because is_same<T,Q> checks for strict equality of the types T and Q; in your case distinct_integral_bit_counts is *not* the same type as boost::mpl::list_c<...>, but only has the same components. You can use boost::mpl::equal to test this: BOOST_STATIC_ASSERT ( (boost::mpl::equal<distinct_integral_bit_counts, boost::mpl::list_c<int, 8, 16, 32> >::value) ); } Other than that, your type_to_digit_count is perfectly lambda-cabable AFAICS. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 4

[Iostreams] Support std::codecvt<char> and std::codecvt_base::noconv in boost::iostreams::code_converter
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I found two problems when using boost::iostreams::code_converter with char as source (internal) type for the conversion. Firstly, I was not able to use facets parameterized with char extracted from std::locale and secondly, my test run in an endless loop if the facet returned std::codecvt_base::noconv from do_in() or do_out(). I would like to use the boost::iostreams::code_converter in a class parametrized either for char or wchar_t using the default std::codecvt. This code works for wchar_t: namespace io = boost::iostreams; class test { io::stream<io::code_converter<xxxodevice, io::default_codecvt> > output; ... }; However I cannot make in templated like this without inheriting from std::codecvt and pasing the inherited type to io::code_converter instead of std::codecvt: template <class C> class test { io::stream<io::code_converter<xxxodevice, std::codecvt<C, char, std::mbstate_t> > output; ... }; The compiler complains about the usage of std::codecvt: error C2248: 'std::codecvt<_Elem,_Byte,_Statype>::~codecvt' : cannot access protected member declared in class 'std::codecvt<_Elem,_Byte,_Statype>' io::detail::codecvt_holder<Codecvt> in codecvt_holder.hpp stores a copy of Codecvt but std::codecvt defines only protected destructor: template<typename Codecvt> struct codecvt_holder { ... Codecvt codecvt_; }; Standard std::codecvt specialized for wchar_t is solved by its explicit specialization storing the pointer: struct default_codecvt { typedef wchar_t intern_type, from_type; typedef char extern_type, to_type; typedef std::mbstate_t state_type; }; template<> struct codecvt_holder<default_codecvt> { ... const codecvt_type* codecvt_; }; Obviously it supports the most usual usage with an instance extracted from std::locale which owns it: typedef std::codecvt<wchar_t, char, std::mbstate_t> codecvt_type; ... = &std::use_facet<codecvt_type>(locale); What about facets not converting from sequence of wchat_ts but chars? If I imbue such facet to a locale I am not able to extract it and use it in io::code_converter: template <class C> class test { io::stream<io::code_converter<xxxodevice, std::codecvt<C, char, std::mbstate_t> > output; void imbue(std::locale const & locale) { output.imbue(locale); } }; I helped it by converting io::detail::default_codecvt and the specialization of io::detail::codecvt_holder for it in codecvt_holder.hpp to this: template <class C> struct basic_default_codecvt { typedef C intern_type, from_type; ... }; template <class C> struct codecvt_holder<basic_default_codecvt<C> > { typedef std::codecvt<C, char, std::mbstate_t> codecvt_type; ... }; typedef basic_default_codecvt<wchar_t> default_codecvt; Now I was able to compile my slightly modified code: template <class C> class test { io::stream<io::code_converter<xxxodevice, io::detail::basic_default_codecvt<C> > output; void imbue(std::locale const & locale) { output.imbue(locale); } }; After being able to compile it a simple output code run endlessly. I found out that the facet in the default locale did not convert but it did not return true from always_noconv() from some reason. io::code_converter can cope with it - it copies the input buffer to the output one but it does not increase the pointer to the next character in the output buffer nor does it decrease the total bytes processed in io::code_converter::write. I am not sure about the behavior of the coverter if the facet returns std::codecvt_base::noconv. Currently it copies the buffer if internal type is the same as external one (both char) otherwise it does nothing (?). Should it not copy or assert if they are diferent? At least the writing should succeed if there was no conversion done and the characters were copied. I tried to modify the code accordingly and it succeeded then. I am attaching a patch to code_converter.hpp and codecvt_holder.hpp from boost 1.35.0. I could provide a test for it too. Thank you, Ferda

1 0

[Iostreams] What about making code_converter from boost::iostreams flushable?
by Ferdinand Prantl 09 Jul '08

09 Jul '08

Hello, I would like to wrap an output stream buffer (std::streambuf) with boost::iostreams::code_converter to be able to use it both raw and with ont-the-fly encoding by the boost::iostreams::default_facet. namespace io = boost::iostreams; xxxstream stream; stream << "raw"; io::stream<io::code_converter<xxxodevice> > wrapper(*stream.rdbuf()); wrapper << L" and converted"; stream << " and another raw"; Running the code writes "raw and another raw and converted" instead of "raw and converted and another raw" to the stream. I found that first in destructor of io::code_converter is the conversion buffer flushed causing the output. I could create a new instance of io::code_converter for every output and always close it: namespace io = boost::iostreams; xxxstream stream; stream << "raw"; { io::stream<io::code_converter<xxxodevice> > wrapper(*stream.rdbuf()); wrapper << L" and converted"; } stream << " and another raw"; But I would feel better being able to reuse the io::code_converter. (Actually, I have it as a private field in a class now.) I would like to make the io::code_converter flushable to be able to combine the output more conveniently: namespace io = boost::iostreams; xxxstream stream; stream << "raw"; io::stream<io::code_converter<xxxodevice> > wrapper(*stream.rdbuf()); wrapper << L" and converted" << std::flush; stream << " and another raw"; I added the support to io::code_converter rather that inheriting from it. What do you think about it? Would you accept it to boost or is it better to make flushable my inherited class? I am attaching a patch to code_converter.hpp from boost 1.35.0. I could provide a test for it too. Thank you, Ferda

1 0