Godot-proposals: `int PoolVector<T>::size() const` should return `unsigned int`

Created on 6 Oct 2020  路  5Comments  路  Source: godotengine/godot-proposals

Describe the project you are working on:
Creating CPP Module for a Machine Learning Module

Describe the problem or limitation you are having in your project:
I face compilation warning(s) because of comparing it with unsigned int value

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
There will be no more warning :)

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
By changing the return argument of the interface

If this enhancement will not be used often, can it be worked around with a few lines of script?:
No

Is there a reason why this should be core and not an add-on in the asset library?:
All the size values should be unsigned int for better logical comparison

core

Most helpful comment

If this enhancement will not be used often, can it be worked around with a few lines of script?: No

Come on, it can xD you can cast it.

Is there a reason why this should be core and not an add-on in the asset library?: All the size values should be unsigned int for better logical comparison

If this is the actual request then that should be done inside Godot because all containers there use int, not even size_t.

All 5 comments

If this enhancement will not be used often, can it be worked around with a few lines of script?: No

Come on, it can xD you can cast it.

Is there a reason why this should be core and not an add-on in the asset library?: All the size values should be unsigned int for better logical comparison

If this is the actual request then that should be done inside Godot because all containers there use int, not even size_t.

I face compilation warning(s) because of comparing it with unsigned int value

There will be no more warning :)

You can use various warning build options like werror=no and warnings=no while compiling Godot.

If that doesn't work, this proposal might as well be qualified as a bug report.

I dont think "muting all warning" is the solution for this problem.. any developer should keep them on not to miss any probable future problem..

Do you use GCC? I use unsigned ints in a custom Godot module and while MSVC never complained for years with me, when I started setting up a CI with GCC, it started warning about every single bit of mix between int and unsigned int, which prevents the CI from suceeding the compilation since warning as error is used. At first it sounds like "oh, thats a bad use anyway, the developer should fix it" but even though I'm doing my best, it's surprising how often this can happen and how annoying this can be when MSVC doesnt warn about it the same way GCC does:

  • Godot containers use int, which causes the warning when I use my own unsigned ints so I have to cast
  • The STL (which I sometimes use because it performs better) uses size_t, which causes the warning when I have to use it with ints that came from Godot so I have to cast
  • Vector3i, Vector2i and rects use ints, which is another source of warnings forcing them to be casted all the time too
  • Using size_t or uint64_t is currently ambiguous with some compiler when constructing a Variant from it
  • In some cases, subtracting two unsigneds appears to create a SIGNED long integer so here we are again
  • If you get an index off by one in negatives, you get a more obscure result number in the billions which may be confusing. Although it allows to write one less bound check in the negatives
  • The script API uses Variant and Variant uses int64_t so again you need to care about this when comparing this to unsigned

At least I start to understand why Godot prefers int generally in places where negatives would not be expected :p

Yes I use GCC, if you ask me these warnings just fork fine, they do their job :D, problem is warnings can not create issues themself :), some one has to create issue about them :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

IllusiveS picture IllusiveS  路  3Comments

PLyczkowski picture PLyczkowski  路  3Comments

davthedev picture davthedev  路  3Comments

WilliamTambellini picture WilliamTambellini  路  3Comments

wijat picture wijat  路  3Comments