Fog Creek Software
Discussion Board

Python with C or C++?

No, not a language war - chill :D

Rather, I have a question. I am presently taking up learning Python for my own edification (I'm not a professional programmer, and don't plan on being one - though I might at some point be a project manager), and after I would like to learn C or C++ - however, I really don't understand at all how they are different.

So as the value of a tool is relative to what you wish to use it for, here is what my desire to do is:

I primarily want to learn Python for client-side programming, for use in quickly building a variety of applications (preferably that run fine on as many platforms as possible), but primarily for use with games. As such I would very much like to learn languages which are more suited for GUI client-side programming than Java is (I presently already know Java and PHP, and in Java I just find it...well, not really designed for what I want to do with it, as evidenced by the attrociousness of Swing/AWT), and be sufficiently speedy for such applications.

C/C++ obviously suggests itself, but from what I have learned of Python one can merely do the majority of the work and prototyping there, then simply rewrite code which is not sufficiently speedy - or which Python doesn't/can't do as well as C/C++ - in C/C++ without much of a problem.

So the only question is...I don't really understand what the difference is in C and C++. I know that both Python and PHP are written in C, and most games are written in C++, and most cross-platform programs it seems are written in C...but I just don't know why. Apparently a big part of C++'s features are not multi-platform compatible (templates?)?

Would someone care to enlighten me to the nuances, and the ways in which one or the other is lacking or outstanding? Is there any reason I'd actually want to spend any time learning C instead of/along with C++?

Also, have any of you done work using the C/C++ with Python combination? How did you like it, and do you think the project was better for having used both - aside from the natural problems of working with 2 different languages, anyway?

How in general do you like working in a higher level language, and only dropping down to a lower level to do some things that aren't done as well in the higher level language? 

Brian Hall
Saturday, March 1, 2003

On the distinction between C and C++: a good highly technical overview is Stroustroup's Annotated C++ Reference Guide.

C++ is C with object oriented features added - the whole notion of classes, for instance. A C++ class is actually derived (intellectually speaking) from the C 'struct' which is the record structure. If you know C++ you automatically know C, at least as far as nuts and bolts goes.

The main difference between C++ and some other object oriented languages is that C++ is "bound" at compile time. C++ was designed to have no appreciable overhead in terms of run time efficiency, beyond  the extra indirection of virtual methods. You can't decide to call a method by a name only known at run time in C++, for instance.

>> How in general do you like working in a higher level language, and only dropping down to a lower level to do some things that aren't done as well in the higher level language?

I personally don't. Calling one language's procedures from another is tedious monkey work because you generally have to establish a calling prototype in the language you call from. This can add a lot of time and effort to a project if the quantity of such calls is widespread, unless you have automated tools to create the declarations or proxies in the calling language.

This is why I have gravitated to Delphi. It is a true compiled language with the efficiency of C++ and allows you to create new components compatible with the Delphi forms designer in the same language that the applications are written in. With Delphi there is little hassle involved in writing extension components or inheriting and modifying the base behavior of existing classes.

(I expect someone with a huge chip on their shoulder to come out of the woodwork and disparage each and every thing I've stated... talking about C++ and other languages is like that... let the flames begin... LOL)

Bored Bystander
Saturday, March 1, 2003

If you intend to code a game then you will want to learn C/C++.  The reason(s) for this are:

1. DirectX and OpenGL, the two most popular game graphics platforms, are C/C++ libraries.
2. C/C++ are systems languages.  The system you code your game on will likely have been written in C/C++ and assembly.  Thus coding your game in the native environment will be easier.
3. Depending on your chosen game platform, you will most likely only have C/C++ as an option.  Especially for console games.
4. IMO C/C++ are elegant languages and, when coding games, you'll need this elegance to work some of the problems you will encounter. (Don't take elegance to mean bad coding practices.)
5. Although possible, interfacing another language with native C/C++ code is a hassle if you're not familiar with things like calling conventions, stack frames, data type conversion etc.
6. As far as learning C versus C++, I would say get a good book on C++.  As mentioned C++ includes C. No pun intended.  Be aware though, learning C and C++ is (somtimes) easy on the surface, but knowing what is happening behind the scenes takes experience.

Saturday, March 1, 2003

Is jumping straight into C++ with the ARM really the way to go? Is there someone who actually started out programming this way?

Seems tough - the ARM is a tough read. And C++ is full of ... subtleties. (Effective C++ by Meyers is where to get started finding out about these subtelties.)

I use C and C++ (have never coded in C/C++ as that's not a language) a lot I see them as two very different things that require very different approaches, even though they share many things.

Anyway the comments about libraries are true - most libraries are going to require access through C or C++.

To learn C, I always recommend the K&R as it is a tutorial. But then don't miss "C Traps and Pitfalls" and "Deep C Secrets" to get the full mastery of C.

Once you feel good with C, start in on C++ if you like. I suggest a wary approach, cautiously adopting just a little C++ at a time and adding to it. Designing your own template library, for example, is pretty hard core and should not be attempted right off. As is weaving in exceptions into everything you do.

Dennis Atkins
Saturday, March 1, 2003

>> "have never coded in C/C++ as that's not a language"

Dennis,  I'm sure an intelligent man such as yourself could deduce that the poster meant C and/or C++ and was using the / as shorthand notation.  Then again some of the most intelligent men do lack common sense.

Saturday, March 1, 2003


I believe it was Stroustroup himself who made the point that "C/C++" is not a language in some recent articles he wrote on the work to reunify C & C++. Many people do believe that "C/C++" is a language and list it on their resumes as such.

Dennis Atkins
Saturday, March 1, 2003

And wouldja look at this I even found the dang quote thanks to the miracle of google:

>Modern C [1, 2] and C++ [3] are sibling languages [4, 5] descended from Classic C [6]. In many people’s minds, they are (wrongly, but understandably) fused into the mythical C/C++ programming language. There is no C/C++ language, but there is a C/C++ community. In last month’s CUJ, I described some of the incompatibilities that complicate the work of developers within that C/C++ community. In this article, I’ll discuss some of the underlying myths that help perpetuate these incompatibilities. I’ll also show why more compatibility (ideally, full compatibility) is in the best interest of the C/C++ community. Next month, I’ll present some examples of how the incompatibilities in C and C++ might be resolved.

Heh heh. It's an insider thing. You'd know about this if you were down with C++. :-P

Dennis Atkins
Saturday, March 1, 2003

Oh and Brian, read that article for a great overview of some of the big issues.

Dennis Atkins
Saturday, March 1, 2003

>> "I believe it was Stroustroup himself who made the point that "C/C++" is not a language in some recent articles he wrote on the work to reunify C & C++. Many people do believe that "C/C++" is a language and list it on their resumes as such."

Stroustroup appears to be a nitpicker who needs a life.

Anyone who lists "C/C++" on their resume and believes that the term is a language, is a liar.  Then again a lot of people seem to lie on their resumes now-a-days.

A little common sense goes a long way.  If a person can't look at "C/C++" and read it as "C and/or C++" then they must be a self-righteous perfectionist.

Saturday, March 1, 2003

Yup, I missed a few things:

DEFINITELY learn "Modern" C at least. C is the lowest common denominator for almost all programming libraries and APIs. I agree and I didn't mention this and it didn't occur to me when I posted earlier. (I am assuming that Modern C means classic K&R C with optional, not mandatory function prototypes and a few other modern constructs? Classic K&R C was an almost typeless junk language... oh boy, let the flames begin NOW... heh)
The ARM is a reference book. Using it to learn C++ would be like using a dictionary to learn English (well, almost.) I mentioned it as a "root document" that, in theory, you could use as a reference to the scope and major features of the C++ language.

I've read Scott Meyer's Effective C++ and it's a short, insightful, conversational book with a lot of great examples of OOP nuance applied to C++. I'm not certain that it's a good first book on C++ because it assumes that you kind of know the syntax and the reason for things in C++. Effective C++ is a great read for someone who understands C++ nuts and bolts and wants to understand why and where to use language features in real projects.
Also agreed that bitching about C/C++ as an proper noun denoting a language is the height of anality. Anyone but a technical recruiter knows what the phrase is intended to  mean.

Bored Bystander
Saturday, March 1, 2003

Stroustrop advises learning C++ first BUT learning the C-like part of C++ that is used for procedural programming:

I think his advise is similar but better than mine to just learn C first. I also agree with what he is saying that tackling classes an inheritance after learning the procedural core makes sense.


I agree that Effective C++ is an intermediate level book, but once you know the procedural core and the basic syntax of classes and inheritence, you should get the book and start trying to understand it since it condenses the gist years of hard won best practices and outlines traps and pitfalls in C++ usage.

If you think you are competant in C, Effective C++ is the standard by which to judge yourself.

If you think you are an guru/expert, Sutter's Exceptional C++ books might be the standard to check. Many things in there are  way too high level for me and essentially show that C++ is far too convoluted and complex and filled with bizarre unexpected behavior for mere mortals to master. It's the language we love to hate.


Yeah, Bjorne's being an anal blowhard. And yet, it's kind of a funny insider thing.  I have noticed that after his article came out, I started to see "C,C++" appear on resumes instead of "C/C++". These comma people are folks that had read the article and proved to keep up with all the subtleties of C++.  But... like whatever, dudes!

Dennis Atkins
Saturday, March 1, 2003


Right - when I said K&R I meant the 2nd ed., which is ANSI C, which differs from Standard C. I think the early C that is the essentially typeless language you are thinking of is B. Standard C has types. The latest and greatest now is C99, which is ANSI C with some useful extensions and a couple frivolous ones. One obvious and useful part of C99 is to admit that line-comments (//) are part of C since every modern compiler accepts them in C already.

Dennis Atkins
Saturday, March 1, 2003

In my experience, anybody with C/C++ on their resume doesn't know either (the code they generate cannot be compiled with a C compiler, but the code derives very little benefit from the overhead that C++ brings to the table).  C++, in particular, is HARD.

Best C++ intro book is Koenig _Accelerated C++_.  It's probably the best starting point after you've been coding in python for a while.  After that, if you still think C++ is a good idea, pick up Meyers I.

There are efforts for easing the interaction between Python and C++; see the folks over at  I'm not aware of a similar effort for C.

As a professional programmer, my advice... well, all learning is good, so if these big rocks look interesting, by all means go ahead.  But I bet there are better uses for your time.  Python rocks.

Another idea: Pick up the Abrash Graphics Black Book.  Because (1) if you really cared about speed, you'd write it in assembler anyway ;-) (2) it will teach you about a lot of optimizations available without changing your implementation language.

Sunday, March 2, 2003

>>  I think the early C that is the essentially typeless language you are thinking of is B. Standard C has types.

C in the pre-function prototype days let you do weird things with no complaint, like use ints in place of pointers. Yes, K&R C had types so to speak but they were so non-enforced that you might as well have had no types, just int assumed for everything that wasn't a struct.
BTW, is lint still around? Do people still use it?

Bored Bystander
Sunday, March 2, 2003

Lint is still around. It is available at Programmers Paradise I think.  Remember the adds that would give a code example then they would ask you to figure out why the code broke?  Do I use it?  I would if I could.

Sunday, March 2, 2003

>> "if you really cared about speed, you'd write it in assembler anyway ;-)"

Not a true statement.

Bic Pen
Sunday, March 2, 2003

Firstly, It's good to see more people take up a higher level (more productive) language.

Secondly, C++ is extremely complex, to learn the entire language. In comparison, C is quite simple.

I advise you learn C (everyone should know C), and only C++ if it is required.

John Moore
Sunday, March 2, 2003

People who put "C/C++" on their resumes are probably doing it for the benefit of recruitment agents (who don't understand that knowledge of C++ implies knowledge of C).

Andrew Reid
Sunday, March 2, 2003

If you really want to produced games, with 2D it looks that there's few learning curve as patient as Flash 5 and 6. With a web service behind the Flash applet, you can get a lot of online gaming concepts implemented.

Li-fan Chen
Sunday, March 2, 2003

Someone mentioned Koenig's book. "Accelerated C++" is an excellent way to learn the subset language I think of as "broken c++".. (like broken english).

Basically it will show you enough C++ to get around and do your work in most day to day small applications. From there you just have to figure out an environment like Visual C++ 6.0 or GNU C++ to get around. There will be days you wish you had a 12 years C vet around to help you around a serious problem.. but most of the time you'll make do with this and a few other books.

Li-fan Chen
Sunday, March 2, 2003

learn C then C++

and use this

python is a very popular language for game logic with C or C++ where speed is need for rendering etc.

pyugame uses SDL ,, which is written in C but works great with C++, just like python.

Sunday, March 2, 2003

There is never any shortage of silly, self righteous flame wars going on in the C++ newsgroups. It can be quite entertaining to watch. I don't know what it is about C++ that attracts so many anally retentive types.

If you can look past the pompous airbags that are scattered throughout the C++ landscape, you'll find it's a great language that is suited for a wide range of tasks.

I haven't read the entire "Effective C++" but from what I've read so far, it seems to be a great book.

(And since you mentioned game programming....You will find that virtually all serious game programming is done in either C or C++.  I've got some friends that work in that industry and those guys *know* C++. Memory management and performance are king in game programming, so those folks have to know the internals quite well.)

Go Linux Go!
Monday, March 3, 2003

Back to the original question, I would say that it depend on the size of the game you want to write.

If you want to have fun and write a game with the complexity of tetris, frozen bobble and all the nice little games like that (including all the games for old computers amiga, msx, atari and such) go for python.

If you want to write the next quake and ultima online, then you need to learn deeply C and C++. And assembly for many things. And operating system prgramming. And understand very well your hardware. And you will need lisp at some point, or at least ML programming.

I suggest to start with python and pygame and move to C/C++ when you want to achieve something more massive or serious. If you are sure you want to get into the field of game programmin, learn both anyway, you will need them.

PHilippe Fremy
Monday, March 3, 2003

One package I didn't see anyone mention is SWIG ( ) . This removes most of the drudgery involved in connecting C , C++ and Python (or Tcl, Perl, Java and Ruby). Another alternative is the Boost::Python library already mentioned.

However if you're just getting started with programming I don't really recommend mixing languages within one program - it gets pretty complicated pretty quickly.

Where I see the value of mixed language programming is that in many large applications there's a library screaming to get out. Giving programmatic access to this library allows your software to be used in ways you never thought possible. It also forces you to make the interfaces simple, clean and opaque, with simple ownership semantics - otherwise wrapping the interface becomes a nightmare.

Monday, March 3, 2003

To return to Brian's original question. I would personally suggest that becoming fluent in Python is a very good starting point for learning to program well. As a language it is clean, succinct and powerful and encourages one to get to grips with object oriented programming in a way that neither C nor C++ does. Although I have no experience of writing games, I believe that there is a strong community using Python for this purpose and at least one tool kit available to (simplify?) matters.

Having mastered Python the move to a 'lower level' language is likely to be easier. To prevent a flame war I will qualify 'lower level' as meaning supporting introspection and supporting concepts such as lists and dictionaries via a class library rather than embedding them in the language. The risk of developing the bad habits that languages such as C and C++ let you get away with is lessened.

I can vouch for this from personal experience. At University I first learnt FORTRAN and Algol 68 (OK, that dates me!) and subsequently PL/1 (aargh!). When I moved from ICL George III and IBM TSO to Unix it took a long time to stop writing FORTRAN (et al) in C. Likewise, it wasn't until I actually encountered Smalltalk that I started to understand how to write good C++. In fact, I don't think I ever liked C++, in the early days - particularly when it was translated to C using cfront rather than being directly compiled - it always felt like a language that gave you just enough rope to hang yourself.

To conclude. Learn Python and then, if you still think you need to, tackle the others.

P.S. A university friend of mine swears by Eiffel as another clean, object oriented language.

David Roper
Tuesday, March 4, 2003

Brian, if you just want to get a relatively simple game done, then one other option to consider is Macromedia Director. Pretty much everything you need to do to handle a game is built into Director. Moving images around, playing sounds, loading graphics, mouse and keyboard interaction, timing issues, etc. It even has support for 3D graphics. Its scripting language, Lingo, is pretty fully-featured and certainly easy to learn.

Macromedia Flash might also suit you. Its scripting language is basically Javascript, and it's more suited to small, fast 2D presentations.

There have been a number of arguments in favour of C, C++, Flash/Actionscript, Python, etc. They're all good languages in the right context, but if you have no experience of game development you may find Director/Flash easier. The advantage of the Macromedia products is that they offer an integrated multimedia development environment -- you can load your graphics and sounds, write code to do stuff with them, test it out, create design-time scripts to help you with you work, etc.

You'll have to shell out to buy Director or Flash though.

Adrian Gilby
Tuesday, March 4, 2003

I second Edwin's advice to learn SWIG,
you'll get the chance to write your
data structures in C and have great
performance with such problems as Massively
multiplayer situations.. but still get to
write the none crucial rules and maintanence
game logics in Python (or any scripting
language SWIG supports--like Tcl and Perl)
You might have to write some code in C
though if these game logics need to be that
high performance...

Li-fan Chen
Tuesday, March 4, 2003

Back to the original question again... In my opinion, Python is a very good start. It is clean, object oriented, with nice data abstractions, coming with many very useful modules.

I believe that the Object Oriented Programming brings so many advantages that it you should never learn C for writing new things. When the time comes to learn C or C++, you should directly start with C++. Working with Standard C++ library (strings, lists, maps, algorithms,...) saves you many low-level nightmares.

But, C++ IS very complex language. Still, you can use it in a simple way. Then, with Python experience, it will be easier for you than the C language.

Look at the Bruce Eckels "Thinking in C++" to start with C++.

Petr Prikryl
Monday, March 17, 2003

A few points to consider.

Pyrex - a Python-like language to write high-performance extensions to Python, generates C code. Numerical snippets can get *much* faster with that. There are also many other ways to avoid C and C++ at all. You can load most C libraries into Python directly using "ctypes" or some specific binding that someone has already made - these exist for almost every known library.

Eckel's book Thinking in is the best source of learning serious C++ - however it goes far beyond the basics. But it reads very easily and warns of all dangers.

Following APIs are C-based (which means they can also be used with C++):
- Standard C library, POSIX, Windows APIs - you need these to read/write files, and use different operating system features. Note that on Windows, User interface is an OS feature, on UNIX it is not.
- OpenGL - cross platform 3D library, SDL - a perfect partner to OpenGL, provides window/fullscreen surface creation, input, and sound output, as well as 2D graphics.
- there are also tons of other C-based libraries.

C++ can make your life easier (especially post-98 C++), because it makes memory management, arrays, and some algorithms simpler to handle, Besides, it supports better organization of code (which is inherently more complex). Writing complex GUI applications with C++ is much easier than in C. Most usable GUI frameworks are written in C++, which are:
- wxWindows - a free powerful GUI ported to most platforms in a most native manner. All other cross-platform libraries listed here use emulated look, while wxWindows uses most platform-native elements.
- Qt -  similar, but commercial. Faster but might have platform inconsisitencies. Free versions also available, but you can use them in a very limited manner.
- FLTK, and diverse GTK wrappers - free, very flexible and easy to learn.

Naturally, functionality underlying these libraries is either present in the OS interface, or provided by an underlying C library, so you might get away with that. However, it gets so awkward, that i'd better not touch it.

Many Windows libraries such as DirectX use COM, which is an object-oriented representation easily usable from C++. All of these can also be accessed through C, but it is not too nice.

So, to sum it up, C++ might be tedious if you dig deep into it - but the surface of it is not much harder than C, but pays off extremely well. However, you might not need either at all.

Ilya Minkov
Monday, April 12, 2004

Delphi is easier in some cases to understand and write than Visual basic, yet visual basic is very limited. Delphi is not limited. I have seen programs written in delphi that no one has ever tried in C++ (example: a resource editor).
Kylix isn't that great though from what I've heard, so c++ or other languages are good if you plan on programming in OS's other than win32.

The fact that you can take a .pas file from one project, and nearly cut and paste it into another project and just put it in your uses clause is even more useful than the components in Delphi at times. So for example if you had made stand alone regular expression search program, and then you wanted to include regex search in a text editor you made, you'd just drop the pas file into your project, put it in the uses clause, and call the form up in the code with one line: 

In c++ or another language, I'd like to see someone drop one file into a project and call the form up with one line of code.

A lot of people say that "all" of delphi is based on RAD visual development, and that a program shouldn't be made this way, and that it's for lazy people. This is quite untrue. One can make a delphi application without ever using any of the visual components.  You can call .pas files without them even being a visual component. You can program software without ever using visual components. In fact you can make your own non-visual code, and turn them into components if you want to.

The idea with visual components is not that they restrict you.  They are an option, a way of programming, but you are not restricted to only using them and only basing your application on visual components.

Visual Basic is also written in c++, whereas delphi, is written in, yes, delphi.

I'd like someone to point me to an application in C++ that couldn't be written in delphi.  A lot of theories suggest that delphi restricts you, but there is no evidence. Once again, why is it that there have been applications written in delphi that were not done in c++ ever (example resource editors).

Remember that pascal is the language used in delphi, and pascal is a language juse like c++ is a language. That means you can use pascal without ever using a component in your life, or you can mix and match, using components, and using pascal without components.

Think of delphi just like a powerful Visual C++ with components. Imagine in Visual C++ if you could drop components onto a form, which automated all or almost all your tedious code.  When you needed to hack the automated code more directly, you could edit the source of what was done for you (in visual C++ you cannot do this-what you throw on the form is automated and it limits you in visual c++. In delphi it does not, you can edit the source)

When one wastes time initiating windows, showing
dialogs, etc. in C++, they could be spending more time on the actual code of the program that makes the program more interesting.

Jorry T
Monday, July 12, 2004

*  Recent Topics

*  Fog Creek Home