- Boost - lists.preview.boost.org

Regression testing -- some new testing options?
by Jeff Garland 09 May '04

09 May '04

Robert Ramey & I have been having a discussion offline about the impact of new boost libraries on the time it takes to run the regression tests. Serialization has a particularly time consuming test -- the so called 'torture test' suite. The problem is, that once serialization is in the tree it will be important to run that full test from time to time (like right before release), but it would probably be overkill to run everyday. And from past dicussion it is clear that running the regression test is already becoming very time consuming. Of course this isn't a serialization specific issue. With more and more libraries added the time to do any sort of regression test is continuing to grow. In addition, there is now the 'dll' versus 'static' library dimension for those of us with compiled libraries. It might be nice to sometimes run one or the other to speed things up. Also, Robert would like to be able to run 'debug' versus 'release' tests from time to time. So here's a suggestion. Perhaps it be possible to create a standard way we could set up the regression test targets so that library authors could: 1) define a couple standard test levels - say 'basic' and 'torture' 2) DLL versus static tests would be an option on the regression suite -- so you could run only one or both. Of course this isn't an issue for header libraries. 3) debug versus release is an option 4) define specific compiler/platform exclusions I believe such a design could increase the regression test effectiveness by allowing some contributors and users to run only one set of options (eg: 'basic-dll-release') tests. This option would be much-much faster than 'torture-all-all' -- which for a compiled library needs to compile and excute 4 versions of the tests (dll-release, dll-debug, static-release, static-debug). The compiler/platform exclusions would save time by just skipping over stuff that is going to fail and will never be fixed. There may be some way of doing this now, but ideally we would have some way of specifying this in the bjam file for the tests. Thoughts? Jeff

1 0

Re: Request for small test in VC7.1
by Arkadiy Vertleyb 09 May '04

09 May '04

Hi Joaquin, Your example compiles with no problem in VC7.1 (.NET 2003) in both debug and release mode. Regards, Arkadiy

1 0

Re: [boost] Request for small test in VC7.1
by JOAQUIN LOPEZ MU?Z 09 May '04

09 May '04

----- Mensaje original ----- De: brok(a)spamcop.net Fecha: Domingo, Mayo 9, 2004 10:52 pm Asunto: Re: [boost] Request for small test in VC7.1 > Quoting JOAQUIN LOPEZ MU?Z <joaquin(a)tid.es>: > [snippet deleted] > Compiled successfully (tried with and without /Za, ie "disable > languageextensions"). > > > B. > Hi Bronek, thanks for trying the test. Obviously, I failed to capture the problem in the snippet, the actual error that's troubling me can be consulted at: http://tinyurl.com/ysmxq The diagnostic seems to be related with the fact that composite_key_result_less privately inherits from composite_key_compare while allowing public access to the base's operator() with a using declaration. Any idea about this? I'll be more than happy to provide further info to anyone who has a clue about the problem, or whishes to try the test in VC 7.1. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: Re: [boost] Re: [serialization] pointers to built-in types
by Robert Ramey 09 May '04

09 May '04

Dave Harris wrote: > I'd rather tell the library exactly which ints can be serialised via > pointers and which not, and the current solution seems a reasonable way of > doing that. At least, I can't think of a better one. To me the cental issue is one of side-effects. I have a header file which implements serialization for pointers to longs - and it works great. Now I forget about the implementation of that header - after all, it works great - and include it in some other header files for some other project. Now I have a big mess. Whereever it's been included, pointers to ALL longs are tracked. Whereever its non included, pointer to longs are flagged at compiler time. Now the behavior of unrelated code is significantly altered just be the inclusion/exclusion of a seemingly unrelated component. The alteration effects even the compilation as well as the execution. Its worse than a global variable in a global namespace. That's why pointers to primitive types have been made non-serializable by default. And there is a very simple solution - use a wrapper to make the long its own type. Probably the only thing missing is to specify serialization for strong_typedef. Robert Ramey

2 1

Possible bug in mpl::push_front for vectorN
by Hamish Mackenzie 09 May '04

09 May '04

#define BOOST_MPL_LIMIT_VECTOR_SIZE 20 #include "boost/mpl/vector.hpp" #include "boost/mpl/push_front.hpp" class X { }; typedef boost::mpl::vector20< X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X > test; typedef boost::mpl::push_front< test, X >::type test2; int main() { return 0; } GCC Version 3.4.0 gives /usr/include/boost/mpl/push_front.hpp: In instantiation of `boost::mpl::push_front<test, X>': push_front.cpp:10: instantiated from here /usr/include/boost/mpl/push_front.hpp:36: error: invalid use of undefined type `struct boost::mpl::push_front_traits<boost::mpl::aux::vector_tag<20l> >::algorithm<test, X>' /usr/include/boost/mpl/aux_/push_front_impl.hpp:31: error: declaration of `struct boost::mpl::push_front_traits<boost::mpl::aux::vector_tag<20l> >::algorithm<test, X>' push_front.cpp:10: error: expected init-declarator before "test2" push_front.cpp:10: error: expected `,' or `;' before "test2"

2 1

Re: [boost] boost/bind.hpp and boost/mpl/less.hpp conflict
by Aleksey Gurtovoy 09 May '04

09 May '04

Lijun Qin writes: > It seems these two files can not be both included, > > just two line file: > > #include <boost/bind.hpp> > #include <boost/mpl/less.hpp> > > will fail to compile on vc 7.1 > > change value to value_t in bind.hpp can resolve the problem. Lijun, It's a known problem that has been fixed in the CVS. The fix will appear in the next release. Thanks for the report, -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

Re: [boost] Re: [serialization] pointers to built-in types
by brangdon＠cix.compulink.co.uk 09 May '04

09 May '04

In-Reply-To: <c7etkk$e3d$1(a)sea.gmane.org> lirong(a)hotpop.com (Li Lirong) wrote (abridged): > > This well mean that all serialized longs have to be tracked. > > I think the lib should only track it when it is serialized through > pointer. And most of the time, primitives are not serialized through > pointers. So there should be any overhead. It's easy to construct cases where that goes wrong. Like: struct S { int x; int *px; S() : x(0), px(&x) {} }; And such cases aren't that unlikely in real code, either. For example, x might be a default, with px being settable to some other location. It's true that such cases are rare... however, that just makes it all the more important that when they happen, they either work correctly or are diagnosed as errors, preferably at compile time. Disallowing serialisation of int pointers altogether may be restrictive, but it gives a safe compile-time check. I suppose it might be OK to have an option where ints are tracked only when serialised through pointers, provided there was also an option which detected any mistakes at run-time. In other words, did the tracking for all ints but without outputting it. The two options would let you trade performance for safety, eg switched with #ifdef _NDEBUG. However, this seems like a lot of development work. In practice I expect serialisation of int pointers is pretty rare. If we have them, then sooner or later we may get cases like S, and then we have to move to some other solution anyway. Handling the special case in the middle doesn't seem worth it to me. Especially if error detection only happens at run-time, and perhaps only in debug builds. I'd rather tell the library exactly which ints can be serialised via pointers and which not, and the current solution seems a reasonable way of doing that. At least, I can't think of a better one. -- Dave Harris, Nottingham, UK

1 0

boost/bind.hpp and boost/mpl/less.hpp conflict
by Lijun Qin 09 May '04

09 May '04

Hi, It seems these two files can not be both included, just two line file: #include <boost/bind.hpp> #include <boost/mpl/less.hpp> will fail to compile on vc 7.1 change value to value_t in bind.hpp can resolve the problem. Regards Lijun Qin

1 0

RE: [boost] Writing fully custom containers for the bgl
by Roman Yakovenko 09 May '04

09 May '04

> -----Original Message----- > From: Pierre DOUCY [mailto:pdoucyml@free.fr] > Sent: Friday, May 07, 2004 1:47 AM > To: Boost General General > Subject: [boost] Writing fully custom containers for the bgl > > > I have written a custom container for the bgl's adjacency_list which > was based on a subclass of a stl container (namely, std:list). > Everything seemed to work just fine (if not by itself) as I followed > the bgl book indications. > > Now, I'm working on a non stl-based container (a wrapper > around the bdb > API), and facing a lot of compile-time problems. I know my > bdb wrapper > is not fully stl-compliant. > > So my question is : if I make this wrapper fully standard-compliant > (for instance by using boost::iterator and by implementing everything > the stl tells me to implement in a AssociativeContainer or a > MultipleAssociativeContainer), will the bgl play nicely with > it (i.e. > as if it was a std::map, for instance) ? I think even if you do this you will not get standard-compliant AssociativeContainer The reason is simple: bdb cursor does not have all functionality of std iterator. > > If not, what should I do to be able to use my containers with > the bgl. > I haven't found any examples out there, and wondered if anyone tried > (and succeded) in this task. > > My second question is : how and when does the adjacency_list > instantiates its containers, and is there any way to mess with it, by > passing special arguments to the containers when instatiating > my graph > ? Reading the code and following the process in a debugger doesn't > really make my ideas clearer. > > Thanks in advance for any help and/or ideas > > Pierre > > -- > Written slowly for people who can't read fast. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

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

08 May '04

John Nagle wrote: >Reece Dunn wrote: >>John Nagle wrote: >> >>>Reece Dunn wrote: >>> >>>>There is currently a static-sized array in the Boost library that allows >>>>you to operate on arrays of fixed size. I was wondering if something >>>>similar exists for strings, in particular, providing buffer-overflow >>>>safe string operations. >>>> >>>>I have an nstring< std::size_t n > string class that provides size-safe >>>>copying and comparison, allowing for you to do things like: > >OK, thanks. First bug reports: > >1. Compile problems under VC++ 6: > No include brings in "std::size_t". Fixed. >2. VC++ 6.x complains about references to a zero-sized array for > [edit]: copy( const char( & s )[ m ] ) I have disabled these for VC6 since they are causing problems with the compiler, even with Thorsten Ottersen's workaround :(. >3. "copy" function does not place a trailing null in the string. >[snip] > Note that "strlen" returns a count that does NOT contain the null. I have added this facility as a template parameter (bool null_terminate). The logic behind this is when you do not specifically need a null-terminated string, e.g.: struct JPEGHeader { // ... boost::string::char_string< 4 > magic; // ... } hdr; if( hdr.magic != "JPEG" ) error( "invalid format" ); but also to allow it if you need that security. > All the operations should guarantee that the string remains null >terminated. A constructor should be provided, but all it has to >do is put a null in the first character position. I have already provided such a constructor :). > As for the naming issue, the important thing for retrofit work >is that it should be possible to write a "using" statement that makes >"strcopy", "sprintf", for char_string etc. valid without prefixes, and >doesn't break anything else. You should be able to include something >("safe_strings.hpp"?) that does as much as possible to fix old code. I have moved the char_string class into char_string.hpp and started work on providing safe versions of ::strXXX. It is not possible to use the same names (strlen, etc.) for the char_string versions :( as can be seen in the example below. #include <iostream> #include <cstring> namespace boost { namespace string { using ::strcpy; inline char * strcpy( char * d, const char * s, size_t n ) { return( ::strncpy( d, s, n )); } }} int main() { char str[ 100 ]; using boost::string::strcpy; ::strcpy( str, "Meine Welt!" ); std::cout << str << '\n'; ::strcpy( str, "1234567890", 5 ); // error std::cout << str << '\n'; return( 0 ); } Because of this, I have decided to use the c prefix (e.g. cstrlen). This seems the best solution, but if the c prefix is problematic, let me know and I'll change it. >This is a good start, and not hard to fix. I look forward to the >next round. I have included this round as attachments, but will place the next version in the boost sandbox. It has the signature: template< size_t n, bool null_terminate = true, typename CharT = char, class StringPolicy = std::char_traits< CharT > > class boost::string::char_string; and is the initial move towards a basic_string-like interface. How about the name fixed_string? Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

3 2