|
Boost : |
From: SourceForge.net (noreply_at_[hidden])
Date: 2004-08-19 07:01:17
Bugs item #1012135, was opened at 2004-08-19 14:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1012135&group_id=7586
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Carlo Wood (libcw)
Assigned to: Nobody/Anonymous (nobody)
Summary: boost::filesystem is systematically broken
Initial Comment:
As is currently discussed on the boost mailinglist,
cygwin is
supposed to support windows paths (at least, when compiled
with BOOST_WINDOWS, which is currently the default).
I understand that Beman, the author of boost::filesystem,
wants it that way.
However, boost::filesystem does not accept a path like
"/usr"
(fs::exists fails in that case), when compiled with
BOOST_WINDOWS
and it *also* doesn't accept windows paths, like
"c:/cygwin/usr",
"C:\cygwin\usr" or anything remotely 'windows' like,
because it
throws when you try to construct a fs::path with a
colon in it!
As a result, one can ONLY construct usable paths on
cygwin in the very non-portable format
"/cggdrive/c/cygwin/usr" which is neither POSIX (on
linux the same path would be "/usr") nor native (the
_users_ of the application will view this path as
"C:\cygwin\usr"). It is 100% cygwin specific. OR one
has to construct paths on
cygwin using 'native' all the time (or no_check) as
path checker,
because even windows_name doesn't work :/
Consider the following code:
#include <iostream>
#include <boost/filesystem/path.hpp>
#include <boost/filesystem/operations.hpp>
int main()
{
try {
boost::filesystem::path p("C:\cygwin\usr",
&boost::filesystem::windows_name);
} catch(std::exception const& error) {
std::cerr << "Exception: " << error.what() <<
std::endl;
}
}
With the following result:
Exception: boost::filesystem::path: invalid name
"C:\cygwin\usr" in path: "C:\cygwin\usr"
Same thing with any other variation that starts with 'C:'.
I believe that this is a structural failure of
boost::filesystem,
revealing a major error in the design. A re-design
seems to be in order before it can be considered to be
usable in multi-platform applications.
The most important problem with the current design is
that a single type (namely fs::path) is being used for
effectively two different types: canonical paths and
native paths. A new design should provide a new type,
fs::native_path that cannot be mixed with the canonical
path representation. This native_path should have
builtin checks that are native and fs::path should only
check for portability (and allow relaxation of that
when lesser OS need to be supported).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1012135&group_id=7586
-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
_______________________________________________
Boost-bugs mailing list
Boost-bugs_at_[hidden]
https://lists.sourceforge.net/lists/listinfo/boost-bugs
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk