- Boost - lists.boost.org

boost::dereferenceable<>::operator->() problem
by Pavel Kuznetsov 24 Aug '04

24 Aug '04

Recently two of our developers encountered the same problem with boost::dereferenceable<>::operator->(). There were an iterator which returned value_type from its operator*, not value_type&: value_type operator*() const; And it was inherited from boost::random_access_iterator_helper, which in turn is indirectly inherited from boost::dereferenceable. Since our iterator class template did not have its own operator->, one from boost::dereferenceable<> was inherited. And it is defined as follows: P operator->() const { return &*static_cast<const T&>(*this); } where P is pointer to value_type of corresponding iterator. Both of the compilers which we use (MSVC 6.0 and CodeWarrior) compile this code without any errors (though at least one of them did gave a warning). That lead to operator-> returning addres of a temporary object. What do you think about modifying operator-> so that it would be permissive to iterators for which operator* gives rvalue? E.g. this way: struct address_of_proxy { value_type value; address_of_proxy( value_type const& v ) : value( v ) { } operator value_type const*() const { return &value; } value_type const* operator->() const { return &value; } }; address_of_proxy operator->() const { return address_of_proxy( *static_cast<const T&>(*this) ); } where value_type is value_type of corresponding iterator. And of course it is possible to avoid creating proxy object when iterator's operator* returns reference, not value... -- Pavel Kuznetsov MetaCommunications Engineering http://www.meta-comm.com/engineering

2 7

Type mismatch in type_with_alignment.hpp
by Joaquín Mª López Muñoz 24 Aug '04

24 Aug '04

Most templates in these header take an alignment parameter of type size_t, yet a few of them accept an int instead: is_aligned type_with_alignment These causes in some compilers nasty truncation warnings when using aligned_storage with its default alignment_ parameter (maximum alignment) integer conversion resulted in truncation detected during: instantiation of class "boost::aligned_storage<size_, alignment_> [with size_=16UL, alignment_=18446744073709551615UL]" at line 114 of... 1. Is there any fundamental reason why some alingment parameters are int instead of size_t? 2. If not, any objection to fixing this in the CVS? 3. Could it be the other way around, namely that aligned_storage must use ints instead of size_t's? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

[bug] bug in 'octonion.hpp' file
by Oleg Anashkin 24 Aug '04

24 Aug '04

I think there is a bug in the 'octonion.hpp' file. There are several tt[0] consecutive assignments (lines 1243-1250, 1292-1299, 1340-1346). It seems that they should be changed to tt[0]..tt[7]. -- Thanks.

2 1

algorithm / string / container regression failure on tru64cxx65
by Markus Schöpflin 24 Aug '04

24 Aug '04

Hello, currently beforementioned test fails on tru64cxx65 with the following error message: cxx: Error: ../libs/algorithm/string/test/container_test.cpp, line 94: #434 a reference of type "char *&" (not const-qualified) cannot be initialized with a value of type "char [4]" argument_test( ach1, "abc" ); The underlying problem is illustrated by the following code snippet: ---%<--- template< typename T > void argument_cv_test( const T& C, const string& strResult ) { } template< typename T > void argument_test( T& C, const string& strResult ) { } void foo() { char ach1[]="abc"; argument_cv_test( ach1, "abc" ); // ok argument_test( ach1, "abc" ); // not ok } --->%--- The line marked as not ok triggers the error. I tried to compile that code snippet with Comeau online and it succeeds. But I could not find a definitive answer in the C++ standard whether that code is legal or not. If it's legal, could anyone please provide me with a reference to the paragraph of the standard which applies here? I would need that to file a proper bug report to HP. TIA, Markus

2 2

Re: [boost] Re: Re: New design proposal for boost::filesystem
by Ferdinand Prantl 24 Aug '04

24 Aug '04

Hi Patrick, > Patrick Bennett wrote: > > Ferdinand Prantl wrote: > > What do you think about imbuing and codecvt-like approach in > > boost::filesystem for the names of the files? > I don't (personally) care for it. More and more libraries and standards are using UTF-8 (for good > reason) these days. It's a nice, simple, and flexible encoding. I have nothing against usage of UTF-8 if it suits the scenario well. I just say that it is not an encoding for all purposes. It is a multibyte one and so extremely inefficient for getting size, searching, etc. Why to prescribe it for all boost::filesystem users and force them to put recoding into their sources, when it can be achived inside the boost::filesystem as it is done in std::streams? I would like to have the boost filesystem as flexible as possible. Someone can work with filenames in std::string in current locale, in UTF-8 or a different locale, someone can use std::wstring with UCS-2 or UTF-16, etc. The question is, if such a flexibility is not so rare, that it rather spoils the interface. I don't think so. > Win32 doesn't support UTF-8 filenames natively. That's why boost::filesystem > would have to convert to/from UCS-2 along Win32 interface boundaries. > If you're concerned about other platforms, you shouldn't be. boost::filesystem > currently works only with latin encodings in ascii strings so no functionality > would be taken away. UTF-8 is not identical with the complete iso-8859-1 (latin1) codepage. Some code could be broken by accepting UTF-8 in the new version. > The UTF-8 representation of ascii strings is identical, so if you already use > ascii strings, nothing will change, and nothing will break. If you want your > application to be runnable in multiple countries though, an operating system > which boost::filesystem has translations defined for would be required. Linux > is UTF-8 natively (assuming the right environment variable is set), so > boost::filesystem would just pass everything through as-is. The Win32 poet > would have to make some simple conversions (Windows even has built-in functions > to perform this conversion) . Other platforms might have to have make other > conversions to/from UTF-8, but assuming that platform supports Unicode at all, > this is a no-brainer. Linux can be configured to support UTF-8 natively. However, it is not necessary and depends on your locale installation and configuration. By imbuing I meant the conversion "application filenames encoding" -> "machine filenames encoding". Instead of putting a platform dependent code into conditions, which does the translation, one could simply say "I am running in UTF-8, boost::filesystem, please understand it and do the system translation for me". Exceptoins could sourt out incompatibilities. boost::filesystem::imbue("UTF-8"); // more abstract than codecvt pseudocode :-) In this example an internal conversion into UCS-2 would be done on Windows, on Linux it would depend on the configured locale and on the other systems, which could support ASCII only, it would convert into ASCII only. However, it does not constrain the application from running wholly in wchar_t (e.g. UCS-2) or char (UTF-8 or something else), or does not force the user to write extra code for character conversion if it is not necessary. Ferda > Patrick Bennett

1 0

Proposal for New Template Metafunction 'is_iterator'
by Alex Chovanec 24 Aug '04

24 Aug '04

Is there a utility in Boost which determines at compile time whether or not a given type meets the most basic requirements for an iterator, without generating an error if the test fails? (This last part is crucial, so concept checks are insufficient.) I recently needed something like this, and I couldn't seem to find it in any of the libraries, so I went ahead and wrote a template metafunction called 'is_iterator' which gets the job done. It uses the same SFINAE techniques as the enable_if library. The declaration looks like this: template <typename T> struct is_iterator; The 'is_iterator' struct template is a model of the "integral constant expression" concept. Thus, 'is_iterator<T>::value' evaluates to true if-and-only-if type T defines iterator traits as well as overloaded operators with the following signatures: boost::iterator_reference<T>::type operator*(void) const; boost::iterator_pointer<T>::type operator->(void) const; T & operator++(void); T operator++(int); These seem to be the minimal requirements (i.e. Readable and Incrementable) according to the New Iterator Concepts. Ideally, T would also have to be a Copy Constructible type, but I don't know of a reliable way to detect this. Originally, i needed the ability to determine at compile time whether or not a given type meets the requirements for a Readable Lvalue iterator. The 'is_readable_iterator' and 'is_lvalue_iterator' template metafunctions work fine for this purpose, except that they both generate an error when passed a template argument that is not an iterator at all. Assuming I'm correct in stating that a utility like 'is_iterator' does not already exist in Boost, is there any interest in such a utility? Thanks, Alex

4 16

boost-sandbox question
by Eric Niebler 23 Aug '04

23 Aug '04

I'd like to make the documentation for xpressive available from the boost-sandbox project home page, like the FSM docs (http://boost-sandbox.sourceforge.net/libs/fsm/doc/index.html) According to the SourceForge docs, I should be able to copy my files there with scp like this: scp index.html eric_niebler@shell.sourceforge.net:/home/groups/b/bo/boost-sandbox/htdoc/libs/xpressive But when I tried that, I got "permission denied". Then I ssh'ed to shell.sourceforge.net and tried to mkdir /home/groups/b/bo/boost-sandbox/htdoc/libs/xpressive, but I got "permission denied" there, too. Do I need special permission to be able to do this? I already have CVS write access -- I guess that's not enough. Any hints? -- Eric Niebler Boost Consulting www.boost-consulting.com

4 3

boost::random overflow bug
by Samuel Krempp 23 Aug '04

23 Aug '04

while checking uniform_int.hpp, I spotted 2 weirdnesses in uniform_int.hpp that almost cancel themselves out, but not to the point that a contrived example is impossible. The heart of the problem is this loop : while(mult <= limit) { result += (eng() - bmin) * mult; mult *= result_type(brange)+result_type(1); // <-- overflow possible } where limit = (range+1)/(brange+1) the multiplication is almost always guaranteed not to overflow (that was the motivation to write the loop that way, I guess), except when mult==limit (which is reached when range+1 is a power of brange+1) in that case, the last multiplication assigns (range+1) to mult. And range+1 might in fact overflow. Now, it turns out in cases where range+1 overflows, limit is computed with special anti-overflow code, and there 's a bizarre condition there that looks like a bug : if(_range % result_type(brange)+1 == result_type(brange)) ++limit; instead of expected if(_range % result_type(brange+1) == result_type(brange+1)) ++limit; so in the end, most of the time when range==max, limit is assigned the value : range/(brange+1) instead of (range+1)/(brange+1). So it cancels out the first bug most of the time (maybe that is the reason for the bizarre code). but the limit will still be equal to (range+1)/(brange+1) for brange=1 (I'm not sure how useful a coin-flipper generator would be, but we never know..), and mult can then be made to wrap and reach 0 in the previous loop, which loops forever. I've attached a compilable exemple and suggested patch. I've thought it over carefully, the patch works in all situations. after the test on (mult==limit), it's all safe since mult is guaranteed to be > limit, and thus _range/mult will still be < brange+1, so the recursive call at the end is safe. -- Samuel

2 2

Shouldn't boost::filesystem be BOOST_POSIX on cygwin?
by Carlo Wood 23 Aug '04

23 Aug '04

At several places in the code we find something like: // BOOST_POSIX or BOOST_WINDOWS specify which API to use. # if !defined( BOOST_WINDOWS ) && !defined( BOOST_POSIX ) # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) || defined(__CYGWIN__) # define BOOST_WINDOWS # else # define BOOST_POSIX # endif # endif (As in for example boost/libs/filesystem/src/path_posix_windows.cpp) This sets BOOST_WINDOWS explicitely, as default, for cygwin - which is a POSIX operating system with a single root. This breaks a lot of code - if not all - of boost::filesystem. For example, the following code: #include <iostream> #include <boost/filesystem/path.hpp> #include <boost/filesystem/operations.hpp> int main() { boost::filesystem::path p = "/usr"; if (!boost::filesystem::exists(p)) std::cerr << p.string() << " doesn't exist according to boost::filesystem" << std::endl; } indeed causes boost::filesystem::exists to return 'false' on cygwin while "/usr" definitely exists. The reason for that is obvious and looks like a clear bug: The code of boost::filesystem::exists is as follows: BOOST_FILESYSTEM_DECL bool exists( const path & ph ) { # ifdef BOOST_POSIX struct stat path_stat; if(::stat( ph.string().c_str(), &path_stat ) != 0) { if((errno == ENOENT) || (errno == ENOTDIR)) return false; // stat failed because the path does not exist // for any other error we assume the file does exist and fall through, // this may not be the best policy though... (JM 20040330) } return true; # else if(::GetFileAttributesA( ph.string().c_str() ) == 0xFFFFFFFF) { UINT err = ::GetLastError(); if((err == ERROR_FILE_NOT_FOUND) || (err == ERROR_PATH_NOT_FOUND) || (err == ERROR_INVALID_NAME)) return false; // GetFileAttributes failed because the path does not exist // for any other error we assume the file does exist and fall through, // this may not be the best policy though... (JM 20040330) return true; } return true; # endif } Therefore, with BOOST_POSIX undefined, "/usr" is passed directly to ::GetFileAttributesA() and that can obviously not work. My question is therefore: shouldn't BOOST_POSIX be forced to be defined on cygwin? -- Carlo Wood <carlo(a)alinoe.com> PS Please note that, looking at http://www.meta-comm.com/engineering/boost-regression/developer/summary.html nobody is running the testsuite on cygwin! How broken on cygwin is boost really?

8 21

boost::random uniform_int bias and speed
by Samuel Krempp 23 Aug '04

23 Aug '04

Looking inside boost::random, I noticed a few things that I think could be better, and since I could not find mentions about those in the lists's archive, I'll ask here. 1. the case : brange / _range <= 4 Is implemented by rejection, directly. But the average number of rejects could be decreased (by a factor up to 4) by rescaling before rejection. i.e. (pseudo code) : .k = (brange+1) / (_range+1) .rejection_thresh = k * (_range+1) .keep generating random number until result < rejection_thresh .return result/k; the probabilty of a reject is then less than _range/brange, and also always less than 1/2, and can reach 0 (if (brange+1) is a multiple of (_range+1)) Was this possible speedup considered useless ? 2. the case brange / _range > 4 since direct rejection could mean very very many retries in this case, this case is dealt with uniform_smallint (which always uses exactly one number generation). But by using previous rejection scheme, there is no need for this case since the average number of needed number generations will be fairly close to 1, and the generator's speed will be equivalent to uniform_smallint. Plus, using a rejection scheme would completely avoid any added bias (contrary to uniform_smallint in which the added bias can reach 1/32, thus unsuitable for high-precision statistics programs) Why not use such a "rescaled" rejection scheme as I describe rather than uniform_smallint's possibly biased computation ? -- Samuel

1 2