-
Hi!
I tried compile and run simply SFML application by MSVC and GCC and I have strange problem.
When I manually configured projects (Visual Studio 11 and CodeBlocks 12.11), app works. So, I wanted to add CMakeLists.txt to my current project and I got problem. When I generate makefiles/solution and compile app by GCC (static or dynamic linked) or Visual Studio dynamic linked, it works, but when I try generate Visual Studio 11 solution, compile it and run - I got this:
Debug: http://puu.sh/2r8eo
Release: http://puu.sh/2r8f8
I'm using win8 and SFML 9fac5d74dcef2e78b21c8500589ea9f8cf263fb3 (Jan 16, 2013). For finding SFML I'm using attached FindSFML.cmake:
# find SFML and add include path
set(SFML_STATIC_LIBRARIES TRUE)
find_package(SFML 2 COMPONENTS audio graphics window system REQUIRED)
include_directories(${SFML_INCLUDE_DIR})
# ...
# add the executable
add_executable(CM_Billiard ${CM_BILLIARD_SRC})
target_link_libraries(CM_Billiard ${SFML_LIBRARIES} ${BOX2D_LIBRARIES})
How to correct it?
Regards,
Mrowqa
-
Do you have global variables in your project?
Could you try a minimal code, to know whether it's your configuration/environment or your code which causes the problem?
-
I don't have global variables AFAIR, but I have many static (in class). Official repo: https://bitbucket.org/Mrowqa/cm-billiard (https://bitbucket.org/Mrowqa/cm-billiard) - any of these modules haven't been using, but I compile all code. Actual CM_Billiard.cpp:
#include <iostream>
#include "CMBilliardConfig.h"
using namespace std;
int main2();
int main()
{
cout << "Source code in development\n"
"Actual version: " << CM_BILLIARD_VERSION_MAJOR << "." << CM_BILLIARD_VERSION_MINOR << "." << CM_BILLIARD_VERSION_EXTRA_INFO << "\n";
main2();
return 0;
}
#include <SFML/Graphics.hpp>
#include <Box2D/Box2D.h>
int main2()
{
b2World world(b2Vec2());
sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!");
sf::CircleShape shape(100.f);
shape.setFillColor(sf::Color::Green);
while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
}
window.clear();
window.draw(shape);
window.display();
}
return 0;
}
PS code on repositorium can't be compile by GCC. It works with MSVC (locally I corrected code, but not uploaded).
-
I don't have global variables AFAIR, but I have many static (in class).
Statics are initialized at global scope too. What SFML classes are involved?
And...
Could you try a minimal code, to know whether it's your configuration/environment or your code which causes the problem?
-
I know that I have static sf::RenderWindow - in global scope app can't create new object. I tested sf::Window, sf::RenderTexture, sf::Context, sf::Image and sf::Time too. Three first of them crashes app. That's probably sf::NonCopyable constructor's blame.
-
No that's because statics are global and thus don't have a well defined destruction order and a few other quirks. Just use a better code design, that doesn't require globals, especially not ones like sf::RenderWindow. ;)
-
That's probably sf::NonCopyable constructor's blame.
Nop, it's more complicated. It's because they are OpenGL resources.
Anyway: don't use globals!
-
Thanks! Someday maybe I'll learn OpenGL, but now it doesn't make sens for me - there's SFML :)
Just use a better code design, that doesn't require globals, especially not ones like sf::RenderWindow. ;)
I wanna singleton for sf::RenderWindow (I'll make static pointer). I'm not professional programmer and I'm still learning how to make good code design :)
Nop, it's more complicated. It's because they are OpenGL resources.
Anyway: don't use globals!
App compiled by GCC works, so... It's strange for me for the time being. MSVC...
-
Someday maybe I'll learn OpenGL, but now it doesn't make sens for me - there's SFML
App compiled by GCC works, so... It's strange for me for the time being. MSVC...
It has nothing to do with OpenGL. It's just about the initialization order of globals: it is not defined by the C++ standard, it's up to the compiler to decide. Therefore your own globals can be initialized before SFML globals with gcc, and the opposite with VC++.
The problem is that OpenGL classes in SFML (sf::RenderWindow, sf::Context, ...) need a special treatment that requires the use of a global variable in their constructor. So if you construct an instance of one of these classes at global scope, before SFML globals are initialized, SFML ends up using an uninitialized variable and it can crash. And this is exactly what happens.
-
I wanna singleton for sf::RenderWindow (I'll make static pointer). I'm not professional programmer and I'm still learning how to make good code design :)
When do you want to learn it? Some day in the far future?
You can start improving your code style now. Try to write code without a single global or static variable, and without a singleton. It may be difficult in the beginning, but it's worth the trouble. Especially because you begin to think about dependencies, and because you are forced to structure your program, making the single parts more modular and maintenance-friendly.
-
As I wrote previously, I'm still learning. I didn't know that global/static variables are so bad for good code design. I've written one module for global managing resources (based on static variables), so there's long way to go through for me ::) Thanks for advice!
-
As I wrote previously, I'm still learning. I didn't know that global/static variables are so bad for good code design. I've written one module for global managing resources (based on static variables), so there's long way to go through for me Thanks for advice!
Global variables are never a good thing. Use classes, data structures, and enums to hold your variables. Declare your variable inside a data container then define them in a function held inside a class. Also, use abstract classes. Here's an example:
// Class.h //
class IDClass {
public:
virtual void function(void) = 0;
virtual void function2(void) = 0;
};
extern IDclass* idclass;
// Class.cpp //
class IDClassLocal : public IDClass {
public:
virtual void function(void);
virtual void function2(void);
private:
int integer;
bool boolean;
};
IDClassLocal idclassLocal;
IDClass* idclass = &idclassLocal;
void IDClassLocal::function(void) {
integer = 5;
boolean = (false);
}
void IDClassLocal::function2(void) {
integer = 2;
boolean = (true);
}
// main.cpp //
int main() {
idclass->function(void); // integer = 5, boolean = (false)
// Other code
idclass->function2(void) // integer = 2, boolean = (true)
}
The following shows the abstract class being declared in a header, then being inherited and defined in the cpp. This is polymorphism at it's best. Using this style will get rid of a lot of issues. If you have an issue you can't seem to solve, run your program in debug mode under a debugger; doing this, you should be able to find the cause.
-
Also, use abstract classes. Here's an example:
To be honest, I've no idea how this fits into the topic at hand... ::)
We all know by now that he's still learning and might even be reading a good book about C++ (http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list), but such a small, uncommented and not clean, regarding code design, example won't teach him much.
The following shows the abstract class being declared in a header, then being inherited and defined in the cpp. This is polymorphism at it's best. Using this style will get rid of a lot of issues. If you have an issue you can't seem to solve, run your program in debug mode under a debugger; doing this, you should be able to find the cause.
You sound like you're selling the solution to all problems. ;D
Programming in C++ is much more than a bit polymorphism and debugging. Besides that, it's a better code design to avoid polymorphism where ever possible, or better said, use it only when really needed and not as general formula.
-
Good knowledge about language is base. I read really good book about C++ by George Grębosz some years ago, but people are learning all life :) I'll look for good book about code design. Thanks again ;)
-
such a small, uncommented and not clean, regarding code design, example won't teach him much
Well, it's pretty straight forward and I honestly didn't think it would require comments. Considering that's a similar piece of code out of "Doom 3"'s source, I wouldn't call it "unclean", considering "Doom 3" had some of the cleanest, most efficient code ever written.
How does it fit in this topic? Containers for data, which was the main issue in the program he wrote. - Preventing the usage of global variables.
EDIT: Also, polymorphism is the base of object oriented programming, so saying:
it's a better code design to avoid polymorphism where ever possible
would be saying to avoid O.O.P., would it not?
or better said, use it only when really needed and not as general formula.
Doesn't that go for almost all techniques?
Programming is much more than polymorphism and debugging, but we are not talking about the definition of programming; we are talking about good programming structure and efficient, effective code. My example also showed pointer, abstract class, and inheritance usage. Not only that, but the usage of a class to store functions and variables in general.
-
Containers for data, which was the main issue in the program he wrote. - Preventing the usage of global variables.
With that, I'd rather point towards std::vector, std::map, etc. and explain that one can wrap things into classes; a polymorphic hierarchy isn't needed for a basic game.
EDIT: Also, polymorphism is the base of object oriented programming, so saying:
it's a better code design to avoid polymorphism where ever possible
would be saying to avoid O.O.P., would it not?
Yes and no. OOP is an paradigm like many others and C++ is a multi-paradigm language, so sticking to one paradigm only, will not only produce bad code, but make life very hard. The modern C++ approach is to use objects, but reduce any dependencies between objects, while preferring composition over inheritance. That said polymorphism is not an "evil" thing over all, it has his places, e.g. SFML makes use of it for sf::Drawable and sf::Transformable, but as Laurent has mentioned a few times, he'd rather not have those "base classes".
As for game development specifically, the whole inheriting entity blob approach is not that much appreciated anymore, because it always introduces a highly depended hierarchy, which turns into less efficient code and makes it nearly impossible to maintain properly at some point. Better approaches are component based or data-driven systems.
Programming is much more than polymorphism and debugging, but we are not talking about the definition of programming; we are talking about good programming structure and efficient, effective code. My example also showed pointer, abstract class, and inheritance usage. Not only that, but the usage of a class to store functions and variables in general.
Well that's the problem, polymorphism isn't very efficient, since for example, every polymorphic structure will get compiled via a v-table, which aren't very efficient.
The whole point being made by me, is that the example is too complicated for a beginner. If he has never worked with classes, he will have no idea what inheritance is and will have no idea, how this point thingy now suddenly works etc. He's missing the basic of C++, which is what a class is and talking about polymorphism is a topic, he might want to checkout later on, thus my questioning of the relevance of your post. ;)
But well everyone is free to post here. ;D
PS: Please, please, please don't put dots between acronyms, it's just not the way to go, i.e. S.F.M.L or O.O.P. or A.P.I., it's SFML, OOP and API - thanks! ;D
-
Considering that's a similar piece of code out of "Doom 3"'s source, I wouldn't call it "unclean", considering "Doom 3" had some of the cleanest, most efficient code ever written.
Doom 3 was written in the 2000's, C++ has evolved a lot since then. I don't only mean C++11, rather "modern C++" in general, as taught by Meyers, Sutter, and so on. One recognition was that "pure" OOP, like Java used it all the time, was too limited on its own. Alternative abstraction techniques, most notably templates, became interesting, and people began to combine different approaches. For example, the STL is extremely flexible, although the container classes don't use inheritance. Or std::function is the perfect example of type erasure, a combination of static and dynamic polymorphism. It is much more powerful than the pure OOP equivalents (observer/command pattern).
Well that's the problem, polymorphism isn't very efficient, since for example, every polymorphic structure will get compiled via a v-table, which aren't very efficient.
Be careful with such statements, they are the reason why there are still so many performance myths. Of course virtual functions come with an overhead, but so does any runtime dispatching mechanism. People often forget that the alternatives (if-else or switch) are not for free, either.
-
Be careful with such statements, they are the reason why there are still so many performance myths. Of course virtual functions come with an overhead, but so does any runtime dispatching mechanism. People often forget that the alternatives (if-else or switch) are not for free, either.
Hehe, yeah I knew someone will criticizes it. I don't like such general statements either and I might not know enough about the topic, that's why I added "for example". Oh well... ;D
-
Doom 3 was written in the 2000's, C++ has evolved a lot since then. I don't only mean C++11, rather "modern C++" in general, as taught by Meyers, Sutter, and so on. One recognition was that "pure" OOP, like Java used it all the time, was too limited on its own. Alternative abstraction techniques, most notably templates, became interesting, and people began to combine different approaches. For example, the STL is extremely flexible, although the container classes don't use inheritance. Or std::function is the perfect example of type erasure, a combination of static and dynamic polymorphism. It is much more powerful than the pure OOP equivalents (observer/command pattern).
That is true, but you should consider looking at the following link: http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code
It's more than just the code itself, it's the organization of it. The placement of braces, spacing, etc. Also, John Carmack's comment:
"In some ways, I still think the Quake 3 code is cleaner, as a final evolution of my C style, rather than the first iteration of my C++ style, but it may be more of a factor of the smaller total line count, or the fact that I haven’t really looked at it in a decade. I do think “good C++” is better than “good C” from a readability standpoint, all other things being equal.
I sort of meandered into C++ with Doom 3 – I was an experienced C programmer with OOP background from NeXT’s Objective-C, so I just started writing C++ without any proper study of usage and idiom. In retrospect, I very much wish I had read Effective C++ and some other material. A couple of the other programmers had prior C++ experience, but they mostly followed the stylistic choices I set.
I mistrusted templates for many years, and still use them with restraint, but I eventually decided I liked strong typing more than I disliked weird code in headers. The debate on STL is still ongoing here at Id, and gets a little spirited. Back when Doom 3 was started, using STL was almost certainly not a good call, but reasonable arguments can be made for it today, even in games.
I am a full const nazi nowadays, and I chide any programmer that doesn’t const every variable and parameter that can be.
The major evolution that is still going on for me is towards a more functional programming style, which involves unlearning a lot of old habits, and backing away from some OOP directions."
Just something to reflect on.
Also:
PS: Please, please, please don't put dots between acronyms, it's just not the way to go, i.e. S.F.M.L or O.O.P. or A.P.I., it's SFML, OOP and API - thanks!
I just feel like changing it up a bit, it's just more entertaining to me; not sure why to be honest, haha. I guess I'll quit doing that.
-
It's more than just the code itself, it's the organization of it. The placement of braces, spacing, etc.
Sorry, I'm not much into apotheosizing one code base. Everyone has its coding style and guidlines that they like or dislike. I'm not familiar with the Quake 3 code base though, thus I can't say anything about it, but I'd guess it's using still quite a lot of legacy code and every code base has its quirks somewhere.
I mean it's very nice that we get access to such code and it's educational to read through it, but making the example out of it... I don't know...
I mistrusted templates for many years, and still use them with restraint, but I eventually decided I liked strong typing more than I disliked weird code in headers. The debate on STL is still ongoing here at Id, and gets a little spirited. Back when Doom 3 was started, using STL was almost certainly not a good call, but reasonable arguments can be made for it today, even in games.
I sure do respect Carmack's answer, but not using the STL, just because it doesn't feel right or one thinks the self-written data structures are way better is just bad. It not only throws away a huge part of C++ itself, but it also puts all the developer of any STL implementation into bad light. For a casual game, for which SFML was developed for, it's idiotic to ditch STL where ever possible. If one is really worried about performance one can always use some drop in replacements later on, but first I want to see that performance issue coming from the STL.
Again I respect Carmack and many other devs from the industry, but if one wants to talk coding guidelines I'm rather sticking with Meyers, Sutter, Stroustrup and alike. ;)
@Laurent: Maybe you wanna split this discussion... If only I had moderator rights... ::)
-
It's more than just the code itself, it's the organization of it. The placement of braces, spacing, etc.
Yes, the organisation may indeed be good. This concerns modularity, dependencies, responsibilities per class/function, code reuse, etc. But certainly not placement of braces, spacing etc -- that's a completely different thing, namely syntax. Code that doesn't adhere to syntactic consistency is not even worth discussing.
Besides organisation, an important part are idioms. RAII, rule of three, copy-and-swap, abstraction from low-level techniques, locality of declarations, invariant checking, and so on.
When I look at the Doom 3 code, it looks indeed clean. But it doesn't use a lot of modern C++ idioms, mainly because it is rather old. For example, it uses un-encapsulated arrays, declares most (not all!) variables at the beginning of the function and uses reserved identifiers. When I search for the std namespace, I can't find any occurrences. Seriously, they don't use a single part of the C++ standard library! Only parts of the C standard library are used. It may be a result of broken STL implementations at that time, but in the field of game development, people have always tended to reinvent wheels.
These are all things that make a code bad, according to today's measures. That's why you should not show the Doom 3 source as an example of good code -- it may be an example of good code organization, but not style in general. We are in 2013 now, C++ is much different today.
-
The whole point being made by me, is that the example is too complicated for a beginner. If he has never worked with classes, he will have no idea what inheritance is and will have no idea, how this point thingy now suddenly works etc. He's missing the basic of C++, which is what a class is and talking about polymorphism is a topic, he might want to checkout later on, thus my questioning of the relevance of your post. ;)
Oh, I'm not so beginner :) I know some languages and libraries. My C++ knowledge maybe isn't the best (I've not recognized new C++11 standard library fully), but I know what are templates, exceptions, polymorphism or even v-table from assembly level. As I wrote previosly - I'm not professional programmer and I just don't know how to make good code - but I want to learn it. I have more difficulty with translating english - I'm just 16 ::)
-
Seriously, they don't use a single part of the C++ standard library!
It may be a result of broken STL implementations at that time, but in the field of game development, people have always tended to reinvent wheels.
Yes, they rolled their own.(It's a big no-no today but made sense back then).
http://fd.fabiensanglard.net/doom3/doom3_diagram2.png
Box2D doesn't use std:: except for sort(I think it was sort) once. Irrlicht rolled their own and they're still ironing out the bugs.. :-\ I'll have to roll my own vector and maybe few others soon because my uni gives penalties to code using STL. But Box2D is pragmatic about everything like HELL, no rendering, no outside libs, no nothing, all you need is have a working C++ compiler with malloc and free(or any functions for memory, there are #defines for that in settings header), that's just so little, no lack of STL or bugs in it or anything can impede you. And it seems to be a good thing, Box2D is on Android, iPhone, it's ported to javascript, objective C, C#, action script(like every game ever that has physics uses it..). Not everyone gets to use comfy gcc or msvc implementations.
The whole point being made by me, is that the example is too complicated for a beginner. If he has never worked with classes, he will have no idea what inheritance is and will have no idea, how this point thingy now suddenly works etc.
That's how my uni teaches for the most part too, it's so fun for me because I know C and c++ so well that Java and C# come somewhat naturally.
Edit: Oh, and there's the rule that any serious programmer has their own string implementation.. let's see.. SFML, Irrlicht, Ogre3D, Qt, MFC.. the list goes on forever..
Edit2: Oh, and the not invented here syndrome. Awesome thing.. I used to have it a bit.
-
Qt is another example of a successful wheel-reinventer. A lot of those libraries have a long history, which makes the avoidance of the standard library somehow reconstructible. Still, arguments like "we want to support as much compilers as possible" are meanwhile definitely off. The C++ standard has existed for one and a half decade! And don't forget the portable standard library implementations like STLport.
For new libraries and own projects, one certainly needs a very good reason to reinvent parts of the standard library. Performance is usually none...
Strings are a special case because the standard library's Unicode support is poor. I hope this improves with C++1y.
-
SSO is first thing that comes to my mind which can affect performance like crazy(I think there is even example somewhere in iterator vs. index thread) between STL implementations.
For new libraries and own projects, one certainly needs a very good reason to reinvent parts of the standard library.
I think so too. :)
"we want to support as much compilers as possible" are meanwhile definitely off. The C++ standard has existed for one and a half decade! And don't forget the portable standard library implementations like STLport.
Especially if they want to avoid STL bugs and introduce own bugs(hello Irrlicht), makes you want to ask Tank to borrow you one of the underscores from hello_stefan_convention to stab yourself with.
- Fixed bug causing memory access violation in string::replace found and patched by Nalin.
That's from 1.8 Irrlicht change notes. I'm not saying they are bad programmers but what's the point of reimplementing everything just to 'be in control' while it can introduce bugs for a long time.
-
Honestly, if you really want to learn good efficient C++ and learn on game development, read "Bjarne Stroustrup The C++ Programming Language", "Accelerated C++ 2000", "Effective C++; More Effective C++", and for game development: "Core Techniques and Algorithms in Game Programming".