|
Boost Users : |
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2008-05-30 01:42:04
2008/5/29 Vladimir Prus <vladimir_at_[hidden]>:
> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net