- Boost - lists.preview.boost.org

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