September 2004 - Boost - lists.preview.boost.org

[boost.range] comparison operators for iterator_range and sub_range
by Thorsten Ottosen 09 Sep '04

09 Sep '04

Dear all, Another small issue have surfaced regarding operator==(), operator!=() and operator<() (the latter currently not there). The current behavior is compare the two underlying iterators. I would suggest to change this to compare the objects in the underlying range. The motivation would be the follwoing: 1. comparing the iterators is seldom useful and can be done explicitlty or by a new member function equal() 2. comparing the objects is the range is highly useful and allows for code like sub_range<string> sub = ...; if( sub == "foo" ) 3. operator<() cannot be defined for iterators in general and hence we couldn't put iterator_range into a set/map; Any comments? An additional question would be if operator> operator>= etc really needs to be defined? I would support just to have ==, !=, < to start with. br Thorsten

3 4

Incorrect XML output using boost::serialization
by Brian Riis 09 Sep '04

09 Sep '04

Using boost CVS (boost-04-09-05-2200), I am using the serialization library (which generally is a real life-saver, btw. Thanks Robert!!!) Anyway, I have been using the XML output for a few days, and I just had a good look at it, and realized it is not well-formed. > <?xml version="1.0" encoding="UTF-8" standalone="yes" ?> > <!DOCTYPE boost_serialization> > <boost_serialization signature="serialization::archive" version="3"> > <m_db class_id="0" tracking_level="0"> > ... The boost_serialization STag above is never matched by a ETag, nor is it an EmptyElem apparently. Is this intended? Or did I miss something while writing the serialization code? I.e. am I supposed to close it myself, or something? It is a minor thing, I know, but it _will_ make any standards-conforming XML-viewer reject it. Other than that, as I mentioned above, Boost.Serialization has saved my life recently (rewriting to use it was by far easier than debugging the I/O routines I was using, and they were somehow _seriously_ messed up). Great work! -- /Brian Riis

1 0

Re:[boost] Re: IOStreams formal review start
by Robert Ramey 09 Sep '04

09 Sep '04

>I decided not to use iterators because I concluded that it would miss the >opportunity for many important optimizations that can be made when one is >presented with a contiguous buffer full of characters instead of one >character at a time. For example, I don't think zlib is very efficient if >you pass it one character at a time. >Still ... >I wish I had looked at the Dataflow Iterators in your library when I first >read your message! I put it on my mental 'to do' list then promptly forgot. >It looks like Dataflow Iterators and input/output filters are intended to >solve exactly the same sort of problems in many cases. So there are these >obvious questions: I didn't want to make a big issue of this because it amounts to comparing what currently the sketch of an idea (my dataflow iterators) to a fully developed and implemented idea (your iostreams). It's an unfair (to you) and often misleading type of comparison. So I see your library getting accepted more or less as it is because it works, well documented and addresses a real and pressing need. Dataflow iterators really became practical with Dave's new iterator façade/adaptor library - with its very formal definition. But, in spite of the fact that they have been used successfully in the serialization package for doing some of the things your library does, Dataflow iterators are a little too fragile for general use. Someday you or someone might want to re-implement some of your library with dataflow iterators - or not. At that point it would become an implementation issue. I'm very pleased that someone has seen the appeal of this idea. I sort of feel that I'm out there by myself with my ideas. I think its because I'm getting old. Anyway. >1. Where the functionality overlaps, which approach is faster? One of the prime motivations for the dataflow iterators is gain absolutely maximum speed. This should occur by collapsing of composed inline functions by C++ optimizing compilers. My limited investigation into this convinces me that this occurs as I would hope. >2. What can your approach do that mine can't? >3. What can my approach do that yours can't? Dataflow iterators is basically a compile-time composition concept while your method is basically a run-time composition concept. There in lies the difference Compile time composition a) compilers can collapse inline code for maximum speed b) each composition of filters is recompiled - can imply replicated almost the same code. Code bloat possible c) new chains can't be made at runtime under program control - its too late to recompile. Runtime composition a) filter chain can be built as needed under program control. b) each filter is compiled only once and reused. No code bloat c) no opportunity for "inter-filter" optimization - the code is compiled before the filters are composed. >4. If your approach is better all around, or in a broad class of cases, can >I adapt my library to use it? (I think so -- the pipe notation, which you >don't like, can give the compiler a clue which filters should be fused at >compile time.) My main complaint with the pipe notation is that, is doesn't permit the following idea to be expressed without destroying its original elegance: Encrypt( Cat( Stream 1, Stream 2 ) ) That is, that you have to break it (the pipe idea) in order to save it. Also I believe that implementing this at compile time by overloading operators would be a lot of work for mere syntactic sugar. In fact this hides the operation of your chaining scheme rather than keeping it transparent. This is the same reason I like to see the streambuf/stream clarified rather than hidden. Hiding is often a good idea - unix command line pipes - but I don't think its a great idea for programmer libraries. I want sharp tools whose application and usage are obvious so that I can compose them into what I need. I don't want a wrapped up solution. So I like a smaller library (e.g. streambuf) with examples (for cut and paste) on how to use it. I also think it's easier to document. I don't think you mess with your library in a major way. Separating out streams/buffers is useful conceptually but that's really mostly a matter of documentation. Basically you should finish what you started, let people start using it then at your leisure if you have the inclination look in this idea. 5. If my approach is better, can your library use it? (BTW, How do you use the Dataflow Iterators in your library?) My use case for this functionality is the following I want a zlib compression filter and an encryption filter. I want to be able to use them in a stream either as compress | encrypt or encrypt | compress. Your library can do that. So the problem is solved in the short term. Its interesting how my thinking has evolved on this. First I thought what I need was a stream adaptors to adapt a stream using filters. After I became more familiear with streams and streambufs I realized that this functionality didn't belong in streams but in streambufs - exactly where you put it. I was much encouraged by your efforts and approach - and Jeff Garland's previous accomplishment of adding zlib compression to a streambuf. Alas, I've now come to understand where codecvt facet fits in here. My current thinking - its just speculation at this point - is composition of codecvt facets using dataflow iterators. This would result in: a) a codecvt_facade - template for making a codecvt class given a dataflow iterator chain at compile time. b) dataflow iterators for encrypt, compress, base64, wchar_t to mbchar, mbchar to wchar_t, wchar_t to utf-8 etc. c) a method - codecvt_adaptor ? - for composition of arbitray codecvt facets. This would permit us to use other existing pre-compiled facets like translating to Chinese mult-byte characterset. So given the above, we could make a custom codecvt facet which would take the output, compress it, encrypt it, convert to base64, convert to Chinese character set with one compile time statement and use that facet with any stream. Except for the Chinese part which used a pre-compiled element, the compiler would optimize away all redundant copying. Naturally this codecvt facet on steroids could be used with any streambuf without alteration. (or even recompilation). So the "final division of effort would be" Streams - rendering types like int, float, etc as char or wchar strings. Streambuf - buffering Codecvt_facet - filtering/transformation Bear in mind that this glosses over details like the fact that there's a lot of annoying little differences in standard libraries in codecvt_facet interface, function prototypes, etc. GCC used 4 by wchar_t, window uses 2 byte wchar_t, endien issues, on and on and on. I've had problems with several libraries that I don't believe handle codecvt facets properly. Just using the utf-8 facet written by Ron Garcia - (nice job - no errors) has been a trial due to these issues. >I'm going to try to re-implement some of your iterators as Filters, and see >what happens. Feel free to experiment at your leisure. But don't get distracted. Starting something is easy - finishing something is very hard. You're in a position to get something of substance actually finished and in the hands of real users. Don't lose focus on that. In the serialization library - composition of dataflow iterators is used to implement the following: Escaping/unescaping html text Binary <-> base64 translation Wstring <-> string translation Maybe others - I don't remember The dataflow concept was once and object of research interest as a fundamental programming paradigm. It's somewhat to related to functional programming in this regard. My dataflow iterator implementation is somewhat similar to the FP package reviewed earlier this year in that it implements a different programming paradigm using the facilities of C++ templates. However, its much less ambitious and much more focused on immediate C++ problems rather producing a complete implementation of another programming paradigm. One thing is clear to me. We're going to see lots of new things in the future of programming. Much more than people think. Robert Ramey

2 1

Re: typeof
by Arkadiy Vertleyb 09 Sep '04

09 Sep '04

Hi Goran, > First, why there isn't a way to register wstring type, even though I've registered wchar_t? I've > managed to use it only after I've registered basic_string template with one template parameter. > Seems inpractical... There are a few choices here: 1) BOOST_TYPEOF_REGISTER_TYPE(wstring); 2) BOOST_TYPEOF_REGISTER_TYPE(wchar_t); BOOST_TYPEOF_REGISTER_TEMPLATE(std::basic_string, 1); 3) BOOST_TYPEOF_REGISTER_TYPE(wchar_t); BOOST_TYPEOF_REGISTER_TEMPLATE(std::basic_string, 3); BOOST_TYPEOF_REGISTER_TEMPLATE(std::char_traits, 1); BOOST_TYPEOF_REGISTER_TEMPLATE(std::allocator, 1); Pre-registration of STL types would be a very nice addition to the library. For now I am avoiding this, and trying to focus on the facility itself. > Second problem, no matter whether I've used wstring or basic_string for registration, I wasn't able > to get a type of wstring::iterator expression! This is much more complicated problem, and I am not sure it can be resolved... The problem is that you can't specialize (or overload) on a nested types. The Standard clearly says that this is a non-deducible context. So we can't do something like: template<class V, class T> encode_type<V, T::iterator>{}; // compiler error! This is VERY unfortunate, and I 've been trying to think of workarounds, but so far I only came up with one that is quite limited and ugly... So I decided to put this on hold. Regards, Arkadiy

2 2

Test of list access through gmane -- please ignore
by Larry Meehan 09 Sep '04

09 Sep '04

Test of boost list access through gmane -- please ignore.

1 0

Re: [boost] Re: Empty member optimization
by JOAQUIN LOPEZ MU?Z 09 Sep '04

09 Sep '04

----- Mensaje original ----- De: Jonathan Turkanis <technews(a)kangaroologic.com> Fecha: Jueves, Septiembre 9, 2004 6:44 pm Asunto: [boost] Re: Empty member optimization [...] > Second, I don't have time to look into the details of your > implementation, but I > wan't to make sure you're aware of the EBO problems Dave Held ran > into with his > policy_ptr, based on the loki SmartPtr. Basically, compilers will > apply EBO once > or twice for a given class, and that's it. The exception seems to > be recent > versions of gcc (I don't remember if its 3.3 or 3.4). > Maybe the implementation can be changed so that compressed_member can inherit from another compressed_member, so as to make this syntax feasible: template <typename T0, typename T1> struct A : private compressed_member<T0> ::and<T1, 1>::type ::and<T2, 2>::type { } or something similar, resolving to a linear hierarchy of compressed_member's. AFAICS, EBO applicability limitations would be solved that way. An sketch of copmresed_member implementation would be as follows: struct dummy{}; template <typename T, size_t Index = 0, typename Base=dummy> struct compresed_member: public Base { // utility metafunc for adding members template <typename Q, size_t AnotherIndex = Index+1> struct and { typedef compressed_member< Q, AnotherIndex, compressed_member<T, Index, Base> > type; }; // rest of the implementation } Get the idea? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[Boost-bugs] [ boost-Bugs-1025124 ] boost::function doesn't accept classes declared in functions
by SourceForge.net 09 Sep '04

09 Sep '04

Bugs item #1025124, was opened at 2004-09-09 06:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1025124&group_… Category: functional Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Mark Rodgers (mark_rodgers) Summary: boost::function doesn't accept classes declared in functions Initial Comment: Submitter: John Engström <john.engstrom\spam\(a)\spam\solcorp.com> Using MSVC 7.1, I use a functor defined in-scope, as in the following example. ///////////////////// code snippet void bar() { ... struct my_functor { void operator () (int arg1, int arg2) { ... foo(); ... } ... }; my_functor my_functor_instance; boost::function2<void, int, int> my_function1 = boost::ref(my_functor_instance); boost::function2<void, int, int> my_function2 = my_functor_instance; } /////////////////// explanation This fails to compile, see below for error messages, however if I move the declaration of the functor out of the function bar(), it compiles fine. Perhaps it only happens with MSVC. /////////////////// error messages main.cpp(116): error C2893: Failed to specialize function template 'const boost::reference_wrapper<T> boost::ref(T &)' main.cpp(117): error C2440: 'initializing' : cannot convert from 'WinMain::my_functor' to 'boost::function2<R,T0,T1>' with [ R=void, T0=int, T1=int ] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1025124&group_… ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: Boost Digest, Vol 844, Issue 5
by Michael Stevens 09 Sep '04

09 Sep '04

On Thursday 09 September 2004 05:42, David Abraham wrote: > If these are (supposedly) random access iterators, it's because the > ublas people aren't using iterator_facade or iterator_adaptor to > define them. I think you hit the nail on the head there! Making this change is number one on the priority list. The base classes to do this are already partially in place. Just a little work is required to change the rest of the code! Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

2 1

[mpl][vacpp] remaining problems
by Joaquín Mª López Muñoz 09 Sep '04

09 Sep '04

Tests are failing due to a problem with BOOST_MPL_ASSERT_RELATION, for instance: "../libs/mpl/test/arithmetic.cpp", line 25.5: 1540-1264 (S) The template argument must be preceded by an ampersand (&). I've checked boost/mpl/assert.hpp, and seems like there is already an alternative implementation for buggy compilers driven by the macro BOOST_MPL_CFG_ASSERT_USE_RELATION_NAMES If given permission, I can commit a fix to define this for vacpp as well, and see how things work. If Markus is listening, maybe he can do a local test before. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Re: [admin] Overlapping reviews -- should this be allowed?
by Dave Gomboc 09 Sep '04

09 Sep '04

> > I wonder if enough libraries are going through the preliminary > > submission/refinement phase outlined at > > http://www.boost.org/more/submission_process.htm#Preliminary > > Many are not. The items listed there before submission for review are not that onerous. If they haven't been performed, the package should not be added to the review queue. Also, FWIW, I'm ixnay on the overlapping reviews. Dave

1 0