In the interests of science, I wrote a small "file finder" using Boost.Filesystem and a comparable version using POSIX functions (e.g. stat, readdir, etc).
Wow, that's a fast test implementation!
Looking at the profiling output from the "finder-fs" program, it appears a bulk of the time is spent in fs::basic_path::operator/=() which may bear out Ion's fears.
Even if the string manipulation was not the most heavy part of the test, I would like to point out two ideas: -> Even if the filesystem is slower than returning a temporary object, that doesn't mean that you shouldn't optimize it. Your program is not alone in the computer, so when your program is waiting for I/O (surely via DMA) other processes are taking CPU, but when you create a lot of temporary strings you are stressing the memory allocator (so you can have more fragmentation in a long live program) and degrading overall system performance. Maybe your program is not much slower, but the CPU consumption is much higher. -> The good old C++ principle: "Pass heavy objects always by reference" is a very good advice to avoid performance problems. You can pass strings by value, but you never do that. But in my opinion this advice is also valid for the inverse sense: "Obtain heavy values always by reference". You never know how your code will be used, how many times your functions will be called. If you want your library to be useful even in situations that you don't predict, it's always helpful to use references. The difference is that passing parameters by reference does not change syntax whereas obtaining by values by reference is uglier. Caleb, I don't know if this is too much work but, can we know how many calls to "new" this application makes or even better, how many std::strings it constructs? Thanks and great job! Ion