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
Related
With native c++, I mean, not managed c++, not cli, not any special things from microsoft, I can:
1) get high performance
2) use existing c++ code library and engine
3) write cross platform code (for example, for ios and android)
it needn't be fully native c++, I can use managed code to do the ui things, like object-c in ios and java in android, but beside interface, can I use native c++ code?
I suggest you have a look at the presentation here: Using the Windows Runtime from C++ and especially at the comments from Herb Sutter. I quote:
Please answer this question: If I decide to write C++ GUI application
in Metro style am I forced to use all these proprietary ref, sealed,
^, Platform::String^ extensions for GUI components or not?
#Tomas: No, you are not forced to use them. We are providing two
supported ways:
1) These language extensions (C++/CX).
2) A C++ template library (WRL), see
Windows Kits\8.0\Include\winrt\wrl as Yannick mentioned. WRL is a C++
library-based solution sort of along the lines of ATL, which offers
what I think you're looking for -- template wrapper/convenience
classes and explicit smart pointers and such.
Yes you absolutely can, real native C++ is fully supported.
You do however mostly have to use the new WinRT libraries to do an user interface or system calls and although they are native code and fully callable from C++ directly the interface to them makes it very painful indeed to do so, as everything is a reference counted COM object and in addition it's not so easy to create instances of them as just calling "new" so you have to write a lot of ugly code to do so.
As the earlier answer said, microsoft provide two ways to help with this. One is via language extensions to c++ and the other is a c++ template library. Personally I consider both to be rather ugly for doing something as simple as calling an API but that's just me :)
But to answer your question, it's completely possible to write your application in real native c++. You won't need to use managed code at all for anything. But you'll probably want to use either the language extensions or the template library to make calling the API more easy.
Personally I'm hoping someone writes a wrapper for WinRT that exposes the most necessary functionality as a more usable c++ native library and then everyone can just use that from c++ instead...
I want to know the difference between c++ and objective-c and objective-c++.
Can any one give me the difference and Can we use the c++ for iPhone development
Thank you,
Madan Mohan
C++ is Bjarne Stroustroup's language based on adding classes and metaprogramming to C in such a way that puts most additional work into the compiler, and relies on least possible effort at runtime.
Objective-C is Brad Cox's language based on adding a SmallTalk-style dynamic message-passing runtime library to C, with a small amount of syntax addition to make it easier to use.
Objective-C++ is, to put it bluntly, what you get when you add the Objective-C runtime and syntax to C++. It has its limitations (e.g. you can't create an Objective-C subclass of a C++ class or vice versa, and Objective-C doesn't like C++ namespaces) but allows you to use C++ classes from Objective-C objects and vice versa.
You can use Objective-C++ in iPhone development. What this means practically is that you could write an application whose object model was entirely C++, where the controller layer would need to interface to Objective-C in order to use the Cocoa Touch APIs.
C++ and Objective C were/are two different approaches to adding object orientation to C. Current objective C compilers also accept C++ as input, so you can build a program with some files written in Objective-C and other files written in C++. When C++ is used this way, it's often called Objective-C++.
1) C++ is a language derived from C that adds Object Orientation (OO) amongst other features. *
2) Objective-C is a language derived from C that adds Object Orientation (OO) amongst other features. *
3) Objective-C++ is Objective-C that you can use C++ classes with.
You CAN use C++ for iPhone development but you will need "some" Objective-C code to interface with the iPhone libraries.
(*) Though they both try to solve the same problem they do it quite differently. There is some information about the differences on wikipedia and I'm sure you can use google to find more.
You CAN use C++ for iPhone development but you will need "some" Objective-C code to interface with the iPhone libraries.
This will very likely give you code and possibly memory bloat. As you know, iOS programming should be a lean as possible: minimize both the library size and runtime memory needs. iOS programming and runtime environments are also highly optimized for Objective C.
Pure ObjC is much better than C++ for iOS. Unless you're trying to use existing large C++ code base it will probably be better to re-write from scratch. Nearly all of the C++ STL have analogs in the iOS frameworks, often easier to use, and highly optimized by Apple.
Learn Objective C memory management, get familiar with the frameworks and go for it.
This might be a dumb question to some of you and maybe I asked this question wrong, because I am new to C++. But I notice when working in a lot of Win32 applications, you use a lot of resources that are pointers. Why do you have to always acquire a objects pointer? Why not initiate a new instance of the class. and speaking of that, I notice in most cases you never initiate new objects, but always call on methods that return that pointer. What if that pointer is being used somewhere else. Couldn't you mess something up if you alter that pointer and it is being used somewhere else?
Windows APIs were designed for C, which was and still is the most used language for system programming; C APIs are the de-facto standard for system APIs, and for this almost all other languages had and have some way to call external C functions, so writing a C API helps to be compatible with other languages.
C APIs need just a simple ABI, that consists of almost just the definition for the calling convention to use for functions (and something about the structures layout). C++ and other object oriented languages, on the contrary, require a complex ABI, that must define how objects are laid out in memory, how to handle inheritance, how to lay out the vtable, how to propagate exceptions, where to put RTTI data, ... Moreover not all the languages are object oriented, and using APIs thought for C++ with other non-object oriented languages may be a real pain (if you ever used COM from C you know what I mean).
As an aside, when Windows was initially designed C++ wasn't so widespread on PCs, and also C wasn't used so much: actually, a large part of Windows 3.11 and many applications were still written in assembly, since the memory and CPU constraints at the era were very tight; compilers were also less smart than now are, especially C++ ones. On machines where hand-forged assembly was often the only solution, the C++ overhead was really unacceptable.
For the pointers thing: Windows APIs use almost always handles, i.e. opaque pointers, to be able to change the underlying nature of every resource without affecting the existing applications and to stop applications to mess around with internal structures. It doesn't matter if the structure used by the window manager to represent a window internally is changed: all the applications use simply an HWND, which is always of the size of a pointer. You may think at this as some kind of PIMPL idiom.
However, Windows is in some way object-oriented (see for example the whole "window class" concept, or, at a deeper level, the inner working of the NT kernel, which is heavily based on the "object" concept), however its most basic APIs, being simple C functions, somehow hide this OO nature. The shell, on the other side, being designed many years after, is written mostly in C++ and it provides a really object-oriented COM interface.
Interestingly, you can see in COM all the tradeoffs that you must face in building a cross-language but still C++ biased object-oriented interface: the result is quite complicated, in some respects ugly and not really simple to use from any language. The Windows APIs, instead, being simple functions are generally more easily callable.
If you are interested in a system based on C++ APIs you may have a look at Haiku; personally, this is one of the aspects because of which I am quite interested in that project.
By the way, if you are going to do Win32 programming just with the APIs you'd better get a good book to get used to these "particularities" and to other Win32 idioms. Two well-known ones are the Rector-Newcomer and the Petzhold.
Because Win32 Api are written on plain C, not C++. So any program on almost any language can make call to those API.
Plus, there are not simple mechanism to use objects across diferent modules, and diferent languages. I.e. you can't export C++ class to python. Of course, there are technoligies like OLE/COM, but they still written on plain C. And they are bit comlicated to use.
At other hand - calls to plain C functions are standardized. So you can call routines from DLL or static lib in any language.
Win32 was designed to work with the C language not C++.
That's why you will see return types of the defined BOOL instead of bool for example.
bool is specific to C++ and doesn't exist in C.
For Microsoft's object oriented wrapper of Win32 see MFC.
A newer framework from Microsoft since then is the .Net Framework.
The .Net framework is based on managed code though and does not run natively. The most modern way to do GUI programming on Windows is WPF or even Silverlight.
The most modern way to do unmanaged GUI programming is still using MFC, although some people still prefer using straight Win32.
Note working with pointers is not specific to C, it is still very common in C++.
First reason is because passing pointers around is cheap. Pointers are 4 bytes on x86 and 8 bytes on x64. While the structure or class it points to can occupy a whole lot more in memory. So instantiating a class means reserving new memory again and again. This isn't efficient from speed and memory consumption POVs.
Another way is to pass references to objects or smart pointers or similar constructs. But win32 api was designed in the C era, so this is where it is up to now ;)
As about potential messing up with pointers - it's possible of course. But most of the time their lifetime is explicitly stated in the API (if not obvious).
Probably because the Win32 API is "older" than mainstream object-oriented programming, it's not a C++ API at its core.
Its almost like you should try one of the many OO wrappers. Like MFC or .net.
The Windows API is plain old C, hence the use of pointers everywhere. Also, the reason you ask Windows for a new pointer is because Windows needs to keep track of all objects... it allocates things and tells you a pointer (or sometimes just a numeric ID) to let you work with them.
Having C functions as the API allows both C and C++ programmers use it.
Windows APIs goes way back - C was famous during those days.
All the HWND, HANDLE, HDC are but a weak attempt to make clamped, objects-like data types (using struct). C FAQ has a question on this -> http://c-faq.com/struct/oop.html.
To understand the pointers you might want to read the CPlusPlus.com tutorial on pointers.
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).
I am a C# programmer who started using ubuntu about 2 years ago. I'm wanting to learn GUI programming in either C or C++. I don't really like mono, it tends to crash on my system. I have a basic understanding of C++. I have never worked in C, but it looks cool. Which toolkit should I learn/use? Give Pro/Cons of each. Thanks!
I could be accused of bias since I do help contribute to gtkmm, but I was a user first, so... In any case, I would highly recommend gtkmm if you're comfortable with C++. Memory management is much easier with gtkmm than with GTK+ because reference-counted objects are managed automatically with smart pointers. You can also instantiate objects as auto variables (e.g. on the stack) and have their lifetime determined by their scope. So in practice, it's much easier to avoid memory leaks with gtkmm than with GTK+.
Another huge advantage of gtkmm over GTK+ (in my opinion) is the use of a type-safe signals framework. In GTK+, you constantly need to pass things as void pointers and then cast them around to the type you think they should be. In gtkmm, you dont need to do this, and can take advantage of the compiler enforcing type-safety on your signal handlers.
Another big advantage over C/GTK+ is the ease of deriving new classes. In GTK+, you need to write a lot of boilerplate code and basically re-implement things that you get for free in C++ as part of the language (e.g. inheritance, constructors, destructors, etc). This is more tedious and error-prone.
greyfade mentioned that gtkmm is incomplete, and he's right to a certain extent -- gtkmm does not cover absolutely everything in the GTK+ API (though it gets awfully close). But in practice this is not a problem because you can always use the C/GTK+ API directly from your gtkmm code. This C compatibility is a huge advantage of C++ over something like C# or python bindings where you would have no alternatives if the binding didn't cover part of the API.
The only real reasons to choose GTK+ over gtkmm (IMO) are that gtkmm has a little additional overhead since it is a wrapper on top of the C library (but this is generally just a single function call, which is going to have negligible impact), or if you hate or can't use C++.
If you're a C# programmer, why don't you take a look at Vala?
I use pygtk for most of my Linux GUI applications, but Python was simply too slow for the project I'm working on right now, so I was trying to pick one of GTK+ and GTKmm. Then I met Vala.
It's a pretty new language, and therefore documentation is pretty limited at the moment, but I think it has the best of both worlds: C# syntax with C speed.
Since C++ is more familiar to you, you may find GTKmm to be a better fit, since you can use idioms like RAII. Unfortunately, GTKmm is a little incomplete and is missing a few of the lesser-used parts of GTK.
GTK+ on its own, however, essentially exposes an object model similar to what you find in C++, but with only C functions. Things like construction and destruction in C++ are done explicitly in the C API and instances of widgets are handled via pointers exclusively.
Try both and see which fits your project better.
Like many have said, Gtkmm does provide you with good memory management, reference counted objects, etc. It does fall down in one department, though. Documentation. The whole of the Gtkmm project suffers from the "undocumentation" phenomena, where the posted (and reposted on 3rd party sites) documentation is simply a javadoc scan of the header files.
Just wanted you to know what you'd be getting into. For instance, the Scrolled Window is one of the better documented classes in Gtkmm.
I would suggest to learn vala with gedit.
http://www.valaide.org/doku.php : vala
https://launchpad.net/valable : Eclipse
http://code.google.com/p/vtg/ : Gedit
http://abderrahim.arablug.org/blog/ : anjuta
I think the best way to go would be first learn gtkmm! After you are done with the basics of gtkmm, GTK+ should be fairly straightforward to learn(provided you know C and are comfortable with pointers).
In case you don't know C, you can learn it quickly by reading The C Programming Language by Dennis Ritchie
I recommend you to learn gtkmm first because it is specially designed for C++, which is somewhat similar to C# since both are Object Oriented, so gtkmm will be relatively easy to learn first than GTK+.
After gtkmm, you can move on to GTK+
Most of the open source companies use GTK+ rather than gtkmm, so GTK+ is worthwile to learn!
Have you looked at Qt?
It's nice C++ design, cross platform and LGPL