Make basic_path more generic?

[Beman Dawes]

in several places I need to have code which works both with char and wchar_t. Those are template functions. I also work with paths there so I wanted to actually write something like

template <typename CharType> void foo(const std::basic_string<CharType>& s) {

typedef fs::basic_path<std::basic_string<CharType> > path_type; ...

}

but it turned out that I can't do it because 1) basic_path has the second Traits template parameter mandatory and 2) this Traits parameter has actually different type for path and wpath:

struct path_traits; typedef basic_path< std::string, path_traits > path; ... struct BOOST_FILESYSTEM_DECL wpath_traits; typedef basic_path< std::wstring, wpath_traits > wpath;

Of course, I can easily workaround it with my own traits, but I wonder could it be in the first place like:

template<class String> class basic_path_traits;

template<class String, class Traits = basic_path_traits<String> > class basic_path;

with basic_path_traits being specialized for std::string and std::wstring and fs::path and fs::wpath being just

typedef basic_path< std::string > path; typedef basic_path< std::wstring > wpath;

?

Thanks.

-- Alexei Alexandrov

[Beman Dawes]

There are two perspectives to consider at this issue.

• As a very specific tweak to the current interface.

• As a further indication that there should be a single path type that can handle both wide and narrow types. Peter Dimov suggested that once, and I keep turning over in my mind how it could be accomplished. With C++0x supplying two new character types, the need becomes more pressing. I still don't want to invent a solution that applies only to filesystem paths; there is a general need for strings that can cope with multiple character types and encodings.

--Beman

[anonymous]

• As a further indication that there should be a single path type that can handle both wide and narrow types. Peter Dimov suggested that once, and I keep turning over in my mind how it could be accomplished. With C++0x supplying two new character types, the need becomes more pressing. I still don't want to invent a solution that applies only to filesystem paths; there is a general need for strings that can cope with multiple character types and encodings.

This is indeed a very big problem and needs to be addressed properly, quickly. It is for this reason that I can't use boost::filesystem and have had to revert to using QT's QFile and friends. Their QString has loads of support for encodings and QFile uses QString. I had hoped C++0x would take us a lot closer to better i18n support.

[dtrebbien@…]

Does anyone know what the status of this feature request is? Is anyone working on it? I have run into a situation where I need something like a basic_path_traits template in order to not have to copy a huge template definition just to create specializations for char and wchar_t.

Beman, I read your ​message in the Boost mailing list and I do not see why you are talking about character encodings. Granted, I have not looked into the code of Boost Filesystem and I am not familiar with its internal workings, but would you mind elaborating on the issue involved here?

[dtrebbien@…]

I developed a partial work-around for those who, like me, are only interested in a "basic_path_traits template" for (char, std::char_traits<char>) and (wchar_t, std::char_traits<wchar_t>):

namespace detail {

template <typename char_t_, class traits_ = std::char_traits<char_t_> >
struct boost_ticket_1936_workaround;

template <>
struct boost_ticket_1936_workaround<char>
{
        typedef boost::filesystem::path_traits boost_filesystem_path_traits;
};

template <>
struct boost_ticket_1936_workaround<wchar_t>
{
        typedef boost::filesystem::wpath_traits boost_filesystem_path_traits;
};

} // end `namespace detail`

Using this code, the generic path traits type is BOOST_DEDUCED_TYPENAME detail::boost_ticket_1936_workaround<char_t_, traits_>::boost_filesystem_path_traits

[Beman Dawes]

Boost.Filesystem Version 3, which will ship with Boost 1.44, address the issues raised by this ticket.

Thanks,

--Beman