- Boost - lists.boost.org

test...ignore
by Jeff Garland 24 Apr '07

24 Apr '07

1 0

[asio] Multiple Interface Multicast Receive Error
by dhk24＠drexel.edu 24 Apr '07

24 Apr '07

I am trying to get a dual homed computer working receiving multicast messages using ASIO and there appears to be all kinds of problems. Firstly, when trying to receive multicast traffic ASIO will only ever bind to one address. Even explicitly providing an IP address to bind to will not convince the OS to allow you to bind to that address. In my case it always attempts to bind to the device that is connected to the WAN. Secondly, even if both devices are connected to the same network, ASIO will only receive multicast packets on one interface. If that interface is disconnected it will no longer receive multicast packets. I have tested this using both the any address and with explicit IP addresses over multiple sockets. Neither seem to work. Disabling all interfaces except the one receiving Multicast traffic allows ASIO to bind to the last remaining interface and receive packets properly. I have seen this problem using ASIO 0.3.7 and both my own programs and the default multicast receive included with ASIO. I have also been able to replicate it using Windows XP SP2 and Fedora Core 6 ( 2.6.20-1) Any explanation or help would be greatly appreciated Dan

2 1

serialization idea - netcdf4
by Neal Becker 24 Apr '07

24 Apr '07

I wonder if anyone has worked on this? It seems serialization of numerical containers to standards like netcdf4 would be very useful.

2 1

Re: [boost] Boost packages?
by Paul Hickey 24 Apr '07

24 Apr '07

Excuse the super long delay in posting this, I did try a couple of weeks back but failed to register first. Paul Hickey wrote: > > David Abrahams wrote: >> on Mon Apr 02 2007, Roland Schwarz <roland.schwarz-AT-chello.at> wrote: >> >>> David Abrahams wrote: >>>> No, boost is not even one library much less a monolithic one. Boost >>>> is a library collection. I've seen the dependencies among the Boost >>>> libraries graphed, and unlike some other development frameworks, >>>> which just show up as a big blob, Boost is neatly partitioned and the >>>> dependencies tend to be a unidirectional DAG. >>> Really? I very much would like to see this graph. >> >> It was in a preview of code structure analysis software from this >> company: http://headwaysoft.com/index.php. They were interested in >> making an analysis of Boost publicly (I think) available online. I've >> Bcc'd my friend there; if he wants to pipe up, he will (Paul, you have >> to register if you want to post on this mailing list). >> > Just back from vacation so excuse the slow response. > >>> If this is available somewhere I think it would be nice to show it >>> somewhere on the web! >> > Dave was referring to a product we used to sell called Headway Review, > which had reasonable GCC C++ support and poor VS C++ support. Headway > Review has since been put out to pasture, and been replaced by the > leaner, meaner, cleaner Structure101. > > Support for C++ for Structure101 is long overdue, but hopefully will > see light of day before the end of the year. More anon. > > Given the lessons we learnt from Headway Review in general and Headway > Review for C++ in particular, when Structure101 for C++ does finally > see the light of day, I am confident the folks in the Boost community > will be interested. ;-) > >> Agreed, for real. >> >>> Besides being a nice eye-candy it would >>> support those in need for these kind of arguments. >> >> Ditto. >> >>> I would have volunteered in providing this graph, but unfortunately >>> I must have been doing something completely wrong when I was trying >>> to generate such a graph on my own. It reminded me very much of the >>> wool ball my cat likes to play with than a well structured graph. :-( >> > If you really want to do this now, I'd be happy to provide an > unsupported copy of Review so you can get some sense of where you stand. > Contact me directly if you do. > >> Well, at the time, Headway's software really did show a remarkable >> difference between Boost and ACE in that respect. >> > Thats for sure! ;-) >

1 0

Marshalling library
by Hans Larsen 24 Apr '07

24 Apr '07

Is there a marshaling library in boost and is there an interest in such a functionality? Is the serializing library any use to marshall calls? I've not seen any mails concerning marshaling recently, though I might have missed one. Thanks, Hans I'm thinking something along the lines of the following. Although it may not be possible, I think it is (maybe the function registry is not necessary). int func( int i, int j ) { using namespace std; cout << "i: " << i << " j:" << k << endl; return i + j; } int main() { using m = boost::marshall; using std; int funcid = 1; m::register_function( funcid, func ); // Using same principles as in boost::function for type safety. m::call x(funcid, 1, 2); string str = x.serialize(); m::call y( str ); try { cout << y() << endl; } catch( m::invalid_function x ) { cout << x.what() << endl; } return 0; } // ------ // Should output: // i: 1 j: 2 // 3

5 16

[GIL] GIL is in Boost CVS repository
by Lubomir Bourdev 24 Apr '07

24 Apr '07

The latest GIL is now in Boost's CVS repository. Thank you for the insightful reviews. We have implemented many of the suggested improvements in GIL 2.0. A summary of the more significant changes can be found here: http://opensource.adobe.com/gil/gil2.0_changes.pdf Thanks, Lubomir

1 0

boost::freetype - extension for boost::gil
by Tom Brinkman 24 Apr '07

24 Apr '07

>> I'd rather we not call it freetype at all - wrap it up as a generic >> text renderer, that just happens to use freetype underneath. I'm not shur how the adobe's guys will want to incorporate the extensions. This freetype wrapper will be just one of many extensions that will be added to GIL.

3 2

Fixed point arithmetic - any interest?
by Phil Endecott 24 Apr '07

24 Apr '07

Dear All, I have recently written some code for fixed point arithmetic which I would be happy to contribute to Boost, if it is considered worthy. Please let me know if this is something that you would use, especially if you would be able to help with testing on platforms other than Linux and other tasks necessary for Boostification. Here's a very quick summary: You declare a fixed-point variable by specifying the number of whole-number bits and the number of fraction bits, e.g. fixed<8,23> x; This has a range of about -256 to +256 with a precision of 1/(2^23), and occupies 32 bits. boost::integer is used to choose an implementation type with sufficient bits. The usual arithmetic operators are implemented with some help from boost::operators, and should have no overhead; note that overflow is not detected (like the built-in integral types). Implicit conversions are provided to and from the built-in integral and floating-point types (well, actually I have only added the ones that I have needed; the others should only need copy&paste). Implicit conversion between fixed types of different sizes is also possible. I'm starting to think that perhaps I should make some of these conversion explicit: I worry that code using this might be doing an "invisible" conversion via a floating point type that I didn't want. Any thoughts about this would be appreciated. Operations between fixed-point values of different sizes are possible, and return a fixed-point value with sufficient bits to store the result. For example: fixed<10,4> a; fixed<15,2> b; fixed<15,4> c; c = a + b; ..except that actually one more bit is needed in the maximum-value case. There are no doubt more opportunities for refinement in this area. You can see the code here: http://svn.chezphil.org/libpbe/trunk/include/fixed.hh Thanks for your attention. Phil.

9 15

proto::or_ arity
by Maurizio Vitale 23 Apr '07

23 Apr '07

proto::or_ (and I presume, but not verified, proto::and_) requires at least 2 arguments. It might be nice to allow 1 argument (and maybe 0 arguments as well). Zero and one can happen while playing around during development, but more importantly as the result of invoking other metafunctions computing grammars. Whether it is really an issue in practice, I cannot tell. For now I've hit this in the 'playing around' part, haven't needed to compute grammars yet. At least with GCC, the error you presently get when you try proto::or_ with one argument is that it requires 8 arguments, with no indication that anything between 2 and 8 would work. Arguably GCC error messages could be improved to take into consideration default aruments, but this is what 4.1.2 does. Best regards, Maurizio

6 20

creating a threadsafe singleton class
by Clark Sims 23 Apr '07

23 Apr '07

http://acumenconsultinginc.net/TechNotes/ThreadSafe/ I used the boost scoped_lock, and shared_ptr classes, to create 2 template classes which provide threadsafe access to a singleton class. I also included the example of a singleton class which has a destructor. --------------------------------- Ahhh...imagining that irresistible "new car" smell? Check outnew cars at Yahoo! Autos.

2 3