Why sf::Drawable::draw is a complately const function?

[china92]

I've searched this forum for similar topics, but I haven't found any.

virtual void draw(sf::RenderTarget& target, sf::RenderStates states) const;

I'd like to know why? I'm asking because right now I have a problem, because of this little "const", here is a preview of this issue:
Wave.h

class Wave :
        public sf::Drawable
{
private:
        std::list<Enemy*> enemies;
[...]
public:
        virtual void draw(sf::RenderTarget& target, sf::RenderStates states) const;
}

In Wave.cpp I would like to draw every enemy in wave.

void Wave::draw(sf::RenderTarget& target, sf::RenderStates states) const
{
        std::list<Enemy*>::iterator temp = enemies.begin();

        for(temp; temp != currentEnemy; temp++)
        {
                target.draw(**temp);
        }
}

But there is an error:

Error   1   error C2440: 'initializing' : cannot convert from 'std::_List_const_iterator<_Mylist>' to 'std::_List_iterator<_Mylist>'

Looks like one does not simply iterate the const list. (there is a problem with initializing iterator "std::list<Enemy*>::iterator temp = enemies.begin();", without const it works, but it cannot initiate abstract class)

If you have any advices how to workaround this problem, please write them.

PS
Is the AnimatedSprite included in standard version of SFML, or I have to copy it by myself?

PS2
Sorry for my lame English.

PS8
If the section on forum is wrong, please move this topic (I wasn't sure where to put it).

[kloffy]

Try:

std::list<Enemy*>::const_iterator temp = enemies.begin();

[china92]

C'mon it was seriously that simple? I'm sorry for my stupidity and lack of knowledge, I just assumed that const_iterator is not incrementable and I haven't even tried that.

Thank you for your really fast answer, everything is working now, this topic can be removed.

[eXpl0it3r]

Besides if you don't use the temp variable later on, you can initialize the iterator directly in the for loop. And if you're using C++11 compatible compilers, you can also use the auto keyword and might even want to consider a range based for loop.

[china92]

I still have a lot to learn, thank you.

[Nexus]

virtual void draw(sf::RenderTarget& target, sf::RenderStates states) const;

I'd like to know why?

The reason for this const is always the same: The method does not modify the logical state of the object.

Assuming that the Wave class owns the enemies, is there a certain reason why you use std::list<Enemy*> and not std::list<Enemy>? If there is none, use the latter. It is much simpler and safer to handle, since you don't have to care about memory management.

Is the AnimatedSprite included in standard version of SFML, or I have to copy it by myself?

It is not part of SFML, same for the other codes on the Wiki. By the way, you could also have a look at the Animation module in Thor -- it is slightly more complex, but allows also other animations than different texture rects, such as color gradients. It depends on what you need, I think to begin AnimatedSprite is a good choice.

[china92]

Yes, you are right of course, but I thought that I cannot iterate via the list, when the function is completely const (that was my mistake, and that's why I asked this question).

I've already implemented the destructor which take care about memory, so it is not a problem for me right now, but I'll take your idea into consideration.

Thank you for your advice, right now my game has some static Sprites, but I'm thinking about some animations. When I decide to implement this feature I'll look at Thor (but I think AnimatedSprite from wiki should be enough for my needs).

[Nexus]

I've already implemented the destructor which take care about memory, so it is not a problem for me right now

I think you are wrong, unless you have also implemented the copy constructor and assignment operator

There are so many things that can go wrong with manual memory management, you should really avoid it whereever possible. Even more if automatic memory management does the job equally well. You could take a look at the RAII idiom.

[Grimshaw]

Great point Nexus. That reminds me I have some issues to take care of with exactly that kind of memory management.