- Boost - lists.boost.org

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