boost.png (6897 bytes) Filesystem Version 3
Design
Home    Tutorial    Reference    FAQ    Releases    Portability    V4    V3 Intro    V3 Design    Deprecated    Bug Reports   
Contents
Introduction
Problem
Solution
Details
Other changes
Acknowledgements

Caution: This page documents thinking early in the V3 development process, and is intended to serve historical purposes. It is not updated to reflect the current state of the library.

Introduction

During the review of Boost.Filesystem.V2 (Internationalization), Peter Dimov suggested that the basic_path class template was unwieldy, and that a single path type that accommodated multiple character types and encodings would be more flexible. Although I wasn't willing to stop development at that time to explore how this idea might be implemented, or to break from the pattern for Internationalization used the C++ standard library, I've often thought about Peter's suggestion. With the advent of C++0x char16_t and char32_t character types, the basic_path class template approach becomes even more unwieldy, so it is time to revisit the problem in light of Peter's suggestion.

Problem

With Filesystem.V2, a path argument to a user defined function that is to accommodate multiple character types and encodings must be written as a template. Do-the-right-thing overloads or template metaprogramming must be employed to allow arguments to be written as string literals. Here's what it looks like:

template<class Path>
void foo( const Path & p );
inline void foo( const path & p )
{
  return foo<path>( p );
}
inline void foo( const wpath & p )
{
  return foo<wpath>( p );
}

That's really ugly for such a simple need, and there would be a combinatorial explosion if the function took multiple Path arguments and each could be either narrow or wide. It gets even worse if the C++0x char16_t and char32_t types are to be supported.

Solution

Overview:

The signatures presented in Problem collapse to simply:

void foo( const path & p );

That's a signification reduction in code complexity. Specification becomes simpler, too. I believe it will be far easier to teach, and result in much more flexible user code.

Other benefits:

Possible problems:

Details

Encoding Conversions

Host system

char string path arguments

wide string path arguments

Systems with char as the native API path character type (i.e. POSIX-like systems) No conversion. Conversion occurs, performed by the current path locale's codecvt facet.
Systems with wchar_t as the native API path character type (i.e. Windows-like systems). Conversion occurs, performed by the current path locale's codecvt facet. No conversion.

When a class path function argument type matches the operating system's API argument type for paths, no conversion is performed rather than conversion to a specified encoding such as one of the Unicode encodings. This avoids unintended consequences, etc.

Other changes

Uniform hybrid error handling: The hybrid error handling idiom has been consistently applied to all applicable functions.

Acknowledgements

Peter Dimov suggested the idea of a single path class that could cope with multiple character types and encodings. Walter Landry contributed both the design and implementation of the copy_any, copy_directory, copy_symlink, and read_symlink functions.


© Copyright Beman Dawes, 2008

Use, modification, and distribution are subject to the Boost Software License, Version 1.0. See www.boost.org/LICENSE_1_0.txt