- Boost - lists.boost.org

how to use boost in VC6
by sanduoren 25 Apr '05

25 Apr '05

I'm a learner of boost.But the boost make me head ache.for example, I can't use /boost/algorithm/string.The VC6 compiler gives hints: yes_no_type.hpp(22) : error C2265: '<Unknown>' : reference to a zero-sized array is illegal yes_no_type.hpp(23) : see reference to class template instantiation 'boost::algorithm::size_descriptor<I>' being compiled who can tell me how to use boost in VC6

9 10

Re: Logging Library -- Formal Review
by Tom Brinkman 25 Apr '05

25 Apr '05

Thanks for your submission John. I've added your library to the review queue. Contact my private email to make further arrangements about a review manager and review start date. If you feel that it is ready, we should be able to get it reviewed within the next month or two. Tom Brinkman reportbase(a)gmail.com Boost Review Wizard

2 1

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 25 Apr '05

25 Apr '05

On Sun, 2005-04-24 at 14:13 -0700, Don G wrote: > Hi Peter, > > Can you give an example of a developer that absolutely > > insists on a single-threaded implementation (not > > interface)? > > I think Iain Hanson is that camp. Could be wrong. > Yes. To support platform that do not have preemptive multi-tasking. /ikh

1 0

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 25 Apr '05

25 Apr '05

On Mon, 2005-04-25 at 00:50 +0300, Peter Dimov wrote: > Don G wrote: > >> This doesn't make any of these streams networks, > >> and neither is a communication port a network. > > > > I won't debate semantics here (too much<g>): Once the line is up, > > communications between A and B occur in exactly the same way as they > > would with TCP/IP. Both ends "listen" for incoming stream connections > > on multiple ports (each for a different "service"), each can accept > > one or more datagrams on different ports, again for different > > services. In a nutshell, they are abstractly identical. The big > > difference is that the entire network consists of two hosts. > > Yes, I see. I was thinking of a different scenario, however, one in which > you communicate with a device over a serial line (not with another host) > using a specified protocol. Since serial lines are relatively slow, > asynchronous communication is a good thing. > > >> This of course leads to the obvious question: > >> which network gives me a stream over COM1? > > > > network_ptr com1 = > > new net_over_stream( > > new stream_over_serial("com1")); > > Wait a minute. Which network creates the stream_over_serial? Assume that I > don't need the outer network since I'll be communicating with a printer, for > example. > > >> LPT1? > > > > network_ptr lpt1 = > > new net_over_stream( > > new stream_over_lpt("lpt1")); This is wrong IMHO. These are devices. If you want to implement a network over them then it should be done with device drivers. E.g you could implement PPP over COMn and then access it via socket or net:: lib via TCP or UDP. /ikh

1 0

boost::function and boost::serialize
by mysticdevil＠gmail.com 25 Apr '05

25 Apr '05

I would like to be able to serialize boost::function objects with the boost::serialize library, and i really don't know anything about the internal structure of boost::function nor how it works, and when trying to read the headers i really get lost there. So could anyone give me a hint or something on how to make a wrapper for boost::function (i know that function address might change from executable to executable, and also for run to run, that's why i thought "adding" a translator, that i assing a name to each function i have a pointer to, and when it serializes it it saves the name, and when loading, it search the address of the function with that name)... if you know how this could be done, or have any hint i will greatly appreaciate it... Also i would like to know how boost::serialize handles the shared pointers, because i my own designed objects with reference counting, and i don't know how to serialize them (to preserve shared behavior), and also i have the doubt, what happens, if i have an object shared 8 times in memory, and i only serialize it 4 times, so when i load it again, the counter will say 8 or 4?. Thanks you very much...

1 0

Re: [boost] Re: [network] An RFC - updated
by Iain Hanson 25 Apr '05

25 Apr '05

On Sun, 2005-04-24 at 17:45 -0700, Don G wrote: > Hi Mats, > > It's good to have someone with experience in non-TCP environments! > Glad you're here. > > > The X.25 API doesn't provide the equivalent to the tcp > > listen(2) backlog parameter. To drive an X.25 acceptor > > to be capable of accepting incoming calls at a high > > rate, one has to implement the backlog oneself. This is because you are doing this in the wrong place IMHO. ( see below ). > > Perhaps this is something that should be part of the impl of the > acceptor for X.25. That would make X.25 and TCP the same in this > sense (there are no doubt other differences of which this is just > one). No. You are comparing apples and oranges. TCP is a transport layer protocol and X.25 is predominantly a Network layer protocol. A connection Oriented equivalent to IP. The correct place to do this is with a device driver 99.9% of the time. /ikh

1 0

[threads] read_write_mutex performance
by Peter Dimov 25 Apr '05

25 Apr '05

What are the design goals of read_write_mutex? (Lock proliferation aside for a moment.) My understanding has always been that read/write locks are an optimization, that is, a read/write lock-based algorithm should deliver better performance than the same algorithm with "ordinary" locks. Right? Wrong. The program at the end of this message demonstrates that in this specific (contrived?) case ordinary mutexes outperform a read/write mutex by a factor of 2.5 or more in almost every scenario, even when no writers are active! In some scenarios (16 readers, 4 writers, 10,000,000 iterations) the ordinary mutex case completes in under 8 seconds on my machine, but the read/write case exceeded my patience threshold. Am I missing something? -- Peter Dimov http://www.pdimov.com #include <boost/thread.hpp> #include <boost/thread/read_write_mutex.hpp> #include <iostream> #include <vector> #include <time.h> //#define RWLOCK int const n = 1000000; int const n_readers = 16; int const n_writers = 0; std::vector<int> v; #ifdef RWLOCK boost::read_write_mutex mtx( boost::read_write_scheduling_policy::alternating_many_reads ); #else boost::mutex mtx; #endif void reader_thread() { int m = 0; for( int i = 0; i < n; ++i ) { #ifdef RWLOCK boost::read_write_mutex::scoped_read_lock lock( mtx ); #else boost::mutex::scoped_lock lock( mtx ); #endif m += v[ i ]; } std::cout << m << std::endl; } void writer_thread() { for( int i = 0; i < n; ++i ) { #ifdef RWLOCK boost::read_write_mutex::scoped_write_lock lock( mtx ); #else boost::mutex::scoped_lock lock( mtx ); #endif v[ i ] += i; } } int main() { v.resize( n ); boost::thread_group group; clock_t t = clock(); for( int i = 0; i < n_writers; ++i ) { group.add_thread( new boost::thread( writer_thread ) ); } for( int i = 0; i < n_readers; ++i ) { group.add_thread( new boost::thread( reader_thread ) ); } group.join_all(); t = clock() - t; std::cout << static_cast<double>( t ) / CLOCKS_PER_SEC << '\n'; }

5 5

Build Dimov's simple Boost.Threads test without bjam...
by Sam Ferland 25 Apr '05

25 Apr '05

Hi, I have used various boost-libraries before but now, when I am trying to build the simple Boost.Threads test application posted by Peter Dimov on this list the other day (http://tinyurl.com/aotq7) I am stuck :-( I copied and pasted Peter's code into an empty Win32-Console-project in my development environment - which happens to be VC++7.1... When trying to get the build through, I get the error: "Mixing a dll boost library with a static runtime is a really bad idea...". This message is probably more than enough for most experienced Boost and Windows developers to say - Oh yes, my stupid #¤*@£¤ I must of course do that and that too, to get the build through. However, poor me is left clueless. I have once built all of boost using bjam so I have two different boost_thread- vc71-mt-*.dlls and the corresponding lib-files within the boost/lib-folder. But I do not know how to set-up my project to first get the compile and then the link through. And I cannot find any helpful information in the Boost.Threads documentation?! Even Google didn't provide any help... So I'd be very glad for any help from you guys! Regards, Sam

4 3

Yet Another Network Library
by Giovanni P. Deretta 25 Apr '05

25 Apr '05

Hello fellow boosters, after months of lurking on this list and seeing how everybody seems to have its own network library, i've finally decided to put online mine. I will upload it under the vault as nanostream.tar.gz, it is unix/linux only currently. You may want to skip the library code and read the pdf under the doc directory where the library is shortly presented and some examples are given. These are the main features/peculiarities of my library: - There is no socket concept because i don't really think it is natural, at least not for a C++ programmer. I use the acceptor, connector and stream concepts. - User is not required to reference streams by pointer, streams are stack allocated or are simply members of another object. Internally they have a smart pointer to an implementaion handle. Consider them stack-based proxies. The acceptor and the connector return the handle that is asigned to the stream. - The preferred way to do input output is to use standard-like algorithms (i.e. copy) with buffered stream adaptors and specialized input/output iterators. I believe that an efficient library can be written this way and be very C++-user-friendly. Classic read/write are still available, but their semantics might be surprising. - All classes are concrete, no polymorphism is used (i.e. no virtuals). Polimorphic behaviour must currently be achieved with some external mean (i.e using the external polymorphism pattern. I think that the boost::IDL library would be great). - Errors can be reported both with exceptions and with error codes. Exceptions are used by default unless error callbacks are passed. This seems to work quite well. Internally only error codes are used and exceptions are thrown only at the most external abstracion layer. Note that the library does not actually use error codes, but error types using a specialized variant object. This is just an experiment and i might remove it. I will probably add status bits a-la iostreams. - File streams. The library actually try to be a generalized i/o framework, and file streams are provided for completeness. - The library can be extended simply by creating new handles. In addition to TCP streams there are Unix streams (come almost for free :-) and file streams. SSL/TLS was present but did get broken some time ago and didn't have the time to fix it. - Input/Output buffer. This is very similar to a std::deque<char>. It has segmented iterators support (the same interface presented in the Austern paper), and it is the preferred input/output buffer, it can be easilly grown on both directions (usefull if you need to add an header) and can be efficiently read/written with scatter-gather operations. While i have yet to implement it, i think that moving data from a buffer to another can be done extremely efficently by splicing the internal pages. The buffer is also used to implement the buffered adapter. boost::arrays, vectors and plain arrays also work fine, while other containers require a bounce buffer and thus slower operations. - Addresses are logically defined by a triplet <domain, host, service>, where the domain is implicit in the acceptor, address, or connector type, host and service are two strings. This is inspired by the getnameinfo(3) interface. - A multithreaded stream adaptor and an http module are also included. These are just proof of concept and not really part of the library (yet). Missing (definitelly not complete list): The library is fully sinchronous for now. I'm still considering how to add asynch support. I think i will implement it in the buffered adaptor I/O is done asynchronously to the internal buffers that can grow as much as it is necessary. Timeouts are definitelly a must-have. Final notes: I've have seen that the current consens is to encode the the stream type in the address, so to allow a dynamic behaviour: the actual transport is selected only at runtime, based on the address string. I think this is a bad decision (i considered doing it while implementing my library) and this is why: - C++ is a static language, let's leave these niceties to more dynamic languages. I have found myself weeks hunting a bug in the http code because i thought that it would be cool if i could access http properties using a map instead of proper accessor functions. I spent weeks hunting persistent connection bug. It was a simple typo inside a http property string that would have been caught immediately by the compiler if i were using functions or costants [1]. - It mimics standard library usage. You cannot open the input stream instead of a file by using the "input:" file name. (well under Unix you might actually do it, but i don't think this was the intention of the standard library authors and it is not portable any way). - It is extremely insecure. In a network library security must be paramount. If the transport type were encoded in the address, it would be much harder to validate externally received addresses. A similar argument can be made for the port numbers. It is better to keep these things separated. The library user can create its own indexed factory collection if it really needs to. Sorry for the long post, just tryin' to be usefull :-). -- Giovanni P. Deretta 1 - I did write "Content-Length" instead of "Content-Lenght".

9 15

[1.33] weak_ptr_timing_test.cpp, OK to commit?
by Peter Dimov 25 Apr '05

25 Apr '05

I've created a new timing test, libs/smart_ptr/test/weak_ptr_timing_test.cpp. It tests the performance of weak_ptr in a single-threaded scenario. This test is not referenced by a Jamfile and is not intended to be run by default. OK to commit? -- Peter Dimov http://www.pdimov.com

1 0