Title: RE: [boost] Re: boost::filesystem file restrictions
From: David Abrahams [mailto:[EMAIL PROTECTED]]
portable_path(/foo/bar) - throws on Windows
Not sure why this would throw, what is the purpose of portable_path?
/foo/bar is perfectly reasonable on Windows.
It's perfectly
Brian McNamara wrote:
On Mon, Jul 28, 2003 at 03:16:52PM -0400, Brian McNamara wrote:
functional programming. Over the next couple of weeks I will make
documentation of the boostified version of FC++ that's
aimed at a C++
audience. Hopefully that will help.
I've been working on a
Glen Knowles wrote:
This is also a way we could solve the whole problem of absolute
paths. It's clear that /foo isn't an absolute native windows path.
This is not at all clear. I have and will contain to argue that
/foo is an absolute windows path, since it does not respect the
current
Glen Knowles [EMAIL PROTECTED] writes:
From: David Abrahams [mailto:[EMAIL PROTECTED]
portable_path(/foo/bar) - throws on Windows
Not sure why this would throw, what is the purpose of portable_path?
/foo/bar is perfectly reasonable on Windows.
It's perfectly reasonable but it doesn't
David Abrahams wrote:
Glen Knowles [EMAIL PROTECTED] writes:
From: David Abrahams [mailto:[EMAIL PROTECTED]
portable_path(/foo/bar) - throws on Windows
Not sure why this would throw, what is the purpose of
portable_path? /foo/bar is perfectly reasonable on Windows.
It's perfectly
On Fri, Aug 15, 2003 at 11:29:49AM +0200, Hartmut Kaiser wrote:
You've done a great piece of code! I've tried to understand your
articles about the differences between fcpp and boost::lambda/bind/etc.
and these (the differences) are now clear to me (to some degree :-).
OTOH I know, that
Edward Diener [EMAIL PROTECTED] writes:
David Abrahams wrote:
A path on windows that starts with '/' is a set
of instructions which begins: go to the root of the current
directory path.
Correction. It does not mean that. It means go to the root directory of the
current drive.
Is the
Title: RE: [boost] Re: boost::filesystem file restrictions
From: David Abrahams [mailto:[EMAIL PROTECTED]]
Yes, an absolute URI identifies a single location in the virtual name
tree. The only way to make this like a current-drive-relative path is
to consider processes which are moved,
-Original Message-
From: Brian McNamara [mailto:[EMAIL PROTECTED]
On Fri, Aug 15, 2003 at 11:29:49AM +0200, Hartmut Kaiser wrote:
You've done a great piece of code! I've tried to understand your
articles about the differences between fcpp and boost::lambda/bind/etc.
and these (the
David Abrahams wrote:
Edward Diener [EMAIL PROTECTED] writes:
David Abrahams wrote:
A path on windows that starts with '/' is a set
of instructions which begins: go to the root of the current
directory path.
Correction. It does not mean that. It means go to the root directory
of the
Can FC++ be accepted into Boost prior to any integration with
lambda/phoenix/bind?
Also it would be nice if FC++ played nice with bind as its in the std::TR1. You
mentioned that you already did std::result_of, and that will help. But I don't see
this as holding up acceptance into boost. The
history comments='below'
Edward Diener
Glen Knowles [EMAIL PROTECTED] writes:
From: David Abrahams [mailto:[EMAIL PROTECTED]
Yes, an absolute URI identifies a single location in the virtual name
tree. The only way to make this like a current-drive-relative path is
to consider processes which are moved, *during execution*, across a
David Abrahams wrote:
Edward Diener [EMAIL PROTECTED] writes:
David Abrahams wrote:
A path on windows that starts with '/' is a set
of instructions which begins: go to the root of the current
directory path.
Correction. It does not mean that. It means go to the root directory
of the
Title: RE: [boost] Re: boost::filesystem file restrictions
/blah is not an absolute path under Windows. It is relative to the current
drive ( or the drive of the current directory, which is the same ). Any file
system paths in Windows are absolute when specifying a drive letter, else they
Samuel Krempp [EMAIL PROTECTED] writes:
David Abrahams a écrit :
Yes, that's the problem. There is another way:
rule format-rtlink ( toolset variant : properties* )
{
if [ MATCH .*(metrowerks).* : $(toolset) ] || [ MATCH
.*(cwpro).* : $(toolset) ]
{
return
From: Brian McNamara [EMAIL PROTECTED]
to think deeply about it though; it is unclear to me if the FC++
implicit assumption of 'value semantics' (FC++ doesn't allow (mutable)
reference parameters) will throw a wrench in the works. It is also
I tried using FC++ a while ago for flexibly
[EMAIL PROTECTED] writes:
I'm just a confused lurker seeking some clarification. I thought most OSs
allowed a process filesystem to be dynamically re-rooted and that '/'
refers to the current root - whatever the OS (assuming hierarchical
filesystem[s]). If you introduce the extra-filesystem
David Abrahams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Fernando Cacciola [EMAIL PROTECTED] writes:
David Abrahams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Fernando Cacciola [EMAIL PROTECTED] writes:
The page is:
Hi Bruce,
Sounds like a good idea to me! Do you want to take a stab at making this
change? Perhaps just DFS to begin with and then the other algorithms
afterwards.
On Thu, 14 Aug 2003, Bruce Barr wrote:
schmoo template typename G
schmoo class dfs_traits {
schmoo typedef typename
At 03:28 PM 8/14/2003, David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
I am not sure that it should be the responsibility of the path class to
enforce some notion of portability. Wouldn't it be more appropriate to
defer the portability check, if any, to the point where the path is
At 01:40 PM 8/14/2003, Peter Dimov wrote:
Beman Dawes wrote:
The current approach is clearly too restrictive and isn't
satisfactory. Beyond the problems you mention, there really isn't a
single standard for portability. Even 8.3 names aren't portable to
systems which don't allow periods in
David Abrahams wrote:
Samuel Krempp [EMAIL PROTECTED] writes:
...
Unfortunately, I left home again and I'd have a hard time commiting
changes to the boost cvs where I am now.
can you please make the changes to
$Boost/libs/format/tests/Jamfile and commit ?
oh, and while you're at it,
the
Title: RE: [boost] Re: boost::filesystem file restrictions
We seem to be at an impasse. To summarize, you think:
David Abrahams wrote:
It's clear that /foo isn't an absolute native windows path.
Where as I think:
This is not at all clear.
Glen
On Fri, Aug 15, 2003 at 02:44:20PM -0400, Joel Young wrote:
From: Brian McNamara [EMAIL PROTECTED]
to think deeply about it though; it is unclear to me if the FC++
implicit assumption of 'value semantics' (FC++ doesn't allow (mutable)
reference parameters) will throw a wrench in the works.
Beman Dawes wrote:
At 01:40 PM 8/14/2003, Peter Dimov wrote:
I am not sure that it should be the responsibility of the path
class to enforce some notion of portability. Wouldn't it be more
appropriate to defer the portability check, if any, to the point
where the path is actually used
At Friday 2003-08-15 08:35, you wrote:
David Abrahams wrote:
Glen Knowles [EMAIL PROTECTED] writes:
From: David Abrahams [mailto:[EMAIL PROTECTED]
portable_path(/foo/bar) - throws on Windows
Not sure why this would throw, what is the purpose of
portable_path? /foo/bar is perfectly
John Maddock [EMAIL PROTECTED] writes:
Currently, BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS
is not defined for gcc. However, the following URL in the gcc bug
database
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7676
leads me to believe that the macro should be set on for the appropriate
Fernando Cacciola [EMAIL PROTECTED] writes:
David Abrahams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Fernando Cacciola [EMAIL PROTECTED] writes:
David Abrahams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Fernando Cacciola [EMAIL PROTECTED] writes:
The
Title: RE: [boost] Re: boost::filesystem file restrictions
From: Peter Dimov [mailto:[EMAIL PROTECTED]]
Glen Knowles wrote:
This is also a way we could solve the whole problem of absolute
paths. It's clear that /foo isn't an absolute native windows path.
This is not at all clear. I have
Victor A. Wagner, Jr. [EMAIL PROTECTED] writes:
At Friday 2003-08-15 08:35, you wrote:
David Abrahams wrote:
Glen Knowles [EMAIL PROTECTED] writes:
From: David Abrahams [mailto:[EMAIL PROTECTED]
portable_path(/foo/bar) - throws on Windows
Not sure why this would throw, what is
Martin Wille [EMAIL PROTECTED] writes:
David Abrahams wrote:
Samuel Krempp [EMAIL PROTECTED] writes:
...
Unfortunately, I left home again and I'd have a hard time commiting
changes to the boost cvs where I am now.
can you please make the changes to
$Boost/libs/format/tests/Jamfile and
David Abrahams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Fernando Cacciola [EMAIL PROTECTED] writes:
[sniped]
How do I apply the patch?
I mean, what do I do with CVS to have it on the right branch/tag.
(I guess that if I just commit it, it won't end on the right place)
Jeremy Siek wrote:
Hi Bruce,
'Sup Jeremy,
Do you want to take a stab at making this change?
Sure.
Perhaps just DFS to begin with and then the other algorithms
afterwards.
Alright.
instead of dfs_traitsG::buffer_value_type how about
dfs_buffer_traitsG::value_type?
Sounds good.
To
At Friday 2003-08-15 14:03, you wrote:
Victor A. Wagner, Jr. [EMAIL PROTECTED] writes:
[deleted]
That changes the physical file(s) associated with certain paths, just
like deleting and creating files or creating symlinks. It does not
change where those paths refer to in the filesystem.
I'd be
Victor A. Wagner, Jr. [EMAIL PROTECTED] writes:
At Friday 2003-08-15 14:03, you wrote:
Victor A. Wagner, Jr. [EMAIL PROTECTED] writes:
[deleted]
That changes the physical file(s) associated with certain paths, just
like deleting and creating files or creating symlinks. It does not
change where
Jeff Garland [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Sure, can do. What would you call it: merge_inclusive, earliest_latest,
rename
merge to union and call it merge, something else?
Yes, the hardest thing is to think of a name. I don't think you can rename
merge to union,
On Sat, 16 Aug 2003 09:05:10 +1000, Chris Trengove wrote
Jeff Garland [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Sure, can do. What would you call it: merge_inclusive, earliest_latest,
rename
merge to union and call it merge, something else?
Yes, the hardest thing is to
Daniel Frey [EMAIL PROTECTED] writes:
Hi Dave,
I checked in a fix for checked_delete.hpp for the Metrowerks CW8 to CVS
HEAD. It was created in cooperation with Howard and I'm positiv that it's
a good one-size-fits-all solution. I don't know about your shedule for
1.30.2, but you might want
David Abrahams [EMAIL PROTECTED] writes:
Daniel Frey [EMAIL PROTECTED] writes:
Hi Dave,
I checked in a fix for checked_delete.hpp for the Metrowerks CW8 to CVS
HEAD. It was created in cooperation with Howard and I'm positiv that it's
a good one-size-fits-all solution. I don't know about
Jeff Garland [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I don't think the it is technically a union because the result draws in
points in the time period that aren't part of either of the initial
periods.
Anyway I wrote the code as merge_inclusive so unless you have a major
-- portable_path(/foo/bar) - throws on Windows
--
-- Not sure why this would throw, what is the purpose of
-- portable_path? /foo/bar is perfectly reasonable on Windows.
-
- It's perfectly reasonable but it doesn't have a portable meaning.
- It
- is a relative
Dave Gomboc [EMAIL PROTECTED] writes:
--- Filesystems belong to computers. A computer's filesystem is accessed
--- via an infinite tree of names (**). How those names which correspond
--- actual storage are mapped can be modified dynamically in any number of
--- ways: you can have symbolic
43 matches
Mail list logo
