- 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: <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

RE:RE: Serialization Library format stability
by Robert Ramey 08 Aug '04

08 Aug '04

One final thought that didn't occur to me before would be to make your own "provably portable" archive. The current libraries all contain a default "fall through" which handles otherwise unspecified types. This could cause surprises when moving code/archives between environments. The alternative would be to make your own archive (or perhaps a derivation) which restricted the serializable types to those that have been specifically accounted for. More work - but might be necessary to guarantee archive portability. Also this might support the idea that the archives produced be accessable by other applications which don't use the serialization library which normally would be much more awkward to implement. Just a thought. Robert Ramey

1 0

RE: Serialization Library format stability
by Robert Ramey 08 Aug '04

08 Aug '04

Walter Landry wrote: > I am thinking of using your serialization library as part of another > project [1]. It will be writing files that need to be read by > multiple operating systems far into the future. So I was wondering, > how stable is the output format? I will be serializing maps, lists, > strings, bitsets, and some simple classes. Do you forsee any possible > changes in the disk format of those kinds of objects? This is an exceptionally good question. I'm amazed that no one has yet to raise it. If you don't mind, I will post it to the list as I don't believe others have given this the importance I believe it deserves. Anyway - here's my answer: It is one of the stated goals that this system produce portable archives as well as use portable code. By portable archives I mean archives that can save data structures on one platform (compiler/os/library) and recovered to another. This is not as easy as it might seem. I have take specific steps in the design and implementation to achieve this. a) My preferred archive - the simple text archive saves/loads primitives as text. This is inherently portable across platforms. XML is also portable. The included binary archive is not-portabable. The signature processing code will detect egregious violations of portability and trap with an exception. However this is not an exhaustive check. There is a demo which includes a portable binary archive. Floating point primitives would have to be added to make this complete. Ralf W Grosse-Kunstleve has submitted code that would address this but I haven't spent any time with it. b) I have taken extra pains that certain things are serialized the same way across platforms. Take std::list<int> for example. Practical efficiency considerations suggest that this should be stored without class information. The simple way of specifying this depends upon the usage of TPS which not all environments support. So I have used a different method to accomplish this. c) In the archive signature - there is a library format version index. If the format the archive type changes the newer code could include branch to deal with older format. I'm hoping it will never be necessary to use this but its there - btw - its now at #3. This would be a fallback. Possible problems: a) In practice, true archive portability will require more. For example, suppose I save an integer on a 64 bit machine to a text archive and load it to a machine which supports 32 bits. This would work fine - until the 64 bit machine saves an integer > 2^32 . This problem wouldn't be detected until the archive is loaded - way too late. Note that wchar_t, which is serialized as an integer, is 4 byte on gcc and 2 bytes everywhere else. So its possible/likely that this problem would surface where you least expect it. b) there are subtle problems than can arise. On some machines size_t is a macro that resolves to an integer while on some it's a true type. Saving a datum as an integer in one environment while recovering it as a type ( with a class id ) on another machine create surprises. Worse (or maybe better) this issue could look different for different archives. Text archives save/load book-keeping info (class-id, object-id, etc. in sequence so differences of this type will cause problems. XML archives include this information as attributes in the XML start tag. Attributes are retrieved by tag rather than by sequence (thanks to spirit) so in XML archives might work where the normal text archive fails. The good news is that this problem has been considered as goal from the very start. So all code has been written to accommodate this goal. That bad news is that this facility hasn't been exhaustively tested. What's needed is a separate/additional test suite which tests archive portability. This would mean a set of "canonical archives". The save test would create a new archives and compare each one to its "canonical" canonical counterpart. The load test would load the canonical archive and check to see that we recovered what we expected to. Implementation of such tests would reveal a host of small errors. For example, int64_t is just a typedef with gcc on a 64 platform while its separate type on on a 32 bit platform. This breaks compilation of the polymorphic archive at compiler time. In itself, its not too hard to resolve. But it requires careful thought to resolve it once and for all. Conclusion and recommendation So, if you want to use the serialization library for your project I would suggest. a) Just start doing it. The serialization library saves an incredible amount of coding and you can effectively just get on with the other more intesting parts of your project. b) When its time to think build your app on another platform and transfer archives between environments, you can rethink the issue. This is basically and economic argument. At this point: i) You will have invested no effort in serialization, so if it were deemed unsuitable, you would have lost no investment of effort if you decide to replace it with something else. ii) Maybe you'll get lucky and someone else will have made the archive portability test suite and the archives your interested in can be "guaranteed" portable. iii) If ii) above hasn't happened, you'll have to make your own archive portability test suite. The cost of this is also zero. This is because if you use some alternative to the serialization library, you'll still have to test the passing of serialized data between platforms in any case. If you make an archive portability test suite, please consider adding it to the library and tests. (Hmm - you're an academic - making such a test suite would be a great small project for one of your students. Important, educational, small enough to do in reasonable time, orthogonal to your main project goal - whatever that might be). Thanks for considering the serialization library for your project. Robert Ramey

1 0

detail/iterator.hpp: workaround_test fails with two-phase lookup (+ patch)
by Stefan Slapeta 08 Aug '04

08 Aug '04

On compilers with two-phase lookup (CW*) the workaround_test (range lib) fails because of incorrect typedefs in iterator.hpp. (Yes, I know it's very strange to disable partial specialization on a compiler with two-phase lookup.) OK to commit this patch for detail/iterator.hpp? Stefan Index: iterator.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/iterator.hpp,v retrieving revision 1.30 diff -u -r1.30 iterator.hpp --- iterator.hpp 26 Jul 2004 00:31:59 -0000 1.30 +++ iterator.hpp 5 Aug 2004 09:35:08 -0000 @@ -334,8 +334,8 @@ : std::iterator_traits<Iterator> { typedef typename std::iterator_traits<Iterator>::distance_type difference_type; - typedef value_type* pointer; - typedef value_type& reference; + typedef typename std::iterator_traits<Iterator>::value_type* pointer; + typedef typename std::iterator_traits<Iterator>::value_type& reference; }; template <class Iterator> @@ -343,8 +343,8 @@ : std::iterator_traits<Iterator> { typedef typename std::iterator_traits<Iterator>::distance_type difference_type; - typedef const value_type* pointer; - typedef const value_type& reference; + typedef const typename std::iterator_traits<Iterator>::value_type* pointer; + typedef const typename std::iterator_traits<Iterator>::value_type& reference; }; # ifdef BOOST_BAD_OUTPUT_ITERATOR_SPECIALIZATION

3 8