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

Re: [boost] Re: iostreams library review
by slavek.f.kuzniar＠jpmorgan.com 05 Jun '04

05 Jun '04

I downloaded the library from the yahoo link you mentioned in the review request. When trying to use 'filtered_stream' I ran into some compilation issues (RedHat 9, g++ 3.3) and before looking into it I wanted to know the review status. Knowing that the library is in the review pipeline I will give it another try. Some time ago I developed simple iostream adapter 'library' that allows to wrap IO device (sockets, pipes, etc) in std::[i,o,io]stream that is very similar to your sink/source technique. One difference is that the adapter is a template class parameterized by the source/sink types. Since your library offers this functionality (plus much more) I am very pleased it will become part of boost soon. technews@kangarool ogic.com To: boost(a)lists.boost.org Sent by: cc: boost-bounces@list Subject: [boost] Re: iostreams library review s.boost.org 05/29/04 06:41 PM Please respond to boost <slavek.f.kuzniar(a)jpmorgan.com> wrote in message news:OFF5E3130C.48F086BB-ON85256EA2.004FA2A3@ny.jpmorgan.com... > On Boost mailing archives I found a review request for Iostreams Library > by Jonathan Turkanis. I did not see any follow-up and the library is not > part of latest release so I suspect the review did not happen. Anyone knows > what is the fate of this library? Thanks for your interest! The previous version available at http://www.xmission.com/~turkanis/iostreams/. I've since made some major simplifications and improvements, and am scrambing to update the docs. It now contains support for memory-mapped files (from Craig Henderson) and for compression and decompression in the zlib, gzip and bzip2 formats. Jonathan _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.

3 9

Re: [boost] Re: New utility at boost/detail/allocator.hpp
by JOAQUIN LOPEZ MU?Z 04 Jun '04

04 Jun '04

----- Mensaje original ----- De: Rob Stewart <stewart(a)sig.com> Fecha: Viernes, Junio 4, 2004 8:39 pm Asunto: Re: [boost] Re: New utility at boost/detail/allocator.hpp > From: Joaquin M Lopez Munoz <joaquin(a)tid.es> > > Rob Stewart <stewart <at> sig.com> writes: > > > From: Joaquin M Lopez Munoz <joaquin <at> tid.es> > > > > > > > > For these reasons, I think allocator_rebind is not an > > > > appropriate name. Anyone suggesting a better name than > > > > allocator_helper? (Andreas? you wanted to use this stuff) > > > > > > Why not simply allocator_utilities.hpp? > > > > Yes, sounds good. Same name for the namespace > > (boost::detail::allocator_utilities)? Isn't it > > a little long? > > Any reason why the ns can't be "allocator?" This code will > coexist with any allocator library that may appear, I should > think, and these should interoperate with such a library; it > might even become part of such a library. I can't see a problem > with them sharing a ns. (That also suggests that the directory > for the header is boost/allocator/detail.) > That's too bold IMHO. We don't even know how a potential future allocator library might look like to impose it to receive this: more than a bequest to that library, this stuff could be an inconvenient burden. So, I propose boost/detail/allocator_utilities.hpp boost::detail::allocator Later on, we're still free to move (or alias) this into boost::allocator if it fits into that future allocator lib. What do you think? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [boost] static sized strings
by Reece Dunn 04 Jun '04

04 Jun '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Martin wrote: > > >2. Substrings > > >------------- > > >One of the applications I can see for fixed_string is when you want to > > >avoid > > >dynamic allocation but still want to use the std::string interface and > > >algorithms. In that perspective it seems strange that substr returns a > > >std::string instead of a fixed_string. > >Agreed. I agree too. It is just that the current implementation cannot create an instance of boost::char_string (because of the ABC - necessary to allow operations on variable-capacity strings). Also, you cannot get at the fixed_string type/length at compile time so it is not possible to derive the *return type* at compile time. > > This is related to the above problem. You cannot create an instance of > > boost::char_string, etc. and as such cannot implement substr in the >usual > > way (this is the proplem I was having with operator+). The solution >would be > > to defione an alternate substr function in fixed_string, but this would >not > > solve the problem for boost::char_string, etc. > > > > The alternative would be to use a ranged string (pointer to the >fixed_string > > buffer and length), but the problem with this is null-termination. > > > > I do not see an easy way around this without removing the ABC design, >since > > it is not possible to do fixed_string< length() > or something similar. > >Couldn't substr() be a pure virtual function in char_string that >deferred to the derived class to create a copy of itself? The >derived class can just create a duplicate of itself, including >the current capacity. That capacity is guarranteed to be >sufficient to hold any substring requested. The return type cannot be boost::fixed_string_base because of the whole ABC issue. Therefore, the return type needs to be a reference or a pointer. It is possible to do this, and have: class fixed_string { inline fixed_string_base & substr_( size_type pos, size_type n ) { return( this_type( *this, pos, n )); } }; This is problematic because of returning the address of a temporary - and leads to unpredictable output. I am looking for a better solution to this. I am also thinking about how to remove the ABC from the implementation using a technique pointed out by someone on this thread (can't remember who): class fs_base { size_t len; szie_t capacity; // needed for buffer-safe operations CharT str[ 1 ]; // string manipulation functions fs_base( size_t c ): capacity( c ){} }; template< size_t n > class fixed_string: public fs_base { CharT data[ n ]; fixed_string(): fs_base( n ){} }; I'll need to look into this, to see what effect this will have, to see if it is a possible replacement for the ABC. What do other people think? Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

3 3

more_io_4 in Files area
by Daryle Walker 04 Jun '04

04 Jun '04

The latest version of More-I/O is in our YahooGroups Files area at <http://groups.yahoo.com/group/boost/files/more_io_4.zip>. This should be the version to be used for the upcoming (second) review. I built this version before my recent hard-drive reformat and OS upgrade, and I haven't tested it yet on my new system. Quick portability checks would be appreciated. I noticed that some reviewed libraries put their code up on the (login-free) web space SourceForge reserved for the Sandbox CVS. How is that done? Does an administrator need to give me special access? (I already have read and write access to the CVS part of the Sandbox.) Contents: * I/O Manipulators * expansions of endl The "new line then flush" function was generalized with optional flushing, repeat amounts, and selectable breaking characters. Streams can output characters belonging to their character type, but also of type "char" (no matter what "char_type" is). The "multi_basic_newer" class template works with a specific "char_type", but any "traits_type". The "multi_newer" class works only with "char" values, but any "char_type" and "traits_type". The "multi_newl" works as an easy way to use "multi_newer". And "newl" encapsulates the most common case of "endl" - "flush". * input-oriented variations of endl Instead of writing a new line, these manipulators read (and ignore) lines instead. These work similarly to their output-oriented counterparts: "multi_basic_skipper", "multi_skipper", "multi_skipl", and "skipl". * basic non-oriented The "resetios" manipulator defaults most of a stream's formatting attributes. * complex non-oriented The "basic_ios_form" class template can encapsulate several simultaneous formatting changes in a potentially reusable object. Configurations of such objects can be done in a progressive manner. * Stream-buffer wrappers Creating new stream types generally involving making a custom stream buffer class, then connecting it to a generic stream class shell. The wrappers "basic_wrapping_istream", "basic_wrapping_ostream", and "basic_wrapping_iostream" help with the latter. These are used by all of the streams given later in this library. * Elementary streams * null-stream ("onullstream", etc.) Acts as an infinite character destination and an empty character source, like "/dev/null" * value-stream ("ivaluestream", etc.) Acts as an empty character destination and an infinite character source, like "/dev/zero" (The returned character is configurable.) * Character buffer streams (legacy of strstream) The std::basic_stringstream family works as an modernized substitute for std::strstream most of the time, but it's overkill when the dynamic memory nature isn't needed. The following class templates fill in the missing modes of the (surprisingly overloaded) std::strstream family. * run-time specified character buffer ("pointerstream", etc.) Only uses the character buffer given to it at construction time, gives EOF instead of going to dynamic memory management when full. There is a variant for constant buffers (read-only, of course). These classes are essential when an existing buffer can be used without forcing a copy (e.g. larger than 50% of RAM). * compile-time specified fixed-size character buffer The "basic_array_streambuf" class template uses an internally contained array as the character buffer. More convenient than the previous class when the maximum buffer size is fixed at compile time and there is little need for sharing the buffer. Changes from the last interim version (called "more_io_3b.zip"): * split the manipulator header into several headers * refined the license statements in some already-affected files Changes from the first formal review (called "more_io.zip"): * refined the interface and implementation of array-streams and stream-buffer wrappers (including a wrapping example) * added the null-stream, value-stream, and pointer-stream headers * added generalizations to the new-line and skip-line manipulators * added the non-oriented 'reset' and 'form' manipulators * split the manipulator header into several headers * changed the license statements -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 2

Re: [boost] Re: New utility at boost/detail/allocator.hpp
by JOAQUIN LOPEZ MU?Z 04 Jun '04

04 Jun '04

----- Mensaje original ----- De: David Abrahams <dave(a)boost-consulting.com> > Joaquín Mª López Muñoz <joaquin(a)tid.es> writes: [...] > > is in boost::detail::allocator), I don't have any problem with > renaming to > > allocator_helper (it's a better name, actually.) If no one else > objects (which > > I doubt) I'll apply the name change tomorrow. > > I think allocator_rebind would be a much better name than > allocator_helper. > Ummm, the problem with allocator_rebind is that the header contains some other stuff not strictly related to rebinding: * partial_std_allocator_wrapper * construct (allocator-independent construction function) * destroy (allocator-independent destruction function) ?? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 5

[iterator + lambda] transform_iterator and lambda expression
by Vladimir Prus 04 Jun '04

04 Jun '04

I'm again trying to use FP in C++, and having problems. What I wanted to do was: for_each(predecesor(v, g), /* BLL expression */ ); where predecessor(..) returns a pair of 'transform_iterator' instances. The simplest example which illustrates the problem is: struct functor { typedef int result_type; int operator()(int i) const { return i+1; }; }; transform_iterator<functor, vector<int>::iterator> it(v.begin()); (cout << _1)(*it); This does not compile, because operator* of transform_iterator return rvalue which can't be bound to non-const reference that operator() of the lambda expression accepts. Of all workarounds suggsted on BLL docs, only break_const is applicable to my case (I want to pass non-const references to the lambda, so const_parameters won't do), and break_const is scary. It looks like a serious problem with using FP, so I wonder what can be done. Maybe, transform_iterator should have yet another template parameter telling if it should store a value internally, and return reference (i.e. lvalue) in that case? It need not be enabled by default, but functions like my 'predecessor' above would make use of that extra template parameter. - Volodya

4 8

Re:[boost] A question on serialization library
by Robert Ramey 04 Jun '04

04 Jun '04

Virendra Verma wrote: > If a class has a pointer to an object, how does class know that the > pointer was created by library or the class itself before serialization? It doesn't. Why would it need to? Robert Ramey

2 1

transform_iterator( Iterator const& x ) ???
by David Abrahams 04 Jun '04

04 Jun '04

I'm not sure why I never saw this on the list, but since I saw the moderation request and I figure you deserve a reply... boost-owner(a)lists.boost.org writes: > From: "Sascha" <vudu(a)gmx.net> > Subject: boost::transform_iterator( Iterator const& x ) ??? > To: <boost(a)lists.boost.org> > Date: Thu, 3 Jun 2004 00:22:18 +0200 > > hi > > a simple question about the construction of > boost::transform_iterator. > > currently there are two ctors implemented: > > transform_iterator(); > transform_iterator(Iterator const& x, UnaryFunction f); > > why does boost::transform_iterator(Iterator const& x) not exist leaving > the function object default constructed? Are you looking at the source code or the documentation? Oh, I see you're doing as you should and looking at the documentation! Well it turns out that the source code actually contains this constructor: explicit transform_iterator(Iterator const& x) : super_t(x) { // don't provide this constructor if UnaryFunction is a // function pointer type, since it will be 0. Too dangerous. BOOST_STATIC_ASSERT(is_class<UnaryFunction>::value); } > can I add it without getting in trouble? No, but we can fix the documentation ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

[Boost-bugs] [ boost-Bugs-966496 ] [BGL] Asymmetry between read_graphviz() and write_graphviz()
by SourceForge.net 04 Jun '04

04 Jun '04

Bugs item #966496, was opened at 2004-06-04 06:02 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=966496&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: [BGL] Asymmetry between read_graphviz() and write_graphviz() Initial Comment: During some experiments with the BGL-GraphViz interface, I observed a significant asymmetry between a given DOT graph input with boost::read_graphviz() and output with boost::write_graphviz() (without changing any attributes). Given the input DOT file <metro.dot> (which is, of course, much longer with the full set of information), the elementary BGL program <metro.cxx> transforms this into the output DOT file <metro_boost.dot> (the three files are attached to this submission). It seems that somewhere on the way, the graph and node (and edge) attributes get clobbered. Note that even the graph name "metro" gets replaced by the name of the (last) subgraph "ligne_1", and /all/ node attributes get mixed up. This seems to be somewhat similar to the recent edge-related problem posted by Hideaki Hiraki to the boost-users list. I have not (yet) tried to mess with the graphviz parser code, so I am asking here for help. Thanks. Greetings, Andreas <andreas dot scherer at rb-its dot de> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=966496&group_i… ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

BOOST_NO_STDC_NAMESPACE and LIBCOMO
by Robert Ramey 04 Jun '04

04 Jun '04

Commeau I'm building with como-win32 with the libcomo library. It seems that BOOST_NO_STDC_NAMESPACE is set to true with this combination and that it should be set to false for this combination. Robert Ramey

3 2