< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
The efficiency gains on Windows might be enough to get many to throw caution to the wind, but the gains on linux are not as large. Outright deprecating the std::ostream-based code is probably not going to sit well with many who use resip on linux, unix, or OS X yet.
DataStream would use std::iostream always. FastDataStream would use ResipFastOStream always. The various encode() and operator<< functions could either have two versions (one for std::ostream and one for ResipFastOStream), or could be made template functions (ie; work with everything that has the right ostream-like functions implemented), or could be based on EncodeStream like now, except we define EncodeStream in a header file that is not installed, and only include the header in implementation files.
Best regards, Byron Campen
Hi Byron,What mismatches have you seen? On what platforms? Note that by default resip should compile exactly the same as it did before the fast streamsaddition. Let me know if that is not the case. Personally, I would like to see the STL interface removed. Trying tosupport 2 interfaces seems, well, redundant. The encoding mechanism doesn'trequire the generic nature of the STL streams. Yes, the STL streamsinterface is well defined and has been used quite a bit for a lot of generalsolutions, but the performance gain with the alternative interface is significant.Of course removing an interface that has been used for so long is a major change. The general consensus may be that people feel more comfortable having the option of either. If these new classes were created, how would for example, resip::DataStream be used to determine which interface to use?Thanks, -justin -----Original Message----- From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Byron CampenSent: Wednesday, October 08, 2008 7:19 PM To: resiprocate-devel Subject: [reSIProcate] New #define landmine; RESIP_USE_STL_STREAMS I'm seeing a new #define being used to substantively change headerfiles; RESIP_USE_STL_STREAMS. This will cause nasty API/ABI mismatch issues when working with installed headers. We really need to restrict this kind of thing to implementation files wherever possible. So, I think we need to define new classes, FastDataStream, FastoDataStream, FastiDataStream, and FastDataBuffer to work alongside their non-fast counterparts, and eitherwrite extra versions of the various and sundry operator<<, or perhaps convert them into template functions. Best regards, Byron Campen
Attachment:
smime.p7s
Description: S/MIME cryptographic signature