's_size' is not a type

  #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);
    void draw1(sf::RenderWindow& win){

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?
Last edited on
Try L14 {s_size} instead of (s_size).
Are you sure that s_size is a SFML type ?
Last edited on
@seeplus thank you!
could you explain why that works?
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).
Last edited on
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.
Last edited on
thank you so much for all your help! :)
The {} form to initialize a variable is known as "uniform initialization." Added in C++11.

Some people hate it, some love it.

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.
From https://github.com/cameron314/readerwriterqueue

BlockingReaderWriterCircularBuffer<int> q(1024);  // pass initial capacity 

Doesn't compile with VS2022 as latest standard. It generates a compiler error:

error C2059: syntax error: 'constant'

It needs to be:

BlockingReaderWriterCircularBuffer<int> q{1024};  // pass initial capacity 

Last edited on
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.
Last edited on
I'll leave the explanation to someone who knows the standard wording better than me...

As far as I know using {} over () is just a syntax requirement. Probably to avoid the confusion with member function declaration.
It's to disambiguate initialization from a function call.
now it is happening with snek_head.setFillColor(sf::Color::Green) too. how do i fix it?
Last edited on
Topic archived. No new replies allowed.