- Boost - lists.boost.org

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

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

25 Apr '05

Hi Boris, > on what part of the network library are you working? It > seems like you are in level 1 without I/O streams - > whatever this part could be called. :) If I understand the levels right: 1 - Socket API wrappers (RAII, type-safety mostly; minimum overhead) 2 - Connector, Acceptor, Connection 3 - iostream integration Then, I guess I would place the ideas I proposed at level 1.5 :) > If I look at the extremes - wrapper classes for the > C API and an acceptor-connector pattern with service > handlers like in ACE - where is your library? You are > somewhere in between if I am right: I don't see any > socket class but see classes reminding me of network > functions. The crux of what I am proposing is a layer that encapsulates sockets behind an abstraction, which would place it between sockets and ACE-like designs or whatever else. Many, but not all, implementations of that abstraction would be based on sockets, select, epoll, kqueue, etc.. At my work, where this design was born, we have a direct serial implementation and an HTTP-tunnel implementation. We have also implemented the stream abstraction for NT named pipes and SSL (using OpenSSL). By virtue of the abstract nature of things, we can use SSL over named pipe for example. Or SSL over serial line (you get the idea<g>). > Do you think we need another layer? Personally, I think the layer I proposed is vital to higher level designs that can be reused (on different platforms or over different network implementations). Not only designs, but also protocol libraries. For example, (if it weren't for proxy servers<g>) the code needed by an HTTP client to support HTTPS would be something on this order of complexity: void http_get (net::network_ptr net, const net::url & url) { net::stream_ptr stream; stream = net->new_address(url)->new_stream(); stream->connect(); // handle SSL: if (url.get_scheme() == "https") stream = ssl::new_client_stream(stream); // now using SSL - or not! } Lower level ideas (like socket and fd_set) imply an implementation that may be completely inappropriate. A bidirectional stream is an idea; it is not a socket. So, yes, I do think we need this layer or one much like it. And it must be much lower level than <iostream>. The abstraction I proposed is a direct rendering of general network concepts (influenced by TCP/IP, which might mean it needs some further generality). It imposes only the overhead necessary to adapt sockets to C++ ways of thinking. > Shall we drop the acceptor-connector pattern? I have acceptor in my proposal, but connector didn't seem (to me) to be an entire class/object. I have an address object as the Abstract Factory for a stream object, which is similar to a connector concept except that the connection process begins with a method on the stream object. In other words, the stream is created in an unconnected state and it is that stream that we want to connect. This felt like a much better fit to the problem at hand (again, to me<g>). > Is your library which belongs to level 1 a neighbour > of an acceptor-connector based package with different > goals? My goal is to iron out a behavior contract that satisfies various possible and desired implementations, so that a library user can know what are safe and portable practices. One could say that the sockets API does this, but there are two central issues: one cannot create a new type of socket (to layer protocols); not all forms of I/O completion are portable. So, underneath my proposal are many implementation choices. Likewise, on top of it can be abstract ideas about services or request/response patterns and the like. The layer is conceptually complete (or should be made so by adding new abstractions). The only reasons I see for going around the layer I propose would be: use of platform-specific features or performance. I believe it is too early for performance conclusions of what I am proposing. That is a job best left for measurement, which is why I wanted to proceed with things at SourceForge. I can say that based on my previous implementation of this design, I know it can perform very well. Perhaps not as well as some direct-sockets approaches. Certainly not as well as feeding the network driver directly from the file system driver's disk cache, but life is full of trade-offs. :) I hope I have answered your questions. Best regards, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

5 19

more \r\r\n found in files
by Victor A. Wagner Jr. 25 Apr '05

25 Apr '05

I edited and committed the following files: boost/none.hpp boost/none_t.hpp boost/iostreams/character.hpp boost/iostreams/operations.hpp boost/iostreams/positioning.hpp boost/iostreams/reverse.hpp boost/iostreams/detail/system_failure.hpp boost/iostreams/detail/streambuf/linked_streambuf.hpp boost/iostreams/detail/vc6/operations.hpp boost/iostreams/filter/symmetric_filter_adapter.hpp libs/iostreams/src/mapped_file.cpp libs/optional/test/optional_test.cpp libs/optional/test/optional_test_common.cpp libs/optional/test/optional_test_ref.cpp because they all had lines ending in \r\r\n Two thoughts occur to me regarding this situation. We should publish widely the names of the person(s) who write editors that create such files and the person(s) at Microsoft who decided to make VC8.0 do: error C4335: Mac file format detected: please convert the source file to either DOS or UNIX format After we publish their names widely we should hold them up to public ridicule. I point out that there is no legitimate defense for the behavior of the VC8.0 compiler. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

1 0

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

25 Apr '05

Hi Peter, > I like the proposal. It shows a certain polish that only > comes with real-world experience with a design. ;-) Thanks! > I have the following comments for now, based on a > not-very-deep look at the document and the header: Thanks for all the feedback. > 1. network root class > > In my opinion, this class is not needed and should be > removed. It complicates the design, forces a global > variable on the user, and is not library-friendly. For > example, if lib1 and lib2 use the network, the user > can't pass an address created by lib1 to lib2. The > global state modeled by the network class should be an > implementation detail. In many of my uses, I have multiple network-derived types in use at the same time (serial, HTTP tunnel, TCP/IP). I agree that it can be an issue, so perhaps there should be a way to associate code with a particular kind of network and not need the network object. Having said that, though, I think this assumed context should only be a default to be used when the calling code has no network object in hand. All libraries should accept and pass along the context. Otherwise, one could not reuse protocols over different networks in the same app. While this can be seen as an issue, most of the time I find that I need to pass something along already: an address object or a stream, for example. That is sufficient to get back to the network object. It is also OK to create multiple network instances of the same type, though it should not be done with impunity<g>. > 2. address > > The address should be a standalone class and not tied > to a particular network. I think different networks (in my uses anyway) have different expectations (data size, textual form, etc.). This lead me to the conclusion that an address is an abstract idea. Its primary role is a factory for other objects related to the address it describes, which is again not something a concrete type would be able to handle (at least w/o indirection hidden inside). > It should be a simple entity and not a hierarchical > container. Logical to physical resolution should take > a source logical address and produce a container of > physical addresses. This container is often needed internally and, in my experience, seldom needed by the user. It is helpful for the logical address object to know the corresponding physical addresses and not have to repeat the resolution process. I see no fundamental problem exposing this collection as std::vector<address_ptr> (or whatever) and not providing an interface to encapsulate it, but I was trying to keep things purely abstract. > The address should not be created with an URL, that is, > a TCP connection to www.example.com should be represented > by the address tcp:/www.example.com:80, leaving > http://www.example.com reserved for the stream obtained > by the HTTP GET / query, not for the raw protocol stream. > A connection to the serial port should probably be > represented by "com1:/38400,n,8,1", and so on. This scheme morphing seems to fit with the idea that network instances are behind the scenes, but creates complexity for the user as well since these transformations must be done at that level. For serial use, it is not sufficient to say "com1" (that was a concept I had early on as well). That would address an entire network, not a specific "port"-like concept. I think the "U" in URL is really fitting for this model. There is a lot of thought behind URL's and they have the right level of generality. IMHO, we do not need another textual form for addresses. > I think that the UDP broadcast address should be > represented by udp:/0.0.0.0, and the TCP loopback > should be tcp:/127.0.0.1, as usual. But I may be > wrong. All of these are forcing TCP/IP (IPv4 even<g>) concepts to the user. The central idea of the abstraction I proposed is that "datagram" and "stream" are the behavior-bundles to which one should write protocols, not TCP/UDP or sockets. The notion of loopback and broadcast can carry over from one network type to another, but these textual forms do not. That said, this will work given an IPv4 network object in my proposal: strm = net->new_address("127.0.0.1:80")->new_stream(); It is just not portable to IPv6 or any other network type. Hence, one is better off saying: strm = net->new_loopback_address()->new_stream(); > 3. Minor stylistic issues > > p->get_X() should be p->X() Personally, I go back and forth on this<g>. I suppose that std::basic_string<>::length is the right form to follow. I currently like the get_X/set_X symmetry, but will change back in the proposal. > p->new_Y() should probably be p->create_Y() Is that a preferred verb for Abstract Factory? I should reread that chapter... :) I chose "new" because it advertised exactly what must happen: a new instance is made. Not that I am wedded to it, if there is ample precedent for "create". > although it might be better to move to > net::create_Y( p ) or even to Y( p ) and reference > semantics under the hood. The approach I took (based on shared_ptr <g>) allowed for clear ownership, copy and layering semantics. In other words: net::stream_ptr stream = ...; stream = ssl::new_client_stream(stream); At this point, the new SSL stream impl drives the original stream which it can rely upon to exist until it is done with it. From the user's point of view, the SSL stream is now _the_ stream. > The destructors should be protected. Agreed. > 4. MT-centric model > > The general idea of an asynchronous callback dispatcher > is sound, but the threading decision should be left to > the user. The library should provide > > void net::poll( timeout tm ); > > that delivers any pending callbacks from the context of > the thread that called poll, and > > void net::async_poll( error_callback ); > > that acts "as if" it executes net::poll( infinite ) > repeatedly in one or more background threads. > (error_callback will be called on errors; the > synchronous variant will probably throw an exception > instead.) The threading choices are certainly the most complex. Having said that, these are mostly implementation choices, not interface choices though one might need to extend the interface to support ideas like the one you propose. The complexity really shows up when one wants to write protocol libraries. For each choice presented to the network user, the protocol library probably needs to provide similar support. For example, an HTTP library would need to provide sync and async under my proposal. Adding more styles of notification to the network layer probably makes this job more difficult. Not to pass final judgment here; just a consideration. In my work on this, I attacked thread affinity outside the network layer for the most part. In particular, what you called net::poll() I had as a different object that handled a queue of boost::function<>-like objects. That way, the main thread was not forced to be only a network thread. I do see room for this approach in cases where the main thread wants to be a network-only thread and the queue approach feels too heavy. I think that this would fit in my proposal as a different concrete network-derived class as long as the abstraction is the same: sync and async (with other rules TBD). > Whether the library uses multiple threads under the > hood, or how many, is implementation defined, even if > async_poll is not called; this depends on which model > delivers the best performance on the specific platform. While I agree to some extent, the user must know the context in which callbacks will be made. Or at least, they need to know a set of rules to follow that will keep their code working for all implementations. Forcing a single-threaded view of the network on the user imposes its own penalty. At the top-most level, the programmer should have some (hopefully small<g>) number of concrete network objects to pick amongst. Once chosen, all mid-level libraries need to know that their expectations of behavior are still going to be met. At the bottom, we do what seems best to implement the abstraction on a given platform. > 5. read_later, etc > > I think that read_later should be dropped. async_read > is enough, in my opinion. Personally I have little use for non-blocking style, but there is a lot of desire for it. And it does have its merits for buffering data. > The functionality of write_later should be achievable > with a call to async_write with size 0; write_later > can be dropped, too. I debated this myself, but decided to apply the axiom "don't parameterize behavior" and ended up with the x_later approach. Under the covers, they will be very much like async_x with no buffers on which to operate. > async_read should not take a buffer; instead, the > callback should receive a pointer to a buffer managed > by the library that is guaranteed to be valid for the > duration of the callback. (Not by default, at least.) > > async_write (by default) should not assume that the > passed buffer stays valid after async_write returns. > > Rationale: buffer management is a pain with multiple > callbacks active ;-) Others I believe have commented on this, but my take is that this level should not make assumptions about the ultimate destination of data. This approach, would in many cases, force data to be copied "one more time". I agree that this can be a painful process, but perhaps this is where higher level abstractions come into play, or possibly (as you suggest) optional additional features for this abstraction. Maybe passing (NULL,0) for I/O requests, or some sort of set_buffer() mechanism. Don't know. > That's it for now. Please don't take these as criticisms > and wherever you see "should" read "in my humble opinion, > the design probably could be enhanced by". Please understand my responses in the same way. :) I (try<g>) to never take criticism of designs personally, and I do feel that all criticism, especially constructively phrased as yours, is only beneficial to everyone. > Thanks for reading. Nope - thank you for taking the time read my proposal and then respond with so many ideas! Best regards, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 16

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

25 Apr '05

Hi Peter, >>> 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. Serves me right for being glib. :) Here's what I meant: class stream_over_serial : public net::stream { public: stream_over_serial (string comport); }; This is a net::stream impl over the named COM device. On Windows, this might use lineOpen. Now that we have a stream, we wrap it in a network: class network_over_stream : public net::network { public: network_over_stream (net::stream_ptr strm); }; The caller of all this is whom so ever wanted a network running over the COM port. (glib again, I know<g> but this is just a sketch). FWIW: We use host names like "g" and "h" for "guest" and "host" where the "guest" is the initiator/active open and "host" is the acceptor/passive open. The new_local_address() would return "g" as a physical address on the side that did the above. > My point was that different network objects can > interpret the same address to mean different > things, at least in theory. URIs are supposed to > be context-independent. I see your point. Your suggestion of encoding the network as part of the URI would solve this. That could be a global map/table or a multi-net impl of net::network (one that was a net::network and wrapped a collection of network's; not that I want to go there<g>). But, these schemes would still compete with the set defined for the Internet (the http:// form should work since it is universal). The issue was that I wanted user visible addresses to be familiar (such as the now infamous "http://www.boost.org"). Given that desire, and the fact that our most heavily used network impl was TCP/IP, I had no problem with this level of abuse. ;) Also, the same protocol can run over multiple nets, so "foo://G" or "foo://10.0.0.7" just made some (twisted<g>) sense to me and I never worried about the ambiguity. Do you see this as an acceptable abuse, or as doing violence to the RFC? :) Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: Yet Another Network Library
by Don G 25 Apr '05

25 Apr '05

Hi Michel, > Even if we go for a interface/inheritance based > approach is would like to expose tcp_stream/ > tcp_connector/tcp_acceptor/udp_stream et al and > the like so the user could instantiate a concrete > implementation and not going through the address, > dynamic factory thingy. There might be specifics > in these classes that you care for if you only > support tcp eg. Do you have any specifics in mind? If they are general in nature, they really belong in the interface. Many things can be optionally meaningful even if they are not universal (eg: flush). Best, Don __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[1.33.0] Please update index.htm for new libraries, updated libraries, etc.
by Douglas Gregor 25 Apr '05

25 Apr '05

There are several new libraries in Boost for the 1.33.0 release, and many that have changed. Developers: please update index.htm in CVS to announce your changes. Also update libs/libraries.htm if you haven't done so already. Doug

3 2

RE: [boost] Use of Other Languages in Boost Tools
by Martin Bonner 25 Apr '05

25 Apr '05

----Original Message---- From: Allen [mailto:yaozhen@ustc.edu] Sent: 23 April 2005 07:28 To: boost(a)lists.boost.org Subject: [boost] Use of Other Languages in Boost Tools > The obvious two attitudes I can imagine are: > > (1) Prohibit *extensive* use of other programming languages in Boost > tools, for example writing a complex tool in Python completely. > (Convenient and small scripts are acceptable.) For we are establishing > the Best Practice *in* C++ and *for* C++. In addition, the tools can > be extensible and reusable with an API for C++ programmers as > *developers* not just as *end-users*. > > (2) Allow extensive use of any convenient and reasonable programming > languages in Boost tools. Maybe there should be a list for acceptable > languages other than C++, for example shell scripts, Perl, Python, > Ruby, etc. For they are just *tools*, not C++ *libraries*. They are > just black boxes to C++ programmers, and we do *not* provide the > tools as an extensible tool platform/framework with API for C++ > developers/programmers for further extension or reuse. > > I tend to support (1) I tend to support (2). On the other hand we should avoid using TOO many languages (because that is yet another thing to download and install to get the tool running). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0