August 2004 - Boost - lists.boost.org

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 24 Aug '04

24 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 24 Aug '04

24 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

RE: [boost] Java style GUI in C++
by Hurd, Matthew 23 Aug '04

23 Aug '04

> Behalf Of John Torjo > > Some rambling thoughts on things I'd like to see are: > > > > 1. run-time and compile-time configurability, especially with some like > > compile time specification language like layout capability. There was > > some talk about this and some suggestions previously on this list. > > Marrying this to run-time would be interesting. > > > > Perhaps at compile time you can decide if there is an explicit handling > > method and if not call something with your source and event type that > > will dispatch. However this would lock you in at run-time if did this > > as a compile time metaprogramming thing that ending up optimizing to a > > function call equivalent but perhaps both options are appropriate... > > that's more or less what win32gui does. > > And more to the point, when you extend a window class, you can add your > own handlers into the picture. > > Thus, you can end up with more event handlers for the same > event/command/notificiation. > > This is TOTALLY ok. > Whenever a handler for an event/command/notification gets called, it can > decide what to consider this event: > - event_not_handled: I consider this handler did not handle this event. > If more handlers exist, call them. If no more handlers, call default (in > our case, DefWindowProc) > > - event_is_handling. I did handle his event, but it's ok if other > handlers handle it too. So, if there are other handlers, call them too. > After all handlers are called, DO NOT call default (in our case, > DefWindowProc). > > - event_handled: I handled this event. DO NOT call other handlers, nor > the default( DefWindowProc). > > > I thinks this handles most (if not all) cases. Yep, in my mind it should be handled by the highest level event handler in the structural tree composite thingo that represents the ui layout. That event handler has the option to allow dispatch to the next lower level handler. I was thinking that you would attach event handlers for messages from sources to any place in the structural ui tree. It is handled by the highest handler in the structural tree or it is ignored if there is no handler. > > > > 2. reverse structural inheritance of events handler equivalents. > > Widgets are composed of other widgets. A window may handle the click, > > or prevent it, for a child. You can attach a handler for a named event > > at any point in the composition / structural hierarchy, it doesn't have > > to be the source, but is aware of it. Handling goes down the hierarchy > > to source. > > In fact, I think it should be quite reversed. > If a window cannot handle a command/notification, forward it to its > parent and so on - until someone handles it or reaches top. I think it should be the other way around, if I understand it. You need to be able to over-ride the behaviour of your components by interposing another handler. E.g. don't do the normal stock window click event do this instead (which may also continue the chain down...). More importantly, should be able to disable and enable all contained (child) messages. Doing so by category as someone else suggested would be nice... e.g. all drag drop, all mouse, etc... Goodluck, your lib sounds interesting. Matt. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

New design proposal for boost::filesystem
by Carlo Wood 23 Aug '04

23 Aug '04

I propose the following design. The aim of boost::filesystem should be to support the following coding idiom: * The programmer should take care to only handle two types of paths in his application: 1) Complete paths 2) Relative paths * The programmer will have to specifically tell the libary when a constructed path is 'native' and when not. A native path is accepted according to native rules and never gives any problem (exceptions) further on. A non-native path is checked according to the existing rules, which basically means that the programmer can set a default check routine that will in effect determine how portable the application will be. I propose two design changes: 1) 'native' is now not only a representation, but an *internal state* of fs::path. (this has no effect on the representation as returned by fs::path::string()). 2) All 'complete' paths are automatically marked as 'native'. Examples, the following code is legal: fs::path p1("C:\\foo\\a.exe", native); // As one might do on windows. fs::path p2("/usr/src/a.out, native); // As one might do on linux. std::cout << p1.native_file_string(); // ok, p1 is native. fs::path p3("foo/bar"); // Relative path, always succeeds. std::cout << p.string(); // ok std::cout << p.native_directory_string(); // Useless, but ok. fs::path p4(complete(p3)); // p4 is now "native", because now it is complete. std::cout << p4.native_directory_string(); // ok And the following will fail (assertion?): std::cout << p4.string() // Not allowed because p4 is native (complete). Since there would be a default way defined of how a relative path is completed, all operation functions will accept both, relative and complete paths. For example: fs::path p1("C:\\cygwin\\usr/bin/ls", native); // Legal path on Cygwin. if (fs::exists(p1)) // Ok, access complete path. // For clarification fs::path p2("C:\\cygwin\\usr"); // Just an example fs::default_working_directory(p2); // fictuous function. fs::path p3("bin/ls"); // Portable representation (refers in fact to "C:\cygwin\usr\bin\ls.exe"). if (fs::exists(p3)) // Ok : exists() will make the path complete before testing. And this throws: fs::path p4("/bin/ls"); // Not allowed: this path has a root but is not marked 'native'. Setting the default_working_directory shall allways need to be done for each supported OS seperately. Of course you can set it to "/" on single root machines, and set it to "E:/" after extracting the 'E:' from the current path at application start up, in effect simulating a 'single root': int main() { fs::default_working_directory(fs::current_path().root_path()); // ... simulate single root machine below. fs::path p("bin/ls"); } The average application will work with relative paths, relative to some (native) base directory and next to that have some arbitrary, complete and thus native directories (ie, read from environment variables). But in case more than one 'working' directory seems needed then we can add support for that too by allowing to construct paths with a reference to the (complete/native) working directory. Ie, fs::path homedir(g_getenv("HOME"), native); fs::path rcdir(homedir / "edragon/rc", native); fs::path tmpdir(current_path().root_path() / "tmp"); // ... fs::path runtime_rcfile(rcdir); // Set 'runtime_rcfile' to be relative to 'rcdir'. // ... runtime_rcfile = "config/runtimerc"; which is then relative to `rcdir' instead of a single, global 'working directory' (as now returned by fs::current_path()). Most of the current boost::filesystem API can be preserved with this design. -- Carlo Wood <carlo(a)alinoe.com>

10 26

Re: [boost] numeric-ublas errors with Comeau
by Michael Stevens 23 Aug '04

23 Aug '04

Hi Bronek, > "C:\Comeau\libcomo\concept_checks.h", line 423: error #349: no operator "!=" > matches these operands > operand types are: I agree with Comeau. The index_pair/triple helpers need and != to be Equity Comparable. Fixed and committed. Michael

1 0

re: [boost] numeric-ublas errors with Comeau
by Michael Stevens 23 Aug '04

23 Aug '04

Bronek Kozicki wrote: > All tests in numeric-ublas are failing in Comeau compiler. Most of these > errors can be fixed if we define BOOST_UBLAS_NO_CMATH in > boost/numeric/unblas/config.hpp for this compiler. Patch attached Sorry I missed the first posting. A case on mailing list overload. > Hello, is there maintainer of numberic-ublas? Certainly! Looking at patch simply defining NO_CMATH for all Comeau versions does not seem to be a good idea. The problem appears to be the old std::abs is not defined for built in types. I sure the problem will non exist for ever in the Comeau library. It could also be due to the --vc71 compatibility flag being set. Do you know what the current __LIBCOMO_VERSION__ is and if the problem still exists. Thanks, Michael

3 5

[tools.regression] performance patch
by Markus Schöpflin 23 Aug '04

23 Aug '04

On my platform (tru64cxx65) the appended patch speeds up process_jam_log by a factor of five(!). If the patch is ok, could anyone please apply it? TIA, Markus *** /vol1/tmp/boost/boost/tools/regression/process_jam_log.cpp Tue Aug 10 10:34:19 2004 --- process_jam_log.cpp Fri Aug 20 09:20:01 2004 *************** *** 50,55 **** --- 50,58 ---- || src.find( "cc1plus.exe: warning: as it has already been specified as a non-system directory" ) != string::npos ) return; + // on some platforms (e.g. tru64cxx) the following line is a real performance boost + target.reserve(src.size() * 2 + target.size()); + for ( string::size_type pos = 0; pos < src.size(); ++pos ) { if ( src[pos] == '<' ) target += "<";

2 3