- Boost - lists.boost.org

RE: [boost] RE: Re: Formal review of "Output Formatters" librarybeginstoday
by Reece Dunn 22 Sep '04

22 Sep '04

Vladimir Prus wrote: >Reece Dunn wrote: > > > You can explicitally state where/how new lines and indentation are going > > to be within my library by adding them to the open/close/separator > > formatting (see output-3D.cpp for an example). > >Yes, but I'd rather write > > os << v > >and have the right formatting, even if 'v' is a vector of something, which >has vector members, and the vector element type has another vector member, >and so on... This would further complicate the implementation of the library. To do what you want would require something similar to the Cascading Style Sheet proposal to maintain the default values for each format object type. This would be more complex for it to handle std::vector and std::list separately, but it may be possible to use the ID returned by type traits (differentiating sequential, associative and set containers). >The wrapping is indeed a separate issue. What I was asking is support of >indenting in your library. For example, the output such as >[snip] >Yes, except that I'd want "multiline" to act recursively, so if I print >vector of maps, the result will look like: >[ > { > a: 1 > b: 2 > } > { > c: 3 > } >] > >or using a different syntax. It would be possible to make use of a state object: a state object is an object that is rendered before or after an element is rendered. The implementation of this using the review version would be complex, but possible. I was considering adding pre+post support for a state object. Another idea is to implement an "event object" that gets called at the various stages of output. e.g.: Event::handler( before_decorator( io::open_decorator_id )); os << open; Event::handler( after_decorator( io::open_decorator_id )); // ... I'll need to think about this. >I'd suggest that you at least try to make top-level functions non-inline. >That would reduce the code size for application which use your library -- >I've had this experience both with program_options and function. For a >single library, it's probably not a huge difference, but if all libraries >use inline less liberaly, the code size of C++ apps would be lower. ok. noted. > >>I might be missing something, but the mechanism for getting the type of > >>formatter from a type to be output seems too complex. First, the > >>type_deducer.hpp file is used, and 'select' computes a 'category'. Then > >>format_deducer.hpp takes the category, and again uses 'select' to obtain > >>the real type of formatter. Why the type_deducer.hpp is needed? > >... > > > template<> struct deduce_type< io::seq_container_type > > > { > > template< typename CharT, typename T > > > struct type_from > > { > > typedef typename T::value_type value_type; > > typedef typename get_deducer< CharT, value_type >::type > > value_deducer; > > > > typedef container_t > > < CharT, typename value_deducer::format_object > format_object; > > > > static format_object deduce( const T & ) > > { > > return( format_object( value_deducer::deduce( >value_type()))); > >Does this expects the T::value_type is DefaultConstructible? IIRC, >containers only require that objects be CopyConstructible and Assignable. Don't std::list implementations work like: struct list_node { T value; list_node * prev, next; }; typedef list_node list_node_block[ 100 ]; // ... so T needs to be DefaultConstructible. I'll need to consult C++98 to be sure. > > } > >Still, I don't understand the need for integer type category. Can't you >have > > 'deduce_sequence_type' > 'deduce_pair_type' > >and so on, and use 'select' to map a type directly into those classes, not >into integer? Then I would need to do: select < is_std_vector< T >, deduce_sequence_type, is_std_list< T >, deduce_sequence_type, ... > This would not allow you to add a new container type into the mechanism without obtrusively altering the code. Also, there is a limit to the number of template parameters on select. The present system simplifies this by mapping to a category. (This also allows you to write more generic code, for example fmt::pair is implemented using these categories to work out how the pair type is constructed and fmt::container uses it to provide different behaviour for sequential, associative and set-based containers). In the new type deduction system, I map type --> type to extract a format object type, e.g. assoc_container_type to seq_container_type. This allows you to only provide one template overload. This system is more extensible than the review version (using select). > >> "providing an extensible framework that sits" > >> > >>How it's extensible? I see only one section about extending and it's >just > >>one paragraph long > > > > I really need to add more documentation regarding this. The idea is that > > you can: > > > > * add your own decorators (delimiters in the review docs) to support >more > > complex types (e.g. trees and graphs). > >That's interesting. Can you explain? You can write a class similar to [openclose_]formatter to add your own decorator type, e.g.: // new style template< typename CharT > struct binary_tree_decorators { decoration< CharT, 3 > left; decoration< CharT, 4 > right; // ... }; where 3 and 4 are the decorator IDs for the left and right decorations. You can then make use of this in a tree format object, e.g.: os << tree.left << left << tree.value << right << tree.right; resulting in something like: 1 <-- 2 --> 3 combining this with fmt::wrapper: [[1] <-- 2 --> [3] ] <-- 4 --> [[] <-- 5 --> [[6] <-- 7 --> []]] This is just an example. Consideration would need to be given to how the data is nested and how it interacts with the rest of the library. > > Underlying type is: typeid(ob).name(). > >Sorry, that's the name of type ;-) Maybe you just mean "according to its >type?" (also note "its", not "it's"). The "underlying" implies there's some >another type, besides 'T'. yes! >Maybe, you can use something like: > > "The 'object' function can only output a container, so to output a range > of iterators you need to make a container from it using io::range". "output a container": the argument is not necessarily a container (e.g. std::pair). How about: "The 'object' function can only output an object of type T (it cannot output ranges declared using two arguments), so to output a range of iterators you need to make a container-like object from it using io::range". >The original sentence sounds like the format is something external to >openclose_formatter, and the class is just a proxy which allows to set it. It is a holder for several decorations (e.g. open/close or open/close/separator), allowing you to set more than one of these and - in the discussion of using expressions - dealing with the evaluation of one of these expressions, e.g.: fmt::container() / " + " > >>The code block before > >>this comment defines two classes openclose_formatter_t and > >>openclose_formatter. Is this a typo, or you really have two classes? > > > > This is not a typo. The _t variants take a template parameter that > > contains the return value of the 'format' ('decorate') functions. This >is > > so that: > > std::cout << io::object( vec, fmt::container().decorate( " | " )); > > works properly. > >Why don't 'decorate' return the same type as 'fmt::container()'? Because they are implemented in wrapper_decorators_t [review version: openclose_formatter_t] and sequence_decorators_t [formatter_t]. To return the same type as fmt::container() would require implementing the 'decorate' function in the fmt::basic_container class (i.e. implementing 5 or 6 functions). You would need to do this for all the other format objects, including the ones that the user writes, so why do this? Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Re: Formal review of "Output Formatters" library beginstoday
by Rozental, Gennadiy 22 Sep '04

22 Sep '04

Hi, I would like to start with resolution. I vote NOT to accept this submission. Here some more details: > 1. What is your evaluation of the design? Library trying to solve in fact trivial problem. Would it be presented as trivial function Template<typename C> Foo( C const& c, std::string open, std::string close, std::string sep ); I may understand it. As to presented design - I see it as unnecessary complicated. And in many cases simply incorrect. Library does not follow standard practice as to wide char support. Interfaces seem confusing and error prone. Decoration model seems too simple to warrant so much trouble as reusable library. Maybe more powerful/flexible solution should be considered. > 2. What is your evaluation of the implementation? In most part I either don't understand or don't like it. IMO simple task library trying to solve shouldn't require that much code. Simple overloading base solution should've done the trick. > 3. What is your evaluation of the documentation? Did not get to this stage. > 4. What is your evaluation of the potential usefulness of the library? Now to the most important: why would I ever want to use library like this? We have already: std::ostream boost::format boost::serailization In what scenario I would use this library? I most definitely wouldn't want to repeat all this formatting every time I need to output my vector. If I write output operation rarely - I would use explicit loop -it's more flexible anyway. If I write output operation frequently - I would separate in function and here again would use explicit loop for the same reasons. If I write many output functions like above - I would write wrapper function like in 1. And it will work for most collections. I wouldn't use this library for filtering - we will have iostreams library for that (If I am not mistaken). I wouldn't use this library for XML printing - why would I want to mention tag name twice? Anybody? > 5. Did you try to use the library? Did not get to this stage. > 6. How much effort did you put into your evaluation? A quick In-depth study. > 7. Are you knowledgeable about the problem domain? That's the main issue - I do not see problem domain. Regards, Gennadiy.

2 1

Re:RE: [boost] Re: FORMAL Review of "Output Formatter" library -
by Reece Dunn 22 Sep '04

22 Sep '04

Robert Ramey wrote: > > Although my library is still under review, I am re-architecturing it > >based on the feedback thus far. This post is the code associated with >what > > was the delimiters/formatters part of the library. They are now given >the > > better name of "decorators". > >If your making changes in the library already, maybe you might want to >consider withdrawing it from the formal review and re-submitting it after >you've made all the changes you want to make. It might be easier (for you >as well as for reviewers) than going through the whole process more than >once. IIUC, the serialization library went through several reviews before being accepted. This is the best place to get decent feedback on a library from the most people. If I withdraw the library, there may be a comment that I miss (because the reviewer has not posted it since the library is withdrawn) that makes an important point. I have had lots of feedback regarding the names of the various components. The changes I have made are an attempt to pre-emptively address these issues and to say that I am taking all the comments into consideration. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

6 11

Re: [boost] RE: OutFrmt lib design questions
by Reece Dunn 22 Sep '04

22 Sep '04

John Torjo wrote: >>>>2. If primary target is collection formatting wouldn't it be better to >>>>name library "collection formats something"? >>> >>>This is a good idea. The name is from when the library just had output >>>support, thus the "outfmt" directory in the sandbox. I am thinking about >>>moving to a "formatter" directory. What do other people think? >> >> >>I'm -1. Having "format" and "formatter" is confusing. The name should >>somehow mention that you format data structures. > >I second that - 'formatter' is just confusing. >However, something like 'coll_format' or 'sequence_format' - I'm ok with >them. 'coll_format' has got my vote :) Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

3 2

Regression: avoid cleanup of binaries
by Stefan Slapeta 21 Sep '04

21 Sep '04

After the regression tests there seems to be a total cleanup of the binaries. Is it possible to avoid this in some way? (maybe specifying --incremental is the solution, but I would rather guess letting away this option should clean up the binaries _before_ the test run, shouldn't it?!?) Stefan

3 4

[shared_ptr] InterlockedIncrement rocks!
by John Torjo 21 Sep '04

21 Sep '04

Hi Peter, I just took your implementation (http://www.pdimov.com/cpp/shared_count_x86_exp2.hpp) for shared_ptr and use it now in win32gui (upcoming v1.4.2). Using Interlocked* for win32 totally rocks! From my tests - Interlocked* are very fast. They're about twice as slow as a raw increment (or my tests are wrong;)). From what I see - I think you can certainly merge them into boost::shared_ptr. Maybe users can select the old version or this Interlocked* version with a certain macro - like BOOST_SHARED_PTR_USE_INTERLOCKED. Also, why not including windows.h directly, like this: #define WIN32_LEAN_AND_MEAN #include <windows.h> <side-note> From my tests it seems your version as is now fails to link for gcc (unresolved external _InterlockedIncrement/_InterlockedDecrement). However, if #including <windows.h> and use InterlockedIncrement/Decrement - they work. </side-note> Best, John -- John Torjo -- john(a)torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)

2 1

RE: [boost] [shared_ptr] InterlockedIncrement rocks!
by Puverle, Tomas (IT) 21 Sep '04

21 Sep '04

> >>Also, why not including windows.h directly, like this: > >>#define WIN32_LEAN_AND_MEAN > >>#include <windows.h> > > > > > > I believe WIN32_EXTRA_LEAN may be even better. > > Just a thought - there is no WIN32_EXTRA_LEAN on vc7.1 Yes you are correct. I misremembered VC_EXTRALEAN, which is a similar macro, but for MFC only. Tom -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not waive confidentiality or privilege, and use is prohibited.

1 0

Re: [boost] Re: [assign] fixes for msvc, msvc-stlport and vc7
by JOAQUIN LOPEZ MU?Z 21 Sep '04

21 Sep '04

----- Mensaje original ----- De: Thorsten Ottosen <nesotto(a)cs.auc.dk> Fecha: Martes, Septiembre 21, 2004 9:03 pm Asunto: [boost] Re: [assign] fixes for msvc, msvc-stlport and vc7 > Hi Joaquin, > [...] > > | 2. list_insert::operator()(T t) has been changed to accept > | a const reference instead. > > I have made this change as > > #if BOOST_WORKAROUND(BOOST_MSVC, <= 1200) > > template< class T > > list_inserter& operator()( const T& t ) > #else > template< class T > > list_inserter& operator()( T t ) > #endif As you wrote it, the workaround applies only to MSVC 6.0. Let's wait for the next test cycle to see if it has to be extended to MSVC 7.0 as well. > > | With these changes, all tests build, though three of them > | crash at run-time (list_inserter, list_of and multi_index_container) > > ok, this is much better than before! some of the test a big and > fat and do > some tricky conversions...but just having the > basic stuff working is great! > > |I've got two questions: > | > |1. Could somebody (the author, I guess) validate these changes > |for commit? > > I have comitted them. > > |2. list_inserter follows a strange convention (IMHO) of not > |forcing template params to be const references in its various > |copy ctors and assignment operators, for instance: > | > |list_inserter( Function fun ); > |template< class T > > |list_inserter& operator=( T r ); > | > |Any reason for this approach? I don't know if this can pose > |problems, but to me having these qualified with const & seems > |like the usual way. > > yes, the bitches are char[N] and wchar_t[N] which does not convert > to char* > and wchar_t* otherwise. this comes up in simple stuff like > > vector<string> = list_of( "foo" )( "goobar" ); Ummm, I see. The fact is that here lies, I think, the reason for the three remaining crashes, all on calls to multi-argument versions of list_inserter::operator(). Maybe I'll give this some thinking over if I have some spare time tomorrow. > > of course, the Function arg could be const Function&, but is there any > difference in inline code? I think this can involve an extra copy under some circumstances, ans some compilers might not optimize this away. But in general I agree with you little is gained by having const Function &. > > Muchos gracias for the patch! Velbekomme :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] Re: static_cast and const
by Ben Hutchings 21 Sep '04

21 Sep '04

Jonathan Turkanis <technews(a)kangaroologic.com> wrote: > "David Abrahams" <dave(a)boost-consulting.com> wrote in message > news:umzzl3pvk.fsf@boost-consulting.com... > > Richard Hadsell <hadsell(a)blueskystudios.com> writes: > > > > > Jonathan Turkanis wrote: > > > > > >>When I was writing it I initially typed 'const_cast', but then > > >>thought to myself: why use my big guns if I don't have to? ;-) > > >> > > > For clarity -- to tell the reader that you intended to modify the > > > const-ness. > > > > static_cast is a bigger gun than const_cast. At least const_cast > > cant violate data layout, and unless there is actually a constant > > object, won't result in undefined behavior. > > Good point. I guess part of the reason I avoid const_cast whenever > possible is that people look upon it suspiciously, even if it's only > adding cv-qualification. Maybe people should be more suspicious of > static_cast. If you want to make an implicit conversion explicit, use boost::implicit_cast.

3 3

dynamic scoping emulation - was Re: Lexical cast suggestion
by Jonathan Graehl 21 Sep '04

21 Sep '04

> > >Nope, there's only one global locale, it's not per-thread. If it's >per-thread, you can do > > std::locale::tss_global(std::locale("koi8-r")); > // do some work with program_options > std::locale::tss_global(std::locale("")); > I do this all the time (but using a scope guard), for globals I've declared thread-local. This essentially simulates dynamic scoping (which I'd prefer to see supported directly by the language, as an alternative to lexical scoping). Perhaps a Boost library for dynamically scoped properties would be nice? -Jonathan

1 0