Counts as ints and size_t

[ABX]

Hi!

I'm looking for the feedback how user projects could be affected or what problems do you expect from changing counts in wxWidgets 2.8 api (and during 2.7 development time) from 'int' to 'size_t'. The idea is to make values which are unsigned in nature also unsigned in type. The question is whether such change does not add extra unneeded and unexpected work for users who maintain thousands lines of sources. Past measurement says that signed/unsigned warnings (while appears) are not big problem however there is known new warning about conversion between types on 64-bit platforms. Do you expect any other problems? Do you see benefits?

Thanks in advance for the feedback!

ABX

[upCASE]

I voted 'yes'. I don't think there'd be big problems with that. Especialy if it's about counter values, it makes perfect sense to have them unsigned.

[priyank_bolia]

The warnings can be suppressed, but the standards cannot.
It gives a lot of warnings too for me, when wxWidgets try to convert size_t to int, without casting, I guess I have posted a bug too. So its better that what is size_t should be that only and not int or other.

[NinjaNL]

I voted yes too.

I agree with upCASE and the idea behind the move, that values which are unsigned in nature also unsigned in type.

[Jorg]

I voted yes, but have a side note. If a count value is also used as a status value, I find the construction (size_t)-1 to return an error less elegant. I do not know if wxWidgets also uses this where max(size_t) - 1 is always reserved for an error (must be somewhere in the wxDir part) .. ok I found it:

wxDir::Traverse

size_t Traverse(wxDirTraverser& sink, const wxString& filespec = wxEmptyString, int flags = wxDIR_DEFAULT)

Enumerate all files and directories under the given directory recursively calling the element of the provided wxDirTraverser object for each of them.

More precisely, the function will really recurse into subdirectories if flags contains wxDIR_DIRS flag. It will ignore the files (but still possibly recurse into subdirectories) if wxDIR_FILES flag is given.

For each found directory, sink.OnDir() is called and sink.OnFile() is called for every file. Depending on the return value, the enumeration may continue or stop.

The function returns the total number of files found or (size_t)-1 on error.

However I do not know how that could be made more elegant, it is less intuitive then passing a < 0 value to represent an error.

- Jorgen

[Frank]

I voted yes too, because I'm using size_t all over the place and think it is the only right type for a counting variable.

For the -1 case Jorg described. I have no problem with it. Even the C++ Standardlib is doing it (eg std::basic_string<>::npos), so I'm fine with it.

[phlox81]

I voted for yes. I think it should be used, cause its almost a standard in a lot of modern C++ librarys.
afaik boost uses it too.

Still i find it unpractically, to test about std::string::npos instead of -1.

phlox

[Jorg]

So do we make a wx::npos too? Would be logical to do that instead of (size_t)-1 at least the typing is easier.

- Jorgen

[utelle]

So do we make a wx::npos too? Would be logical to do that instead of (size_t)-1 at least the typing is easier.

If size_t will be used as the type for sizes and counters then it is definitely necessary to have something like wx::npos.

Let me illustrate this with a simple example:

Code: Select all

std::string str = "abc";
if ( str.find( ".." ) != (unsigned int)-1 ) 
{ 
  return 0; 
}

Astonishingly the statement return 0 will be executed on a 64 bit machine, although the string does not contain "..".

std::string::find() returns the constant std::string::npos if the argument is not found within the string. You may say, but this is the largest unsigned integer, which is the same as -1 on all two's complement architectures, where is the problem?

The length of a std::string is of type size_type, which is usually the same as size_t. On a 64 bit machine this is equivalent to unsigned long, while unsigned int is a 32 bit value. The latter will be extended to 64 bit for the comparison, respecting the sign. Since it is unsigned after the cast, the comparison will use the value 0x00000000FFFFFFFF, but std::string::npos equals 0xFFFFFFFFFFFFFFFF.

On a 32 bit machine you will never realise the difference, but on a 64 bit machine you will.

Using the constant std::string::npos eliminates the problem.

You may argue, I could have used (size_t)-1 instead of (unsigned int)-1 to eliminate the problem. True, but then the code would break some day in the future when there will be a 128 bit architecture.

Regards,

Ulrich

[metalogic]

I voted yes and I also "vote" for a wx::npos.

[AkiraDev]

size_t is the most sensible way to handle counting. I also think a wx::npos constant should be introduced to handle errors accordingly to the change and further improve compatibility with the STL.

[phlox81]

hm, wx::npos.
Interesting, is there gonna be a namespace wx ?
Would make sense imho.

[Ryan Norton]

So do we make a wx::npos too? Would be logical to do that instead of (size_t)-1 at least the typing is easier.

- Jorgen

You mean wxString::npos?

[Jorg]

Well could be. But I see npos more as a general index offset, and string::npos was only an example. So I think wx::npos would be better.

- Jorgen