std::size_t instead of unsigned int

[cob59]

Hi
Just a quick suggestion about the types used for indexing.

I'm compiling a VC++ projects in 64bits right now and I've noticed some sf::VertexArray methods use the 32bits unsigned int (i.e. unsigned long) index types, even though their underneath std::vector<Vertex> uses the 64bits unsigned long long types.

This leads to unnecessary casts and warnings.

So I think you should use std::size_t for unsigned indexes and std::ptrdiff_t for the signed ones.

NB: I didn't check, but sf::VertexArray probably isn't the only concerned class.

[Nexus]

Yes, there are indeed some places where unsigned int is used to refer to an array size or index. I found the following ones:

void          Shape::getPoint(unsigned int index) const
unsigned int  Shape::getPointCount() const
// ... and the derived classes' setters

              VertexArray::VertexArray(PrimitiveType type, unsigned int vertexCount)
void          VertexArray::resize(unsigned int vertexCount)
Vertex&       VertexArray::operator[] (unsigned int index)
const Vertex& VertexArray::operator[] (unsigned int index) const

void          RenderWindow::draw(const Vertex* vertices, unsigned int vertexCount,
                  PrimitiveType type, const RenderStates& states)

[Nexus]

I also found this, but I'm currently not sure with what unsigned int would need to be consistent. There are places where SFML does use std::size_t for indices and array sizes, e.g. loadFromMemory() or sf::String methods.

What do other developers think? I could open a branch in case we agree to change the above-mentioned places to std::size_t.

[minirop]

but I'm currently not sure with what unsigned int would need to be consistent.

it should be std::vector<>::size_type, which in turn is std::size_t.

[Nexus]

No, I meant the other thread, where Laurent stated unsigned int is probably used for consistency reasons.

In other words, I'm waiting for arguments to keep unsigned int in the above-mentioned places
Otherwise I'll start working on the branch soon.

[Laurent]

I'm ok for replacing them.

[Gambit]

I know this isnt exactly related to the topic but if I'm not mistaken, int as a type is frown upon due to its 32/64 bit size on their respective architectures. Is there any change that they could be changed to the proper std::u/int8/16/32/64 types?

[FRex]

No and no:

1. Int is very, very likely to be 4 bytes (and (signed) int is actually what SFML typedefs sf::Int32 to). The type that varies with the bitness of the CPU is long (except on VC++ where it's apparently always 4 bytes too).

2. SFML can't use this header's typedefs: http://www.cplusplus.com/reference/cstdint/ because it's from C++11 which SFML doesn't use (yet).

[Nexus]

cob59, you can check out the bugfix/size_t branch and see if the warnings disappear.

[cob59]

There's an oversight in one file:

void ConvexShape::setPoint(std::size_t index, const Vector2f& point)
// instead of
void ConvexShape::setPoint(unsigned int index, const Vector2f& point)
 

After fixing it, the SFML project compiles/installs himself correctly with MSVC12 x64, but produces some warnings.

Yet, the sf::VertexArray used in my project do not produce any warnings now.

[Nexus]

I amended the commit. What are the other warnings about? I'm aware of one in InputImpl.cpp about unused parameter, and one about taking the address of main in sfml-main, as well as long long warnings on g++ in -pedantic mode.

[cob59]

There were problems with:

• stb_image.h that uses int types as a difference result between 2 pointers (should be ptrdiff_t, but the whole thing is inside an extern "C", so I don't know...)
• IpAddress.cpp that uses inet_addr() that seems to be deprecated for MSVC12 (warning C4996: 'inet_addr': Use inet_pton() or InetPton() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings)
• RenderTarget.cpp(L280): vertexCount is a size_t but glDrawArrays needs a GLsizei (i.e. an int).