Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: New naming convention  (Read 90162 times)

0 Members and 1 Guest are viewing this topic.

Cornstalks

  • Full Member
  • ***
  • Posts: 180
    • View Profile
    • My Website
New naming convention
« Reply #165 on: March 17, 2012, 09:11:03 pm »
Quote from: "Laurent"
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
New naming convention
« Reply #166 on: March 17, 2012, 09:30:12 pm »
Quote
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.
Laurent Gomila - SFML developer

Cornstalks

  • Full Member
  • ***
  • Posts: 180
    • View Profile
    • My Website
New naming convention
« Reply #167 on: March 17, 2012, 10:41:50 pm »
Quote from: "Laurent"
Quote
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

  • Newbie
  • *
  • Posts: 14
    • View Profile
New naming convention
« Reply #168 on: March 21, 2012, 01:15:58 am »
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

  • Full Member
  • ***
  • Posts: 201
    • View Profile
    • Github Profile
Re: New naming convention
« Reply #169 on: March 25, 2012, 01:06:03 pm »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: New naming convention
« Reply #170 on: March 25, 2012, 01:55:58 pm »
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.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: New naming convention
« Reply #171 on: March 25, 2012, 02:57:48 pm »
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Haze

  • Full Member
  • ***
  • Posts: 201
    • View Profile
    • Github Profile
Re: New naming convention
« Reply #172 on: March 25, 2012, 04:23:43 pm »
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

  • Newbie
  • *
  • Posts: 43
    • View Profile
Re: New naming convention
« Reply #173 on: March 25, 2012, 09:13:38 pm »
Quote
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

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
    • http://julen26.blogspot.com
Re: New naming convention
« Reply #174 on: April 18, 2012, 12:49:56 am »
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.

 

anything