May 2004 - Boost - lists.preview.boost.org

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

[Formal review] Collection Traits library
by hartmutkaiser＠t-online.de 08 May '04

08 May '04

Hi all, The review of the Collection Traits library, written by Thorsten Ottosen starts today (April 28th, 2004) and runs for 10 days (until May 7th, 2004). The Latest version of the library is available at (yahoo files sections): http://tinyurl.com/ysbaj (72 kB) or in the Boost sandbox. What is it? The Collection Traits library is mainly a tool for writing generic algorithms that work on External Collections. A Collection is a subset of the container requirements; it is so small and essential that it can be made to work with standard containers, iterator-views, built-in arrays and strings by defining a new requirement, the External Collection Concept, where typedefs and functions have been made free-standing instead of members. The library consists of two components: (1) type generators and (2) free-standing functions. The type-generators provide types such as iterators and size_type of external collections whereas the Free-standing functions are for extracting iterators and size of the external collections. Here is a small example: // Example: extracting bounds in generic algorithms template< typename ExternalCollection, typename T > inline typename boost::iterator_of<ExternalCollection>::type find( ExternalCollection& c, const T& value ) { return std::find( boost::begin( c ), boost::end( c ), value´); } template< typename ExternalCollection, typename T > inline typename boost::const_iterator_of<ExternalCollection>::type find( const ExternalCollection& c, const T& value ) { return std::find( boost::begin( c ), boost::end( c ), value´); } // replace first value and return its index template< typename EC, typename T > inline typename boost::size_type_of< EC >::type my_generic_replace( EC& c, const T& value, const T& replacement ) { boost::iterator_of<EC>::type found = find( c, v ); *found = replacement; return std::distance( boost::begin( c ), found ); } // usage std::vector<int> my_vector; typedef vector<int>::iterator iterator; std::pair<iterator,iterator> my_view( my_vector.begin(), my_vector.begin() + N ); char str[] = "a string"; // ... std::cout << my_generic_replace( my_vector, 4, 2 ) << my_generic_replace( my_view, 4, 2 ) << my_generic_replace( str, 'a', 'b' ); As the External Concepts idea is a rather new one, I would like to ask you to comment on this. Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

20 102