[reSIProcate] New #define landmine; RESIP_USE_STL_STREAMS

[Byron Campen]

	API/ABI mismatch will occur if you use installed headers and fail to  
define RESIP_USE_STL_STREAMS in the same way it was when the libraries  
were built. A header stating that DataStream has a base-class of  
std::iostream and a library where DataStream has a base of  
ResipFastOStream (or vice-versa) are not going to be compatible.

	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  
> streams
> addition.  Let me know if that is not the case.
>
> Personally, I would like to see the STL interface removed.  Trying to
> support 2 interfaces seems, well, redundant.  The encoding mechanism  
> doesn't
> require the generic nature of the STL streams.  Yes, the STL streams
> interface is well defined and has been used quite a bit for a lot of  
> general
> solutions, 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 at resiprocate.org
> [mailto:resiprocate-devel-bounces at resiprocate.org] On Behalf Of  
> Byron Campen
> Sent: 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 header
> files; 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  
> either
> write extra versions of the various and sundry operator<<, or perhaps
> convert them into template functions.
>
> Best regards,
> Byron Campen
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2482 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20081008/86fd3ba7/attachment.bin>