- Boost - lists.boost.org

Subject: Re: [boost] Re: [prereview request][fsm]
by Simon Meiklejohn 27 May '04

27 May '04

On the subject of Constructors/destructors for state entry/exit- A consideration is that the state object also gets deleted on shutdown (or deletion of the FSM), which is not a state-transition event as such. Entry/Exit functions are more explicitly about state transitions, whereas destructors/constructors make us need to think about state object lifetimes and needlessly constrain implementation down a certain path. Simon

1 0

[Boost-bugs] [ boost-Support Requests-961789 ] dag_shortest_paths.cpp example doesn't compile on MS VC++6.0
by SourceForge.net 27 May '04

27 May '04

Support Requests item #961789, was opened at 2004-05-27 12:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=961789&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: dag_shortest_paths.cpp example doesn't compile on MS VC++6.0 Initial Comment: Trying to run example dag shortest path that came in the download but it won't compile. Just downloaded and installed Boost. This was first attempt to use Boost libraries. Compiling... dag_shortest_paths.cpp c:\boost\include\boost-1_31 \boost\graph\detail\adjacency_list.hpp(1055) : error C2244: 'bidirectional_graph_helper_with_property<Config >::remove_edge' : unable to resolve function overload c:\boost\include\boost-1_31 \boost\graph\detail\adjacency_list.hpp(1057) : error C2954: template definitions cannot nest Error executing cl.exe. dag_shortest_paths.obj - 2 error(s), 0 warning(s) Would appreciate any direction anyone may have. Prethanks, Brian bcollins(a)draper.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=961789&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] [guidelines suggestion] boost-wide debug support
by Ferdinand Prantl 27 May '04

27 May '04

Hi, it think, it is good to be able to turn on debugging for the one library only, at least sometimes, and to to have the debugging output from all. I would not get rid of local debugging macros completely - thy could be defined according to the global presence of BOOST_DEBUG, e.g. Then, one can easily control the full debug output with BOOST_DEBUG or refine the configuration with a separate BOOST_XXX_DEBUG. Do you see it sensible? Ferda > From: Pavel Vozenilek [mailto:pavel_vozenilek@hotmail.com] > > Right now every library enabled and disables internal debug > support individually. Its impossible to do it now from single place. > > > Suggestion for guidelines: > > - If BOOST_NDEBUG is defined then all libraries will switch off any > debug support (asserts, pre- and post-condition checking, > invariants etc). > There would be no exception. > > - If BOOST_DEBUG is defined then all available debug suport > will be switched on. There would be no exceptions. > > - If neither of macros is defined then libraries will behave > as they behave > now - picking their own choice using library specific macros. > This would allow fine grained customization. > > > Enforcing this rule would require quite a lot of effort and > cooperation though. > For example all assert()s would need to convert to BOOST_ASSERT()s. > > /Pavel

2 1

[guidelines suggestion] boost-wide debug support
by Pavel Vozenilek 27 May '04

27 May '04

Right now every library enabled and disables internal debug support individually. Its impossible to do it now from single place. Suggestion for guidelines: - If BOOST_NDEBUG is defined then all libraries will switch off any debug support (asserts, pre- and post-condition checking, invariants etc). There would be no exception. - If BOOST_DEBUG is defined then all available debug suport will be switched on. There would be no exceptions. - If neither of macros is defined then libraries will behave as they behave now - picking their own choice using library specific macros. This would allow fine grained customization. Enforcing this rule would require quite a lot of effort and cooperation though. For example all assert()s would need to convert to BOOST_ASSERT()s. /Pavel

2 2

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

27 May '04

John Nagle wrote: > I think the relationship between "size()" and "capacity()" >has to be such that if "size() < capacity()" you can add a >character. So "capacity()" should not include the trailing >null. Makes sense. > For consistency with "<string>", "size()" can't include >the trailing null. This applies for both basic_string::size() and strlen( s ). > The big question is whether the size specified in the >declaration (as in "char_string<80>") includes the >trailing null. > > I don't want to express an opinion on this until >I've had some sleep. I can think of good arguments >for both sides. I have modified the sandbox implementation to make it easy to switch between the two models; it is currently using the 2nd model (adding space for the null). One possibility is putting the choice of models as a template parameter (e.g. bool need_null -- see comments in the sandbox code for an implementation), that way the decision is up to the programmer and not the library implementor. >Reece Dunn wrote: > >>John Nagle wrote: >>>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 _________________________________________________________________ Best Restaurant Giveaway Ever! Vote for your favorites for a chance to win $1 million! http://local.msn.com/special/giveaway.asp

3 3

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

27 May '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Rob Stewart wrote: > > >* 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 did mean zero-capacity. I didn't look at your implementation >at this point, but I did notice that John's class declares a size >N array, so for N == 0, his would fail to compile. Is the same >true of yours? yup. With mine, you'll also get an additional error, e.g.: fixed_string.hpp(101) : error C2039: 'value' : is not a member of 'boost::fixed_string<n>::zero_buffer_error' Is there any reason you'd want a zero-capacity buffer? > > >* 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 > >Fine, but there should only need to be one test per call to >at(). If size() can never exceed capacity, by enforcing >invariants elsewhere, then at() only needs to check that the >index doesn't exceed size(). But the standard specifies that at will throw if i > size(), but operator[] does not. The i > capacity() check in the implementation is a sanity check for operator[] and the real at function [note: I will change the name as suggested to prevent hiding]. Therefore it is technically redundant for at, but needed for []. I could supply an additional function (adding to those that need to be implemented by the string provider) or add a i > capacity() check on operator[] (deviating from the standard, but providing a sanity check). >If you're not going to implement get_allocator(), then it should >be in basic_string_impl and shouldn't be among the requirements >levied upon derivates. ok. Do you have a way to do this? > >From your fixed_string.hpp: > if( l == npos ) l = StringPolicy::length( s ) + 1; This is referring to a char_traits policy (as it operates on strings): template< size_t n, typename CharT = char, class StringPolicy = std::char_traits< CharT > > class fixed_string; The basic_string_impl used StringPolicy for the Derived type (now renamed to Derived) because it was based around flex_string. Sorry for the confusion. > > I am actually interested in both. The feedback is appreciated and I will >use > > it to improve the code. > >I'm starting to wonder if it would be good to reach some >consensus as to which approach is better, by some definition of >"better," so that the two of you can collaborate or one can stop >work. I'm not certain we've reached that point, but it may be >wise to write a common set of tests that you both can run so that >performance can be compared (memory and speed) and binary size >can be assessed. Given the adherence to std::basic_string's I/F, >both classes should work with the same tests, and usability comes >down to non-interface issues. I agree. Although John's implementation does not yet fully implement the basic_string interface. Mine doesn't either, but mine only lacks swap and get_allocator (unless I have missed something). > > 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, > >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. It would be easy to make it usable like it currently is: template< size_t n, typename CharT = char, class Traits = std::char_traits< CharT > > class fixed_string: public detail::basic_string_impl< detail::fixed_string_impl< n, CharT, Traits >, ... > { public: // constructors }; It's just that it means that you need to do this for every string implementation. Or you could use the template typedef hack, so it would be: fixed_string< 10 >::type str; but this looks odd, especially to novice users or people who don't have experience with template metaprogramming. This was one of the motivations for my approach as opposed to the flex_string approach. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

3 5

[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