Hi, I finished anothher round of modification in wrap_stringstream makeing it more generic (actually it now template basic_wrap_stringstream and specializations). Is there still interest in putting it uner boost/utility and do we need a fast review for it? If yes I will prepare doc page. Gennadiy.
"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote:
I finished anothher round of modification in wrap_stringstream ....
Is it possible to see it somewhere? /Pavel
http://tinyurl.com/2ebnh Gennadiy
On Sun, 2004-05-23 at 12:30, Gennadiy Rozental wrote:
Hi,
I finished anothher round of modification in wrap_stringstream makeing it more generic (actually it now template basic_wrap_stringstream and specializations). Is there still interest in putting it uner boost/utility and do we need a fast review for it? If yes I will prepare doc page.
among the libraries currently in boost, stringstreams are used by : -test_tools, using wrap_stringstream - math/quaternion.hpp and octonions, and date_time. It seems those use stringstreams but could use wrap_stringstream just as well - spirit which does its own wrapping of str/string stream (at first glance it looks as if it could use wrap_stringstream instead) -lexical_cast, which handles internally either strstreams or stringstreams. I think it could also use wrap_stringstream. - boost::format. stringstreams are in fact a performance bottleneck for format, and I wrote an alternative stringstream class supporting most platforms, to overcome std::stringstream limitations (making it possible to reuse stringbufs, and the likes). BTW I'm also asking for opinions on the status to give to this class, see <1082886685.5949.42.camel@marvin.localdomain>) It seems to me most libraries that need stringstream features only use the basic interface (operator<< and then str() ) and could just as well use wrap_stringstream. About the code : I'm wondering, why have the str() function return a const-reference to string rather than a value, like stringstream does ? -- Samuel
On Sun, 2004-05-23 at 19:03, Gennadiy Rozental wrote:
About the code : I'm wondering, why have the str() function return a const-reference to string rather than a value, like stringstream does ?
Is there a reason to return it by value?
I think both possibilities don't make any difference in performance (as long as the return-by-value is optimized and does not lead to an extra string copy). And the semantics difference is not really substential. Personnally the only concrete reason to return by value I could think of is it's simpler with value : the stream would not need to store m_str (which is redundant with the buffer inside the stringstream / strstream). I don't know stringstream's designers motivation, but they faced the same choice. That's why I thought you found reasons against stringstream's by-value str() return. If there isn't any, I'd go for the by-value str(), to keep the user comfortable with any habit she might have. (like, directly modifying the result of the str(). probably not too common, but who knows..) In fact, it seems that if the user wants to modify the string obtained from str(), the return-by-value design is the best (in case of RVO), whereas the design with the m_str stored string implies an unnecessary copy. -- Samuel
About the code : I'm wondering, why have the str() function return a const-reference to string rather than a value, like stringstream does ?
Is there a reason to return it by value?
I think both possibilities don't make any difference in performance (as long as the return-by-value is optimized and does not lead to an extra string copy). And the semantics difference is not really substential.
Personnally the only concrete reason to return by value I could think of is it's simpler with value : the stream would not need to store m_str (which is redundant with the buffer inside the stringstream / strstream).
I don't know stringstream's designers motivation, but they faced the same choice. That's why I thought you found reasons against stringstream's by-value str() return. If there isn't any, I'd go for the by-value str(), to keep the user comfortable with any habit she might have. (like, directly modifying the result of the str(). probably not too common, but who knows..) In fact, it seems that if the user wants to modify the string obtained from str(), the return-by-value design is the best (in case of RVO), whereas the design with the m_str stored string implies an unnecessary copy.
I incline to agree. I consider changing it. Gennadiy.
participants (3)
-
Gennadiy Rozental -
Pavel Vozenilek -
Samuel Krempp