August 2004 - Boost - lists.boost.org

Problems with MPL in Fusion on MSVC 6.5
by Peder Holt 10 Aug '04

10 Aug '04

Hi. I am porting Fusion, Joel de Guzmans new tuple library to MSVC 6.5 and VC 7.0. Several of the testcases ICEs on MSVC 6.5. I traced the problems back to integral_c's operator int() Problem: When the template expressions gets too complicated, MSVC is unable to handle inlined functions inside a type computer struct. Solution: Place the function body outside of the struct. The relevant lines: operator AUX_WRAPPER_VALUE_TYPE() const #if BOOST_WORKAROUND(BOOST_MSVC,==1200) ; #else { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif }; #if BOOST_WORKAROUND(BOOST_MSVC,==1200) template< AUX_WRAPPER_PARAMS(N) > AUX_WRAPPER_INST(N)::operator AUX_WRAPPER_VALUE_TYPE() const { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif This change fixed most of the remaining (known) issues with Fusion & MSVC Is it OK if I check in these changes? -- Peder Holt

4 4

shared_ptr for ROOT
by troy d.straszheim 10 Aug '04

10 Aug '04

Hi boost:: I have created a work derivative of the boost::shared_ptr and would like boost's OK before I release this into the wild. Explanation: I am on a large project, a neutrino telescope, that involves the ROOT data analysis framework (http://root.cern.ch) This is a large package, one of whose features is a C++ interpreter. That's right, an *interpreter*. You build shared objects describing your classes, load them into the interpreter, and then you can run C++ *scripts*. The ability to do all of this is absolutely insisted upon by my client, a platoon of physicists. From what I can see this is almost a standard in high-energy physics. The general idea is that, if one inherits one's object from the ROOT uber-object "TObject", and puts a macro into the class class MyClass : public TObject { // whatever ClassDef(MyClass, 1); // this inserts "streamer" functions }; then one can quite easily write these objects to disk, and use a whole slew of introspection functions that come from TObject, like bool InheritsFrom(string classname) and Browse().. well you get the idea. One's code must make its way through a code generator, called "rootcint" which adds a bunch of functions to the class. One then specifies the template instances that one wants dictionaries for with #pragmas. I managed to put together a hybridized boost::shared_ptr that works with this framework. Objects that are inherited from the TObject that contain boost::shared_ptr-s to other TObjects make the round trip to/from disk with all reference counting and everything intact. Not a small feat, if I may say so, and possibly of general interest to the ROOT community. This involved a hybridization of the no-member-templates shared_ptr and the "regular" shared_ptr. rootcint is very idiosyncratic. Member template friends don't work (I am told the fix is in CVS). sp_enable_shared_from_this doesn't work. template member functions do, for the most part, but the keyword volatile seems to confuse things. You get the idea. the atomic_count stuff had to be taken out. specializations of void didn't go through, if I remember correctly. I removed most everything that was not necessary for linux/macosx and gcc (our project's platforms). I dislike "forking" code and doing merges, but I could not imagine that boost itself would have any interest in supporting this toolkit's interpreter, the #ifdefs would be nightmarish, and testing required the framework itself, of course. I also could not leave the hybridized version named "boost", as the full boost libraries remain in our toolset, and anyway it would not be truth in advertising, I may very well have introduced some bugs. With perl's help I named everything "roost" (root/boost). I have left the comments intact at the tops of the files and where applicable added my own. the boost license is of course included. The documentation clearly states that this is a ROOT-specific version of the boost::shared_ptr<> Again, I just wanted to be sure this all was OK and give an opportunity to before I release this into the wild. The tarball is at http://www.resophonic.com/software/ROOST-1.0.tar.gz and runs tests with ./configure && make runtests Which would require ROOT (http://root.cern.ch) If you're interested, I can give quick instructions on that offline, mail me directly. Thanks, -t

2 1

Re: [boost] shared_ptr improvement proposal
by brangdon＠cix.compulink.co.uk 09 Aug '04

09 Aug '04

In-Reply-To: <200408091418.i79EIu107210(a)entwistle.systems.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > The whole point behind the names selected for the new-style casts > was to make things more verbose. Yes. And as a result, I know some people still sometimes use old-style casts entirely because they are shorter. I can see mine is a minority view, so now that I've made my plea I'll shut up :-) > Note that it can be written as follows when not casting to a > different pointer type: > > boost::shared_ptr<Widget> p(boost::shared_ptr_cast(new Widget)); Thanks, that helps. -- Dave Harris, Nottingham, UK

1 0

Boost.Thread compile problems
by Johan Nilsson 09 Aug '04

09 Aug '04

Hi, I'm getting errors from the tss handling when compiling Boost.Thread using the DEC CXX 6.5 compiler (under OpenVMS). The compiler doesn't like the fact that a pointer to a function with C++ linkage is being passed to a function expecting a pointer to a function with "C" linkage. The function in question is when the address of "thread_specific_ptr<T>::cleanup" is used as an argument to pthread_key_create (indirectly). I'm using Boost 1.31.0. The workaround I've implemented is the following (snippets from the modified source to illustrate): --- tss.hpp --- namespace boost { namespace detail { extern "C" { typedef void (*pthread_key_destruct_cb_t)(void*); <<<=== } class BOOST_THREAD_DECL tss : private noncopyable { public: tss(pthread_key_destruct_cb_t cleanup = 0); <<<=== [snip] template <typename T> class thread_specific_ptr : private noncopyable { public: thread_specific_ptr() : m_tss(reinterpret_cast<detail::pthread_key_destruct_cb_t>(&thread_specific_p tr<T>::cleanup)) <<<=== {} [snip] --- tss.cpp --- [snip] #elif defined(BOOST_HAS_PTHREADS) tss::tss(pthread_key_destruct_cb_t cleanup) <<<=== { int res = 0; res = pthread_key_create(&m_key, cleanup); if (res != 0) throw thread_resource_error(); } [snip] ------ I'd be very grateful if you could implement something similar (this might not be the prettiest fix) before the release of 1.32.0. There are also some very annoying warnings originating from meaningless casts (from timeconv.inl), e.g.: --- timeconv.inl --- [snip] const int NANOSECONDS_PER_SECOND = 1000000000; [snip] #if defined(BOOST_HAS_PTHREADS) inline void to_timespec(const boost::xtime& xt, timespec& ts) { ts.tv_sec = static_cast<int>(xt.sec); ts.tv_nsec = static_cast<int>(xt.nsec); if(ts.tv_nsec > static_cast<const int>(NANOSECONDS_PER_SECOND)) <<<=== [snip] ------------ Basically the compiler finds it pretty meaningless to cast "const int"s to "const int"s (and so do I). Possible to fix this also? Thanks // Johan

3 4

Boost Workshop at OOPSLA 2004
by Jeremy Siek 09 Aug '04

09 Aug '04

CALL FOR PAPERS/PARTICIPATION C++, Boost, and the Future of C++ Libraries Workshop at OOPSLA October 24-28, 2004 Vancouver, British Columbia, Canada http://tinyurl.com/4n5pf Submissions Each participant will be expected to develop a position paper describing a particular library or category of libraries that is lacking in the current C++ standard library and Boost. The participant should explain why the library or libraries would advance the state of C++ programming. Ideally, the paper should sketch the proposed library interface and concepts. This will be a unique opportunity to critique and review library proposals. Alternatively, a participant might describe the strengths and weaknesses of existing libraries and how they might be modified to fill the need. Form of Submissions Submissions should consist of a 3-10 page paper that gives at least the motivation for and an informal description of the proposal. This may be augmented by source or other documentation of the proposed libraries, if available. Preferred form of submission is a PDF file. Important Dates • Submission deadline for early registration: September 10, 2004 • Early Notification of selection: September 15, 2004 • OOPSLA early registration deadline: September 16, 2004 • OOPSLA conference: October 24-28, 2004 Contact committee oopsla2004(a)crystalclearsoftware.com Program Committee Jeff Garland Nicolai Josuttis Kevlin Henney Jeremy Siek _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Student, Indiana University Bloomington C++ Booster (http://www.boost.org) _______________________________________________

1 0

Re: [boost] shared_ptr improvement proposal
by brangdon＠cix.compulink.co.uk 09 Aug '04

09 Aug '04

In-Reply-To: <200408061504.i76F4EW20044(a)entwistle.systems.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > Note, however, that "rawptr" is rather terse for something you're > trying to call attention to. I liked the terseness. To be honest I am less likely to use new features if they are verbose. "boost::raw_ptr()" is already 16 characters. Surely the main benefit comes from being able to search for raw_ptr with tools like grep, rather than with eyeballs? The later suggestion of writing: boost::shared_ptr<Widget> p = boost::shared_ptr_cast<Widget>(new Widget); is even more verbose and repetitive, the word "Widget" occurring 3 times. The original proposal: boost::shared_ptr<Widget> wp2 = boost::raw_ptr(new Widget(a, b)); at least fits into 80 columns. Is it time to wrap operator new()? For example: boost::shared_ptr<Widget> wp2 = boost::make<Widget>(a, b); with something like: template <typename R, typename A, typename B> inline raw_ptr_t<R> make( A &a, B &b ) { return raw_ptr_t<R>( new R( a, b ) ); } Users being allowed to specialise make<> with their own factory code if desired. -- Dave Harris, Nottingham, UK

4 3

[program_options / g++ 3.3.3] Problem with UTF-8 codecvt facet
by Tilman Kuepper 09 Aug '04

09 Aug '04

Hello world, I took a closer look at the UTF-8 codecvt facet which is part of the program_options library. A test program is attached. The last assert (in the Read-function) fails with g++ (GCC) 3.3.3 (Debian 20040429). After some debugging I think I found the problem: The function utf8_codecvt_facet_wchar_t::do_in() converts only valid (com- plete) UTF-8 sequences into internal (wchar_t) characters. In case the input buffer ends with an incomplete UTF-8 character, do_in() returns codecvt_base::partial and points from_next at the beginning of this incomplete UTF-8 sequence. Obviously the library (libstdc++) is surprised by the fact that the codecvt facet stops the translation, although there is still room in the output buffer (i. e. to_next != to_end) and not all input characters have been processed (from_next != from_end). As a consequence the for-loop in the test program stops too early (wifstream not "good" any longer) and assert(pos == wstr.size()) fails. Is this a known issue with the GNU library or with the UTF-8 conversion facet? And what can be done? Best regards from Aachen, Tilman PS: You can find the codecvt facet cpp/hpp files in the folders /boost/boost/program_options/detail/ and in /boost/libs/program_options/src/ PPS: There seems to be no problem with VC7.1/Dinkumware. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #include "utf8_codecvt_facet.hpp" #include <string> #include <iostream> #include <fstream> #include <locale> #include <cassert> using namespace std; using namespace boost; using namespace boost::program_options; using namespace boost::program_options::detail; namespace { wstring wstr; } inline bool IsUnicode(wchar_t wch) { if(wch >= 0x00D800 && wch < 0x00E000) return false; if(wch >= 0x00FFFE && wch < 0x010000) return false; if(wch >= 0x110000) return false; return true; } inline void MakeTestStr() { const size_t loops = 1; wstr.clear(); wstr.reserve(loops * 0x110000); for(size_t i = 0; i < loops; ++i) for(wchar_t wch = 0; wch < WCHAR_MAX; ++wch) if(IsUnicode(wch)) wstr += wch; } inline void Write() { locale loc; locale utf8loc(loc, new utf8_codecvt_facet<wchar_t, char>()); wofstream f; f.imbue(utf8loc); f.open("test.utf8", ios::binary); f << wstr; assert(f); } inline void Read() { locale loc; locale utf8loc(loc, new utf8_codecvt_facet<wchar_t, char>()); wifstream f; f.imbue(utf8loc); f.open("test.utf8", ios::binary); wchar_t wch; size_t pos = 0; for(; f.get(wch); ++pos) assert(wstr[pos] == wch); assert(pos == wstr.size()); // ***PROBLEM HERE*** } int main() { MakeTestStr(); Write(); Read(); }

3 4

BGL: which algorithm needs edge_index
by Andreas Fabri 09 Aug '04

09 Aug '04

Hello, The subject says it all. Which are the algorithms that need this property? googling boost I only found the subgraph thanks in advance, andreas

2 1

Virtual function parameter variance
by Dave 08 Aug '04

08 Aug '04

Hello all, Quoting from page 24 of "The Boost Graph Library; User Guide and Reference Manual": "It turns out that by the contravariance subtyping rule, the parameter type in the derived classes member function must be either the same type or a base class of the type as the parameter in the base class." Now please consider this code: #include <iostream> struct base_1 {}; struct derived_1: base_1 {}; struct base_2 { virtual void foo(derived_1 *p) {std::cout << "base_2::foo()\n";} }; struct derived_2: base_2 { virtual void foo(base_1 *p) {std::cout << "derived_2::foo()\n";} }; int main() { base_2 *ptr = new derived_2; ptr->foo(new derived_1); } This outputs base_2::foo(). Why? The quoted passage implies derived_2::foo() should override base_2::foo(). Clearly, it does not. Furthermore, I cannot find anything in the Standard that indicates it should. So, I am clearly misinterpreting the quoted passage. Can anybody explain to me what was meant in that passage? Thank you, Dave

3 4

type_with_alignment question
by Maxim Yegorushkin 08 Aug '04

08 Aug '04

I am using boost::aligned_storage<> and I would like it to be aligned on 32 byte boundary (the reason being that sizeof(my type) is 32 bytes and I want it to be aligned on x86 cash line size so that it is cashed most effectively). I am working now under VC7.1 and it seems like the maximum alignment I can get with the compiler is 8 which is the alignment of the largest built-in type which is long double (or a pointer to member/function). But type_with_alignment.hpp seems to have special support for gcc in the form of: namespace align { struct __attribute__((__aligned__(2))) a2 {}; struct __attribute__((__aligned__(4))) a4 {}; struct __attribute__((__aligned__(8))) a8 {}; struct __attribute__((__aligned__(16))) a16 {}; struct __attribute__((__aligned__(32))) a32 {}; } template<> class type_with_alignment<1> { public: typedef char type; }; template<> class type_with_alignment<2> { public: typedef align::a2 type; }; template<> class type_with_alignment<4> { public: typedef align::a4 type; }; template<> class type_with_alignment<8> { public: typedef align::a8 type; }; template<> class type_with_alignment<16> { public: typedef align::a16 type; }; template<> class type_with_alignment<32> { public: typedef align::a32 type; }; Are MSVSs going to be supported as they have similar extension __declspec(align(x))? -- Maxim Yegorushkin

2 2