SFML Game Development by Example - 4th SFML book

[zsbzsb]

(... and uses modern C++)

This is why I asked about the source code, because if you look at the cover (I know you shouldn't judge a book by it's cover) you will see the following line of code blended into the background...

sf::Texture* texture = new sf::Texture();

[OrderNexus]

(... and uses modern C++)

This is why I asked about the source code, because if you look at the cover (I know you shouldn't judge a book by it's cover) you will see the following line of code blended into the background...

sf::Texture* texture = new sf::Texture();

With the exception of smart pointers, all of the code used in this book is modern. I have made a decision quite early on during the writing stage to stick to raw pointers for educational purposes. If you're picking this book up, it's fair to assume that you have at least a decent knowledge of C++, hence you probably have used smart pointers or at the very least have heard of them. At least to me, it seemed that learning how to properly dispose of dynamically allocated objects was more beneficial than using a feature that does it for you, especially since so many newbies have problems with memory leaks. Instead of using smart pointers and swiping the problem under a rug, I attempted to tackle it in a way that seemed the most fit. I guess we'll just have to wait and see how it works out in the long run though.

[Jesper Juhl]

With the exception of smart pointers, all of the code used in this book is modern. I have made a decision quite early on during the writing stage to stick to raw pointers for educational purposes. If you're picking this book up, it's fair to assume that you have at least a decent knowledge of C++, hence you probably have used smart pointers or at the very least have heard of them. At least to me, it seemed that learning how to properly dispose of dynamically allocated objects was more beneficial than using a feature that does it for you, especially since so many newbies have problems with memory leaks. Instead of using smart pointers and swiping the problem under a rug, I attempted to tackle it in a way that seemed the most fit. I guess we'll just have to wait and see how it works out in the long run though.

I would argue that the correct way to manage dynamically allocated memory is with RAII and smart pointers. Teaching manual memory management seems misguided to me - especially since it's incredibly hard to get right and code te ds to get pretty ugly with lots of try-catch blocks if you really want to handle all possible leaks and smart pointers solve the whole problem quite elegantly.
I'd have written that line from the book cover as

auto texture = std::make_unique<sf::Texture>();

[OrderNexus]

With the exception of smart pointers, all of the code used in this book is modern. I have made a decision quite early on during the writing stage to stick to raw pointers for educational purposes. If you're picking this book up, it's fair to assume that you have at least a decent knowledge of C++, hence you probably have used smart pointers or at the very least have heard of them. At least to me, it seemed that learning how to properly dispose of dynamically allocated objects was more beneficial than using a feature that does it for you, especially since so many newbies have problems with memory leaks. Instead of using smart pointers and swiping the problem under a rug, I attempted to tackle it in a way that seemed the most fit. I guess we'll just have to wait and see how it works out in the long run though.

I would argue that the correct way to manage dynamically allocated memory is with RAII and smart pointers. Teaching manual memory management seems misguided to me - especially since it's incredibly hard to get right and code te ds to get pretty ugly with lots of try-catch blocks if you really want to handle all possible leaks and smart pointers solve the whole problem quite elegantly.
I'd have written that line from the book cover as

auto texture = std::make_unique<sf::Texture>();

I agree, it is a more elegant solution. Not sure I'm on the same page about teaching manual memory management being misguided though. It's a useful skill to have, hence a subject worthy of being taught, as you yourself said that it's hard to get right. At the end of the day, it came down to a simple choice: Do I want a more elegant yet educationally lacking solution for non-production code, or one that is unjustly so looked down upon by many C++ modernists, but with a purpose of teaching something. I chose the latter, obviously, with relatively little negatives to show for it. Performance wasn't impacted in any way, which should always be your number one concern. Whether it was the right choice for the book remains to be seen, so I guess we'll just have to let time do its thing. Besides, we shouldn't be judging usage of raw pointers too harshly. The source code of SFML itself has lines like this in it:

m_impl = new priv::ThreadImpl(this);
...
delete m_impl;
m_impl = NULL;

On a side note, it wouldn't really be a huge task for the reader to utilize smart pointers while reading this book, should they choose to do so. The rest of the code is fairly modern and uses C++11 standards. With that said, I think we should wrap up this discussion, since it's really just a matter of opinion at this point.

[Laurent]

Besides, we shouldn't be judging usage of raw pointers too harshly. The source code of SFML itself has lines like this in it

Sadly, C++98 has no proper alternative to offer, so this code is necessary. But all this crap will vanish once SFML (3) finally moves to C++11.

[hobby]

I'd have written that line from the book cover as

auto texture = std::make_unique<sf::Texture>();

I prefer to not start a religious war here, but since the previous discussion was on smart vs. raw pointers I'll allow myself to question the merit of auto in this example.
Usually over the course of a project, a line of code is read many more times than it is written. Surely if several people are involved in the project. Do you find auto better than the explicit std::unique_ptr<sf::Texture>?

[eXpl0it3r]

Usually over the course of a project, a line of code is read many more times than it is written. Surely if several people are involved in the project. Do you find auto better than the explicit std::unique_ptr<sf::Texture>?

It's quite redundant since the factory (i.e. std::make_unique<sf::Texture>) already indicates the type. Having it written out twice, could be interpreted as a bit of noise.

[Elias Daler]

Usually over the course of a project, a line of code is read many more times than it is written. Surely if several people are involved in the project. Do you find auto better than the explicit std::unique_ptr<sf::Texture>?

It's quite redundant since the factory (i.e. std::make_unique<sf::Texture>) already indicates the type. Having it written out twice, could be interpreted as a bit of noise.

Agreed. And auto makes it easier to refactor this code later. Suppose you want to change unique_ptr to shared_ptr. You'd need to change it twice (instead of only once) if you've written it this way:
std::unique_ptr<sf::Texture> texture = std::make_unique<sf::Texture>();

Or, suppose, you decide to change sf::Texture to another class, again, you'd have to change the same thing twice, which is a bad sign because some day you'll forget to change it somewhere which will lead (at best) to compilation errors and to hard-to-spot bugs at worst.

[hobby]

It's quite redundant since the factory (i.e. std::make_unique<sf::Texture>) already indicates the type. Having it written out twice, could be interpreted as a bit of noise.

I tend to agree, in my view this example lies on the border (I had to start the discussion with something...) Have you seen auto i = 0; used in practice (I have)?

Agreed. And auto makes it easier to refactor this code later. Suppose you want to change unique_ptr to shared_ptr. You'd need to change it twice (instead of only once) if you've written it this way:
std::unique_ptr<sf::Texture> texture = std::make_unique<sf::Texture>();

Or, suppose, you decide to change sf::Texture to another class, again, you'd have to change the same thing twice, which is a bad sign because some day you'll forget to change it somewhere which will lead (at best) to compilation errors and to hard-to-spot bugs at worst.

Dynamically-typed languages excel at minimizing the code changes required for refactoring, and SFML has bindings in some of them. Still, I wouldn't go on to claim that they enable easier refactoring - the number of keystrokes is not the only metrics. I think the same holds for considering to which extent to adopt auto in C++.

[eXpl0it3r]

I tend to agree, in my view this example lies on the border (I had to start the discussion with something...) Have you seen auto i = 0; used in practice (I have)?

I don't think, this is the place for a general discussion about auto, especially if it's just for discussion's sake.
If you're really unsure, which to me doesn't seem like it, then you can read all the existing discussions on the web by various people some better known than others.

Let's not further hijack this thread.

[Sanction]

I just got the book today, skimmed threw it at work. Lots of content and some advance game programming techniques looking forward to going back and following it threw and studding the content.

I didn't like how the code was smushed together, being still a novice I like to see the pattern more clearly, but like I said there was lots of content and you can easily open up an example and see it more clearly.

I really liked how it walked you threw the system / pattern and keep adding to it. So like for the ECS you get a more clear understanding of how the ESC works and later shows you adding more components and systems adding even more.

Overall I'm really excited and I'll be sure to post more

[OrderNexus]

I just got the book today, skimmed threw it at work. Lots of content and some advance game programming techniques looking forward to going back and following it threw and studding the content.

I didn't like how the code was smushed together, being still a novice I like to see the pattern more clearly, but like I said there was lots of content and you can easily open up an example and see it more clearly.

I really liked how it walked you threw the system / pattern and keep adding to it. So like for the ECS you get a more clear understanding of how the ESC works and later shows you adding more components and systems adding even more.

Overall I'm really excited and I'll be sure to post more

Thanks for showing your support! I hope you enjoy the rest of the book.

[eXpl0it3r]

Who could say no to a 5 bucks eBook.

I very quickly went a bit over the source code and it looks quite good, even though I don't agree with some of the design decisions.

[OrderNexus]

Who could say no to a 5 bucks eBook.

I very quickly went a bit over the source code and it looks quite good, even though I don't agree with some of the design decisions.

I'm glad to hear it's acceptable. Regarding the design choices, I can already imagine what those would be for the most part. I hope that doesn't ruin the book for you, and you find something useful in it still. Thanks so much for purchasing it!

[AncientGrief]

Hey,

I bought your book a couple of days ago. Working on the Snake chapter atm. Nice to read I think using pointers etc. is okay ... I for myself try to avoid them and will exchange your pointers to smart pointers...but I have a question:

The Game class in chapter 2 -> Building the game class has the method

Window* GetWindow();
 

why using a pointer instead of this?:

const Window& GetWindow() const;
//EDIT: the const may be ignored, later on it will be stupid to make it return a const Window...
 

Btw.: I try to be more const correct than the book, but I don't see it as a flaw, since the code is much more readable while learning Nice work so far! I also prefer it over the first book so far!

Edit2:
What does the prefix l_ for function parameters stand for?! LValue?!

Snake::Render(sf::RenderWindow& l_window)