- Boost - lists.boost.org

Re: [boost] [cpo-proposal] presentation of the idea
by Santiago Tapia 19 Aug '13

19 Aug '13

> Date: Fri, 16 Aug 2013 13:00:57 +0200 > From: Thorsten Ottosen <thorsten.ottosen(a)dezide.com> >> int main(int argc, char** argv) >> { >> classifier<base, std::allocator> collection; >> >> collection.insert( derived_A(21) ); >> collection.insert( derived_B(40) ); >> >> classifier<base, std::allocator>::iterator i, e = collection.end(); >> >> for ( i = collection.begin(); i != e; ++i ) >> { >> const base& x = *i; >> std::cout << x.do_something(6) << std::endl; >> } >> >> return 0; >> } > > I would like to see the use of forwrding in-place construction: > > collection.push_back<derived_A>( 21 ); > > using variadic templates. OK, I will try. > >> - The container's name is classifier because it classifies objects >> internally using the RTTI. > > I had similar ideas that I wanted to implement. I didn't expect to use > RTTI. Basically I wanted the class hierarchy's base class to derive from > a class with pure virtual functions that allowed the container to > perform the inplace-contruction, copying and alignment stuff. I am trying to make the interface of the container as easy as possible. I think using RTTI is an easy solution. > >> - The container classifier is _not_ a sequence. > > I would expect the container to allow forward iteration. I assume you > mean that erase/insert into the middle is prohibited? I imagined that > only push_back/pop_back was supported. > >> - The classifier uses continuous storage in memory for objects of the >> same type, therefore it is expected to improve cache efficiency with respect >> to solutions that use pointers (and new to allocate objects), especially if the >> client code uses some cache-aware allocator. > > I wanted to call my class template polymorphic_vector, taking base class > and allocator template arguments. I imagined that the storage > would be completely contigious, even when many different types of > objects where stored into the container. This would give maximum cache > efficiency. Then if the user wanted to sort or otherwise manipulate the > sequence, he could just create an std::vector<T*> of the elements > (Thus, push_back should probably return a pointer to the constructed > element). I am thinking about including that std:vector<T*> internally in another container, thus, I could provide a random access iterator. That could be "sequence_classifier". But I see a problem: if we only sort the vector<T*> then the objects in memory of consecutive iterations will not be contigous in memory and we will lose some of the cache efficiency. I will try to provide another kind of iteration, actually a two-levels iteration, like in a matrix, in order to gain access to the vectors of objects. That way we might sort objects of the same type without drawbacks. > > All in all, I hope you will persue this idea. I certainly have many > use-cases for it in code where efficiency matters, and in code where > using Boost.Intrusive is just must more work. > > kind regards > > Thorsten > Date: Fri, 16 Aug 2013 19:20:36 -0500 > From: Larry Evans <cppljevans(a)suddenlink.net> >> Yes, that is the idea. Actually, whether the implementation uses a collection >> of vectors or other mechanism is an implementation detail. I use a map >> of vectors in the classifier container, but I will try other implementations. > Is the map key something like the type_info: > > http://www.cplusplus.com/reference/typeinfo/ Yes, actually a wrapper of typeinfo because of a problem with typeinfo I could not workaround. But that is an implementation detail, I mean, that will be an inner detail of the library and I might find a better solution without changing the interface of the classifier container. > > If there is a separate vector for each type, then the storage for a > container containing more than one type can't be contiguous, > since the vectors for the containers for the types cannot be > contiguous, or am I missing something? I think what Thorsten > was aiming at in this post: > > http://article.gmane.org/gmane.comp.lib.boost.devel/243504 I could not follow the link... ? > > was each element in the container was truly contiguous. IOW, > given a container, c, then. > > c.insert(T1()); > c.insert(T2()); > > The T1 inserted into c would be contigous with the T2. No, in the prototype of the classifier T1 will not be contigous with T2, but: c.insert(T2()); c.insert(T2()); first object of T2 will be contigous with second object of T2. > > [snip] >>> Date: Tue, 13 Aug 2013 23:33:25 +0400 >>> From: Andrey Semashev <andrey.semashev(a)gmail.com> >>>> >>>> - The container classifier is _not_ a sequence. >>> >>> Why? Is this intentional? >> >> Both intentional and accidental, because I want to allocate objects >> contiguously in memory I have to store them in a collection of >> vectors, the container is not a sequence but a collection of sequences, >> one sequence for every class in the classifier. >> I will implement a sequence, but later. >> > > The above reinforces my above conclusion that T1 and T2 elements > cannot be contiguous in the container. A container might store T1 and T2 contigously, but up to now, that is not my idea, because it is more difficult and I am not sure about the efficiency of that alternative. Actually, I have read somewhere that there is a cache memory for functions, in that case, classifying the objects by type could be a good implementation because the virtual methods could be stored in the cache until the objects of that type were finished. > Date: Sat, 17 Aug 2013 08:12:48 -0400 > From: Rob Stewart <robertstewart(a)comcast.net> > To: "boost(a)lists.boost.org" <boost(a)lists.boost.org> > Subject: Re: [boost] [cpo-proposal] presentation of the idea > > On Aug 16, 2013, at 9:21 AM, Santiago Tapia <santiago.tapia(a)upm.es> wrote: > >>> Date: Tue, 13 Aug 2013 23:33:25 +0400 >>> From: Andrey Semashev <andrey.semashev(a)gmail.com> >>> >>>> - The allocator argument in the classifier will be applied to every object added to the classifier. Thus, the allocator is provided without its argument. The std::allocator is the default argument. >>> >>> You can use the standard interface for allocator rebinding: >>> >>> typedef allocator<T> allocator_T; >>> typedef typename allocator_T::template rebind<U>::other allocator_U; >>> >>> You can use std::allocator<void> by default then. >> >> I am not sure how to do this. I need a allocator with a parameter in order to get: allocator<triangle>, allocator<square>, ... this allocator must be instantiated when an object of a new class is inserted in the classifier. > > That's the point of rebind. Starting with allocator<A>, you can get allocator<B>. The spelling of allocator<B> just looks odd: > > typename allocator<A> template ::rebind<B>::other > > ___ > Rob > Understood, thank you both for the comment. > Date: Sat, 17 Aug 2013 09:20:14 -0500 > From: Larry Evans <cppljevans(a)suddenlink.net> > > The attached demonstrates, I believe, what Thorsten was aiming at > an shows the storage of *different* types in contiguous storage. > > HTH. > > > -regards, > Larry > >

3 2

[AFIO] AFIO Proposed feature Voting announcement
by Paul Kirth 19 Aug '13

19 Aug '13

Hello Boost-dev and Boost-users, I’m Paul Kirth, and I am the student working on the upcoming AFIO library this summer as part of GSoC. As of last week AFIO is fully ported to Boost and is now building cleanly on all of the last three major releases of the three most popular C++ compilers. Niall Douglas, my mentor for AFIO, has previously mentioned on the list that we would be asking for your feedback regarding which new features would be most beneficial to the Boost community. We would like to accommodate you all, but with GSoC being limited in time and ending in just one month’s time now, we’re going to limit the current additions to the top 3 most requested features. I plan to stay involved with AFIO for as long as I am able, so I’m sure many more of these features can be supported by AFIO in the future. I have set up a voting site on https://boostafio.uservoice.com to help with the voting. You may vote 10 times as you see fit, and you can give more (or all!) votes to those features you prefer the most. You may also add additional features not currently up for voting, so we encourage you to read the whole list of proposed additions before adding your own. Try to be descriptive with your feature request including a rationale, as not everyone involved with Boost may have the same expertise as you do. Including an example of how this feature would useful will help make a good case for your feature request, and help voters identify what is important. Finally, if you are not familiar with AFIO, we encourage you to take a look at our documentation at https://ci.nedprod.com/view/All/job/Boost.AFIO%20Build%20Documentation/Boos…. A link is also present on the voting site for your convenience. Additionally you will find our project on github at https://github.com/BoostGSoC/boost.afio, if you wish to dive into the source code for yourself. Voting is open right now, so please be sure to vote before the voting period ends on 8/23/13 at 11:59 PM GMT-8:00. We look forward to seeing which features are most important to the community, and hope to meet your expectations. Quick list of the features already proposed: Directory Monitoring Support Permissions and ACL Support Support for Boost Iostreams Improve Formal Closure Execution Engine Support Asynchronous Directory Enumeration Memory Mapped File Support Support for STL Iostreams Linux Kernel AIO Backend POSIX aio_* Asynchronous I/O Backend -- Paul Kirth

1 0

[Interprocess] Named pipe interface proposal
by Geoff Shannon 18 Aug '13

18 Aug '13

I emailed the list a while ago that I was starting to work on a named pipe implementation for potential inclusion in the Boost.Interprocess library, and now I finally have some concrete evidence of progress. I've come up with a header file for my proposed interface and I would really appreciate any and all feedback on it. Particularly, I'm interested in ideas for an appropriate replacement for using char *'s as the data buffers for reading and writing. As a point of interest this interface is meant to be extremely simple. I don't intend to initially support ANYTHING except for basic creation and reading and writing. Thanks! -- Geoff Nothing is ever easy.

9 36

about bessel function
by llwaeva＠gmail.com 17 Aug '13

17 Aug '13

Hi all, I am testing the bessel function boost::math::cyl_bessel_j in gnu compiler with boost 1.51.0, I am testing boost::math::cyl_bessel_j(2000, 0.9) boost::math::cyl_bessel_j(4000, 0.9) the first one give zero but the second one gives infinity while it should give zero also. I wonder why it doesn't work when the order is bigger than 4000?

2 1

Re: [boost] [Interprocess] Named pipe interface proposal
by John Venarchick 15 Aug '13

15 Aug '13

> > > > I would URGE you to make this exclusively a Boost.ASIO implementation. > > I also agree, an ASIO implementation is the way to go with this. > > 3. There seemed to be some confusion regarding named pipes on POSIX. > > > The only difference between Windows and POSIX named pipes is that the > > > former use the NT kernel namespace, within which the filing systems > > > are mount points, whereas the latter use the filing system namespace > > > directly. In my own code, I use a magic directory in /tmp as the > > > namespace for all my named pipes in the system in an attempt to > > > replicate a similar behavior to Windows, but there are many other ways > > > of doing the same thing. > > > > > > > Hmmm, I see what you're saying and I agree with it, but I'm also not sure > that > > it's strictly true that this is the "only" difference. > also a +1 to using POSIX pipes instead of domain sockets. I don't think you'd need to copy Niall's /tmp/ magic directory or if so make that an option. > > Also, FYI, I'm doing this project as an independent study through my CS > program. > > I'm getting close to the end of the quarter and I need to have something > > concrete to show for my efforts. Since I've already started down the > path > of > > implementing this not inside of Boost.ASIO, for the purposes of my school > > project I'm going to continue with that. However, I plan to continue > working on > > it after the scholastic bit is finished, and then I would be interested > in > > implementing it as part of ASIO. > > That's pretty cool as a CS project. I hope you get a good grade. I've done far too much with Windows pipes and would definitely like to see an ASIO interface if not just to replace what I'm doing now. -John V

1 0

Endian Library?
by Andrew Ho 15 Aug '13

15 Aug '13

Hi, I'm curious what the status for endian/byte order support in Boost is (namely, detecting system byte order and swapping between byte orders)? I did a quick search of the include dir and it seems that Spirit has some endian support, though I haven't found any documentation. There's also boost/detail/endian.hpp which has detection of the endian-ness, but doesn't provide any structure for switching between endians/byte-orders. I also found endian.h in predef, which appears to do something similar to boost/detail/endian.hpp. Searching through the list, there were at least 2 different proposals for Boost.Endian (a few years ago), though as far as I can tell neither of these implementations were formally adopted into Boost. I couldn't find any reason why they weren't included.

2 1

server error on ci.boost.org?
by Anthony Foiani 15 Aug '13

15 Aug '13

[Sorry for sending this to the dev list, but I didn't see a server admin email address anywhere obvious. Or I just went right past it, one of the two...] I was searching for something on Google, and one of the hits was on ci.boost.org: http://ci.boost.org/websvn/filedetails.php?repname=repos+1&path=%2Ftrunk%2F… [shortened: http://preview.tinyurl.com/lkvqbo3 ] When I went there, I got the navigation elements, but the actual content was missing, and instead there was a yellow warning box with this message: Unable to cat file: svn: Can't write to stream: No space left on device Thought you all might like to know. Thanks, Anthony Foiani

2 4

[Asio] Commit-rollback on asynchronous operations - cancel / close may fail
by Sorin Fetche 15 Aug '13

15 Aug '13

Hi, I noticed that functions for canceling asynchronous operations or closing objects on which they are executed are documented as being possible to fail. This is the case at least for the acceptor objects (basic_socket_acceptor or ip::tcp::acceptor), socket objects (basic_socket or ip::tcp::socket) and even timer objects (deadline_timer or steady_timer). In this case what are the options for implementing commit-rollback for asynchronous operations? By rollback I mean canceling a successfully started first operation in case a second operation in the batch of operations fails (as exemplified in the attached test code). As described in [1] a rollback operation absolutely relies on no-throw operations. What is supposed to happen with the handler associated with the asynchronous operation that failed to be canceled? Handlers, most often, at least for non-trivial programs are carrying shared resources with them and, if not called, may leave the application in a hanged state waiting for an event that will never come. I didn't find in the documentation any guarantees given regarding the handlers associated with the async-operations that they can or cannot be lost (that is never called). This of course, as long as io_service::run is running or the control returns to it after an exception. Also, as shown in [2] and as demonstrated by the attached test program, at least for async_write, invoking the destructor of an object on top of which asynchronous operations are being executed is not correct either and may lead to undefined behavior (crash). [1] Exception-Safety in Generic Components; section 6 http://www.boost.org/community/exception_safety.html [2] BoostCon 2011: Thinking Asynchronously; slide 47 https://github.com/boostcon/2011_presentations/raw/master/mon/thinking_asyn… Thank you, Sorin Fetche

1 0

[serialization] How are floating point values handled?
by John Maddock 14 Aug '13

14 Aug '13

I can't find anything in the docs about how floating point types are handled by the serialization lib. It seems like text archives print however many digits are specified in the ostream's precision is that correct? If so I think this needs to be raised as a big red flag, because it means that floating point values, uniquely compared to other primitives, do not round trip by default. Except actually they do when using a binary archive. This actually raises a problem when using text archives with floating point data - if you want to be able to round trip the values, then how many digits precision should you set the stream to? Particularly if you're saving a complex structure containing different floating point types of differing precisions? I would have thought it would be better for the serialization lib to set the stream precision before outputting a primitive type - to std::numeric_limits<T>::max_digits10 (or std::numeric_limits<T>::digits10+2 if max_digits10 is not available). However, I recognize that this is a difficult issue! Cheers, John.

4 15

Pre-build MSVC Boost binaries
by Fredrik Orderud 13 Aug '13

13 Aug '13

Over the last year, I've set up a small SourceForge "WinBin" project [1] for distributing Microsoft Windows binaries for Boost (and some other projects). The repository is sorted by Boost version, compiler version and shared vs. static linking. Each file archive contains pre-build boost in debug/release for both 32/64-bit, following a include/lib[64]/bin[64] folder structure. There also seems to be some other sources for pre-built boost around (e.g. https://sourceforge.net/projects/boost/files/boost-binaries/ and http://boost.teeks99.com/bin/) However, these do not seem to provide boost built for both static and shared linking. Also, they do not appear to adhere to the "quasi standard" include/lib[64]/bin[64] folder naming convention used by many libraries. Finally, they seem to lack information on which version of python (and possibly other 3rd party SW) they are compiled against. Therefore, I decided to set up my own boost-binaries webpage. Please let me know if you might be interested in either improving the "WinBin" project, or somehow joining forces to merge the various sources of Boost binaries into a single, more "authoritative" repository. I would be more than happy to shut WinBin down if "similar enough" binaries can be downloaded elsewhere. Thanks in advance, Fredrik Orderud [1] https://sourceforge.net/projects/winbin/files/boost/

5 10