Home » Blog » 2016 » February » New papers: Iterator facade for ranges; adopt File System TS for C++17; unified call syntax wording

New papers: Iterator facade for ranges; adopt File System TS for C++17; unified call syntax wording

By Blog Staff | Feb 11, 2016 06:04 PM | Tags: None

Note: This is the last batch of individually- or small-group-posted papers this week. Tomorrow is the pre-Jacksonville paper mailing deadline, so we expect a bunch of papers to come in all at once, and instead of blogging about them individually, those will all advertised here next week as part of the mailing blog post.

 

New WG21 papers are available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

 

P0186R0: Iterator Facade Library Proposal for Ranges (Beman Dawes, Eric Niebler, Casey Carter)

Proposes a library component for easily creating conforming iterators. Based on existing practice. Depends only on the C++17 working paper plus Concepts TS and Ranges TS. Breaks no existing code or ABI's. Two open-source implementations including test suites available. Proposed wording provided.

 

P0218R0: Adopt the File System TS for C++17 (Beman Dawes)

Technical work on N4100, File System Technical Specification, ISO/IEC TS 18822:2015, was completed in July 2014, and published by ISO in July 2015. There are three shipping implementations and one soon-to-ship implementation. Two of the shipping implementations have been have been in use for several years. This document proposes adopting the File System Technical Specification, with corrections, for C++17. The alternative to this proposal is to start work on version two of the File System TS. Doing nothing is not an alternative.

 

P0251R0: Unified Call Syntax Wording (Bjarne Stroustrup, Herb Sutter)

This is the proposed wording for a unified call syntax based on the idea that f(x,y) can invoke a member function, x.f(y), if there are no f(x,y). The inverse transformation, from x.f(y) to f(x,y) is not proposed. [...] As agreed in EWG at the Kona meeting, the intent of the wording is: For f(x,y), see if f(x,y) is valid and if so do that call; otherwise try x.f(y).

 

Add a Comment

Comments are closed.

Comments (2)

0 0

petke said on Feb 11, 2016 06:47 PM:

About filesystem TS. At the point when we get co-routines into the language, we probably want to use any filesystem API in an async manner. Could this library be cleanly extended to also support awaitable interfaces, or would a separate async filesystem API be needed at that point?
0 0

cpptmp said on Feb 14, 2016 07:19 AM:

I am somewhat concerned about some aspects of the filesystem TS,
hopefully these are baseless worries.

An example case:

"Directory foo has 500 subdirectories, 500 regular files and 100 symlinks.
Print the size of those 500 regular files on Linux.
How many (l)stat calls does this involve?"

On modern Linux with typical filesystems the answer should be 500.

The C answer on Linux can use d_type from readdir to get the type and
then (l)stat the 500 regular files for the size. (With #ifdefs and
slow path for the cases where d_type is not provided).

The C++ solution first stats the directory once, then lstats 1100
times to get the type and then does 500 times stat for the file
size for a total of 1601 (boost and gcc implementations).



#include <iostream>

#include <experimental/filesystem>



using namespace std::experimental::filesystem;



int main(void) {

  long long sum = 0;

  for (auto &de : directory_iterator("/tmp/foo")) {

    auto p = de.path();

    auto ty = de.symlink_status().type();

    if (ty == file_type::regular) {

      sum += file_size(p);

    }

  }

  std::cout << sum << std::endl;

}


I am not sure that the current filesystem TS API allows this to be solved
in an efficient fashion.

Currently type information on iteration is typically provided on Linux, *BSD,
OSX and Windows (which provides also other info). It is not provided on e.g.
Solaris. However, taking advantage of the info on those platforms where it
is provided would make sense.

This is mainly caused by the API providing file_type only via file_status.
File_status requires the permissions in addition to the type, and thus
ends up needing a superfluous (l)stat call.

When trying to cache things with the current API some of the existing
implementations (boost, elib) seem to mutate mutable data members
in const functions in unsynchronized fashion.

Adding e.g. a hard_link_count in addition to the file_size makes the number
of system calls rise even more.