because there is no law how to code. i code how i want and i explicitly mentioned, that there is a option. pointers are just dangerous if you don't know what your are doing.
[...]
why next time not try to answer his question instead of trying to force others program your way?
Do you see the difference between "to force" and "to advise"? Lots of people using pointers are not aware of what they're doing, that's why pointers are dangerous
for them (of course not in general, pointers are a powerful feature). If a problem can be solved in two ways - the easy, obvious one, and the other one, which is much more error-prone and where you have to be very attentive - which one would you recommend to people who aren't used to core language features?
It's exactly because of people like you why I say "do rather not use raw pointers in STL containers". You are obviously part of the people not knowing what they're doing as you lack important knowledge about C++. Do you know, why malloc() may be faster in your example? Because it just allocates memory, no construction is performed. Do you also know what "no construction" means if you are dealing with Non-POD-objects? That's very hazardous. In your example, you generate massive undefined behaviour. Sorry, but with a knowledge like that, I do not consider you to be able to judge about what is dangerous or not.
Some of your code I referred to:
struct myAnimFrame {
sf::Sprite sprite;
float frameTime;
};
frame=(myAnimFrame *)malloc(sizeof myAnimFrame *);
frame->frameTime=0.1f; // time how long frame is displayed
frame->sprite=sf::Sprite(frame1Image);
this->frames->push_back(frame);
but thats another library, i dont want to use tons of libraries for things that are already there
I explicitely said "even for these cases", which means they're rather exceptional. And of course everyone can choose, if he does all work manually and makes debugging and maintenance to his hell. At least, I don't, and I think it's not wrong to share this approach with others. By the way, many C++ programmers use Boost.
read my lips: this is untested code, just to show the principle
And it's a very bad way to show the principle. Better use pseudocode, if you aren't sure about the programming language. Your example is only misleading beginners.
i am not interested in pure oo, as it makes everything slow, and 25 years of experience in game industry are my proof (ok, i admit, the first commercial game was in pure assembler), but i always encourage people to program the way *they* like instead of forcing them my pattern.
Don't take it personally, but I don't believe the 25 years at all. You are making trivial errors and have those views of programming. Statements like "OO is slower" are pure propaganda, that must already be nonsense because OOP is a technique, not a concrete realization. Even if the 25 years should be right - what would that prove? That you're an expert and know what really matters? Besides, no one spoke of pure OOP, that's not possible in C++ anyway.