[wx-dev] int vs ssize_t and u-inst vs size_t
Stefan.Neis at t-online.de
Stefan.Neis at t-online.de
Wed Aug 2 02:54:57 PDT 2006
Hi,
> For example: ..\..\include\wx/richtext/richtextbuffer.h declares a lot
> of input/output values and member variables as long or int. For example
> GetParagraphCount() returns a signed int where I'd say that it should
> return size_t.
>
> While continuing with my observations I concluded that even a lot of
> very basic and 'old' classes would need a change.
> wxString::Find() returns int, while find() returns size_t. There are
> some other functions similar to Find() which should return size_t instead.
I'm not exactly sure about richtextbuffer, but I guess the same argument
that we give for strings is valid also there: 2^32 (or even 2^31) really
should be enough for the length of a single string, there isn't much point
in using an even larger datatype here. If you want to manage several GB of
memory, there are more efficient methods than using a conventional string
no matter what exactly you want to do ...
> And when I finally saw that wxSize uses 'int' for 'x' and 'y', I decided
> to write this eMail and ask the wx-developers to please use ssize_t and
> size_t more often (and where appropriate) as they're IMHO more - well
> more portable maybe? Changing wxSize to use ssize_t would be ideal, but
> I guess the risk to break existing code on not so common compilers may
> be too big, so I don't dare to ask.
Similarly here, these types are often feed to native routines which most
often require int (or even short, e.g. for win16, since very few monitors
have more than 32000 pixels in any direction), so switching to a larger
datatype here is likely to result in more problems rather than fewer.
Regards,
Stefan
More information about the wx-dev
mailing list