- Boost - lists.boost.org

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