September 2007 - Boost - lists.preview.boost.org

Repository Layout
by Frank Birbacher 08 Sep '07

08 Sep '07

Hi! I'm trying to think of a usable repository layout. The features it should provide IMHO: (1) release-ready branch, which is updated by the release manager/team and includes latest additions for the next release as well as bug fixes from the last release. this one is to prepare for a major release (2) release-fixing branch, which is updated by the release manager/team and only gets bug fixes. this one is to provide support/fixes for the last release (3) a main development branch for each library in boost. this would be updated by the library maintainer. this directory should hold changesets which the release manager/team merges into (1) (4) testing branches for each library which can hold various bugfixes and which are used for testing the changes before they are merged into the release-ready (1) and release-fixing branches (2). (5) possibly branches for each library which are "private" to the library and used by the maintainer as she likes To keep (3), (4), and (5) together, I think the following directory structre would do: /libraries /iostreams /trunk (3) /branches /testing_bug143 (4) /trying_refactor (5) /serialization /trunk (3) /branches /... /tags /... (also 5) /... /release /release-1-35-ready (1) /release-1-34-fixing (2) /tags /release-1-34 /release-1-34-1 /... Library work flow: Bring /library/foo/trunk in sync with last release. Fix bugs in this trunk. Report to release manager/team: "please include /libraries/foo/trunk -c 39042 into release, its a bug fix for ticket #374". Maybe branch off from trunk of foo or from latest release in order to develop new feature. Use this branch for heavy testing, too. When ready, report: "please include /libraries/foo/branches/new_feature -r 40000:42000 into release-ready, its a new feature requested in #845". Release work flow: When receiving a "bug fix report" merge it into working copy of the release-fixing branch and do local testing. maybe include some more requests. After that "commit" and create a tarball for external testing. Committing the only locally tested state will preserve this exact state in the subversion. I think this is needed to provide a tarball and an identical copy in repository. If tests are successful try the same bug fix in release-ready branch and do the same testing. Ok. I currently don't know how testing is done exactly, but other messages on the list indicated testing each bug fix as it is merged into the release branch. This seemed to require building a tarball and giving it away for testing. I think this is a process which takes days. So how long would it take to include a couple of fixes into the release-fixing branch? How much testing is done up to today? Frank

2 1

[intrusive] Info on ongoing interface changes. Need for ideas.
by Ion Gaztañaga 08 Sep '07

08 Sep '07

Hi Boost.Intrusive user, ------- 1 Info ------- As you might know, recently an interface change was discussed for Boost.Intrusive and more configurability was required. The discussion lead to the following templatized option specifiers: typedef list < member_hook<Hook> , constant_time_size<false> , size_type<unsigned short> , any_future_options<option_value> .... > MyList; I've implemented this approach and my first results were not very encouraging: list_test obj grew from 3.5MB to 11MB, compilation times skyrocketed, debug symbol files were really big... However, I started shortcutting internal symbols to reduce symbol length and I've reduced the bloat to 4.5MB obj and moderately increased compilation time. The executable has grown a bit (5-10% in release mode) but I still don't know why (maybe I still get some long symbols there but machine code has not grown). My conclusion is: Be careful with meta-programming. The current implementation, if the user does not specify any hook or value traits, the container automatically uses the corresponding base hook with the default tag, so defining a class to be insertable in different containers is pretty easy: using namespace boost::intrusive; class my_class : list_base_hook< link<auto_unlink> > , slist_base_hook< link<safe_unlink>, void_pointer<offset_ptr<void> > , set_base_hook<> {}; typedef list<my_class> MyList; typedef slist<my_class> MySlist; typedef set<my_class> MySet; I plan to upload a version with the new interface to get more comments. -------------------------- 2 Configuratility problem -------------------------- Now that compile_time configurability is more self-describing (which was one of the main goals of the change) we must also allow stateful option configurability. This means that constructors of containers must take objects of configured stateful policies. stateful policies can be: * Stateful ValueTraits * Comparison or Equality predicates * Hash functors * Any new stateful option we might imagine So a container might end with a long list of initializers: unordered_set ( bucket_info , const hash &h = hash() , const equal &e = equal() , const value_traits &v = value_traits() , const my_new_option &n() , ....) Obviously, if the user has to pass a stateful value_traits, he has to also specify all previous parameters. Similarly to template parameters, I would like to achieve something like: typedef unoredered_set < value_traits<my_stateful_value_traits> , hash <my_hash> , equal<my_stateful_equal> > MyUset; //my_value_traits_conf is passed to the internally built //value traits, all other options are default constructed MyUset u1 (to_value_traits(my_value_traits_conf)); //my_stateful_equal_conf is passed to the internally built //equal, all other options are default constructed MyUset u2 (to_equal(my_stateful_equal_conf)); //my_stateful_equal_conf is passed to the internally built //equal, _value_traits_conf is passed to the internally built //value traits, all other options are default constructed MyUset u3 (to_equal(my_stateful_equal_conf) ,to_value_traits(my_value_traits_conf)); I've thought about implementing this with a brute-force approach but since I know there are people who knows much more than me in this configurability issues, I would like to know how could we efficiently implement this. Compile-time performance appreciated. Big props guaranteed in the documentation. Regards, Ion

1 0

Interest in a small Enum IO utility?
by Marcus Lindblom 08 Sep '07

08 Sep '07

Hi, I have some code that helps with defining iostream-operators for enums. We use this in our C++<->xml bindings. Basically, it's just two maps (string->enum & enum<-string) and some syntactic sugar. However, I happen to think it is quite neat and so figured it might be useful to other people too. (And it's always nice to give something back :) So, is this something that would fit in boost? Advantages: * Enables lexical_cast on enums. * Pure implementation detail from user-of-enum's perspective. * Very little syntax overhead, inspired by boost::assign. * Works across namespaces & DLLS. * Allows user to define io-ops for "external" enums too. (But the IO-op-macro hs to go into the external namespace.) * Uses pimpl-idiom for faster compilation. * Suitable for header-only version. Issues to work out: * Uses the Loki-singleton to store implementation details. * Initialization is a bit rough. (We get away with it because we have a static "initClass" method for every class. It is a natural place for enumio-setup in our app, but this does not translate to general code well.) * Stores std::strings, although it's almost always constructed from string literals. Wastes a bit of memory for simpler implementation. * EnumIO<E>::The() is globally accessible, so there could be conflicts. (Very low probability though) See below for example & implementation. Comments? Cheers, /Marcus --- user .h ------------------------------------------------ enum Foo { Bar, Baz; } // to export from a win32 dll, add dllimport/export here std::istream& operator>>(std::istream&, Foo& foo); std::ostream& operator<<(std::ostream&, Foo foo); --- user.cpp ------------------------------------------------ #include "user.h" #include <enumio.h> ENUMIO_IMPLEMENT_IOSTREAM_OPS(Foo) // just one way to do it bool init = (::EnumIO<Foo>::the() (Bar, "bar") (Baz, "baz")), true; --- enumio.h ------------------------------------------------ class EnumUtilBase { public: ~ EnumIOBase(); protected: explicit EnumIOBase(const std::type_info& enumType); std::istream & in(std::istream & os, int &value) const; std::ostream & out(std::ostream & os, int value) const; protected: void add(int value, const char* data); private: class Impl; boost::scoped_ptr<Impl> m_i; }; // Helps with serialization (iostream) of enums template<class E> class EnumIO : public EnumIOBase { public: typedef E Enum; EnumIO<E> the() { return ::Loki::SingletonHolder<::EnumIO<E> >::the(); } EnumIO(); EnumIO<E>& operator()(E value, const char* data); std::istream & in(std::istream & is, E & value) const; std::ostream & out(std::ostream & os, E value) const; }; #define ENUMIO_IMPLEMENT_IOSTREAM_OPS(E) \ std::istream& operator>>(std::istream& is, E& value) { \ return ::EnumIO<E>::the().in(is, value); } \ std::ostream& operator>>(std::ostream& os, E value) { \ return ::EnumIO<E>::the().out(os, value); } template<class E> inline EnumIO<E>::EnumIO() : EnumIOBase(typeid(E)) { BOOST_STATIC_ASSERT(sizeof(E) == sizeof(int)); } template<class E> inline EnumIO<E> &EnumIO<E>::operator()(E value, const char* data) { EnumIOBase::add(value, data); return *this; } template<class E> inline std::istream & EnumIO<E>::in(std::istream & is, E & value) const { return EnumIOBase::in(is, (int&) value); } template<class E> inline std::ostream & EnumIO<E>::out(std::ostream& os, E value) const { return EnumIOBase::out(os, value); } --- enumio.cpp ------------------------------------------------ typedef std::map<int, std::string> MapOut; typedef std::map<std::string, int> MapIn; class EnumIOBase::Impl { public: const char* m_typename; ///< is retrieved from typeid(X).name() MapIn m_mapIn; MapOut m_mapOut; }; EnumIOBase::EnumIOBase(const std::type_info& enumType) : m_i(new Impl) { m_i->m_typename = enumType.name(); } EnumIOBase::~EnumIOBase() { } std::istream & EnumIOBase::in(std::istream & is, int &value) const { std::string str; is >> str; if (m_i->m_mapIn.empty()) { MapIn& m = const_cast<MapIn&>(m_i->m_mapIn); for(MapOut::const_iterator i = m_i->m_mapOut.begin(); i != m_i->m_mapOut.end(); ++i) { m.insert(std::make_pair(i->second, i->first)); } } MapIn::const_iterator i = m_i->m_mapIn.find(str); if (i != m_i->m_mapIn.end()) { value = i->second; } else { is.setstate(std::ios::failbit); } return is; } std::ostream & EnumIOBase::out(std::ostream & os, int value) const { const std::string& str = toStr(value); if (!str.empty()) { os << str; } else { os.setstate(std::ios::failbit); } return os; } void EnumIOBase::add(int value, const char* data) { m_i->m_mapOut.insert(std::make_pair(value, data)); }

2 6

[intrusive] Looking for a non-recursive structural tree cloning algorithm
by Ion Gaztañaga 08 Sep '07

08 Sep '07

Dear tree expert, As you might know, Boost.Intrusive implements an intrusive red-black tree and also a class offering red-black tree algorithms. Those algorithms were taken from the SGI STL code and optimized a bit. One of the goals of Boost.Intrusive is avoiding recursive calls to make those algorithms suitable for very big trees and/or embedded systems. The SGI STL uses two recursive algoritms: * Recursive destruction with no rebalancing * Recursive structural copy (which needs a erasing function in case a copy throws an exception). All STL implementations I'm aware of use recursive cloning and destruction. Boost.Intrusive changed the recursive tree destruction algorithm to a non-recursive one thanks to a step by step tree destruction function (unlink_leftmost_without_rebalance) that is also very useful to implement advanced tree cloning functions that might reuse old allocated nodes. However, I haven't found a non-recursive structural copy algorithm anywhere. So if you are a tree expert, I need your help to get a tree cloning function, that: * Does not use the comparison predicate or calls any function that uses it (e.g.: insert()) * Can destroy all constructed nodes in a non-recursive form if node-copying throws an exception. * It's pretty efficient ;-) Willing to help? Ion

1 0

Simple object factory: Checking signatures at runtime
by Marco Costalba 08 Sep '07

08 Sep '07

I'm extending the 'simple object factory' I have presented to this mailing list few threads ago. It is coming out pretty nice: the number of allowed object c'tor arguments have been extended until a given maximum and instead of an (optional) custom "object creator" function it is now possible to use any callable entity as example a functor object. The factory is now "almost" satisfactory. It has only a couple of drawbacks, one small and a work around does exist. The other is "important" because is a design issue. Very briefly: I can register any c'tor anywhere in a program to teach the factory how to build an object: Factory::register_class<Base, double>("MyObject"); Factory::register_class<Base, int, Base*>("MyObject"); Above instructions automatically instantiate and register two c'tor invokers c1 and c2 defined as: Base* c1(double d) { return new Base(d); } Base* c2(int i, Base* b) { return new Base(i, b); } Constructor overloading support it means that the factory will call two different functions also if the same key "MyObject" is passed depending on the argument types: Base* o1 = Factory::object("MyObject", 3.14); /* function 'c1' is called */ Base* o2 = Factory::object("MyObject", 3, o1); /* function 'c2' is called */ The factory is also able to check the signatures at runtime and discards any wrong call: Base* o3 = Factory::object("MyObject", o1, 3); /* o3 == NULL */ Finally, here it is the current big limitation: automatic argument type conversion is not supported: Factory::object("MyObject", 3.14, o1); /* fails: double -> int is not done */ Derived* d = new Derived(); /* say Derived it's a sub class of Base */ Factory::object("MyObject", 3, d); /* fails: Derived* -> Base* is not done */ The design issue is that type info is templatized so that only "near perfect matches" are discovered. Where "near perfect matches" it means that if a value 'v' has type V and constructor argument accepts type A then we have a match only if: A == V || A == V& || A == const V || A == const V& My question is: there exsist a way to check "relaxed" signatures at run-time? Put in general terms: Given a set 'Set' of functor objects f1,f2,..fn with different signatures in their operator() is it possible to check if a given set of values v1,v2,...vk are compatible with one or more of them ? What I would need is an implementation of the following algorithm: foreach(f in Set) if ( "f(v1,v2,..,vk)" is compilable ) return f; Constrains are: - Functors can be "registered" with the factory in different times and in different translation units. - At runtime you have a only set of values as input: v1,..vk - Functor signatures may not be homogeneous Thanks for your help Marco

4 15

[Release Process] composing the release
by Frank Birbacher 07 Sep '07

07 Sep '07

Hi! In this message I'm grounding my questions on the release process which we discussed ealier: development in the trunk and a release manager who will merge the changes into a release branch. When the libraries develop over time and some new features become release-ready they should me merged into the release branch. Now what happenes/should happen when a library X and a library Y both depend on library BASE and X includes a new feature which depends on a new version of BASE but library Y is using the old version of BASE? What should become of the release? Would the new features of X be rejected for release? Would we require lib Y to test against the new BASE? Proposal: For important/widely used "base" libraries we would use the release-ready version of the previous release. Meaning: at the same time when doing a release the lib BASE has some release-ready state (which is not necessarily part of the release). This state shall be "fixed" for use by other libraries when preparing for the *next* release. The BASE lib would be "one release behind", but every other library would have a common base to work with. Is this sensible? Frank

2 1

Updated Development and Release Practices for 1.35.0
by Beman Dawes 07 Sep '07

07 Sep '07

The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users. I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0. Comments appreciated. --Beman

18 83

Trac open tasks - by assignee
by Marshall Clow 07 Sep '07

07 Sep '07

[ 8 tasks ] 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> 4 grafik 3 djowel 1 agurtovoy agurtovoy 1122 Update regression.py to use SVN repo. djowel 1174 Simplified template arg handling djowel 1175 What is punctuation? djowel 1200 Revamp the header information grafik 1040 boost.devel archive at ActiveState disconnected grafik 1088 Docs for template escape feature. grafik 93 Testing problems on AIX and OSF grafik 94 Better reporting of failed expectation. -- -- 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

Trac open support requests - by assignee
by Marshall Clow 07 Sep '07

07 Sep '07

[ 27 open requests ] 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> 4 grafik 3 jbandela 2 vladimir_prus 2 turkanis 2 rogeeff 2 jsiek 2 djowel 2 az_sw_dude 1 urzuga 1 shammah 1 johnmaddock 1 fcacciola 1 anthonyw 1 agurtovoy 1 None None 982 x64 documentation for windows agurtovoy 816 duplicat initial members -> erase_key postcond. fail anthonyw 1053 Error using boost::mutex and C++/CLI az_sw_dude 605 support new 2007 DST rules for timezone db az_sw_dude 614 new timezone db file for #1471723 - 2007 DST support djowel 1221 Section names may cause html names to be too long djowel 543 Embedded python won't compile fcacciola 282 boost::optional<enum> fails with /CLR grafik 481 Linker Problems with VC .NET 2003 / STLPort / Boost grafik 497 Unable to build boost with Dinkumware STL version 4.02 grafik 552 Building universal binary on MacOSX grafik 683 libraries won't build jbandela 259 Problem compiling :/ jbandela 279 SLOOOWW tokenizer compilation on VC++6.0 jbandela 306 Visual C++ "Language Extensions" support johnmaddock 502 Problem running configure for unsupported platform jsiek 580 Max Flow Algorithm jsiek 905 Assertion failed in token_iterator.hpp rogeeff 747 failing on 6 targets in MacOS X rogeeff 847 [Test Library] How to init/free a singleton shammah 836 warning using pool.hpp turkanis 484 Boost.Iostreams and newline translation turkanis 579 boost.iostreams file_descriptor and sharing urzuga 426 lambda vs pure virtual functions vladimir_prus 1132 program_options documentation error. vladimir_prus 850 program_options strips off escaped quotes in some situations -- -- 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

Trac submitted patches - by assignee
by Marshall Clow 07 Sep '07

07 Sep '07

[ 42 submitted patches ] 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> 5 rogeeff 4 grafik 4 dave 4 agurtovoy 3 doug_gregor 2 turkanis 2 nesotto 2 anthonyw 2 None 1 vladimir_prus 1 urzuga 1 shammah 1 samuel_krempp 1 nobody 1 nasonov 1 jsiek 1 johnmaddock 1 dlwalker 1 djowel 1 danielw 1 bemandawes 1 az_sw_dude None 1116 disable some warnings in msvc build None 1182 Specifying character-set by the guideline and the inspect program agurtovoy 1049 Getting mpl/has_xxx.hpp to compile on AIX agurtovoy 637 Adjusts mpl::pair concept to be compatible with STL pairs agurtovoy 761 [mpl] evc4 port agurtovoy 861 Detect nested template members with has_template_xxx anthonyw 802 [thread] MSVS: Allow use of thread headers with /Za anthonyw 868 [thread] thread_specific_ptr::element_type ? az_sw_dude 827 Unused variable in format date parser bemandawes 1090 scoped_file class that deletes file at end of scope danielw 863 [parameter] fix operator|| for lazy binding dave 1020 Boost.Iterator proposal to add is_constant_iterator dave 1066 Patch to make Boost.Python compile on SunCC dave 857 add shared_ptr< const T> support dave 903 inconsistent usage of function pointer typedefs djowel 1208 gcc initialization order warnings dlwalker 653 [integer] add support for integers longer than long doug_gregor 1087 Mismatch between BBv2 and bjam toolsets in configure script. doug_gregor 862 [utility] Make result_of handle lambda expressions doug_gregor 870 boost::graph::graph_utility.hpp is_connected() bad call grafik 1031 AmigaOS fixes for bjam grafik 1074 FreeBSD specific patches to boost 1.34.0 grafik 798 bjam: always define OSPLAT grafik 989 Boost build does not support building universal binaries on macintosh johnmaddock 633 [config] evc4 port jsiek 541 [concept_check.hpp] remove unused variable warning in msvc nasonov 839 lexical_cast - local variable shadow patch nesotto 1027 [ptr_container] optional serialization support nesotto 1151 [range] make_indirect_range() nobody 884 [iostreams] workaround for the boost + stdcxx on MSVC 7.1 rogeeff 1169 errors in tutorial for test framework "new_year_resolution" rogeeff 645 [test] no eh exception handling functions on evc4 rogeeff 762 [test] evc4 issue with SEH support rogeeff 998 prg_exec_fail2 fail on ppc rogeeff 999 prg_exec_fail3 fails on release variant samuel_krempp 980 boost.format vc8/win32 compilation warning shammah 840 pool allocator - local variable shadow patch turkanis 586 iostreams // file_descriptor::seek BUG on files > 4 GB turkanis 869 [iostreams] patch for building by BBv2 urzuga 864 [lambda][utility] Make lambda support result<> vladimir_prus 1177 Various bugs in STLport jamfile -- -- 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