- Boost - lists.boost.org

Secret handles and descriptors: Enemies of reuse, conspirators with frameworks.
by Aaron W. LaFramboise 13 Sep '04

13 Sep '04

Boost now contains several classes that provide abstraction for operating system resources that are logically _waitable_. A waitable resource is any resource for which an operation on it might not complete immediately. Examples include threads and processes, files and the file system, and sockets and pipes. A notification of some activity on a waitable resource is often called an _event_. In modern software, it is often necessary to wait for events asynchronously. Quite often threading is a good solution for this, but quite often it isn't. In these latter cases, it is necessary to have some sort of _demultiplexor_ entity that handles the system-specific mechanics of waiting for events. In both UNIX and Windows, to wait for events relating to a resource, one must have a handle or a descriptor associated with that resource. In general, this must be provided by the class that maintains the abstraction itself. If a class managing a waitable resource, through encapsulation, allows no way for a demultiplexor to access the handle needed for waiting, waiting is impossible. Despite having all the functionality that a programmer may require, this class is useless to the programmer because it can not be demultiplexed. This is unacceptable. To solve this design deficiency, a particular Boost demultiplexor class might be created. Boost classes that are associated with waitable resources might provide the needed handles to the demultiplexor—perhaps using _friend_—and so make asynchronous waiting possible. Unfortunately, there is a problem with this approach. Resources managed by classes outside of Boost would, in general, be incompatible with the demultiplexor. In addition, demultiplexors other than the one provided by Boost—that might be able to handle these classes incompatible with the Boost demultiplexor—would likely be unusable. The nature of typical demultiplexor implementations is that they monopolize control flow (for reasons that are usually unavoidable), and may only cooperate within the same program by using separate processes or threads, which may be inappropriate if there is no other logical reason for such separation. The affect is that waitable resources provided by libraries other than Boost are useless to the Boost programmer, as they are fundamentally incompatible. This is the mark of a conniving, conspiratorial framework, which lures its victims in with attractive features, and then locks them in its dungeon by preventing them from using other libraries. This is also unacceptable. It is the unfortunate truth that until the C++ world decides on universal resource concepts there will always need to be some piece of code that knows the interfaces of both the waitable resource and the demultiplexor. However, there is no need for this dependent code to be part of either the demultiplexor or the resource. This code might be an adapter for the Boost thread class that allows it to be compatible with a particular third party demultiplexor class. In consideration of the these issues, one may conclude that there must be a mechanism in Boost classes to allow arbitrary code to access the encapsulated handle or descriptor that describes the underlying resource for purposes of implementing demultiplexing. While this may, at first, seem a potential violation of encapsulation, it might also be seen as proper application of the Open-Closed Principle. One simple mechanism for achieving this is presented: class unix_thread_handle { protected: pthread_t handle() { return hand; } private: pthread_t hand; }; class thread : public unix_thread_handle, public boost::noncopyable { // ... }; Demultiplexor adaptors are permitted to access the underlying handles by deriving from a system-specific type and copying from an existing resource. Such access is subject to the lifetime of the origin object and documented constraints about the meaning of the handle. A demultiplexor should also be designed to be compatible. The demultiplexor must provide some mechanism to allow code outside of Boost to obtain control flow when particular system events occur. In addition, interoperability should be maintained not only with foreign waitable resource classes, but with other demultiplexors, to the maximum extent possible. For example, on a system where an event is delivered through a chain of handlers (such as Windows hooks or UNIX sigaction), the demultiplexor must be careful to pass on the event when appropriate. In light of recent interest and development relating waiting and demultiplexing, it is especially important that the above points are considered. Writing a naïve demultiplexor that will forever plague future programmers who use third party libraries is a temptation that should be strenuously ignored. There are already plenty of frameworks that have implemented this unfortunate xenophobia. If Boost is able to offer an interface that makes its waitable resources and future demultiplexor openly compatible with the rest of the world, it will continue to be popular long after other libraries have outlived their usefulness. Any thoughtful consideration and comments would be greatly appreciated. If there is some interest in these things for Boost, I’d like to prepare some proof-of-concept alterations for waitable parts of Boost. I also have designed a cross-platform demultiplexor class, but unfortunately it is not in a state that is immediately ready to be shared with Boost. However, if there was interest, I would consider polishing it up. Aaron W. LaFramboise

5 14

RE: [boost] Formal review of "Output Formatters" library begins today
by Reece Dunn 13 Sep '04

13 Sep '04

Paul A Bristow wrote: >| [mailto:boost-bounces@lists.boost.org] On Behalf Of Reece Dunn >| > One thing I would REALLY REALLY like is a Boost 'Standard' way of >| >colouring and indenting code similar to Visual Studio IDE - >| though I don't >| >feel their colour scheme is quite as good mine! >| >| What do you think about the new Boost.quickdoc? The docs for >| quickbook are >| available at http://tinyurl.com/64el7, and the source is at >| http://tinyurl.com/4tdjj. Thanks to Eric and Joel for this great tool. > >I don't like the greyed background to anything. I don't think it helps at >all. >It makes things take longer to print out if you need a paper copy - when >the >going gets really tough. >Nor do the boxes around really help much either, but they at least don't >hinder. > >The coloring isn't strong enough for my taste - using blue for keywords is >a >great help in reading, IIUC, this can all be controlled via the CSS, e.g.: .keyword{ color: red; font-weight: bold; } >My view is that color is a massive hit in helping people to read code, >especially if it can be applied uniformly, something that Boost could >'impose'. This is true and would be where QuickDoc --> BoostBook --> HTML+CSS pays off. I am not sure about how the styling is controlled in XSL:FO+PDF, though. QuickDoc for syntax highlighting the C/C++ code; BoostBook for a consistent documentation format and CSS for consistent styling. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

[1.32 Release] Branch-for-release date
by Aleksey Gurtovoy 13 Sep '04

13 Sep '04

Hi All, 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? 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! -- Aleksey Gurtovoy MetaCommunications Engineering

7 8

RE: [boost] Re: Compression usinig IOStreams library
by Ben Hutchings 13 Sep '04

13 Sep '04

George M. Garner Jr. <gmgarner(a)erols.com> wrote: [Jonathan Turkanis wrote:] > > Dumb question - is Winzip supposed to be able to read the zlib > > format? I usually use it to decompress .zip or tar.gz archives. > > Well I made that assumption because Winzip and XP both maintain > associations for the .z extension. This is from the Winzip help > file: <snip> The ".Z" extension is conventionally used for files compressed with the Unix "compress" program, which uses LZW. zlib and gzip were created to provide a patent-free alternative to it. They use the same compression algorithm as PKZip and WinZip but do not use the PKZip file format. I doubt that WinZip has any support for raw compressed files.

2 1

[1.32 Release] Fixing long filenames
by Aleksey Gurtovoy 13 Sep '04

13 Sep '04

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 Thanks! -- Aleksey Gurtovoy MetaCommunications Engineering

7 8

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

13 Sep '04

John Torjo wrote: >>That is basically what I do already: >>wrappedfmt() is associated with openclose_formatter; >>pairfmt() is associated with formatter (using default_nary_traits) >>containerfmt() is associated with formatter (using >>default_sequence_traits) >>etc. > >Yes, and that is great! >But you hold them in the formatob object. I have this relationship: formatob isa FormatObject isa formatter usesa DefaultTraits FormatObject hasa FormatObject >What I'm saying is that (overridable) defaults for each of the above can >also be kept in the stream object itself. I understand what you are saying, I am just looking at how to implement it. >>so you can theoretically use any string type to store the default >>delimeter values. How do we do the equivalent with ios_base::pword/iword? > >That's your job - to come up with a technique for this ;) :) >Basically, the library's underlying concept doesn't have to change. This is >just an extra goodie you can provide. Sure. >>openclose_formatter/formatter set their delimeter values to the values >>provided by the default traits object passed to them. You can then >>override these defaults by calling format(). How do you tell that the >>default has been overrided? > >It's certainly possible. Internally, in the delim object, you can keep the >data like this: > >template<class value_type> struct val_keeper { > value_type val; > bool has_been_set; > //getter and setter - I assume you get the point >}; This might be easier if instead of formatter holding DelimeterType objects for each delimeter, have it store an io::delimeter< CharT > object and have that responsible for access, thus: template< typename CharT > class delimeter { private: const CharT * value; bool is_set; public: const CharT * get() const{ return( is_set ? value : ios_base::pword -> value()); } void set( const CharT * v ){ value = v; is_set = true; } delimeter(): value( "" ), is_set( false ){} }; and template< typename CharT > class formatter { public: delimeter< CharT > separator; // separator is now a property! }; >>The main questions are: >>[1] how do you store different DelimeterTypes in this mechanism? > >Which brings us to ;) : >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 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? Regards, Reece _________________________________________________________________ Get ready for school! Find articles, homework help and more in the Back to School Guide! http://special.msn.com/network/04backtoschool.armx

2 1

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

13 Sep '04

Jeff Flinn wrote: >"John Torjo" <john.lists(a)torjo.com> wrote in message >news:414443E0.60008@torjo.com... > > Dear boosters, > > > > The FORMAL Review of "Output Formatter" library begins today, > > Sept 12, 2004. > > > > 1. What is your evaluation of the design? > >I find the naming conventions misleading. 'outfmt' but it does io? What is >an '...ob' and '...obex'? This effort at reducing verbosity is then >countered as mentioned by Dave Abrahams, by the "syntactic noise". I am going to provide more consistent names once the review period is over. I made a start at this before review, but wanted to get a more general view of peoples thoughts before sticking to any particular names. The name outfmt is legacy. Initially it only provided output, but people were interested in input as well. Xob is an "X object" and Xobex is the variant of Xob that takes < DelimeterType >, e.g. Xobex< wchar_t * >. (I don't have a better name for this and am open to suggestions). >I do like the delimiter traits objects approach to dealing with >leader/trailer existence issues. Although I have not found passing "" >(empty >string) as the leader/trailer being a performance bottleneck since they are >only performed once per range. What about for the separator delimeter? For example: std::cout << io::formatob( vec ).format( "" ); >I like the range approach, but isn't a range library coming? Boost.Range has recently been adopted into boost. It should be fairly trivial to replace io::range with the Boost equivalent. >Will io::range be entirely compatible? My home grown range_streamer is >often used with >filter and transform iterators. It would be nice to use a shorter syntax >like: > os << range_stream( aC, lFilterFnc, "\n=\n{ ", "\n, ", "\n}" ); >rather than > [snip] You mean supporting your range_streamer from within my framework? Or supporting ranged types in general (range types are supported within the framework)? > > 2. What is your evaluation of the implementation? > >The main motivation I had for developing a similar output facility was >dealing with the dangling separator when using std::copy and >ostream_iterator in a consistent/performant fashion. Your rearrangement is quite neat! It removes the duplicated test. > > 3. What is your evaluation of the documentation? > >After reading Jonathon's IOStream documentation, my expectations have been >raised. Some of the problems are due to the misleading names used in the >implementation itself. Almost everything is a format_this or format_that >with format methods... Perhaps an additional namespace level would >alleviate >some of this. As I have mentioned above, I am going to revise the naming once the review is over, based on the comments provided here. >Missing are Motivation and Rationale sections. When/Why would someone use >this library versus ostream_iterator/Tokenizer/Spirit/... ostream_iterator does not, AFAIK, handle nested constructs like std::vector< std::list< int > >. Tokenizer is primarliy concerned with reading data back in and I'm not sure if/how it supports containers, arrays and pair/nary types. Spirit is too complex for when you want simple formatting and is only concerned with parsing (reading) data. It also adds a lot of overhead and does not fit in with the C++ I/O stream framework. Boost.Serialize does a great job, but is not very flexible in the way that the data is serialized. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

4 4

boost/tools/build/jam_src/strings.c typo
by Caleb Epstein 13 Sep '04

13 Sep '04

Looks like version 1.6 of boost/tools/build/jam_src/strings.c introduced a typo. #include is spelled #Include (capital I) on line 5. -- Caleb Epstein caleb.epstein(a)gmail.com

1 0

C++ GUI - another view
by Andy Little 13 Sep '04

13 Sep '04

Hi, Recent discussions on boost have talked about GUI's in quite technical terms, windowing etc. Another part of the abstraction is simply that of providing an area for drawing on. The code below is a simple example of what I mean. The "drawFunction" is meant to be like a graphics version of a main() function .( Note that there should ideally be no DeviceHandle visible to the "drawFunction". The DeviceHandle should be wrapped in the GX object, passed to the function so some of the impl is poking through here in form of the gx.line_to etc functions 'hdc' argument. Its early days.) The display output from the function is available at: http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/source/capacitor… Behind the function there is of course a windows app, (built using WTL in this case), though the function could could be invoked on any widget, any operating system ,screen or printer or any device,,, even (say) an oscilloscope with suitable exposure of the x, y type traits of the GX object :-) Note that the use of the unit'ed lengths eg length:::mm provides the key to the success of the abstraction. If (say) doubles were used, one would need to provide (Somehow) the information as to what those values represent. here it is encoded in the type. (And a note to Java programmers... The same scheme is entirely possible in Java too ). The other useful device is the "morph" object, which is used to morph time and voltage into lengths in this example. However it can be used on any two types that can be divided by one another. There arent many primitives yet, only lines which makes the function a bit wordy as it stands, but the intention is to make lines, rects etc available which can be used to build more complex objects which can be sent to an output "graphics stream". ... and then the "three_d" namespace ;-) regards Andy Little /////////////// #if (defined _MSC_VER) && (_MSC_VER >= 1200) # pragma once #endif /* draw the voltage/time discharge curve for a capacitor */ #ifndef PQS_TWO_D_VIEW_ABSTRACTION_HPP_INCLUDED #define PQS_TWO_D_VIEW_ABSTRACTION_HPP_INCLUDED #include "pqs/ct_quantity/operations/morph.hpp" #include "pqs/pqs.hpp" namespace pqs { namespace two_d{ template <typename GX, typename DeviceHandle> inline void drawFunction(GX & gx, DeviceHandle hdc) { // vect<X,Y> is a general purpose (x,y) container // for coords sizes etc typedef vect<length::mm> pt; // set up size of drawing area in world coordinate sizes // This can be scaled and scrolled by the other layers // for output on a device // world coordinates as used here // are the top layer of the graphics view gx.max_position() = pt(length::mm(180),length::mm(170)); gx.min_position() = pt(length::mm(0), length::mm(0)); // set up border length::mm const border(20); // set up a drawing rectangle for the graph // of voltage / time pt draw_rect; draw_rect.x() = gx.max_position().x() - 2 * border; draw_rect.y() = gx.max_position().y() / 2 - border; // move origin to (0,0) on graph gx.set_origin(border,border); // draw a border round the graph gx.move_to(hdc,length::mm(0),length::mm(0)); gx.line_to(hdc,draw_rect.x(),length::mm(0)); gx.line_to(hdc,draw_rect.x(), draw_rect.y()); gx.line_to(hdc,length::mm(0), draw_rect.y()); gx.line_to(hdc,length::mm(0),length::mm(0)); gx.text_out(hdc,length::mm(20), draw_rect.y() - length::mm(10), "Capacitor Time Curve" ); // capacitor time curve data capacitance::uF const C(0.47); //capacitor voltage::V const V0(5); //starting voltage across capacitor resistance::kR const R(4.7); // resistance between terminals time_<int>::ms const max_time(20); // The "morph" functors convert the source physical-quantities to target types // (here lengths for drawing obviously) // with correctly dimensioned scaling value // as ctor argument morph<length::mm,time::ms> time_x( draw_rect.x() / max_time); morph<length::mm,voltage::V> volts_y( draw_rect.y() / V0); // draw the graph for ( time_<int>::ms t ; t <= max_time; ++t ){ voltage::V Vt = V0 * std::exp(-t / (R * C)); if (t == time_<int>::ms(0)){ gx.move_to(hdc, time_x(t),volts_y(Vt) ); // "morph" useage } else{ gx.line_to(hdc, time_x(t),volts_y(Vt) ); } } } }}//pqs::two_d #endif

1 0

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

13 Sep '04

David Abrahams wrote: >John Torjo <john.lists(a)torjo.com> writes: > > > When doing the formal review, please answer the following questions: > > > > 1. What is your evaluation of the design? > >It seems to introduce a great deal syntactic noise: > > std::cout << boost::io::formatob( vec ); > // output: [ 1, 2, 3 ] > > std::cout << boost::io::formatob( vec ).format( "{ ", " }" ); > // output: { 1 : 2 : 3 } > > >I'd like to (at least) see rationale on why something cleaner wasn't >chosen. For example: > > namespace io = boost::io; > std::cout << io::sequence( vec ); > // output: [ 1, 2, 3 ] > > std::cout << io::sequence( vec, "{ ", " }" ); > // output: { 1 : 2 : 3 } There are two basic components: a delimeter holder (formatter/openclose_formatter) that contain the delimeters and control over them, and a format object that tells the library what type the object being formatted is. Your suggestion for placing the delimeter specifications in the type construction messes things up since you are combining two separate concepts. This would lead to many different function overloads (you'd need one for each variant). Also, the design would fail when adding new delimeters for things like trees and graphs. >In case it's not obvious, I don't like the name "formatob." Abbrevs >should generally be avoided, and frankly I don't know what 'ob' >stands for. Also "format" doesn't seem to add much semantically. "ob" stands for "object". I am willing to negotiate appropriate names. io::sequence seems reasonable enough. >I'm generally not a great fan of statefulness, but this also seems >like a reasonable thing to want: > > namespace io = boost::io; > std::cout << io::sequence_delimiters("{ ", " }"); > std::cout << io::sequence( vec ); > // output: { 1, 2, 3 } You can achieve something like this using: io::formatter< const char * > fmt( "{ ", " }" ); std::cout << io::sequence( vec ).format( fmt ); If there are any better alternatives, I am willing to listen. >Library organization seems problematic. On one hand, I'd like to see >the io for individual boost types like octonion distributed across >their respective libraries (e.g. in boost/math/io.hpp). On the other >hand that will introduce an "apparent library dependency" that may not >be needed by some. The "apparent dependency" of this library on all >the others isn't very comforting, either. Perhaps some refactoring is >appropriate. I think this will be an issue no matter how it is implemented. Especially for the STL container types. The code has already been refactored so that each STL/Boost type registers its self in a separate file, so you can include them individually. It might be a good idea to have the Boost/complex types include just the type deduction mechanism code. This would reduce the file/library dependencies. >Another point: I'd like to see functionality for pretty-printing >sequences. It's very common to have sequences that are too long to >represent comfortably on one line. There are several strategies for >dealing with that, and it seems to me that to be *really* >indispensible, this library should help in that department. I don't know if additional support needs to be built into the framework, but you can implement your own format object that could perform pretty-printing functionality, e.g.: std::cout << io::sequence( vec, io::pretty_container()); It should also be possible to design character escapers/unescapers, allowing: std::cout << io::sequence( str, io::container_fmt( xml::char_escaper().format( "", "" )); >It might >also need ways to prevent infinite recursion in self-referential >sequences (consider sequences that embed ranges). Hmm. I am not sure how to implement this. Suggestions are welcome. >Where's I/O for tuples? I have not added tuple support yet. > > 3. What is your evaluation of the documentation? > >What little I saw of the tutorial documentation looked readable and >comprehensible. The lack of namespace aliases in the examples don't >help the library's case. I'd like to see more rationales. okay. >AFAICT the docs lack any sort of formalized reference guide, showing >interface summaries, what headers to include, requirements, etc. IMO >it's unacceptable without that component. Did I miss something? okay. IIUC, Doxygen will auto-generate these when provided javadoc-like comments. >The use of "implementation defined" in the documentation is >incorrect. To be correct, the Boost implementation would have to >define whatever it is. The appropriate term is "unspecified." okay. >I/O for existing Boost types such as rational<>: > > IMO the fact that we didn't have I/O for these is sort of > embarassing, but at the same time it's unclear to me that not > having inserters/extractors was a burden for anyone. I can't > recall a single post asking where these things were. I/O does exist for rational, octonion, interval and so forth. The headers in my library for boost components are there to tell my library what type of sequence a particular type is (e.g. rational<> is a pair type, octonion an n-ary type and std::list a container). This is so that my library knows how to format that type. > > And most important, > > 8. Do you think the library should be accepted as a Boost library? > > Be sure to say this explicitly so that your other comments don't > > obscure your overall opinion. > >The lack of reference docs is a showstopper for me. okay. I'll look at getting doxygen up and running on my machine. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

4 7