• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Storyyeller

why is C++ not commonly used in low level code?

68 posts in this topic

One thing I've wondered about is why C is so much more common than C++ in low level code. Even without exceptions and RTTI, C++ as a lot of useful features, and it is nearly a complete superset of C as well. The only explanation I can think of is the lack of name mangling and desire for simplicity. However, this is kind of defeated by relying on complicated macro tricks which just imitate C++ features in a less readable way.
0

Share this post


Link to post
Share on other sites
For embedded devices, one of the biggest reasons is size/simplicity. I don't mean developer simplicity, I mean runtime simplicity. WIth ulta constrained resources, implementing the C runtime is a lot "lighter". Also, frankly, C is far simpiler to implement, just compare the size of the language specs.



As to why it's not used in Linux, thats cause Linus doesn't like C++.
2

Share this post


Link to post
Share on other sites
It has a tendency to be a little less predictable in things like memory allocations, object sizes and what it's copying where.

People who are working (say) inside the Linux kernel need that little bit extra control over exactly what's happening.
0

Share this post


Link to post
Share on other sites
First, let's get our terms correct. There is only one "low level" language: assembly. The reason this isn't widely used in application development should be clear by simply looking at some example code. I am a fan of Assymbly, but I realize that it is impractical for application development.

C is a mid-level language that is capable of compiling to as near to the size and execution speed of an Assembly executable as possible with non-low-level coding. On a system level, the object orientation of C++ is just a naming trick, but it does allow more abstraction in source. More abstraction means more reliance on libraries and language than the compiler. This means that an amount of the binary included in the executable is completely unnecessary. Now, before people get their hackles up of this, let me explain: if a function included in a program was written to handle dozens of different situations and you only ever use that function for a single situation, you have un-used code and a procedure that is more broad in scope and size than you actually need.

The modern idea is that memory is cheap and processors are fast. Linux does not, by and large, abide by this idea. Thus I refer to the posts above mine by Katie.
1

Share this post


Link to post
Share on other sites
Correct the main reason certain things are coded in C instead of C++ is for that fine grained control over computationally expensive tasks as well as to limit memory footprints. Some examples of these are embeded devices, kernel's for an OS, and even 90% of the Version control systems people use everyday. An example of a VCS written in C++ is monotone. If you take Monotone and compare it to say mercurial you will notices mercurial blows monotone out of the water in speed and efficiency and it is easier to maintain. For those that don't know the core of mercurial is actually coded in C the python interacts with the parts of the core that are in C. Certain things are also easier to express and maintain in a language like C as well. I would hate to look at the linux kernel if it was written in C++ and used OOP it would be a maintenance nightmare.

The ultimate point here is that each language is good at certain tasks. I am currently using C for my project because it is the proper tool for the job and I happen to really like the language and I am very comfortable in using it. If I was making a game I would use C++ or some other language because those languages cater better for that type of programming. Learn to be flexible don't worry why something is not used. If it is not used it comes down to 2 simple answers 1. it was not right for the job or 2 the main developer is more comfortable with said language.

To the OP also check out my latest blog post it actually develops an algorithm in C++ and then C and explains why the C is actually more efficient.

Edit: Note C is very tiny and easy to port to different architectures. The runtime is exceptionally smaller then the C++ runtime as well. C is always ported first to a new architecture because you technically can't port C++ until C is ported over. Sure C++ has great features but with those features come overhead that can't be present under certain circumstances.
-1

Share this post


Link to post
Share on other sites
Just as a side note, it seems these days that C++ is starting to be the "low level" you are referring to, since most things are moving towards higher level managed languages and frameworks. Game development is one of the few cases in which this trend was somehow restrained but more and more developers and studios move towards game development tools / engines (Unity, Shiva), .NET, Java, etc. From my personal point of view development speed and maintainability surpasses the performance of lower level languages (not to be confused with application performance).
0

Share this post


Link to post
Share on other sites
C typically has much less overhead than C++. In environments and applications where memory and CPU are scarce, or need to be used extremely efficiently, C tends to be used more.
There are other reasons though. The people who work on these systems are used to C, most of the existing code is already written in C, and interfacing or re-writing isn't worth the money and effort, as well as certain stigmas associated with "higher level" languages. C++ compilers weren't very good for a while, that sort of thing.

For all its faults, C is actually a very nice language, it just lacks some of the bells and whistles that newer languages have. There were computers, video games, and great applications long before Java and C# became popular, and they were pretty much all built on C.
1

Share this post


Link to post
Share on other sites
One of the central design principles of C++ is "don't pay for what you don't use", so I don't know what you are all on about "C++ overhead". C++ programmers are very adamant to the language committee that we don't want features to impact performance if they aren't used.

C++ *is* commonly used in "low level" code, and you can write operating systems with C++ just as you can with C.

Comparing a popular version control system with an unpopular one and claiming the performance difference is due to using a C++ compiler vs a C compiler is just silly.
1

Share this post


Link to post
Share on other sites
[quote name='ApochPiQ' timestamp='1310863235' post='4836205']
Wow. Lots of misinformation here.


The truth of the matter is virtually entirely historical. C was stable and well-understood [i]many[/i] years before C++, and enjoyed a lot of widespread usage in the Unix world in particular. C was entrenched before C++ was even invented; given that it took a couple of [i]decades[/i] for C++ to become a language that was worth writing an OS (or whatever) in, it shouldn't be surprising at all that C remained king for that period. C++ has only very recently (i.e. since 2003 or so) had good enough specifications and tools to actually be competitive with C in the truly low-level space, because low-level stuff requires hitting corner cases of the C++ language that [i]most[/i] applications never have to worry about. In essence, C++ wasn't ready for prime time until a few years ago [i]as far as extremely efficient low-level code is concerned.[/i]
[i]
[/i]
Now, given that, it should be obvious why C is still only slowly being supplanted: because C had decades to take root. Porting code is fucking expensive and difficult, especially when you're talking about, oh, say, an OS kernel. It's a no-brainer to retain a well-refined language like C over switching to C++ and risking a huge code rewrite [i]and[/i] possibly running into areas where the tools are still weak. This is especially true on hardware where C++ compilers are still archaic and half-broken.

By historical accident, some people (like Linus Torvalds) became incomprehensibly, irrationally opposed to using C++ [i]ever[/i], and so even fewer people have an interest in bucking the trend and switching away from C.

Of course, by now, if you want to invest the effort to get away from C, then there's far better options out there than the shit-show that is C++. Consider projects like Singularity that aim to use much better languages for OS implementation, for instance.
[/quote]


Say what you will, everything I said is still fact:


1- C is used in embedded systems because it is ( as a system ) small and easier to implement, and has a lesser footprint, especially when you are talking megabytes of available RAM.

2- C is not used in Linux because Linus hates it.



No misinformation in either regard.



I have worked, and have friends that continue to work on embedded systems, and C is still the reigning champ. This is because implementing C ( and it's tool chain ) is a hell of a lot easier than C++, and has a smaller footprint, while at the same time, the code complexity of embeded systems is generally quite small, so what C++ brings to the table really isn't required. [url="http://en.wikipedia.org/wiki/Small-C"]Small-C[/url] is probably as guilty for the continued success of C in embeded systems as any other factor, as it was the learning basis for so many people regarding compiler development.
0

Share this post


Link to post
Share on other sites
Why so defensive? I obviously didn't contradict or attempt to dispute anything you said, and I never claimed I was addressing you anyways...
1

Share this post


Link to post
Share on other sites
Imagine how pissed Linus is going to be when he hears about Java.

==EDIT==
A good (short) read. (Linus ranting off his rocker)
[url="http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918"]http://thread.gmane....643/focus=57918[/url]
1

Share this post


Link to post
Share on other sites
[quote name='Serapth' timestamp='1310864333' post='4836210']
1- C is used in embedded systems because it is ( as a system ) small and easier to implement, and has a lesser footprint, especially when you are talking megabytes of available RAM.
[/quote]


There's no reason to use C over C++, even in embedded systems, except for legacy support. All compilers that target embedded systems allow you to turn off exceptions and RTTI, etc. If you don't use a feature, you don't pay for it. But there's no reason to use C and paint yourself in a corner if you end up needing a feature found in C++ that C doesn't have.


This perspective is coming from someone who does embedded development for a living. I've worked with DSPs (TI C64x+), microprocessors (MSP430), and FPGA softcores (Xilinx MicroBlaze) all within the past 3 months. Guess what? All of the applications were written in C++. Even on the MSP430 that ran at 16MHz and had 4kBytes of RAM.
0

Share this post


Link to post
Share on other sites
[quote]why is C++ not commonly used in low level code?[sup][citation needed][/sup][/quote]This whole thread is based on a large assumption...
As mentioned above, this assumption is true for the Linux kernel. However, it's not true for many other areas.

The vast majority of game middleware systems that I've worked with ([i]which are all very "low-level code"[/i]) have been written in C++ ([i]albeit usually not in the ivory-tower OOP style associated with [url="http://macton.smugmug.com/gallery/8936708_T6zQX#593426709_ZX4pZ"]typical C++[/url][/i]).
2

Share this post


Link to post
Share on other sites
[quote name='jamesleighe' timestamp='1310881588' post='4836258']
Imagine how pissed Linus is going to be when he hears about Java.

==EDIT==
A good (short) read. (Linus ranting off his rocker)
[url="http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918"]http://thread.gmane....643/focus=57918[/url]
[/quote]

Haha that post is funny and very arrogant even for Linus. This is actually because you quoted the wrong post. If you actually read his other posts they are more sane and less of a rant.
Either way Linus is a very smart man, however, his opinions should be taken with a grain of salt because they are borderline insane. The better post from that whole exchange is this one.
[url="http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57918"]More Sane reply[/url]. But really please lets not use Linus as a definition of a good read especially if he is ranting.


I also agree with Hodgman above. As I stated it is not that C++ can't be used for low level tasks it is just that C is better for certain low level tasks. For instance on an android or ios device ASM and C are used to bootstrap the operating systems and in androids case it's virtual machine (which I believe is also written in C). But the rest of android is a custom Java byte compile and in IOS the typical language is Objective-C which is literally an extension on top of C unlike C++ which is more of it's own beast at this point. In the future it also looks like the guys at apple are going to move people towards using Ruby instead anyway due to the massive Ruby -> objective C compiler they are working on.
The point is C is good for some tasks, Java for others, and C++ for some more. So people need to stop dwelling on this stuff and just use what they want to use.
A language is nothing more then a tool for a job people need to stop arguing what is better.
1

Share this post


Link to post
Share on other sites
[quote name='Serapth' timestamp='1310864333' post='4836210']
1- C is used in embedded systems because it is ( as a system ) small and easier to implement, and has a lesser footprint, especially when you are talking megabytes of available RAM.

...

I have worked, and have friends that continue to work on embedded systems, and C is still the reigning champ. This is because implementing C ( and it's tool chain ) is a hell of a lot easier than C++, and has a smaller footprint, while at the same time, the code complexity of embeded systems is generally quite small, so what C++ brings to the table really isn't required.
[/quote]

Nowadays, I do a lot of embedded systems work, mostly on the PIC24 line of 16bit microcontrollers and I use a mix of C and assembly. While I'm certain that for a lot of people your points are true, they certainly do not aply to everyone: the reason I use C over C++ is not for any of the reasons you gave (except perhaps the C compilers are easier to implement, in an indirect way), but rather that of availability. There are good C compilers available for PIC24's, but I have yet to find a good C++ compiler (or any other langauge I know). If there was a good C++ compiler, I would use that instead. The lack of availability of other language compilers could be down to a number of reasons including historical reasons and the fact that C compilers are easier to implement.

This doesn't invalidate what you said at all, but rather brings up another reason: availability.
1

Share this post


Link to post
Share on other sites
[quote name='Aardvajk' timestamp='1310851128' post='4836148']
Meh. There is no real reason that any given compilable language should result in different final executable code than any other. The features of C++ that add to the generated code should optional and either only included if used or removable with compiler switches. However, this does not automatically mean that such an "ideal" compiler exists for a given platform.

Everything C++ does with memory is entirely predictable in the hands of someone who understands the language. Anything C++ does automatically behind the scenes that you [i]actually need[/i] would just have to be manually implemented in C, say. Oh teh noes, templates cause code bloat, far better than I should manually write three versions of the same function. Etc etc.

C is older, more compilers exist, more low-level-domain programmers learned that way. I suspect that if it is indeed more commonly used for "low-level" programming, whatever that may mean, it is more a cultural than technological choice or due to availability of battle-tested compilers for a given platform.
[/quote]That's pretty much the truth, the whole truth, and nothing but the truth, right there. Absolutely couldn't agree more!

FYI: At the place I work, embedded programming is approximately 10% asm, 40% C and 50% C++
2

Share this post


Link to post
Share on other sites
Yes [i]technically[/i] there are few reasons why C++ code should become a bigger binary compared to C code. For the most part, C++ degrades to a procedural program at the lowest level anyway. Methods become procedures that pass around the [i]this[/i] pointer of a class in a similar way as you'd pass around a struct pointer in C. As for virtual methods and polymorphism, they are a collection function pointers, which is nothing overly exotic in C land either. I suppose one big overhead in C++ is probably exception handling. Exceptions are generally considered expensive on embedded devices, but you can avoid using exceptions if when required. I also have to agree with dublindan, choice comes often down to the quality of the tools for your chosen embedded platform, and C often wins in that respect.
0

Share this post


Link to post
Share on other sites
Would love to see a fight between Linus Torvalds and Alex Stepanov. I think they'd each lose an eye before working out that they agree OO is the root of all evil.
0

Share this post


Link to post
Share on other sites
[quote name='mrbastard' timestamp='1310991684' post='4836770']
before working out that they agree OO is the root of all evil.
[/quote]

Then two people would be wrong, yay!

There is nothing wrong with OO [b]done correctly[/b], the 'problem' is the lack of design skills, critial thinking and correctly applying paradigms to solve a problem.

The problem is most people don't have those skills but then again chances are they would write bad code in any paradigm if left to their own devices...
2

Share this post


Link to post
Share on other sites
[quote name='phantom' timestamp='1310992060' post='4836772']
There is nothing wrong with OO [b]done correctly[/b], the 'problem' is the lack of design skills, critial thinking and correctly applying paradigms to solve a problem.

The problem is most people don't have those skills but then again chances are they would write bad code in any paradigm if left to their own devices...
[/quote]

Oh, I agree. I've just always found it funny that many c programmer's arguments against c++ revolve around inheritance, when the guy who designed the STL has pretty much the same opinion! [img]http://public.gamedev.net/public/style_emoticons/default/biggrin.gif[/img] I'd very much enjoy watching Stepanov and Torvalds direct their arguments at one another in some kind of forum trollocalypse.

In the linked rant (in between attempts at trolling) Torvalds says similar to what you say about lack of skills. Stepanov, for all his hatred of OO, presumeably likes that in c++ you can have a function [i]object[/i] whose operator() can be inlined, unlike a c function ptr. So he doesn't mind objects, just OO...... [img]http://public.gamedev.net/public/style_emoticons/default/blink.gif[/img]

Personally, I think the problem is that '[b]OO done correctly[/b]' means different things in different languages and different problem spaces, which has lead to people having the skills and wanting to apply them, but applying them wrongly for c++ in performance-critical situations. There's a wealth of OO design wisdom out there, and while most of it can be applied to c++ design, not all of it should have been. For example, classical OO literature revolves around using inheritance for polymorphism, which is not always the best way to go in c++ where we have lovely compile-time polymorphism.

(insert obligatory comment about OO being possible in c and the OO argument therefore being irrelevant to this thread anyway - if I didn't someone else would!)
1

Share this post


Link to post
Share on other sites
This opinion that C is 'better than' C++ for various problem domains is rampant in the open source community.
Before making my way back to game development i spent many years writing an irc daemon (ircd). I was often beset with idiots telling me that because i had chosen to write such a program in C++, it simply would not scale, would take all available RAM in the server, that inheritence would make it slow, and other quite frankly stupid arguments.

Needless to say most of these people did not believe that you should choose the [b]right tool for the job[/b]. In this particular case, the right tool for the right job, based on my skillsets and the requirements of the application, were C++.

If i was to approach the same problem again today maybe i would not choose C++, but i definitely still would not choose C.
0

Share this post


Link to post
Share on other sites
The answer is extremely simple. Three points.
1) Portability. C is the most portable language out there.
2) Simplicity. Most low level code does not require C++ features.
3) Efficiency. C code is often both faster and smaller than C++ code. There's a reason why there are no interesting 1k/4k demos written in C++, because it is shit for size optimized code. :)
The interesting question would be "Why should anyone use C++ in low level code?". :)
Note that with C++ code I actually mean proper OO+exceptions+templates kind of code. Sure, you can write pure C and compile it with C++ compiler and claim that "Oh but it IS valid C++!" but it defeats the whole purpose of the discussion.

[quote name='braindigitalis' timestamp='1311002954' post='4836838']
This opinion that C is 'better than' C++ for various problem domains is rampant in the open source community.
Before making my way back to game development i spent many years writing an irc daemon (ircd). I was often beset with idiots telling me that because i had chosen to write such a program in C++, it simply would not scale, would take all available RAM in the server, that inheritence would make it slow, and other quite frankly stupid arguments.

Needless to say most of these people did not believe that you should choose the [b]right tool for the job[/b]. In this particular case, the right tool for the right job, based on my skillsets and the requirements of the application, were C++.

If i was to approach the same problem again today maybe i would not choose C++, but i definitely still would not choose C.
[/quote]

This is because you don't care about portability. You only wanted your ircd run on your own system.

I myself write code which has to run from routers to super computers, so anything except C is a definite no-go for me, because the code HAS to compile on those machines which run operating systems and CPU and hardware architectures unknown to me. Everything I care about is conforming to C89, POSIX and SUS(Single Unix Specification) standards.


0

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  
Followers 0