- Boost - lists.boost.org

Re: [boost] Re: Formal review of "Output Formatters" library beginstoday
by Reece Dunn 14 Sep '04

14 Sep '04

John Torjo wrote: >>PS: >> I noticed that in earlier versions strings within STL containers >> where surrounded by "quotes"; now, they are no longer, which causes >> problems if a string contains ",". Why was that changed? >> >at my suggestion ;) > >I think you'd use this library a lot for pretty printing. Thus, the above >would only hurt. You can still specify it manually (if you wish to read the >strings back) The problem with the system I developed was that it overrided the "natural" behaviour of the basic format object (read/write the object to/from the stream using >> and << respectively). As John points out, this can result in output that looks like: [ "Tina", "Dana", "Eric", "Shaun" ] when you would want: [ Tina, Dana, Eric, Shaun ] I am aware of the problems reading the data back in if the string contains spaces. Placing quotes around it requires that you escape the quotes (to allow quotes in the string, e.g. \") and to escape the character that signals an escaped character (e.g. \\). This can lead to "ugly" output, e.g.: "This is a message \\ to say \"Hallo Welt!\" to my German friends." when you'd want: This is a message \ to say "Hallo Welt!" to my German friends. Now, consider the case when you want to generate XML or HTML-based output. In that case, you would want something like: <message>This is a message \ to say "Hallo Welt!" to my German friends.</message> and do not need to explicitly escape the string. In this case you can do: namespace io = boost::io; std::cout << io::formatob( str, io::containerfmt()).format( "<message>", "</message>", "" ); I am looking to add support for format objects that transform elements, i.e.: OutStream & write( OutStream & os, const Elem & e ) { return( os << fn( e )); // fn = transformation function } bool read( InStream & in, Elem & e ) { return( inv_fn( in, e )); // inv_fn = inverse transformation function } That way you can define character escapers for strings, XML, HTML and other escaped formats. To format the string as: "This is a message \\ to say \"Hallo Welt!\" to my German friends." you can do: std::cout << io::formatob( str, io::containerfmt( io::string_escaper()) ).format( "\"", "\"", "" ); This makes the process more well formed, consistent within the framework and explicit. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

RE: [boost] any interest in Boost Unification andBacktracking library(UBL)?
by Klaus Nowikow 14 Sep '04

14 Sep '04

Kresimir Fresl wrote: > Klaus Nowikow wrote: > > [...] > > My company uses a Prolog engine from a C++ program > > to solve a problem that is very hard to solve in C++ (I > can't explain > > this in detail here). > > Anyways, the inclusion of this Prolog engine caused various problems > > - the biggest being hard-to-reproduce program crashes when > we did not use > > the library _very_ carefully. > > > > So, if there was a C++ library that we could use for these tasks, we > > would surely consider it. > > Did you try LC++ library? > > http://www.cc.gatech.edu/~yannis/lc++/ > Not yet. Thanks for the link :-) -- Klaus

1 0

RE: [boost] any interest in Boost Unification and Backtracking library(UBL)?
by Klaus Nowikow 14 Sep '04

14 Sep '04

G. Wang wrote: > I am wondering how many people here are interested in a Boost > Unification > and Backtracking Library (UBL). UBL will implement the unification and > backtracking feature with the help of both preprocessor > meta-programming > (Boost Preprocessor library) and template meta-programming > (MPL). With UBL, > you will define Prolog-like predicates right inside your C++ code. I am very interested. My company uses a Prolog engine from a C++ program to solve a problem that is very hard to solve in C++ (I can't explain this in detail here). Anyways, the inclusion of this Prolog engine caused various problems - the biggest being hard-to-reproduce program crashes when we did not use the library _very_ carefully. So, if there was a C++ library that we could use for these tasks, we would surely consider it. Best regards, Klaus

2 1

Re: [boost] [1.32 Release] Branch-for-release date
by Robert Ramey 14 Sep '04

14 Sep '04

>With the new MPL in the main trunk and the updated MPL documentation coming >later this week, we've finally come to the point when it's feasible to talk >about the branch-for-release date. >Given that there is still some work on regressions to be done, I'd like to >aim for the end of the week, let's say Friday, September 17th. Does that >sound OK to everybody? Sounds too optimistic to me. >I'm assuming that at this point all library authors/maintainers are >finished with the tasks they wanted to perform before the release, minor >regression fixes aside. If not, please scream loudly! That's a reasonable assumption. But ... >One thing that we really have to take care of before branching is long >filenames. Could maintainers of the following libraries please fix the >corresponding problems listed in detail in http://www.boost.org/regression->logs/inspection_report.html? > archive (serialization) > build > date_time > graph > iterator > preprocessor > property_map > python > serialization > spirit > test > utility/enable_if The problem here is that some boost libraries depend on other boost libraries. E.g. serialization depends on spirit, lots of stuff depend on iterator, everything depends on test. So changing names will have lots of secondary effects. I'm still struggling with the fact that spirit 1.61 depends upon apply_if.hpp which no longer exists. In effect this makes the serialization library unavailable to vc 6.0, borland and others. That's just one case. BTW. These changes will break user code that depends on previous boost versions. So that's another question. Another issue is that the toolsets have some pending anomalies. Aside from the fact that the toolset documentation is now out of sync with the actual toolsets available and in use, I'm having problems with all those which use stlport which used to work. I'm still tracking this down. This is just the stuff I know about. I would say 17 Sep is hopelessly optimistic. Robert Ramey

3 2

Re: [boost] Re: Formal review of "OutputFormatters"library beginstoday
by Reece Dunn 14 Sep '04

14 Sep '04

John Torjo wrote: >>>I think one type of delimeter is enough (I assume you wholeheartidly >>>disagree with this). >> >>I don't wholeheartedly disagree... I am open to persuasion ;) >> >>>This type should be the std::basic_string<underlying_char_type>(). >> >>This would still mean that you have one per underlying_char_type, so the >>same problem exists although it is now in a smaller problem domain. My > >Nope, in this case, the problem does not exist. >It's because you have this correspondence: >1 stream - 1 underslying character type - 1 object that can keep delimeters >As oposed to: >1 stream - N delimeter_types - N objects keeping these delimeters. <light-bulb = on>! ;) >>main reason against using std::basic_string as the storage type is >>performance (excessive copying of the delimeter values). Also, what about >>managed strings in C++/CLI? Don't they require a String^ type, or am I >>missing something? > >whoa. I have no idea. But I do think that std::string should work ;) Or am >I dreaming ;) ? C++/CLI implements it's String objects as wchar_t * strings. In VC7.x you do String * str = S"Hello"; to create a string. VC8 allows the following: String ^ str = "Hello"; String ^ str2 = L"World"; You would need to convert to an ASCII string if outputting on std::cout. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

RE: [boost] Secret handles and descriptors: Enemies of reuse, conspirators with frameworks.
by Hurd, Matthew 14 Sep '04

14 Sep '04

> Behalf Of Scott Woods > > >From: "Aaron W. LaFramboise" <aaronrabiddog51(a)aaronwl.com> > > <snip> > > > Discounting polling, as its generally unacceptable, you always will need > > access to that underlying system resource handle, unless . . . <snip> Please don't discount polling. Trading CPU for latency benefits latency critical applications. A quick $0.02, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Secret handles and descriptors: Enemies of reuse,
by Simon Meiklejohn 14 Sep '04

14 Sep '04

>From my perspective developing interactive telephony applications this problem is an example of a more general one. Heres the outline of a solution that I've been using In general a program may need to integrate a variety of libraries which are sources of information/events. Often it's the nature of these libraries that they either own a thread which calls back into application code, or require the user to call a potentially blocking function that returns the data/event. Then again there are the libraries which explicity make available o/s objects that can be waited on. Its frequently the case that no single 'raw' demultiplexor system can interface to all of these at once. (I guess that's the reason for this thread). To me the underlying issue is one of threading. Heres a list of typical issues that arise in my apps. - my networking library wants to call me back in its own thread - ditto for my multi-media timer - my telephony library wants to signal me by setting an event - so I'd better dedicate a thread to it. That thread will also call me back. - my application objects are having events fired at them from all sides from multiple threads and therefore need to use Mutex's, but events from below (telephony) keep on deadlocking with events from above (network). - my COM interface wants to issue connection point callbacks to me in a the app main thread via the app message pump. - I cant call out on my COM interface on my Network library's callback thread because its not marshaled for that kind of stuff. - So I put the network messages in a queue - now I have to send a windows message to the main thread, where its ok to call COM. This isn't necessary on my unix version, so I have ugly platform specific code in the middle of my app. - My smart network library parses my messages into complex data types before I get to see them. So getting them out of the queue in the main thread involves some kind of dispatch on type. This is expensive and hard to maintain. STEPPING BACK A BIT While it may seem that many of my problems stem from COM, I think it stems from an unfortunate need to implement the application's threading policy at all levels of the code - library and application code. Also, the hoops I have to jump through to get COM working wont be at all applicable if I shift to unix or move to a non-COM interface. What I really need is the ability to define a threading policy at some high level point in my code (e.g. main), have library code that defers to that policy. I've called this a Thread Redirector policy Looking at the Network lib to COM path as an example: - the network lib receives bytes from the network in its own thread. When it has a complete message (but before it starts decoding the message) it calls the Thread Redirector asking for a callback in the appropriate thread. - in main() we've set things up so that when Networking asks for a callback it will be called back in the main thread via a windows message. (On Unix I substitute a pthreads based callback.) - On windows the callback occurs in the main thread. The Network library starts decoding the message. It determines it's a message type XXX and calls back into the App code MyAppObj.DeliverMessageXXX( MsgXXXType& XXX ). - the app can now call into its COM API like - myCOMIF->DoSomething( XXX.param) - without first queueing the message. I can define it so that all my libs deliver their events to the application objects on the same thread. This relieves the thread deadlock issues. I can go into more detail if required - but that's the flavour of it. Simon Meiklejohn

2 1

IOStreams formal review start
by Jeff Garland 14 Sep '04

14 Sep '04

All - Today (August 28th, 2004) is the start of the formal review of the Iostreams library by Jonathan Turkanis. I will be serving as review manager. Note that this is a somewhat unusual situation in that we have several libraries that overlap in the same area, so comments related to the MoreIo overlap are needed. As usual, please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments ********************************************** Library Synopsis ********************************************** The Iostreams Library serves two main purposes: * To allow the easy creation of standard C++ stream and stream buffer classes for new data sources and sinks. * To provide a convenient interface for defining i/o filters and attaching them to standard streams and stream buffers. The library focuses on freeing users from writing boiler plate code and allowing them instead to create highly reusable components. In addition to providing an abstract framework the library provides a number of concrete filters, sources and sinks which serve as example applications of the library but are also useful in their own right. These include components for accessing memory-mapped files, for file access via operating system file descriptors, for code conversion, for text filtering with regular expressions, for line-ending conversion and for compression and decompression in the zlib, gzip and bzip2 formats. The latest package can be found at the following locations: http://home.comcast.net/~jturkanis/iostreams/ Thanks, Jeff

14 88

meta-comm page not found
by troy d.straszheim 13 Sep '04

13 Sep '04

I was hunting around for something to do. If I click on any of the failed tests for gcc-3.4.1 on this page: http://tinyurl.com/3uxpm, you get a "page not found" error, on, for instance, the following page: http://www.meta-comm.com/engineering/boost-regression/developer/output/ bin-boost-libs-test-test-token_iterator_test-test-gcc-3-4-1-linux- debug.html ? -t

2 1

[ANN] asio - yet another networking library!
by Christopher Kohlhoff 13 Sep '04

13 Sep '04

Hi all, In light of some of the recent discussion about sockets (e.g. the "behond IOStreams" thread), I'd like to take this opportunity to announce "asio". asio will be going live in a commercial system in a little over a month, and I think it's now at a point where it is suitable for use by a wider audience. I would like to think that asio has potential as the basis of a boostified networking library, or that at least it can inject some ideas into the discussion. asio is a cross-platform library for doing network programming, using a "modern" c++ style. It is designed to use an asynchronous I/O model for virtually all operations, even when the OS lacks native asynchronous I/O. The library is intended to ease the development of scalable network applications through the use of a proactive event-driven architecture. You can download asio from: http://tenermerx.com/programming/cpp/asio/asio-0.1.12.tar.gz I have also put the generated documentation online at: http://tenermerx.com/programming/cpp/asio/asio-0.1.12/doc/html/ asio supports Win32 and Linux, and has been infrequently tested on Solaris. It is free for any use. Here is a sample usage of asio showing how to receive data on a socket: char buf[BUFSIZ]; void handle_receive(asio::error& e, size_t bytes_recvd) { if (!e) { /*...*/ } } int start_receiving(asio::socket& s) { s.async_recv(buf, BUFSIZ, boost::bind( handle_receive, asio::arg::error, asio::arg::bytes_recvd)); } I have been working on asio for well over a year and, as I said, it will be going into production in a commercial system in a little over a month. For commercial reasons I can't give too much detail, but I can say that asio has been used to develop a custom HTTP proxy that supports hundreds of concurrent connections. The inspiration for asio was the work of Alex Libman in developing a "portable Proactor framework" for ACE (see http://www.terabit.com.au) This is a Proactor that can use select or a similar synchronous event demultiplexer if no more appropriate OS mechanism is available. Regards, Chris

5 10