- Boost - lists.boost.org

Re: [boost] [asio] Are the _at_least_n functions useful?
by BRIDGES Dick 21 Nov '05

21 Nov '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of > Christopher Kohlhoff > Sent: Thursday, November 10, 2005 7:18 PM > To: boost(a)lists.boost.org > Subject: [boost] [asio] Are the _at_least_n functions useful? > > > Hello all, > > As part of cleaning up asio's interface I am pondering the utility of > the read_at_least_n/write_at_least_n free functions. I'd appreciate > hearing from anyone who actually uses these functions (or their async > counterparts), and anyone else who has an opinion on the matter :) [snip] > Cheers, > Chris <use_case truncated="yes"> I have done some message passing over TCP where the message headers can be fairly elaborate and there is considerable variation in message size (e.g., DIAMETER RFC 3588). Every time some traffic arrives, one of two questions get asked: "Did we get enough of the header to determine the message length?" or "Given we know the length, do we have the entire message yet?". It would be nice to move this code (and all of the associated anomaly handling) out of the application and *down* into the library. read_at_least_n would certainly be handy. </use_case> As a generalization, I'd say that those two questions get asked almost anytime discrete messages are passed over a stream protocol. <aside humorous="hopefully" sentiment="serious"> I am already using asio on [at least] two projects so I have no stake in hurrying the review process. License is Boost. Great support is available on boost(a)lists.boost.org. Packaging won't change substantially until 1.34. "Accepted" should be a *very* good bet. Take your time. ;) </aside> Regards, Dick Bridges

3 2

Link boost DLL (BOOST_ALL_DYN_LINK) ? Beginner..
by Renato Tegon Forti 21 Nov '05

21 Nov '05

Hi all, I did try use: BOOST_ALL_DYN_LINK, but I did't have success. The boost returns this to me: c:\Boost\include\boost-1_33_1\boost\config\auto_link.hpp(281): fatal error C1189: #error : "Mixing a dll boost library with a static runtime is a really bad idea..." How I fix this? My code: // BoostDefines.hpp : Defines the entry point for the console application. // //-------------------------------------------------------------------------- -- // //-------------------------------------------------------------------------- -- // Filename: BoostDefines.hpp // Type: Declaration // Language: Microsoft Visual C++ V7.1 // Module: //-------------------------------------------------------------------------- -- // Description: class BoostDefines //-------------------------------------------------------------------------- -- #ifndef BOOSTDEFINES_HPP #define BOOSTDEFINES_HPP #pragma once #define BOOST_ALL_DYN_LINK #define BOOST_THREAD_USE_DLL //thread header not compliant with 'BOOST_ALL_DYN_LINK' #define BOOST_LIB_DIAGNOSTIC #ifdef BOOST_ALL_DYN_LINK #pragma message("Include: dynamic linking with boost libraries") #endif #endif //BOOSTDEFINES_HPP // test.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include "BoostDefines.hpp" #include <boost/lexical_cast.hpp> #include <boost/regex.hpp> int _tmain(int argc, _TCHAR* argv[]) { //... //use boost //... return 0; }

2 1

c++/cli boost subproject?
by relative＠gmx.net 21 Nov '05

21 Nov '05

is there, or are there plans for, a boost c++/cli subproject? i've played around with boost and the cli compiler, a lot of libraries work with unmanaged data types (with a lot of warnings, but work), others don't. none work with managed data types of course although that wouldn't be a big problem I suppose. (e.g. boost::tuple) the spec is there, at least one compiler exists(mono?) and there is a STL called STL.NET by dinkumware(distributed by microsoft) for c++/cli. I haven't found anything on the website or the mailing list archives, is this beyond the scope of the boost project? -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen f�r GMX Partner: http://www.gmx.net/de/go/partner

7 10

boost::thread - mistake in documentation
by Oliver.Kowalke＠infineon.com 21 Nov '05

21 Nov '05

Hello, the documentation (http://www.boost.org/doc/html/condition.html) of class condition contains a mistake: instead of template<typename ScopedLock, typename Pred> bool timed_wait <http://www.boost.org/doc/html/condition.html> (ScopedLock&, Pred); it should be template<typename ScopedLock, typename Pred> bool timed_wait <http://www.boost.org/doc/html/condition.html> (ScopedLock&, const boost::xtime <http://www.boost.org/doc/html/xtime.html> & , Pred); so long, Oliver

1 0

contribution - sync. queue between producer/consumer threads
by Oliver.Kowalke＠infineon.com 21 Nov '05

21 Nov '05

Hello, I would contribute this code. The queue synchronizes the access between producer threads (putting items into the queue) and consumer threads (removing items from queue). I would be glad if you add this code to boost::thread library. With regards, Oliver <<queue.hpp>> <<test.cpp>>

1 0

Re: [boost] [multi_index] ordered_index should be noncopyable?
by JOAQUIN LOPEZ MU?Z 21 Nov '05

21 Nov '05

----- Mensaje original ----- De: Dylan Trotter <trotterdylan(a)yahoo.ca> Fecha: Domingo, Noviembre 20, 2005 8:17 pm Asunto: [boost] [multi_index] ordered_index should be noncopyable? > I just had a really irritating time tracking down bad memory access > in > ordered_index because I foolishly wrote something like this: > > typedef client_set::nth_index<0>::type address_index_type; > address_index_type addressIndex = clients_.get<0>(); > address_index_type::iterator iter = addressIndex.find(addr); > > The problem here is that I got my addressIndex by value in the > second > line. I may be overlooking something here, but I think it might be > useful to make ordered_index noncopyable so that this would be > detected > at compile time instead of runtime. I nearly threw my monitor out > the > window over this one. > Hi Dylan, I'm sorry you had a hard time with that. The truth is, indices are not copyable; moreover, I comment on this very mistake you have stumbled upon at the end of the following section: http://boost.org/libs/multi_index/doc/tutorial.html#multipe_sort So, how come you can compile even when the docs state you shouldn't? The problem is that some compilers have problems with template friends (signaled by Boost.Config macro BOOST_NO_MEMBER_TEMPLATE_FRIENDS) that force me to make (on these compilers only) some internal index ctors public, hence your problem. What compiler are you using? MSVC 6.5/7.x/8.0 all have this problem. Most others don't, and on those a nice compiler error would have popped up when compiling your snippet. Again, I'm sorry for the time you might have wasted. At least, you have refrained from throwing the monitor out of the window :) Thanx for using Boost.MultiIndex. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] [serialization] fast array serialization (10x speedup)
by bwood 21 Nov '05

21 Nov '05

Matthias Troyer wrote: >> >> i) somehow I doubt that this archive type has been tested with all >> the serialization test suite. Instructions for doing so are in the >> documenation and the serialization/test directory includes batch files >> for doing this with one's own archives. Was this done? What where >> the >> results? With which compiler? It costs nothing to do this. > > >Just ask if you had a doubt. The short answer is "I have done this". >After adding the fast array serialization to the binary and >polymorphic archives, I ran all your regression tests, without any >problem (using gcc 4 under MacOS X). Have you done this with vector also? I would be surprised if you have. It seems to me there is a standards issue to be addressed in this area. It is no problem to send the data in a vector of int as a unit, but I don't know of a way to add/receive the data into a vector correctly. It is possible to stuff the data into the correct place, but the vector's internal state/size does not get set properly since you didn't call push_back or some other method to get the data into place. Adding something like push_n_back to vector might help when it comes this. Brian www.webEbenezer.net

2 1

[multi_index] ordered_index should be noncopyable?
by Dylan Trotter 20 Nov '05

20 Nov '05

I just had a really irritating time tracking down bad memory access in ordered_index because I foolishly wrote something like this: typedef client_set::nth_index<0>::type address_index_type; address_index_type addressIndex = clients_.get<0>(); address_index_type::iterator iter = addressIndex.find(addr); The problem here is that I got my addressIndex by value in the second line. I may be overlooking something here, but I think it might be useful to make ordered_index noncopyable so that this would be detected at compile time instead of runtime. I nearly threw my monitor out the window over this one. Thanks, Dylan Trotter

1 0

serialization - NaN, +/Inf and others
by Robert Ramey 20 Nov '05

20 Nov '05

Troy S. and I have been looking at the question of implementing serialization of NaN, +/-Inf for floats, and doubles for portable text or binary archives. Turns out there's a fly in the ointment. For determining if a given double contains a "special" value, float.h contains the following handy function int _fpclass( double x ); which returns one of the following values: _FPCLASS_SNAN Signaling NaN _FPCLASS_QNAN Quiet NaN _FPCLASS_NINF Negative infinity ( -INF) _FPCLASS_NN Negative normalized non-zero _FPCLASS_ND Negative denormalized _FPCLASS_NZ Negative zero ( - 0) _FPCLASS_PZ Positive 0 (+0) _FPCLASS_PD Positive denormalized _FPCLASS_PN Positive normalized non-zero _FPCLASS_PINF Positive infinity (+INF) So we could write a flag to the archive indicating if its a special value. So far, so good. When the archive is read back, we can read the flag and initialize the variable with the appropriate value. BUT - I can't find any "official" to initialize a float/double to any of these values. They seem to be the result of operations and its certainly not obvious that all compilers would be on the same page here. Note that this same problem arises whenever a float/double is written/read to/from a stream in a way designed to be portable. So it must have come up before. What's the solution here? Robert Ramey

6 6

which libs to use for g++ 2.95
by PerzonalJezus 19 Nov '05

19 Nov '05

Hi. I´ve written an app using g++ 3 which uses the BGL. Now I need to compile my stuff (and make changes to the code if necessary) for g++ 2.95. Which version of the BGL lib (and any other boost lib for that matter) work with g++ 2.95? Thanks for any answer. Ed. PS: I´ve searched but haven´t found any helpful posts... -- perzonaljezus

1 0