Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Tuesday 29 of March 2011, Bjoern Michaelsen wrote:
Hi Lubos,

On Tue, 29 Mar 2011 15:11:44 +0200

Lubos Lunak <l.lunak@suse.cz> wrote:
 Why not? I generally just need a number and int fits that perfectly.
I really don't care how many bits it has as long as it works and
don't need to wonder if I should use sal_Int32, sal_UInt16, sal_Int64
or whatever.

For example you will create a lot of needless work for people who want
to get the code warning-free (which is a valid goal, see Caolans commits
for example) because of comparisons between different types
(signed/unsigned or different ranges).

 I don't think there's any warning for comparing differently sized types of 
the same signedness, as the smaller one is simply promoted to the larger one. 
And, because of the trouble caused by promotion rules when comparing signed 
vs unsigned, it's just not worth using unsigned for anything except bitwise 
operations. In fact insisting on the wide range of different types leads to 
more warnings, not the other way around - if everything that's simply a 
number is int, there are no warnings. I also doubt that using differently 
sized typed rigorously gains anything - types smaller than int are promoted 
to int in pretty much any operation, so presumably no warnings there, and as 
soon as there's an operation that involves two different types, it's probably 
just not worth the trouble.

Almost every numeric data you 
have in the codebase has been marshalled once, or will be (it was
either loaded, will be saved or is available though the API).

 How does API have to do anything with marshalling? Do you mean UNO with that? 
And what do you estimate is the ratio of code that does marshalling to the 
rest of the code?

sal_* Types are typedefs and can be changed as a whole or be defined
different on different (or new) platforms. That eases a lot of trouble.

 If it's used for marshalling, then it can't be changed. Or, if it can, then 
it doesn't matter if the data would be simply marshalled as int.

 It's more typing and it's foreign to anybody not used to the
codebase. Sure, that may sound like silly reasons

Indeed. And its wrong too. As "unsigned int" is for example a lot longer
to type than sal_*.

 Typing is not really the biggest problem of unsigned int, see above.

Also its really not something only LO does: 

http://www.gtk.org/api/2.6/glib/glib-Basic-Types.html
http://doc.qt.nokia.com/4.7-snapshot/datastreamformat.html

 The Qt page is about data marshalling. Normally Qt uses int wherever 
possible.

Also, you are not making it easier for the newcomers at all: If he gets
a sal_* type from one source and a creatively selected other type from
another source, you are making life hard for him. If he gets the same
types there is no trouble for him.

 Are you sure you're not arguing for my way here? The only way to get the same 
type is if the codebase normally used int. Now it's full of different types 
(sal_* ones and standard ones, all mixed).

That is not at all the case for numeric types (for example "long").
Someone writing code on *nix might easily store a sal_uInt64 in a long
on 64-Bit and create havoc on Windows in interesting and hard to
reproduce ways.

 I was talking about the case where the value is "just a number". If it needs 
an extended range for whatever reason then that's something different.

 And I'm also not arguing for converting everything right now this very 
moment. But I don't see why we should have an easy task that moves the 
situation in the wrong direction.

-- 
 Lubos Lunak
 l.lunak@suse.cz

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.