- Boost - lists.preview.boost.org

including external libraries
by Andreas Beyer 28 May '04

28 May '04

I am using boost with mingw. How do I tell bjam to bind with an additional (non-boost) library? In my case I would like to bind msvcp60.dll or libmsvcp60.a into my project. The latter file is in mingw's lib-path. Thanks, Andreas

2 1

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

28 May '04

Hmm.. (spent some hours doing some more digging on this). I write a managed app, yet my dtor is called.. ok, so this is not a question for boost. I have not been able able to find anything in the MS docs as to "why" RAII is working managed, this goes against everything I have heard\understood. """""""""""""""""" -----Original Message----- From: Gregory Colvin [mailto:gregory.colvin@oracle.com] Sent: Wednesday, May 26, 2004 6:02 PM To: boost(a)lists.boost.org Subject: Re: [boost] Re: [prereview request][fsm] If RAII is broken by "Managed C++" then "Managed C++" is broken. On May 26, 2004, at 6:22 PM, Brian Braatz wrote: > (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? """"""""""""""""""

3 2

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

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

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

RE: [boost] Bang for the buck (reducing warnings)
by Rozental, Gennadiy 24 May '04

24 May '04

> Would someone like to commit this fix, please? Ok. Will do tonight. Gennadiy.

1 0

Bang for the buck (reducing warnings)
by Marshall Clow 24 May '04

24 May '04

I found that adding one line to "boost/libs/test/src/unit_test_log.cpp" reduced the number of warnings in the Mac regression test by 80% Here's the change: >diff -r1.22 unit_test_log.cpp >318a319 > > case invalid_log_level: Here's the warning (over and over again!): /Users/marshall/boost/boost/libs/test/src/unit_test_log.cpp:320: warning: enumeration value `invalid_log_level' not handled in switch Would someone like to commit this fix, please? -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> I want a machine that thinks I'm more important than it is, and acts like it. -- Eric Herrmann

1 0

[random] missing seed() method
by Mario Ruetti 24 May '04

24 May '04

Hi I sent this message already some month before. I made some corrections to the boost random library because some generators don't fulfil the wg-21 specifications about the seed() method. I add the missing seed() methods to the following generators * linear_congruential * linear_feedback_shift * additive_combine * inversive_congruential * discard_block * shuffle_output Greetings Mario Index: linear_congruential.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/random/linear_congruential.hpp,v retrieving revision 1.15 diff -r1.15 linear_congruential.hpp 219c219 < void seed(int32_t x0) { lcf.seed(cnv(x0)); } --- > void seed(int32_t x0=1) { lcf.seed(cnv(x0)); } Index: linear_feedback_shift.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/random/linear_feedback_shift.hpp,v retrieving revision 1.7 diff -r1.7 linear_feedback_shift.hpp 83c83 < void seed(UIntType s0) { assert(s0 >= (1 << (w-k))); value = s0; } --- > void seed(UIntType s0 = 341) { assert(s0 >= (1 << (w-k))); value = s0; } Index: additive_combine.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/random/additive_combine.hpp,v retrieving revision 1.5 diff -r1.5 additive_combine.hpp 62a63,68 > void seed() > { > _mlcg1.seed(); > _mlcg2.seed(); > } > Index: inversive_congruential.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/random/inversive_congruential.hpp,v retrieving revision 1.6 diff -r1.6 inversive_congruential.hpp 63c63 < void seed(IntType y0) { value = y0; if(b == 0) assert(y0 > 0); } --- > void seed(IntType y0 = 1) { value = y0; if(b == 0) assert(y0 > 0); } Index: discard_block.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/random/discard_block.hpp,v retrieving revision 1.7 diff -r1.7 discard_block.hpp 52a53 > void seed() { _rng.seed(); _n = 0; } Index: shuffle_output.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/random/shuffle_output.hpp,v retrieving revision 1.6 diff -r1.6 shuffle_output.hpp 65a66 > void seed() { _rng.seed(); init(); } -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info

2 1

Latest ScopeGuard
by Max Khesin 24 May '04

24 May '04

Hiall, I recall there have been sevral attempts at a boostified version of Andrei A. ScopeGuard. I want to start using this functionality and was wondering a) if there is any consensus about best/most boost-consistent implementation b) if there is there is a version in the library approval pipeline (or some definite plans for including this functionality in boost) thanks, max. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

4 5

RE: [boost] STL algorithm for containers (was Re: Re: boost/test/ detail/algorithm.hpp: request forpromotionand/or fast review)
by Max Khesin 24 May '04

24 May '04

There has been an attempt to do something like that here (looks somewhat useful, but far from being 'boosified): http://userpages.umbc.edu/%7Ebcorfm1/easystl.zip Stated goal of this library (from http://userpages.umbc.edu/~bcorfm1/software.html) EasySTL. A supplemental library to the C++ Standard Template Library (STL) that has three main goals. * Eliminate iterators from function calls (where possible). * Enable functional programming by modifying copies of passed containers instead of modifying containers in-place. * Introduce high-level functions (like those in Lisp or Python) for string, file and container manipulation. This library has been tested with Visual C++ .NET only. (I've started moving over to VC++.NET wholeheartedly as their template and STL support is much better now.) m > > Gennadiy Rozental wrote: > > > Why don't we provide container versions of all stl algorithms: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

Re: [boost] Re: class properties: requestforpromotionand/orfastreview.
by Reece Dunn 24 May '04

24 May '04

Peter Dimov wrote: >Reece Dunn wrote: > > Peter Dimov wrote: > >> As a relatively simple example, consider a pair of integers (x, y) > >> that has an invariant of x*x + y*y = 25, and try to move from (3, 4) > >> to (4, 3) by using the X and Y properties. > > > > Since the invariant is on both variables, neither can be set > > independant of each other, since you'd assume that changing one would > > invalidate the invariant. Therefore, the properties must be > > *readonly* to prevent modification. You'd have a function to set both > > values at the same time (e.g. moveto). > >Exactly. Which is the C++ model: int x() const, int y() const, void >set(int, >int). Some purists even omit the set(): p = point(4, 3); > >You can, of course, use "read only properties" instead of x() and y() but >this changes nothing but syntax, not necessarily for the better, I might >add. It all depends on what you are using the properties for. I use them regularly when dealing with MS COM objects where the interfaces use get/set methods to interface with the underlying object. So you can use them more intuitively (especially when coupled with smart pointers, exceptions and variant/BSTR helpers): com::msxml::XMLDOMNode node = ...; std::cout << node.nodeName << " = " << node.nodeValue << '\n'; which would look very ugly without properties! Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

[Boost.Test] New testing procedure?
by David Abrahams 24 May '04

24 May '04

According to http://tinyurl.com/3f32c tests have been failing (IIUC for several days if not longer) because of protected/private access violations in the test library. See the end of http://tinyurl.com/35ole for details. IMO this situation is unacceptable, and I'm looking for practical solutions. Problems with the Boost.Test affect our ability to get meaningful feedback on the state of other libraries. If Gennadiy can't test on more compilers before checking in, and respond faster to problems introduced in its source, and if library authors genuinely find Boost.Test useful, maybe we need to move to a different model wherein the test library's own tests are run on a CVS branch of the code (?) so that Gennadiy can see and deal with his problems before they are merged into the main trunk and break everything else? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

3 2

Safe to combine boost asinh and boost interval?
by Antony Searle 24 May '04

24 May '04

Hi, >From what I can make out of their respective implementations, the interval library assumes that asinh (when it exists) produces values consistent with the floating point rounding mode (i.e. rounding up or down as requested). The boost implementation of asinh doesn't seem to take account of the rounding mode like this [for x < 0 it returns -asinh(-x), which will be rounded the wrong way]. Does this mean that the inclusion guarantee is violated when combining boost interval and boost asinh? Thanks, Antony Searle antony.searle(a)anu.edu.au

3 3

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

24 May '04

Rob Stewart wrote: >From: "Reece Dunn" > > Rob Stewart wrote: > > >From: "Reece Dunn" > > > > > > > > Currently, this implementation is missing iterator support (and thus >all > > > > basic_string functionality that relies on begin(), end(), etc). This >is > > > > because I am wondering how to map them from the basic_string adaptor >to > > >the > > > > implementation (knowing that you cannot have const and non-const >virtual > > > > functions). > > > > > >Since when can you not have const and non-const virtual > > >functions? > > > > Let me rephrase: > > > > class char_string > > { > > virtual iterator begin() = 0; > > virtual const_iterator begin() = 0; // oops! begin already in >vtable!! > > }; > >I'm still missing something. Why would you want a non-const mf >to return the const iterator type? That was a typeo! > class char_string > { > virtual iterator begin() = 0; > virtual const_iterator begin() const = 0; > }; That is what I was referring to. You need to change the name of the const version if you are to allow virtual functions. > > > > I have two possible solutions: > > > > [1] name the const versions cXXX (cbegin(), crend(), etc.) -- the > > >problem > > > > with this is that you have 8 virtual functions! > > > > I was meaning to modify the above to: > > > > class char_string > > { > > virtual iterator begin() = 0; > > virtual const_iterator cbegin() = 0; // ok - cXXX variant > > }; > > > > >You'd have those same eight variations with const and non-const > > >virtual functions. > > > > That's the problem -- too many virtual functions. > >But if you need all eight variations, then you need eight virtual >functions. Is it that you're trying to minimize what the derived >class must implement for the adaptor to work? Even if that's the That is indeed what I am trying to do. >case, because the const and non-const functions return different >types, you can't have the derived class implement a const >implementation function that the adaptor can use to provide both >const and non-const interface functions. So what am I missing? Nothing. You do indeed need two functions: iterator iter_offset( difference_type ); const_iterator const_iter_offset( difference_type ) const; these can be used to implement the 8 iterator functions like this: begin() const = const_iter_offset( 0 ); begin() = iter_offset( 0 ); end() const = const_iter_offset( size()); end() = iter_offset( size()); rbegin() const = const_reverse_iterator( const_iter_offset( size())); rbegin() = reverse_iterator( iter_offset( size())); rend() const = const_reverse_iterator( const_iter_offset( -1 )); rend() = reverse_iterator( iter_offset( -1 )); Regards, Reece _________________________________________________________________ Get a FREE connection, FREE modem and one month's FREE line rental, plus a US or European flight when you sign up for BT Broadband! http://www.msn.co.uk/specials/btbroadband

3 3

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

24 May '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Nothing. You do indeed need two functions: > > iterator iter_offset( difference_type ); > > const_iterator const_iter_offset( difference_type ) const; > >Why? This is perfectly valid C++: > > iterator iter_offset(different_type); > const_iterator iter_offset(different_type) const; > >So is there something in how you want to use them that precludes >your overloading them that way? No. I was not aware that it is possible to do this. I have now adopted struct char_string { ... virtual iterator iter_offset(different_type) = 0; virtual const_iterator iter_offset(different_type) const = 0; }; into my implementation. Q: Since the above is valid C++, is the following?: virtual void myfn( char ) = 0; virtual void myfn( int, bool ) = 0; Because I had assumed that you could not do this, since (1) I haven't read the standard that properly, I have mainly focused on learning from other books (like Stroustrup, 3ed) and (2) I haven't seen any code that uses virtual functions like char_string above or my question. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

5 6

program_options not detecting invalid options
by Neal D. Becker 24 May '04

24 May '04

Not sure what's causing it, but here's what happens: /Test9a --doCancel=0 -e 3.5 --ampl1=0 --ampl2=-300 --freqStep=1.563e-4 --randomFreq=0 --cheatFreq [program running with no complaint...] But --cheatFreq is not a valid option.

2 1

Re: [boost] Re: class properties: request forpromotionand/orfastreview.
by Reece Dunn 24 May '04

24 May '04

Peter Dimov wrote: >It doesn't matter. Properties represent degrees of freedom. They don't >describe dependent data well. > >As a relatively simple example, consider a pair of integers (x, y) that has >an invariant of x*x + y*y = 25, and try to move from (3, 4) to (4, 3) by >using the X and Y properties. Since the invariant is on both variables, neither can be set independant of each other, since you'd assume that changing one would invalidate the invariant. Therefore, the properties must be *readonly* to prevent modification. You'd have a function to set both values at the same time (e.g. moveto). class coord { private: int x, y; public: inline int get_X(){ return( x ); } inline int get_Y(){ return( y ); } inline void moveto( int x_, int y_ ) { assery(( x_ * x_ ) + ( y_ * y_ ) == 25 ); // invariant x = x_; y = y_; } public: // data access property_readonly< int, &get_X > X; property_readonly< int, &get_Y > Y; public: // ... }; Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Re: PING: Lambda Documentation Problem
by Stephan T. Lavavej 24 May '04

24 May '04

[David Abrahams] > What *any* book other than the standard says has no bearing > on whether a DR is appropriate. Yes, of course. Very well. Though the Standard is clear to me, apparently it's not clear to everyone, and it should be. So here is a proposed DR. Comments (particularly on the Proposed Resolution)? Once we get this DR into shape, would you like to pass it on to the Committee? ---BEGIN DR--- Library DR [FIXME]. May the functor given to for_each modify its argument? Section: 25.1.1 [lib.alg.foreach] Status: Open Submitter: Stephan T. Lavavej Date: 24 May 2004 for_each is classified (without explanation) in [lib.alg.nonmodifying], "25.1 Non-modifying sequence operations". Every other algorithm in [lib.alg.nonmodifying] is "really" non-modifying in the sense that neither the algorithms themselves nor the functors given to them may modify the sequences or elements in any way. The guarantee about the algorithms is provided by their descriptions (and implicitly by their classification in [lib.alg.nonmodifying], which is the subject of this DR), while the guarantee about the functors is provided by the fact that they are all Predicate or BinaryPredicate. In contrast, for_each takes a Function. Library DR 290 complains that there are no requirements placed on this Function; this DR complains that there are no guarantees given about what the Function may do. I believe that the intent of the Standard in classifying for_each as a "non-modifying sequence operation" is to say that the algorithm itself does not modify the sequence it is given (in contrast to "mutating sequence operations" such as replace, where the algorithm itself does the modifications), but that the Function given to for_each may modify the elements it operates on. This is supported by the bottom of Page 524 of The C++ Programming Language Third Edition, fifth printing or higher (or any printing of Special Edition). The problem is that no guarantee is given that the Function may modify elements it operates on, so conceivably an implementer could write for_each in such a way as to disallow this, or a programmer may avoid using for_each with element-modifying functors because of the belief that implementers have such latitude. Proposed Resolution: Add the following sentence to the Notes in 25.1.1 [lib.alg.foreach]: "/f/ may apply non-constant functions through the dereferenced iterators it is applied to." The phrasing here is chosen to be consistent with [lib.alg.foreach] Effects ("Applies /f/ to the result of dereferencing every iterator...") and the opposite of the restrictions placed on Predicate in [lib.algorithms] ("/pred/ shall not apply any non-constant function through the dereferenced iterator"). I believe that this guarantee coupled with the requirement proposed in Library DR 290 covers all cases of what the Function passed to for_each may and may not do. Alternatively, phrasing based on the more detailed explanation in The C++ Programming Language Special Edition could be used (it explains that when an element-modifying functor is used, the sequence has to be non-const; I believe that the above phrasing implies this). This guarantee merely clarifies what I believe is already the intent of the Standard. It is related to Library DR 290 but is independent of it, and neither DR relies on the other. ---END DR--- The DR is probably unnecessarily verbose. Stephan T. Lavavej http://nuwen.net

2 1

input_iterator_facade (was: Re: [iterator facade] Why is dereference const?)
by Gennadiy Rozental 24 May '04

24 May '04

Hi, Here is the input_iterator_facade template (similar in nature to Vladimir's eof_iterator ) I am using in Boost.Test development: namespace detail { template<typename T> struct value_type_ident { typedef T value_type; }; template<typename T> struct ref_type_ident { typedef T reference; }; } // namespace detail template< typename ImplPolicy, typename Derived = mpl::void_, typename ValueType = mpl::void_, typename Reference = mpl::void_> class input_iterator_facade : public iterator_facade< typename mpl::if_<mpl::is_void_<Derived>,input_iterator_facade<ImplPolicy>,Derived>:: type, typename mpl::if_<mpl::is_void_<ValueType>,ImplPolicy,detail::value_type_ident<ValueT ype> >::type::value_type, forward_traversal_tag, typename mpl::if_<mpl::is_void_<Reference>,ImplPolicy,detail::ref_type_ident<Referenc e> >::type::reference> { public: // Constructor explicit input_iterator_facade( ImplPolicy const& p = ImplPolicy() ) : m_policy( p ) { m_valid = m_policy.initialize(); increment(); } //!! copy constructor/assignment - should we make rhs invalid after copy?? //!! do we need reset method? protected: // provide access to the derived // Data members ImplPolicy m_policy; private: friend class iterator_core_access; // iterator facade interface implementation void increment() { if( m_valid ) m_valid = m_policy.get(); } bool equal( input_iterator_facade const& rhs ) const { return !m_valid && !rhs.m_valid || m_valid && rhs.m_valid && m_policy.equal( rhs.m_policy ); } reference dereference() const { return m_policy.dereference( m_valid ); } // Data members bool m_valid; }; See full versions with extra comments here: http://tinyurl.com/2x69z There is one specific iterator implemented that used this template located in the same directory (more coming). I actually combine new CRTP and old policy technique here, for later allows me to implement more functionality in common code. Is there interest in adding this to the family of iterator helpers? Or could I move it in boost namespace for convenience? Gennadiy.

3 4

Re: [boost] Re: [Boost.Test] New testing procedure?
by Robert Ramey 24 May '04

24 May '04

Jeff Garland wrote: > Well as soon as Robert wants to run the torture test he's going to get it > at all sites if he controls it via his Jamfile. So we need some > boost-wide option to define these variations. Hopefully my other email > clarifies the idea. My concern was raised base on the following scenario: a) I get things working to taste on the 3 or 4 compilers I have installed. b) I check in to CVS c) Test is run - takes a long time d) But shows some problems in the 5 compilers I don't have e) Now I start to fix stuff - more or less one compiler at a time f) Now much computer resource are used to no good purpose. I can't stop the test from running on the compilers that I know will fail anyway. g) Now my interest shifts to another compiler and a whole different set of wasted effort is done. .... q) Now everything is spiffy r) test runs - but only those tests that are dependant on something that has changed. The situation is tolerable - until something changes that changes the library - then caos from q onward the problem might be manageable if BJAM was could manage dependencies from are particular x.hpp -> y.cpp -> test.cpp. But as it is now, if one *.cpp file in the library has to be rebuilt, all the test that depend on any portion of the library have to be run. I realize this is an unrealistic hope but we're allowed to dream. So checking in a new Jamfile to customize at test is OK but it still leaves me with doing all the compilers even though I know it's a waste of time. Robert Ramey

3 2

RE: Re:[boost] [Boost.Test] New testing procedure?
by Roman Yakovenko 24 May '04

24 May '04

Aleksey Gurtovoy wrote: > a) incremental cylces, with a full rebuild once a week or > something similar > (here at Meta, for instance, are currently doing full > rebuild on every > cycle); > > b) distributed testing of libraries, with the following > merging of results > into a single report. I agree with Aleksey. I am using boost a lot in my work. So I would like to give something back. I can test CVS version of boost on WinXP + compiler of MS Visual Studio 7.1. And at home on "Fedora Core 2" gcc 3.4. The question is what should I send back? Roman

2 1

[Boost-bugs] [ boost-Support Requests-959156 ] boost for ARM platform?
by SourceForge.net 24 May '04

24 May '04

Support Requests item #959156, was opened at 2004-05-23 16:50 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=959156&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost for ARM platform? Initial Comment: mailto:peter.mason@dilithiumnetworks.com is writing ... Sorry if this has been discussed already, but I've only just joined. Something I'm building under an ARM toolchain/devkit requires Boost functionality, and thus needs a porting of boost to ARM platforms. I'm not even familiar with the build tools used to build Boost, so it's a daunting task. Can someone please tell me that such a port has been done already and it's available at XXX? If not, then I'd appreciate some options and guidance. Thanks in advance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=959156&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

2 1

wrap_stringstream status
by Gennadiy Rozental 23 May '04

23 May '04

Hi, I finished anothher round of modification in wrap_stringstream makeing it more generic (actually it now template basic_wrap_stringstream and specializations). Is there still interest in putting it uner boost/utility and do we need a fast review for it? If yes I will prepare doc page. Gennadiy.

3 6

Re:[boost] [Boost.Test] New testing procedure?
by Robert Ramey 23 May '04

23 May '04

Dave Abrahams wrote: > maybe we need to move to a > different model wherein the test library's own tests are run on a CVS > branch of the code (?) so that Gennadiy can see and deal with his > problems before they are merged into the main trunk and break > everything else? Clearly, test the test (meta-testing ?) is a special category. I needs to be staged to be tested itself before being used to test other stuff. I believe boost testing is going to be an issue in the near future do the fact that testing time is getting longer and longer and longer. I believe we will have to move to an "on demand" model for most testing while reserving "total coverage" testing for just prior to release. Although this wouldn't definitively address the issue raised it would help. As only those libraries currently being tested would suffer due to dependencies on other code. It would also save lots of time and permit test time to keep from becoming an issue. Robert Ramey

5 17

IMPLICIT_CAST macro
by Gennaro Prota 23 May '04

23 May '04

Hi, I was grep'ing for my name in the boost repository in order to update any old license reference and found the following definition in implicit_cast.hpp: // Macro for when you need a constant expression (Gennaro Prota) #define BOOST_IMPLICIT_CAST(dst_type, expr) \ ( sizeof( implicit_cast<dst_type>(expr) ) \ , \ static_cast<dst_type>(expr) \ ) This wasn't the form I submitted though, as the comma operator isn't allowed in a constant expression and I remember pointing out on this list that this was a case where it would be useful :) Maybe the above was simply copied from this post: http://lists.boost.org/MailArchives/boost/msg42102.php where I was saying that it *doesn't* work and that I had to use the check_helper<> template. Genny.

2 5

Re:[boost] Re: [Boost.Test] New testing procedure?
by Robert Ramey 23 May '04

23 May '04

David Abrahams wrote: > We currently already have a way of expressing that "known to not work on X > compiler" idea in the regression system. We could make the build > system smart about it. I haven't seen that. That would be helpful. How can I specify that its pointless to run tests on a particular compiler. Probably simpler, though, you could just put something in one of your library headers that said: > #if BOOST_WORKAROUND(compiler1) || BOOST_WORKAROUND(compiler2) || ... > # error doesn't work yet > #endif Actually I've done something similar for systems whose support for wide character i/o is insufficient. Its sort of OK but the the test show up as all failures which is slightly miss leading. At it doesn't take all that long but I'd prefer just to skip it. >> from q onward the problem might be manageable if BJAM was could manage >> dependencies from are particular x.hpp -> y.cpp -> test.cpp. > Of course it can and does. >> But as it is now, if one *.cpp file in the library has to be >> rebuilt, all the test that depend on any portion of the library have >> to be run. >Of course they should. >> I realize this is an unrealistic hope but we're allowed to dream. >I clearly don't know what you're talking about here. What I mean is: Test.cpp only depends on module1.cpp which Is in the library. The functions in module1.cpp can only be accessed by including header1.hpp in the test either directly or indirectly. Suppose module2.cpp gets recompilied. This provokes a rebuild of the library which provokes a rebuild of test.cpp and rerunning of the test. This occurs even though this isn't necessary as module1.cpp - the only module the test depends upon - hasn't changed. In other words. The dependency granularity is the library - not the modules within the library. My understanding comes from study of BJAM and observation of my system when I make a change. I would be very pleased to find out that I'm wrong about this. So let me see if I have this right. a) I can check in a different version of runtest that will set my "testing level" appropriate for the state of the library and change it as necessary. b) I can specify which compilers should be included/excluded from the test. (somehow - I don't know how yet) c) If something changes that effects any code/header module used by the library - everything is going to be rebuilt and tested regardless of the dependency of the particular test. OK - given a and b I think this can be made to work with relatively little difficulty. >From another post: >> The same set of tests should be runnable by the regression tester >> and hence associated with the column in the results table. So >> something like: >> >> VC7.1 VC7.1 VC7.1 etc >> release release debug >> dll static dll >> >> test1 Pass fail Pass >> test2 Pass Pass Pass >> ... >> >> Then basic/complete option controls the number of tests run. >That's outta hand, IMO. If it's worth having options, let's keep > them simple. The compiler_status program is a good start but I have a real need for something that can produce the table above driven by a command line configuration string. So much so that that I'm almost up for writing it myself using the current compiler_status program as a staring point. It may happen. My experience is that when I have the debug version all running spiffy, I always have some weird issue with release mode which is compiler dependent. Usually its related to the compiler/linker dropping stuff it doesn't think needs to be instantiated. In practice, once its fixed, it doesn't break until some really major change occurs. So my policy will be to run the relase mode test just once in a very long while. Robert Ramey

2 1

RE: [boost] class properties: request for promotion and/or fast review.
by Reece Dunn 23 May '04

23 May '04

Gennadiy Rozental wrote: >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). Have you had a look at SC22/WG21/N1615 (C++ Properties -- A Library Solution) by Lois Goldthwaite (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf)? Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

Re: PING: Lambda Documentation Problem
by Stephan T. Lavavej 23 May '04

23 May '04

[Jaakko Jarvi] > for_each is the only one that takes a 'free-form' function > object. Yes, as I said, it is "special". > If side effects are allowed, I don't understand why for_each > is classified as a non-modifying sequence. It sure can modify > the elements of the sequence. What is (philosophically) > different in the way that, say, std::replace, modifies the > elements of the sequence? Because for_each() does not do the modifying, the /functor/ does the modifying. Contrast replace(), which does the modifying itself. > Do you know what Bjarne is referring to with the 'recent > standards resolution'? I have E-mailed him asking for a clarification. > The sgi STL documentation (predecessor of what is currently > in the standard) ... is wrong wrt the final Standard. > This must be the initial reason why for_each is in the > category of non-modifying sequences. It may have been that this was the intent pre-Standardization. > A DR would be in place: either explicitly mention that > side-effects (of the sort that modify the values in the > sequence) are not allowed, or move for_each to mutating algs. > Volunteer to raise that and provide wording? I don't believe that a DR is necessary given the phrasing in TC++PL, which is reasonably authoritative (though lacking Standard force). Stephan T. Lavavej

2 1

[boost.test] feature request - random order of testing
by Pavel Vozenilek 23 May '04

23 May '04

Would it be possible to add ability to execute tests in random order, instead of as they are added into suite? Example: test_suite* init_unit_test_suite(int argc, char * argv[]) { test_suite* tests = BOOST_TEST_SUITE("..."); tests->add(BOOST_TEST_CASE(&test1)); tests->add(BOOST_TEST_CASE(&test2)); return tests; } Here test1() will be always executed before test2(). This behaviour may hide errors. It would be nice to have: - possibility to say: now execute test in random order, - if error happens framework would print out seed for random, - ability set seed manualy is needed to be able to repeat problem. (If such feature is already present in library my weak reading skills didn't spot it.) /Pavel

3 4

[Serialization] Errors when compiling using GCC 3.4
by Allen Yao 23 May '04

23 May '04

I just updated my gcc from 3.3.3 to 3.4, and found that the serialization17 and serialization18 cannot compile. There are many error messages, some of them seem to caused by lack of "typename", others are very strange, for example, about using boost::noncopyable. Does someone try serialization library on GCC 3.4? Can it be compiled? I suspect I am missing something. Otherwise, I would like to try to "fix" the "bugs" myself. Best regards.

1 0

Re: [boost] Re: [Boost.Test] New testing procedure?
by Reece Dunn 23 May '04

23 May '04

Jeff Garland wrote: >And that's today. Consider during the next couple months 3-4 new libraries >are pending to be added. Serialization tests alone dramatically increase >the >length of the time to run the regression if we always run the full test. >What >will happen in a year when we have say 10 new libraries? > >Robert and I have believe something will need to be done. We've tried to >start a discussion, but no one responded: > >http://lists.boost.org/MailArchives/boost/msg64471.php >http://lists.boost.org/MailArchives/boost/msg64491.php I don't know how feasable this would be, but you might also want to consider library dependancies so that if you modify the iterator adaptors library you can pull a list of tests that need to be re-run because the associated libraries use iterator adaptors. This would reduce the number of tests that need to be performed on each cycle, but you'd need some way of archiving the results and only updating the ones that are re-run. When testing a new platform/compiler/configuration, you can tell the test suite to run all the tests for that setup, but for the others (where it has already been run) it will operate as above, unless an explicit request for the full set of tests is provided (allowing for, say, the full set to be performed weekly while the dependant tests are performed daily/every 12 hours). I like the idea of specifying the test level (basic, torture, concept). Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

3 6

RE: [boost] Re: [Boost.Test] New testing procedure?
by Reece Dunn 23 May '04

23 May '04

David Abrahams wrote: >"Jeff Garland" <jeff(a)crystalclearsoftware.com> writes: > > > On Sat, 22 May 2004 13:18:41 -0400, David Abrahams wrote > >> > I like the idea of specifying the test level (basic, torture, >concept). > >> > >> I am opposed to the idea of requiring humans to initiate the right > >> tests, at least without proof that mechanically-initiated tests are > >> unworkable. I don't think we've proven that yes. > > > > They shouldn't be human initiated -- just configured to one level or >another. > > Now obviously a human would need to intervene to reset the level, but >that > > would only be in the case of ramping up to release, adding a new >library, > > adding a new compiler, or a specific author request. I believe this >would be > > rather infrequent. I was not suggesting that the basic/full tests be initiated by a human. This is what shell scripts are for: full-tests.sh and basic-tests.sh! Then tell a computer to run full-tests.sh once a week and basic-tests.sh daily. > > Basically, right now we have no way of setting up a Jamfile that can >satisfy > > the need to have full up tests for new compilers, etc and a basic set of >quick > > tests...short of replacing the Jamfile all the time. > >I don't see that as a need, or neccessarily an advantage. Only >outdated tests get run. > >That said, of course we do have a way: > > # foo.jam > > if $(Not_Defined) > { > # torture tests go here > } > >In what way is commenting out the "if" line and checking in the >jamfile significantly different from other mechanisms one might use to >alter the set of tests that get run? Is it possible to add the level as a parameter like how you can configure static/dynamic linking, e.g.: test basic : basic.cpp : <level>basic ; test complete : complete.cpp : <level>torture ; # basic-tests.sh bjam ... basic-test # full-tests.sh bjam ... full-test Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 2

scoped_ptr - custom deleter?
by Robert Ramey 23 May '04

23 May '04

Question: Shouldn't scoped_ptr have a constructor of the form: template<class Y, class D> scoped_ptr(Y * p, D d) where D is a custom deleter. Shared_ptr has it. I have a need for this now. This has been raised during a discussion with Martin Ecker re serialization library implementation. Robert Ramey.

1 0

any interest in a producer consumer template?
by Arash Partow 23 May '04

23 May '04

Hi all, I was wondering if there would be any interest in a template library based around producers and consumers. I've developed something already and have a series of working examples, I propose a library that consist of 3 basic entities, a producer a consumer and a hybrid entity called an interchange. the entities themselves will be threaded and will be linked together via a linking mechanism that is itself a base template but which can be extended to provide data transfer between same system processes and threads and also extended versions which provide data transfer over pipes, sockets, serial lines etc.. the idea of the producer-consumer is very simple the producer produces a type of data ie: string, a class, a struct etc.. and a consumer that is instantiated as a consumer of the type will consume the data provided by the producer and do something with it. The interchange entity is a transformation entity, it acts both as a consumer and as a producer, it consumes from a producer or another interchange, and then invokes the user implemented transmute method to convert/munge/process the data from one type to another then sends it to its consumer. Simple class syntax: template < typename OutputType // class IdleProductionPolicy = Policy class for implementing producer's //behavior during idle production periods. > class Producer : public Thread { }; template <typename InputType> class Consumer : public Thread { }; template < typename InputType, typename OutputType // template < typename > class InternalProducer possible future policy > class Interchange : public Thread { }; The link mechanism is a basically a type that supports the common type between a producer and its consumer, it is a one way flow of data, the consumer is signaled when data is ready for it to collect if its asleep it will awake and fetch the data if its doing something else when it comes back to go and wait for the condition from the producer to be signaled it will instantly be awaken and go off and fetch the data off the link. the data on the link or more precisely in the container which resides in the link is made thread safe via mutexes around the add and get methods. A link has a basic get and add functionality but depending what entity is being implemented they will only see it via an interface and hence only be able to invoke 1 kind of method, a producer can only invoke "add" where-as a consumer can only invoke a get, an interchange can invoke both because it is instantiated with both a consumer and producer link interface, but the links are separate for an interchange, because it requires 2 links, one link for the incoming data and one link for the out going data. both link maybes of different types, ie: Producer <string> ----> Interchange <string, AClass> ----> Consumer <AClass> I need some opinions, about whether or not people will find this library useful and hence have it as part of Boost, if so could people give me their opinions about my design, its just a simple first trial run at designing it, i intended for the producers and interchange entities to be policy driven as far as production of data is concerned. I think this library can be used in distributed computing, in network packet assembly, and also for interfacing and passing data up and down threaded software layers. Any advice, opinions would be very much appreciated. Kind regards Arash Partow __________________________________________________ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net A more detailed class syntax and usage is here: template < typename OutputType // class IdleProductionPolicy = Policy class for implementing producer's //behavior during idle production periods. > class Producer : public Thread { private: typedef vector < OutputType > TypeVector; typedef ProducerLink < OutputType > TypeLink; public: Producer(TypeLink* _link, unsigned int _minpendbufsize = MIN_PEND_BUF_SIZE, unsigned int _maxpendbufsize = MAX_PEND_BUF_SIZE, unsigned int _id = 0) { }; ~Producer(){}; unsigned int getMinPenBufferSize() { return minpendbufsize; }; unsigned int getMaxPenBufferSize() { return maxpendbufsize; }; void setMinPenBufferSize(int _minpenbufsize = MIN_PEND_BUF_SIZE) { minpendbufsize = _minpenbufsize; }; void setMaxPenBufferSize(int _maxpenbufsize = MAX_PEND_BUF_SIZE) { maxpendbufsize = _maxpenbufsize; }; virtual void setActiveMode(bool state = true) { }; protected: void add(OutputType t) {}; void add(const TypeVector& tlist) {}; virtual bool manufacture()=0; private: void execute() {}; }; template <typename InputType> class Consumer : public Thread { private: typedef vector < InputType > TypeVector; typedef ConsumerLink < InputType > TypeLink; public: Consumer(TypeLink* _link){}; ~Consumer(){}; protected: void get(TypeVector& tlist) { }; void setLink(TypeLink& _link) { }; virtual bool consume()=0; private: void execute(){}; }; template < typename InputType, typename OutputType // template < typename > class InternalProducer possible future policy > class Interchange : public Thread { public: typedef vector < InputType > ConsDataList; typedef vector < OutputType > ProdDataList; typedef ConsumerLink < InputType > ConsLink; typedef ProducerLink < OutputType > ProdLink; public: Interchange( ConsLink* _consLink, // Link from the producer entity ProdLink* _prodLink, // Link to the consumer entity unsigned int _minpendbufsize = MIN_PEND_BUF_SIZE, unsigned int _maxpendbufsize = MAX_PEND_BUF_SIZE, unsigned int _id = 0 // for debugging purposes ) { }; ~Interchange() {}; unsigned int getMinPenBufferSize() {}; unsigned int getMaxPenBufferSize() {}; void setMinPenBufferSize(int _minpenbufsize = MIN_PEND_BUF_SIZE) { }; void setMaxPenBufferSize(int _maxpenbufsize = MAX_PEND_BUF_SIZE) { }; void setActiveMode(bool state = true){}; protected: void add(OutputType t) { prodLink->add(t); }; void add(const ProdDataList& tlist) { prodLink->add(tlist); }; void get(ConsDataList& tlist) { consLink->get(tlist); }; void setConsumerLink(ConsLink& _link) { consLink = _link; }; void setProducerLink(ProdLink& _link) { prodLink = _link; }; virtual bool transmute()=0; private: void execute(){}; }; Usage would be as follows: class AClass { public: AClass(string str):val(str){} ~AClass(){}; void displa(){cout << val << endl;}; private: string val; }; class MyProducer : public Producer<string> { public: typedef ProducerLink < string > LinkType; MyProducer(LinkType* _link, int minpenbs, int maxpenpbs):Producer<string>(_link, minpenbs, maxpenpbs){}; bool manufacture() { add("abc"); return true; }; }; class MyInterchange : public Interchange<string,AClass> { public: typedef ProducerLink < string > ProdLinkType; typedef ConsumerLink < string > ConsLinkType; MyInterchange( ConsLinkType* _conslink, ProdLinkType* _prodlink, unsigned int minpenbs, unsigned int maxpenbs ):Interchange<string,string>( _conslink, _prodlink, minpenbs, maxpenbs, ){}; bool transmute() { vector <string> slist; get(slist); for(unsigned int i = 0; i < slist.size(); i++) { add(AClass(slist[i])); } add(slist); return true; }; private: }; class MyConsumer: public Consumer<AClass> { public: typedef ConsumerLink < string > LinkType; MyConsumer(LinkType* _link, int mpID):Consumer<string>(_link){}; bool consume() { vector <AClass> alist; get(alist); for(unsigned int i = 0; i < slist.size(); i++) { alist[i].display(); } return true; }; }; int main () { Link < string > link1; Link < AClass > link2; MyProducer myproducer = MyProducer(new ProducerLink <string>(&link1),10,50); MyInterchange myinterchange = MyInterchange(new ConsumerLink <string>(&link1),new ProducerLink <AClass>(&link2),1,10); MyConsumer myconsumer = MyConsumer(new ConsumerLink <AClass>(&link2)); myproducer.start(); myinterchange.start(); myconsumer.start(); while(true) { . . . } return true; }

2 2

MSDN News of the week
by Edward Diener 22 May '04

22 May '04

The news of the week at MSDN, first item, http://msdn.microsoft.com/ mentions Boost. All Boost developers can take a bow and to them I also offer my applause.

1 1

Re:Re: [boost] Re: [Boost.Test] New testing procedure?
by Robert Ramey 22 May '04

22 May '04

Reece Dunn wrote: > I don't know how feasable this would be, but you might also want to > consider library dependancies so that if you modify the iterator adaptors > library you can pull a list of tests that need to be re-run because the > associated libraries use iterator adaptors. This would reduce the number > of tests that need to be performed on each cycle, but you'd need some way > of archiving the results and only updating the ones that are re-run. I thought that's what it already did! Isn't that the whole point of the BJAM system? Is there not a way to "compose" Jamfile(s) into a one so that only dependent tests are run? Just a thought. More food for thought. The serialization library relies on spirit. The current version of spirit (1.8?) doesn't build on older platforms such as VC 6. For me this isn't a problem. For testing on other platforms spirit 1.61 will have to be installed in a "known" place. These kind of testing tweaks can occur inside the runtest.sh but that would inhibit the composition of Jamfiles described above. - maybe this is not a consideration. I recognize that the current testing procedure is exhaustive and that's a good thing. If I were to add exhaustive testing of the serialization library (35 tests * 5 archives (maybe 10) * 2 (debug/release) * 2 (dll/lib) * 8 compilers ) that would be 5600 build and run tests. This would take a while. (I havn't included polymorphic archive versions which would double this). So I'm resigned to the fact that I'm not going to be able to test exhaustively on a continuing basis. I would like to be able to solicite a test for a given combination on demand. Robert Ramey

1 0

boost.css validation
by Gennaro Prota 22 May '04

22 May '04

Hi, the W3C online validator accessible at http://jigsaw.w3.org/css-validator/ gives a warning on our main .css file: Warnings URI : http://www.boost.org/boost.css * Line : 0 font-family: You are encouraged to offer a generic family as a last alternative This looks like a good idea. What about adding 'monospace' as the last choice for both the PRE and the CODE rules? Genny.

2 1

[MPL] Integral constant expressions and MSVC.
by Cromwell Enage 22 May '04

22 May '04

Morning, all. I'm trying to implement a compile-time greatest common divisor metafunction, a key component of which is boost::mpl::modulus_c. Am I correct if I say that the following is typical usage of this class template? #include <iostream> #include <boost/mpl/modulus.hpp> int main() { typedef typename boost::mpl::modulus<int,14,6>::type remainder_type; std::cout << "The remainder of 14 divided by 6 is "; std::cout << remainder_type::value << std::endl; return 0; } MinGW 3.2 accepts this usage, but MSVC 7.1 files the following complaint: ..\..\Libraries\boost\boost\mpl\modulus.hpp(39) : error C2975: 'N' : invalid template argument for 'boost::mpl::integral_c', compile-time evaluatable constant expression expected It seems MSVC doesn't recognize A % B as an integral constant expression. What's the proper way of handling this? Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer

2 2

RE: [boost] Wave/flex_string with VC7.0 + dinkumware (new problem)
by Reece Dunn 22 May '04

22 May '04

Hartmut Kaiser wrote: >Reece Dunn wrote: > > I have this in my implementation if you want to take a look, > > along with > > several other changes to the flex_string implementation. > >Yes please send it to me (perhaps privately). I'll have to make some >changes >anyway, so I'll try to incorporate your fix along the lines. It is available on the sandbox (boost-sandbox/boost/fixed_string/detail/basic_string_impl.hpp). Feel free to incorporate any of my changes. NOTE: My version is still slightly defective because it uses std::allocator< value_type >::pointer for the iterator type, but I aim to fix this at some point. Also, I am wondering how good are flex_string and my basic_string_impl (based on flex_string) at handling rope-like containers and iterators. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

Updating Test Regression for HP-UX
by DY, JERRY U (SBCSI) 22 May '04

22 May '04

How does the Boost Regression Test page for HP-UX aC++ get updated? I have the latest results using aC++ 3.55 compiler (including recent fixes) generated by the run_tests.sh script. The next aC++ patch I'm being told is scheduled to be released this July where the aC++ team hope to include as many fixes as possible. -Jerry

2 1

RE: [boost] Wave/flex_string with VC7.0 + dinkumware (new problem)
by Reece Dunn 22 May '04

22 May '04

Hartmut Kaiser wrote: >Reece Dunn wrote: > > > I reported that VC7 uses the correct implementation of > > reverse_iterator, and that this can be detected via > > BOOST_NO_STD_ITERATOR. Although this compiles, you cannot use > > reverse iterators. > > > > The problem is that the iterator is of the form (const) T *, > > and this fails because there is not a correct implementation > > of iterator_traits (due to a lack of partial template > > specialization) that *is* detected by BOOST_NO_STD_ITERATOR_TRAITS. > > > > The solution would therefore be to - in this case - provide > > an iterator wrapper around a standard pointer so it has the > > correct Iter::value_type, etc definitions. Is there an > > iterator_adaptor that provides this within boost? If not, > > should there be one? I am looking into this and will commit > > the solution to my iterator_adaptor-style implementation > > (sandbox/boost/fixed_string/detail/basic_string_impl.hpp). > > > > NOTE: If you want to add any of my modifications to the Wave > > flex_string implementation, feel free, but be warned that I > > haven't run full tests on it yet and thus there might be bugs > > in it (especially the pod_xxx --> traits_type::xxx, since > > these functions have different parameters). > >Thanks again for pointing that out. I'll have a look at it next week, when >I'm back home. Is this problem specific for VC7 or does it occur on the >VC7.1 platform also? If it's specific, then I would some need from somebody >to fix this, because I don't have it handy to reproduce the problem. Could >you provide a fix for Wave then? It is just a VC 7 problem, because VC 7 does not have partial template specialization. I have a fix now for this: replace std::reverse_iterator< Iterator > with boost::reverse_iterator< Iterator > (I do not have a proper diff): +# include <boost/iterator/reverse_iterator.hpp> // ... - typedef std::reverse_iterator<iterator -#ifdef BOOST_NO_STD_ITERATOR_TRAITS - , value_type -#endif - > reverse_iterator; + typedef boost::reverse_iterator< iterator > reverse_iterator; - typedef std::reverse_iterator<const_iterator -#ifdef BOOST_NO_STD_ITERATOR_TRAITS - , const value_type -#endif - > const_reverse_iterator; + typedef boost::reverse_iterator< const_iterator > const_reverse_iterator; I have this in my implementation if you want to take a look, along with several other changes to the flex_string implementation. Regards, Reece _________________________________________________________________ Get a FREE connection, FREE modem and one month's FREE line rental, plus a US or European flight when you sign up for BT Broadband! http://www.msn.co.uk/specials/btbroadband

2 1

Re: PING: Lambda Documentation Problem
by Stephan T. Lavavej 21 May '04

21 May '04

[Jaakko Jarvi] > I'm reading the standard back and forth and I do not agree > with you. The Standard is not very well written when it comes to this point, yes. However, I am right, and in the course of this E-mail, you will be convinced that I am right. :-> > What do you mean by "inherently mutating sequences"? Algorithms which always modify the sequences that they are given. > Does std::replace inherently modidfy sequences? Yes, because its purpose is to write NewValue in every place that OldValue occurs. In contrast, for_each does not necessarily have to modify sequences, if given a functor that inspects its argument and mutates itself. However, the functor can modify the sequence. This caused me some confusion (I thought, as you do, that conforming implementations could implement for_each in such a way as to disallow functors from mutating the values, and hence that for_each was morally bankrupt) until I read something that cleared it up for me. http://www.cuj.com/documents/s=7998/cujcexp1902langer/ "the function object may produce an effect by modifying the input sequence, and it can produce a useful result by mutating itself in the course of its invocations" for_each is special, because all of the other "non-modifying sequence operations" are /really/ non-modifying. If you are still unconvinced, see Library DR 290, where Angelika Langer (coauthor of the above article) complains that there are insufficient restrictions on for_each's functor. Note that she asks that the functor be required to not invalidate iterators or subranges. The DR is still open, but note that the LWG's response so far is "we think this should be a blanket statement", not "what are you talking about, for_each's functor cannot mutate its argument period, much less invalidate iterators". Finally: http://www.research.att.com/~bs/3rd_printing5.html "pg 524 add at the end of the page: "The for_each() algorithm is classified as nonmodifying because it doesn't explicitly modify a sequence. However, if applied to a non-const sequence for_each() may change the elements of the sequence. For an example, see the use of negate() in 11.9." (recent standards resolution)." If your TC++PL3 is 5th printing or higher (or if it's any printing of Special), you can look on page 524, and there it is. Spoken by the Bearded One himself. Stephan T. Lavavej http://nuwen.net

2 1

Newbie to Regex simple test failure...
by Richard Latter 21 May '04

21 May '04

Hello All, I'm probably missing something obivous here.....So please fogive me if it's a basic error. I am using regex for the first time on MSVC 6 and would like to create a simple function that could pass in a string and an expression to do a regular match on it. I believe I have successfully compiled this library, but I don't understand why either of these simple functions are not working.... bool TestStr (std::string& szExpr, const std::string& szSearch) { bool bResult=false; boost::regex cExpr(szExpr); bResult = boost::regex_match(szSearch, cExpr); return bResult; } or bool TestStr2 (std::string& szExpr, std::string& szSearch) { return boost::regex_match(szSearch, boost::regex(szExpr)); } After debugging these routines, it appears thta the boost::regex declaration fails (at least for the first function) returning a Kernel32.dll exception with some kind of address. The credit card example implies that the search and the regex example I have observed keeps the regex expressions as constansts inside the function, but I would like to be able to parse in my own string Questions? 1. Wht doesn't any of the functions work? 2. Is there a tutorial outside of the regex library I could look at. 3. I would be interested to know if anyone had any POSIX regex examples.... Many thanks in advance, Richard

4 7

bjam - building binaries in one dir
by John Torjo 21 May '04

21 May '04

Hi all, Looking at how bjam makes its great subdirs - when creating binaries for a library, I see that each libs/dlls is put in its own sub-directory. As I see, anyway, the binary name already indicates the compiler + release type + etc. And all the library linkinage is solved automatically (for instance, if I need boost_date_time-vc71-mt-gd-1_31.lib, it will automatically be added to my dependencies). I would like however for all binaries for a specific library to be built in the same dir. This way all I need to remember is the directory where the library binaries are, and include that in my 'Additional library directories'. I know that the current behavior (making subdirs) is much better for existing libraries, but I would like to create a new library, and build all binaries in the same dir. Does bjam allow this? (note: I will have four binaries per compiler) Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

3 3

how to get the files for review?
by Oliver Kullmann 21 May '04

21 May '04

Hi, I just subscribed, and I would like to review the three--valued-logic library. So I click "Files" at the Boost home page. As a result I'm transferred to http://login.yahoo.com/config/login?.intl=us&.src=ygrp&.done=http://groups.… where my ID is asked for?!?! I have never used Yahoo, so I don't know what to do here (given that subscribing with Boost doesn't involve some ID) ?!?! Oliver

2 1

intrusive_ptr question
by Joe Gottman 21 May '04

21 May '04

The intrusive_ptr contains two functions that allow comparisons between intrusive_ptr<T> and T *. template<class T> bool operator==(intrusive_ptr<T> const & a, T * b); template<class T> bool operator==(T * b, intrusive_ptr<T> const & b); and similar operator!=() functions. I'm curious why the pointer parameters are of type T* and not T const *. Joe Gottman

3 4

[Graph] Recently introduced vc6/7 bugs
by David Abrahams 21 May '04

21 May '04

Some new problems in the Graph library on vc6 and vc7 are breaking the Boost.Python library build. See http://tinyurl.com/2j4nj for details. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

RE: [boost] Re: [license]
by Glen Knowles 21 May '04

21 May '04

> > > > Would this be appropiate too: > > > > // Copyright 2004 Joe Coder. Distributed under the Boost // > Software > > License, Version 1.0, provided this > ^^^^^^^^^^^^^ > > // copyright notice appears in all copies. (See accompanying file > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > // LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) > > > > ? > > The highlighted wording is redundant; the licence itself > already requires that. Citing the FAQ once more, > My understanding was that it might be more then merely redundant, it could be interpreted as more restrictive. Possibly requiring the copyright notice to appear in compiled object code for example. Glen

4 3

Wave/flex_string with VC7.0 + dinkumware (new problem)
by Reece Dunn 21 May '04

21 May '04

I reported that VC7 uses the correct implementation of reverse_iterator, and that this can be detected via BOOST_NO_STD_ITERATOR. Although this compiles, you cannot use reverse iterators. The problem is that the iterator is of the form (const) T *, and this fails because there is not a correct implementation of iterator_traits (due to a lack of partial template specialization) that *is* detected by BOOST_NO_STD_ITERATOR_TRAITS. The solution would therefore be to - in this case - provide an iterator wrapper around a standard pointer so it has the correct Iter::value_type, etc definitions. Is there an iterator_adaptor that provides this within boost? If not, should there be one? I am looking into this and will commit the solution to my iterator_adaptor-style implementation (sandbox/boost/fixed_string/detail/basic_string_impl.hpp). NOTE: If you want to add any of my modifications to the Wave flex_string implementation, feel free, but be warned that I haven't run full tests on it yet and thus there might be bugs in it (especially the pod_xxx --> traits_type::xxx, since these functions have different parameters). Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2

iterator_adaptor.hpp and python/detail/is_xxx.hpp
by Domenico Andreoli 21 May '04

21 May '04

hi, i'm wondering whether boost/iterator/iterator_adaptor.hpp really needs to include boost/python/detail/is_xxx.hpp or not. it seems this inclusion is not required, removing it does not any harm. i'm asking this because debian packages python headers in package libboost-python-dev and itarator headers in libboost-dev. this (maybe useless) inclusion forces libboost-dev to depend on libboost-python-dev making it useless as separate package from libboost-dev. i'd like to remove this inclusion, at least for what regards the debian packages. i'd be very glad to hear your thoughts about this story. cheers domenico -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50

3 4

PING: Lambda Documentation Problem
by Stephan T. Lavavej 21 May '04

21 May '04

About two weeks ago I pointed out a fairly serious factual error in the Boost Lambda documentation, described here: http://lists.boost.org/MailArchives/boost/msg64450.php Stephan T. Lavavej http://nuwen.net

2 1

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

21 May '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > > > Currently, this implementation is missing iterator support (and thus all > > basic_string functionality that relies on begin(), end(), etc). This is > > because I am wondering how to map them from the basic_string adaptor to >the > > implementation (knowing that you cannot have const and non-const virtual > > functions). > >Since when can you not have const and non-const virtual >functions? Let me rephrase: class char_string { virtual iterator begin() = 0; virtual const_iterator begin() = 0; // oops! begin already in vtable!! }; > > I have two possible solutions: > > [1] name the const versions cXXX (cbegin(), crend(), etc.) -- the >problem > > with this is that you have 8 virtual functions! I was meaning to modify the above to: class char_string { virtual iterator begin() = 0; virtual const_iterator cbegin() = 0; // ok - cXXX variant }; >You'd have those same eight variations with const and non-const >virtual functions. That's the problem -- too many virtual functions. > > [2] direct to non-const versions and convert to const iterators: > > inline const_iterator begin() const > > { > > return( const_iterator( const_cast< basic_string_impl & >( *this > > ).begin())); > > } > > but I am debating whether this is standards compliant and if it is a >good > > design decision. > >If the object is really const, then this results in undefined >behavior. I have disregarded this idea. > > If there are alternate solutions, I'd like to hear them. > >Use const and non-const virtual functions. ;-) > > > Another possibility would be to construct the iterators from offsets: > > > > inline iterator begin() > > { > > return( get_impl().iter_offset( 0 )); > > } > > inline reverse_iterator rbegin() > > { > > return( reverse_iterator( get_impl().iter_offset( size() - 1 ))); > > } > > > > That way you would only need two functions (iter_offset and > > const_iter_offset). > >But how would the iterator know whether to give const or >non-const access to the elements? iter_offset = non-const access (e.g. begin()) const_iter_offset = const access (e.g. rend() const) class char_string { virtual iterator iter_offset( difference_type ) = 0; virtual const_iterator const_iter_offset( difference_type ) = 0; }; template< class Derived, ... > class basic_string_impl > { public: inline iterator begin(){ return( get_impl().iter_offset( 0 )); } inline const_iterator begin() const{ return( get_impl().const_iter_offset( 0 )); } }; NOTE: it is not necessary for Derived to be implemented with virtual functions, but each function name is unique so if they are virtual there isn't a problem. I have tested this on VC6, VC7, VC71 and BCB and it works :). Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

Who's in charge of the Mac OS regression machine?
by Joaquín Mª López Muñoz 21 May '04

21 May '04

There are some problems with the output of some tests of mine that do not longer exist. Please contact me for further elaboration (joaquin at tid.es) Thanx in advance. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

condition::notify_[whatever] overhead
by Vadim Senchukov 21 May '04

21 May '04

On Win32 platform both notify_one and notify_all do a lot of work with kernel objects whether there are any threads waiting on condition or no. Can't we eliminate such overhead using pretty simple counter of waitng threads like in code below? Or I've overlooked smth and code has subtle problems? boost::mutex mtx; boost::condition cond; int waiting = 0; ... //waiting in some place boost::mutex::scoped_lock lk( mtx ); ++waiting; while (!pred) cond.wait( lk ); --waiting; //notification in another place boost::mutex::scoped_lock lk( mtx ); if ( waiting ) cond.notify_one();

1 0

RE:RE: [boost] seiralization of shared_ptr
by Robert Ramey 21 May '04

21 May '04

>> template<class Archive, class T> >> inline void load( >> Archive & ar, >> shared_ptr<T> & t, >> const unsigned int /* file_version */ >> ){ >> // object tracking guarantees that pointers are not replicated >> // on loading. >> T * t_new; >> ar >> boost::serialization::make_nvp("px", t_new); >> // if its not the first time, it should be equal to the current pointer >> assert(0 == t.use_count() || t.get() == t_new); >> // assign new pointer or bump reference count as appropriate >> // ???? - what goes here? >> } >> >> Can anybody tell me "what goes here?" >> >> Robert Ramey >I don't see problem where you see it. I ses problem in different place. >How is it possible that t.use_count() != 0? My understanding that before >loading all data is empty and you never actually load the same variable >twice. >struct A { > shared_ptr<user_type> member; > load(...) { > ar >> member; > } >}; >A a1, a2 At this point a1.member.use_count == 0, >ar >> a1; >ar >> a2; ... >Now the real problem lies IMO in a fact that you need to keep map raw ptr - >corresponding shared_ptr. IOW when you got raw ptr and you need to create >shared ptr for it you need to figure out somehow whether you already did >it. If yes you need to make a copy to that shared_ptr. If not create new >and register it. That's the problem. There's no way I can see to create a copy of an existing shared pointer given only the copy to the shared underlying pointer. The current implementation uses object tracking to load the replicated pointer to the shared_count. At that point the loaded shared pointer is connected to any other shared_ptrs that correspond to the underlying shared object. This does not require maintenance of any other ptr/shared_ptr maps which would only replicate the what the serialization library does anyway through object tracking. However, the current method does require either privileged access to shared_ptr and shared_count or some sort of expansion of the interface. I believe this answers the original question you posed:"Why does serialization of shared_ptr require access to shared_count?" Robert Ramey

3 2

[Boost-bugs] [ boost-Support Requests-957850 ] boost for ARM platform?
by SourceForge.net 21 May '04

21 May '04

Support Requests item #957850, was opened at 2004-05-21 00:07 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=957850&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: boost for ARM platform? Initial Comment: mailto:peter.mason@dilithiumnetworks.com is writing ... Sorry if this has been discussed already, but I've only just joined. Something I'm building under an ARM toolchain/devkit requires Boost functionality, and thus needs a porting of boost to ARM platforms. I'm not even familiar with the build tools used to build Boost, so it's a daunting task. Can someone please tell me that such a port has been done already and it's available at XXX? If not, then I'd appreciate some options and guidance. Thanks in advance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=957850&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

enabling automatic memory leak detection with VC
by Robert Ramey 21 May '04

21 May '04

While investigating shared_ptr serialization, I've come upon the VC method used for detecting memory leaks. I had previously used it as part of MFC and found it very helpful. By including the following at the beginning of one's test program: #define _CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> struct leak_reporter { static leak_reporter instance; leak_reporter(){ _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); } ~leak_reporter(){ // _CrtDumpMemoryLeaks(); // replaced by the above } }; leak_reporter leak_reporter::instance; The program displays the following in the output window while running under the VC IDE: Detected memory leaks! Dumping objects -> c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {663} normal block at 0x00325480, 24 bytes long. Data: < ,W > C4 2C 57 00 00 00 00 00 FF FF FF FF 00 00 00 00 c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {393} normal block at 0x003261F0, 24 bytes long. Data: < ,W > 94 2C 57 00 00 00 00 00 FF FF FF FF 00 00 00 00 Object dump complete. The sequential number (663 and 393 in this example) can be used to trap the debugger at the original allocation when the test is run the next time. Is this not a worthy idea to be included in the test system - at least for VC? In this way we would get a report of memory leaks every time we ran a test. Robert Ramey

2 1

VC7.1 and BGL from cvs
by Victor A. Wagner Jr. 21 May '04

21 May '04

The following errors have been showing up in my nightly builds starting 2004 May 14 C:\Projects\boost>bjam -sTOOLS=vc7.1 install 1>bjaminstall.log ============ a section of the log file, hopefully relevant =================================== vc-C++ bin\boost\libs\python\build\boost_python.dll\vc7.1\debug\inheritance.obj inheritance.cpp C:\Projects\boost\boost\graph\adjacency_list.hpp(423) : error C2653: 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::vertex_bundled' : is not a class or namespace name C:\Projects\boost\boost\graph\adjacency_list.hpp(342) : see declaration of 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::vertex_bundled' C:\Projects\boost\boost\graph\adjacency_list.hpp(459) : see reference to class template instantiation 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>' being compiled C:\Projects\boost\boost\graph\adjacency_list.hpp(432) : error C2653: 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::vertex_bundled' : is not a class or namespace name C:\Projects\boost\boost\graph\adjacency_list.hpp(342) : see declaration of 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::vertex_bundled' C:\Projects\boost\boost\graph\adjacency_list.hpp(441) : error C2653: 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::edge_bundled' : is not a class or namespace name C:\Projects\boost\boost\graph\adjacency_list.hpp(346) : see declaration of 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::edge_bundled' C:\Projects\boost\boost\graph\adjacency_list.hpp(450) : error C2653: 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::edge_bundled' : is not a class or namespace name C:\Projects\boost\boost\graph\adjacency_list.hpp(346) : see declaration of 'boost::adjacency_list<OutEdgeListS,VertexListS,DirectedS,VertexProperty,EdgeProperty,GraphProperty,EdgeListS>::edge_bundled' CALL "C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\bin\VCVARS32.BAT" >nul "C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\bin\cl" /Zm800 -nologo -GX -c -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_SOURCE /Z7 /Od /Ob0 /GX /GR /MDd /Op /Zc:forScope /Zc:wchar_t -I"bin\boost\libs\python\build" -I"C:\Projects\boost" -I"c:\python23\include" -Fo"bin\boost\libs\python\build\boost_python.dll\vc7.1\debug\inheritance.obj" -Tp"C:\Projects\boost\libs\python\build\../src/object/inheritance.cpp" ...failed vc-C++ bin\boost\libs\python\build\boost_python.dll\vc7.1\debug\inheritance.obj... ...skipped <@boost!libs!python!build\boost_python.dll\vc7.1\debug>boost_python-vc71-mt-gd-1_31.CMD for lack of <@boost!libs!python!build\boost_python.dll\vc7.1\debug>inheritance.obj... ...skipped <@boost!libs!python!build\boost_python.dll\vc7.1\debug>boost_python-vc71-mt-gd-1_31.dll for lack of <@boost!libs!python!build\boost_python.dll\vc7.1\debug>boost_python-vc71-mt-gd-1_31.CMD... Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

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

20 May '04

John Nagle wrote: > This looks rather complex for what it does. > > It might be helpful to define the user-visible >API first. Then worry about the implementation. The user-visible API that I am using is the basic_string API (C++98 21.3) along with operator const CharT *() and format( const CharT *, va_args ) to allow C-style string interoperability. There are also implementations of the C string API (string.h) to allow fixed_string to interface with C code. The requirements for fixed_string are: [1] prevent buffer overflow on a fixed capacity string (CharT[ n ]); [2] provide a basic_string interface -- this is where part of the complexity comes in [3] provide C-string functions (strcpy, strlen, etc.) [4] allow functions to operate on variable-capacity strings without resorting to template code -- this is where the rest of the complexity comes in My implementation meets the above requirements, although requirement [3] could be more fully implemented (I'm working on this). Requirements 2 and 3 are interface (API) requirements, defined in the C++98 and C90 standards, while 1 and 4 are interface requirements. Despite the basic_string interface being complex, I do not want to drop it (even if that would simplify the class considerably!) However, if there is a simpler way to meet these requirements then I'd be happy to see what it is. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

1 0

[license]
by David B. Held 20 May '04

20 May '04

Is this the canonical way to license a Boost library? // Copyright 20xx. I. M. Author // Use, modification, and distribution are subject to the Boost Software // License, Version 1.0. (See accompanying file LICENSE_1_0.txt or // copy at www.boost.org/LICENSE_1_0.txt) If we don't want to include the actual license text in the library itself (nor does it seem desirable, when distributed with all of Boost), does it make more sense to abbreviate it to: // Copyright 20xx. I. M. Author // Use, modification, and distribution are subject to the Boost Software // License, Version 1.0. (See www.boost.org/LICENSE_1_0.txt) And did we agree that "use, modification, and distribution" is sufficient, or do we need to mention something about display rights? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.683 / Virus Database: 445 - Release Date: 5/12/2004

4 5

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

20 May '04

John Nagle wrote: >Reece Dunn wrote: >>I have uploaded an initial version of this. > Thanks. I'll take a look at that shortly. You might want to take a look at fixed_string.hpp. It is an alternate implementation of fixed_string that I intend to replace char_string.hpp once it is stable. Currently, this implementation is missing iterator support (and thus all basic_string functionality that relies on begin(), end(), etc). This is because I am wondering how to map them from the basic_string adaptor to the implementation (knowing that you cannot have const and non-const virtual functions). I have two possible solutions: [1] name the const versions cXXX (cbegin(), crend(), etc.) -- the problem with this is that you have 8 virtual functions! [2] direct to non-const versions and convert to const iterators: inline const_iterator begin() const { return( const_iterator( const_cast< basic_string_impl & >( *this ).begin())); } but I am debating whether this is standards compliant and if it is a good design decision. If there are alternate solutions, I'd like to hear them. Another possibility would be to construct the iterators from offsets: inline iterator begin() { return( get_impl().iter_offset( 0 )); } inline reverse_iterator rbegin() { return( reverse_iterator( get_impl().iter_offset( size() - 1 ))); } That way you would only need two functions (iter_offset and const_iter_offset). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 3

RE: [boost] enabling automatic memory leak detection with VC
by Max Khesin 20 May '04

20 May '04

I also used this idom, it is very nice. One thing to watch out for is 'false positives' from other global/static objects that do mallocs. leak_reporter leak_reporter::instance; std::string i_will_trigger_leak_report; I am not aware of any automatic way to avoid this. m > -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: Thursday, May 20, 2004 2:06 PM > To: boost(a)lists.boost.org > Subject: [boost] enabling automatic memory leak detection with VC > > > While investigating shared_ptr serialization, I've come upon > the VC method > used for detecting memory leaks. I had previously used it as > part of MFC > and found it very helpful. By including the following at the > beginning of > one's test program: > > #define _CRTDBG_MAP_ALLOC > #include <stdlib.h> > #include <crtdbg.h> > > struct leak_reporter { > static leak_reporter instance; > leak_reporter(){ > _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | > _CRTDBG_LEAK_CHECK_DF ); > } > ~leak_reporter(){ > // _CrtDumpMemoryLeaks(); // replaced by the above > } > }; > leak_reporter leak_reporter::instance; > > The program displays the following in the output window while > running under > the VC IDE: > > Detected memory leaks! > Dumping objects -> > c:\program files\microsoft visual studio .net > 2003\vc7\include\crtdbg.h(689) > : {663} normal block at 0x00325480, 24 bytes long. > Data: < ,W > C4 2C 57 00 00 00 00 00 FF FF FF FF > 00 00 00 00 > c:\program files\microsoft visual studio .net > 2003\vc7\include\crtdbg.h(689) > : {393} normal block at 0x003261F0, 24 bytes long. > Data: < ,W > 94 2C 57 00 00 00 00 00 FF FF FF FF > 00 00 00 00 > Object dump complete. > > The sequential number (663 and 393 in this example) can be > used to trap the > debugger at the original allocation when the test is run the > next time. > > Is this not a worthy idea to be included in the test system - > at least for > VC? In this way we would get a report of memory leaks every > time we ran a > test. > > Robert Ramey > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

RE: [boost] Re: Is there interest in a decimal floating-point cla ss?
by Max Khesin 20 May '04

20 May '04

No I can't so I recant :). m. > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Thursday, May 20, 2004 2:14 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Is there interest in a decimal floating-point cla > ss? > > > Max Khesin <MKhesin(a)liquidnet.com> writes: > > > I would think the crucial difference is that pthreads pretty much > > come with the platform, while the C decimal math lib would have to > > be included with its wrapper's distribution from boost to insure > > availability - correct me if I am wrong. > > Unless you can cite an actual library guideline somewhere that rules > out such a wrapper, I guess you're wrong to "doubt boost library > guidelines would allow including a wrapper over a C library." > Parts of uBlas work that way with FORTRAN libraries, IIUC. > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

3 2

RE: [boost] enabling automatic memory leak detection with VC
by Rozental, Gennadiy 20 May '04

20 May '04

> I also used this idom, it is very nice. One thing to watch > out for is 'false positives' from other global/static objects > that do mallocs. > > leak_reporter leak_reporter::instance; > std::string i_will_trigger_leak_report; > > > I am not aware of any automatic way to avoid this. I will use command line argument to to turn this feature on/off Gennadiy.

1 0

RE: [boost] enabling automatic memory leak detection with VC
by Rozental, Gennadiy 20 May '04

20 May '04

> While investigating shared_ptr serialization, I've come upon > the VC method used for detecting memory leaks. I had > previously used it as part of MFC and found it very helpful. > By including the following at the beginning of one's test program: > > #define _CRTDBG_MAP_ALLOC > #include <stdlib.h> > #include <crtdbg.h> > > struct leak_reporter { > static leak_reporter instance; > leak_reporter(){ > _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | > _CRTDBG_LEAK_CHECK_DF ); > } > ~leak_reporter(){ > // _CrtDumpMemoryLeaks(); // replaced by the above > } > }; > leak_reporter leak_reporter::instance; > > The program displays the following in the output window while > running under the VC IDE: > > Detected memory leaks! > Dumping objects -> > c:\program files\microsoft visual studio .net > 2003\vc7\include\crtdbg.h(689) > : {663} normal block at 0x00325480, 24 bytes long. > Data: < ,W > C4 2C 57 00 00 00 00 00 FF FF FF FF > 00 00 00 00 > c:\program files\microsoft visual studio .net > 2003\vc7\include\crtdbg.h(689) > : {393} normal block at 0x003261F0, 24 bytes long. > Data: < ,W > 94 2C 57 00 00 00 00 00 FF FF FF FF > 00 00 00 00 > Object dump complete. > > The sequential number (663 and 393 in this example) can be > used to trap the debugger at the original allocation when the > test is run the next time. > > Is this not a worthy idea to be included in the test system - > at least for VC? In this way we would get a report of memory > leaks every time we ran a test. > > Robert Ramey Thanks Robert, I will look onto it. Gennadiy.

1 0

RE: [boost] Re: Is there interest in a decimal floating-point cla ss?
by Max Khesin 20 May '04

20 May '04

I would think the crucial difference is that pthreads pretty much come with the platform, while the C decimal math lib would have to be included with its wrapper's distribution from boost to insure availability - correct me if I am wrong. m > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Thursday, May 20, 2004 11:41 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Is there interest in a decimal floating-point > class? > > > Max Khesin <MKhesin(a)liquidnet.com> writes: > > > I think this is very valuable, but I really doubt boost > library guidelines > > would allow including a wrapper over a C library, as the C > library certainly > > would not be confirming with boost coding (and possibly licensing) > > standards. Perhaps you should propose your wrapper as the > library interface, > > if you are willing to reimplement the guts later. > > I don't think that's neccessarily a problem. Boost.Threads is "just a > wrapper" over the pthreads library on some platforms. > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

ETI bug
by David B. Held 20 May '04

20 May '04

Is VC 6.x the only compiler with this bug? Or does 7.x also have problems? How about compilers from other vendors? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.683 / Virus Database: 445 - Release Date: 5/12/2004

6 7

RE: [boost] Is there interest in a decimal floating-point class?
by Max Khesin 20 May '04

20 May '04

I think this is very valuable, but I really doubt boost library guidelines would allow including a wrapper over a C library, as the C library certainly would not be confirming with boost coding (and possibly licensing) standards. Perhaps you should propose your wrapper as the library interface, if you are willing to reimplement the guts later. m > -----Original Message----- > From: Richard Kaiser [mailto:rk@rkaiser.de] > Sent: Thursday, May 20, 2004 9:03 AM > To: boost(a)lists.boost.org > Subject: [boost] Is there interest in a decimal floating-point class? > > > I want to ask the boost community if there is interest in a decimal > floating-point class implementing one or more of the decimal > floating-point types that are intended to become part of a > future C and > C++ standard. > > This class would be a wrapper class around Mike Cowlishaws > decNumber C > library. You can take a look at my first preliminary version > (it is just > a first try, the design is far from perfect, it is incomplete, its > notation is inconsistent and not according to boost conventions) at > > http://www.rkaiser.de/rkaiser/DecFPClass/DecFPClass.html > > Most of its operators work as they should do, and most of Mikes > testcases pass successfully. The function > DecimalFloat_Testcases("d:\\cpp.boo\\decnumber\\decnumberclass \\decTest\\") in my test program test_rk reads all the testcases from Mikes decTest files and logs each testcase in a file (bcb files were created with Borland C++Builder 6, gcc with MinGW g++, and msc with MS Visual Studio ..Net). With “grep "###number" *.log” you get the summary lines: File abs.decTest_bcb.log: ###number of tests passed=87 failed=2 File abs.decTest_gcc.log: ###number of tests passed=87 failed=2 File abs.decTest_msc.log: ###number of tests passed=87 failed=2 File add.decTest_bcb.log: ###number of tests passed=773 failed=45 File add.decTest_gcc.log: ###number of tests passed=773 failed=46 File add.decTest_msc.log: ###number of tests passed=773 failed=45 ... If the boost community is interested, if I find enough time, and if everything works as intended, the resulting classes would be a reference implementation for the new standard decimal floating point types, or at least a close one. I posted this request already some days ago, but by mistake I have posted it as a reply to a message it did not belong to. Sorry. Richard Kaiser _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

[assert_no_intrinsic_wchar_t] What the...?
by David Abrahams 20 May '04

20 May '04

The logic used here seems to be completely and totally broken. Was it even tested? config/compiler/intel.hpp first says: #if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else ... #endif So if I have intel6, BOOST_NO_INTRINSIC_WCHAR_T is now set. Then config/compiler/intel.hpp goes on to say: #if defined(BOOST_NO_INTRINSIC_WCHAR_T) #include <cwchar> template< typename T > struct assert_no_intrinsic_wchar_t; template<> struct assert_no_intrinsic_wchar_t<wchar_t> { typedef void type; }; // if you see an error here then you need to unset BOOST_NO_INTRINSIC_WCHAR_T: typedef assert_no_intrinsic_wchar_t<unsigned short>::type assert_no_intrinsic_wchar_t_; #else ... #endif So, if I get the error, how exactly am I supposed to "unset BOOST_NO_INTRINSIC_WCHAR_T" before the error occurs? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

6 11

seiralization of shared_ptr
by Robert Ramey 20 May '04

20 May '04

Some time ago the question was raised on this list as to why it was necessary to access share_count in order to implement serialization of shared_ptr. At the time I didn't have an answer. So I went back and tried to re-implement it and have come to the following point beyond which I can't proceed without manipulating shared_count directly. ///////////////////////////////////////////////////////////// // implement serialization for shared_ptr<T> template<class Archive, class T> inline void save( Archive & ar, const shared_ptr<T> & t, const unsigned int /* file_version */ ){ ar << boost::serialization::make_nvp("px", t.get()); } template<class Archive, class T> inline void load( Archive & ar, shared_ptr<T> & t, const unsigned int /* file_version */ ){ // object tracking guarantees that pointers are not replicated // on loading. T * t_new; ar >> boost::serialization::make_nvp("px", t_new); // if its not the first time, it should be equal to the current pointer assert(0 == t.use_count() || t.get() == t_new); // assign new pointer or bump reference count as appropriate // ???? - what goes here? } Can anybody tell me "what goes here?" Robert Ramey

3 2

Is there interest in a decimal floating-point class?
by Richard Kaiser 20 May '04

20 May '04

I want to ask the boost community if there is interest in a decimal floating-point class implementing one or more of the decimal floating-point types that are intended to become part of a future C and C++ standard. This class would be a wrapper class around Mike Cowlishaws decNumber C library. You can take a look at my first preliminary version (it is just a first try, the design is far from perfect, it is incomplete, its notation is inconsistent and not according to boost conventions) at http://www.rkaiser.de/rkaiser/DecFPClass/DecFPClass.html Most of its operators work as they should do, and most of Mikes testcases pass successfully. The function DecimalFloat_Testcases("d:\\cpp.boo\\decnumber\\decnumberclass\\decTest\\") in my test program test_rk reads all the testcases from Mikes decTest files and logs each testcase in a file (bcb files were created with Borland C++Builder 6, gcc with MinGW g++, and msc with MS Visual Studio .Net). With “grep "###number" *.log” you get the summary lines: File abs.decTest_bcb.log: ###number of tests passed=87 failed=2 File abs.decTest_gcc.log: ###number of tests passed=87 failed=2 File abs.decTest_msc.log: ###number of tests passed=87 failed=2 File add.decTest_bcb.log: ###number of tests passed=773 failed=45 File add.decTest_gcc.log: ###number of tests passed=773 failed=46 File add.decTest_msc.log: ###number of tests passed=773 failed=45 ... If the boost community is interested, if I find enough time, and if everything works as intended, the resulting classes would be a reference implementation for the new standard decimal floating point types, or at least a close one. I posted this request already some days ago, but by mistake I have posted it as a reply to a message it did not belong to. Sorry. Richard Kaiser

1 0

RE: [boost] basic_string interface generator
by Reece Dunn 20 May '04

20 May '04

Darryl Green wrote: > > -----Original Message----- > > From: boost-bounces(a)lists.boost.org > > [mailto:boost-bounces@lists.boost.org] On Behalf Of Reece Dunn > > > > Is there any interest in the ability to generate a > > basic_string compliant > > interface from a base set of functions in a similar way that > > the iterator > > adaptors work? > >Yes, though I'm not sure yet that the flex_string policy based approach >wouldn't work just as well. I guess if this capability is at least an >implementation detail of your fixed_string you can easily make it >available for review/comparison. If you do, I will certainly give it a >go and post a review of that feature (I'm interested in fixed_string >anyway). I am working on it now. It is available in the sandbox (boost/fixed_string/detail/basic_string_impl.hpp) along with an experimental implementation of fixed_string (boost/fixed_string/fixed_string.hpp). Note that the current implementation is still available as char_string.hpp. Comments and feedback are always welcome. NOTE: This is still very much a work-in-progress. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

1 0

Fwd: Bug#245390: libboost-graph-dev: A different example in the boost dist doesn't compile
by Domenico Andreoli 20 May '04

20 May '04

hi, as most of you have already understood, today is the debian bugs reporting day :) here we have another report, #245390 [0]. it is easily reproducible alson on a i386 box. anybody has already seen it? thanks domenico [0] http://bugs.debian.org/245390 ----- Forwarded message from Bogdan Oporowski <bogdan(a)math.lsu.edu> ----- Date: Thu, 22 Apr 2004 16:44:37 -0500 From: Bogdan Oporowski <bogdan(a)math.lsu.edu> To: Debian Bug Tracking System <submit(a)bugs.debian.org> Reply-To: Bogdan Oporowski <bogdan(a)math.lsu.edu>, 245390(a)bugs.debian.org Subject: Bug#245390: libboost-graph-dev: A different example in the boost dist doesn't compile Package: libboost-graph-dev Version: 1.31.0-4 Severity: normal This example is isomorphism.cpp, and gives: /usr/include/boost/graph/isomorphism.hpp:111: error: invalid conversion from ` void* const' to `int' as the final message in a huge error. I can attach the entire error if you need it, but otherwise don't want to waste a lot of space if you can reproduce it locally. ----- 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 3

Regex Token Iterator Warning
by Stephan T. Lavavej 20 May '04

20 May '04

John Maddock, I love regex_token_iterator's vector<int> constructor - it fits my needs perfectly! However, my use of it is generating a trivial warning that should be fixed. Using Boost CVS 20040427, in boost/regex/v4/regex_token_iterator.hpp, the member flags is declared on Line 59: match_flag_type flags; And the member subs is declared on Line 62: std::vector<int> subs; However, they are initialized in a different order in the constructor on Lines 67-68: regex_token_iterator_implementation(const regex_type* p, BidirectionalIterator last, const std::vector<int>& v, match_flag_type f) : end(last), pre(p), subs(v), flags(f){} This upsets my ninja warning options on gcc 3.3.3, since members should appear in an initialization list in the same order that they are declared, for safety reasons. There may be other initialization order warnings lurking in the code that my program does not yet trigger. I am always impressed with your prompt attention to my regex issues; thanks again for the hard work! Stephan T. Lavavej http://nuwen.net

2 1

Sleep(1) in spinlock in lwm_win32.hpp
by Aaron W. LaFramboise 20 May '04

20 May '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I was doing some research on implementing fast mutexes in Windows for GCC, and in the course of doing various sorts of benchmarks, I came across something very disturbing. I've noticed a lot of discussion of the Windows spinlocks before, but I don't think this came up. By default on Windows when using lightweight mutexes, Boost acquires and releases a spinlock using this code: ~ explicit scoped_lock(lightweight_mutex & m): m_(m) ~ { ~ while( InterlockedExchange(&m_.l_, 1) ) ~ { ~ // Note: changed to Sleep(1) from Sleep(0). ~ // According to MSDN, Sleep(0) will never yield ~ // to a lower-priority thread, whereas Sleep(1) ~ // will. Performance seems not to be affected. ~ Sleep(1); ~ } ~ } ~ ~scoped_lock() ~ { ~ InterlockedExchange(&m_.l_, 0); ~ // Note: adding a yield here will make ~ // the spinlock more fair and will increase the overall ~ // performance of some applications substantially in ~ // high contention situations, but will penalize the ~ // low contention / single thread case up to 5x ~ } First, I verified the claim that Sleep(1) yields to low-priority threads, and this is, in fact, true. However, when benchmarking, I noticed that it in fact sleeps slightly more than 10ms by default on Windows XP! Other platforms seem to have similar results. This is a very long time. Using timeBeginPeriod(), it is possible to lower this to 1ms, but in no case when Sleep has a positive parameter will Windows sleep for a period shorter than this. Unfortunately, timeBeginPeriod() is part of of mmsystem and on every compiler I am familiar with, requires linking against an additional import library, winmm. This may or may not be a big deal. In any case, the present code seems very suboptimal, and in some situations, it could be ridiculously slow, compared to the standard Windows synchronization primatives it is working so hard to avoid. I would suggest that if there were another Boost release that included this code, the situation involving this spinlock would need to be documented somewhere obvious. I think, though, that we could trivially improve this code without too much effort and without compromising its goals. In particular, the loop could spin for a while using Sleep(0), which is orders of magnitude faster, before falling back to Sleep(1)--presumably because a thread of lower priority holds the lock. This should eliminate 90% of the practical problem, but definitely is not a perminant solution. Aaron W. LaFramboise -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFArHA7lp/lhnWsM8QRAganAJ9tW7F8axtjSeTqp9ZDmXKuNb2a3QCgl1ZO 4CMavVQnkH7DNtZmd4Fitgw= =te8D -----END PGP SIGNATURE-----

1 0

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

20 May '04

John Nagle wrote: > With no base class for all fixed_string types, though, >there's no way to pass fixed_string objects around, short >of templating every function that uses them. > > A base class seems to be needed. Otherwise, there's >no direct replacement for "char *" arguments. I have uploaded an initial version of this. I wanted to wait before I approached the base class concept for two main reasons: (a) I wanted to move the interface closer to that of std::basic_string and (b) I wasn't sure how to implement it as a template on character type. The interface names have been moved to the corresponding basic_string/STL names (assign, append, etc.). The approach I have used for the base classes retains the template on character type, using MPL machinery to select the appropriate base class. Note that this is not perfect, since I still need a constraint to limit CharT to char and wchar_t, or provide an additional template parameter that defaults to the MPL machinery, allowing you to provide your own interface for custom string types. > Here's a simple test program. It should be possible >to do the common operations done here. That doesn't >seem possible with the latest version in the Boost >sandbox. This should work with the appropriate name changes: boost::char_string is now boost::fixed_string (although it still currently resides in fixed_string/char_string.hpp); boost::char_string_base is boost::char_string for readability; boost::wchar_string_base is boost::wchar_string for readability; Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 2

RE: [boost] basic_string interface generator
by Darryl Green 20 May '04

20 May '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Reece Dunn > > Is there any interest in the ability to generate a > basic_string compliant > interface from a base set of functions in a similar way that > the iterator > adaptors work? Yes, though I'm not sure yet that the flex_string policy based approach wouldn't work just as well. I guess if this capability is at least an implementation detail of your fixed_string you can easily make it available for review/comparison. If you do, I will certainly give it a go and post a review of that feature (I'm interested in fixed_string anyway). Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

1 0

RE: [boost] seiralization of shared_ptr
by Rozental, Gennadiy 19 May '04

19 May '04

> Some time ago the question was raised on this list as to why > it was necessary to access share_count in order to implement > serialization of shared_ptr. At the time I didn't have an answer. > > So I went back and tried to re-implement it and have come to > the following point beyond which I can't proceed without > manipulating shared_count directly. > > ///////////////////////////////////////////////////////////// > // implement serialization for shared_ptr<T> > > template<class Archive, class T> > inline void save( > Archive & ar, > const shared_ptr<T> & t, > const unsigned int /* file_version */ > ){ > ar << boost::serialization::make_nvp("px", t.get()); > } > template<class Archive, class T> > inline void load( > Archive & ar, > shared_ptr<T> & t, > const unsigned int /* file_version */ > ){ > // object tracking guarantees that pointers are not replicated > // on loading. > T * t_new; > ar >> boost::serialization::make_nvp("px", t_new); > // if its not the first time, it should be equal to the current pointer > assert(0 == t.use_count() || t.get() == t_new); > // assign new pointer or bump reference count as appropriate > // ???? - what goes here? > } > > Can anybody tell me "what goes here?" > > Robert Ramey I don't see problem where you see it. I ses problem in different place. How is it possible that t.use_count() != 0? My understanding that before loading all data is empty and you never actually load the same variable twice. struct A { shared_ptr<int> member; load(...) { ar >> member; } }; A a1, a2 ar >> a1; ar >> a2; Now the real problem lies IMO in a fact that you need to keep map raw ptr -> corresponding shared_ptr. IOW when you got raw ptr and you need to create shared ptr for it you need to figure out somehow whether you already did it. If yes you need to make a copy to that shared_ptr. If not create new and register it. Gennadiy.

1 0

python 'in' syntax mini-lib RFC
by Max Khesin 19 May '04

19 May '04

I have been playing around with a library to emulate Python 'in' syntax if(a in [x1, x2]): stuff the main motivation for this is the annoyance of repeating the || operator with the same value in C++ if(val==v1 || val==v2 || val==v3){ ^^^ ^^^ ^^^ } I figured I would use tuple for the list to allow membership test for a list of heterogeneous types (just like python). The rough results are included below. I am interested in your feedback: 1) how useful would you find this in general 2) there are 3 variations on syntax in the main() 1st is native(no macros) with more typing, 2 is less typing with macros, 3d is even less but does not compile :) (coule use a language lawer here). Do you like any of these? Alternative suggestions? 3) implementation - is it correct (I know it's not since is_convertible is used to mean is_comparable, any suggestion), can it be simplified internally or by using other boost libs? thanks, max ///////////////////////////////////////////////////////////////// #include <boost/tuple/tuple.hpp> #include <boost/tuple/tuple_io.hpp> #include <boost/type_traits/is_convertible.hpp> #include <iostream> using std::cout; // compare the values is they are comparable (is_convertible is not // good enough for all cases, suggestions?) template<bool> struct compare_convertible; template<> struct compare_convertible<false> { template<class T1, class T2> bool operator()(const T1&, const T2& ){return false;} }; template<> struct compare_convertible<true> { template<class T1, class T2> bool operator()(const T1& val1, const T2& val2){return val1==val2;} }; template<class T1, class T2> bool compare_if_convertible(const T1& val1, const T2& val2) { return compare_convertible<boost::is_convertible<T2, T1>::value>()(val1, val2); } template<class T, class TupleT> bool contains(const T& val, const TupleT& the_tuple) { return (compare_if_convertible(val, the_tuple.get_head()) // check head || (boost::tuples::length<TupleT::tail_type>::value// not empty && contains(val, the_tuple.get_tail()))); // check tail } // value wrapper, provides the -- part of the --> syntax template<class T> struct Element { const T& val; const Element& operator--(int)const {return *this;} Element(const T& val_):val(val_){} }; template<class T> Element<T> element(const T& val) { return Element<T>(val); } // provides the '>' part of the '-->' syntax template<class ElemT, class T1, class T2> bool operator>(const Element<ElemT>& element, const boost::tuples::cons<T1, T2> the_tuple) { return contains(element.val, the_tuple); } #define in -->boost::make_tuple #define in2 >boost::make_tuple int main(int argc, char* argv[]) { if(element(1.4) --> boost::make_tuple(1, "aa", 1.2)) { std::cout<<"yahuuu\n"; } if(element(1.0) in (1, "aa", 1.2)) { std::cout<<"yahuuu\n"; } #if 0 // will not compile due to // test.cpp(92) : error C2784: 'bool operator >(const Element<ElemT> &,const boost: // :tuples::cons<T1,T2>)' : could not deduce template argument for 'const Element<T // > &' from 'double' // test.cpp(73) : see declaration of 'operator`>'' // test.cpp(92) : error C2677: binary '>' : no global operator found which takes ty // pe 'boost::tuples::detail::make_tuple_mapper<T0,T1,T2,T3,T4,T5,T6,T7,T8,T9>::ty p // e' (or there is no acceptable conversion) // with // [ // T0=int, // T1=const char [3], // T2=double, // T3=boost::tuples::null_type, // T4=boost::tuples::null_type, // T5=boost::tuples::null_type, // T6=boost::tuples::null_type, // T7=boost::tuples::null_type, // T8=boost::tuples::null_type, // T9=boost::tuples::null_type // ] // if(1.0 in2(1, "aa", 1.2)) { std::cout<<"yahuuu\n"; } #endif return 0; } This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

RE: [boost] [test library patch for como]
by Rozental, Gennadiy 19 May '04

19 May '04

> Rozental, Gennadiy wrote: > > Does it incorrect from standard standpoint: > > > > class A { > > int member; > > }; > > > > class B : A { > > public: > > using A::member; > > }; > > > > If it is allowed why so many compilers having issues with it? > > I don't see why you think it should be allowed. A::member is > private, not protected. It's not accessible from B. Sorry I meant protected of course. class A { protected; int member; }; class B : A { public: using A::member; }; Gennadiy

1 0

RE: [boost] [test library patch for como]
by Rozental, Gennadiy 19 May '04

19 May '04

Does it incorrect from standard standpoint: class A { int member; }; class B : A { public: using A::member; }; If it is allowed why so many compilers having issues with it? Gennadiy.

3 2

Re: [boost] [preprocessor] math macros
by Cromwell Enage 19 May '04

19 May '04

--- Paul Mensonides <pmenso57(a)comcast.net> wrote: > Hi Cromwell, Hello! > FYI, these macros don't belong in the preprocessor > library (pp-lib). That library is a set of macros > (etc.) designed to be used to generate C and C++ > code. They don't actually generate that code > themselves. Ah, understood. > That isn't saying anything about whether your > implementation is good or bad or whether it belongs > in Boost. Only that it doesn't properly belong in > the pp-lib. Instead, your macros are clients of the > pp-lib. They should probably go with the rest of > the math stuff (<boost/math/...>) and use a plain > BOOST_ or BOOST_MATH_ prefix (but definitely not > BOOST_PP_). Okay, I'll reorganize everything. > In order to be part of the pp-lib, the macros would > have to calculate their results at preprocessing > time. For example, BOOST_PP_ADD(5, 5) expands to 10 > (the single token), not (5 + 5). Does that make > sense? Gotcha. I don't see how I can do that with my lib without an inordinate amount of work, so unless someone else can see how, I'll stop trying. Thanks for clearing things up! I'll try not to be so presumptuous next time. Cromwell Enage __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/

1 0

RE: [boost] [Test] Test library failing to build on MetaComm inte l-win32-7.1-vc6
by Rozental, Gennadiy 19 May '04

19 May '04

> On Friday 14 May 2004 01:20 pm, Rozental, Gennadiy wrote: > > Do you have any suggestions? > > I've fixed it on Borland, and tried to fix it on Intel 7.1, > Comeau, and Sun > based on the error messages (but I don't have those compilers > handy to test). > > Doug This is not a fix I am looking for. What you did makes whole facility useless on affected compiler. I look for solution that will retain functionality. Gennadiy.

3 2

[test library patch for como]
by Thorsten Ottosen 19 May '04

19 May '04

Hi, I have no idea what the number (second argument) should be. But it worked. br Thorsten begin 666 class_properties.hpp.diff M+2TM(&-L87-S7W!R;W!E<G1I97,N:'!P"3(P,#0M,#4M,C @,# Z,CDZ,3@N M-S,P-34R,# P("LQ,# P#0HK*RL@8VQA<W-?<')O<&5R=&EE<RYH<' N;VQD M"3(P,#0M,#4M,C @,# Z,C8Z,#DN,3 W.#@X,# P("LQ,# P#0I 0" M-38L M-R K-38L-R! 0 T*( T*(" @(" O+R!$871A(&UE;6)E<G,-"B -"BTC:68@ M0D]/4U1?5T]22T%23U5.1"A?7T)/4DQ!3D1#7U\L(#P](#!X-3<P*2!\?"!" M3T]35%]73U)+05)/54Y$*"!?7T-/34]?7RP@/#T@,'@T,S,@*0T**R-I9B!" M3T]35%]73U)+05)/54Y$*%]?0D]23$%.1$-?7RP@/#T@,'@U-S I#0H@(" @ M("\O($)O<FQA;F0@8V%N)W0@9&5A;"!W:71H('1H92!U<VEN9R!D96-L87)A M=&EO;B!I;B!D97)I=F5D(&-L87-S97,-"B C96QS90T*('!R;W1E8W1E9#H- !"@`` ` end

1 0

Re: [boost] Re: BUG: mpl and iso646.h in vc7
by Aleksey Gurtovoy 19 May '04

19 May '04

Ken Hagan writes: > > Ian Baxter wrote: > >> Boosters, > >> > >> Microsoft's macro hacks in the iso646.h header unfortunately kills > >> the current MPL implementation. The headers or.hpp, and.hpp are > >> substituted as ||.hpp, &&.hpp! > > Eric Niebler wrote: > > > > I don't think changing the header names is the right solution. Since > > you're on VC7, you can use the push_macro and pop_macro pragmas to > > work around the issue. > > > > // file: or_.hpp > > #pragma once > > #pragma push_macro("or") > > #include <boost/mpl/or.hpp> > > #pragma pop_macro("or") > > Nice workaround, but it won't help you much if you are using a library > that uses MPL. Renaming the header will upset everyone's sense of > aesthetics, but resolves the problem once and for all. > > Incidentally, I assume VC7 is looking at > > #include <boost/mpl/or.hpp> > > and macro expanding the "or". The standard text for preprocessing phase > 4 does indeed begin "Preprocessing directives are executed and macro > invocations are expanded.", but the text for phase 3 begins "The source > file is decomposed into preprocessing tokens..." and I would have > thought that "boost/mpl/or.hpp" (without the quotes) was a single > h-char-sequence in this context so there is no invocation of the "or" > macro here. > Clearly at least one of "me" and "VC" must be wrong here. You are both right :). In #include <boost/mpl/or.hpp> 'boost/mpl/or.hpp' *is* a single h-char-sequence and MSVC does *not* perform macro substitution here. The problem Ian reported was caused by the code that roughly looked like this: # define HEADER or.hpp # include BOOST_PP_STRINGIZE(boost/mpl/aux_/preprocessed/HEADER) Fixed in the CVS now. No changes are required on user part. Thanks to everybody, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

bug in Wave/flex_string with VC7+dinkumware
by Reece Dunn 19 May '04

19 May '04

BOOST_NO_STD_ITERATOR_TRAITS does not work for VC7 + Dinkumware when using it to identify whether std::reverse_iterator is C++98 or an older/broken implementation. BOOST_NO_STD_ITERATOR does work, however. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

2 1

RE: [boost] Re: basic_string interface generator
by Reece Dunn 19 May '04

19 May '04

Pavel Vozenilek wrote: >"Max Khesin" <MKhesin(a)liquidnet.com> wrote: > > > Just curious: > > what do you think of Andrei's work on policy-based strings: > > http://www.cuj.com/documents/s=7994/cujcexp1906alexandr/alexandr.htm > > http://moderncppdesign.com/code/flex_string.zip I have only previously come across it in passing and have not had a chance to take a look at it. I am studying it at the moment: a very good library! > > - does it do what you want (or leave flexibility to do what you want) > > - if so why not just use it > > - if not what doesn't it do >From what I understand thus far, usage would be like this: boost::flex_string< char, std::char_traits< char >, std::allocator< char >, VectorStringPolicy< char > > vecstr; which is too weildy. It would be possible to use the template typedef concept to have something like: template< typename CharT, template< typename C, class A > class Storage, class Traits, class AllocT > struct cust_string { typedef boost::flex_string< CharT, Traits, AllocT, Storage< CharT, AllocT > > type; }; cust_string< char, VectorStringPolicy >::type vecstr; If you want a special string type, you will need to do something like this: template< typename CharT, class A = std::allocator< CharT > > class MyCustStorage{ ... }; template< typename CharT, class Traits > class mybasic_string: public boost::flex_string< CharT, Traits, std::allocator< CharT >, Storage< CharT > > { public: mybasic_string(){} // ... }; Where you are essentially having to write more code. What I am ideally looking for is something similar to what the iterator adaptors do, allowing: template< typename CharT, class Traits > class mybasic_string: public boost::string_adaptor< mybasic_string, CharT, Traits > { public: const CharT * c_str(){ ... } // ... public: mybasic_string(){} // ... }; Another minor point is that the policy classes do not meet the standard/Boost naming convention. Also: what if you want to use a different string type for substrings than the type being used? As an example, I have a fixed-capacity string fixed_string< n, CharT > that is equivalent to CharT[ n ], and guards against buffer overflow on the string operations (as a safe replacement for the equivalent C operations). In order to write code generically on them without using template code, I have an abstract class: class char_string { public: virtual const char * c_str() = 0; virtual size_t length() = 0; // ... }; template< size_t n, typename CharT = char, ... > class fixed_string: public char_string // note: MPL code to select char or wchar_t version { CharT str[ n ]; size_t len; public: inline const CharT * c_str(){ return( str ); } inline size_t length(){ return( len ); } // ... }; inline void printme( const char_string & s ) { std::cout << s.c_str(); } With this, you can't use char_string as a standard type (it needs to be a reference or pointer) because you'd get an error about instantiating an abstract base class. >Just remark: Andrei's flex_string is already included in Wave, (future) >Boost library. :) Regards, Reece _________________________________________________________________ Get a FREE connection, FREE modem and one month's FREE line rental, plus a US or European flight when you sign up for BT Broadband! http://www.msn.co.uk/specials/btbroadband

1 0

BUG: mpl and iso646.h in vc7
by Ian Baxter 19 May '04

19 May '04

Boosters, Microsoft's macro hacks in the iso646.h header unfortunately kills the current MPL implementation. The headers or.hpp, and.hpp are substituted as ||.hpp, &&.hpp! Since the iso646.h header is typically force included at the project level, header re-arranging is not a practical solution. Any possibility of getting these headers renamed? Ian

3 2

date_time high resolution clock for Win32
by Aaron W. LaFramboise 19 May '04

19 May '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, (This is a followup to this question of mine on boost-users http://lists.boost.org/MailArchives/boost-users/msg06618.php . Jeff Garland suggested comments on that thread should be posted here. I'm new to this list, and not entirely sure if messages with this sort of platform-specific detail are welcome here; if they aren't, let me know.) I've been examining possibilities for a high resolution clock in date_time for Win32 over the past few days. In particular, Windows, like many other platforms, has a system clock with only fair precision (usually about 10ms), but excellent 'counter' clocks with very high precision. It seemed reasonable to me that it should be possible to combine the accuracy of the system clock with the precision of a high-resolution counters, to create a Boost date_time clock that had both the system's maximum accuracy and maximum precision. So, after a few days of casual research and brainstorming, I came up with this simple, incomplete prototype clock. The idea is that it queries both the system clock and the high resolution counter, saves them in static memory. Future calls only use the high resolution counter, using the saved correspondence between the two clocks to calculate the real time. This sort of timer, if it can be implemented reasonably, might be useful on many platforms, including when only time() and clock() are availible. This implementation has these characteristics: THEORY (Wishful thinking) - -Should be the best general-purpose clock and timer on Win32, that would be very difficult to exceed in useful precision or accuracy in a reimplementation. - -Should gracefully handle user changes of system clock. PRACTICE - -It does in fact have the promised ten millisecond accuracy and sub-microsecond resolution. - -The Windows system clock is a lot more "jittery" than I had noticed before. This is a huge problem. The clock routine checks every call to ensure that the two clocks are not further apart than twice the reported precision of the system clock. If they are, the saved times are re-initialized, and the clock starts over from the system time. There is a small problem in my implementation that causes the clock to return subsequent decreasing times for only very small drifts, which should not happen. I have not yet decided how to fix this, but this is not the big problem. The big problem is that while the system clock and counter stay very well in synch under 'normal conditions,' the system clock jitters a whole lot when a lot of system resources are being used in the background, causing the clock to reset itself when it really should not. This in turn causes some strange precision characteristics which might be unacceptable for some applications. I'm going to let this sit for a few days while I think about it. I'd be very interested in hearing any comments in the meantime. Aaron W. LaFramboise #include "boost/date_time/c_time.hpp" #include <windows.h> namespace boost { namespace date_time { ~ template<class time_type> ~ class win32_clock ~ { ~ public: ~ typedef typename time_type::date_type date_type; ~ typedef typename time_type::time_duration_type time_duration_type; ~ typedef typename time_duration_type::rep_type resolution_traits_type; ~ //! Return the local time based on computer clock settings ~ static time_type local_time() { ~ SYSTEMTIME st; ~ ::GetSystemTime(&st); ~ LARGE_INTEGER pc; ~ ::QueryPerformanceCounter(&pc); ~ return create_time(st, pc); ~ } ~ private: ~ static time_type create_time(const SYSTEMTIME &system_time, ~ const LARGE_INTEGER &count) ~ { ~ // Suspicious: lock mutex. ~ static long mutex; ~ while(::InterlockedExchange(&mutex, 1)) ~ Sleep(1); ~ // System time and counter at a previous call. ~ static ULONGLONG saved_time; ~ static ULONGLONG saved_count; ~ // Decode system time and get system time precision ~ ULONGLONG now_time; ~ ::SystemTimeToFileTime(&system_time, ~ reinterpret_cast<FILETIME *>(&now_time)); ~ DWORD sysincrement; ~ { ~ DWORD sysadjust; ~ BOOL sysdisabled; ~ ::GetSystemTimeAdjustment(&sysadjust, &sysincrement, &sysdisabled); ~ } ~ // Convert counter, and get frequency. ~ ULONGLONG now_count = count.QuadPart; ~ LONGLONG frequency; ~ ::QueryPerformanceFrequency( ~ reinterpret_cast<LARGE_INTEGER *>(&frequency)); ~ if(frequency <= 0) { ~ frequency = 1; ~ now_count = 0; ~ } ~ // Release mutex. ~ ::InterlockedExchange(&mutex, 0); ~ // Calculate time now (in FILETIME style measurement) according ~ // to the counter, and calculate drift from system clock. ~ double now = static_cast<double>(now_count - saved_count) ~ * 10000000 / frequency + saved_time; ~ double drift = now - now_time; ~ if(drift < 0) ~ drift = -drift; ~ // Initialize static data on first call, or counter drift. ~ // Adjust time now if counter has drifted. ~ if(saved_count == 0 ~ || now_time < saved_time ~ || now_count < saved_count ~ || drift > sysincrement * 2) { ~ if(saved_count != 0) ~ std::cerr << "DRIFT " << now - now_time << std::endl; ~ saved_time = now_time; ~ saved_count = now_count; ~ now = saved_time; ~ } ~ // Now that we've decided what time it is, break it into time units. ~ ULONGLONG now_ull = static_cast<ULONGLONG>(now); ~ SYSTEMTIME now_systemtime; ~ ::FileTimeToSystemTime(reinterpret_cast<FILETIME *>(&now_ull), ~ &now_systemtime); ~ now_systemtime.wMilliseconds = 0; ~ ::SystemTimeToFileTime(&now_systemtime, ~ reinterpret_cast<FILETIME *>(&now_ull)); ~ double frac_seconds = (now - now_ull)/10000000; ~ // Create date_now and time_duration_now. ~ date_type date_now(now_systemtime.wYear, now_systemtime.wMonth, ~ now_systemtime.wDay); ~ time_duration_type time_duration_now(now_systemtime.wHour, ~ now_systemtime.wMinute, now_systemtime.wSecond, ~ static_cast<ULONGLONG>(frac_seconds ~ * resolution_traits_type::res_adjust())); ~ return time_type(date_now, time_duration_now); ~ } ~ }; } } //namespace date_time #include <iostream> // #include "clock.hpp" #include "boost/date_time/posix_time/posix_time.hpp" using boost::posix_time::ptime; ptime now() { ~ return boost::date_time::win32_clock<ptime>::local_time(); } int main() { ~ using boost::posix_time::seconds; ~ ptime start = now(); ~ ptime last = start; ~ ptime n = last; ~ do { ~ n = now(); ~ if(n == last) ~ std::cerr << "two times equal!\n"; ~ if(n < last) ~ std::cerr << "time went backwards: " << n - last << '\n'; ~ last = n; ~ } while(n < start + seconds(15)); ~ std::cout << n - start << '\n'; ~ return 0; } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAnX8tlp/lhnWsM8QRAjAdAJoDKMO0++1NeO4CMqaY9K+Q/VhvKgCdGS7x aOARRMWjmfr3KrMiDsNH7qk= =M9Kf -----END PGP SIGNATURE-----

4 8

Re: [boost] basic_string interface generator
by Igor Kholodov 18 May '04

18 May '04

>Reece Dunn wrote: >> >> Is there any interest in the ability to generate a basic_string compliant >> interface from a base set of functions in a similar way that the iterator >> adaptors work? > >While I don't have a present need for it, there has been >discussion of various types of strings including ropes and small >string optimized on the list. A utility such as you've proposed >would make writing them easier. > This would also benefit libraries designed specifically for STL strings. See, for example, Common Text Transformation Library, http://cttl.sourceforge.net/. Is there is a need for grammar-based STL string transformations? Igor Kholodov http://cttl.sourceforge.net/

1 0

RE: [boost] basic_string interface generator
by Max Khesin 18 May '04

18 May '04

Just curious: what do you think of Andrei's work on policy-based strings: http://www.cuj.com/documents/s=7994/cujcexp1906alexandr/alexandr.htm http://moderncppdesign.com/code/flex_string.zip - does it do what you want (or leave flexibility to do what you want) - if so why not just use it - if not what doesn't it do m > -----Original Message----- > From: Reece Dunn [mailto:msclrhd@hotmail.com] > Sent: Tuesday, May 18, 2004 2:30 PM > To: boost(a)lists.boost.org > Subject: [boost] basic_string interface generator > > > Is there any interest in the ability to generate a > basic_string compliant > interface from a base set of functions in a similar way that > the iterator > adaptors work? > > I am currently developing a fixed-capacity string class that > complies to the > basic_string interface and have at least 3 variants: > > boost::fixed_string< n, CharT = char, StringPolicy = > std::char_traits< > char > > > boost::char_string > boost::wchar_string > > where fixed_string derives from boost::char_string or > boost::wchar_string > depending on CharT. It may be useful to implement these like this: > > struct char_string: boost::basic_string_impl< char_string > > { > // ... > }; > > void myfn( char_string & s ) > { > // manipulate s like a basic_string or apply C-string functions > } > > So the question is this: are other people interested in this > concept, or is > it better placed as an implementation detail? > > Regards, > Reece > > _________________________________________________________________ > Want to block unwanted pop-ups? Download the free MSN Toolbar now! > http://toolbar.msn.co.uk/ > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

"+" sign in filesystems
by Florian Becker 18 May '04

18 May '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi list, have wondered, why the "+" sign won t work in filesystem lib. So i have added it. I need this, for monotone system control use. Maybe you can add this to the tree for later.. boost_1_31_0/libs/filesystem/src/operations_posix_windows.cpp line 119 only add a "+" sign. I have build patched packages for this. ftp://ftp.yplus.org/monotools/ Cheers, - -- - -------------------------------------------------------- Florian Becker - -------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAqlgGtdIR2yXuDwERAoOPAKDOT1iMwdJVsAVJan68c/UK5RzSaACeKHcu eotMtSZd3cAgsXH+QsGoXSs= =xl4O -----END PGP SIGNATURE-----

2 1

basic_string interface generator
by Reece Dunn 18 May '04

18 May '04

Is there any interest in the ability to generate a basic_string compliant interface from a base set of functions in a similar way that the iterator adaptors work? I am currently developing a fixed-capacity string class that complies to the basic_string interface and have at least 3 variants: boost::fixed_string< n, CharT = char, StringPolicy = std::char_traits< char > > boost::char_string boost::wchar_string where fixed_string derives from boost::char_string or boost::wchar_string depending on CharT. It may be useful to implement these like this: struct char_string: boost::basic_string_impl< char_string > { // ... }; void myfn( char_string & s ) { // manipulate s like a basic_string or apply C-string functions } So the question is this: are other people interested in this concept, or is it better placed as an implementation detail? Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

2 1

[preprocessor] math macros.
by Cromwell Enage 18 May '04

18 May '04

As promised, I have some results. My work can be found this time at <http://groups.yahoo.com/group/boost/files/pp_math.zip>. The example program is simpler and has been confirmed to work correctly when compiled under MinGW 3.2 and MSVC 7.1 (using the VC 2003 Toolkit). Later on I'll test it using MSVC 6. The usual caveats that apply to other macros (no incrementing, decrementing, or runtime functions with side effects can be called from within parameters) apply here. Once again, comments welcome! Cromwell Enage __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/

1 1

Filesystem iterator suggestion
by Martin 18 May '04

18 May '04

I have used the filesystem library for some time now and noticed that there is no portable way of iterating over files in a directory that matches a pattern. In my applications I often need to find all files in a directory that matches "*.txt" or "input.*". I think it would be a good idea to add another constructor to the directory_iterator that support some primitive wilcards. The support could be limited to "*" at the end or followed by a "." (e.g. "*", "a*.*", "*.txt", "a.*") for (path::directory_iterator itr = directory_iterator(path, "*.txt"); itr != directory_iterator(); ++itr) ... I assume this limited wildcard support could easily be ported to most operating systems. ------------------- Another small improvement that would make the directory_iterator easier to use is to somehow allow it to only list directories or files. In the current implementation you need to create a temporary to use an algorithm on all files in a directory (or use some lambda if construct). std::vector<path> tmp; std::remove_copy_if(directory_iterator(dir), directory_iterator(), back_inserter(tmp), std::ptr_fun(is_directory)) std::for_each(tmp.begin(), tmp.end(), func); instead of just std::for_each(directory_iterator(dir, files_only), directory_iterator(), func);

4 4

Fwd: Bug#247643: boost::format completely broken on ia64
by Domenico Andreoli 18 May '04

18 May '04

hi all, i received this bug report for the Boost debian package version 1.31.0-4, the full log is available at [0]. it is reproducible on ia64 architecture. anybody with in depth knowledge of the format library is able to give me a hint about where the problem might be? i cannot provide any access to the debian project's ia64 box but i'm available to perform any test i'm asked to further delve into the bug. best regards domenico [0] http://bugs.debian.org/247643 ----- Forwarded message from Martin Pool <mbp(a)samba.org> ----- Date: Thu, 06 May 2004 17:03:38 +1000 From: Martin Pool <mbp(a)samba.org> To: submit(a)bugs.debian.org Reply-To: Martin Pool <mbp(a)samba.org>, 247643(a)bugs.debian.org Cc: mbp(a)sourcefrog.net Subject: Bug#247643: boost::format completely broken on ia64 Package: libboost-dev Version: 1.31.0-4 Severity: important X-Debbugs-CC: debian-ia64(a)lists.debian.org Here is a test case, extracted from the examples in http://www.boost.org/libs/format/example/sample_formats.cpp: --------------- #include <iostream> #include <boost/format.hpp> using namespace boost; using namespace std; int main(void) { cout << format("Hello %d!\n") % 69; return 0; } ----------------- I build this with g++ -o boost-format-bug boost-format-bug.cpp On i386 it works fine. On ia64, with g++ 4:3.3.3-2 and libstdc++ 1:3.3.3-6, it crashes. In fact I cannot find any use of the format class other than passing a constant string which does not crash. gdb shows Catchpoint 1 (exception thrown) 0x2000000000149981 in __cxa_throw () from /usr/lib/libstdc++.so.5 (gdb) bt #0 0x2000000000149981 in __cxa_throw () from /usr/lib/libstdc++.so.5 #1 0x20000000000acc50 in std::__throw_length_error () from /usr/lib/libstdc++.so.5 #2 0x200000000012fc30 in std::string::_M_replace_safe<char const*> () from /usr/lib/libstdc++.so.5 #3 0x200000000012ba40 in std::string::append () from /usr/lib/libstdc++.so.5 #4 0x400000000000db60 in boost::io::detail::(anonymous namespace)::mk_str<char, std::char_traits<char> > () #5 0x400000000000c900 in boost::io::detail::(anonymous namespace)::put<char, std::char_traits<char>, int const&> () #6 0x400000000000ac60 in boost::io::detail::distribute<char, std::char_traits<char>, int const&> () #7 0x40000000000076c0 in boost::io::detail::feed<char, std::char_traits<char>, int const&> () #8 0x4000000000003fe0 in boost::basic_format<char, std::char_traits<char> >::operator%<int> () #9 0x4000000000003d00 in main () Regards Martin ----- 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 1

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

18 May '04

Martin wrote: >Do you plan to add more of the basic_string members? I intend to (hopefully) have as close to the basic_string interface as I can get to help interoperability. I have been working on getting core functionality up and running initially, but I am working on adding more basic_string members. >Many of the string algorithms (e.g. trim & replace) seem to require insert >& >erase? I haven't included these yet, but I shall work to get them implemented as soon as I can. I am also thinking about how to implement substrings: either create a std::basic_string or have an internal/external type that operates on const char * instead of const char[ n ], etc. Then there's the issue of compilers/standard libraries that don't have the correct std::reverse_iterator, std::iterator_traits, std::basic_[i/o]stream implementations (sigh). Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

1 0

RE: [boost] Is there interest in a decimal floating-point class?
by Michiel Salters 18 May '04

18 May '04

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Jeff Garland > Sent: maandag 17 mei 2004 14:34 > To: boost(a)lists.boost.org > Subject: Re: [boost] Is there interest in a decimal floating-point > class? > > > On Sun, 16 May 2004 19:26:51 +0200, Richard Kaiser wrote > > I want to ask the boost community if there is interest in a decimal > > floating-point class implementing one or more of the decimal > > floating-point types that are intended to become part of a future C > > and C++ standard. > > At this moment I don't need this, but I've need something > like this in the past and suspect I will again. So I'd like to > see it. Only question is will the compiler vendors get > there first if it's already clear this is going in the standard? It's just a proposal, and I doubt it will become part of the standard. P.J.Plauger wasn't very positive, and NNI (Dutch) voted against it. I'm not aware of other formal votes, though. One problem I saw was that the proposal implemented its types as core language, with semantics that I felt were hard if not impossible to achieve for UDTs (w.r.t. conversion sequences) Regards, -- Michiel Salters Consultant Software Engineering LogicaCMG RTSE1, the Netherlands Michiel.Salters(a)logicacmg.com This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

RE: [boost] Re: [iterator facade] Why is dereference const?
by Max Khesin 18 May '04

18 May '04

> "Neal D. Becker" <ndbecker2(a)verizon.net> writes: Good suggestion! I'll post the modified code if anyone is interested. Yes pleaze. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

3 5

RE: [boost] [Test] Test library failing to build on MetaComm inte l-win32-7.1-vc6
by Rozental, Gennadiy 18 May '04

18 May '04

> Looks simple enough to fix... > > Doug Do you have any suggestions? Gennadiy. P.S. It also fails on Borland, Cameu, and sun compilers. Any suggestions/help very welcome

2 1

[Signals] Borland compile problems
by Douglas Gregor 18 May '04

18 May '04

Hello Borland users/developers, I am unable to get the new Signals implementation to play nicely with Borland and have given up. It seems to want to instantiate classes that should not be instantiated, causing a whole mess of problems I haven't solved. Help would be appreciated; otherwise we might need to drop Borland support to move the library forward :( Doug

2 2

[MPL] Compile-time math metafunctions.
by Cromwell Enage 18 May '04

18 May '04

Hi, all! I spent a bit of time reading Pete Isenesee's article, "Fast Math Using Template Metaprogramming", which can be found in Game Programming Gems, Section 1.2, and it inspired me to implement compile-time versions of some of the standard math functions. Two of the metafunctions even work for complex numbers, using the components as input instead of any particular complex number class. My work so far can be found here: <http://groups.yahoo.com/group/boost/files/mpl_math.zip> Yes, it also provides the math constant PI. Perhaps a constants library can be built on top of this one? I'm holding off on putting this mini-library in the Sandbox until the file hierarchy is reasonably stable; I'm not even sure if the classes are well-structured at this point. For this reason, I'm also holding off on writing documentation; I'm hoping the example program would be simple enough to understand. Please send feedback! Cromwell Enage __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/

4 5

[Boost-bugs] [ boost-Bugs-955768 ] undirected adjacency_matrix example segfaults at print_graph
by SourceForge.net 18 May '04

18 May '04

Bugs item #955768, was opened at 2004-05-18 11:58 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=955768&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Burnce (burnce) Assigned to: Jeremy Siek (jsiek) Summary: undirected adjacency_matrix example segfaults at print_graph Initial Comment: Example 2 from http://www.boost.org/libs/graph/doc/adjacency_matrix.html creates a segfault in the second to last line boost::print_graph(ug, name); Details follow: Program received signal SIGSEGV, Segmentation fault. 0x0804a276 in bool boost::detail::get_edge_exists<char>(char const&, ...) (edge_proxy=@0xc804bbe9) at adjacency_matrix.hpp:84 /usr/include/boost/graph/adjacency_matrix.hpp:84:2923:beg:0x804a276 (gdb) up #1 0x0804ab6b in boost::detail::undir_adj_matrix_out_edge_iter<unsigned, __gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >, unsigned, boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned> >::dereference() const (this=0xbfffead0) at adjacency_matrix.hpp:228 (gdb) up #2 0x0804ab0c in dereference<boost::detail::undir_adj_matrix_out_edge_iter<size_t, __gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >, size_t, boost::detail::matrix_edge_desc_impl<boost::undirected_tag, size_t> > > (f=@0xbfffead0) at iterator_facade.hpp:341 (gdb) up #3 0x0804aae2 in boost::iterator_facade<boost::detail::undir_adj_matrix_out_edge_iter<unsigned, __gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >, unsigned, boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned> >, boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned>, boost::random_access_traversal_tag, boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned>, int>::operator*() const (this=0xbfffead0) at iterator_facade.hpp:442 (gdb) up #4 0x0804aa7b in boost::filter_iterator<boost::detail::does_edge_exist, boost::detail::undir_adj_matrix_out_edge_iter<unsigned, __gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >, unsigned, boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned> > >::satisfy_predicate() (this=0xbfffead0) at filter_iterator.hpp:102 /usr/include/boost/iterator/filter_iterator.hpp:102:2993:beg:0x804aa7b (gdb) up #5 0x0804a9fd in filter_iterator (this=0xbfffead0, f={<No data fields>}, x={<iterator_adaptor<boost::detail::undir_adj_matrix_out_edge_iter<unsigned int, __gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >, unsigned int, boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int> >,__gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >,boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int>,boost::use_default,boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int>,int>> = {<iterator_facade<boost::detail::undir_adj_matrix_out_edge_iter<unsigned int, __gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >, unsigned int, boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int> >,boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int>,boost::random_access_traversal_tag,boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int>,int>> = {<No data fields>}, m_iterator = {<iterator<std::random_access_iterator_tag,char,int,char*,char&>> = {<No data fields>}, _M_current = 0x804d050 ""}}, m_src = 0, m_inc = 3221220248, m_targ = 0, m_n = 6}, end={<iterator_adaptor<boost::detail::undir_adj_matrix_out_edge_iter<unsigned int, __gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >, unsigned int, boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int> >,__gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >,boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int>,boost::use_default,boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int>,int>> = {<iterator_facade<boost::detail::undir_adj_matrix_out_edge_iter<unsigned int, __gnu_cxx::__normal_iterator<char*, std::vector<char, std::allocator<char> > >, unsigned int, boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int> >,boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int>,boost::random_access_traversal_tag,boost::detail::matrix_edge_desc_impl<boost::undirected_tag, unsigned int>,int>> = {<No data fields>}, m_iterator = {<iterator<std::random_access_iterator_tag,char,int,char*,char&>> = {<No data fields>}, _M_current = 0x804d065 ""}}, m_src = 0, m_inc = 3221220260, m_targ = 0, m_n = 6}) at filter_iterator.hpp:61 (gdb) up #6 0x08049f60 in std::pair<boost::adjacency_matrix<boost::undirectedS, boost::no_property, boost::no_property, boost::no_property, std::allocator<bool> >::out_edge_iterator, boost::adjacency_matrix<boost::undirectedS, boost::no_property, boost::no_property, boost::no_property, std::allocator<bool> >::out_edge_iterator> boost::out_edges<boost::no_property, boost::no_property, boost::no_property, std::allocator<bool> >(boost::adjacency_matrix<boost::undirectedS, boost::no_property, boost::no_property, boost::no_property, std::allocator<bool> >::vertex_descriptor, boost::adjacency_matrix<boost::undirectedS, boost::no_property, boost::no_property, boost::no_property, std::allocator<bool> > const&) (u=0, g_=@0xbfffed70) at adjacency_matrix.hpp:529 (gdb) up #7 0x08049cc7 in void boost::print_graph_dispatch<boost::adjacency_matrix<boost::undirectedS, boost::no_property, boost::no_property, boost::no_property, std::allocator<bool> >, char const*>(boost::adjacency_matrix<boost::undirectedS, boost::no_property, boost::no_property, boost::no_property, std::allocator<bool> > const&, char const*, boost::undirected_tag) (G=@0xbfffed70, name=0x804b0fc "ABCDEF") at graph_utility.hpp:201 (gdb) up #8 0x08048e28 in void boost::print_graph<boost::adjacency_matrix<boost::undirectedS, boost::no_property, boost::no_property, boost::no_property, std::allocator<bool> >, char const*>(boost::adjacency_matrix<boost::undirectedS, boost::no_property, boost::no_property, boost::no_property, std::allocator<bool> > const&, char const*) (G=@0xbfffed70, name=0x804b0fc "ABCDEF") at graph_utility.hpp:211 (gdb) up #9 0x08048a9a in main () at undirected_adj_matrix.cc:25 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=955768&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: Newbie to Regex simple test failure...
by Stephan T. Lavavej 18 May '04

18 May '04

[Richard Latter] > I am using regex for the first time on MSVC 6 You DO know that MSVC 6 is an abomination against everything good in the world, right? Right? > bool TestStr (std::string& szExpr Hungarian notation is evil. And here, you're not even using it correctly. std::string's aren't lame null-terminated C strings. And you should take the first argument by const reference. > bool bResult=false; This would, uhhh, be better written as return regex_match(... I guess you do this in TestStr2, which doesn't take either of its arguments by const reference like it should. > boost::regex_match(szSearch, cExpr); Wouldn't you like to be a Koenig lookup too?</Johnny Five> > it appears thta the boost::regex declaration > fails Is the regex, which you do not provide here, correctly formed? > 1. Wht doesn't any of the functions work? I'd tend to blame your crummy compiler (although Boost does bend over backwards to support twentieth century technology). Stephan T. Lavavej http://nuwen.net

1 0

Re: [boost] Re: Re: [iterator facade] Why is dereference const?
by John Torjo 18 May '04

18 May '04

>>> >>Yes, there is. >>rtl (Range Templates Library) has a generate_iterator. >> >>You have a generator, and a stopper. From these, you create an input >>iterator sequence. The stopper tells you when you've reached end. >> >>For instance: >>// input iterator sequence - 20 fibonacci numbers >>generated(fibonacci(), gen_n(20)) >> >>// input iterator sequence - fibonacci numbers up to 200 >>generated(fibonacci(), gen_upto(200)) >> >>You can use it like this: >>rng::copy( generated(fibonacci(), gen_upto(200)), >>std::ostream_iterator<int>(std::cout," ")); >> >>The rtl (and the generate* examples) can be found at: >>www.torjo.com/code/for_boost.zip >> >> > >The RTL approach looks very interesting. There is a lot to digest here. > >What is the state of maturity of this code? Would you consider it ready for >use? > I would think so. I've used it successfully in 6 projects so far, 3 of them being > 100000 lines of code each. Best, John -- John Torjo Freelancer -- john(a)torjo.com -- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!

1 0

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

17 May '04

John Nagle wrote: > That's an older version, though; the strings have >no length field, and you said you were putting one in. >Should I do that? I have been busy with other things. I have finally gotten around to updating the code, which now includes: * internal length tracking * null-termination as a given (i.e. it will no longer work in data structure headers for signature checking, etc.) * safe_strings.hpp uses your strategy of putting the C-string functions in the global namespace (I would have liked a better approach to this). #include <boost/fixed_string/safe_strings.hpp> // ... boost::char_string< 15 > cstr; strcpy( cstr, "Meine Grosse Welt!" ); std::cout << cstr << '\n'; sprintf( cstr, "Hello %d Worlds!", 10 ); std::cout << cstr << '\n'; Results in: Meine Grosse W Hello 10 World Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

2 1

[iterator facade] Why is dereference const?
by Neal Becker 17 May '04

17 May '04

In iterator_facade.hpp: reference operator*() const Why the const? I am writing function_input_iterator (again), using iterator_facade. The functor used as a generator may not be const - it might well have state. Therefore, dereference changes the state, and so isn't const.

6 12

Fwd: Mailman privacy alert: What is going on?
by Paul C. Leopardi 17 May '04

17 May '04

Hi, I'm currently subscribed to boost-users and have just tried to subscribe to the boost developers mailing list. In response, I have received the following message. What is going on? Am I subscribed or not? If I am subscribed, then why am I not receiving any messages from or reminders about the boost developers mailing list, while I am receiving messages from and reminders about the boost-users mailing list? The last boost digest I received was dated 2002-10-30 20:26. Excerpt included below. Thanks ---------- Forwarded Message ---------- Subject: Mailman privacy alert Date: Monday 17 May 2004 15:53 From: boost-bounces(a)lists.boost.org To: leopardi(a)bigpond.net.au An attempt was made to subscribe your address to the mailing list boost(a)lists.boost.org. You are already subscribed to this mailing list. Note that the list membership is not public, so it is possible that a bad person was trying to probe the list for its membership. This would be a privacy violation if we let them do this, but we didn't. If you submitted the subscription request and forgot that you were already subscribed to the list, then you can ignore this message. If you suspect that an attempt is being made to covertly discover whether you are a member of this list, and you are worried about your privacy, then feel free to send a message to the list administrator at boost-owner(a)lists.boost.org. ------------------------------------------------------- Boost Digest, Vol 174, Issue 1 From: boost-request(a)lists.boost.org To: boost(a)lists.boost.org Date: 2002-10-30 20:26 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/MailArchives/boost/ Today's Topics: 1. Re: Reference documentation: one approach (Peter Simons) 2. Re: signals questions (Douglas Gregor) 3. Re: Reference documentation: one approach (Beman Dawes) 4. Boost.Bind: problem binding auto_ptr arguments (Gustavo Guerra) 5. Re: Reference documentation: one approach (Carl Daniel) 6. Re: Reference documentation: one approach (David Abrahams) 7. Re: namespace organization (was Poisoning Koenig lookup) (David Abrahams) 8. Re: Re: Reference documentation: one approach (David Abrahams) 9. Re: Reference documentation: one approach (David Abrahams) 10. Re: Reference documentation: one approach (Douglas Gregor) 11. Signals Question (David Abrahams) 12. typeof() substitute. (David Abrahams) 13. Re: Re: Reference documentation (Anthony Williams) 14. typeof() substitute. (Anthony Williams) 15. RE: Reference documentation: one approach (Anthony Williams) 16. Re: Reference documentation: one approach (Mattias Flodin) [...]

1 0

[MPL] Lambda
by David B. Held 17 May '04

17 May '04

Ok, suppose we have a policy-based class Foo, and a policy P: template <typename Policy> class Foo { // ... }; struct P { template <typename T> struct apply { typedef policy type; }; }; Now, my understanding is that we can use Lambda so that we can invoke Foo this way: Foo<P> f; Or define P in this way: template <typename T> struct P { // policy }; and call Foo this way: Foo<P<_> > f; But if I require that everyone define P in the first way, then Lambda should not be necessary, is that correct? Is there still a reason to use Lambda in that case? Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.683 / Virus Database: 445 - Release Date: 5/12/2004

4 6

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

16 May '04

John Nagle wrote: >Could you put it in the Boost sandbox, please? I'm not a >Yahoo customer, and prefer not to become one. It is now in the sandbox (boost-sandbox/boost/fixed_string/*.hpp) :). Regards, Reece _________________________________________________________________ Get a FREE connection, FREE modem and one month's FREE line rental, plus a US or European flight when you sign up for BT Broadband! http://www.msn.co.uk/specials/btbroadband

2 1

thread_specific_ptr suggestion
by Howard Hinnant 16 May '04

16 May '04

thread_specific_ptr<T> is the thread local data storage mechanism of the excellent (thanks William!) boost threads library. thread_specific_ptr<T> isn't capable of supporting custom deleters for good reason. The deleter function must be a real function (not a functor) so as to work well with various OS level threading api's (like Posix threads). So the pointer passed into a thread_specific_ptr<T> (via reset) must be free-able with delete. thread_specific_ptr<T> could offer a custom deleter constrained to be a function pointer instead of a more general deleter policy (functor), but that seems like it would be of limited functionality and frankly just not much fun in a C++ environment. However, there is one case where another deleter policy is common enough to warrant special attention: delete []. So I suggest a partial specialization for thread_specific_ptr: template <class T> class thread_specific_ptr<T[]> { public: thread_specific_ptr(); ~thread_specific_ptr(); T* get() const; T& operator[](std::size_t i) const; T* release(); void reset(T* p = 0); private: thread_specific_ptr(const thread_specific_ptr&); thread_specific_ptr& operator=(const thread_specific_ptr&); }; In this case, any pointers owned by thread_specific_ptr<T[]> must be free-able with delete []. thread_specific_ptr<int> value; thread_specific_ptr<int[]> array_value; void foo() { value.reset(new int); array_value.reset(new int [3]); ... } -Howard

2 1

[Spirit] Grammar as parser problem
by David B. Held 15 May '04

15 May '04

In the program below, I am having trouble using a grammar as a parser for a rule. In particular, I get an error with gcc 3.3 on the line: Module_ = *Statement; The code below is fully self-contained. Dave //-------------------------------------------------------------------------- - #include <stdexcept> #include <string> #include <iostream> #include <boost/spirit/core.hpp> #include <boost/spirit/iterator/file_iterator.hpp> #include <boost/spirit/attribute.hpp> #include <boost/spirit/tree/ast.hpp> //-------------------------------------------------------------------------- - using namespace boost::spirit; using namespace phoenix; //-------------------------------------------------------------------------- - typedef file_iterator<char> TFileIterator; typedef node_val_data<TFileIterator>::const_iterator_t TNodeIterator; typedef tree_match<TFileIterator>::node_t node_t; typedef tree_match<TFileIterator>::parse_node_t parse_node_t; typedef tree_match<TFileIterator>::container_t trees_t; //-------------------------------------------------------------------------- - enum TRuleID { idModuleTag, idDeclarationTag, idIdentifierTag }; //-------------------------------------------------------------------------- - struct Statement : public grammar<Statement> { template <typename ScannerT> struct definition { public: // Types template <TRuleID ID> struct TRule { typedef rule<ScannerT, parser_context, parser_tag<ID> > type; }; public: // Definition definition(Statement const&) { Declaration_ = root_node_d[Identifier_] >> Identifier_ >> discard_node_d[ch_p(';')]; Identifier_ = lexeme_d[(alpha_p | '_') >> *(alnum_p | '_')]; } typename TRule<idDeclarationTag>::type const& start(void) const { return Declaration_; } public: // Rules typename TRule<idDeclarationTag>::type Declaration_; typename TRule<idIdentifierTag>::type Identifier_; }; }; //-------------------------------------------------------------------------- - struct Module : public grammar<Module> { template <typename ScannerT> struct definition { public: // Types template <TRuleID ID> struct TRule { typedef rule<ScannerT, parser_context, parser_tag<ID> > type; }; public: // Definition definition(Module const&) { Module_ = *Statement; } public: // Rules typename TRule<idModuleTag>::type Module_; } }; //-------------------------------------------------------------------------- - void Generate(std::string const& File); //-------------------------------------------------------------------------- - int main(int argc, char* argv[]) { if (argc > 1) { Generate(argv[1]); } else { std::cout << "No source file specified." << std::endl; } return 0; } //-------------------------------------------------------------------------- - tree_parse_info<TFileIterator> Parse(std::string const& File) { TFileIterator Begin(File.c_str()); TFileIterator End = Begin.make_end(); static Statement Parser; return ast_parse(Begin, End, Parser, space_p); } //-------------------------------------------------------------------------- - void Generate(std::string const& File) { tree_parse_info<TFileIterator> Info = Parse(File); if (!Info.full) { std::cerr << "Parsing failed\n"; std::cerr << "stopped at: \"" << *Info.stop << "\"\n"; return; } node_t const& node = Info.trees[0]; try { std::cout << std::string(node.value.begin(), node.value.end()) << std::endl; } catch (std::runtime_error const& e) { std::cerr << e.what() << std::endl; } } //-------------------------------------------------------------------------- - --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.683 / Virus Database: 445 - Release Date: 5/12/2004

1 2

big_integer numeric error
by Joel Young 15 May '04

15 May '04

I believe there is a numeric error in big_integer. I am working to isolate it to a single operation. I can find the error now because the library is fast enough to run one of my sims. I get a different value when running with rational<big_integer> then with any of these choices (which give identical results) rational<long long> rational<big_integer (cln)> rational<big_integer (gmp)> cln::cl_RA Not that it is much use but the wrong answers are: Inonsistent Value: 38485535445/562949953421312 6375930541/562949953421312 Consistent Value: 42780502741/562949953421312 10670897837/562949953421312 Again, I'll try to narrow down the exact point where things go wrong but it might take a while. Joel

3 4

Re:[boost] [serialization] function pointers
by Robert Ramey 15 May '04

15 May '04

Christoph Ludwig wrote: > Is it possible with the serialization library to serialize function > pointers and pointers to member functions? If it is not directly > supported, is there a "best practice" workaround? I didn't find this > info in the documentation. There's no information in the documentation about this. I'm not sure what it would mean to serialize a function pointer. Its possible it might be done by just defining non-intrusive serialize(ar, fp) as and empty function. I would have to think about this. However, I do believe that serialization of a function object would present no new issues. Then there is the possibility of creating a wrapper which makes a function object out a function pointer and serializing that. I'm sure already contains some objects of this nature. Please investigate this and report back. > BTW: Is the version of the serialization library available at > http://www.rrsd.com/boost/ still the most recent or is there a post > review version? Yes, a post review version hasn't been submitted yet. Robert Ramey

3 2

RE: [boost] Re: [iterator facade] Why is dereference const?
by Max Khesin 15 May '04

15 May '04

> -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > > > > Actually, I like the one based on Vladimir Prus much better > than the one I > > wrote, so here is the current: > > I don't love it. Count is overkill; you only need a bool. Also it > only works when value_type is default-constructible. There's a > reason I suggested optional<value_type>, you know ;-) But Neal wants the function to be called count times; how would you do this without a count? thanks\max This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

RE: [boost] Re: Latest ScopeGuard
by Max Khesin 15 May '04

15 May '04

This is funny in the light of Robert R.'s remark that you boostified his version. Anyway it seems like a high priority that the more experienced boost guys should get a basic version of this pushed through before we get 20 slightly different versions sneaking in via the libraries being incorporated into boost. Consensus may be more important than perfection at this stage. max. -----Original Message----- From: Pavel Vozenilek [mailto:pavel_vozenilek@hotmail.com] Sent: Friday, May 14, 2004 2:02 PM To: boost(a)lists.boost.org Subject: [boost] Re: Latest ScopeGuard "Max Khesin" <MKhesin(a)liquidnet.com> wrote: > I recall there have been sevral attempts at a boostified version of Andrei > A. ScopeGuard. I want to start using this functionality and was wondering > a) if there is any consensus about best/most boost-consistent implementation > b) if there is there is a version in the library approval pipeline (or some > definite plans for including this functionality in boost) > thanks, > Multi index container library includes ScopeGuard (almost verbatim from Andrei) until some boost-wide solution appears. /Pavel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

4 4

Questions about the timestamp webbot
by JOAQUIN LOPEZ MU?Z 15 May '04

15 May '04

Reading the documentation guidelines by Bill Kempf I stumbled upon the suggestion of using the so called timestamp "webbot": <p>Revised  01 January, 2001  </p> I've got some questions about this: 1. Is this feature still supported by the Boost web site? 2. What is the checksum stuff? Googling for this yield no info. 3. Where can I find info on the date formats supported 4. Suppose I've got an HTML doc written on May 10 like this:  10 May, 2004  and later on, say May 15th, I update some of its contents and commit the changes to the CVS *without manually replacing the revision date*. Which of these two possibilities happens (if any)? 3a. When I retrieve the HTML doc from CVS again, it has automatically been changed to  15 May, 2004  3b. The "10 May, 2004" stays untouched though it is correctly displayed as "15 May, 2004" when the doc is served by Boost web site. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

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

15 May '04

John Nagle wrote: > Is the code in the Boost sandbox yet? Given the various possible implementation strategies and the fact that the code is currently likely to change rapidly, I have uploaded it to the Boost files section (in the CCompat folder) with the associated files. I will move it to the sandbox when the major issues have been settled and the class is more complete. I have added an mpl implementation of a zero-buffer check, so it will be picked up at compile-time, rather than at run-time with a message similar to: error: 'value' is not a member of zero_buffer_error. Beside that change, I haven't had chance to process the other comments/ideas that have come up. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

RE: [boost] Re: Latest ScopeGuard
by Max Khesin 14 May '04

14 May '04

I understand, and I wish I could do this myself, but I do not feel qualified at this point. I am just pointing out that this is going to become a problem due to inconsistent versions of the same idiom making it into the boost via sub-libraries. So if someone qualified wants to propose (X || Y || ScopeGuard) they should consider this as a factor. This is what I meant. regards, max > -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Friday, May 14, 2004 4:23 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Latest ScopeGuard > > > Max Khesin <MKhesin(a)liquidnet.com> writes: > > > This is funny in the light of Robert R.'s remark that you boostified > > his version. Anyway it seems like a high priority that the more > > experienced boost guys should get a basic version of this pushed > > through before we get 20 slightly different versions sneaking in via > > the libraries being incorporated into boost. Consensus may be more > > important than perfection at this stage. max. > > We don't "get ____ pushed through", though. Someone has to make a > library proposal. > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

RE: [boost] Re: Finding operator==(directory_iterator&, directory_iterator&)
by DY, JERRY U (SBCSI) 14 May '04

14 May '04

I'm learning so much reading at the boost code, which is one of the reasons why I'm getting so excited. Please bear with my questions. The compiler appears to be having a problem with matching this operator== due to the return type, it can't find enable_if_interoperable<...>::type. Here's how aC++ expanded the macro BOOST_ITERATOR_FACADE_RELATION from your previous e-mail. template < class Derived1, class V1, class TC1, class R1, class D1 , class Derived2, class V2, class TC2, class R2, class D2 > inline typename detail::enable_if_interoperable< Derived1, Derived2 , typename mpl::apply2<detail::always_bool2,Derived1,Derived2>::type >::type operator ==( iterator_facade<Derived1, V1, TC1, R1, D1> const& lhs , iterator_facade<Derived2, V2, TC2, R2, D2> const& rhs) { typedef ::boost::static_assert_test< sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)( ( is_interoperable< Derived1, Derived2 >::value ) ) >)> boost_static_assert_typedef_622; return iterator_core_access::equal( static_cast<Derived1 const&>(lhs) , static_cast<Derived2 const&>(rhs) , is_convertible<Derived2,Derived1>() ); } enable_if_interoperable is declared as follows. It's empty, and since it inherits privately from enable_if, none of enable_if's members would be visible. Now where is the struct member "type"??? template <class Facade1, class Facade2, class Return > struct enable_if_interoperable: ::boost::iterators::enable_if< mpl::or_< is_convertible<Facade1, Facade2> , is_convertible<Facade2, Facade1> >, Return > { }; Thanks! -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams Sent: Wednesday, May 12, 2004 2:54 PM To: boost(a)lists.boost.org Subject: [boost] Re: Finding operator==(directory_iterator&,directory_iterator&) "DY, JERRY U (SBCSI)" <jd2419(a)sbc.com> writes: > In trying to compile the filesystem library, I'm getting an error that > the compiler cannot find the operator== for the following function: > > bool is_empty_directory( const fs::path & dir_path ) > { > return fs::directory_iterator(dir_path) == end_itr; > } > > aCC-C++-action > ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/acc/debug > /operations_posix_windows.o > Error 226: > "../../../libs/filesystem/build/../src/operations_posix_windows.cpp", > line 176 # No appropriate function found for call of 'operator =='. > > class directory_iterator doesn't declare it, neither do ancestors > iterator_facade and iterator_facade_types. Can't find free function for > operator==(directory_iterator&, directory_iterator&), > operator==(iterator_facade&, iterator_facade&), > operator==(iterator_facade_types&, iterator_facade_types&) or any of its > variants. Is it using the default compiler-generated operator== in > directory_iterator? The compiler is wrong. There is an operator== that takes two iterator_facade specializations in iterator_facade.hpp, generated by this line: BOOST_ITERATOR_FACADE_RELATION(==, return, equal) Try preprocessing the source if you need to see it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

RE: [boost] RE: Re: [iterator facade] Why is dereference const?
by Max Khesin 14 May '04

14 May '04

> > I think another alternative would be to use this for counting > > functionality: > > > http://www.boost.org/libs/iterator/doc/counting_iterator.html and dumb > > down your function_input_iterator to be a very simple Incrementable. > > m. > > Any reason to prefer that approach? Not really, after some pondering I think it would make things harder. Thanks for posting your solution. max. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

1 0

RE: [boost] Re: [iterator facade] Why is dereference const?
by Max Khesin 14 May '04

14 May '04

I think another alternative would be to use this for counting functionality: http://www.boost.org/libs/iterator/doc/counting_iterator.html and dumb down your function_input_iterator to be a very simple Incrementable. m. -----Original Message----- From: Neal D. Becker [mailto:ndbecker2@verizon.net] Sent: Friday, May 14, 2004 12:01 PM To: boost(a)lists.boost.org Subject: [boost] Re: [iterator facade] Why is dereference const? David Abrahams wrote: > "Neal D. Becker" <ndbecker2(a)verizon.net> writes: > >> Max Khesin wrote: >> >>> >>>> "Neal D. Becker" <ndbecker2(a)verizon.net> writes: >>> >>> Good suggestion! I'll post the modified code if anyone is interested. >>> >>> >>> >>> Yes pleaze. >> >> Here is the current version: > > distance_to doesn't belong here, and you can eliminate the > corresponding cnt. > Actually, I like the one based on Vladimir Prus much better than the one I wrote, so here is the current: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.

2 1

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

14 May '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Rob Stewart wrote: > > >From: John Nagle > Reece Dunn wrote: > > The idea is to prevent overrun when this type of situation occurs. Thus, >it > > will be a 3 character buffer with the extra character being a > > null-terminator. > >I think we're miscommunicating, and it's probably me >misinterpreting something. > >The four byte matter was raised because someone wanted to be able >to peek into a buffer of data read from a file. The 5th byte That was me :). I was suggesting that one possible application for this type of class was in managing header files of binary data, e.g. tar files, doing things like: struct tar_header { ... boost::char_string< 6 > magic; } hdr; if( hdr.magic == "ustar\x20\x20\0" ) // process GNU TAR file >wasn't a null terminator and it shouldn't be changed, so I took >that to suggest effectively overlaying a char_string on that >file's contents in the buffer. I have revised my initial idea of supporting both null-terminated and non-terminated string buffers in response that (a) boost::array< char, N > is a good candidate for hte latter, and (b) adding a boolean template parameter to select null termination and the associated code made the logic too complex. > > > > >> IOW, make it a runtime error to fix the capacity too small to > > > > >> permit null termination when calling c_str(). That still leaves > > > > >> room for things like the 4-character file signature to which you > > > > >> referred, and yet prevents buffer overrun, but doesn't require > > > > >> foregoing flexibility. > > > > > > > > If you want a 4-char file signature, you can use > > > > "boost::array<char,4>", which does that job. Is there any > > > > real need for that functionality in char_string? > > > > Isn't boost::array specific to generic arrays, whereas using a variant >of > > char_string, you can use string functions that will be optimized for >string > > operations. This is the main reason for using a special string class. > >You're right that using boost::array doesn't offer any string >facilities. Perhaps what we need is a string library that uses >all namespace scope functions and type generators to generalize >the notion of a string (this is not unlike Thorsten's >CollectionTraits library). Then, a boost::array<char,N>, a >std::string, even a C string can be treated generically as a >string. With such a facility, boost::array would work just fine >for the file signature example and char_string would be relieved >from needing to handle the "no terminator" case. Doesn't the string algorithms library do just that? > > > > What about the base class issue? There's a need to be able to > > > > write something like "char_string_base& s" when you want to > > > > pass around fixed-capacity strings of more than one capacity. > > > > > >If that is a necessary feature, then the length can be stored in > > >the base class. However, such a base class means that the dtor > > >must be virtual. Is vtable overhead acceptable in such a class? > > >Perhaps two types are needed. > > > > My design does not use a virtual base class, so that isn't an issue. >John > > Nagle's version does, so that is where the problem arises. I have >several > > issues with the use of a virtual base class: > >A "virtual base class" or a base class with a virtual function? Base class with a set of virtual functions (my mistake). > > [1] If you want to operate on a variable length character string > > specifically, why not templatize the function: > > template< int n > > > void myfn( boost::char_array< n > & s ){ ... } > >The issue had to do with being able to create collections of >variable sized string objects. Hmmm. That could be tricky :(. > > [2] How do you deal with wide-character strings? My update generalizes >to > > support char and wchar_t based buffers, but with a virtual base class, >you > > are limited to char buffers. > >That's true only if the character type is encoded in the base >class. Why would it be? You need to know the character type you are operating on in the base class. This is the basic idea that John Nagle's approach takes: class char_string_base { public: virtual std::size_t length() const; virtual const char * c_str() const; virtual void copy( const char * ); }; But I agree with John's comments that it may be necessary to have a wchar_string_base to support wide characters. > > [3] One of the reasons for having a virtual class is to supply custom >string > > operations, e.g. using Windows-specific string functions instead of the > > standard library ones. This can also be solved with a policy template >like > > that found in basic_string. My current version uses this approach, >improving > > interoperability with basic_strings. > >You can certainly design an ABC with many pure virtual functions >that the derived types implement, but that was never the intent >of the base class idea. > >Your policy approach will permit a lot of custimization, but >perhaps the better approach is to externalize all operations. Can you expand on what you mean by externalize. Regards, Reece _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

3 2

Re:[boost] Latest ScopeGuard
by Robert Ramey 14 May '04

14 May '04

Max Khesin > I recall there have been sevral attempts at a boostified version of > Andrei A. ScopeGuard. I want to start using this functionality and was > wondering > a) if there is any consensus about best/most boost-consistent > implementation > b) if there is there is a version in the library approval pipeline > (or some definite plans for including this functionality in boost) > thanks. Take a look at the serialization library (www.rrsd.com/boost/) which contains state_saver.hpp and a manual page. I did this because I needed it and was inspired by Daryl Walkers I/O state saver. Pavel V. made many improvements and to my mind effectively "boostified" it. Only did I much later become aware of the ScopeGard in the files section. I would much like to see this promoted out of the serialization library. Perhaps, even the original i/o state_savers might be slightly refactored to use the general state_saver. Robert Ramey

1 0

[Test] Test library failing to build on MetaComm intel-win32-7.1-vc6
by Douglas Gregor 14 May '04

14 May '04

Looks simple enough to fix... Doug

1 0

[Boost-bugs] [ boost-Support Requests-954048 ] Jam Fails to Build
by SourceForge.net 14 May '04

14 May '04

Support Requests item #954048, was opened at 2004-05-14 08:50 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=954048&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jim McKelvey (jmckelvey) Assigned to: Nobody/Anonymous (nobody) Summary: Jam Fails to Build Initial Comment: Jam fails to build on Solaris SPARC with recent gcc: mushroom~...jam_src>sh build.sh ### ### Using 'gcc' toolset. ### rm -rf bootstrap.gcc mkdir bootstrap.gcc gcc -o bootstrap.gcc/jam0 command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c ./bootstrap.gcc/jam0 -f build.jam --toolset=gcc --toolset-root= clean Segmentation Fault - core dumped mushroom~...jam_src>uname -a SunOS mushroom 5.7 Generic_106541-19 sun4u sparc SUNW,Ultra-2 mushroom~...jam_src>gcc -v Reading specs from /mnt/home3/utilities/lib/gcc/sparc-sun-solaris2.7/3.5.0/specs Configured with: /mnt/home3/utilities/gcc/configure --prefix=/mnt/home3/utilities --verbose --with-as=/mnt/home3/utilities/bin/as --with-ld=/mnt/home3/utilities/bin/ld --with-gnu-as --with-gnu-ld --disable-multilib --enable-languages=c++ Thread model: posix gcc version 3.5.0 20040324 (experimental) Traceback from gdb: (gdb) bt #0 0xff370cec in seg2 () from /usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1 #1 0xff37088c in blalign () from /usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1 #2 0x00028098 in extend_full () #3 0x000282e8 in string_append_range () (gdb) quit ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=954048&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Re: [Boost-users] Re: How to compile minimal_test.cpp with gcc?
by Douglas Gregor 14 May '04

14 May '04

On Friday 14 May 2004 09:28 am, Gennadiy Rozental wrote: > libs/test/src/execution_monitor.cpp: No such file or directory > > There should be ..boost/libs directories installed with all source (cpp) > and docs files files. I remember it was reported already that some > procedure does not install it. I strongly disagree. The headers in $BOOST_ROOT/boost should be self-contained, and their use should require only prebuild libraries (.a, .so, .dll, .lib, etc). If as a developer you need to access ../boost/libs, then I suggest those files be moved into $BOOST_ROOT/boost. Doug

2 1

big_integer cln and gmp
by Joel Young 14 May '04

14 May '04

Feature Request: Can support for alternate numerics packages be specified in the type declaration for big_integer rather then with a macro? I'd like to be able to have multiple implementations declared in the same program. Joel

2 2

[Boost-bugs] [ boost-Bugs-953876 ] Bug in build via MSVC Solution
by SourceForge.net 14 May '04

14 May '04

Bugs item #953876, was opened at 2004-05-14 15:03 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=953876&group_i… Category: test Group: None Status: Open Resolution: None Priority: 5 Submitted By: sdanil (sdanil) Assigned to: Beman Dawes (beman_dawes) Summary: Bug in build via MSVC Solution Initial Comment: When build via %boost%\libs\test\build\msvc71_proj\boost_test_library.sln uniX_test_framework.lib is created. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=953876&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

regex lib bug: failed assertion in perl_matcher
by Benzinger, Ralph 14 May '04

14 May '04

Hello, When searching for regex "(a)(?:b)" with the nosubs flag set, perl_matcher cores with failed assertion "m.subs() > 2" in perl_matcher.hpp, match_results::set_second(). Regards, Ralph

2 1

Regex Documentation Issue (and two pings)
by Stephan T. Lavavej 14 May '04

14 May '04

I was just bitten by an extremely nasty bug, caused in part by my own foolishness, but also by a subtlety of Boost Regex that probably should be documented explicitly. http://boost.org/libs/regex/doc/format_syntax.html gives a list of "The following Perl like expressions" and says that $N "Expands to the text that matched sub-expression N." HOWEVER, Boost Regex is sufficiently general that $10 will match the tenth subexpression, $25 the twenty fifth, and so forth. Perl is not that general - it recognizes only $1 through $9 here. I believed that Boost behaved like Perl. I concatenated "$1" with a random hexadecimal string, occasionally producing "$10", "$15", etc. before the letter hexits appeared. This led to many hours of misery. The documentation should note Boost Regex's generality. The generality is a good thing - $1 can be separated from later digits with empty () parentheses - but it needs to be made clear. Does this also affect the regex standardization proposal? It'd be bad if some implementers thought they only had to support $1 - $9. On an unrelated note, the following issues have not yet been addressed: Lambda Doc Bug, http://lists.boost.org/MailArchives/boost/msg64450.php Boost Array Documentation, http://lists.boost.org/MailArchives/boost/msg64502.php Stephan T. Lavavej http://nuwen.net

2 1

RE: [boost] Lambda/functions
by Roman Yakovenko 14 May '04

14 May '04

>best2=bind(&Node::value2, > bind( &std::vector<Node>::at, //Ask for an element > bind(&Node::children,_1), //Get the vector object > 0 ) //Ask for element zero > ); > > [3]: > function.cpp: In function `int main(int, char**)': > function.cpp:69: no matching function for call to > `bind(<unknown type>, const > > boost::lambda::lambda_functor<boost::lambda::lambda_functor_ba > se<boost::lambda::action<2, > boost::lambda::function_action<2, > boost::lambda::detail::unspecified> >, > boost::tuples::tuple<std::vector<Node, > std::allocator<Node> > Node::*, const > boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, > boost::tuples::null_type, boost::tuples::null_type, > boost::tuples::null_type, boost::tuples::null_type, > boost::tuples::null_type, boost::tuples::null_type, > boost::tuples::null_type, boost::tuples::null_type> > >, int)' > It's simple, compiler can't guess which function "at" you try to bind. See overloading section of lambda documentation. Hint: typedef std::vector<int> ints; typedef ints::const_reference ( ints::*ConstAtFunc ) (ints::size_type) const; Now call bind with ConstAtFunc( at ) as function Roman

2 1

[Boost-bugs] [ boost-Bugs-953818 ] recursive matching for regular expression fails.
by SourceForge.net 14 May '04

14 May '04

Bugs item #953818, was opened at 2004-05-14 01:57 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=953818&group_i… Category: regex Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: John Maddock (johnmaddock) Summary: recursive matching for regular expression fails. Initial Comment: I am looking for regular expression "http://$[^ ]+$+" in a buffer containing following text http://business.jet2web.at. and it failes in file "perl_matcher_non_recursive.hpp" function match_all_states() { ...... if(state_count > max_state_count) raise_error(traits_inst, REG_ESPACE); } I work with bersion BOOST 1.31 in Visual Studio .NET 2003. My User.hpp is attached. I set following flags of compilation: boost::regbase::flag_type reg_flags = boost::regbase::char_classes | boost::regbase::escape_in_lists | boost::regbase::bk_parens | boost::regbase::intervals; Maya ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=953818&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

[serialization] function pointers
by Christoph Ludwig 14 May '04

14 May '04

Is it possible with the serialization library to serialize function pointers and pointers to member functions? If it is not directly supported, is there a "best practice" workaround? I didn't find this info in the documentation. BTW: Is the version of the serialization library available at http://www.rrsd.com/boost/ still the most recent or is there a post review version? Thanks Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

1 0

boost][serialization] Adding State to Archives
by Robert Ramey 14 May '04

14 May '04

Martin Ecker wrote: > One way of achieving all this would, of course, be to derive from one of > the existing archive classes and add the required functionality. > However, we don't want to lose the flexibility of being able to write > out data to a binary, text, XML, or any other archive with some other > kind of representation. So basically we're looking for a good way of > inserting an additional layer in between the archives and the actual > serialize functions that can store state variables. > Have you consider making a template which takes the base class as a parameter? Example template <class BaseArchive> class stately_iarchive : public BaseArchive { ... // your overloads here ... // you extra control functions here }; To be used thusly: // can't use typedef because it typedef does like self-reference class stately_binary_archive : public stately_archive<binary_iarchive_impl<stately_binary_archive> { stately_binary_archive(istream &is, flags = 0) : stately_archive<binary_iarchive_impl<stately_binary_archive>(is, flags); }; Now just use stately_binary_archive anywhere you used binary_archive before. Robert Ramey

2 1

[hash container patch]
by Thorsten Ottosen 14 May '04

14 May '04

Some fixes to the implementation. I couldn't find the a newer version of the container. There are still problems with friends. You should use BOOST_DEDUCED_TYPENAME. br Thorsten begin 666 detail_hash_table_new_old_diff.txt M*BHJ(&AA<VA?=&%B;&4N:'!P"49R:2!-87D@,30@,# Z,30Z,S0@,C P- T* M+2TM(&AA<VA?=&%B;&4N;VQD+FAP< E&<FD@36%Y(#$T(# P.C T.C$P(#(P M,#0-"BHJ*BHJ*BHJ*BHJ*BHJ*@T**BHJ(#(R,"PR,C8@*BHJ*@T*(" @(" @ M(" @(')E='5R;B J8F]U;F0[#0H@(" @(" @('T-"B @#0HA(" @(" @('-T M871I8R!C;VYS="!S=&0Z.G-I>F5?="!D969A=6QT7VEN:71I86Q?8G5C:V5T M7V-O=6YT(#T@-3 [#0H@( T*(" -"B @(" @(" @+R\@97%U:79A;&5N="!K M97ES('-P96-I86QI>F%T:6]N#0HM+2T@,C(P+#(R-B M+2TM#0H@(" @(" @ M(" @<F5T=7)N("IB;W5N9#L-"B @(" @(" @?0T*(" -"B$@(" @(" @8V]N M<W0@<W1A=&EC('-T9#HZ<VEZ95]T(&1E9F%U;'1?:6YI=&EA;%]B=6-K971? M8V]U;G0@/2 U,#L-"B @#0H@( T*(" @(" @(" O+R!E<75I=F%L96YT(&ME M>7,@<W!E8VEA;&EZ871I;VX-"BHJ*BHJ*BHJ*BHJ*BHJ*@T**BHJ(#0Y,"PT M.38@*BHJ*@T*(" @(" @(" @(&YO9&4@*FYE>'0[#0H@(" @(" @('T[#0H@ M( T*(2 @(" @("!T>7!E9&5F('1Y<&5N86UE($%L;&]C.CH@0D]/4U1?3D53 M5$5$7U1%35!,051%(')E8FEN9#QN;V1E/CHZ;W1H97(@;F]D95]A;&QO8V%T M;W([#0H@( T*(" @(" @("!N;V1E7V%L;&]C871O<B!A;&QO8SL-"B @#0HM M+2T@-#DP+#0Y-B M+2TM#0H@(" @(" @(" @;F]D92 J;F5X=#L-"B @(" @ M(" @?3L-"B @#0HA(" @(" @('1Y<&5D968@='EP96YA;64(a)06QL;V,Z.G)E M8FEN9#QN;V1E/CHZ;W1H97(@;F]D95]A;&QO8V%T;W([#0H@( T*(" @(" @ M("!N;V1E7V%L;&]C871O<B!A;&QO8SL-"B @#0HJ*BHJ*BHJ*BHJ*BHJ*BH- M"BHJ*B U,#(L-3$W("HJ*BH-"B @#0H@(" @("!P<F]T96-T960Z#0H@( T* M(2 @(" @("!T>7!E9&5F('1Y<&5N86UE($%L;&]C.CH@0D]/4U1?3D535$5$ M7U1%35!,051%(')E8FEN9#QN;V1E("H^.CIO=&AE<B!B=6-K971?86QL;V-A M=&]R.PT*(" -"B @(" @(" @8G5C:V5T7V%L;&]C871O<B!G971?8G5C:V5T M7V%L;&]C871O<B@I('L-"B @(" @(" @("!R971U<FX@8G5C:V5T7V%L;&]C M871O<BAA;&QO8RD[#0H@(" @(" @('T-"BT@(" @(" @#0HM(" @(" @(&-O M;G-T(&)U8VME=%]A;&QO8V%T;W(@9V5T7V)U8VME=%]A;&QO8V%T;W(H*2!C M;VYS= T*+2 @(" @("![#0HM(" @(" @(" @("!R971U<FX@8G5C:V5T7V%L M;&]C871O<BAA;&QO8RD[#0HM(" @(" @('T-"B @#0H@(" @(" @(&AA<VAE M<B!H9CL-"B @(" @(" @:V5Y7V5Q=6%L(&5Q.PT*+2TM(#4P,BPU,3(@+2TM M+0T*(" -"B @(" @('!R;W1E8W1E9#H-"B @#0HA(" @(" @('1Y<&5D968@ M='EP96YA;64(a)06QL;V,Z.G)E8FEN9#QN;V1E("H^.CIO=&AE<B!B=6-K971? M86QL;V-A=&]R.PT*(" -"B @(" @(" @8G5C:V5T7V%L;&]C871O<B!G971? M8G5C:V5T7V%L;&]C871O<B@I('L-"B @(" @(" @("!R971U<FX@8G5C:V5T M7V%L;&]C871O<BAA;&QO8RD[#0H@(" @(" @('T-"B @#0H@(" @(" @(&AA M<VAE<B!H9CL-"B @(" @(" @:V5Y7V5Q=6%L(&5Q.PT**BHJ*BHJ*BHJ*BHJ M*BHJ#0HJ*BH@-C0P+#8T-B J*BHJ#0H@(" @(" @(" @(" ^('L-"B @(" @ M(" @(" -"B @(" @(" @("!F<FEE;F0@8VQA<W,@8F]O<W0Z.FET97)A=&]R M7V-O<F5?86-C97-S.PT*(2 @(" @(" @("\O9G)I96YD(&-L87-S(&)A<VEC M7VAA<VA?=&%B;&5?='EP93L@+R\@<')O8FQE;0T*(" -"B @(" @(" @("!T M96UP;&%T92 \8VQA<W,^(&9R:65N9"!C;&%S<R!I=&5R871O<E]B87-E.PT* M(" -"BTM+2 V,S4L-C0Q("TM+2T-"B @(" @(" @(" @(#X@>PT*(" @(" @ M(" @( T*(" @(" @(" @(&9R:65N9"!C;&%S<R!B;V]S=#HZ:71E<F%T;W)? M8V]R95]A8V-E<W,[#0HA(" @(" @(" @9G)I96YD(&-L87-S(&)A<VEC7VAA M<VA?=&%B;&5?='EP93L-"B @#0H@(" @(" @(" @=&5M<&QA=&4@/&-L87-S M/B!F<FEE;F0@8VQA<W,@:71E<F%T;W)?8F%S93L-"B @#0HJ*BHJ*BHJ*BHJ M*BHJ*BH-"BHJ*B V.3@L-S V("HJ*BH-"B @#0H@(" @(" @(&-L87-S(&ET M97)A=&]R(#H@<'5B;&EC(&ET97)A=&]R7V)A<V4\=F%L=65?='EP93X@>PT* M(" -"B$@(" @(" @(" O+V9R:65N9"!C;&%S<R!B87-I8U]H87-H7W1A8FQE M7W1Y<&4[("\O('!R;V)L96T-"B @#0HA(" @(" @(" @+R]F<FEE;F0@<W1R M=6-T('-P96-I86QI>F5D7V]P97)A=&EO;G,[#0H@( T*(" @(" @(" @(&9R M:65N9"!C;&%S<R!C;VYS=%]I=&5R871O<CL-"B @(" @(" @("!T>7!E9&5F M(&ET97)A=&]R7V)A<V4\#0HM+2T@-CDS+#<P,2 M+2TM#0H@( T*(" @(" @ M("!C;&%S<R!I=&5R871O<B Z('!U8FQI8R!I=&5R871O<E]B87-E/'9A;'5E M7W1Y<&4^('L-"B @#0HA(" @(" @(" @9G)I96YD(&-L87-S(&)A<VEC7VAA M<VA?=&%B;&5?='EP93L-"B @#0HA(" @(" @(" @9G)I96YD('-T<G5C="!S M<&5C:6%L:7IE9%]O<&5R871I;VYS.PT*(" -"B @(" @(" @("!F<FEE;F0@ M8VQA<W,@8V]N<W1?:71E<F%T;W([#0H@(" @(" @(" @='EP961E9B!I=&5R M871O<E]B87-E/ T**BHJ*BHJ*BHJ*BHJ*BHJ#0HJ*BH@-S$X+#<R-B J*BHJ M#0H@( T*(" @(" @("!C;&%S<R!C;VYS=%]I=&5R871O<B Z('!U8FQI8R!I M=&5R871O<E]B87-E/'9A;'5E7W1Y<&4@8V]N<W0^('L-"B @(" @(" @(" - M"B$@(" @(" @(" O+V9R:65N9"!C;&%S<R!B87-I8U]H87-H7W1A8FQE7W1Y M<&4[#0H@(" @(" @(" @#0HA(" @(" @(" @+R]F<FEE;F0@<W1R=6-T('-P M96-I86QI>F5D7V]P97)A=&EO;G,[#0H@( T*(" @(" @(" @('1Y<&5D968@ M:71E<F%T;W)?8F%S93P-"B @(" @(" @(" @('1Y<&5N86UE(&)A<VEC7VAA M<VA?=&%B;&5?='EP93HZ=F%L=65?='EP92!C;VYS= T*+2TM(#<Q,RPW,C$@ M+2TM+0T*(" -"B @(" @(" @8VQA<W,@8V]N<W1?:71E<F%T;W(@.B!P=6)L M:6,@:71E<F%T;W)?8F%S93QV86QU95]T>7!E(&-O;G-T/B![#0H@(" @(" @ M(" @#0HA(" @(" @(" @9G)I96YD(&-L87-S(&)A<VEC7VAA<VA?=&%B;&5? M='EP93L-"B @(" @(" @(" -"B$@(" @(" @("!F<FEE;F0@<W1R=6-T('-P M96-I86QI>F5D7V]P97)A=&EO;G,[#0H@( T*(" @(" @(" @('1Y<&5D968@ M:71E<F%T;W)?8F%S93P-"B @(" @(" @(" @('1Y<&5N86UE(&)A<VEC7VAA M<VA?=&%B;&5?='EP93HZ=F%L=65?='EP92!C;VYS= T**BHJ*BHJ*BHJ*BHJ M*BHJ#0HJ*BH@-SDP+#<Y-B J*BHJ#0H@(" @(" @(" @(" @('1Y<&5N86UE M(&)A<VEC7VAA<VA?=&%B;&5?='EP93HZ=F%L=65?='EP90T*(" @(" @(" @ M(" @/B![#0H@( T*(2 @(" @(" @("\O9G)I96YD(&-L87-S(&)A<VEC7VAA M<VA?=&%B;&5?='EP93L-"B @#0H@(" @(" @(" @='EP961E9B!L;V-A;%]I M=&5R871O<E]B87-E/ T*(" @(" @(" @(" @='EP96YA;64@8F%S:6-?:&%S M:%]T86)L95]T>7!E.CIV86QU95]T>7!E#0HM+2T@-S@U+#<Y,2 M+2TM#0H@ M(" @(" @(" @(" @('1Y<&5N86UE(&)A<VEC7VAA<VA?=&%B;&5?='EP93HZ M=F%L=65?='EP90T*(" @(" @(" @(" @/B![#0H@( T*(2 @(" @(" @(&9R M:65N9"!C;&%S<R!B87-I8U]H87-H7W1A8FQE7W1Y<&4[#0H@( T*(" @(" @ M(" @('1Y<&5D968@;&]C86Q?:71E<F%T;W)?8F%S93P-"B @(" @(" @(" @ M('1Y<&5N86UE(&)A<VEC7VAA<VA?=&%B;&5?='EP93HZ=F%L=65?='EP90T* M*BHJ*BHJ*BHJ*BHJ*BHJ#0HJ*BH@.# X+#@Q-" J*BHJ#0H@(" @(" @(&-L M87-S(&-O;G-T7VQO8V%L7VET97)A=&]R#0H@(" @(" @(" @.B!P=6)L:6,@ M;&]C86Q?:71E<F%T;W)?8F%S93QV86QU95]T>7!E(&-O;G-T/B![#0H@( T* M(2 @(" @(" @("\O9G)I96YD(&-L87-S(&)A<VEC7VAA<VA?=&%B;&5?='EP M93L-"B @#0H@(" @(" @(" @='EP961E9B!L;V-A;%]I=&5R871O<E]B87-E M/ T*(" @(" @(" @(" @='EP96YA;64@8F%S:6-?:&%S:%]T86)L95]T>7!E M.CIV86QU95]T>7!E(&-O;G-T#0HM+2T@.# S+#(a)P.2 M+2TM#0H@(" @(" @ M(&-L87-S(&-O;G-T7VQO8V%L7VET97)A=&]R#0H@(" @(" @(" @.B!P=6)L M:6,@;&]C86Q?:71E<F%T;W)?8F%S93QV86QU95]T>7!E(&-O;G-T/B![#0H@ M( T*(2 @(" @(" @(&9R:65N9"!C;&%S<R!B87-I8U]H87-H7W1A8FQE7W1Y M<&4[#0H@( T*(" @(" @(" @('1Y<&5D968@;&]C86Q?:71E<F%T;W)?8F%S M93P-"B @(" @(" @(" @('1Y<&5N86UE(&)A<VEC7VAA<VA?=&%B;&5?='EP M93HZ=F%L=65?='EP92!C;VYS= T**BHJ*BHJ*BHJ*BHJ*BHJ#0HJ*BH@.38X M+#DW-" J*BHJ#0H@(" @(" @(" @("!R96AA<V@H<W1A=&EC7V-A<W0\<VEZ M95]T>7!E/BAM;&8@*B!N("L(a),2DI.PT*(" @(" @("!]#0H@( T*(2 @(" @ M(" O+V9R:65N9"!S=')U8W0@<W!E8VEA;&EZ961?;W!E<F%T:6]N<SL-"B @ M#0H@(" @("!P=6)L:6,Z#0H@( T*+2TM(#DV,RPY-CD@+2TM+0T*(" @(" @ M(" @(" @<F5H87-H*'-T871I8U]C87-T/'-I>F5?='EP93XH;6QF("H@;B K M(#$I*3L-"B @(" @(" @?0T*(" -"B$@(" @(" @9G)I96YD('-T<G5C="!S M<&5C:6%L:7IE9%]O<&5R871I;VYS.PT*(" -"B @(" @('!U8FQI8SH-"B @ M#0HJ*BHJ*BHJ*BHJ*BHJ*BH-"BHJ*B Q,#4R+#$P-C$@*BHJ*@T*(" -"B @ M(" @(" @=F]I9"!E<F%S92AC;VYS=%]I=&5R871O<B!R*2![#0H@(" @(" @ M(" @<VEZ95]T>7!E(&D@/2!B=6-K970H97AT<F%C=%]K97DH*G(I*3L-"B$@ M(" @(" @("!N;V1E("HJ;F]D95]P;VEN=&5R(#T@8G5C:V5T("L@:3L-"B @ M(" @(" @("!W:&EL92 H*FYO9&5?<&]I;G1E<B A/2!R+FYO9&5?<&]I;G1E M<BD-"B @(" @(" @(" @(&YO9&5?<&]I;G1E<B ]("8H*"IN;V1E7W!O:6YT M97(I+3YN97AT*3L-"B$@(" @(" @("!N;V1E("IN(#T@*FYO9&5?<&]I;G1E M<CL-"B @(" @(" @(" J;F]D95]P;VEN=&5R(#T@;BT^;F5X=#L-"B @(" @ M(" @("!N+3Y^;F]D92(a)I.R O+R!M=7-T(&YO="!T:')O=PT*(" @(" @(" @ M('1R>2![#0HM+2T@,3 T-RPQ,#4V("TM+2T-"B @#0H@(" @(" @('9O:60@ M97)A<V4H8V]N<W1?:71E<F%T;W(@<BD@>PT*(" @(" @(" @('-I>F5?='EP M92!I(#T@8G5C:V5T*&5X=')A8W1?:V5Y*"IR*2D[#0HA(" @(" @(" @;F]D M95]P;VEN=&5R("HJ;F]D95]P;VEN=&5R(#T@8G5C:V5T("L@:3L-"B @(" @ M(" @("!W:&EL92 H*FYO9&5?<&]I;G1E<B A/2!R+FYO9&5?<&]I;G1E<BD- M"B @(" @(" @(" @(&YO9&5?<&]I;G1E<B ]("8H*"IN;V1E7W!O:6YT97(I M+3YN97AT*3L-"B$@(" @(" @("!N;V1E7W!O:6YT97(@*FX@/2 J;F]D95]P M;VEN=&5R.PT*(" @(" @(" @("IN;V1E7W!O:6YT97(@/2!N+3YN97AT.PT* M(" @(" @(" @(&XM/GYN;V1E*"D[("\O(&UU<W0@;F]T('1H<F]W#0H@(" @ -(" @(" @=')Y('L-"@`` ` end

2 4

[Graph] Bundled properties
by Douglas Gregor 14 May '04

14 May '04

Introducing internal properties for vertices and edges is too hard, and is one of the various things that came up in the "forced client complexity" thread. For a simple task, I ended up writing this: -------------------------------------------------------- namespace boost { enum edge_length_t { edge_length }; enum edge_speed_limit_t { edge_speed_limit }; enum edge_direction_t { edge_direction }; enum edge_snow_route_t { edge_snow_route} ; BOOST_INSTALL_PROPERTY(edge, length); BOOST_INSTALL_PROPERTY(edge, direction); BOOST_INSTALL_PROPERTY(edge, speed_limit); BOOST_INSTALL_PROPERTY(edge, snow_route); } typedef boost::adjacency_list< boost::listS, boost::vecS, boost::bidirectionalS, // Vertex properties boost::property<boost::vertex_name_t, std::string>, // Edge properties boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool> > > > > > RouteMap; -------------------------------------------------------- I'm basically enumerating all of the fields in a struct, but it's not represented efficiently (for the human, compiler, or run-time). I'd really like to do something like this: -------------------------------------------------------- struct Intersection { std::string name; }; struct Street { std::string name; double length; int speed_limit; char direction; bool snow_route; }; typedef boost::adjacency_list< boost::listS, boost::vecS, boost::bidirectionalS, Intersection, Street> RouteMap; -------------------------------------------------------- It's a heck of a lot shorter and more intuitive. The attached patch introduces this capability for adjacency_list. The UDT's Intersection and Street are referred to as "bundled properties", and may occur at the end of the vertex or edge property list passed to adjacency_list. Accessing these bundled properties is done using the graph's subscript operator: void foo(Map& g, Map::vertex_descriptor v, Map::edge_descriptor e) { map[v].name = "Albany"; map[e].length = 25.3; } Often one needs a property map for an internal property. With bundled properties this is achieved through an overloaded ->* operator. So if you want to create a property map from edge descriptors to the speed_limit property for a graph g, use: g->*&Street::speed_limit And here's a real usage: void shortest(Map& g, Map::vertex_descriptor from) { dijkstra_shortest_paths(g, from, weight_map(g->*&Street::length)); } The attached patch implements this functionality. It is completely backward-compatible (no new regressions on GCC 3.3.x), includes documentation and a test case, and seems to work well. Comments? Doug

1 1

Why don't lambda funcs work for stl function objects?
by Neal D. Becker 13 May '04

13 May '04

Any reason lambda functions can't meet requirements for std::unary_function, for example? Specifically, it seems result_type is not defined. For example boost::constant(0) doesn't have result_type, so can't be used where a std::unary_function is needed.

3 2

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

13 May '04

Rob Stewart wrote: >From: John Nagle <nagle(a)animats.com> > > > > STL strings are variable-sized, with no limit. When you > > add characters, "size()" increases. Should fixed-size > ^^^^ >I presume you're referring to fixed-capacity strings which can >have a variable size, right? yup. The idea is to make it a buffer-overflow safe replacement for C style character buffers, e.g.: char buf[ 100 ]; ::sprintf( buf, "...", ... ); while allowing it to behave like a basic_string. > > strings be similar? If the STL string operations are > > to be meaningful, they have to be. > >Only if you want to apply mutating algorithms that modify size. >IOW, it isn't unreasonable to choose either fixed-size or >fixed-capacity strings. If the former, then there are no >mutating algorithms that affect the size. If the latter, the >size can change, but an exception occurs when trying to exceed >the capacity. That's the way I see it, but instead of throwing an exception, the class simply prevents overrun and fills the available space, e.g.: char_string< 5 > buf; buf.copy( "Meine Grosse Welt!" ); std::cout << buf << '\n'; // prints "Mein" (null terminated) > > In STL strings, "size" doesn't include a trailing null. > > Using "c_str" can result in expanding the string to add a > > trailing null. With fixed-size strings, we don't have that > > option. > > > > If c_str is provided, there must always be space > > for a trailing null. So you can't use char_string > > when you need a specific fixed length, as for Macintosh > > 4-character file signatures. Perhaps "boost::array<char>" > > is the way to go for that sort of thing. Trying to do > > both null-terminated and non-null-terminated strings > > in the same class will get ugly. > >If the string if fixed-capacity *and* there remains sufficient >capacity, c_str() can null terminate the buffer. If there isn't >sufficient remaining capacity, then throw an exception. > >IOW, make it a runtime error to fix the capacity too small to >permit null termination when calling c_str(). That still leaves >room for things like the 4-character file signature to which you >referred, and yet prevents buffer overrun, but doesn't require >foregoing flexibility. That is a good idea. It will mean keeping track of the string length, but it does permit both versions without requiring complex internals/semasntics or seperate classes. In order to keep interoperability with C style usage (i.e. operator const char *()), we can have the following: inline const char_type * c_str() { // null-terninate buffer: str[ len ] = char_type( '\0' ); return( str ) } inilne operator const char *() { return( c_str()); } Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

5 8

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

13 May '04

Rob Stewart wrote: >From: John Nagle > Reece Dunn wrote: > > > Rob Stewart wrote: > > >> From: John Nagle >You're comparing apples to oranges. Either you mean for the >buffer to be exactly four bytes or you don't. If you do, then >there's no room for a null terminator. You're not dealing with a >"C string" (a null terminated string), you're dealing with a four >byte buffer. If you allocated four bytes for a "C string" and >write "ABCDE" to it, or even strcat() "ABCD" to it, you overrun >the buffer. Why would we want to provide consistent semantics >for that behavior? The idea is to prevent overrun when this type of situation occurs. Thus, it will be a 3 character buffer with the extra character being a null-terminator. > > >> IOW, make it a runtime error to fix the capacity too small to > > >> permit null termination when calling c_str(). That still leaves > > >> room for things like the 4-character file signature to which you > > >> referred, and yet prevents buffer overrun, but doesn't require > > >> foregoing flexibility. > > > > If you want a 4-char file signature, you can use > > "boost::array<char,4>", which does that job. Is there any > > real need for that functionality in char_string? Isn't boost::array specific to generic arrays, whereas using a variant of char_string, you can use string functions that will be optimized for string operations. This is the main reason for using a special string class. > > char_string might have some convenience template functions to > > interconvert "boost::array" and "boost::char_string". > > > > > That is a good idea. It will mean keeping track of the string length, > > > > Yes, that seems to be necessary. > >The question is, which is better: char_string<4> or >boost::array<char,4>? I suggest that the latter is better. In C >code, and similar C++ code, arrays of char are used as buffers of >fixed length and as memory for strings. Code will be clearer if >one uses boost::array<char,N> for the former and char_string<N> >for the latter. Once you make that distinction of purpose, null >termination can be integral to char_string without complication >or unwanted overhead. That makes sense. > > What about the base class issue? There's a need to be able to > > write something like "char_string_base& s" when you want to > > pass around fixed-capacity strings of more than one capacity. > >If that is a necessary feature, then the length can be stored in >the base class. However, such a base class means that the dtor >must be virtual. Is vtable overhead acceptable in such a class? >Perhaps two types are needed. My design does not use a virtual base class, so that isn't an issue. John Nagle's version does, so that is where the problem arises. I have several issues with the use of a virtual base class: [1] If you want to operate on a variable length character string specifically, why not templatize the function: template< int n > void myfn( boost::char_array< n > & s ){ ... } [2] How do you deal with wide-character strings? My update generalizes to support char and wchar_t based buffers, but with a virtual base class, you are limited to char buffers. [3] One of the reasons for having a virtual class is to supply custom string operations, e.g. using Windows-specific string functions instead of the standard library ones. This can also be solved with a policy template like that found in basic_string. My current version uses this approach, improving interoperability with basic_strings. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

3 2

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

13 May '04

Rob Stewart wrote: >From: David Abrahams > John Nagle writes: > > > > > If you're willing to accept a call to "new", you can just > > > use std::string and reserve some initial size. > > > > It's not the same thing. You might only be willing to accept a call > > to "new" if things go beyond a certain length. That's *usually* the > > only reason I'd ever have a fixed-size buffer. Very occasionally > > I'll be in code that where I don't want to throw an exception, but > > then a string that responds to overflow by throwing is no better. > >char_string can throw a more meaningful exception than >std::bad_alloc. > >In the small string optimization or std::string with reserve >approaches, the buffer grows when the input is too large, and >other, downstream code may overflow or behave badly. Stopping >the overflow early may be better and having an automated >mechanism for preventing overflow is wise. There is not meant to be any buffer allocation. char_string is a fixed-capacity string that will not write beyond the length of that buffer. > > > So you don't need that capabiilty in char_string. char_string is > > > for situations when you don't want to invoke dynamic allocation at > > > all. In desktop applications, that's not too common, but in real > > > time work, inside operating systems, and in embedded applications > > > it's not unusual. > > > > I'm saying, it's almost always better to degrade performance > > gracefully as the program's input grows than it is to introduce an > > execution discontinuity like an exception (if possible). In many of > > those scenarios you've named, exceptions, like dynamic allocation have > > been banned anyway for similar real and/or imaginary reasons. > >There's probably room and need for both types of strings. I don't intend the char_string buffer to be increased. I intended that the operations on the buffer would not go beyond the buffer (which would lead to overflow) and also that going over the buffer would not generate an exception. It may be beneficial to have an error policy to determin the behaviour in the event of an overflow. I am not advocating this approach, just putting it up for discussion. The only exception I can see keeping is the one in the constructor to test for a buffer of 0, but this would be better re-implemented as a compile-time check using mpl code, e.g.: template< int n, ... > class char_string { class ok{ typedef char value; }; class zero_buffer_error{}; typedef mpl::if_< mpl::equal< n, 0 >, zero_buffer_error, ok >::value value; }; Regards, Reece _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess

3 2

RE: [boost] Re: static sized strings
by Martin Bosticky 13 May '04

13 May '04

>> >>There's probably room and need for both types of strings. > >I don't intend the char_string buffer to be increased. I intended that the >operations on the buffer would not go beyond the buffer (which would lead >to >overflow) and also that going over the buffer would not generate an >exception. >It may be beneficial to have an error policy to determin the behaviour in >the event of an overflow. I am not advocating this approach, just putting >it >up for discussion. In the spirit of contributing to this 'discussion', I would suggest a size limited string that would throw exception if assigned data that is too long. However I would also add a friend function(s) that would assign and truncate supplied data. So by default the string would be safe for use, but you could assign using a 'truncation' technique in which case no exception could ever be thrown. This would then satisfy requirements of both parties. Martin Bosticky This email message contains confidential information and is intended for the use of its intended recipient only. Access to this email by anyone else is unauthorised. If you are not the intended recipient you are hereby notified that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If this communication has been sent to you in error, please notify us immediately. Action Information Management Ltd. 129 Devizes Road, Hilperton, Trowbridge, Wiltshire BA14 7SZ. Tel: +44 (0) 1225 711200 Fax: +44 (0) 1225 711222 Website www.aimltd.co.uk email: support(a)aimltd.co.uk

1 0

big_integer and boost::random::uniform_int
by Joel Young 13 May '04

13 May '04

I tried to use boost::random::uniform_int with the in-development big_integer library. Here is a test code: #include <boost/random/uniform_int.hpp> #include "boost/big_integer.hpp" /////////////////////// int main(int argc, char* argv[]) { typedef boost::big_integer data_t; // typedef long long data_t; data_t n(235345345); boost::uniform_int<data_t> rng(0,n-1); return 0; } /////////////////////// ==> g++ --version g++ (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1) Compiling this yields: /////////////////////// g++ -o a -I ~/boost/boost/include/boost-1_31/ randomtest.cpp /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/random/uniform_int.hpp: In constructor `boost::uniform_int<IntType>::uniform_int(IntType,IntType) [with IntType = main(int, char**)::data_t]': randomtest.cpp:10: instantiated from here /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/random/uniform_int.hpp:52: error: invalid application of `sizeof' to an incomplete type ////////////////////// Joel

2 1

Boost.Test and free 7.1 tools
by Vladimir Prus 13 May '04

13 May '04

I've just tried building the Boost.Test library with the free VC 7.1 tools. I get this error: msvc.compile.c++ ..\..\.. \bin\libs\test\build\msvc-7.1\debug\link-static\execution_monitor.obj execution_monitor.cpp ..\..\..\libs\test\src\execution_monitor.cpp(52) : fatal error C1083: Cannot open include file: 'wtypes.h': No such file or directory call "W:/Program Files/Microsoft Visual C++ Toolkit 2003\bin\vcvars32.bat" > nul cl /Zm800 -nologo -TP -DBOOST_TEST_NO_AUTO_LINK=1 /Z7 /Od /Ob0 /GX /GR /MDd -I"..\..\.." -c -Fo"..\..\.. \bin\libs\test\build\msvc-7.1\debug\link-static\execution_monitor.obj" ".. \..\..\libs\test\src\execution_monitor.cpp" All the other files compile fine, so I assume it's not misconfiguration, and that Boost.Test uses some header which is not included in free tools. Is it possible to fix that? I guess that I'm not the only one Linux user who would like to test code with free vc 7.1 and if Boost.Test fails to build that's not possible. TIA, Volodya

2 1

signals lib bug
by Alexey Subbota 13 May '04

13 May '04

Under windows <signals>.dll not export some function because absent #include <boost/config.hpp> before #ifdef BOOST_HAS_DECLSPEC at boost/signals/detail/config.hpp

2 1

[boost][serialization] Adding State to Archives
by martin.ecker＠tab.at 13 May '04

13 May '04

Hello, I was wondering what the best way would be to extend the serialization library to allow storing state in e.g. the archive objects during the serialization process. We could use such a facility in our project for various purposes. For example, it would be possible to influence the serialization of certain classes, i.e. make them write out only their internal state but not any pointers or references to other objects, or something like that. Another use case for having state variables in archives: We're using another library in our project that has its own serialization system. So instead of writing boost::serialization code for the classes of this library we want to use its serialization system. This is straightforward enough by having the library serialize into a memory buffer which is then written out using boost::serialization's binary_object. However, we also need to do proper tracking of pointers for that library, so we can't just create a new memory buffer every time we encounter a pointer to one of its objects during serialization. Therefore it would be convenient to store an "archive" object of the library's serialization system (which calls an archive a "stream") in the boost::serialization archive and simply write all objects of the library we encounter to it. The library's serialization system will track all these objects for us in a similar way boost::serialization does. Then at the end of the serialization process we write the additional serialization data out to the archive using a binary_object. In general, there are a lot of use cases I can think of where having state variables in an archive is useful (setting flags to influence the serialization process, deserializing smart pointers, registering objects upon deserialization in some kind of object registry, etc.). One way of achieving all this would, of course, be to derive from one of the existing archive classes and add the required functionality. However, we don't want to lose the flexibility of being able to write out data to a binary, text, XML, or any other archive with some other kind of representation. So basically we're looking for a good way of inserting an additional layer in between the archives and the actual serialize functions that can store state variables. Thanks for any comments. Best Regards, Martin Ecker TAB Austria Industrie- und Unterhaltungselektronik GmbH & CoKG http://www.tab.at

1 0

Lambda/functions
by Darren Cook 13 May '04

13 May '04

I've a set of trees (e.g. a set of identically structured XML documents) and I want to be able to return a reference to a certain position in the tree. My test tree node is [1] below, with a test tree [2]. I think I can solve this with boost::function and boost::lambda. E.g. this works: boost::function1<int,Node&> best2; best2=bind(&Node::value2,_1); std::cout<<"best2(root)="<<best2(root)<<"\n"; std::cout<<"best2(child[0])="<<best2(root.children[0])<<"\n"; I also need to be able to treat "number of children" the same way I can treat value1 or value2. I've now worked this out as: best2=bind(&std::vector<Node>::size,bind(&Node::children,_1)); Going strong, but now I want to refer to the "value1 of the first child". Following the patterns of the previous ones I thought it would be: best2=bind(&Node::value2, bind( &std::vector<Node>::at, //Ask for an element bind(&Node::children,_1), //Get the vector object 0 ) //Ask for element zero ); That fails with a short error message [3], which is so rare when dealing with BLL that I thought I might be able to understand it, but no, I couldn't work out which bit it didn't like. Can anyone help? Also, is there any limit to how deep I can nest these binds? I think I'm going to need 3 more levels, but it would be useful to know if it is unlimited. Darren [1]: class Node{ public: std::vector<Node> children; int value1,value2; public: Node(int v1,int v2):value1(v1),value2(v2){} friend std::ostream& operator<<(std::ostream& s,const Node& obj){ s<<"value1="<<obj.value1<<",value2="<<obj.value2<<",children.size="<<obj.children.size()<<"\n"; return s; } }; [2] Example usage: Node root(1,111); root.children.push_back(Node(2,222)); std::cout<<root<<root.children[0]; [3]: function.cpp: In function `int main(int, char**)': function.cpp:69: no matching function for call to `bind(<unknown type>, const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<2, boost::lambda::function_action<2, boost::lambda::detail::unspecified> >, boost::tuples::tuple<std::vector<Node, std::allocator<Node> > Node::*, const boost::lambda::lambda_functor<boost::lambda::placeholder<1> >, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type, boost::tuples::null_type> > >, int)'

1 0

RE: [boost] Re: static sized strings
by Martin Bosticky 13 May '04

13 May '04

I have already written code that allows me to create std like strings of fixed upper bound length. If such thing doesn't exist in boost, I am willing to submit and help standardise my code. Eg. // create a string with upper bound length of 4 characters. boost::slstring<4> myLimitedString; My implementation has the ability to quickly copy between strings with the same upper bound (ie without checking the max length). But during assignments from char* or normal std::string objects or strings with different upper bound, the upper bound condition is checked and exception is thrown if there is an error. Martin. Martin Bosticky Software Engineer Action Information Management Ltd. Tel: (01225) 711200 Fax: (01225) 711222 Email: mbosticky(a)aimltd.co.uk -----Original Message----- From: John Nagle [mailto:nagle@animats.com] Sent: 12 May 2004 23:00 To: boost(a)lists.boost.org Subject: [boost] Re: static sized strings Reece Dunn wrote: > Rob Stewart wrote: > >> From: John Nagle <nagle(a)animats.com> >> > >> > STL strings are variable-sized, with no limit. When you >> > add characters, "size()" increases. Should fixed-size >> ^^^^ >> I presume you're referring to fixed-capacity strings which can >> have a variable size, right? Yes. > yup. The idea is to make it a buffer-overflow safe replacement for C > style character buffers, e.g.: > > char buf[ 100 ]; > ::sprintf( buf, "...", ... ); Yes. >> If the string if (sic) fixed-capacity *and* there remains sufficient >> capacity, c_str() can null terminate the buffer. If there isn't >> sufficient remaining capacity, then throw an exception. Done that way, if you write char_string<4> s; strcat(s,"ABCDE"); // truncates at "ABCD", no null. printf("s=%s\n",s.c_str()); // c_str throws exception which is quite different from classic <string.h> semantics. You couldn't use that as a drop-in replacement for C strings. Nor is it compatible with STL basic_string semantics. I'd suggest consistent null-terminated semantics for char_string. >> IOW, make it a runtime error to fix the capacity too small to >> permit null termination when calling c_str(). That still leaves >> room for things like the 4-character file signature to which you >> referred, and yet prevents buffer overrun, but doesn't require >> foregoing flexibility. If you want a 4-char file signature, you can use "boost::array<char,4>", which does that job. Is there any real need for that functionality in char_string? char_string might have some convenience template functions to interconvert "boost::array" and "boost::char_string". > That is a good idea. It will mean keeping track of the string length, Yes, that seems to be necessary. What about the base class issue? There's a need to be able to write something like "char_string_base& s" when you want to pass around fixed-capacity strings of more than one capacity. > Regards, > Reece _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This email message contains confidential information and is intended for the use of its intended recipient only. Access to this email by anyone else is unauthorised. If you are not the intended recipient you are hereby notified that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If this communication has been sent to you in error, please notify us immediately. Action Information Management Ltd. 129 Devizes Road, Hilperton, Trowbridge, Wiltshire BA14 7SZ. Tel: +44 (0) 1225 711200 Fax: +44 (0) 1225 711222 Website www.aimltd.co.uk email: support(a)aimltd.co.uk

1 0

[boost] Finding operator==(directory_iterator&, directory_iterator&)
by DY, JERRY U (SBCSI) 12 May '04

12 May '04

In trying to compile the filesystem library, I'm getting an error that the compiler cannot find the operator== for the following function: bool is_empty_directory( const fs::path & dir_path ) { return fs::directory_iterator(dir_path) == end_itr; } aCC-C++-action ../../../bin/boost/libs/filesystem/build/libboost_filesystem.a/acc/debug /operations_posix_windows.o Error 226: "../../../libs/filesystem/build/../src/operations_posix_windows.cpp", line 176 # No appropriate function found for call of 'operator =='. class directory_iterator doesn't declare it, neither do ancestors iterator_facade and iterator_facade_types. Can't find free function for operator==(directory_iterator&, directory_iterator&), operator==(iterator_facade&, iterator_facade&), operator==(iterator_facade_types&, iterator_facade_types&) or any of its variants. Is it using the default compiler-generated operator== in directory_iterator? Can somebody who is familiar with the filesystem library code assist me so I can generate a test case for the HP aC++ team? Thanks! -Jerry

2 1

Re: [boost] Big integer library
by Richard Peters 12 May '04

12 May '04

I have once again uploaded a new version of my big integer library (available at http://groups.yahoo.com/group/boost/files/big_integer/, version 0.3). The divison algorithm is completely new, and this time it is fast (it now uses Knuth's algorithm). The code is also reorganised, which made it quite easy to build in support for GNU MP and CLN. When either of those two libraries is available, set BOOST_BIG_INTEGER_USE_GMP or BOOST_BIG_INTEGER_USE_CLN, and those libraries will be used to implement the basic arithmetic functions. Those libraries aren't completely supported yet, a few functions (mostly conversion functions from types larger than int) need to be implemented correctly (it's kindof hacked together right now), and most noticeable, cln hasn't got power_mod yet, because I was unable to find the matching function in the cln library. That aside, it shows that it is quite easy to make the library work with other libraries to provide speedy implementations with a uniform interface. Best regards, Richard Peters ----- Original Message ----- From: "Joel Young" <jdy(a)cs.brown.edu> > > I made a simple program with some big numbers that demonstrate the > speed difference: > > The summary is that big_integer is making millions of > iterator calls and lexicographical_compares, while even > boost::rational using long long is just making a few calls > to things like boost::gcd. > > Joel

3 2

[Boost-bugs] [ boost-Bugs-952713 ] incomplete connected components with disjoint_sets
by SourceForge.net 12 May '04

12 May '04

Bugs item #952713, was opened at 2004-05-12 10:20 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=952713&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: incomplete connected components with disjoint_sets Initial Comment: I am trying to understand why the order in which I add edges to an adjacency_list graph has some effect on the connected components I get using incremental_components. Using the listing below, with Boost release 1.30.0 (also 1.31.0) with g++ 2.95 (cygwin) I get the following: > g++ -I./boost_1_31_0 -o ok -ftemplate-depth-40 incremental-components-eg-bug.cpp > ./ok rank[0] = 0 rank[1] = 0 rank[2] = 0 rank[3] = 1 rank[4] = 0 parent[0] = 3 parent[1] = 3 parent[2] = 3 parent[3] = 3 parent[4] = 3 component 0 contains: 4 3 2 1 0 This is what I expect. If I change the order in which I add edges to the graph, I get a different answer: > g++ -I./boost_1_31_0 -DSHOWBUG -o bug -ftemplate- depth-40 incremental-components-eg-bug.cpp > ./bug rank[0] = 0 rank[1] = 0 rank[2] = 1 rank[3] = 2 rank[4] = 0 parent[0] = 3 parent[1] = 2 parent[2] = 3 parent[3] = 3 parent[4] = 3 component 0 contains: 4 3 2 0 This is not what I expect. The single connected component has lost a vertex. But it should be the same graph, the only difference being the order in which I called add_edge(). Is this a bug or a misunderstanding on my part? Any advice would be appreciated... Jeff #include <iostream> #include <vector> #include <algorithm> #include <utility> #include <boost/graph/adjacency_list.hpp> #include <boost/pending/disjoint_sets.hpp> #include <boost/graph/incremental_components.hpp> int main(int, char *[]) { using namespace boost; // Create a graph typedef adjacency_list < vecS, vecS, undirectedS > Graph; typedef graph_traits < Graph >::vertex_descriptor Vertex; const int N = 5; Graph G(N); add_edge(0, 3, G); add_edge(0, 4, G); #ifndef SHOWBUG add_edge(1, 4, G); add_edge(1, 2, G); #else add_edge(1, 2, G); add_edge(1, 4, G); #endif // create the disjoint-sets object, which requires rank and parent vertex properties std::vector < Vertex > rank(num_vertices(G)); std::vector < Vertex > parent(num_vertices(G)); typedef graph_traits<Graph>::vertices_size_type* Rank; typedef Vertex* Parent; disjoint_sets < Rank, Parent > ds(&rank[0], &parent [0]); // determine the connected components, storing the results in the disjoint-sets object initialize_incremental_components(G, ds); incremental_components(G, ds); for (unsigned int i = 0; i < rank.size(); ++i) { std::cout << "rank[" << i << "] = " << rank[i] << std::endl; } for (unsigned int i = 0; i < parent.size(); ++i) { std::cout << "parent[" << i << "] = " << parent[i] << std::endl; } typedef component_index < unsigned int >Components; Components components(parent.begin(), parent.end()); for (Components::size_type i = 0; i < components.size (); ++i) { std::cout << "component " << i << " contains: "; for (Components::value_type::iterator j = components [i].begin(); j != components[i].end(); ++j) std::cout << *j << " "; std::cout << std::endl; } return EXIT_SUCCESS; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=952713&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Request for small test in VC7.1
by JOAQUIN LOPEZ MU?Z 12 May '04

12 May '04

I'd appreciate if someone on the list could try the following in VC7.1 and report the results: template<typename T> struct A { template<typename Q> void operator()(const Q&){} }; template<typename T> struct B: private A<T> { using A<T>::operator(); }; int main() { B<char> b; b(3); return 0; } The regression tests for multi_index seem to indicate that VC7.1 is having trouble with this kind of construct and I'd like to make sure before applying any fix. Curiously enough, this problem also shows up in GCC for versions under 3.4, as confirmed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9810 Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 3

RE: [boost] Re: changing aCC-Link-action
by DY, JERRY U (SBCSI) 12 May '04

12 May '04

I've attached changes with your suggestions. I tested it and it worked!! I'm starting to like bjam, now how does it compare to ant?? =) (we're still using gnu make here). I've also added the line: flags acc CFLAGS <inlining>off : +d The +d option prevents inlined functions from being inlined, useful for debugging -- assuming that's what the option is meant to do. -Jerry -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Wednesday, May 12, 2004 7:54 AM To: boost(a)lists.boost.org Subject: [boost] Re: changing aCC-Link-action Rene Rivera wrote: > flags acc CFLAGS <target-types>$(SHARED_TYPES) : +z ; > flags acc LINKFLAGS <target-types>$(SHARED_TYPES) : -b ; Oops :-) That should be "target-type", singular not plural. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Regression tests: EXIT STATUS: 666
by Joaquín Mª López Muñoz 12 May '04

12 May '04

Regression status reports list the following run output for some tests of my lib in CWPro8: EXIT STATUS: 666 And nothing more (see for instance http://tinyurl.com/2e56z) Anyone has a clue what this is about? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

boost::date_time: ISO compliant IO for periods/durations?
by Daniel Krügler 12 May '04

12 May '04

Hello boosters, I would like to know whether there already exist ISO 8086 conforming extractors/inserters for the duration/period classes? Specifically I am looking for io/string functions which can handle "Periods of Time, no Specific Start or End", which begin with a 'P' following a list of periods, e.g. "P18Y9M4DT11H9M8S" (18 years, 9 months, 4 days, 11 hours, 9 minutes and 8 seconds) (I am using the term period in the sense ISO 8086 seems to do, i.e. including durations and periods - or did I overlook something?) Thanks for any help, Daniel

3 5

regex lib bug: \u and icase
by Benzinger, Ralph 12 May '04

12 May '04

Hello, Regular expressions "[\u]" and "\u", unlike "[[:upper:]]", will not match any letters when the icase flag is set. Similarly, "\U" will match anything. Expressions "\l" and "\L" seem to be fine due to the lower_case_map[] translation. My suggestion would be to replace classes.push(traits_type::char_class_upper); and the like by classes.push((_flags & regex_constants::icase) ? traits_type::char_class_alpha : traits_type::char_class_upper); in the 'syntax_u/U/l/L' cases in set_compile() and set_expression(). This approach is currently taken in the 'syntax_open_set' case in set_compile(). John may have a different fix in mind, though. :-) Regards, Ralph

2 1

[Boost-bugs] [ boost-Bugs-952335 ] Build Boost.Python from minwg gcc
by SourceForge.net 12 May '04

12 May '04

Bugs item #952335, was opened at 2004-05-12 11:21 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=952335&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: Build Boost.Python from minwg gcc Initial Comment: I try compile Boost.Python from minwg, and i recive compile error. Boost: CVS HEAD 2004-05-12 Os: WinXP Compiler: gcc (GCC) 3.2.3 (mingw special 20030504-1) (MinGW-3.1.0-1.exe) bjam: Boost.Jam Version 3.1.9. OS=NT. command line: c:>boost\libs\python\build>bjam -sTOOLS=mingw - sPYTHON_ROOT=C:/Lang/Python23 - sPYTHON_VERSION=2.3 Full output in attached file. Some output lines: gcc-C++- action ..\..\..\bin\boost\libs\python\build\boost_python.dl l\mingw\release\slice.obj In file included from C:/Lang/sf.net/boost/libs/python/src/slice.cpp:1: C:/Lang/sf.net/boost/boost/python/slice.hpp:29: warning: `dllexport' attribute ignored C:/Lang/sf.net/boost/boost/python/slice.hpp:29: declaration does not declare anything C:/Lang/sf.net/boost/boost/python/slice.hpp:29: parse error before `)' token C:/Lang/sf.net/boost/libs/python/src/slice.cpp:18: prototype for ` boost::python::slice::slice()' does not match any in class ` boost::python::slice' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=952335&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

changing aCC-Link-action
by DY, JERRY U (SBCSI) 11 May '04

11 May '04

I would like to add options to the compile and link line used for building the threads library. I have added as follows but not sure if it's the proper place for it. With these changes, I'm able to cleanly compile and build the threads shared lib using aC++ 3.55 compiler. Credit to the HP aC++ team for their help on hpux.hpp changes. boost_1_31_0/tools/build/v1/acc-tools.jam:105 $(acc.bin-directory)$(CXX) -AA -mt +z -w -c +W823 -I$(BOOST_ROOT) -U$(UNDEFS) -D$(DEFINES) $(CFLAGS) $(C++FLAGS) -I"$(HDR S)" -I"$(STDHDRS)" -o "$(<)" "$(>)" boost_1_31_0/tools/build/v1/acc-tools.jam:82 $(acc.bin-directory)$(CXX) $(LINKFLAGS) -AA -mt -b -o "$(<[1])" -L$(LIBPATH) -L$(STDLIBPATH) "$(>)" "$(NEEDLIBS)" "$(NEEDLIBS)" -l$(FINDLIBS) boost_1_31_0/boost/config/platform/hpux.hpp:63 #define BOOST_HAS_PTHREADS -Jerry

2 1

serialization/shared_ptr load memory leak.
by Jeff Flinn 11 May '04

11 May '04

Ok, I've determined that the memory leak I was seeing is real, atleast in vc7.1. The boost::detail::sp_counted_base_impl<P,D> held by a serialization loaded shared_ptr never gets deleted. This is due to boost::serialization::load_construct_data setting weak_count to 0. When the sp_counted_base::weak_release() gets called new_weak_count is -1 so destruct is not called. A fix that works for my application, is to comment out the line: shared_ptr_access::weak_count(*t) = 0; in template<class Archive, class P, class D> inline void load_construct_data( Archive & ar, boost::detail::sp_counted_base_impl<P, D> * t, const unsigned int /* file_version */ The following was used to reproduce the problem in vc7.1. // SerializationSharedPtrTest.cpp : Defines the entry point for the console application. // #define CRTDBG_MAP_ALLOC #include <stdlib.h> #include <crtdbg.h> struct Checker { Checker() { _CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_CHECK_ALWAYS_DF | _CRTDBG_LEAK_CHECK_DF ); } }; Checker lChecker; #include <boost/serialization/shared_ptr.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <fstream> typedef std::string tName; class PointedToClass { int mInt; friend class boost::serialization::access; template< class Archive > void serialize( Archive &ar, unsigned int version ) { ar & boost::serialization::make_nvp( "Int", mInt ); } public: ~PointedToClass(){} PointedToClass():mInt(123){} PointedToClass( int aInt ):mInt( aInt){} PointedToClass( const PointedToClass& aRhs ):mInt(aRhs.mInt){} }; typedef boost::shared_ptr< PointedToClass > tPtr; int main( int argc, char* argv[] ) { { std::ofstream lOut( "SomeClass.archive", std::ios_base::out | std::ios_base::trunc ); if( lOut.good() ) { boost::archive::text_oarchive oa( lOut ); tPtr lPtr( new PointedToClass(456) ); oa << boost::serialization::make_nvp( "Ptr" , lPtr ); } } { std::ifstream lIn( "SomeClass.archive" ); tPtr lPtr; if( lIn.good() ) { boost::archive::text_iarchive ia( lIn ); ia >> boost::serialization::make_nvp( "Ptr" , lPtr ); } } return 0; }

1 0

RE: [boost] Re: Request for small test in VC7.1
by Ferdinand Prantl 11 May '04

11 May '04

> From: Joaquín Ma López Munoz [mailto:joaquin@tid.es] > > Maxim Yegorushkin ha escrito: > > > JOAQUIN LOPEZ MU?Z wrote: > > > > > I'd appreciate if someone on the list could try the following in > > > VC7.1 and report the results: > > > > [] > > > > If you have a Windows machine you can try it yourself as > Microsoft has > > released free Visual C++ 2003 Toolkit - > > http://msdn.microsoft.com/visualc/vctoolkit2003/ > > > > Ummm... do you know whether it clashes with a preexisting > VC++ 6.0 installation? (that I don't want to loose). Nope; I have all VC++ 6.0, 7.0, 7.1 and 8.0-preview on a one machine happily working (installed in this order: 7.0, 6.0, 7.1, 8.0). I did not register them in the environment (INCLUDE, LIB, ...) and use vcvars32 in a command-line to build. Ferda > > Joaquín M López Muñoz > Telefónica, Investigación y Desarrollo

1 0

[filesystem] directory iterator operator++ patch
by Vladimir Prus 11 May '04

11 May '04

Beman, the attached patch enables the operator++(int) in directory_iterator. To summarize our discussion with Dave: 1. New single pass iterator requirements did not meants to outlaw returning proxy from operator++(int) 2. Even if proxy is automatically generated by iterator_facade, this might take some time to be implemented. In fact, I no longer believe it's really desired. So, implementing operator++(int) is directory_iterator makes sense. The attached patch basically uncomments your code, adds one using declaration to bring preincrement operator++ into the scope and changes the tests. Okay to commit? - Volodya

1 0

Metacomm BoostBook-generated documentation not updated?
by Douglas Gregor 11 May '04

11 May '04

It looks like the Metacomm BoostBook documentation hasn't been regenerated in a few days. Is there a problem of some sort? Doug

2 1

Boost Array Documentation
by Stephan T. Lavavej 11 May '04

11 May '04

See http://boost.org/doc/html/array.issues.html : g++ 3.3.3 accepts array<int, 5> a = { 0, 1, 2, 3, 4 }; without complaint when using -Wall -W. Assuming that other modern compilers do too, then this Open Issue should be removed, and the documentation updated accordingly. (Also, the Lambda Doc Bug I pointed out has not yet been addressed; see http://lists.boost.org/MailArchives/boost/msg64450.php .) Stephan T. Lavavej http://nuwen.net

1 0

typeof
by Arkadiy Vertleyb 10 May '04

10 May '04

Hello everybody, A couple of weeks ago I initiated the discussion about simple typeof emulation, and provided an example on how it can be done with the help of MPL vector of integral constants. I then used MS-specific __COUNTER__ macro to spare the user from specifying the unique integer for each registered class/template. I hoped to find a way to do something similar in standard C++, and asked preprocessor experts for help. Indeed, Paul Mensonides suggested such a way. At first I thought that it will not be good enough replacement for the __COUNTER__, but then I realized that I was wrong. So I re-worked my implementation of typeof, and now offerring it to your attention. Besides removing __COUNTER__, I used the Boost.Preprocessor library to cleanup the implementation. Also, after the discussion with Jody Hagins, I put the encoding/decoding classes inside anonimous namespace to avoid collisions between translation units. The provided example shows what registration needs to be done to calculate the type of a lambda functor: #include BOOST_TYPEOF_BEGIN_REGISTRATION() BOOST_TYPEOF_REGISTER_TEMPLATE(tuples::tuple, 2); BOOST_TYPEOF_REGISTER_TEMPLATE(lambda_functor, 1); BOOST_TYPEOF_REGISTER_TEMPLATE(lambda_functor_base, 2); BOOST_TYPEOF_REGISTER_TEMPLATE(relational_action, 1); BOOST_TYPEOF_REGISTER_TEMPLATE(logical_action, 1); BOOST_TYPEOF_REGISTER_TYPE(greater_action); BOOST_TYPEOF_REGISTER_TYPE(less_action); BOOST_TYPEOF_REGISTER_TYPE(and_action); BOOST_TYPEOF_REGISTER_TYPE(placeholder<1>); BOOST_TYPEOF_REGISTER_TYPE(placeholder<2>); #include BOOST_TYPEOF_END_REGISTRATION() main() { BOOST_TYPEOF_ALLOCATE(fun, _1 > 15 && _2 < 20); // <unspecified> fun(_1 > 15 && _2 < 20); int n = 19; assert(fun(n, n)); } One of remaining problems is inability to process top-level consts and references, that get eatten up at the function level, before the partial template specialization gets involved... Although I believe that I don't do anything non-standard now, unfortunately I can't prove it myself. The only compiler I have besides MSVC is GCC, and it gives me "sorry not implemented" on something as simple as mpl::int_<sizeof(foo(...))>... Besides, GCC already has a typeof. Would anybody be so kind as to try the "typeof" with some other compiler? I would really apprciate this... Here is the link: http://groups.yahoo.com/group/boost/files/typeof.zip Any comments are greatly appreciated. Thanks, Arkadiy

10 39

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

10 May '04

John Nagle wrote: > There are fundamental issues with string size that have to be >resolved. > > STL strings are variable-sized, with no limit. When you >add characters, "size()" increases. Should fixed-size >strings be similar? If the STL string operations are >to be meaningful, they have to be. The way I see it, size() relates to the current size of the string, and capacity() relates to the current storage size, thus you have: -- null-terminated, fixed size (char_string< n > s) size() = strlen( s.c_str()); capacity() = n; string manipulations guaranteed such that size() < capacity() in order to cope with null character null character is always added fixed size (fixed_string< n > s) size() = capacity() = n; > In STL strings, "size" doesn't include a trailing null. >Using "c_str" can result in expanding the string to add a >trailing null. With fixed-size strings, we don't have that >option. size() will not include the trailing null; c_str() will return the character buffer; null character is added by the string operations, thus there is no need to add it on the c_str() operation. > If c_str is provided, there must always be space >for a trailing null. So you can't use char_string >when you need a specific fixed length, as for Macintosh >4-character file signatures. Perhaps "boost::array<char>" >is the way to go for that sort of thing. Trying to do >both null-terminated and non-null-terminated strings >in the same class will get ugly. I don't think it will be that ugly. In a previous post that contained the updated char_string class, I had an implementation of it as a boolean template parameter (null-terminate). > Top priority, I think, is a size policy. Do you mean how to handle size() and capacity()? If so, see above. > Is Dunn's version in the Boost sandbox? Where? I have not yet added it to the sandbox, but will in the next few days. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

c.l.c++.m post
by David Abrahams 10 May '04

10 May '04

Hi, The enclosed post showed up on c.l.c++.m; AFAICT it has little or nothing to do with MPL, but it does contain several boost-related issues. The best answer isn't really clear to me; we could detect dereferenceability, use a hack involving get_pointer, or maybe something else would be appropriate. Would anyone like to tackle this one? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 1

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

10 May '04

John Nagle wrote: >John Nagle wrote: >> I've been doing some work on this too. I made char_string >>a subclass of a non-templated char_string_base, so you can >>pass references to char_string_base. This has the disadvantage >>of requiring a vtable, but makes the class much more useful. >> >> I'll put this someplace publicly visible in the next day >>or two. > > It's at > http://www.animats.com/source >Take a look and see if you like the direction this is going. >Thanks. Hmm. Which way to go? My latest version has been generalized to incorporate char/wchar_t support, so you can use wide-character strings. It also uses a StringPolicy class (i.e. char_traits) so you can control the length, copy, comparison, etc functions that are used. BTW: the reason I use the const char( & s )[ m ] on compilers that support it is because this picks up the string literals in order to remove a call to strlen, thus improving performance. Which design do you like better: using a virtual base class, or using a policy template? I have been working on providing an interface similar to std::basic_string, hence some of my latest design choices. Ideally, the class should: * safeguard against buffer overflow on static-sized character arrays; * interoperate with classic C string operations; * interoperate with std::basic_string; * provide support for null-terminated strings and also fixed-length strings; * prevent silly mistakes by the user, ideally providing compile-time errors wherever possible. At the moment, both implementations provide a different subset of those aims. Do you mind if I look into this and let you know what I come up with. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

3 2

FW: Bjam error on Windows
by Janet Schneider 10 May '04

10 May '04

_____ From: Janet Schneider Sent: Monday, May 10, 2004 10:40 AM To: 'boost(a)lists.boost.org' Subject: Bjam error on Windows Hello, I'm seeing the following error when I try to run bjam on a Windows 2003 system: F:\Liberty\Boost\src\boost_1_31_0>..\bjam --prefix=F:\Liberty\Boost\32bit\boost_1_31_0 -sTOOLS="vc7.1-stlport" -sBUILD="<stlport-iostream>on <runtime-link>static release debug" install Jamfile:118: in load-jamfiles *** argument error * rule install-subinclude ( jamfiles + : options * ) * called with: ( : ) * missing argument jamfiles F:\Liberty\Boost\src\boost_1_31_0\tools/build/v1\boost-base.jam:2766:see definit ion of rule 'install-subinclude' being called F:\Liberty\Boost\src\boost_1_31_0\tools\build\v1\bootstrap.jam:15: in boost-buil d F:\Liberty\Boost\src\boost_1_31_0\boost-build.jam:16: in module scope Does anyone have any hints why this is happening? Thanks, Janet

1 0

Re:[boost] Regression testing -- some new testing options?
by Robert Ramey 10 May '04

10 May '04

Testing everything all the time amounts to using one package to test another - which is OK but not as efficient as a complete test suite. What I would like to be able to do is run the tests on a demand basis. That is, I would like to request a test for a specific set of compiler, dll/lib, debug/release options. As a practical matter, I will get everything working with the compilers I have on hand, upload to cvs, run tests on compilers I don't have. This wouldn't take a huge amount of time. Only on special occasions - i.e. right before release, would it be necessary to re-test everything. Maybe a facility could be include whereby I just submit a jamfile and it's queued up. Robert Ramey

1 0

bind behavior
by Dill, John 10 May '04

10 May '04

I ran into some possibly confusing behavior when trying out the documentation example from bind. When you have: struct F { int operator()(int a, int b) { return a - b; } bool operator()(long a, long b) { return a == b; } }; F f; int x = 104; bind<int>(f, _1, _1)(x); // f(x, x), i.e. zero What could be confusing is when you do this: long y = 104; bind<int>(f, _1, _1)(y) // Calls the operator<bool>, not operator<int> which is counter-intuitive as the documentation says your binding on the return type, but the return type is not actually what function call the type deduction gets. Does anyone else observe this behavior? I tried this on gcc 3.4. Thanks, John

1 0

number ranges and compile-time errors
by Reece Dunn 10 May '04

10 May '04

Is there a boost library that allows you to specify the range that a number can take, e.g. boost::range< int, 1, 12 > month; generating an error on an invalid range, e.g. month = 20; // [1] oops! Also, is it possible to distinguish between a number literal like the above and a variable assignment, like: month = m; // [2] The logic behind this is to provide compile-time checks where possible, so [1] would produce a compile-time error and [2] would be a run-time error. You could also do something like: inline char & string::operator[]( boost::range< int, 5, 10 > i ){ ... } // ... string s; s[ 1 ] = 'a'; // oops! and class date { boost::range< int, 1, 12 > month; public: inline date( boost::range< int, 1, 12 > m ): month( m ){} }; Regards, Reece _________________________________________________________________ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband

3 3

Large files ( > 2GB) and boost::filesystem library
by David Judson 10 May '04

10 May '04

In a number of places in the filesystem library on Linux, the ::stat file system call is used. When this call is executed on a file whose size is larger than 2GB, it fails because the file size cannot fit into the default "stat" structure. This problem happens even when the size information in the stat structure is not used. For example the stat information is used in the directory iterator to look for sub directories. This can be corrected by setting the macro _FILE_OFFSET_BITS to 64. What is the best way to set this macro on Linux? I have looked at the jam rules and cannot locate the appropriate place to include the definition. Also, what process should be followed if I want to have this macro defined either by default or at least as an option in the boost source tree so that I don't have to modify the build rules each time I install boost?

6 8

[Graphs] another c.l.c++.m post
by David Abrahams 10 May '04

10 May '04

-- Dave Abrahams Boost Consulting http://www.boost-consulting.com

1 0

gmane
by Daniel Wallin 10 May '04

10 May '04

Did someone just import an archive to the boost gmane group? I've been getting old (1998+) postings and no new ones all day, also they are not in order which is kind of annoying.. -- Daniel Wallin

3 2

borland workaround still needed
by Gennadiy Rozental 10 May '04

10 May '04

Hi, I an trying to make protected member defined in base class public: template<class PropertyType> class class_property { protected: PropertyType value; }; template<class PropertyType> class readwrite_property : public class_property<PropertyType> { public: typedef class_property<PropertyType> base; #if BOOST_WORKAROUND(__BORLANDC__, <= 0x570) base::value; #else using base::value; #endif }; Borland fail to compile it, stating something about an attempt to grant access to protected member. Well that's the whole point!! Any suggestions? Gennadiy.

1 0

patch: boost/math/special_functions => compile error in asinh.hpp, acosh.hpp and atanh.hpp
by Huber, Carsten 10 May '04

10 May '04

Hello boost developers, this is my first mail to boost(a)lists.boost.org and it is already a bug that I found in the latest release 1.31.0 :-( I tried to compile boost::math::asinh, boost::math::acosh and boost::math::atanh recently and got a compile error "C2039 'abs' : is not a member of '_STL'" on my MSVC6 compiler. I have STLPort 4.5.3 installed and thought, this might be the problem, but then I found out that boost::math::sinc_pi and boost::math::sinhc_pi compile with no errors. To make it short: asinh, acosh and atanh are using ::std::abs, ::std::sqrt and ::std::log - which are not part of the STL. To fix this problem, I have created a patch - see attached files. Best regards, Carsten Huber ------------------------------------------------- Dipl.-Ing. Carsten Huber (Member of the VDE) Software Development Engineer Product Line Diagnostics (PDG) Vector Informatik GmbH Ingersheimer Str. 24 D-70499 Stuttgart Phone : +49 711 80670-0 Fax : +49 711 80670-299 Mailto : carsten.huber(a)vector-informatik.de Internet: http://www.vector-informatik.de -------------------------------------------------

2 1

[Boost-bugs] [ boost-Bugs-951106 ] bjam install does not copy .inc files
by SourceForge.net 10 May '04

10 May '04

Bugs item #951106, was opened at 2004-05-10 08:05 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=951106&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pere Mato (pmato) Assigned to: Nobody/Anonymous (nobody) Summary: bjam install does not copy .inc files Initial Comment: On trying to compile we got the follwing error: afs/cern.ch/cms/external/lcg/external/Boost/1.31.0/rh73_ gcc32/include/boost- 1_31/boost/pool/object_pool.hpp:83:51: boost/pool/detail/pool_construct.inc: No such file or directory The problem has been traced to the fact that the .inc files in boost/pool/detail were not copied to the installation area by "bjam install". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=951106&group_i… ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0