- Boost - lists.boost.org

[Test] Intel 8 seems to need workaround
by Joaquín Mª López Muñoz 27 May '04

27 May '04

Linux regression tests seem to indicate that the workaround for Intel in class_properties.hpp should be extended to cover ICC 8.0 as well: 146c146 < #if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND( __COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 700 ) --- > #if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND( __COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 800 ) 160c160 < #if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND( __COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 700 ) --- > #if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) || BOOST_WORKAROUND( __COMO__, <= 0x433 ) || BOOST_WORKAROUND( __INTEL_COMPILER, <= 800 ) Warning: this diff has not actually been checked with ICC 8.0, but I'm confident it'll work as the problem looks exactly the same as with ICC 7.0: /boost/head-regression/boost/libs/test/src/unit_test_suite.cpp(224): error #453: protected member "boost::unit_test::class_property<PropertyType>::value [with PropertyType=boost::unit_test::unit_test_counter={unsigned long}]" is not accessible through a "boost::unit_test::readwrite_property<boost::unit_test::unit_test_counter={unsigned long}>" pointer or object p_stages_amount.value = p_stages_amount + 1; ^ Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 15

Re: [Users] Problems with parameterized boost::function based test case
by Gennadiy Rozental 27 May '04

27 May '04

> add( BOOST_PARAM_TEST_CASE( bind( &test_mask, _1, 0x80 ), > parameters_list.begin(), parameters_list.end() ) ) ); > > I get the following error: > > error C2661: 'boost::unit_test_framework::create_test_case' : no overloaded > function takes 4 arguments It all caused by the fact that following fails: void moo( int , int ) { } template<typename T> void foo( boost::function1<void,T> const& f ) { } ... foo( bind( &moo, _1, 1 ) ); Is there way to make it work? Gennadiy.

2 2

Program options library added to CVS
by Vladimir Prus 27 May '04

27 May '04

The program options library is now in CVS. It's integrated with regression tests, and BoostBook generation. I've also updated top-levle index.htm. The regression test results can be seen at: http://tinyurl.com/3bdvp http://tinyurl.com/2x6jo The windows results are not as good as I would have hoped -- though a bit better than 100% of failures I had after initial checking. I'll look into remaining intel problem but borland and mertowerks failures are complete mistery for me -- I'd ask about them separately. Thanks again to everyone who helped with library developement! - Volodya

1 0

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