wxArray size_t or int, which one is it?

remenic · Post by **remenic** » Thu Dec 07, 2006 8:27 pm

When trying to fix a few of the signed/unsigned mismatches my compiler keeps reminding me about, I noticed a few oddities about the wxArray class.

Now, maybe these oddities were decision based, maybe not. If they are, then I hope someone can help me understand why these decisions were made.

As I understand, wxArray uses a size_t as index number. size_t is an unsigned integer (in this case), so it can store from 0 to 4,294,967,295. So when calling wxArray's GetCount() you ought to be comparing to another size_t.

But here's the strange thing. wxArray::Index(T &item) returns an INT. Theoretically from -2,147,483,648 to 2,147,483,647.

What happens when the item I'm looking for is item number 3,000,000,000 ?

So basically my question is: why does wxArray::Index(T &item) return an int, while wxArray::GetCount() returns a size_t?

Post by **DavidHart** » Thu Dec 07, 2006 8:34 pm

Hi,

Because wxArray::Index might return wxNOT_FOUND, which is -1.

Regards,

David

S.Volkenandt · Post by **S.Volkenandt** » Thu Dec 07, 2006 8:41 pm

Since I'm interested, too, this still doesn't work out for item no. 3000000 for example.

A solution could be defining the not_found-id as (size_t)-1 (or more conformant std::numeric_limits<size_t>::max()-1), which is the largest possible size_t. This would only render one possible index useless, not half the range...

Post by **DavidHart** » Thu Dec 07, 2006 9:12 pm

While I agree in theory I suspect that, in practice, the number of people who have actually needed a wxArray of 3,000,000,000 elements will also equal -1

metalogic · Post by **metalogic** » Sun Dec 10, 2006 4:45 am

S.Volkenandt wrote:A solution could be defining the not_found-id as (size_t)-1 (or more conformant std::numeric_limits<size_t>::max()-1), which is the largest possible size_t. This would only render one possible index useless, not half the range...

I agree with this assessment and also with the proposed solution. I would recommend submitting a patch.

Belgabor · Post by **Belgabor** » Sun Dec 10, 2006 6:46 am

metalogic wrote:
S.Volkenandt wrote:A solution could be defining the not_found-id as (size_t)-1 (or more conformant std::numeric_limits<size_t>::max()-1), which is the largest possible size_t. This would only render one possible index useless, not half the range...
I agree with this assessment and also with the proposed solution. I would recommend submitting a patch.

I don't think this is such a good idea. Lots of people come from Windows programming where unselected/not found = -1. I guess this will break lots of code as probably people often check for >=0 and not for !=wxNOT_FOUND.

jgeorgal · Post by **jgeorgal** » Sun Dec 10, 2006 12:09 pm

Belgabor wrote: I don't think this is such a good idea. Lots of people come from Windows programming where unselected/not found = -1. I guess this will break lots of code as probably people often check for >=0 and not for !=wxNOT_FOUND.

... and besides, wx will use exclusively STL in the future in which there are no such "problems", wouldn't it ?

S.Volkenandt · Post by **S.Volkenandt** » Sun Dec 10, 2006 10:51 pm

jgeorgal wrote:... and besides, wx will use exclusively STL in the future in which there are no such "problems", wouldn't it ?

Agreed, as long as dereferencing iterators of wxArray doesn't evaluate to void* (at least I've experienced that with 2.7, but I will verify it before filing any reports).

Are there any official (meaning online-readable) specs about what wx will use in future (i.e. 3.0)? Maybe even parts of std::tr1?