- Boost - lists.boost.org

[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

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

13 Sep '04

John Torjo wrote: >>>Well, I think my alternative is better if you want a stateful change, >>>since yours doesn't accomplish that. My suggestion is certainly >>>consistent with normal io manipulators. The point is to stream a >>>bunch of sequences without having to repeat the format part. >> >>I understand what you are saying and yes your version is neater. However, >>implementing something like this would have performance penalties (because >>you will need to create/store the preset values at run-time). > >The penalties are small. Anyway, using std::istream/ostream have penalties, >compared to using raw FILEs ;) This is true. >That said, in this case there shouldn't be many penalties. >Again, you can use >ios_base::pword and ios_base::iword for this. >It's an advanced technique, but I think it can prove very neat and >flexible. okay. >>It will also change the way all sequence constructs are rendered. (n-ary >>types have a different rendreing so won't be affected). As I understand, >>this is the desired effect. But then: > >You can make it possible to associate a fmt object with a delimeter object. > >Example: pairfmt() with openclose_formatter. >basicfmt() with formatter. Etc. 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. At the moment, default_nary_traits/default_sequence_traits provide the default strings to map to the specific type, e.g.: const char * default_nary_traits< const char * >::open_default(){ return( "( " ); } wchar_t default_nary_traits< wchar_t >::open_default(){ return( L"(" ); } std::string default_nary_traits< std::string >::open_default(){ return( std::string( "(" )); } 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? 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? One solution would be to use a null string as a default value. Then you can do class openclose_formatter { private: inline DelimeterType get_default_open() const { return ios_base::pword -> open(); // pseudocode } public: inline DelimeterType open() const { return( _open == null ? get_default_open() : _open ); } }; but this would complicate the access process for open(), close() and separator(), that in the current implementation simply return the data member. Also, what about string types such as std::string, QtString, CBStr and CString? What are their appropriate "null" values and how do you test that? I suppose you could have a resolve_default_values() function in the formatter class that is called when using FormatObject::read/write to reduce the resolution to a single pass, but what about when you save a formatter/format object, e.g.: io::formatter< const char * > fmt( " : " ); // oen/close use defaults std::cout << io::formatob( lst, io::containerfmt()).format( fmt ) // [1] << io::set_sequence_defaults( "< ", " >" ) // [2] << io::formatob( vec, io::containerfmt()).format( fmt ); // [3] [1] will resolve the default values used by fmt, [2] will change the defaults used and [3] will not be updated to reflect these changes, so you'd need the slower version. Alternatively, you can do this in FormatObject::read/write: DelimeterType separator_delim = separator(); while( first != last ) { // ... os << separator_delim; } >Then, you can store (default) delimeter objects within the stream. >Once you want to output/input something, it requires a specific delim >object. You'll somehow use ios_base::pword/iword to get a reference to that >object. The main questions are: [1] how do you store different DelimeterTypes in this mechanism? [2] how do you tell if the default is needed (see above)? Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

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

13 Sep '04

John Torjo wrote: >>2. The first part of documentation should >> be what is purpose of the library. >> >> I guess in this case it is debugging >> and testing support, 100% cases. > >Introduction: >"The Standard Template Library (STL) provides a mechanism for storing >collections of objects, but does not provide I/O support via streams. [...] > The outfmt library is an attempt to solve the problems outlined above, >providing an extensible framework [...]" > >So, what I gather is that it provides customizable I/O for >containers/ranges. Yes. >That said, I donot think its purpose is debugging/testing support 100% >cases. It does definitely support that, but you can do more - like, do some >pretty printing to file(s), std::cout, etc. Yes. >>5. To support debugging I would like to see >> many more features: >> >> - ability to wrap long lines in pretty way > >I guess this could be solved by IO streams lib ;) :) The problem with doing this during the output phase with my library is that you don't know in advance if outputting the next element will wrap around to the next line (and thus will need a new line inserting). Jonathan's library does indeed provide a solution for this. The example he gives does not support smart word-wrap facilities, but this can be done by writing to an internal buffer and outputting that up to the last space in the buffer, retaining the rest of the buffer until it wraps. >> - ability to generate HTML as output >> (+ ability to fold/unfold big data >> structures using Javascript). > >I assume this could be added in time... Reece? You can generate this now if what you are generating is regular, for example: <ol><li>a</li><li>b</li><li>c</li></ol> if you want an id or special position-based output, you can create a state object and use statefmt() like is done in libs/example/john-torjo.cpp to output: [0] John, [1] Jane, [2] Claire, [3] Mark for example: <ol><li id = "elem1">a</li><li id = "elem2">b</li><li id = "elem3">c</li></ol> Alternatively, you can output the data as XML and use XSL:T to generate the javascript/dynamic content. For example: std::list< std::pair< int, std::vector< char > > > data; std::cout << xml_signature << '\n' << xsl_stylesheet_signature << '\n' << '\n' << io::formatob( data, io::containerfmt ( io::pairfmt ( io::wrappedfmt().format( "<e>", "</e>" ) io::containerfmt().format( "<seq><e>", "</e></seq>", "</e><e>" ) ).format( "<pair>", "</pair>" ) ).format( "<seq>", "</seq>" ) ); output: <seq><pair><e>5</e><seq><e>a</e><e>b</e><e>c</e></seq></pair><pair><e>102</e><seq><e>x</e><e>y</e><e>z</e></seq></pair></seq> If you want it to be pretty, e.g.: <seq> <pair><e>5</e> <seq><e>a</e><e>b</e><e>c</e></seq> </pair> <pair><e>102</e> <seq><e>x</e><e>y</e><e>z</e></seq> </pair> </seq> You can specify this as: io::formatob( data, io::containerfmt ( io::pairfmt ( io::wrappedfmt().format( "<e>", "</e>" ) io::containerfmt().format( "\n <seq><e>", "</e></seq>", "</e><e>" ) ).format( "\n <pair>", "\n </pair>" ) ).format( "<seq>", "</seq>" ) ); Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

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

13 Sep '04

David Abrahams wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> writes: > > >>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. > >Well, I think my alternative is better if you want a stateful change, >since yours doesn't accomplish that. My suggestion is certainly >consistent with normal io manipulators. The point is to stream a >bunch of sequences without having to repeat the format part. I understand what you are saying and yes your version is neater. However, implementing something like this would have performance penalties (because you will need to create/store the preset values at run-time). It will also change the way all sequence constructs are rendered. (n-ary types have a different rendreing so won't be affected). As I understand, this is the desired effect. But then: [1] how do you select sequence or n-ary formatting? [2] what about extending this to incorporate - for example - tree or string formatting? [3] how do you extend this to formatter types that have additional delimeters? [4] how do you know when to extract the default delimeter values from the stream? Adding a formatter as a parameter to io::sequence, etc. would further complicate function lookup. Perhapse if I had an is_format_object< T >::value trait I could use MPL wizardry to distinguish between format object and delimeter formatter, allowing: io::formatter< const char * > fmt( "{ ", " }" ); std::cout << io::sequence( vec, fmt ); // output: { a, b, c } The problem with this is: what if you want to specify a format object and a delimeter formatter? This might work, but the implementation becomes more complex. Another idea would be to overload an operator like: std::cout << io::sequence( vec )( fmt ); // output: { a, b, c } or std::cout << io::sequence( vec )[ fmt ]; // output: { a, b, c } but this would further add to the confusion. If operator() was adopted, it would be possible to have that as a shorthand for format(). For example: std::cout << io::sequence( vec )( " | " ); // output: [ 1 | 2 | 3 ] Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Access to compiler options for all tests
by Stefan Slapeta 13 Sep '04

13 Sep '04

Would it be possible to provide the compiler options also for the regression tests that passed? They sometimes are interesting, too! Stefan

2 1