Re: [reSIProcate] New #define landmine; RESIP_USE_STL_STREAMS
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@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] 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