New naming convention

[Cornstalks]

I compiled with

Code: [Select]

-Wall -Wextra -Wshadow -pendantic -Wno-long-long
with

Code: [Select]

clang
gcc
mingw32-gcc
 and fixed all that was found.

Just out of curiosity, which versions did you use?  Specifically, will SFML 2 be targeting C++03 or C++11?  I see issue 129 is about adding conditional C++11 support, but I can't tell if that means adding support conditionally (i.e. it doesn't exist yet) or removing it (i.e. it does exist now).  I was getting issues when compiling with -pedantic on g++4.2 because long long isn't a C++03 type, so I just removed -pedantic.  I see Config.hpp still has long long so I'm assuming C++11...

[Laurent]

I was getting issues when compiling with -pedantic on g++4.2 because long long isn't a C++03 type, so I just removed -pedantic. I see Config.hpp still has long long so I'm assuming C++11...

Code: [Select]

-Wno-long-long


SFML is currently C++03, and will have conditional support for C++11.

[Cornstalks]

I was getting issues when compiling with -pedantic on g++4.2 because long long isn't a C++03 type, so I just removed -pedantic. I see Config.hpp still has long long so I'm assuming C++11...

Code: [Select]

-Wno-long-long


SFML is currently C++03, and will have conditional support for C++11.

*facepalm*  Thanks, overlooked that one.  And thanks for the info.  And SFML.

[VPellen]

Downloaded the latest source today, and my compiler spat out about a few dozen no-such-member errors.

A pain in the ass to rename, but this is a good thing, right?

[Haze]

Laurent, have you made up your mind about high-level getter/setter methods for sf::Transformable, such as getX, setX, getY, setY, getSize ?
IMHO, those methods would be really convenient, user code is sometimes too complex for really simple position manipulation.

[Laurent]

getX and getY are not necessary (getPosition().x is as easy to write).
getSize cannot be in sf::Transformable, the local size is not known there.
setX and setY could be useful, but if I do it for every function of every class that takes a sf::Vector2, the public API will explode.

[Nexus]

Haze, this concerns not only position, but also scale (x, y), origin (x, y) and color (r, g, b, a). Maybe even rect (left, top, width, height) in other places.

I suggest to write global function templates on user side, this way you can cover large parts of the library with very few code.

[Haze]

That's the solution I'm currently using.
I was just assuming this may be part of the API, and I was pointing at position because I think this attribute is more used than the other ones you listed.
It would also avoid a couple of function calls, but I don't want to sound captious

[Yours3lf]

you should definitely decide it now

Hum? It's decided, and it's changed now. So what do you mean?

I only meant that a naming convention should be chosen and sticked to, so that if now everybody updates to the new convention it will be consistent later on (and compatible with apps written with older versions of SMFL). But if you decided then it's cool

[julen26]

I just wanted to say that I hate the new naming convention and will probably switch to a different library because of this

it looks like ass and makes no sense

You had your time to judge before releasing the new naming convention. The new naming doesn't affect when coding, only changes some characters. Which are your arguments for making that decision?

Anyway I think that it's your post wich doesn't make sense.