Re: [boost] [filesystem] create_directories
Beman Dawes wrote: Volodya, Agreed. BTW, where would that header live? In CVS tree or in sandbox? And what would be the access rules? No comment on this? Or, specifically, do you plan to add convenience.hpp to some CVS tree and place create_directories there any time soon? I've just added these convenience files to the main CVS: boost/filesystem/convenience.hpp libs/filesystem/doc/convenience.htm libs/filesystem/src/convenience.cpp libs/filesystem/test/convenience_test.cpp plus updated doc/index.htm, and the build and test Jamfiles to reference convenience. Take a look and see if I've missed anything. Everything looks OK. doc/convenience.htm is just a shell; I'm hoping you'll add create_directories() docs. Added. There needs to be some kind of precondition. Maybe: !exists(ph) || is_directory(ph) but it is more complicated than that. Say you code: create_directories( xx/yy/zz ); If zz doesn't exist, and xx/yy does, then xx/yy has to be a directory; xx/yy can't be a file. I'm not sure how to express a recursive precondition. I've writted that using forall, as mathematicians do. Hope this makes sense. Please take a look at the docs. I've had to use is_parent function, which does not exists, but hopefully the meaning is clear. What are the postconditions? In your posting, you gave: exists(ph) is_directory(ph) is_empty(ph) But is_empty(ph) would only apply if a new directory was created. You are right. There are also the cases create_directory() and Explicitly permitted by new preconditions. create_directory(/). To begin with, what's this? More concrete question --- is this empty relative path with trailing / or empty root name, followed by root directory, and then empty relative path? If this is the latter case, then... / is a directory and it most surely exists. See no problem there --- preconditions are satisfied. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] The Wonder of Tuples
Aleksey Gurtovoy wrote: David A. Greene wrote: The fundamental problem is that it's inconvenient to iterate through a tuple. 'tuple_ext' (tuple extensions) make it easier - http://groups.yahoo.com/group/Boost-Users/message/704. Has any discussion taken place about incorporating something like this into Boost? Seems like a useful bit of code. There has been some out-of-list discussion about this, and some work is being done. There's a PP based tuple implementation (mostly written by Joel) in Spirit's CVS that conforms to the Tuple speicification in the TR. (Note that the current Boost.Tuples is not one-to-one what was accepted into the TR. Most notably, the cons-list interface was not standardized.) The PP based tuples are not complete yet, and what the iteration interface will be is still undecided. /Jaakko -- -- -- Jaakko Järvi email: [EMAIL PROTECTED] -- Post Doctoral Fellow phone: +1 (812) 855-3608 -- Pervasive Technology Labs fax: +1 (812) 855-4829 -- Indiana University, Bloomington ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] gcc toolset problems
It seems that running the regression with multiple gcc toolsets has similar
issues with gcc as it had with intel-linux a couple of days ago. I am using:
$BOOST_BUILD_ROOT/tools/build/gcc2953-tools.jam
{
local GCC_ROOT_DIRECTORY = /opt/gcc2 ;
local GCC_STDLIB_DIRECTORY =
/opt/gcc2/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/ ;
extends-toolset gcc ;
}
$BOOST_BUILD_ROOT/tools/build/gcc2953-stlport-tools.jam
{
local GCC_ROOT_DIRECTORY = /opt/gcc2 ;
local GCC_STDLIB_DIRECTORY =
/opt/gcc2/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/ ;
local STLPORT_ROOT = /opt/gcc2 ;
local STLPORT_INCLUDE_DIRECTORY = include/stlport ;
extends-toolset gcc-stlport ;
}
And the command line:
bjam '-sTOOLS=gcc2953 gcc2953-stlport gcc'
is picking /opt/gcc2/bin/g++ as the compiler for the gcc toolset.
Any ideas?
Thanks,
--
Alkis
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] gcc toolset problems
[2002-12-23] Alkis Evlogimenos wrote:
It seems that running the regression with multiple gcc toolsets has similar
issues with gcc as it had with intel-linux a couple of days ago. I am
using:
$BOOST_BUILD_ROOT/tools/build/gcc2953-tools.jam
{
local GCC_ROOT_DIRECTORY = /opt/gcc2 ;
local GCC_STDLIB_DIRECTORY =
/opt/gcc2/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/ ;
extends-toolset gcc ;
}
$BOOST_BUILD_ROOT/tools/build/gcc2953-stlport-tools.jam
{
local GCC_ROOT_DIRECTORY = /opt/gcc2 ;
local GCC_STDLIB_DIRECTORY =
/opt/gcc2/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/ ;
local STLPORT_ROOT = /opt/gcc2 ;
local STLPORT_INCLUDE_DIRECTORY = include/stlport ;
extends-toolset gcc-stlport ;
}
And the command line:
bjam '-sTOOLS=gcc2953 gcc2953-stlport gcc'
is picking /opt/gcc2/bin/g++ as the compiler for the gcc toolset.
Any ideas?
Yes ;-) ... It's now fixed in CVS.
Thanks,
Your'e welcome.
-- grafik - Don't Assume Anything
-- [EMAIL PROTECTED] - [EMAIL PROTECTED]
-- 102708583@icq
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] The Wonder of Tuples
- Original Message - From: Jaakko Jarvi [EMAIL PROTECTED] Aleksey Gurtovoy wrote: David A. Greene wrote: The fundamental problem is that it's inconvenient to iterate through a tuple. 'tuple_ext' (tuple extensions) make it easier - http://groups.yahoo.com/group/Boost-Users/message/704. Has any discussion taken place about incorporating something like this into Boost? Seems like a useful bit of code. There has been some out-of-list discussion about this, and some work is being done. There's a PP based tuple implementation (mostly written by Joel) in Spirit's CVS that conforms to the Tuple speicification in the TR. (Note that the current Boost.Tuples is not one-to-one what was accepted into the TR. Most notably, the cons-list interface was not standardized.) The PP based tuples are not complete yet, and what the iteration interface will be is still undecided. Yup, I've been itching to reply to the thread but opted to wait for Jaakko. There's already a TR conformant tuple implementation in Spirit's CVS in the PHOENIX_X branch. It is PP and MPL based. Compiles on all relevant compilers. There is only one implementation, unlike boost tuples which has a different implementation for MSVC which can easily get out of sync (it is out of sync now in fact. e.g. the MSVC branch does not convert a make_tuple(ref(x)) to tupleX. And interestingly, some code that does not compile on some compilers now compile with this implementation. All of Jaakko's regression tests (except the cons related stuff) plus some more new ones compile and run. With the help of Jaakko, Aleksey et. al, I wish to implement a set of tuple algorithms similar to STLs. The tricky part is that it should work at compile time, run-time and half-run-compile time. Cheers, Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
