Andrey Semashev wrote:

Edward Diener wrote:

...

Jorge Lodos Vigil wrote:

...

Hi The Traits classes for basic_path provided in the filesystem library (path_traits and wpath_traits) are good enough to be used as default values for basic_path in most cases. However, since they are independent structs, they can not be used to instantiate a basic_path with a single String template parameter. I would like to write:

typedef basic_string<char> string_t; typedef fs::basic_path<string_t, fs::basic_path_traits<string_t> > path_t; I would like to second this request. I also noticed that one can not easily instantiate a basic_path based completely on a string type, because of the traits class. If it is at all possible, the traits class should be a template class based on the string type, with supplied specializations for std::string and std::wstring.

I second that, too. Maybe, a Trac ticket would be a appropriate.

I made a trac ticket, #2439.

Beman Dawes wrote:

On Mon, Oct 27, 2008 at 1:18 PM, Andrey Semashev <andrey.semashev@gmail.com>wrote:

...

Edward Diener wrote:

...

Jorge Lodos Vigil wrote:

...

Hi The Traits classes for basic_path provided in the filesystem library (path_traits and wpath_traits) are good enough to be used as default values for basic_path in most cases. However, since they are independent structs, they can not be used to instantiate a basic_path with a single String template parameter. I would like to write:

typedef basic_string<char> string_t; typedef fs::basic_path<string_t, fs::basic_path_traits<string_t> > path_t; I would like to second this request. I also noticed that one can not easily instantiate a basic_path based completely on a string type, because of the traits class. If it is at all possible, the traits class should be a template class based on the string type, with supplied specializations for std::string and std::wstring. I second that, too. Maybe, a Trac ticket would be a appropriate.

I'm pretty close to posting a Filesystem Version 3 prototype for feedback. Perhaps as soon as this weekend.

It uses a single class path, with templated member functions. Much simpler and more straightforward to use. So the question will become, are these member templates flexible enough to achieve what you are trying to accomplish? It wouldn't be surprising if some further work were needed, and I'll be very interested in getting your comments on the prototype.

The issue for me was just ease of instantiation of a basic_path based solely on a string type ( which is actually a character type ). One can not currently instantiate a basic_path with: boost::filesystem::basic_path<std::basic_string<char>, boost::filesystem::basic_trait<std::basic_string<char> > > myPath; where one just specifies the character type. Why would one want to do that ? For two reasons: 1) In a VC++ program which may be multibyte or Unicode depending on a compiler option, we would have: boost::filesystem::basic_path<std::basic_string<_TCHAR>, boost::filesystem::basic_trait<std::basic_string<_TCHAR> > > myPath; 2) A template class or template function taking a character type parameter would just pass that type in to filesystem to instantiate the correct type path. So I do not know whether your version 3 solves makes that easier or not, but hopefully it does.

Hi Beman Dawes wrote:

Here is an example; this code does compile and run correctly under V3:

#include <boost/filesystem/path.hpp> #include <boost/filesystem/operations.hpp> #include <string> #include <cassert> #include <windows.h> #include <winnt.h>

namespace fs = boost::filesystem;

typedef std::basic_string<TCHAR> tstring;

void func( const fs::path & p ) { assert( fs::exists( p ) ); }

int main() { // get a path that is known to exist fs::path cp = fs::current_path();

// demo: get tstring from the path tstring cp_as_tstring = cp.string<tstring>();

// demo: pass tstring to filesystem function taking path assert( fs::exists( cp_as_tstring ) );

// demo: pass tstring to user function taking path func( cp_as_tstring );

return 0; }

It is nice to have a single path class, thank you. I'm curious about the internal path representation and the conversion to std::string or std::wstring. If I understood the logic, the string type and path traits are now function template parameters. Is that correct? Could you please estimate when filesystem v3 will be included in a boost release? Thanks again. Best regards Jorge

Beman Dawes wrote:

On Wed, Oct 29, 2008 at 11:33 PM, Edward Diener <eldiener@tropicsoft.com>wrote:

...

Beman Dawes wrote: ... The issue for me was just ease of instantiation of a basic_path based solely on a string type ( which is actually a character type ). One can not currently instantiate a basic_path with:

boost::filesystem::basic_path<std::basic_string<char>, boost::filesystem::basic_trait<std::basic_string<char> > > myPath;

where one just specifies the character type.

Why would one want to do that ? For two reasons:

1) In a VC++ program which may be multibyte or Unicode depending on a compiler option, we would have:

boost::filesystem::basic_path<std::basic_string<_TCHAR>, boost::filesystem::basic_trait<std::basic_string<_TCHAR> > > myPath;

2) A template class or template function taking a character type parameter would just pass that type in to filesystem to instantiate the correct type path.

So I do not know whether your version 3 solves makes that easier or not, but hopefully it does.

Here is an example; this code does compile and run correctly under V3:

#include <boost/filesystem/path.hpp> #include <boost/filesystem/operations.hpp> #include <string> #include <cassert> #include <windows.h> #include <winnt.h>

namespace fs = boost::filesystem;

typedef std::basic_string<TCHAR> tstring;

void func( const fs::path & p ) { assert( fs::exists( p ) ); }

int main() { // get a path that is known to exist fs::path cp = fs::current_path();

// demo: get tstring from the path tstring cp_as_tstring = cp.string<tstring>();

// demo: pass tstring to filesystem function taking path assert( fs::exists( cp_as_tstring ) );

// demo: pass tstring to user function taking path func( cp_as_tstring );

return 0; }

It looks like you are saying that a boost::filesystem::path can be created from any string type and that one can retrieve the path as any string type. I can not think of any immediate objection to using boost::filesystem::path in this way, and it does simplify the use of it with different string types. This certainly seems like a worthwhile way to upgrade the library.