FWIW, using const vs. non-const accessors can have a dramatic
difference on programs. One of our customers claimed that carefully
avoiding the non-const functions increased the performance of their
application by an order of magnitude.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

The path class in the proposed filesystem library
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html) has
several member functions that return the string
associated with the path:

        const string_type string() const;
        const string_type file_string() const;
        const string_type directory_string() const;
        const external_string_type external_file_string() const;
        const external_string_type external_directory_string() const;

Why do all these functions return const objects?  They all return rvalues,
so there can be no worries about any of them granting access to the path's
internal structure. If the rvalue-reference proposal passes, returning const
values could prevent the use of move semantics on the return value.

Joe Gottman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

In article <B8W4g.13243$P65.5662@southeast.rr.com>,
 jgottman@carolina.rr.com ("Joe Gottman") wrote:

> The path class in the proposed filesystem library
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html) has
> several member functions that return the string
> associated with the path:
>
>         const string_type string() const;
>         const string_type file_string() const;
>         const string_type directory_string() const;
>         const external_string_type external_file_string() const;
>         const external_string_type external_directory_string() const;
>
> Why do all these functions return const objects?  They all return rvalues,
> so there can be no worries about any of them granting access to the path's
> internal structure. If the rvalue-reference proposal passes, returning const
> values could prevent the use of move semantics on the return value.

Beman brought this issue to me a year ago (or has it been two or three
now?).  I've been unable to give him a satisfactory answer so far, but I
think I have one now.

First the cause of the const string_type return:

On some file systems basic_path will maintain an internal string which
has the exact same format as that needed by string() (for example).  On
these systems the ideal signature and implementation would be:

A:

const string_type& string() const {return path_;}

On other systems the internal format will be different, and the ideal
signature and implementation would look more like:

B:

string_type string() const {return portable_format(path_);}

(disclaimer, I am still ignorant of some file-system details).

Platform A may be able to avoid all copies in some common scenarios such
as:

file.open(my_path.string());

open would presumably take a const string& and thus the return on
platform A would simply pass the path around by const ref the whole way
down.

However on platform B, a copy of the internal data has to be made
anyway.  And as you noted, it is best not to return by const string as
it would inhibit moving from that rvalue.

There may be some clients that do something like:

string file = my_path.string().append(".cpp");

This code would work on Platform B, but fail at compile time on Platform
A.  Thus the rationale for the return by const rvalue:  To have such
code behave identically (fail at compile time) on both platforms.

This issue is "Issue 1" in the paper.

My opinion on the best way to handle this, formed only just now in
response to your post, is that we should allow Platform B to return by
non-const rvalue, and allow Platform A to return by const ref.

Justification:  If it is implementation defined, then both platforms A &
B will have optimal performance for what is by far the most common use
cases.  Relatively uncommon code will work on B, but fail at compile
time on A (the append(".cpp") example).  However, the failure is at
compile time, not run time, and is easily fixed on A:

string file = string(my_path.string()).append(".cpp");

Furthermore, if clients really care, in C++0X they will be able to learn
the return type of string() at compile time and optimize their code
accordingly using is_reference<decltype(my_path.string())>::value.

In general I don't like implementation defined behavior.  But I hate it
worse when 99% of the use cases suffer performance for the benefit of 1%
of the use cases.  And in this case those 1% can even have their code
automatically adjust to the implementation defined behavior with no run
time or code size hit (using compile time dispatching).

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Howard Hinnant wrote:
> In article <B8W4g.13243$P65.5662@southeast.rr.com>,
>  jgottman@carolina.rr.com ("Joe Gottman") wrote:

> > The path class in the proposed filesystem library
> > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1975.html)
> > has several member functions that return the string
> > associated with the path:

> >         const string_type string() const;
> >         const string_type file_string() const;
> >         const string_type directory_string() const;
> >         const external_string_type external_file_string() const;
> >         const external_string_type external_directory_string() const;

> > Why do all these functions return const objects?  They all
> > return rvalues, so there can be no worries about any of them
> > granting access to the path's internal structure. If the
> > rvalue-reference proposal passes, returning const values
> > could prevent the use of move semantics on the return value.

> Beman brought this issue to me a year ago (or has it been two
> or three now?).  I've been unable to give him a satisfactory
> answer so far, but I think I have one now.

I don't know if it was a consideration in the original design,
but in a reference counted implementation of std::string,
operations like [] and begin() can be significantly faster on
const objects.  (FWIW, I can't imagine it making a difference in
real programs.)

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]