- Boost - lists.preview.boost.org

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

numeric/ublas aix test failures
by Michael Stevens 23 Aug '04

23 Aug '04

Hallo Danial, > I am interested in using ublas for a large government project. > I noticed ublas (as of 8-19-2004) failed test3 on the visual age c++ compiler. > What does this test exercise? Test3 exercise the whole spectrum of sparse vector and matrix types with a variety of BLAS operations. These tests are by far the most demanding on the compiler. Unless > We have currently installed the 1.31 libraries. Is this the same code that > produced the test results? The the code the regression test use is take from the HEAD of Boost CVS. This code has been developed a great deal since Boost-1.31 The aim at the moment is to get maximum compiler compatibility. Bar an incorrect commit over the weekend and the recent noncopyable problems this is progressing well. I have cross posted this to the ublas-dev mailing list. This is the best place for uBLAS specific discussion as there are many active contributers. In particular you will find many people who also use Visual age C++ on large systems. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

1 0

Segfault at program exit using memory pools
by Thomas 22 Aug '04

22 Aug '04

Hi all, I'm running into a problem where I'm getting a segfault when my program exits when I use boost's memory pools. If I call purge_memory right before the end of the program, that also produces the segfault. Basically all I'm doing with the pools is calling ordered_malloc to allocate memory for arrays, and then free(myPointer,size_of_array) to de-allocate the memory. Oddly enough, when I run the code through valgrind, I don't get the segfault at all. I'm pretty sure that it's not bad memory or anything like that because none of the other programs I compile & run yields this kind of result. Any thoughts on what might be going wrong? Thanks Tom -- Thomas <hazard(a)imsa.edu>

1 0

Successfully compiled & static linked with Boost.Threads using Visual Studio .NET 2003
by David Barrett 22 Aug '04

22 Aug '04

Hi, I see a lot of people have been having problems statically-linking Boost.Threads with Visual Studio .NET 2003. For what it's worth, I just got it to work, and here's what I did: 1) Created and entered a C:\Libraries folder C:\> Mkdir c:\Libraries C:\> cd c:\Libraries 2) Checked out the latest code from CVS using: (From http://boost.org/more/getting_started.html) cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost login [Hit <return> when it asks for a password] cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost checkout boost cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/boost logout 3) Installed Boost.Build and Boost.Jam 4) Built everything: C:\Libraries\Boost> bjam --prefix=c:\Libraries\Boost install 5) Launched Visual Studio .NET 2003 6) Created a new Win32 Console Project (CTRL+SHIFT+N) and accompanying solution named BoostTest 7) Configured the wizard to create an Empty Project (click "Application Settings", check "Empty Project", click "Finish") 8) Configured the project to use the "Multi-threaded Debug Runtime Library" (Project::BootTest Properties, C/C++::Code Generation::Runtime Library) 9) Configured the project to search for the Boost include files (Project::BootTest Properties, C/C++::General::Additional Include Directories) by adding: C:\Libraries\boost\include 10) Created a new file named BoostTest.cpp (CTRL+SHIFT+A, click "C++ File", type "BoostTest.cpp" in the Name field, click Open) 11) Inserted the single include line: #include <boost/thread/thread.hpp> 12) Compiled (CTRL+F7) 13) It works! So yes, that all seems pretty obvious. But it took me a long time to get working. I was unable to get anything with a Boost.Thread header to compile *at all* (with any combination of static/dynamic runtimes, #defines, and code hacks) using the 1.31.0 release currently available for download via SourceForge. But it works now, and I'm proof that it can be done. Good luck! -david

1 0

Re: [boost] New design proposal for boost::filesystem
by Reece Dunn 22 Aug '04

22 Aug '04

Carlo Wood wrote: >On Sat, Aug 21, 2004 at 11:36:31AM +0100, John Maddock wrote: > > > 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 > > > > That is true now. > >No, the current implementation/design doesn't restrict anything at all >in this regard. You can just use fs::path to store paths - and that is >it. A path is not aware of a distinct difference between complete >paths and relative paths (except that they are complete or relative >of course) - definitely not in the same way as a design would that >uses two different classes for the two. A complete path is one that is fully qualified, thus: fs::path absolute = fs::path( "d:/devel/libraries/boost/1.31.0/libs" ); whereas a relative path is one that is "relative" to another. With a relative path, you must have an absolute path as the basis, e.g.: fs::path relative = fs::path( "../boost/mpl" ); and can turn the relative path into an absolute one by doing: fs::path qualified = absolute / relative; so where is the problem? >The most problematic difference is that it is possible to even store >a third possibility (one that is neither complete nor relative). ??? Do you mean one that isn't relative because it is not based from an absoute path, or that the path does not exist? If so, you can do that in any file system, e.g.: fs::path foobar = fs::path( "../booster/foobar.foo" ); fs::exists( absolute / foobar ); A path will either (in absolute form) refer to a file, a directory or be invalid. > > > * 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. > > > > That is also true now, isn't it? > >No, because the 'native' that you can specify with the current design >is only a check on the characters used in the directory components, and >only related to the representation of a path - not *marking* the path >as different. The 'native' I am talking about is enforced for complete >paths and reflexs also the root part of a directory ("C:\", "c:/cywgin/", >"/" etc). The essential difference is that a path that is once marked >as 'native' must stay native. It can never be converted to a portable >path anymore. Only relative paths that are portable from the start >can stay portable after certain operations (like appending a directory, or >cutting off a directory at the end). The native you are referring to is an "absolute" path, correct? Boost.Filesystem stores the paths in a generic form. Thus, if your filesystem uses ':' as a directory separator, the library will map this correctly from it's internal state. If you enforce that all "native" Windows paths must have a directory, you are restricting the use of the library, e.g. "\\mycomp\devel\libraries" is not possible! Likewise, it would not be possible to store URLs. NOTE: I am not sure if Boost.Filesystem currently supports URLs, but it should be possible to extend it to add that support. Also, URLs are not attached to a particular filesystem and are thus portable. It should be possible to handle both URLs and native paths, but limiting "native" paths will only make this harder. > > > 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()). This would make things too restrictive. I think you are confusing "native" with "absolute" paths, but how do you validate an absolute path? Is there a Windows and a POSIX function to validate an absolute path (e.g. IsPathAbsoute)? It would then be possible to have a fs::is_absolute( ... ) function. > > > 2) All 'complete' paths are automatically marked as 'native'. Likewise, how do you validate a complete path? What about a URL? If you have the URL "http://www.boost.org/people" and are using a system whereby the native directory separator is ':', the URL will be mapped to "http:::www.boost.org:people", corrupting the URL. > > If I understand you correctly, you are suggesting that error checking is > > turned off for native paths, I would support that, but other than that I > > don't see how it differs. > >Heh - the current design does NOT have an internal state that marks >a path as native or not. Hence, it cannot do sensible error checks >that need that knowledge. Isn't that difference enough? Native - as Boost.FileSystem uses it - is used to mark a path as using the native OS syntax for specifying paths. This is so you can do: fs::system_complete( fs::path( argv[1], fs::native ) ); and use the library on Windows, *nix, OpenVMS, MacOS, etc. without having to worry about the differences between how they specify their paths and thus what regular expressions need to be used on the string. The example from the documentation (using OpenVMS) is: DISK$SCRATCH:[GEORGE.PROJECT1.DAT]BIG_DATA_FILE.NTP;5 > > > 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. > > > > Not useless at all. And works now. > ^^^^^^^^^^^^^^^^ > \__ this. > >That is not backupped. Did you mean p to be the relative path p3? If so, then p3.native_directory_string() is perfectly valid and *not* useless. If the OS uses ':' as it's directory separator, then this will return "foo:bar". It is useful for all sorts of purposes, like debuging. > > > fs::path p4(complete(p3)); // p4 is now "native", because now it is > > complete. Why does native ==> complete? You can have a native relative and/or complete path. > > > std::cout << p4.string() // Not allowed because p4 is native >(complete). Huh? IIUC path.string() returns the internal format of the path (e.g. "foo/bar") whereas path.native_directory_string() returns the path as represented by the native OS (e.g. "foo:bar"). >Right now you can call all the operations that actually pass a path to some >system call - and UNLESS that path is complete - it will not be >non-portable. Not true. "foo/bar" is relative *and* non-portable for OS's that use ':' as a directory separator. >THAT means that boost::filesystem has a structural design error. You are >now saying that I can complete all paths just prior to calling any >operation >that passes paths to system calls. Would you mind even listing those for >me? >Why not change boost::filesystem so that it takes care of completion >automatically when needed? That way you cannot make errors. If you have an absolute path boost_dir and a relative path boost_build2, you can do: ::SetWorkingDirectory(( boost_dir / boost_build2 ).native_directory_string().c_str()); >As an example - I developed my application first on GNU/Linux with as only >demand that it had to be portable to cygwin. Therefore, I used UNIX paths. >Testing if /usr/src/edragon/edragon/build/src/gui/gui.la existed on linux >worked fine. It did NOT work on cygwin. Because I was stupid? No, I >think >that was because boost::filesystem is not activily supporting portable >programming. Did you check that you have the file where you said on the cygwin system. Have you checked that "/usr/bin/ls.exe" exists? Also, have you checked that BOOST_POSIX is defined as per the note on using the cygwin platform in the docs? Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1