Hi there,
On Tue, 2010-10-05 at 09:47 +0100, Caolán McNamara wrote:
I don't like adding another << >> SvStream operator for bool. If there
are places which would break on converting BOOL to bool because they're
getting streamed to disk via SvStreams, then I think I'd prefer to see
those specific BOOLs converted to sal_uInt8.
Fair enough; so an explicit cast in the code calling the operator:
rStrm << static_cast<sal_uInt8>(aBool) << ...;
sort of thing ?
I see we also have a << >> SvStream operators for "long" which is
another disaster seeing as a long is either 32bits of 64bits in size
depending on platform.
Weelll ... the operator in fact only streams 4 bytes regardless of
architecture ...
Anything streaming a long to disk is probably
broken and depending on a long being 32bit, or is hopefully only being
used for some temporary scratch format which could be replaced by
something platform-independent.
I guess; OTOH - do we really want to get into some monster LONG ->
sal_Int32 replacement scheme just now ? :-) I'd rather get hackers
re-focused on the higher-win tasks further up the stack really.
Here's another to-do for someone. Remove the long << >> SvStream
operators and find what's using them and lets consider if we can remove
them too as they are a ticking timebomb.
Added it to the wiki page[1] anyhow :-)
HTH,
Michael.
[1] - http://www.freedesktop.org/wiki/Software/LibreOffice/EasyHacks
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.