SFML should use only types of defined size

[deadalnix]

SFML uses a lot of types like int. Thoses types has different size on different architecture.

This leads to difficulties to have consistent results on different hardware. Plus, this leads to difficulties to interface SFML with languages other than C or C++, that can have different type systems.

If the type depend explicitely on the architecture, the usage of typedef like size_t should be the usage.

What do you think ?

[gsaurus]

I think the usage of int, unsigned int, etc are used because they are the most efficient regarding the architecture (so it's better for the F of SFML).
It can hardly affect behavior in different systems, whatever the size of int is, it's unlikely that the ints used by SFML reach values high enough to make any significant difference.

[Laurent]

Fixed-size types shouldn only be used where appropriate (most likely when serializing to binary data across platforms). It makes no sense to use them everywhere.

This leads to difficulties to have consistent results on different hardware.

Which difficulties? On which hardware?

Plus, this leads to difficulties to interface SFML with languages other than C or C++, that can have different type systems.

Which languages? So far, SFML has been ported to many languages without any problem.

[deadalnix]

This leads to difficulties to have consistent results on different hardware.

Which difficulties? On which hardware?

Well nothing more than 32 -> 64 bits arch can sometime lead to funcky linking error in klingon (native language of the linker). And people rusually don't have both architectures ready to test.

Plus, this leads to difficulties to interface SFML with languages other than C or C++, that can have different type systems.

Which languages? So far, SFML has been ported to many languages without any problem.

Actually any language that have a different type system than C/C++ will experience issues with that. It doesn't means this is impossible (actually, it has been done sevral time) but it is error prone.

I'm currently working on the D port and experiencing issue with that (D has fixed size type system). A java port will have even more problems with that if it's done one day.

gsaurus > I didn't mesure that, so this is speculation, but I don't thnink working on a 32 bit value is slower than on a 64bit one on recent intel's or AMD's CPU.

The point is : 64bit values doesn't make any sense in many places where int are used. Consider Videomode. Do we really expect that the width or height of the screen will be more than 4 bilions pixels ?

The same goes for sampleRate or ChannelsCount in SFML-audio classes. Do we really expect someone have a sound to play with more than 4 billions channels ?

Using fixed size types here would make SFML easier to handle cross plateforms and cross languages.

[bastien]

Well nothing more than 32 -> 64 bits arch can sometime lead to funcky linking error in klingon (native language of the linker). And people rusually don't have both architectures ready to test.

gsaurus > I didn't mesure that, so this is speculation, but I don't thnink working on a 32 bit value is slower than on a 64bit one on recent intel's or AMD's CPU.

The “default” integer size on x86-64 is still 32 bits. The rationale is that most of the time you don't need 64 bits integers, and if I remember correctly, using 64 bits all the time would make the code larger because immediate values are coded on 64 bits (I wouldn't be surprised if it requires a prefix too). They could probably have made the 64 bits instructions smaller, but as I said you don't need them most of the time and the instruction set needs to be backwards-compatible, so staying with 32 bits integers by default is fine.
In the end, I believe that all the PC C compilers have 32 bits ints on 64 bits operating systems. The main difference is that Microsoft decided to stick with 32 bits long ints on Windows 64 (!): http://msdn.microsoft.com/en-us/library/3b2e7499.aspx.

Personally, I wrote a Python binding for SFML 2 and I don't remember having problems working with integers with non-specific size. You can assume that the C++ int is at least 32 bits wide, and in practice almost all the platforms that run SFML probably have 32 bits ints, although you shouldn't rely on it.

[Laurent]

Well nothing more than 32 -> 64 bits arch can sometime lead to funcky linking error in klingon (native language of the linker). And people rusually don't have both architectures ready to test.

You'll get linker errors if you mix 32 and 64 bits libraries anyway, using fixed-size types won't make it magically work.
If you don't mix architectures, I don't see what kind of problems you would get.

Actually any language that have a different type system than C/C++ will experience issues with that. It doesn't means this is impossible (actually, it has been done sevral time) but it is error prone.

Almost all languages are designed to work with C easily (because C has a well-defined ABI), and they can handle primitive types very well.

A java port will have even more problems with that if it's done one day.

It's already done, and there was no problem with types as far as I know.

The point is : 64bit values doesn't make any sense in many places where int are used. Consider Videomode. Do we really expect that the width or height of the screen will be more than 4 bilions pixels ?

It doesn't matter, what's important is to use the native types of the language you're working with. Or maybe you mean that C and C++ are badly designed languages, and that nobody should ever use their primitive types directly?

Sorry but unless you have more relevant arguments, or concrete use cases that demonstrate an actual problem, I think that this discussion is useless.

[deadalnix]

You'll get linker errors if you mix 32 and 64 bits libraries anyway, using fixed-size types won't make it magically work.
If you don't mix architectures, I don't see what kind of problems you would get.

That is not what I meant. Just consider the cas ewhere a size_t is passed to a function using int paramater. This will work on 32 bits. This will fail badly on 64 bits. And, if thoses are different mabguage, fail at link time with explainations in klingon.

Consider java port, this is, well, a port, and not using SFML code.

Actually, yes using primitive types in C/C++ ends up being a mess when you link to other languages. I will not say that they shouldn't be used at all, but probably not exposed.

[Laurent]

Well, SFML was ported to a lot of different languages, without any problem so far. So to be honest, it will be hard to convince me.

[deadalnix]

Ok, so I'll stop trying

[deadalnix]

http://schneide.wordpress.com/2011/11/08/inconsistent-usage-of-type-definitions-kills-portability-in-cc/

[Laurent]

http://schneide.wordpress.com/2011/11/08/inconsistent-usage-of-type-definitions-kills-portability-in-cc/

This blog article (who's the author by the way?) doesn't go deep enough into the problem, there's no concrete use case. He says they got crashes, but where? why? what was the specific problem? with which type? on which platform?

SFML has already been compiled on many platforms (32/64 bits, Windows/Linux/OS X, VC++/GCC) and many languages (C++, C, D, Ruby, Python, .Net) without any problem. I know that I'm just repeating myself, but I hope you understand that I need slightly better arguments or examples than "it's bad blah blah blah, don't do it".

[Tank]

"it's bad blah blah blah, don't do it".

[deadalnix]

Well so just don't do SFML at all. SDL works fine.

Binding are possible (for sure, I'm working on that currently) but the typesystem quirks from C leaks into other language by consequence.

Just like you don't have to do OOP and all that stuff. SDL is working just fine without it.

[Laurent]

You still haven't explained why native types would be a problem, or at least what benefits fixed-size types would bring.

Sorry, but this discussion is as useless as it was two weeks ago. "Blah blah blah" again.

[deadalnix]

Fixed size type has a size you can rely on. That is just the point of fixed sized type.

So you now are sure that the type you use at one side will always match the type you'll find to the other side.

Note that C object files doesn't bring with them information about type, so you end up with really nasty bugs when the type size mismatch.

Currently, this is a problem for long, mostly, because the long size is really inconsistent across plateforms.

What is the problem of non fixed size type ? Well, they have non fixed size. You can rely on this size. You know thing will not explode in an unexpected way on some plateform.

Many header of SFML are already using types like sf::Uint32 and similars ones. So I guess you already see a point to have known sized types.

This isn't blablabla, all recent languages have known sized types. Call me crazy, but you already did that in several parts of SFML. And I can't see any good reason for most use of long in the public API.

Like, for exemple, the style of a RenderWindow. This can be 64 bits long, but still, those extra 32bits are non exploitables (I would make SFML incompatible for 32 bits or require the use of fixed size type for 32 bits SFML). The same goes for window. The same goes for Text.

The same goes for any usage of non known sized type in the API actually.

The int everywhere as not a problem as long as SFML isn't ported on other plateforms. I did work on plateform where int wasn't 32bits and I can assure you that this can become quite a mess quickly. You don't immagine how much code rely on the fact that int is 32bits (but actually isn't always).

Just try to link SFML with another language. Every missized variable will compile just fine. And then only god knows what happen at runtime because the calling convention is screwed. You don't get any error. You simply segfault or get plein wrong results, sometime you even get correct results that turns wrong with some criteria on input values. And you have actually no clue if your code will work on any plateforms because you cannot be sure of the size of thoses types. Long is especially inconsistent (it isn't 64bits on all plateforms).