- Boost - lists.boost.org

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

Re:Re:[boost] [serialization] CW8 and the recent changes...
by Robert Ramey 08 Aug '04

08 Aug '04

Rene Rivera wrote: > The most recent changes cause a large number of new warnings to show up. > The are all of the form: > ### mwcc Compiler: > # In: ..\boost\serialization\void_cast.hpp > # From: ..\libs\serialization\test\test_array.cpp > # -------------------------------------------------- > # 188: __declspec(noinline) __declspec(dllexport) > # Warning: ^^^^^^^^ > # illegal type qualifier(s) Thanks, I'm on it - I'll check in a fix soon. I'm still struggling with cwpro8+ but haven't run out of options yet so stay tuned and have patience. Robert Ramey

2 1

[preprocessor] More changes for Digital Mars, and some of the examples.
by Daniel James 08 Aug '04

08 Aug '04

Hello, I've got some more changes for the preprocessor library. I noticed the other day that there are no tests for sequences in the preprocessor library, which meant that I hadn't tested them on Digital Mars, so I missed a couple of changes that were needed there. I've put up a patch at: http://myweb.tiscali.co.uk/calamity/patches/preprocessor-2.patch.gz This also contains some unit tests for sequences (I just took the list tests and made some changes). It also fixes some typos in the examples in the reference documentation. Daniel

1 0