Boost C++ Libraries: Ticket #1936: Make basic_path more generic?

status changed

Beman Dawes — Tue, 20 May 2008 13:12:42 GMT

status new → assigned

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

component changed

Beman Dawes — Tue, 20 May 2008 13:18:26 GMT

component None → filesystem

status changed

Beman Dawes — Wed, 25 Jun 2008 21:34:48 GMT

status assigned → new

anonymous — Sun, 02 Nov 2008 00:01:45 GMT

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.

severity, milestone changed; cc set

dtrebbien@… — Sat, 30 Jan 2010 04:05:05 GMT

cc dtrebbien@… added
severity Not Applicable → Problem
milestone Boost 1.36.0 → To Be Determined

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@… — Sat, 30 Jan 2010 17:56:23 GMT

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

status changed; resolution set

Beman Dawes — Fri, 11 Jun 2010 15:57:02 GMT

status new → closed
resolution → fixed

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

Thanks,

--Beman