2008/5/29 Vladimir Prus
Christian Holmquist wrote:
Do you have hard numbers about how much the user of iterator_facade affects compilation speed? Honest question -- I also find it unfortunate that compilation time is not a priority for Boost.
I haven't modified fs::path to not use iterator_facade and measured the difference, no. It could be other sources that affects the compilation time as well, I'll try to put together a test in the weekend. Still fs::path depends on complicated libraries compared to std::basic_string, when they're both merely a wrapper around a char type with a traits class. If std::basic_string only had the 'path concatenation' operator/ (which I found very useful), would there be any use for fs::path? when it comes to the member functions of fs::path, it seems like they're going down the road of std::basic_string: a group of member functions that suits some particular usecases, but in the end everyone must revert to free functions doing the real work. I'm now more into extracting the fs::path.append into a free function range append_path(range, range, path_traits) then I could manually overload operator/ for std::basic_string and get the nifty path / path. With a wrapper header like the one Emil Dotchevski suggested for file operations there'd be close to no penalty for filesystem dependent code. - Christian
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users