- Boost - lists.boost.org

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

25 May '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > To simplify my design, I could implement basic_string_impl using the >policy > > approach that flex_string uses. >Sorry, I don't know anything about flex_string, but what you've >shown would only serve to make your string class more painful >than John's (or your) current approach. I have come up with the following design that should satisfy all requirements: [1] it retains the basic_string interface in fixed_string_base (and thus [w]char_string) and fixed_string< n > [2] it retains the existing usage [3] it allows the use of char_string for operating on fixed_string< n, char > for any n without resorting to templates [4] it hides the implementation functions from the main interface and should now allow aggressive inlining of the code namespace detail { template< typename CharT, class Policy = std::char_traits< CharT > > struct fixed_string_iface{ /* ... */ }; template< class Base > class basic_string_impl: private Base { public: typedef typename Base::char_type char_type; typedef typename Base::traits_type traits_type; // ... }; } template< typename CharT, class Policy = std::char_traits< CharT > > struct fixed_string_base: public detail::basic_string_impl< detail::fixed_string_iface< CharT, Policy > > { // ... }; typedef fixed_string_base< char > char_string; typedef fixed_string_base< wchar_t > wchar_string; template< size_t n, typename CharT = char, class Policy = std::char_traits< CharT > > class flex_string: public fixed_string_base< CharT, Policy > { // ... }; However, the implementation has another an additional class, making it slightly more confusing to see what is happening; it does simplify basic_string_impl, though! NOTE: I have not fleshed out the above design, so don't know if it is truely implementable (it seems so). I shall update the sandbox code to reflect the above design when it is implemented. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

1 0

RE: [boost] Re: Formal Review Tribool
by Powell, Gary 25 May '04

25 May '04

I have read the docs and the code and I vote for acceptance. Implementation details aside as to whether the results of logic operators should be table lookups or not. I have not compiled the code but I will. >> 9. Silly question: is there way to use ternary operator >> somehow to initialize tribool conditionally: >> >> tribool t(x ? true : indeterminate); // something like that >Unfortunately, I don't know of a way to get the conversions to work out >right for that. If only we could overload the ternary operator :( Don't you want a quaternary operator? tribool t( x ? true_fn() : maybe_fn() : false_fn() ); :> (And yes I'd like to overload the ternary operator! But for other reasons...lambda one of them.) ------------------------------------- As a total aside, the only time I've needed anything like this I used a fuzzy_bool which had values from zero to one representated by a float. Then "indeterminate" fluxuates closer or farther from "true" and "false". With an optional latch function that prevents the shift in states from true to false until some threshold has been exceeded. I suspect that many users of tribool would be better off with such a beast. But that doesn't change my vote for this one. -Gary-

1 0

RE: [boost] Re: static sized strings
by Reece Dunn 25 May '04

25 May '04

Martin wrote: >I have looked at both implementation and got some comments: > >1. Both implementations use a size independent base class. I can see the >need >for such a class but don't understand how to use it in the way proposed. There are some examples in the associated C-string compatibility sections (boost/fixed_string/safe_strings.hpp for mine; boost_fixed_string_string.hpp for John's). This allows you to write: inline char * strcpy( boost::char_string & d, const char * s ) { return( d.assign( s )); } as opposed to: template< size_t n > inline char * strcpy( boost::fixed_string< n, char > & d, const char * s ) { return( d.assign( s )); } allowing you to migrate code that relies on strcpy, etc easier and not have to templatize each function (so you can keep them in a static/dynamic library for example). >The base class only implements a few methods so in my view it is more or >less >useless. E.g. a function taking a "base" argument can't iterate or look at >the >string content without converting it to a c-string (so it could just as >well >use a c-string argument). Why not implement the full interface in the base >class? The base class actually has the full basic_string interface (minus the constructors). It exposes 14 virtual functions that are implemented by fixed_string (allowing the proper implementation to be called). The complete basic_string interface is implemented by detail::basic_string_impl (which is based on flex_string), so for example, at( szie_t ) is used to implement operator[] as well and [const_]iter_offset is used for the begin(), end() variations. >2. I couldn't find any background discussion on what non-const operations >should be allowed on the string. Only the std::string interface is >mentioned >but since the fixed_string is guaranteed to be continuos it makes sense to >also allow non-const access to the string. There wasn't that much discussion, although John is in favour of const-only (safer). Feel free to add to the discussion and I'll take a lopok at implementing them if they are reasonable. >In both versions c_str() is const while data() is const only in the sandbox >version. I think a const c_str() and non-const data() (as an overload to >keep >the std::string interface) is the way to go. The only objection to this I can see would be relating to the safety of the underlying string and co buffer overflow quarantees on using the non-const data. >3. As mentioned in other posts, length is messy and I don't think there are >any way to safely store the length inside the class. There will always be a >risk that the non-const operations add/removes a '\0' in the wrong place. >One Maybe the c_str() in fixed_string< n, CharT > should perform a validation to ensure that: str[ len ] == CharT() and optionally (it is not a requirement that this holds, if it does not, then the full string is not printable, just as if you tried to output "Hello\0Foobar!"): str[ 0..(len - 1)] != CharT() That way the string integrity is kept, while allowing simple implementations of operations such as length and push_back. >solution may be to add something similar to the CString's "ReleaseBuffer()" >(with a better name) that allows you to force an update of the length after >an >unsafe operation. That is a possibility (see John's implementation). The question is: how does this affect performance? I am not saying my solution is the way to go, just evaluating the various options. >And last just an idea I got from the flex_string implementation: Why not >allow >use of the "struct hack" as a performance option. e.g. > >[snip] This is interesting. Does it have any specific advantages over the two implementations? Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

4 3

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

25 May '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > > > What I am interested in is a comparison between > >* I think that data() would be better named "buffer." The This would go with the renaming you suggest for functions that are the same in the base and implementation classes (hiding issue). >* Should fixed_string support zero-length strings? You can have zero-length strings in my implementation (this is what fized_string() defaults to). What you *can't* have is a zero-*capacity* string, which is the same as CharT[ 0 ]. >* I'm not sure that there's enough value in > const_iter_offset()/iter_offset() versus begin()/end() (const > and non-const) in the derived class. You eliminate four > trivial functions, but you may eliminate opportunities for > optimizations. (I'm thinking there may be derived types that > have a better way of computing end and that returning the > result of adding zero to a pointer is slower than simply > returning the pointer.) This is true. I will probably expand the interface to the four begin/end functions. >* fixed_string doesn't have a const overload of at(). I shall fix this. > Calling fixed_string's at() "at" seems wrong. You should take the tack > of requiring a derivate of detail::basic_string_impl to provide > uniquely named, implementation functions that basic_string_impl > uses to provide the public interface. You could even suggest > that such functions be made private with the basic_string_impl > specialization made a friend. Your current approach will > generate many "hiding" warnings, too. I will rename the conflicting names. >* fixed_string's at() shouldn't test the length and throw an > exception since detail::basic_string_impl::at() does it and > detail::basic_string_impl::operator[] calls it. fixed_string tests against capacity as a measure against [] usage that would cause buffer overflow, e.g. fixed_srting< 5 > str; str[ 10 ] = 'a'; // ok: exception vs char str2[ 5 ]; str[ 10 ] = 'a'; // foobar >* fixed_string::swap() is missing. >* detail::basic_string_impl::get_allocator() expects > string_type::get_allocator() but that isn't listed in the > requirements levied on the derived type and isn't defined in > fixed_string. These are currently missing becase (1) swap requires a deep copy and haven't implemented that yet; (2) allocators are not used by fixed_string (no need to allocate any data) so it is not implemented (I am considering if/how it should be implemented). NOTE: it should compile despite these missing from fixed_string unless you attempt to call those functions. >* I wouldn't expect fixed_string's StringPolicy to govern how to > determine the length of a string passed to a mf as a CharT *. It does not. string_type::length() returns the value of the string held in the class (return a variable value, defer to container, use traits_type, etc.). traits_type::length( const CharT * ) calculates the length of a string passed to it, wher traits_type is a char_triats compatible interface. >* If I kept looking, I'm sure I'd find many more things, but you > are more interested in philosophical differences, so I'll stop > here. Look at the end of the message for my summary. I am actually interested in both. The feedback is appreciated and I will use it to improve the code. >I think John's approach is better, only because it does less type >indirection. It relies on the more ordinary pvf approach to the >core functionality. Otherwise, the two libraries provide the >same functionality (or can when complete). To simplify my design, I could implement basic_string_impl using the policy approach that flex_string uses. The problem with this is that it requires a usage like: flex_string< fixed_string< 10, char > > str; so in order to get the fixed_string< n > syntax, I would need two classes instead of just the one: this was something I was trying to move away from, but the approach I use has several problems: [1] the code is less optimal (7.5k vs 5k on MS VC 7.1) in my approach, due to the indirection used; the flex_string policy approach would allow compilers to aggressively inline. [2] the implementation functions are exposed in the interface; a policy approach would allow the implementation to be hidden because it can be derived from it like flex_string. [3] in my current approach, I can't use typedefs from the StringPolicy in basic_string_impl (they are not defined yet); seperate classes will solve this. There may be others to this list. So I am going to change to the flex_string approach and see what happens :). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Re: [boost] Re: [Test] Intel 8 seems to need workaround
by JOAQUIN LOPEZ MU?Z 25 May '04

25 May '04

----- Mensaje original ----- De: Gennadiy Rozental <gennadiy.rozental(a)thomson.com> [...] > How presence of unrelated class foo affects access in class AA? That's the funny thing about it. In your code, from where I came up with this, the error with p_stages_amount pops out due to the presence of other, unrelated objects of type class_property. > Is it important that method is called foo also? > No, it is not relevant. You might want to play with the snippet using the online Comeau compiler at: http://www.comeaucomputing.com/tryitout/ Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

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

25 May '04

Rob Stewart wrote: >Sure, but you've both jumped off on a tangent unrelated to the >purpose of the original query. See my reply to Dave's message. I agree (thanks for the info, though :)). What I am interested in is a comparison between my implementation at: boost-sandbox/boost/fixed_string and John Nagle's implementation at: http://www.animats.com/source if possible. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

5 4

Fwd: Bug#245893: Boost.Python looks broken on debian/arm
by Domenico Andreoli 25 May '04

25 May '04

hello there, this is the the last important bug debian packages of Boost 1.31.0 have. this is copy of the message i already sent to debian-arm ml and Boost.Python ml with no response. i'm forwarding it here, on boost developers ml, as last chance to settle this out and finally make 1.31.0 reach debian sarge. it may also look like a problem in MPL. cheers domenico ----- Forwarded message from Domenico Andreoli <cavok(a)debian.org> ----- Date: Mon, 26 Apr 2004 23:46:10 +0200 From: Domenico Andreoli <cavok(a)debian.org> To: c++-sig(a)python.org, debian-arm(a)lists.debian.org Cc: 245893(a)bugs.debian.org Subject: Bug#245893: Boost.Python looks broken on debian/arm hi all, debian arm autobuilder fails to build the only two applications in main archive which make use Boost.Python, they are kdeedu [0] and regina-normal [1]. i'm trying to understand where the chain of errors reported in debian bug #245893 [2] really starts, problem is that i still have no simple program to reproduce this bug and not arm machine to play with. i'm asking to debian-arm mailing list some help reproducing the bug and to Boost.Python mailing list some help understanding the outcome. here follows what i think is the culprit error... /usr/include/boost/python/detail/def_helper.hpp: At global scope: /usr/include/boost/python/detail/def_helper.hpp: In instantiation of `boost::mpl::apply1<boost::python::detail::is_reference_to_member_function_pointer<boost::mpl::_1>, const char* const&>': /usr/include/boost/python/detail/def_helper.hpp:78: instantiated from `boost::python::detail::tuple_extract_base_select<boost::tuples::tuple<const char* const&, const boost::python::detail::not_specified&, const boost::python::detail::not_specified&, const boost::python::detail::not_specified&, boost::python::default_call_policies, boost::python::detail::keywords<0>, const char*, void (boost::python::detail::not_specified::*)(), boost::tuples::null_type, boost::tuples::null_type>, boost::python::detail::is_reference_to_member_function_pointer<boost::mpl::_1> >' /usr/include/boost/python/detail/def_helper.hpp:173: instantiated from `boost::python::detail::tuple_extract<boost::tuples::tuple<const char* const&, const boost::python::detail::not_specified&, const boost::python::detail::not_specified&, const boost::python::detail::not_specified&, boost::python::default_call_policies, boost::python::detail::keywords<0>, const char*, void (boost::python::detail::not_specified::*)(), boost::tuples::null_type, boost::tuples::null_type>, boost::python::detail::is_reference_to_member_function_pointer<boost::mpl::_1> >' /usr/include/boost/python/detail/def_helper.hpp:173: instantiated from `boost::python::detail::default_implementation_extract<boost::tuples::tuple<const char* const&, const boost::python::detail::not_specified&, const boost::python::detail::not_specified&, const boost::python::detail::not_specified&, boost::python::default_call_policies, boost::python::detail::keywords<0>, const char*, void (boost::python::detail::not_specified::*)(), boost::tuples::null_type, boost::tuples::null_type> >' /usr/include/boost/python/detail/def_helper.hpp:173: instantiated from `boost::python::detail::def_helper<const char*, boost::python::detail::not_specified, boost::python::detail::not_specified, boost::python::detail::not_specified>' /usr/include/boost/python/class.hpp:304: instantiated from `boost::python::class_<T, X1, X2, X3>& boost::python::class_<T, X1, X2, X3>::def(const char*, F) [with F = void (PythonOutputStream::*)(), T = PythonOutputStream, X1 = boost::noncopyable, X2 = boost::python::detail::not_specified, X3 = boost::python::detail::not_specified]' pythoninterpreter.cpp:89: instantiated from here /usr/include/boost/python/detail/def_helper.hpp:78: error: no class template named `apply' in `struct boost::python::detail::is_reference_to_member_function_pointer<boost::mpl::_1> ' any hint? thanks domenico [0] http://buildd.debian.org/fetch.php?&pkg=kdeedu&ver=4%3A3.2.2-1&arch=arm&sta… [1] http://buildd.debian.org/fetch.php?&pkg=regina-normal&ver=4.1.1-1&arch=arm&… [2] http://bugs.debian.org/245893 ----- End forwarded message ----- -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

2 2

Where is pool::get_requested_size() ??
by Martin Pärtel 25 May '04

25 May '04

This function can be found in documentation of pool: size_type get_requested_size() const; I searched for it in the header file in the latest 1.31.0 release and in the main CVS and was not able to find it. A google search turned up a post on the Boost mailing list dated March 2003! http://lists.boost.org/MailArchives/boost/msg45833.php A fix was promised in the reply but as far as I can see it is still not fixed (I may be wrong). Does anyone know anything about this? Thanks

1 0

RE: [boost] STL algorithm for containers (was Re: Re: boost/test/ detail/algorithm.hpp: request forpromotionand/or fast review)
by Rozental, Gennadiy 25 May '04

25 May '04

> Gennadiy Rozental wrote: > > Why don't we provide container versions of all stl algorithms: > > > > template<typename C,typename P> > > inline > > for_each( C const& c, P pred) // or non const ref?? > > { > > // unwrap here used to allow by_ref( c ) usage for > mutable predicates > > std::for_each( begin( unwrap( c ) ), end( unwrap( c ) ), P ); } > > This depends who do you mean by "we" ;-) There's a bunch of container > algorithms in the sandbox: > > http://tinyurl.com/yv6q3 > > and I use them quite a lot. > > - Volodya Oh! I missed it somehow. Is there plans for review request? I would second it. Gennadiy.

3 3

class properties: request for promotion and/or fast review.
by Gennadiy Rozental 25 May '04

25 May '04

Hi, I am using simple class properties facility for some time and found it quite useful. Actually it's nothing fancy - simple helper classes to eliminate repetitive setter/accessor methods (and no need for language extensions). Essentially if you need simple readwrite property with trivial access methods in you class you would instead of writing: T member; void set_member( T const& ) {...} T const& get_member() {...} would write: readwrite_property<T> member; Now any time you need to get a member value you would write T t = obj.member; while if you need to update the value: obj.member.value = t; It's not more nor less safe as usual get/set scheme. If you need readonly object property that get initialized in constructor and never updated you could use readonly_property template for example like this: class node { public: readonly<std::string> p_name; .... }; Now everywhere (almost) you could just use n.p_name. To get an access to name member functions you could use operator-> like this: n.p_name->size(); And nobody would be able to update readonly property value. Finally if you need to provide a write access for readonly property you could use another form of readonly_property template. Unfortunately during language limitations (inability to declare template parameter as friend) you would need to use macro, for example like this: class foo { public: BOOST_READONLY_PROPERTY( int, (foo)(Friend2) ) p_value; ... }; Now only class foo and Friend2 have a write access to the value of the property p_value; If boosters find this functionality worth reusing I am ready to prepare document page describing it's usage. If we don't find this header eligible for review I would like to ask then for permission to at least put these templates in boost namespace (currently boost::unit_test), for it inconvenience for me to keep it in deep namespace for rest of my current development. Header you could see here: http://tinyurl.com/38mcm Regards, Gennadiy.

5 18