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
--> 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
"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
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'
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 migh
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 th
"Ross Smith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Aleksandr Golovanov wrote:
> > "Ross Smith" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >
> >>Aleksandr Golovanov wrote:
> >>
> >>>Yesterday, I ran into a small problem, lexical_cast accepts copy
inste
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 to consider merging it to RC_1_30_0. I will n
When I fixed the problems with metrowerks needing static linking to
get locale support, intel-win32 started linking dynamically, and for
some reason it seems to need static linking to get facet support.
Therefore, I made the enclosed patch on the RC_1_30_0 branch.
facet-patch.zip
Description: Z
"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,
"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 doe
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 b
"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_traits::buffer_value_type" how about
> "dfs_buffer_traits::value_type"?
Sounds good.
>
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 r
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/t
"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
>>
>>
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 cle
"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" <[EMAI
"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 th
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? "
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 >actu
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
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
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 ios_st
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 per
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
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
schmoo> class dfs_traits {
schmoo> typedef typename graph_traits::ve
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: http://boost.so
[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-fil
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 ex
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) ]
>> {
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
are
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 d
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*,
The test case libs/integer/cstdint_test.cpp includes and
_before_ it defines __STDC_CONSTANT_MACROS. This means that on
a platform that (a) supports defining the C99 macros in when
__STDC_CONSTANT_MACROS is defined and (b) uses somewhere in
, the test fails, because __STDC_CONSTANT_MACROS has b
"Edward Diener"
>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.
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 d
>-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 (th
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, *d
"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
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
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 Wi
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 reas
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
> cu
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 worki
46 matches
Mail list logo
