- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-1469792 ] segm. fault during std::string (STLport 5.0.2) serialization
by SourceForge.net 13 Apr '06

13 Apr '06

Bugs item #1469792, was opened at 2006-04-13 12:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1469792&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: serialization Group: None Status: Open Resolution: None Priority: 5 Submitted By: simmeone (simmeone) Assigned to: Robert Ramey (ramey) Summary: segm. fault during std::string (STLport 5.0.2) serialization Initial Comment: There is an segmentation fault during STLport5.0.2 std::string object serialization. It is probably caused by new implementation of std::string. Now, one of possible implementation of _String_base class contains members: _M_buffers - union, wich holds dynamic char buffer _M_Finish - pointer to end of string in dynamic buffer In this case it represents our string, as a chain of chars, which is not ended with null separator. For example in my debbuger string "Un." is represented as: +_M_buffers._M_dynamic_buf 0x00378958 "Un.' 'data same as trigger' parameter is not set, 'use as data' cannot be changed.ÃÃÃÃÃÃWhen 'data same as trigger' parameter is not set, 'use as data' cannot be changed.ÃÃÃÃÃÃ`Å 7" char * -_M_finish 0x0037895b "' 'data same as trigger' parameter is not set, 'use as data' cannot be changed.ÃÃÃÃÃÃWhen 'data same as trigger' parameter is not set, 'use as data' cannot be changed.ÃÃÃÃÃÃ`Å 7" char * During serialization, there is used std::copy algorithm, which use template class escape, as an iterator, to iterate through the string. in file: ../boost/archive/iterators/escape.hpp we see function: void increment(){ if(++m_bnext < m_bend){ m_current_value = *m_bnext; return; } ++(this->base_reference()); m_bnext = NULL; m_bend = NULL; m_current_value = (static_cast<Derived *>(this))->fill(m_bnext, m_bend); } When iterator points to last char in string, and then is incremented, it points to next char in dynamic buffer _M_buffers._M_dynamic_buf - in our example with string "Un." it points to apostrof character '\''. Then function "fill" modifies "m_bnext" and "m_bend", because of character '\''. In the next step, function "equal" is called, to check if copy algorithm should be stopped or not. bool equal(const this_t & rhs) const { return NULL == m_bnext && NULL == m_bend && this->base_reference() == rhs.base_reference() ; } And because of m_bnext and m_bend are not NULL's, copy algorithm is not stopped and goes on. It leads to segmentation fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1469792&group_… ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Support for reading/writing binary 'streams' (asio?)
by Olaf van der Spek 13 Apr '06

13 Apr '06

Hi, When reading/writing binary streams, you often need to read/write an (unaligned) integer in big, little or native endian. Is there support for this in Boost? I think iostreams isn't usable as 'zero-copy' is required. What do other Boost developers/users use/recommend? Wouldn't this make a nice additional to the new asio library? Olaf

7 11

[shmem-interprocess] New Shmem bugfix version in cvs and Boost Vault and Interprocess is on the way
by Ion Gaztañaga 13 Apr '06

13 Apr '06

Hi to all, Thanks to all people sending bugfixes for the good old Shmem library. I've uploaded a new version (0.91) with the bugfixes. I would like to thank specially Peter Johnson and Michal Wozniak (Michal, I've tried to reply your mails but they are rejected saying your address was not valid) for their extensive bug hunting and suggestions. Meanwhile I'm working on Interprocess. I've replaced my old two-phase construction and implemented Filesystem-like error handling. mapped_file and mapped_region classes are done. I'm adding more tests to avoid embarrassing lock function problems found on shmem. Boost.Date_Time is now used with mutexes instead of good old xtime. I have a lot of work to do (I have to rework all the documentation, for example) but I plan to start reworking documentation soon. I will add some ABI breaking changes also (for example, small string optimization for shared memory basic_strings). I also plan to change the default top-bottom allocator to a bottom-up allocation so that I can in the future implement realloc-like functions and allocator version 2 functions. I *lot* of work. Please be patient! Regards, Ion

1 0

Re: [boost] [multi_index] Problems with chained pointers in multi index from 1.34 RC
by JOAQUIN LOPEZ MU?Z 13 Apr '06

13 Apr '06

----- Mensaje original ----- De: Alexei Alexandrov <alexei.alexandrov(a)gmail.com> Fecha: Miércoles, Abril 12, 2006 7:17 pm Asunto: Re: [boost][multi_index] Problems with chained pointers in multi index from 1.34 RC > JOAQUIN LOPEZ MU?Z <joaquin <at> tid.es> writes: > > > > > 1. What is the compiler error you're getting? > > > Now, from what you report, seems the restriction is > > being too much comprehensive. Could you test what is the > > value of > > > > boost::is_convertible< > > const name_record::Ptr, > > const name_record > > >::value > > > > on your compiler? > > No, this thing compiles and expands to false as expected. In fact, > the error > I'm getting is about > > boost/boost/type_traits/is_convertible.hpp(254): error: class > "name_record" has > no suitable copy constructor > BOOST_STATIC_CONSTANT(bool, value = > ^ > detected during: > instantiation of > class "boost::detail::is_convertible_basic_impl<From, To> [with > From=boost::detail::is_convertible_impl<const name_record, const > name_record>::ref_type, To=const name_record]" at line 286 > instantiation of class > "boost::detail::is_convertible_impl<From, > To> [with From=const name_record, To=const name_record]" at line 362 > instantiation of > class "boost::detail::is_convertible_impl_dispatch<From, To> [with > From=const > name_record, To=const name_record]" at line 409 > instantiation of class "boost::is_convertible<From, > To> [with > From=const name_record, To=const name_record]" at line 59 of > "D:\src\3rd- > parties\boost/boost/utility/enable_if.hpp" > > and can be reproduced with > > bool br = boost::is_convertible< > const name_record, > const name_record > >::value; > > It fails to compile as well. It seems that is_convertible doesn't > handle > noncopyable target type well. I guess you mean the source type (i.e. the From argument.) Well, this also explains the problems you're getting, and it's a serious issue (IMHO) with boost::is_convertible. I'll report this in a separate post. In the meantime, I guess you can work around the problem by specializing boost::is_convertible<const name_record,const name_record> like this: namespace boost{ template<> struct is_convertible< const name_record, const name_record >: public true_type{}; } This tecnhique is sanctioned at http://boost.org/doc/html/boost_typetraits/user_defined.html HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[review] promotion traits - result
by Tobias Schwinger 13 Apr '06

13 Apr '06

Dear Boost community, Alexander Nasonov's Promotion Traits have been accepted conditionally into Boost with 4/4 positive votes. The conditions are - an example must be added to the documentation (plus accompanying source code for the example folder), - the reference should be clarified (cv-qualification, bit fields) - further conditions might arise from the merger with the extended library (TypeTraits) and are subject to synchronization with the library maintainer (John Maddock). Thanks to Alexander for the submission and to our reviewers for their work! Regards, Tobias (Review Manager)

3 2

[config] borland.hpp updated
by Nicola Musatti 13 Apr '06

13 Apr '06

Hallo, I just committed a small change to boost/config/compiler/borland.hpp . This should enable proper regression testing for the latest compiler, 5.8.2 beta. Cheers, Nicola Musatti

1 0

[preprocessor] computed include possible?
by Roland Schwarz 12 Apr '06

12 Apr '06

I am wondering if it would be possible to write a computed include macro that is sufficiently compiler independent? E.e. given a macro #define BOOST_PLATFORM_INCLUDE(hdr) ... definition missing ... which should be usable as: #include BOOST_PLATFORM(foo.h) The effect being win32/foo.h included on one linux/foo.h included on another platform. I have yet figured out a way that can achieve something close, but gcc does not allow to use a parameterized macro. I would be interested if someone has some experience with this. Roland

6 13

intrusive pointer, rationale for preferring shared_ptr instead.
by Ulrich Eckhardt 12 Apr '06

12 Apr '06

http://boost.org/libs/smart_ptr/intrusive_ptr.html says: "As a general rule, if it isn't obvious whether intrusive_ptr better fits your needs than shared_ptr, try a shared_ptr-based design first." I wonder why? Embedding the refcounter into the object seems to me much more natural and performant than adding another free-store allocation which shared_ptr requires. Another related thing is why is there no complementary class to add a refcounter to an object? Something like template<typename ObjectType> struct refcount { refcount(): refs(0) {} ~refcount(){} private: refcount( refcount const&); refcount& operator=(refcount const&); friend void intrusive_ptr_add_ref( ObjectType* o) { static_cast<refcount<ObjectType>*>(o)->add_ref(); } void add_ref() { inc(refs); } friend void intrusive_ptr_release( ObjectType* o) { static_cast<refcount<ObjectType>*>(o)->release(); } void release() { dec(refs); if(!refs) delete static_cast<ObjectType*>(this); } some-integer-type refs; }; (I think that I can't legally inject functions into the surrounding namespace via these friend functions, but maybe there's a workaround and this is just a sketch. ) Uli

5 6

Re: [boost] [multi_index]terminology/design concern
by JOAQUIN LOPEZ MU?Z 12 Apr '06

12 Apr '06

Hello Gennadiy, ----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> Fecha: Miércoles, Abril 12, 2006 7:09 pm Asunto: [boost] [mulit_index]terminology/design concern > Hi, > > It possible that I just missing something and it was already > discussed. But > I find the terms used by the library misleading and/or incorrectly > used. The > library present different views on the same data. Each view is > defined by > notion of "Index". My understanding if term index is something > close to the > index at the end of the book. The thing is modeled here I would > rather > called an "Order". > Even more importantly is that I feel the these concepts are > kind of mixed > into one in library design. I understand that we want multiple > Orders for > the same data. Each order define a view to the container. Each > view present > iterators to access this view. Different views have different > iterators, > which are not comparable in any way. >From your description above, seems to me what you understand as an "order" is verily what the index concept (as used in Boost.MultiIndex) tries to model. Basically, an index is an access interface to a set of objects jointly owned by several other indices --in contrast with regular STL containers who own their elements in an exclusive fashion. The problem with the words "view", "order", "index", etc. is that they are badly overloaded. David Abrahams recently objected to the current use of "index" since, for him, this word is customarily used to refer to the distance between an element and the beginning of the container it belongs in (as for instance the argument of std::vector::operator[]). I would have happily used "view" instead of "index" but refrained myself because the term "view" was already used by some view libraries (e.g. Maciej Sobczak's view library at http://www.msobczak.com/prog/publications.html or Gary Powell and Martin Weiser's VTL at http://www.zib.de/weiser/vtl/) with a somewhat different meaning: these views are detached from the elements they're constructed from (so that further changes to the elements may not be reflected back to the view) and may list only some of the elements (filtering views.) At the end I decided on "index" to avoid semantic clashing with preexisting definitions of "view" and because the concept is more or less related to indices as used in relational databases --in fact, the definition of a multi_index_container is kind of reminiscent of the way one declares indices for a relational DB table. "Order" would be a good candidate, except that it's generally tied to fixed-order containers (sets, maps), and Boost.MultiIndex also includes sequence-like constructs. > Now for any view (for any > order) I may > want to have one or more Indexes. Index is something that provides > direct(random) access based on some key into view. Index present > iterator > interface. All indexes for the same order present the same > iterator which is > a view iterator. > Lets consider some example: an address book. We may have > different orders > defined: > 1. City, Last name, First Name order > 2. Last name, First Name order > 3. Phone number order > 4. Time registered order > > Now each order may have in addition following Indexes defined: > 1. City, Last name, First Name > a) City Index: jump to the first record in the particular city > 2. Last name, First Name > a) Last Name Index: jump to the first record with particular > last name > 3. Phone number order > a) Area code Index: jump to the first record with particular > area code > 4. Time registered order > a) Year Index: jump to the first record registered in > particular year > > I see Order and Index as two independent concepts and current > model seems to > mixing them in one. I'm afraid I'm not quite getting what you mean by "index" in this context. Certainly, the kind of operations you describe can be performed in Boost.MultiIndex by means of so-called "compatible keys" as described in http://tinyurl.com/rouet, so that, for instance, given an ordered index sorted by (last name, first name) one can jump to the records beginning with some given last name. Is this what you're referring to? If so, the only thing I can say is I never thought of these operations as directly related to an index concept. If you could elaborate on your discussion maybe I'll be seeing your point more clearly. Thanks for discussing your concerns, I hope at least I've shed some light on them. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[test] Warnings in test_tools.ipp on CW
by Stefan Slapeta 12 Apr '06

12 Apr '06

In CW tests, I get a lot of warnings like this one: ### mwcc Compiler: # In: ..\boost\test\impl\test_tools.ipp # From: ..\libs\numeric\conversion\test\traits_test.cpp # -------------------------------------------------------- # 161: /* toler_descr = */ va_arg( args, char const* ); # Warning: ^ # expression has no side effect # (included from: # C:\br\boost\boost\test\included\test_exec_monitor.hpp:26 # C:\br\boost\libs\numeric\conversion\test\test_helpers.cpp:19 # C:\br\boost\libs\numeric\conversion\test\traits_test.cpp:29) ...because of these lines: /* toler_descr = */ va_arg( args, char const* ); Maybe this expression could be changed to something else? Thanks, Stefan

2 1