- Boost - lists.boost.org

[Format] Failures on sunpro-5_3
by Doug Gregor 01 Apr '05

01 Apr '05

All of the Boost.Format tests are failing on SunPro 5.3 with this error: "/home/nbde52d/src/boost-regression/boost/boost/format/ alt_sstream_impl.hpp", line 248: Error: Cannot assign void* to char*. Can this be solved, or should we mark this compiler as unusable for the Format lib? Doug

2 1

Re: [boost] Re: Re: Asynchronicity (long)
by Iain Hanson 01 Apr '05

01 Apr '05

On Fri, 2005-04-01 at 19:57 +0400, Maxim Yegorushkin wrote: > By the way, we use libevent and are happy with it. It's portable > (Linux/Windows) and has very simple interface. I just don't see a need for > the stuff you guys are discussing here. > Because we like our libraries spelt in C++ :-). /ikh

2 1

Classpath to C++ conversion
by Tushar 01 Apr '05

01 Apr '05

Hi all, I am thinking of converting GNU Classpath used for GCJ to C++. I have following reasons about why to do this. 1. C++ requires a Good OOPs library with well defined api. Java has that . While C++ also have many of them, most do not look truly object oriented. As all of us know, Java is really a subset of C++ from pure language point of view. C++ has every thin that JAVA has except GC. But still programming in JAVA is more easy because they have a well define API to work with. I thinks, we should have some thing similar in C++ also. 2.C++ has much of the libs using STL. The only problem is STL is not a object oriented.(See STL Tutorial and reference) This really makes it difficult to think in OO and implement in STL. Particularly in STL, T a,b T a=b means a is separate entity and same for b. This make problem in many case where one wants just pointer e.g File handling and manipulation of large buffer. 3.There are other "standard" API to work with things like thread and networking. I know many libs are there on this boost and some other good site, but there is no uniform framework to work with in C++,one like one JAVA provides. These was some reasons why C++ libs are required. My idea is that API specification is already defined for java. And it seems much complete.I mean to say more complete then if start deciding from scratch -:). Why not to use java then? 1.JAVA is not free neither under GPL. 2.GC makes problem for many programs. 3.Compilation of java to binary using GCJ or something similar gives performance problem 4.After all, many C++ programmer like me do not want to change language but I do want a good uniform library. Difference bet proposed C++ and Java 1.Everything is a pointer other them simple atomic data types.(Same) 2.There is no GC. Its here large change will be required. (Diff) 3.Arrays - I do not know. Should it be made object like in java or let it be as it is in C++. Later seems good and one can use some class like Array to have similar effects.(?) 4.Every thing is subclass of Object(Same). 5.Sync support in Object (i.e to every object) using wait and signal - I am not sure. This makes it easy but may also bring some performace problem (?) Ok, enough thinking. Now implementation. Here I am thinking of converting entire GNU Classpath to C++. One major change will be lack of GC. For others, I will have to dig deeper. For GNU Classpath people, it will be review of their code. Regards, Tushar

10 24

Re: [boost] Re: Asynchronicity (long)
by Iain Hanson 01 Apr '05

01 Apr '05

On Fri, 2005-04-01 at 09:14 -0500, Edward Diener wrote: > Boris wrote: > 1) No one normally uses 1000 sockets. Be real rather than hyperbolic if you > are trying to make a point. Sorry, but that is a bad assumption. A server that I'm currently working on will have 1,000's of sockets open concurrently. Application gateways, web servers and database connection concentrators are typical of Apps that often need large numbers of sockets. /ikh

2 1

Re: [boost] Re: Re: Asynchronicity (long)
by Iain Hanson 01 Apr '05

01 Apr '05

On Fri, 2005-04-01 at 18:02 +0300, Boris wrote: > Iain Hanson wrote: > > On Fri, 2005-04-01 at 13:53 +0300, Boris wrote: [snip] > I don't think our opinions are very different. You agree that library users > should have some control about the implementation for a better performance. yep! > There is really a trade-off between design and performance. As we have seen > in another thread today's operating systems don't support asynchronous I/O > very well. They don't need to as long as they support threading. > In Linux asynchronous I/O would be probably best implemented > using epoll() as multiplexing is the traditional *unix way. No. The unix way is to have as many orthogonal ways of doing something as possible ;-). Because the user knows best what works well on their platform they should probably be able to select the implementation whether it uses epoll, user space threads, or kernel supported aio. > A C++ network > library which can't support efficient I/O because of its design won't be of > much use. It could be perfectly designed but it couldn't be implemented > using best available I/O APIs on different operating systems. > I don't understand what your trying to get at here. There are sufficient mechanisms to does this on all the major platforms. It is just that they happen to vary by platform. /ikh

1 0

Re: [boost] Re: Asynchronicity (long)
by Iain Hanson 01 Apr '05

01 Apr '05

On Fri, 2005-04-01 at 13:53 +0300, Boris wrote: > While asynchronicity in .NET is basically based on threads it is not true > for asynchronous I/O. If you built asynchronous I/O on top of an > asynchronicity library with callbacks in threads you will end up with 1000 > threads blocked in read() if you have 1000 sockets. No. This would be a configuration or implementation detail. The only requirement is that you have at least 1 thread dispatching async requests and queueing work to be dispatched. LibC AIO has an init function where the user can supply a hint regarding size of thread pool to use. I think the contract for a C++ lib should be stronger and allow the user to specify/control the size of the thread pool as well as the type of the ACT ( not just callback, but signal and polling ). /ikh

2 1

[format] conversion to string
by Vladimir Prus 01 Apr '05

01 Apr '05

Hello! While it's generally considered a bad practice to provide implicit conversions, I think it would be good to provide such a conversion for the boost::format class. Currently, I can't write: string s; s = format("%1%") % 10; and need to write s = (format("%1%") % 10).str(); Maybe it's specifics of my code, but I can count 10 such conversions in a single source file. I think that: 1. Calling .str() is rather inconvenient. 2. The 'format' class most often used inside expressions. It's not likely to be passed around to functions and so the dangers of implicit conversions are not critical. Thoughts? - Volodya

4 7

Re: Asynchronous I/O
by Don G 31 Mar '05

31 Mar '05

Hi Robert, Thanks for contributing to these discussions! I hope that with you and the others involved we can get this long overdue library off the ground. Anyway, to respond to your question: --- Robert Ramey wrote: > The question here is: > > Is aio.h interface not sufficient in some way? If not, what > facility is it missing? If it is sufficient, then just > depend on the available implementation or re-implement the > interface in the most convenient way. > > Robert Ramey IMHO, the "io" part of "aio" is the primary thing what makes it insufficient. Unless I misread the man pages, I cannot post custom events or messages with aio; it is all about I/O on file descriptors. Which brings me to the other problem. At least on Windows, a file != socket != pipe != etc (regardless of the quasi-polymorphic WaitForXXX functions). If we constrain the discussion only to sockets, then this approach could be used. Sadly, pipes are a totally different ball game. If memory serves, the CygWin folks "mapped" all such types of objects to fd's, but doing so was very heavy handed. There was no other solution to their particular problem, but that is not the case here since we can invent the interface. The first issue is what spawned to Asynchronicity thread: given a general async mechanism, I/O could be easily adapted to it. The interface could be portable, even given the diverse ways and means necessary to achieve the goal. If we are to adopt an existing interface, I believe that it should be general enough for non-I/O uses. It should also be something that could be implemented on all platforms without undue inefficiency (something a select-style interface could not do, IMO, because of the poor performance of populating fd_set's or their moral equivalent). In a previous post I showed that the async technique I am proposing could be (fairly<g>) easily used to shield the application from library worker thread issues. With a little more work (and coupling), the use of channel.async_call could be encapsulated/automated to simplify the user experience. Best, Don __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

3 3

Boost policy on relying on std library implementation defined behaviour
by Jonathan Turkanis 31 Mar '05

31 Mar '05

Hi All, Is there a reason to avoid providing a uniform interface to implementation-defined standard library features? One of the most often heard complaints about the standard iostreams library is that there is no portable way to seek within a file stream using large (64-bit) offsets. Simplifying a bit, the standard library provides functions for seeking within a stream using - an offset of type streamoff, which may be 64-bits but is sometimes smaller, or - a position indicator of type streampos (usually fpos<mbstate_t>), a non-integral implementation defined type, with implicit conversions to and from streamoff. (streampos also stores a code conversion state, but I'm ignoring this) There are platforms where streamoff is inadequate to express an arbitrary seek offset, and where streampos is adequate, but only if implementation defined functionality is used. (There might be cases where neither type is adequate, but I'm ignoring this) I would like to implement functions which provide conversions between a large integral type and streampos. This will allow most uses of streampos to be hidden, with library users specifying integral types most of the time. The alternative would be: 1. provide additional concepts which require user defined filters and devices to implement functions involving streampos, AND 2. force users to deal with streampos directly, relying whatever guarantees are provided by their standard libraries. Point 1. requires complicating the iostreams library interface. Point 2. forces users to implement functions which could instead have been implemented just once by the iostreams library. What do people think? Jonathan

6 11

Re: [boost] Addition for shared_ptr
by Peter Dimov 31 Mar '05

31 Mar '05

Michael Rutman wrote: > At 1:40 PM +0300 9/20/04, Peter Dimov wrote: >> Michael Rutman wrote: >>> I'd like to propose adding a template function to shared_ptr to >>> allow the automatic testing of a shared_ptr to its raw ptr. >>> >>> The template is as simple as >>> >>> template <class T> >>> bool operator==(boost::shared_ptr<T> const & a, T * const & b) >>> { >>> return a.get() == b; >>> } >>> >>> >>> Here is the case where I need it. >>> >>> I have a vector<Foo> myFoo. >>> >>> In a method of Foo I need to see if this instance is in the vector. >>> I want to do this >>> >>> vector<Foo>::iterator iter = find( myFoo.begin(), myFoo.end(), this >>> ); >> >> This is a reasonable suggestion. It turns out that std::find _is_ >> specified in a way that allows heterogeneous comparisons, although >> this may be an oversight on the part of the committee and not a >> design decision. ;-) > > Any chance this can go in for the next release? <tilts head and ponders for a moment> Probably not, but not because it's necessarily a bad idea. I only add extensions to components already in TR1 if I'm reasonably sure that I want to (formally) propose this extension for a later version of the component (TR2, or C++next). Which in this case I'm not (yet).

1 0