As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The Introduction
Okay, so after version 0.60 of GTK+, the designers realized that for future development and progress, the entire toolkit needed to be rewritten to be object-oriented.
Now, since C doesn't support OOP, to provide object-orientation and in inheritance heiriearchies, they created the GObject System. Now creating the GObject System must have required development time, more dependencies, more problems, but they had to create it to provide object orientation capabilities to the C Programming Language. But at that time, there was another solution that provided exactly that, C++!
The Question
Why didn't the developers of GTK+ just use C++?
The Explanation
I mean, Why waste time creating an entire library instead of using a time-tested solution adopted by a lot of projects? Don't get me wrong, I am not trying to turn this post into a C vs C++ thing (I've had enough of that on forums, thank you). I just want to know the reasons and issues that made the designers of GTK+ make the decision they did.
I can't directly answer the question, at least as far as GTK goes. That answer lies with the GTK+ developers, so you'll have to hunt them down and ask them. But as for why one would want to add an object oriented system to C, instead of using C++, there are plenty of reasons. The three I would immediately think of are
Language Complexity: While C is a pretty simple language, C++ is mind-numbingly complicated, with support for most (not all) C stuff, as well as conveniences like references, and also object-oriented features and a complex template language. And have you seen the new system of values: lvalues, rvalues, glvalues, prvalues and xvalues - huh? There's plenty more I could talk about. Given time, C++ becomes manageable, but it's still overkill for just wanting some object oriented features in C.
Control: If the designers went with C++, they'd be stuck with C++ philosophy. For instance, multiple inheritance is a controversial idea, and for good reason. By design, the GObject system is built to only support single inheritance, which can drastically simplify the inheritance hierarchies. If the designers went with C++, there would be no way to limit users to a single inheritance system. Multiple inheritance is just an example - I'm sure there's plenty of other places in which the GObject system differs from the C++ ideology.
Interoperability: This is probably a big one. Although there a few languages with which C++ interoperates cleanly, the fact is that C++ just isn't that great at interop. However, interoperability with C is almost taken for granted. C is often described as the lingua franca of programming languages, since it forms the de facto standard for interop. By designing a C API, the GObject designers opened the door to GTK+ development in any number of languages.
GObjects is intended to be language independent. It has dynamic typing, and you should it compare with a run-time system like COM, .NET or CORBA, rather than with specific languages. If you go into languages, then the features are more at the Objective-C than the C++ side.
The GObject type system does things that you can't do in C++. For one thing, it allows creation of new classes at runtime, and does this in a way that is language-independent - you can define a new class in Python at runtime, then manipulate instances of that class within a function written in C, which need not even be aware that Python was ever involved.
From the wiki linked to in the question:
History (From Wikipedia)
GTK+ was originally designed and used in the GNU Image Manipulation Program (GIMP) as a replacement of the Motif toolkit; at some point Peter Mattis became disenchanted with Motif and began to write his own GUI toolkit called the GIMP toolkit and had successfully replaced Motif by the 0.60 release of GIMP.[3] Finally GTK was re-written to be object oriented and was renamed GTK+. This was first used in the 0.99 release of GIMP.
This should tell you that object-oriented paradigm was not a paramount criterion for the choice of language for GTK (which is different from GTK+) and that feature was added much later.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to develop in Qt, and I already know Python. I am learning C++, so what are the advantages of programming Qt in C++ over Python? C++ seems more complicated, and seems like there is not much gain.
What is the advantage of using the native C++ Qt over PyQt
Speed/power/control.
PyQt application will still require python. C++/Qt Application compiles to native exe. By using C++ you'll get access to 3rd party libraries that won't be available in python, plus you'll exterminate "middle man" - layer that sits between your program and qt dlls and potentially you can get better performance. For example, I would not write an archiver or mp3 decompressor in python, although it certainly can be done.
However that comes at a cost - c++ does not have a garbage collector, is much more complex, has "slower" development (compilation time), requires years to master and you'll get better performance only if your bottleneck is in within interpreter (i.e. scripted language overhead). I.e. C++ gives more power at a cost of greater responsibility and longer development time. If you don't need that, then you don't have a reason to stick with C++.
Choice of language depends on your application/situation and your personal preferences. If you need to make application SOON or make a mockup, then it'll be reasonable to use language you're familiar with. If you have serious performance problems, then it'll be reasonable to hire skilled C++ programmer to do the job - make native application, profile it, optimize, etc.
Please note that language is a tool. If you want to use your language for everything simply because you like the language, you're not working efficiently.
--EDIT--
Personally, I would not use python for a larger application I'm expected to maintain for a long time. However, this is because the language is not exactly compatible with my mindset (reliance on Murphy's Law) and (as a result) I'm not comfortable with it. Person that thinks differently will be probably much more comfortable with Python and might even think that C++ is too restrictive.
Another thing is that judging from my experience of writing Blender plugins and various python scripts, there's some serious performance overheads that appears because language is scripted, and very heavy list/map/array manipulation that can be performed FAST for free in C++ might take 5x..10x times longer in python. Some people might insist that this can be fixed, however, cost of this "fixing" might overcome benefits you get from using scripted language. Regardless of my preference, I still use Python for making utility scripts that need to run several utilities, split/splice/parse their text output and do something with it (C++ isn't very good at this situations), and I'd still provide Python bindings (assuming Lua is no good) in a program that must be extensible.
In the end it comes down to selection of most suitable tool - if C++ will not give you any benefit compared to Python, then there's no reason to switch.
If you're planning on distributing your app, it's much easier to deliver a self-contained compiled executable than relying on your end users to install Python and PyQt first. But that may or may not be a consideration for you.
C++ optimizes machine speed.
Python optimizes programmer speed.
C++ is relatively wordy: more words per idea expressed. Bugs / Lines_of_code is roughly a constant, so concision matters.
C++'s memory management is sometimes manual, which can mean strange runtime issues http://stromberg.dnsalias.org/~strombrg/checking-early.html including segfaults and memory leaks. Python takes this out of the hands of the programmer and automates it.
GUI's rarely care about the speed of their implementation language - the main issue is how fast the enduser can type and click.
In short, I believe that unless you have strong performance requirements, you should stick with Python. Also, as Greg mention, your program will be more portable with Python than with C++.
I love C++ but these days, for most project, I mostly turn to Python if not Java. However, if I'm writing a game or a graphics application, I might consider C++.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have the book "Write Portable Code" which details POSH, an open-source "framework" (mostly just a header) to help with portability of C/C++ code between different platforms and hardware.
Since Poshlib hasn't had an update in 5 years now, I was wondering what other similar libraries/frameworks exist out there?
For C code, GLib is a modern cross-platform (non-GUI) library which makes it easy to write applications that run on many different platforms without source code changes. GLib is actively developed in an open manner as part of the GNOME project with lots of open source projects using it.
For C++ I would suggest looking at the Boost libraries.
Dear Shaggy Frog,
While I remain largely incurious about your handle, I must say that this is something of a hairy issue. Here's why. I work with the boost libraries day in and day out. They're fantastic, and make innumerable tasks way easier. But I must emphasis that if you use them, you need to use a profiler. Some of the really nice portions of it tend to be a bit slow, and you should definitely read up on best-practices before using certain parts like, say, transform iterators. Boost, though, is worth mentioning because it does make an effort to supply some pretty powerful pieces of abstraction that are almost foreign in the ++cverse.
However, Boost, and other frameworks like it, are not snakeoil. They rock. People who rock use them. People who rock work on them. For more specialized tasks, I'd need to know more about your problem domain. However, one other tool that's really excellent is SWIG, which will let you bundle up any hunk of portable C code into a library that's... well.... accessible.
As for bloat, a lot of that is going to go away when C++0x moves to the standard, thanks to variadic templates, and a number of similar pieces of cleverness. Honestly, I'm tired of people yelling about The Terrors Of Templates. Perhaps six years ago they were a danger due to poor compiler support, but these days, they're part of the language. They live under almost every piece of generic code you touch. Projects like CLang are hammering the very last nails into this coffin as we speak. They aren't a fad anymore. They aren't a magical solution. No one still thinks that. No one you should hire, anyway.
The future approaches. Do you need a Boost?
Most libraries with the buzzwords "portability framework" or "portable runtime" in their names are useless bloat and snake oil. If you want to write portable code, start with the relevant standards and follow them. Instead of reading your vendor's man pages or help files for standard library functions, read the ISO C or C++ standard or POSIX standard. And so on.
Aside from highly crippled embedded systems (note: many/most embedded systems do not fall into the "highly crippled" category) and DSPs, pretty much any environment can be made to be POSIX conformant. A much better approach than trying to design or find a new "portability framework" on top of diverse and incompatible underlying systems is to evaluate what parts of POSIX you need to get the job done, what parts might be missing or non-conformant on systems you're interested in, and whether there are drop-in replacements or workarounds for the missing or broken functionality.
For most people, the only relevant non-POSIX system is Windows. Cygwin is one heavy-weight option for making Windows conform to POSIX, but if you code to a more-inclusive subset of POSIX, you can get by with much lighter solutions and still support Windows.
There is similar Predef project on sourceforge, but it are not updated for several years also.
FWIW, the predef pages are actively maintained and have been continuously updated over the last several years.
Aside from Boost, which all C++ programmers should be familiar with, there are several libraries worth looking at. STLSoft is the first one that comes to my mind.
I have prepared a list of some prominent portability libraries for C and C++ on my personal web site. One can freely reuse it under the terms of the Creative Commons Attribution Licence. I had some experience with Qt, GLib, and the Apache Portable Runtime, and they all seemed to have been mostly OK.
There is also another list on the wikipedia.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I would like to know the advantages and disadvantages between C++ and VB6. The reason I am asking is because I came across a website where they have source code for various programs that are coded for Windows machines, and they are almost all coded in VB6.
However, I do not know a lot about VB6, and am trying to learn C++ at the moment, and I was wondering why people would code in VB6 instead of C++ or how they rank in different areas.
So I would appreciate it if someone could weigh the pros and cons of each language and really give me perspective of the languages.
-Oswald.
I was wondering why people would code
in VB6 instead of C++ or how they rank
in different areas.
VB6 is a dead language. It was a Microsoft proprietary language.The VB6 IDE is no longer supported but VB6 applications are supported for at least the lifetime of Windows 8. Most (with many changes) of the syntax lives on in VB.NET (another proprietary language). In addition to the syntax, VB.NET and VB6 share the idea of "canned programming", where the developer just combines existing building blocks to create small applications very easily. VB6 introduced a large number of innovative techniques for this. It became known as RAD, Rapid Application Development or Rabid Application Development, depending on who you ask.
The problem with RAD, that it doesn't scale…
Probably you looked at a very old web site.
C++ is a general programming language standardized by ISO. There are also a great many other general programming languages, and many of them are also standardized. In addition there are general programming languages like Java that are not standardized by some international standards organization, but have sufficient heavy backing that it's almost as if they are open languages, in spite of being technically proprietary.
Going into more details comparing the languages serves no useful purpose.
You might read up on the old C versus Pascal debates to see why (these debates got pretty heated, so called language wars, but resulted in some classic papers such as Brian Kernighan's "Why Pascal is not my favorite language").
VB6 is antiquated -- the only reason people would code in it these days is if their company had business reasons for not upgrading to something newer (like a large legacy code-base written in VB6). Even then, you'd expect them to be looking to move on.
VB6 has been obsolete for quite some time now and superseded by VB.NET. C++ and Visual Basic have way too many differences to list here, but if you want to learn C++, it doesn't help much to learn from VB examples. There are plenty of books, tutorials and examples for C++ - in all likelihood, much more than what you would find for VB - so that's what you should be looking for.
I am learning C++, but only after Python and Java.
It is not suggested to learn C++ as a first language (that's what I got online).
I am interested in getting deeper in low-level programming an OSs so C/C++ is what I am aiming for right now.
I would say learn C++
One reason VB may still be used is that in some companies (such as the one I worked for) we required financial analysts who were good at understand the math behind the business AND be able to produce applications that solved business problems. It turned out (as others have pointed out above) that it was easier for us to hire folks with good functional business knowledge and then get them up-to-speed with VB than C++ or VC++, the latter two being the exclusive domain of the IT-department developers.
Basically if you are looking for low-level coding that offers more speed then go with C++, however if you are new to programming I wouldn't recommend it. However, there is much more overhead with C++ and coding can take more time. C++ also allows you to be object oriented if you so choose, but it does not force the paradigm.
Visual Basic is a high-level language and is pretty well noob friendly but is slower than C++. Visual Basic has less overhead meaning you can code a lot quicker once you get the hang of it. I'm not sure if VB is object oriented but I don't believe so.
C++ is a lower-level languagge, thus programs will perform better... everywhere, period.
VB6 is a higher-level languagge, so it'd probably be easrier to learn. Actually it would depend on your previous skills, if you know java you'll have a hard time understanding VB6.
A friend of mine once said, if you know english you can write VB6 :)
Plus, VB6 is no object-oriented, while C++ is
VB6 has since been superseded by VB.net. VB was and continues to be very "newbie" friendly. VB was easier(depends on what and whom you ask) to code in, whereas C++ allowed access to certain components not available in VB6. C++ was also significantly faster than VB6, though those type of speed differences don't matter much any more.
There are certain sites which continue to host/advocate vb6 code. VB6 support will be completely dropped after Windows 7.
So the main difference is that VB6 is a slower, (becoming unsupported), proprietary language that is easier to learn for programming beginners. C++ is a standardized, supported language that's quite a bit harder to learn, though its faster/more efficient.
For starters, I'd recommend a Basic dialect, be it Microsoft Small Basic (this is a newb's language), VB.net, FreeBasic, RealBasic, Auto-it or maybe even PowerBasic.
Hope this helps.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I want to go into native c++ programming after University, but it seems like languages that compile with JIT (like .Net) are overtaking c++. What does the future hold for Native code?
C++ is the seventh programming language I have been professionally paid to program in, and I'm sure won't be the last. My advice is not to think of yourself as a specific language programmer. Even if JIT takes over the world, it has to get down to native machine code eventually, and someone has to write that software.
There are a lot of opportunities to work on natively compiled C++ code. It's especially popular (along with C) in non-PC environments such as embedded and real time environments, and in a lot of situations where there is some level of safety certification required.
Game programming, where performance is usually critical, is another area where C++ is very popular.
It is less popular than it was in traditional 'desktop' applications and web service applications although you can find native code projects in both these areas - especially the former - if you hunt around.
I'm not sure what you mean when you say that you will be "going into native C++ after college". Your career will not be defined by what languages you know, it will be defined by what you can do with those languages.
However, C++ is used widely in many applications. I work in systems and we use C++ for everything. .NET isn't an option in my world, but the guys doing the GIU's next door use it for everything. It comes down to what you want to do with your career. The language you use will come naturally, you are thinking about it backwards.
There will always be a place for C/C++
Any application that needs to be as
fast as possible will be written in
a native language like C/C++
Any application that runs on a device that has limited memory
will
run better in C/C++ since memory
management is more deterministic.
Operating systems will continue to be written in C. That
include
device drivers.
Up until recently one always had the luxury of speeding an application up by using better hardware. Will Moore's law being stretched to the limit, chances are the performance improvements will have to come from software. Chances are that languages that give better performance will come into their own in this regard.
If you go desktop C++ is still the way to go especially if you want to be cross platform.
Java GUI Libraries are way to slow and .NET is not portable (the GUI part).
But C++ is a language beast, the only language where i can understand managers to ask for 5 years experience.
In the server world the VM/JIT has so many advantages that only basic infrastructure is coded native. If this is the industry you want to join learn (infrastructure) or don't learn (applications) C++.
Its also pretty popular in embedded programming where you can't fire up a hundert MB virtual machine.
Since C/C++ is the only fast imperative native programming language left in mainstream you should learn at least the basics.
Yes, of course it is:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://langpop.com/
And some of the great features like rvalue-references, variadic templates, uniform initializations, lambdas, unrestricted unions, thread-local storage, extern templates and ... yet keeps C++ to be a good choice for 20 years of the future, until the C++ committee decides to publish another new standard for the other remaining years (like a do...while!) (:
Note that the computers needs native programs to run! Java, .NET, python and ... needs native environment to run on it! so, native programs are the base of softwares.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
C++ was the first programming language I really got into, but the majority of my work on it was academic or for game programming. Most of the programming jobs where I live require Java or .NET programmers and I have a fairly good idea of what technologies they require aside from the basic language. For example, a Java programmer might be required to know EJB, Servlets, Hibernate, Spring, and other technologies, libraries, and frameworks.
I'm not sure about C++, however. In real life situations, for general business programming, what are C++ programmers required to know beyond the language features? Stuff like Win32 API, certain libraries, frameworks, technologies, tools, etc.
Edit: I was thinking of the standard library as well when I said basic language, sorry if it was wrong or not clear. I was wondering if there are any more specific domain requirements similar to all the technologies Java or .NET programmers might be required to learn as apposed to what C++ programmers need to know in general. I do agree that the standard library and Boost are essential, but is there anything beyond that or is it different for every company/project/domain?
As for every language, I believe there are three interconnected levels of knowledge :
Master your language. Every programmer should (do what it takes to) master the syntax. Good references to achieve this are :
The C++ Programming Language by Bjarne Stroustrup.
Effective C++ series by Scott Meyers.
Know your libraries extensively.
STL is definitely a must as it has been included in the C++ Standard Library, so knowing it is very close to point 1 : you have to master it.
Knowing boost can be very interesting, as a multi-platform and generic library.
Know the libraries you are supposed to work with, whether it is Win32 API, OCCI, XPCOM or UNO (just a few examples here). No need to know a database library if you develop purely graphic components...
Develop your knowledge of patterns. Cannot avoid Design Patterns: Elements of Reusable Object-Oriented Software here...
So, my answer to your updated question would be : know your language, know your platform, know your domain. I think there is enough work by itself here, especially in C++. It's an evergoing work that should never be overlooked.
C++ developer have to grok std and boost libraries.
List of other technologies largely depends on project type. For sure you will have some interaction with SO, so you will need to know API of your environment.
As for data-access and other stuffs there are tons for different solutions. C++ is much richer than some managed langs in that sense. 99% of old popular systems have C/C++ interface.
After you clarified your question a bit in the comment to my answer I can recommend:
Good code browser (SourceInsight or Understand For C++ for example)
Static analysis tools (Link, KlockWork Inforce, etc.)
MySQL\SQLite (I encountered these DB in a huge number of C++ projects)
UI technologies (OpenGL\GLUT, DirectX, GDI, Qt, etc)
technologies you should know as a C++ programmer (and therefore more technically knowledgeable than lesser programmers ;) ):
performance issues - what makes things go slow, how to find and fix such issues. I also mean stuff like context switching, cache lines, optimised searches, memory usage and constraints, and similar stuff that your average VB/C# developer doesn't care about.
threading issues - how to get the most from a multi-threaded app, how to detect and fix abuses of the same.
low-level communications - especially being able to connect to obscure systems that no-one else has written a toolkit for (especially radio comms), latency and bandwidth management.
Otherwise, for specific tools - it depends on what you're targeting, Windows dev will be different to Linux, different to embedded.
This will largely depend on the used platform and other constraints. As a general rule, a good (C++) programmer is (or should be) able to learn a platform-specific API in a very short time. For C++, it's much more important to understand the different tool chains (e.g. a Windows programmer should also know the GCC tool chain) and differences in compilers. Programmer should also understand limitations and platform-dependend behaviour of the language.
As for libraries, C++ programmers absolutely need to know STL and Boost. No discussion.
Standard Template Library
http://en.wikipedia.org/wiki/Standard_Template_Library
Besides the stuff everyone listed, keep in mind that C++ programmer have space on the embedded systems market (much more than most other high level languages).So familiarity with embedded systems and development may open a lot of doors and job opportunities where you will not be competing so heavily with Java development for example. So learning to code compact code (compact after compiled) and low memory usage techniques is a good bet.
if you're using gcc you should definitely know gdb. Actually, you should be proficient with the local debugger for whichever compiler you're using. Other than that there is such a wide range of libraries used that being able to quickly pick up an API is more useful than any specific one. I would suggest learning doxygen though.
If you are using linux then Valgrind is a very usefull tool for checking how your program deals with memory access.
In no specific order
COM/ATL
DirectX
MFC & Win32
STL
GDI
BOOST
The popular way to use C++ in the mobile space would involve learning Symbian OS development.
http://developer.symbian.com