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

Could anybody fix an archive?
by Gennadiy Rozental 07 Jan '05

07 Jan '05

Why does it happening anyway? Gennadiy

2 1

[Boost-bugs] [ boost-Support Requests-1098070 ] Spirit does not compile on aCC
by SourceForge.net 07 Jan '05

07 Jan '05

Support Requests item #1098070, was opened at 2005-01-07 10:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1098070&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Spirit does not compile on aCC Initial Comment: I am really interested in using boost, and especially spirit, for a project on HP-UX, but it seems the aCC compiler has got some issues with the template resolutions, even though it is a decent compiler, and very fast, compared to gcc at least. I tried to compile some of the spirit tests and here are the kind of errors I get: >aCC -AA -I../../boost_1_32_0/ +W823 chset_tests.cpp Error 619: "../../boost_1_32_0/boost/spirit/core/primitives/primitives.hpp", line 40 # The definition of template result<boost::spirit::anychar_parser> contains typename qualification 'ScannerT::value_t', yet generation of specialization struct result<boost::spirit::anychar_parser> implies that 'ScannerT' is 'tentative struct anychar_parser', which does not contain a type named 'value_t'. typename parser_result<self_t, ScannerT>::type ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Error 617: "../../boost_1_32_0/boost/spirit/core/primitives/primitives.hpp", line 40 # The definition of template result<int> contains typename qualification 'ScannerT::value_t', yet generation of specialization struct result<int> implies that 'ScannerT' is 'int', which is not a class type. typename parser_result<self_t, ScannerT>::type ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ It seems it does not use the proper parameters. note that aCC does not have issues usually with template, even when using several level of nesting or specialisations. any kind of help towards resolution of this issue would be greatly appreciated, thanks, maudouy(a)amadeus.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=1098070&group_… ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] Re: Interesting Boost Implementation Details?
by Brian Braatz 07 Jan '05

07 Jan '05

> > [Brian Braatz] > > I am biased because I am going to be attending both of those :) > > > > My thoughts are also biased because, currently, boost.lambda has been > > the focus of my attention recently. (it is also currently my "favorite > > boost library of the month") > > > > Suggestion: > > Take Lambda and tear it apart and show how it works. This might > > be a good subject matter to keep a consistent topic as a foundation for > > covering techniques. > [David Abrahams] > The biggest problem with that is that Boost.Lambda's implementation is > in large part obsoleted by the new stuff Joel de Guzman and friends are > doing with Phoenix-2. It is supposed to form the basis of a > Boost.Lambda rewrite. I don't know the details of what's there, but I > imagine a good bit of Boost.Lambda is old technology for which better > solutions exist today. > > > The other thing you could do, is borrow the structure of your book, and > > use the same structure for the lecture. This way the attendees could > > then get your book, and have a consistency from the lecture to the book. > [David Abrahams] > That's fine for the other talk (the one on metaprogramming), but the > book isn't about "inside the Boost libraries." > [Brian Braatz] DOH! I am behind the times here. I have been working with Boost for a year now. And I am finally to the point where I can use boost.lamda in my sleep. So all this stuff I find exciting and enthralling is "last decades technology". Man I need to get with it :) Ok- let me alter the suggestion: For inside boost: Think of the 5 most important techniques used in most of the libraries For each technique, show the technique, then show how at least 2 libraries use that technique in similar (or dissimilar) ways. This would be a good way to ground the technique and by seeing the different implementations, would help people "think correctly" to further understand inside boost. I make this suggestion because, I had to read "Brochschmidts" book on OLE, like 5 times before I "got it". I first had to learn "how to think about it". Once I learned "how to think about it", the whole thing made sense. If you can show the same technique in multiple areas, it will aid people in "how do I think about this". Once you have accomplished that with the audience, you can then springboard into the really complicated stuff. (and yes, I am willfully and shamelessly trying to offer suggestions for things I want you to talk about since I will be attending both talks :) )

1 0

Re: [Boost-users] B is_convertible to A<T> for some T
by Aleksey Gurtovoy 07 Jan '05

07 Jan '05

John Maddock writes: >> how do I express through template metaprogramming or in a similar >> way that a class is convertible to a template class for some T1? >> I.e., the condition: "There exists some T1 such that B is >> convertible to A<T1>". An example program: (Platform: VC++7.1) > > I guess you want the type-trait: is_convertible<from, to>. In his case, 'to' is an unbound family of types ('A<X>' for any 'X'), so 'is_convertible' won't do it. May be we should consider getting this in the library, in some form. E.g. tweak 'is_convertible' to support something like is_convertible<from, A<_> > -- Aleksey Gurtovoy MetaCommunications Engineering

3 3

Draft Critique of Code Conversion Proposal (N1683)
by Beman Dawes 07 Jan '05

07 Jan '05

Toward the end of a thread with the subject "std::string <-> std::wstring conversion" there was some discussion of how the C++ committee N1683 proposal could be improved. I volunteered to write up our discussions. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1683.html for a copy of the proposal. Here is a draft of what I have written so far. Comments and improvements welcome. --Beman Critique of Code Conversion Proposal (N1683) -------------------------------------------- N1683==04-0123, Proposed Library Additions for Code Conversion, proposes sorely need code conversion facilities for the standard library. (See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1683.html) Without these facilities programmers concerned with internationalization are forced to reinvent the wheel; Boost has run into that problem two or three times in existing libraries, and additional times in libraries currently in the Boost pipeline. The proposal should be accepted by the LWG as a high priority need. That being said, there are several concerns described in this paper which may indicate the proposal can be further refined and improved. 1. Hard-wired byte_string type in wstring_convert ------------------------------------------------- The underlying wstring_convert design seems flexible enough to cope with conversion between any two character types which meet std::basic_string requirements. Conversion is actually performed by std::codecvt, which is already parameterized by both internalT and externalT types. It seems artificial to restrict wstring_convert::byte_string to std::basic_string<char>. New character types such as the proposed char16_t and char32_t will need conversions to and from other wide types, yet with the current restriction wstring_convert could not be used for that purpose. Suggested change: replace typedef std::basic_string<char> byte_string; with: typedef std::basic_string<typename Codecvt::extern_type> byte_string; and change from_bytes argument types accordingly. If this suggested change is accepted, it will probably make sense to rename some wstring_convert members. 2. wstring_convert template parameter Elem seems unneeded --------------------------------------------------------- The wstring_convert template parameter Elem seems unneeded. Isn't it always Codecvt::intern_type? Suggested change: remove the Elem parameter and replace Elem with Codecvt::intern_type 3. Need target-argument form for wstring_convert conversion functions --------------------------------------------------------------------- wstring_convert's conversion functions are in the form: byte_string to_bytes(const wide_string& wstr) const; While this form is often useful and should be retained, it may imply an extra copy of the result if a compiler is not smart enough to optimize the copy away. Suggested change is to add additional functions in the form: void to_bytes(const wide_string& wstr, byte_string & target) const; 4. More explicit name for wstring_convert ----------------------------------------- "wstring" might be misleading, depending on the actual types involved. "convert" is a verb, yet nouns make better class names. Suggested change: wstring_convert to: string_converter 5. Standardese needed --------------------- The proposal needs improved standardese. For example, the requirements on the template parameters need to be specified and the function description converted to canonical form. 6. Comparable changes need to be made for wbuffer_convert --------------------------------------------------------- Any of the above changes which are accepted need to be folded into wbuffer_convert. Acknowledgements ---------------- This critique is based on discussions with Thorsten Ottosen, Stefan Slapeta, and Jonathan Turkanis. Revised: 05 January 2005

4 16

RE: [boost] Interesting Boost Implementation Details?
by Brian Braatz 07 Jan '05

07 Jan '05

> -----Original Message----- > On Behalf Of David Abrahams > > I'll be giving two talks at SD West in March, one about template > metaprogramming, and another called "Inside the Boost Libraries," where > I plan to discuss some of the more interesting Boost internals. You can > see a synopsis at > http://www.cmpevents.com/SDw5/a.asp?option=G&V=3&id=271893 > > I'm trying to decide exactly what to cover there. I've listed some of > my ideas below, but I'm obviously not familiar with the entire Boost > codebase, so I thought I'd solicit suggestions. Thoughts, anyone? > > My ideas: > > * Discuss the design of shared_ptr/weak_ptr. While not exactly an > implementation technique, the design is fiendishly clever and worth > exploring. > > * The use of template-generated polymorphism in Boost.Function to combat > virtual function bloat > > * The way that Boost.MPL uses partial specialization on template > template parameters to peel apart lambda expressions and turn them into > metafunction classes. > > * Something Boost.Python does to avoid doing dynamic lookup of argument > converters based on parameter types for each wrapped call. > > * Something Boost.Python does to dynamically build a chain of exception > handlers. > > * ... your ideas here ... :) [Brian Braatz] I am biased because I am going to be attending both of those :) My thoughts are also biased because, currently, boost.lambda has been the focus of my attention recently. (it is also currently my "favorite boost library of the month") Suggestion: Take Lambda and tear it apart and show how it works. This might be a good subject matter to keep a consistent topic as a foundation for covering techniques. The other thing you could do, is borrow the structure of your book, and use the same structure for the lecture. This way the attendees could then get your book, and have a consistency from the lecture to the book.

2 1

Re: Singleton
by Dave Handley 07 Jan '05

07 Jan '05

David A. Greene wrote: > > Dave Handley wrote: > > > I would love to see a robust implementation of a Singleton in Boost. > > Whenever I start a software project, almost without exception I tend to > > add both Boost and Loki to the project - it would be great if I could > > add only Boost. I have to say however, that a more general library > > which implemented a variety of design patterns (like Loki) would be even > > better. For example: > > > > 1) Singleton > > 2) Visitor - like Loki implementing both a conventional cyclic > > visitor, and an acyclic visitor. > > 3) Composite > > 4) Abstract Factory > > 5) etc. etc. > > Definitely. I've been wanting this for a long time. I haven't had > a chance to look at it yet, but from your description, your composite > and visitor code is a good starting point. I'd love to help out > with this effort. > I can provide a starting place on both the Visitor and Composite, but don't really have anything in the Singleton area that is up to scratch. Does anyone have a starting point for that - if so I suggest putting them all in a namespace like patterns and getting everything posted into the Yahoo group for some general comments. If there is interest, I could then set up a SourceForge project to run things from. I have to say that my code is flawed at present though: 1) My Visitor only supports acyclic visiting, but should support both cyclic and acyclic. I also want to set it up for const and non-const visiting (something else that the Loki visitor is weak at). 2) My Composite has a few major flaws. The first is that I need to make the iterator fully STL compliant - but that is relatively easy. The second is more serious and concerns destruction policy. At present, calling the destructor on composite objects causes dangling pointers. I did this because of a really subtle issue implementing the Composite in C++ which I will explain below, but I think destruction needs to be something handled by a policy class - then calling delete could optionally remove from the tree or not according to the policy. The flaw concerns the state of objects during destruction. It is quite common (in my experience) to use what I will term "Quick Pointers" in a complex composite structure - for example in a CAD system. A Quick Pointer is basically a cache of a pointer to a child. For a quick pointer to be safely handled it must be set up and deleted during the add_child/remove_child functions. It also usually needs to know the dynamic type of the tree members. When you get to destruction of the base class, the dynamic type of the node is no longer known, so the wrong add_child and remove_child functions (which must be virtual) get called - breaking tree invariants. To get over this you can make the base destructor protected, and force all destruction through a base destroy function which is what I have done. But, if you aren't using these quick pointers, then there is no point in this, and it is more intuitive to allow a call to the delete operator to dismantle the tree appropriately - hence why I want to make this into a policy. Dave

3 2

sunpro iterator test failures?
by Robert Ramey 07 Jan '05

07 Jan '05

http://www.meta-comm.com/engineering/boost-regression/developer/iterator.htm l show mostly failures for the sunpro platform. These failures inhibit the serialization libraries from building - (and probably others as well). Are there any plans to accomodate this compiler? If not, should it continue to be tested? Robert Ramey

4 7

Question and idea for smart pointers
by Ion Gaztañaga 07 Jan '05

07 Jan '05

Hello to all, While developing the Boost Shmem library I needed to be independent of the pointer types (raw or smart), so I started looking for those functions in Boost. As I've seen an overloaded "get_pointer" function returns a raw pointer from a generic pointer, and I've made the same with the relative offset_ptr from Boost Shmem. But to treat all types of pointer generically I needed to obtain from a generic pointer a pointer to other type of the same class. I've solved this defining in my smart pointer an internal type following the STL allocator rebind mechanism: /*!Obtains offset_ptr <OtherType> from offset_ptr*/ template<typename OtherType> struct pointer_to_type { typedef my_smart_ptr<OtherType> type; }; and the structs: template <typename Ptr, typename NewValueType> struct pointer_to_other { typedef typename Ptr::template pointer_to_type<NewValueType>::type type; }; template <typename T, typename NewValueType> struct pointer_to_other<T*, NewValueType> { typedef NewValueType *type; }; so that the user can generically write: typedef pointer_to_other<NewType>(my_smart_ptr)::type new_pointer_t; and obtain a pointer of the same class (smart pointer or raw pointer) to other type. My question is, do you find this mechanism useful to include it in boost in a general way, and if so, is there another way of doing this without modifying existing classes (for example, if I want use these mechanism with shared_ptr)? Regards, /Ion

3 3

patch: 3 bugs in pool.hpp
by Paul Du Bois 07 Jan '05

07 Jan '05

Please ignore my previous patch, if it ever made it through to the list. I have found 3 bugs in pool::release_memory(). I am under a bit of deadline pressure, so I'm sorry that I don't have the tuits to supply a tested patch for the tests :-). A tentative patch that fixes the bugs is appended, but it's only gotten the lightest of testing. I've tried to make the changes small, but the function is complicated enough that I'm afraid it's "no obvious bugs" rather than "obviously no bugs". Test case 1: ... block N all free Memory leak: blocks 0-(N-1) will be lost from the block list, because prev isn't being updated correctly. Test case 2: block 0 some non-free block 1 no free block 2 all free block 2 will not be deallocated, because prev_free is erroneously advanced too many times. There are other failure modes of this sort, but this is the simplest. Test case 3 (theoretical; the others happened to me block 0 some non-free ... block N (last block) chunks 0-m are free, and m+1 to the end are non-free Thus, m is the end of the freelist Crash: trying to call nextof(0).

1 0