I am new to SDL programming. And in one of the tutorials, http://twinklebeardev.blogspot.in/2012/07/lesson-2-dont-put-everything-in-main.html it is mentioned that the SDL Window,and SDL Renderer should not be declared as global?
What is the technical underpinning behind it ?
There is no reason as far as c standard and sdl library are concerned, to not use SDL Window and SDL Renderer as global variables.
A think is more a recommendation than a mandatory order. If they are declared locally, you will structure your code better and is easier figure out where these are being used. If you declare them as global you can quickly forget what parts of your code are using it and some small change in a part of it can break everything without giving you any clue about it.
The rule of thumb is never declare any globals except if extremely necessary.
There is nothing technically preventing the use of globals, it's more a matter of taste and choice of language.
The author of the tutorial is speaking from the point of view of using SDL from the c++ language. In C++ there is a strong emphasis on object-oriented code structure, including encapsulation and abstraction (i.e. hiding the details of an implementation behind a class structure).
The author goes into more details regarding global objects and classes in tutorial 7, which might be useful to get a better understanding of their design process.
Related
I am learning OpenGL but I am a little confused about the way how variables are used. In many example codes written in C++, the variables are used as global variables. But I do not think it is desirable for us to use too many global variables in the program. So I am wondering how can I use variables without violating encapsulation? Or should I use a singleton to record all the variables such as the models?
In many example codes written in C++, the variables are used as global variables
This sound like you're reading examples written using the GLUT framework. That the variables are global is a direct result of GLUTs design to be a minimalistic framework, that's meant for simple tests and techdemos. You should not use GLUT for serious applications.
GLUT is not part of OpenGL. It's a 3rd party library and there's no requirement to use it in any way when it comes to OpenGL. In fact it's highly recommended you don't use it.
OpenGL itself can be used from encapsulated code just fine. Look for OpenGL examples that use the Qt framework. IMHO the way Qt implements OpenGL widgets and context encapsulation is suboptimal (only recently I've run into serious limitations), but if you're an beginner you'll hardly notice that.
After coding for some time in Java and using Graphics2d, I thought of using what I've learned in other languages, for example C++. I usually use SFML, and have a Render class so as to reduce dependency of other classes on SFML (as in, if I must switch libraries I would not need to switch much code in unrelated classes). I was wondering if I should have this Render class inherit RenderWindow, or simply have it as a member.
A currently often suggested idiom is 'composition over inheritance'. From your vague description of what you're doing, it's actually impossible to give precise answer. I'm assuming you're talking about a simple interface between your framework and any graphics library.
In that case the answer is quite simple, because inheritance would automatically change the API of the render and it would change for every single graphics library you'd use and thus defeat the whole purpose of it. So if you use it as a member variable, you can craft a stable API for your framework and do all the adaption for different libraries within the scope of the render class.
I am choosing a GUI toolkit for C++ to learn. I have done some searching online and most people suggest GTKmm for C++ over GTK+. Despite that fact, I have seen some C++ applications made using GTK+.
Therefore, I just want to know the specific reasons for this:
1. Why GTKmm is preferred for C++?
2. What are the limitations I will face if I use GTK+ for C++ applications instead of GTKmm?
gtkmm allows you to write code using normal C++ techniques such as encapsulation, derivation, and polymorphism. As a C++ programmer you probably already realize that this leads to clearer and better organised code.
gtkmm is more type-safe, so the compiler can detect errors that would only be detected at run time when using C. This use of specific types also makes the API clearer because you can see what types should be used just by looking at a method's declaration.
Inheritance can be used to derive new widgets. The derivation of new widgets in GTK+ C code is so complicated and error prone that almost no C coders do it. As a C++ developer you know that derivation is an essential Object Orientated technique.
Member instances can be used, simplifying memory management. All GTK+ C widgets are dealt with by use of pointers. As a C++ coder you know that pointers should be avoided where possible.
Less code. The GTK+ C object model uses prefixed function names and cast macros. For instance: gtk_button_set_text(GTK_BUTTON(button), "sometext"); gtkmm C++ code is shorter and clearer. For instance: button.set_text("sometext");
There's no need to worry about GTK+'s inconsistent reference-counting policy.
Source: http://live.gnome.org/gtkmm/FAQ
I have often seen the spinning gears OpenGL example ( I think originally done by SGI) but I today I have only been able to find C and Ruby implementations, can anyone point me to a c++ implementation?
What, in particular, would you be looking for in a C++ implementation that the C one doesn't provide? OpenGL is a C API, and thus a C demonstration is practical. A C++ implementation would call all the same functions in the same order and to the same effect, it would likely just wrap the implementation in an object. This doesn't really further one's understanding of the core API, and can possibly add a layer of obfuscation to those not familiar with some C++ styles and patterns.
If what you are really looking for is an example of initiating OpenGL wrapped in a C++ framework, I made a few of those a while back. You can find them here. Please note that I'm no longer actively maintaining the code or page, though.
If you want to mess around with OpenGL i strongly reccomend using OpenSceneGraph (OSG) since you can focus better on computer graphics aspects instead. It's using all the C++ magic and design patterns.
I'm writing a graphical application using Objective-C for the front end and C++ for the graphics processing and network communication. I read around on Apple's site looking for a way to link either a .dylib or .so with my C++ code in it to my Xcode project, but nothing seemed to work. I was able to get the project to reference it and link against it, but when I tried to call functions from that .dylib, it was saying that it didn't know what I was trying to do. Does anyone know what is going on here?
I know that Objective-C has all the libraries I would need to do graphics and networking, but I just feel like doing it like this. I haven't done much C++ in a while and I want to learn more Objective-C, so what better way than to use them together?
Thanks,
Robbie
Most of the projects I work on have an ObjC frontend and C++ backend. If you're dealing exclusively with functions, then Dave Gamble's name mangle fix is correct, but if you're dealing with more complex situations, where you need to deal with both ObjC and C++ objects, your best bet is to wrap the C++ objects in ObjC objects. Using opaque references (which is a very fancy way of saying void*), you can actually hand around C++ objects in ObjC and vice versa. I have some sample code that may be helpful.
That said, for graphics you're probably going to take a serious performance hit doing custom C++ rather than using Core Image and the related frameworks. Core Image and the other graphics frameworks are highly optimized for the Mac, and you're very unlikely to do better with hand-rolled C++ (or even very well-written C++ that isn't specifically for the Mac). As you move to 10.6 and grand central dispatch, the performance difference is going to be even more notable because you'll lose all the parallelization advances that you would get for free otherwise. This has nothing to do with ObjC; Core Image is C. You can call it from C++ all you like. I just recommend against custom graphics processing on Mac in any language unless you need portability or you have the expertise necessary to beat Core Image.
You're going to hit one obstacle in the form of what's called "name mangling". C++ stores function names in a way not compatible with Obj-C.
Objective-C doesn't implement classes in the same way as C++, so it's not going to like it.
One way around this is to implement a set of simple C functions which call the C++ functions. It'll be a good challenge to keep the number of C functions as low as possible! You'll end up with a nice compact interface! :)
To declare these functions in a C++ file, you'll need to mark them as C with:
extern "C" int function_name(char *blob,int number, double foo) {...}
This disables the standard name-mangling.
Build a header file with the prototypes for all these functions that you can share with your objective C code.
You won't be able to pass classes around in the same way (because your ObjC code can't use them), but you'll be able to pass pointers (although you might have to lie about the types a little).