Subject: Re: [boost] [filesystem] windows/posix inconsistencies.
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-02-01 10:21:11
on Tue Jan 31 2012, Ion GaztaÃ±aga <igaztanaga-AT-gmail.com> wrote:
> El 31/01/2012 14:47, Stephan T. Lavavej escribiÃ³:
>> [Thorsten Ottosen]
>>> However, consider
>>> const std::string& ext = iter->path().extension().string();
>>> This is fine on windows, as a temporary is returned, and its lifetime is
>>> extended; on linux, extension() returns a temp path object, from where
>>> we get a reference. I'm not a 100% sure, but I think the C++ standard
>>> does not guarantee that this path object be kept alive.
>> * The Standard requires the temporary path to be destroyed at the semicolon.
>> * Replace string with wstring, and this becomes problematic on Windows.
>> * Additionally, returning const values like const string/const wstring inhibits move semantics.
> I know I repeat myself too many times, but I can't resist! One of the
> issues I find with move semantics is that sometimes we assume
> returning by value is free. Returning by value objects with dynamic
> allocation avoids reusing those dynamic resources (specially in
> loops). I think returning by value has a nice syntax and properties
> (you don't need a default-constructed object when you need to create a
> new object instead of assigning it), but IMHO is premature
> Although returning vectors by value might be a good idea for
> factories, and such things, it's always more efficient to pass a
> reference to a vector, and clear() + fill or assign, or even better,
> reusing already constructed values (which can be vectors of
Are there any numbers to back that claim up? It seems obvious at first
glance, of course, but sometimes reality surprises us.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk