- Boost - lists.boost.org

Any Interest in a 3-D Vector library?
by Stefan Koch 23 Apr '05

23 Apr '05

Any interest in a templatized class for 3-Dimensional vectors? (Similar in style to std::complex or boost math/octonion and math/quaternion.) The most recent uses I have had for it are in ray tracing of scattered light through an experimental setup, and in calculating the bending parameters for a pipe of a certain shape. Basic Features: Constructor and component access. Addition and subtraction of vectors. Multiplying and dividing vectors with scalers. Dot and Cross products of vectors. Length (norm) calculation an conversion to unit vectors. Stream I/O. More Advanced Features: Spherical coordinates Cylindrical coordinates Rotations (around principle axes and general axes) Reflection by a surface Refraction across an interface (Snell's law). Rotations are specified by the axis about which the rotation is to be done, and the angle through which to rotate. There is no support for general rotation matrices. What do you think? Stefan

1 0

[optional] End-of-lines problem.
by Rene Rivera 23 Apr '05

23 Apr '05

Please be careful when "fixing" EOL problems you encounter so as not to create additional ones. This change: http://build.redshift-software.com:9990/changes/514 Caused the EOLs to be duplicated: http://tinyurl.com/b6h3r Causing a variety of failures like this one: http://tinyurl.com/bdqrj -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

1 0

Re: [network] An RFC - updated
by Don G 23 Apr '05

23 Apr '05

Hi Michel, > Is it a problem that the special or specific adresses is > represented by different textual representations for > different networks? I guess a textual representation > could be devised that makes these look the same with > some psuedo notation. > Like broadcast tcp:/[broadcast]:1234, > tcp6:/[broadcast]:1234, local tcp:/[local]:1234, > tcp6:/[local]:1234, any > tcp:/[any]:1234, tcp6:/[any]:1234 this would i guess > alleviate some of the eventual problems. The pseudo-tokens would work as long as they weren't ambiguous with allowed machine names in that network. I think a simple layer to register network objects (so you don't get them all linked in<g>), plus a fully general text-to-address object mapping would be a reasonable facility. Again, though, I view this as a (good) simplified use case and would still want control over the life-time of these objects (see other posts for the sad story<g>). I do recognize my concerns here are probably not too common, but all this might mean is that an http_get wrapper would be overloaded on url and address_ptr. The former would call the later after a lookup. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Serialization: docs addition
by Darren Cook 23 Apr '05

23 Apr '05

Hi, Can I suggest adding another example to: http://www.boost.org/libs/serialization/doc/special.html#objecttracking I had this code: void mycallback(const BigClass &BC){ const SomeData *d=BC.get_data(); ... archive & BOOST_SERIALIZATION_NVP(d); } My archive was smaller than intended and I discovered that the data only got saved the first time. XML version showed me it was using: object_id_reference. It turns out the fix was to dereference the pointer: archive & BOOST_SERIALIZATION_NVP(*d); That is an easy to write bug; I cannot see how the serialization library can catch it, so all I can think of is to make people aware of it in the docs. Also please mention "object_id_reference" in the objecttracking section of the docs, as that was the first thing I googled on and it got no useful hits. Darren

2 2

[website] Fluid layout.
by Rene Rivera 23 Apr '05

23 Apr '05

OK I've done more changes/improvements. It's now a fluid layout. Since no one except Dave had suggestions on what to I went with his idea of two (mostly equal) columns. In this case the left is fluid the right is fixed. I also removed everything except the latest release information. For the simple reason that more than that make the page unnecessarily long. After all anything older than the latest version isn't "Latest News". http://redshift-software.com/~grafik/boost/index.htm -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org

11 26

Re: [network] An RFC - updated
by Don G 23 Apr '05

23 Apr '05

Hi guys, > Peter Dimov wrote: >>Michel Andr� wrote: >> Should several pending reads be allowed? I have >> leaned back and forth on this issue in a previous >> platform specific async com library I wrote. > > Definitely; a server that has N active connections > might have up to N reads active at any time. Not > on the same socket, of course. :-) If I understood Michel's question correctly, then your answer would be "no". As would mine. There's the question of need (which, IMO is close to 0) plus the added complexity of explaining/managing FIFO read order; and don't forget multiple threads making simultaneous reads - just say NO. :) Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

New Singleton Release!
by Jason Hise 23 Apr '05

23 Apr '05

I'm pretty confident that this is the last major update before the review starts. All new library features and changes are explained in the documentation. The new library is available here: http://tinyurl.com/6qvrd -Jason

1 2

Re: [network] An RFC - updated
by Don G 23 Apr '05

23 Apr '05

Hi Michel & Peter, --- Peter Dimov wrote: > Michel Andr� wrote: >> This means we have one global dispatcher for the library >> (completion queue in asynch case). Isn't there a need to >> have several dispatchersto be able to group connections >> to several dispatchers/pollers. > > You can probably guess that I think that the answer is no. ;-) And I would agree. :) I can see no particular reason to expose the arbitrary grouping of network objects to the user. I can see the need for multiple dispatchers, but at most one per thread. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [network] An RFC - updated
by Don G 23 Apr '05

23 Apr '05

Hi Iain, > A connector sets socket options that can not be set after a call to > connect on a TCP connection! In the proposal I am making, the stream is created without being connected. So, it could offer pre-connection configuration. Of course, those methods would just be sitting there (temptingly<g>) after connect was performed. But, so I suppose would the connector if it were an object. If there are some significant options to be set, I could see them effectively becoming ctor arguments. Perhaps packaged in a stream_options bundle. Just some ideas. Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [boost] Re: (Another) socket streams library
by Iain Hanson 22 Apr '05

22 Apr '05

On Thu, 2005-04-21 at 19:30 -0700, Jeff Garland wrote: > I notice we don't have a buffer concept in any of our net/socket writeups on > the wiki. I think that's a big omission. I also wonder if the abstraction > doesn't already exist --> std::basic_streambuf. Let the socket class write > into the streambuf and then you can trivially wrap a stream around it to do > sophisticated i/o if you wish -- or simply pull out the raw chars.... > A buffer concept is absolutely essential for TCP. Without it you will run into delays with Nagle, delayed ack and slow start all combine-ing. Yuk! Streambuf makes sense for the iostream concept. For lower layers the buffer concept needs to be a model of contiguous container. Iterator type can only be guessed at because I don't know what goes on inside the 'C' socket lib or the kernel but first guess would be forward iterator. /ikh

4 4