January 2006 - Boost - lists.preview.boost.org

[Release 1.34] Supported Compilers
by Thomas Witt 07 Feb '06

07 Feb '06

Hi, several recent posts touched the issue of deprecating compilers in the next release. Given the fact that we don't even seem to know what deprecating means I would like to propose the following: Compiler support should be phased out instead of dropped. I see three different stages here. Fully Supported --------------- Libraries should make an effort to support these compilers. Regressions in support version to version should be avoided. (Weasel wording intended). Full regression testing. Marked Deprecated ----------------- No effort is required to support these compilers in new functionality. Version to version regressions are accepted after the first version that marked these compilers as deprecated. Full regression testing (if resources are available). One key idea here is to give the user a good idea on the level of available functionality until a toolset reaches the "Unsupported" stage. Unsupported ----------- No regression testing is done. (Library authors might still support these toolsets for their libraries on a case by case basis.) AFAICS there seems to be strong support for moving gcc-2.95 and vc6 to "Marked Deprecated" and somebody needs to fight Alisdair over Borland (volunteers? any?). Comments Thomas -- Thomas Witt witt(a)acm.org

18 36

Filesystem I18n comments
by Martin 07 Feb '06

07 Feb '06

1. Why "directory_iterator->exists()" instead of "exists(directory_iterator)" 2. Any chance of having a non-throwing version of directory_iterator (similar to status). Since such a common error like not having access to a directory throws an exception, every directory_iterator construction needs a try/catch. The recursive_directory_iterator is kind of useless since it will stop as soon as you get an "access denied". (Maybe a portable can_be_iterated function can be added) 3. The documentation doesn't say how other_flag is supposed to work. If an implementation adds more flags, will other_flag be set for these? 4. A suggestion is to overload exists, is_directory etc for status flags and let the error condition be statusflags == 0. (or make status_flags a class with a bool conversion) In the code you could then write like if (status_flags s = status(path)) { if (!exists(s) || !is_directory(s)) cout << "bad directory"; } else cout << "error"; In the current implementation you need to remember if you should use == or & when checking the status flags. status_flags s = status(path); if (s == error_flag) // must test with == here cout << "error"; else if ((s & directory_flag) == 0) // must test with & here cout << "bad directory";

3 6

[Range] breaking update pending
by Thorsten Ottosen 06 Feb '06

06 Feb '06

Dear All, I have been trimming boost.range to incorporate the changes we have been discussing some time ago. These changes will break many uses of the library. Inside boost this will affect Boost.foreach Boost.string algo Boost.iostreams (*) (*) I don't this will break The list of major changes is the follwing: 1. ADL hooks renamed boost_range_begin -> range_begin, boost_range_end -> range_end 2. ADL hook boost_range_size removed; boost::size(rng) now requires RandomAccessIterators to guarantee O(1) complexity. 3. range_result_iterator renamed range_iterator and range_iterator renamed mutable_iterator. The correct way to spell const_iterator<T> is now iterator<const T>. 4. intrinsic string support removed. instead a header as_literal.hpp is previded with a small utility for use in string algorithms. I expect that (3) and (4) is where the most work lies. If nobody has anything to add, will add the new version to the cvs within a few days. -Thorsten

5 28

Library Proposal: Reflection for C++
by Stefan Roiser 06 Feb '06

06 Feb '06

Hi, We would like to propose a library and tools which enhance C++ with reflection capabilities. The package, "Reflex", provides a library for runtime introspection and interaction with C++ "constructs" such as objects, types, scopes, members, templated types, ... The library has no external dependencies and was developed with the ISO/IEC standard for C++ as guideline. Production of dictionary information of arbitrary C++ definitions is done via a Python script (genreflex), in a non-intrusive way, using an external tool (gccxml - www.gccxml.org) The generated dictionary source code can be compiled into a shared library, dynamically loaded and accessed via an API providing the introspection information. You can find more information at http://cern.ch/reflex Below you may find an example code snippet which exposes a subset of the functionality. The four different parts show 1 - the definition of the example classes 2 - how to generate the dictionary information 3 - example on introspection (re-generate classes from the dictionary information) 4 - examples on interaction (get/set data members, invoke functions, con/destruct objects) Cheers Stefan // // 1. original class Foo.h // namespace zot { struct foo_base { public: foo_base() : fBar(4711) {} ~foo_base() {} protected: int fBar; }; class foo : public foo_base { public: int bar(); void set_bar(int i); void set_bar(float f); void operator ++ (); }; inline int foo::bar() { return fBar; } inline void foo::set_bar(float f) { fBar = int(f); } inline void foo::set_bar(int i) { fBar = i; } inline void foo::operator ++ () { ++fBar; } } // namespace zot // // 2. Run python script on Foo.h generating dictionary source code // (Foo_rflx.cpp) and produce a shared library libFooRflx.so // genreflex Foo.h --gccxmlpath=/dir/to/gccxml/bin (e.g.) g++ -shared -o libFooRflx.so Foo_rflx.cpp -I${REFLEXROOT}/ include -L${REFLEXROOT}/lib -lReflex // // 3. + 4. example code for introspection and interaction // #include "Reflex/Reflex.h" using namespace std; using namespace ROOT::Reflex; enum Visibility { Public, Protected, Private }; void generate_class_decl( const Type & cl, const string & indent ) { // ... base class declarations if ( cl.BaseSize()) { for ( Base_Iterator b = cl.Base_Begin(); b != cl.Base_End(); ++b) generate_class_decl((*b).ToType(), indent); } cout << indent << "class " << cl.Name(); // ... bases if ( cl.BaseSize()) { cout << " : " ; for ( Base_Iterator b = cl.Base_Begin(); b != cl.Base_End(); + +b ) { if ( (*b).IsVirtual() ) cout << "virtual "; if ( (*b).IsPublic() ) cout << "public "; if ( (*b).IsProtected() ) cout << "protected "; if ( (*b).IsPrivate() ) cout << "private "; cout << (*b).ToType().Name(SCOPED); if ( b != cl.Base_End()-1 ) cout << ", "; } } cout << " {" << endl; Visibility vis = Private; // ... function members for ( Member_Iterator f = cl.FunctionMember_Begin(); f != cl.FunctionMember_End(); ++f ) { if ( ! (*f).IsArtificial()) { if ( (*f).IsPublic() && vis != Public ) { cout << indent << "public:" << endl; vis = Public; } else if ( (*f).IsProtected() && vis != Protected ) { cout << indent << "protected:" << endl; vis = Protected; } else if ( (*f).IsPrivate() && vis != Private ) { cout << indent << "private:" << endl; vis = Private; } Type ft = (*f).TypeOf(); cout << indent + " "; if ( ! (*f).IsConstructor() && !(*f).IsDestructor() ) cout << ft.ReturnType().Name(SCOPED) << " "; if ( (*f).IsOperator() ) cout << "operator "; cout << (*f).Name() << " ("; if ( ft.FunctionParameterSize() ) { for ( size_t p = 0 ; p < ft.FunctionParameterSize(); p++ ) { cout << ft.FunctionParameterAt(p).Name(SCOPED|QUALIFIED); if ( (*f).FunctionParameterNameAt(p).length() ) cout << " " << (*f).FunctionParameterNameAt(p); if ( (*f).FunctionParameterDefaultAt(p).length() ) cout << " = " << (*f).FunctionParameterDefaultAt(p); if ( p != ft.FunctionParameterSize()-1 ) cout << ", "; } } cout << ");" << endl; } } // ... data members for ( Member_Iterator d = cl.DataMember_Begin(); d != cl.DataMember_End(); ++d ) { if ( (*d).IsPublic() && vis != Public ) { cout << indent << "public:" << endl; vis = Public; } else if ( (*d).IsProtected() && vis != Protected ) { cout << indent << "protected:" << endl; vis = Protected; } else if ( (*d).IsPrivate() && vis != Private ) { cout << indent << "private:" << endl; vis = Private; } cout << indent + " " << (*d).TypeOf().Name(SCOPED) << " " << (*d).Name() << ";" << endl; } cout << indent << "};" << endl; } void generate_class(const Type & ty) { string indent = ""; Scope sc = ty.DeclaringScope(); // ... declaring scope if ( ! sc.IsTopScope() ) { if (sc.IsNamespace()) cout << "namespace "; else if (sc.IsClass()) cout << "class "; cout << sc.Name() << " {" << endl; indent += " "; } generate_class_decl(ty, indent); if ( ! sc.IsTopScope() ) { cout << "}" << endl; if (sc.IsClass()) cout << ";"; } } int main() { // load the dictionary information void * v = dlopen("libFooRflx.so", RTLD_LAZY); // get meta information of type Foo Type fooType = Type::ByName("zot::foo"); // check if the type is valid if (fooType) { // // 3. Introspection // // generate declarations for foo generate_class(fooType); // // 4. Interaction // // update the information for inherited members of class foo // this will be automatic in the future fooType.UpdateMembers(); // construct an object of type Foo Object fooObj = fooType.Construct(); // get the value of the data member (i.e. 4711) int val = Object_Cast<int>(fooObj.Get("fBar")); // set the data member to 4712 fooObj.Set("fBar",++val); // get the data member again (i.e. 4712) val = Object_Cast<int>(fooObj.Get("fBar")); // call function setBar with value 4713 fooObj.Invoke("set_bar",Type::ByName("void (int)"), ++val); // call operator ++ to increase fBar by one fooObj.Invoke("operator++"); // call bar getter and cast the output to int (i.e. 4714) val = Object_Cast<int>(fooObj.Invoke("bar")); // delete the Foo object fooObj.Destruct(); } return 0; } /* // // the output of the introspection part is // namespace zot { class foo_base { public: foo_base (); ~foo_base (); protected: int fBar; }; class foo : public zot::foo_base { public: int bar (); void set_bar (int i); void set_bar (float f); void operator operator++ (); }; } // // // */ -- Stefan Roiser CERN, PH Department CH - 1211 Geneva 23 Mob:+41 76 487 5334 Tel:+41 22 767 4838 Fax:+41 22 767 9425

7 46

[filesystem, config (maybe) ] bug: static link with msvc8 fails
by Tobias Schwinger 05 Feb '06

05 Feb '06

When linking statically against Boost.Filesystem the (msvc) link step fails if <boost/filesystem.hpp> was included by one of the source files. Everything's works if - compiling with GCC, or - none of the source files includes boost/filesystem.hpp. The link settings are <threading>multi <link>static <runtime-link>static Here are the symptoms: boost_filesystem-vc80-mt-sd-1_34.lib is built, but linking fails because ... cannot open file 'libboost_filesystem-vc80-mt-sgd-1_34.lib' . Adding <runtime-debugging>off to the link settings changes error message to ... cannot open file 'libboost_filesystem-vc80-mt-s-1_34.lib' I'm using Boost.Build V2. There is an example project that shows the problem attached to this post (note the path to Boost in 'project-root.jam' needs manual adjustment). I hope the report was of any help. Regards, Tobias

2 2

asio and vc8.0 Link Error
by Ian Baxter 05 Feb '06

05 Feb '06

Asio when compiled in a mixed assembly with VS 8 produces a link error (LNK2022) because of an undefined struct in error.hpp. changing line 288 error.hpp to this: struct unspecified_bool_type_t{ }; fixes the problem. Cheers

2 1

1.34 Release Plan
by Thomas Witt 03 Feb '06

03 Feb '06

Hi, with 1.33.0 now five months old it is time to get the 1.34.0 release going. Well to be honest it's probably more than time. In order to improve our release process we are planning to adopt a staged release process that is modelled partly after the gcc release process. By and large it can be seen as a formalization of things already done in past releases. A description of the different stages will be given at the end of this mail. But lets get the important issues out of the way first: schedule. I think that we have enough features in CVS already to make 1.34 worthwhile. For that reason the main focus for 1.34 will be a release within reasonable time. For that reason I am going to aim for a feature freeze (Stage 3) in two weeks from now. I ask anybody who can not make that deadline for one reason or another to contact me directly and we try to figure something out. Furthermore for this release feature freeze will also be the cut off date for addition of new libraries. I am planning to flesh out the further schedule in a few days once I got an idea how we are doing with the feature freeze. Thanks Thomas Boost Release Procedure (by Doug Gregor) ==================== Boost development for each release will be divided into four stages, influenced by the GCC development model. The stages move from a very loose, open development model where major changes can be made toward a much more tightly-controlled model as the release date nears. Release managers are appointed for the duration of the release process for a particular version of Boost, and several Boost versions may be in progress at any point in time. However, actual release dates will be staggered to allow testing resources to be allocated to the most imminent release. Stage 1 - Open Development -------------------------- Major changes to libraries or infrastructure may be performed, including large updates or additions to core libraries (e.g., type traits) and tools (e.g., Boost.Build). New libraries and new features can be added freely. Stage 2 - Intracomponent Open Development ----------------------------------------- This stage restricts Stage 1 slightly by banning far-reaching changes to Boost. Major changes to libraries or infrastructure, or the addition of new features and libraries, can be made in the stage. However, the changes must be limited in scope and may not have far-reaching affects. For instance, the build or regression testing systems in Boost cannot be changed at this point, and Boost libraries on which other major components of Boost depend (such as MPL, Type Traits, and Config) may not have large interface changes or be fundamentally rewritten. The Release Manager has final say regarding the classification of changes as "far-reaching" or not; if you are unsure, please ask. Stage 3 - Feature freeze ------------------------ This stage is a bug-fixing stage. Bug fixes may be freely applied to Boost, even if they require substantial changes. Interfaces may not be changed (unless required to fix bugs) and new features should be added only sparingly and with Release Manager approval. New libraries may be introduced at this stage with Release Manager approval, but the introduction of new libraries is tentative: if the new library fails a significant number of its regression tests, it will be removed from the release. Stage 4 - Release preparation ----------------------------- Only bug-fixes and documentation changes may be applied, and the changes should be as minimal and as safe as possible. If a change is large, or has the potential to cause additional failures, consult the Release Manager before applying the change to the repository. Changes that cause failures will be reverted after 48 hours if the failures are not addressed to the Release Manager's satisfaction. The beginning of stage 4 will be marked by the creation of a new CVS branch for the release. At this point, the old CVS branch falls back to stage 1 (for major releases, e.g., 1.XX.0) or stage 3 (for minor releases, e.g., 1.XX.Y). Final Freeze ------------ 7 days prior to a release, the Release Manager will call for a final freeze on the CVS branch corresponding to the release. At this point, no changes may be made to the branch with explicit Release Manager approval. Post-Release ------------ After a release is made, the changes made on the release branch should be merged back into its parent branch. The release branch reverts to stage 4; should another minor release be scheduled on that branch, the Release Manager for that minor version may revert to stage 3 or remain in stage 4 until the point release is imminent. Thomas Witt witt(a)acm.org

22 77

Bind comparisons
by David Abrahams 03 Feb '06

03 Feb '06

Is it really true that I can write bind(f, _1) > _2 but can't write _1 > _2 ?? I can't imagine a good reason for that restriction, but I don't see any indication that the latter is supported in the docs. -- Dave Abrahams Boost Consulting www.boost-consulting.com

5 25

Re: [boost] [Release 1.34] Supported Compilers - another view
by Robert Ramey 03 Feb '06

03 Feb '06

I've come to believe that the huge amount of discussion regarding how compilers should be classified is another symptom of the (excessively?) close coupling of boost libraries. The first symptom is the disproportionate amount of effort required to make a new "release" which has been discussed on another thread. With a couple of caveats noted below I see no reason why all libraries have to support the exact same set of compilers at the same level. As an example consider a couple of libaries. spirite and lambda - these absolutley depend upon high compiler conformance. Anyone seriously interested in using tools like this and the techniques they embody will not be using msvc 6.0 . Demand and utility of msvc 6.0 for these libraries approaches nil. smart_ptr, iostreams and others. These have wide applicabilty and probably demand for those using MSVC. I'm sure that the developer of smart_ptr suffered with MSVC 6.0 - but its over now and I doubt that just keeping it up is a big problem. I suspect that msvc 6.0 compatiblity for iostreams issn't too bad. All in all I think its fine that each author decide what level of support to give each compiler. The current test system permits a compiler to be marked as supported/unsupported on a library by library basis. This is just fine. Of course library authors and the review process will have to resolve what level of support is appropriate for each combination of library and compiler. I just don't see how there is anyway to agree blanket policy "compiler X is supported/deprecated" etc. So now it comes down to individual libraries. The only time this comes up as a boost wide issue is for libraries which are used by other boost components. The current case is that of Boost Test. Lets consider this library in particular. Boost Test is used by ALL libraries in boost to test themselves. For it to be an effective in this role, it must be usable with any compiler that is supported by any library. This is not a suggestion or normative statement. Its just a recognition of the fact that it can't do the job it has been doing if it doesn't support older compilers. So Boost Test should be structured so that it doesn't break old tests. It can add new features that are supported only in new compilers but it should be able to continue to provide the support it has in the past. I realise that this is an extra burden that other libraries don't have to shoulder and maybe its not "fair" but it is part of the requirement for Boost Test to continue in its fundamental role in boost. A couple of random observations re boost test. It has been a fundamental contributer to a big change in the way I do my programming. It deserves full credit for that. I'd read the "continuous testing" mantra and believed it in theory - but without a fully implemented test sytsem with good documents to teach me how to do it and make it easy to do I wouldn't have been converted. I suspect that my experience is common in this regard. Boost Test is special it has to be almost universal in order or full fill its extremely important and special role in boost and in C++ development in general. I appreciate that the author of Boost Test thinks its a pain in the rear to address the "old compilers" but he is too modest in appreciation of his own work and I'm sure that if knew how important it really has been and he would just say "$%%&%&*" OK and accept his lot and keep it widely compatible. I think that boost test is plenty sophisticated an complete feature wise. Maybe too much - which is what might be creating the compatiblity issues. The main obstacle to "selling and promoting" boost test is that the documents need work to make boost test more obvious to a new user - (and to me as well). The perspective should be to "increase market penetration" of boost test rather than "increase functionality" of boost test. In my view, lack of ease of use is currently a larger obstacle to "increasing market penetration" than limited feature set and this is where effort should be invested. An and another thing. It damn annoying to find that all my tests suddenly fail on msvc because of a change in the test system. Oh I'm sure it was announced somewhere and I don't care - its annoying none the less. Now what am I to do? Stop supporting msvc? Shouldn't that be my decision? Re write my tests to not use boost test? I don't want to do that! Finally, I managed to get the serialization libraries test to work with comeau by commenting out some of boost test. unit_test_parameters.ipp // const_string rs_str = retrieve_framework_parameter( RANDOM_SEED, argc, argv ); // s_random_seed = rs_str.is_empty() ? 0 : lexical_cast<unsigned int>( rs_str ); This apparently instantiates some basic_stream template that the serialiation library also instantiates. The comeau 4.3.3 prelinker complains about this - which I don't thnk it should - and build of serialization library fails. Commenting this out permits the serialization libary to be tested with comeau. Robert Ramey

13 58

Boost test tools using static library - operator new link problem
by Paul A Bristow 02 Feb '06

02 Feb '06

In release mode (debug to libboost_unit_test_framework-vc80-mt-sgd-1_34.lib is OK, and dll debug and release libs also OK) Compiling... test_tools_test.cpp Linking... libboost_unit_test_framework-vc80-mt-s-1_34.lib(exception_safety.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in libcpmt.lib(newaop.obj) I:\boost-06-01-13-0500\libs\test\build\msvc71_proj\Release\test_tools_test_s tatic.exe : fatal error LNK1169: one or more multiply defined symbols found Suggestions about what I am doing wrong? Thanks Paul PS Trying to avoid transition to monitor defenestration mode ;-) -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow(a)hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html

4 8