May 2004 - Boost - lists.boost.org

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

27 May '04

John Nagle wrote: > Since space for a trailing null is required, the >minimum "capacity" is currently 1. > > The maximum value for "size()" is then "capacity()-1". >That seems a little wierd. Should the trailing null be >counted in "capacity?" This is a good point. At the moment fixed_string< n >::capacity() == n. It would therefore make sense that this be changed so that either: [1] fixed_string< n >::capacity() == n - 1 -- this would seem counter-intuitive, as fixed_string< 1 > would not be able to store any characters! [2] change CharT str[ n ] to CharT str[ n + 1 ] -- i.e. add an extra character for the trailing null. This would make more sense, as it is similar to: char * str = new char[ s.length() + 1 ]; I personally but a vote for solution 2, but what do other people think? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

RE: [boost] Re: [prereview request][fsm]
by Brian Braatz 27 May '04

27 May '04

(My own post got me thinking some more). I am new to boost, and do not fully have my head around all that exists. But I am asking a general question here, has anyone tried running boost under "Managed C++", I assume there is a lot of RAII type of usage in boost that I assume would break. Or am I misunderstanding something? Thanks to anyone who can clarify. -----Original Message----- From: Brian Braatz Sent: Wednesday, May 26, 2004 5:18 PM To: 'boost(a)lists.boost.org' Subject: RE: [boost] Re: [prereview request][fsm] My 2 cents """""""""""""""""" This is certainly doable. However, I'm unsure whether the current > design allows a you-don't-pay-for-what-you-don't-use implementation of > such a feature. Plus, I'm still not convinced that this feature would > be used more than rarely. Do you have some real-world use cases in mind? [David Abrahams] Unfortunately I'm not so familiar with what exit actions in FSMs are typically used for, but from an abstract point of view I don't think of resource releasing as an "action". If you were writing this stuff in a GC'd language, for the most part, you wouldn't devote any exit action code to resource releases. """""""""""""""""' I think this is a very good point as MS seems (IMO\whether I like it or not) to be driving us down a managed GC path for future C++ efforts. This is something to deeply consider. Not that MS is "everything", but they do have a lot of C++ developers using their tools and os's.

3 2

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

26 May '04

Reece Dunn wrote: >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. I have fixed the various naming issues: adding a const version of at(); expanding iter_offset() to begin() and end(); adding a _ at the end of the implementation functions to prevent name hiding and to allow them to be declared private. I have also implemented get_allocator() and switched to a flex_string style policty-based implementation (which resolves several issues and allows for the compiler to better optimize the code). The implementation is still lacking swap, but that is all. This change has not effected the interface I have been using, so you can still do things like: inline void print( boost::char_string & str ) { std::cout << str << '\n'; } int main() { boost::fixed_string< 20 > s; strcpy( s, "Hello " ); // note: this does not work with Borland s += "Meine Welt!"; print( s ); for( boost::fixed_string< 20 >::reverse_iterator i = s.rbegin(); i != s.rend(); ++i ) { std::cout << *i; } std::cout << '\n'; } Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

Re: [Boost-announce] Formal Review Tribool
by Haim Cohen 26 May '04

26 May '04

Hi, I am happy to contribute my review for the tribool library. I am a software engineer developing EDA (Electronic Design Automation) software, so I think I can contribute my 2 cents to the review of tribool, as I think EDA tools will benefit from this library. I did not compile the library. I have made a quick reading of this library, but an in-depth study of this problem domain before. First of all, my first comment is about the library's name, as well as the class name. In logic circuit simulation, there are 4 values : 0, 1, x ( which is tribool referred to as undetermine ), and z ( represents high impedance - or disconnection, and sometime referred to as "tri state" ). So, I think users will find it quite confusing when they see the 'tri' in the library's name. Since the library implements a logic value which has some value that is unknown, I would suggest 'unknown bool' or 'x bool'. Now to the interface. I think that a macro which enables renaming of the x value should not be supplied. This will make people's code less standard. Same as we all know what 'true' and 'false' mean, we should adopt a unique name for 'unknown yet quite determined logic value'. I think the default 'undetermine' name is not a good name. My suggestions : logic_x, x_value, x_logic, unknwon_bool . I also think the default tribool constructor should create a tribool object which is 'undetermine'. (Not false, as in the documentation) Besides the above, I think the interface of the class is good and succinct. Some point for thought : Users might want arrays of tribools, with all the support of bitwise operations. Is this should be a part of tribool as well ? I do not know. Now I will refer to the implementation. In real-life problems, programs might make a heavy usage of the tribool class for simulations of logic circuits. A logic circuit (at least the combinatoric part) is a DAG where nodes are logic gates, and directed archs are wires. This graph might be the result of a synthesis process, where a high level language for hardware description (e.g Verilog) is compiled into this DAG. Note : This is a very general and simple description of the process. Life are much more difficult. So, outputs will be calculated by performing lexicographic order of the DAG, and calculating from inputs to outputs. I am telling this, to convince that performance is *very* important here. With a quick look at the implementation code, I think that calculating the value using branches (if else) will not result with good performance. Calculations with true/false values only is fast - CPU vendors dedicate special hardware for this, so calculation can be made in one machine cycle. Even bitwise calculation (up to some word width) is done in one machine cycle. Compilers are making use of this, and (hopefully) compiles boolean and bitwise operators to the appropriate instruction. Unfortunately, I did not see any CPU which supports built in true/false/X arithmetic. And even if there are such CPUs available, we will not be able to use it, since boost libraries should be portable. So, it is very tempting to think - how can we implement efficient true/false/X arithmetic using the existing boolean arithmetic ? One tempting idea is to represent true/false/X with some integers, and use bitwise arithmetic to get the right results. It seems there are no such integer values. I think I even managed to proof this. Since there is already a library implementing 4 values logic (0,1,x,z) - which is SystemC - I took a quick look on how they do it with their 4-states logic data type called sc_logic. They use an approach which I think should be also used in tribool. It seems that they maintain lookup tables for each operation: AND, OR, NOT, XOR (!=) and XNOR (==). As the internal representation of tribool is enumerated type, we can use the integer value of this enumerated type to access the lookup tables (primitive 2D fixed-size and fixed-values arrays) and get the result of the calculation. This will be much faster since most CPUs has a special addressing mode for accessing arrays. So, I suggest to change implementation to use class-static fixed array to perform calculations. I know that the spirit of Boost is portability and not performance, but since what is suggested here is actually very similar to a primitive data type which might be heavily used in applications, I think it is important to consider performance as well. I hope this review would be found useful. Haim -- _____________________________________________________ Haim Cohen Software Engineer haim.cohen AT analog.com / haimcohen2002 AT hotmail.com Analog Devices Israel

2 2

Ranged type mini-library submission
by christopher diggins 26 May '04

26 May '04

There has been some discussion previously on this list for a ranged type. My personal desire was to have new double types in the ranges [0.0, 1.0) and [0.0, 1.0] among other things. There are several other uses that I can imagine. Feel free to rip this apart or do whatever you want. #include <float.h> #include <assert.h> namespace boost { // a simple range class template<class policy> class range { public: typedef range<policy> self; typedef typename policy::value value; range() : m(min()) { } range(const self& x) : m(x) { } range(const value& x) { m = rangeAssert(x); } static const value min() { return policy::min(); } static const value max() { return policy::max(); } operator value() { return m; } self& operator=(const self& x) { m = x; return *this; } self& operator=(const value& x) { m = rangeAssert(x); return *this; } const value& rangeAssert(const value& x) const { assert(x <= max()); assert(x >= min()); return x; }; private: value m; }; // some range policies struct RangePolicyZeroToOne { typedef double value; static const value min() { return 0.0; }; static const value max() { return 1.0; }; }; struct RangePolicyZeroToBelowOne { typedef double value; static const value min() { return 0.0; }; static const value max() { return 1.0 - DBL_EPSILON; }; }; struct RangePolicyPercent { typedef double value; static const value min() { return 0.0; }; static const value max() { return 100.0; }; }; struct RangePolicyDegrees { typedef double value; static const value min() { return 0.0; }; static const value max() { return 360.0 - DBL_EPSILON; }; }; struct RangePolicyRadians { typedef double value; static const value min() { return 0.0; }; static const value max() { return (2 * PI) - DBL_EPSILON; }; }; template <typename T, T min_T, T max_T> struct StaticRange { typedef T value; static const value min() { return min_T; }; static const value max() { return max_T; }; } // some sample types made with ranges typedef range<RangePolicyZeroToOne> Probability; typedef range<RangePolicyZeroToBelowOne> Distribution; typedef range<RangePolicyPercent> Percent; typedef range<RangePolicyDegrees> Degrees; typedef range<RangePolicyRadians> Radians; typedef range<RangePolicyStatic<int, 0, 11> > Month; typedef range<RangePolicyStatic<int, 0, 364> > DayOfTheYear; typedef range<RangePolicyStatic<int, 0, 6> > DayOfTheWeek; typedef range<RangePolicyStatic<char, 'a', 'z'> > LowerCaseLetter; typedef range<RangePolicyStatic<char, 'A', 'Z'> > UpperCaseLetter; typedef range<RangePolicyStatic<char, '0', '9'> > NumberChar; }; by Christopher Diggins licensed under the Boost software license http://www.cdiggins.com http://www.heron-language.com

8 47

Graph Library: Sparse edge sets
by Andy Harrison 26 May '04

26 May '04

I'm new to Boost and I'm trying to determine whether the Graph Library supports sparse edge sets. What I wish to represent is a complete bipartite graph with 2n nodes (n each side) where only nm of the n^2 nodes will be non-zero (n~10,000 and m~20). Can I represent this with the Boost Graph library? Thanks, Andy

1 0

problems with program_options
by Janusz Piwowarski 26 May '04

26 May '04

Hello, In my cvs copy of utf8_codecvt_facet.hpp and utf8_codecvt_facet.cpp files there is CR+CR+LF used as line separator. Also, gcc 3.3.1 (mingw) claims: d:/sources/boost/libs/program_options/src/utf8_codecvt_facet.cpp: In member function `virtual std::codecvt_base::result boost::program_options::detail::utf8_codecvt_facet_wchar_t::do_out(mbstate_t &, const wchar_t*, const wchar_t*, const wchar_t*&, char*, char*, char*&) const ': d:/sources/boost/libs/program_options/src/utf8_codecvt_facet.cpp:229: warning: comparison is always false due to limited range of data type d:/sources/boost/libs/program_options/src/utf8_codecvt_facet.cpp: In function ` int <unnamed>::get_cont_octet_out_count_impl(wchar_t) [with unsigned int s = 4]': d:/sources/boost/libs/program_options/src/utf8_codecvt_facet.cpp:445: warning: comparison is always true due to limited range of data type d:/sources/boost/libs/program_options/src/utf8_codecvt_facet.cpp:451: warning: comparison is always true due to limited range of data type d:/sources/boost/libs/program_options/src/utf8_codecvt_facet.cpp:457: warning: comparison is always true due to limited range of data type Also gcc 3.3.1 generates erros like: C:/CPP/MINGW/include/c++/3.3.1/bits/basic_ios.h: In instantiation of `std::basic_ios<wchar_t, std::char_traits<wchar_t> >': d:/sources/boost/libs/program_options/src/config_file.cpp:145: instantiated from `std::basic_istream<wchar_t, std::char_traits<wchar_t> >' d:/sources/boost/libs/program_options/src/config_file.cpp:145: instantiated from here C:/CPP/MINGW/include/c++/3.3.1/bits/basic_ios.h:67: error: no type named ` pos_type' in `struct std::char_traits<wchar_t>' I found pos_type is defined for char_traits<wchar_t> specialization if _GLIBCPP_USE_WCHAR_T is set, but os_defines.h sets _GLIBCPP_USE_WSTRING only. Is it mingw related problem? Regards, Janusz

2 5

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