#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>
#include <SFML/Window.hpp>
#include <iostream>
class Snake{
int length = 1;
float s_size = 10.f;
int x = 0;
int y = 0;
sf::CircleShape snek_head(s_size);
public:
void draw1(sf::RenderWindow& win){
win.draw(snek_head);
}
};
snake.cpp:12:31: error: 's_size' is not a type
12 | sf::CircleShape snek_head(s_size);
| ^~~~~~
snake.cpp: In member function 'void Snake::draw1(sf::RenderWindow&)':
snake.cpp:16:17: error: no matching function for call to 'sf::RenderWindow::draw(<unresolved overloaded function type>)'
16 | win.draw(snek_head);
| ~~~~~~~~^~~~~~~~~~~
im getting this error, what is the reason for this?
I'll leave the explanation to someone who knows the standard wording better than me... I've recently had the same issue using VS2022 (as latest standard) for some code that compiled OK before (can't say when).
The rule, in layman terms, is: "If it can be a function declaration, it is a function declaration."
sf::CircleShape snek_head(s_size); can be interpreted syntactically as a function called snek_head that returns an sf::CircleShape and takes in an object of type s_size.
Using the C++11 {} syntax makes it impossible for it to be a function declaration, so the only other option left is a variable declaration/initialization.
There are potential pitfalls when changing from "=" initialization to uniform initialization. The biggest is whinging about "narrowing conversion" errors. int i { 3.6f}; for example. With int i = 3.6f; an implicit conversion from float to int happens, the code compiles without a hitch. With uniform initialization you have to explicitly state there is a conversion happening by casting. int i { static_cast < int>(3.6f) };
I see the whinging as a nice, neat compile-time tool for type conversions that might otherwise go unnoticed and potentially introduce run-time bugs.
I use {} initialization nearly exclusively, so I guess one could conjecture I am someone who likes it.
@Grando. Yes, but that rule goes back to the beginning. As s_size isn't a type this format of variable definition and initialisation as far as I know used to compile OK. If that rule was used, then that line would compile OK but with potential later errors re variable not defined. I think something has changed (in the standard/compiler ??) that no longer accepts this format which previously compiled OK. The issue is that line is now causing a compile error which it didn't in the past.
There's certainly many current examples on the web (github) etc. I just downloaded some code from github which in it's documentation used () when defining a class variable with a constructor argument. It didn't compile until I changed () to {}.
Show examples, please? I think later standards have been more lenient about what is allowed to be initialized inside the class definition, but that would be the opposite of what you're describing.
I don't see where in that link it's being used in a class scope.
Edit: But you bring up a different valid point, which is regardless of function declaration syntax [since in this case it's an int literal, so what I said earlier doesn't matter], you can't initialize variables like that in classes. You'd have to do Object obj = Object(1024); if not for uniform initialization. Now with regards to why that is... I don't know, it's just the way it be. But this isn't new, as far as I know.