• 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

[quote name='Hodgman' timestamp='1311053625' post='4837215']
[quote name='Calmatory' timestamp='1311047148' post='4837187']
So what would your conclusion be for both C and C++? A right tool for the right task? What tasks are right for C but not C++? What tasks are right for C++ and not C?[/quote]IM[b]H[/b]O, C is the right choice if:
* you've got a team who are good C programmers but bad at C++, and you don't trust them to not write bad C++ code ([url="http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf"]pitfalls of OOP[/url] is a good example of the performance disaster that bad C++ can lead to).
* you're on a platform with a good C compiler but a bad C++ compiler.
* you really want to use some C99 feature that isn't supported in your C++ compiler for some reason.

[quote name='Calmatory' timestamp='1311051634' post='4837209']Instead of ranting, teach me. Show me. I'm asking for fourth time for someone to show how things are done correctly, and I'd appreciate it if it actually showed that C++ would be more ideal for low-level development than C. Especially for embedded systems in which resources are scarce. I'm waiting for code.[/quote]I'm not going to fix your hello-world [font="Courier New"]printf[/font] vs [font="Courier New"]cout[/font] loop, because it's just a hello-world problem and has no relation to any real problems. Does anyone even use [font="Courier New"]cout[/font], in anything but "hello world"? [img]http://public.gamedev.net/public/style_emoticons/default/tongue.gif[/img]

I'm too busy writing high-performance C++ for embedded devices to tutor you right now, but the folks at Dice have some presentations on how to not write bad C++ that you should absolutely read: [url="http://publications.dice.se/publications.asp?show_category=yes&which_category=Engineering"]http://publications....ory=Engineering[/url]. The 'Scope Stack Allocation' presentation is a particularly good gem.
You'll be happy to see that the result is very "C style" [img]http://public.gamedev.net/public/style_emoticons/default/wink.gif[/img]
[/quote]

Ironically, their latest presentation is essentially "don't use C++ features" :D
http://www.slideshare.net/DICEStudio/executable-bloat-how-it-happens-and-how-we-can-ght-it
1

Share this post


Link to post
Share on other sites
[quote name='Aardvajk' timestamp='1311065924' post='4837271']
[quote name='Calmatory' timestamp='1311057270' post='4837231']
I guess it's needless to say at this point that to make the most out of C++, it has to be very C-like, perhaps even relying on the C library rather than the C++ one?
[/quote]

Sure. All the hundreds of thousands of dollars spent funding research and development, ratifying standards and building compilers was just to be awkward. Obviously none of it was ever intended to be used in production code. [/sarcasm]

The facts are these: the domain we are discussing in this thread, very low level code written to execute with a very small memory footprint and realistically valid concerns about micro-optimisation, is highly specialised and represents a tiny, tiny subset of programming domains in general.

[/quote]

Sigh.. ...but what if this topic explicitly covers just that tiny subset of programming domains in general? :)








1

Share this post


Link to post
Share on other sites
[quote name='Calmatory' timestamp='1311067393' post='4837279']
Sigh.. ...but what if this topic explicitly covers just that tiny subset of programming domains in general? :)
[/quote]

Then I refer to the point that C++ is suitable for these subsets while providing improved type-safety and generics at no extra cost, except for programmer training.

I have no interest in arguing that X is better than Y. I am, however, happy to argue that a box of tools is better than a tool on its own. If I want my lawn cut, I'd rather employ a gardener who also owns a chainsaw just in case I suddenly decide a tree needs pruning while he is there. If not, his chainsaw can stay in the van.

Plus, to stretch the analogy to beyond breaking point, his lawnmower is less likely to electrocute my cat.
0

Share this post


Link to post
Share on other sites
But if C++ is suitable, and better by providing improved type-safety and generics at no extra cost, why isn't C++ used instead of C? That's the fundamental question behind this whole topic. :)




And not to repeat myself, but I believe it is because 1) C is more compact in terms of resource usage. 2) C is more portable, so there are more mature compilers for wider variety of platforms 3) C is simpler, easier to learn and use properly and there exists lots of good enough programmers for the job.

0

Share this post


Link to post
Share on other sites
[quote name='Calmatory' timestamp='1311067393' post='4837279']
Sigh.. ...but what if this topic explicitly covers just that tiny subset of programming domains in general? :)
[/quote]

Sigh all you want. With the same immature reasoning I could say that using ASM in C makes C less of a usable language because in some cases it was worthwhile to write inlined ASM to write performant C code. Look at the Linux kernel? You can use Google and a brain to find it.

Your broken code example was entertaining, though. :rolleyes:
1

Share this post


Link to post
Share on other sites
[quote name='SymLinked' timestamp='1311068986' post='4837291']
[quote name='Calmatory' timestamp='1311067393' post='4837279']
Sigh.. ...but what if this topic explicitly covers just that tiny subset of programming domains in general? :)
[/quote]

Sigh all you want. With the same immature reasoning I could say that using ASM in C makes C less of a usable language because in some cases it was worthwhile to write inlined ASM to write performant C code. Look at the Linux kernel? You can use Google and a brain to find it.

Your broken code example was entertaining, though. :rolleyes:
[/quote]

Instead of ranting you could debunk the three points I made in my earlier post, after you realize that this topic is indeed about low-level programming and I am myself talking mainly about embedded(especially non-x86) systems.

The difference between native code(asm) and C is far greater than the difference between C and C++, and as you probably knew this, it makes me wonder why you had to bring it up in the first place?
1

Share this post


Link to post
Share on other sites
[quote name='Calmatory' timestamp='1311068770' post='4837290']
1) C is more compact in terms of resource usage.[/quote]

Disagree, as stated.

[quote name='Calmatory' timestamp='1311068770' post='4837290']
2) C is more portable, so there are more mature compilers for wider variety of platforms[/quote]

Agree, as stated, with reservations. Age and ease of implementation are the reasons, not portability. C++ has a perfectly well-defined standard.

[quote name='Calmatory' timestamp='1311068770' post='4837290']
3) C is simpler, easier to learn and use properly and there exists lots of good enough programmers for the job.[/quote]

Agree, as stated, with reservations. "Properly" is a dangerous term. Your own example with the potentially breaking limitation of a 32 character name well demonstrates this point.
1

Share this post


Link to post
Share on other sites
[quote]
In C++ I am writing a bubble-sorting algorithm to sort a list of strings alphabetically ... If each string is 10,000 characters in size, and there are 40,000 strings your looking at a huge overhead implementing it this way.
[/quote]
If there are 40,000 strings, why have you decided to [b]bubble sort[/b] them? This is under a bullet point talking about [i]efficiency[/i].
2

Share this post


Link to post
Share on other sites
[quote name='Calmatory' timestamp='1311068770' post='4837290']
But if C++ is suitable, and better by providing improved type-safety and generics at no extra cost, why isn't C++ used instead of C? That's the fundamental question behind this whole topic. :)[/quote]It is...[img]http://public.gamedev.net/public/style_emoticons/default/tongue.gif[/img]
C++ [b]is [/b]used instead of C, commonly, in low-level code.

The question behind the topic is based on a false assumption.
1

Share this post


Link to post
Share on other sites
[quote name='rip-off' timestamp='1311070601' post='4837303']
[quote]
In C++ I am writing a bubble-sorting algorithm to sort a list of strings alphabetically ... If each string is 10,000 characters in size, and there are 40,000 strings your looking at a huge overhead implementing it this way.
[/quote]
If there are 40,000 strings, why have you decided to [b]bubble sort[/b] them? This is under a bullet point talking about [i]efficiency[/i].
[/quote]

A better question would be why have you decided to sort them yourself at all in fact, rather than just using std::qsort()? :)
Another reason i prefer C++ over C is because i don't have to invent the wheel every time i want a linked list, R/B tree or sort function, or have my own libraries of code built up when STL does most of it for me and is very extensible.
0

Share this post


Link to post
Share on other sites
[quote name='Yann L' timestamp='1311049289' post='4837198']In fact this is something one can observe in almost all C vs C++ discussions. The most rabid C defenders (explicitly including Linus Torvalds) have actually very little knowledge of C++, sometimes leading to almost absurd arguments.[/quote]The two most important sentences in the entire thread, summarizing it all.

This concept easily extends to other fields too, such for example revision control software.

CVS is total shit. The Subversion authors initially said they'd try to do right what CVS did wrong, [i]and they aren't gits[/i]. So, without looking at Subversion, it is obvious that it's total shit, too. Clearly. Sending tarballs via email is better than Subversion.
Having said that, my Windows Subversion install is 3.5% the size of the side-by-side Git install, performs better in every respect, and has a much superior Explorer integration. Yes, committing over the internet is slower than committing to a local copy on the hard drive (which SVN does just fine too). What a surprise.

I won't even mention BSD :rolleyes:
2

Share this post


Link to post
Share on other sites
[quote name='samoth' timestamp='1311082281' post='4837369']
[quote name='Yann L' timestamp='1311049289' post='4837198']In fact this is something one can observe in almost all C vs C++ discussions. The most rabid C defenders (explicitly including Linus Torvalds) have actually very little knowledge of C++, sometimes leading to almost absurd arguments.[/quote]The two most important sentences in the entire thread, summarizing it all.

This concept easily extends to other fields too, such for example revision control software.[/quote]

Why don't Linux developers use Visual Studio? It's the best IDE, it's so much better, has better debugging, team deployment, it integrates with reporting systems and makes it easy to work with off-shore teams via Visio diagrams.


Is it perhaps because it simply doesn't work? Or because Linux developers have little knowledge of MVS?


C++ doesn't work for Linux kernel development. Simple as that. The assumptions C++ memory and OO model make *do not work* in kernel. The syntax features C++ introduces, such as scoping *do not work* with grep (there is no IDE for kernel development). The C++ ABI or lack thereof *does not work* with much of POSIX. That said, POSIX systems are C, so bringing in C++ doesn't really make sense. C and C++ are not compatible. At POSIX level they have some fundamental incompatibilities, but most developers will never run into them, since their work would have been much more suitable for something like Java or C# in the first place.


Why does one choose CVS or SVN? Management and regulation. In many if not most companies, developers are end of the line. They have no decision making power and when they write code they do so as instructed and when instructed. Just like engineering. On-site construction worker can't suddenly start experimenting with different support beams, because the choice was made after months of design and load testing work before it was cleared by regulatory process. So "performance" of SVN vs. git is irrelevant. The seconds/minutes/hours difference is factored in the whole 1 year process.

Distributed VCS are many, git is just blindly accepted because Linus does it and he has to be right. What they often forget is that they are not C kernel developers. There are other DVCS, but the biggest and about only advantage is departure of merging style and benefits it brings, not performance or anything else. They are considerably better suited for highly contested code and experimentation, which is the pinnacle of agile web development. If your development doesn't have such problem (single developer or share-twice-a-week), then DropBox might work just as well.

Or, if you work with Ruby, you use git. Not because it's good, but because everyone uses github. It's always about process, or better yet, people. Tools evolve around that.But at minimum, they need to work. No matter how good, they simply must not lack even one required feature. A tool may be best in everything, but if there is just one single thing it lacks, it will not be used.
2

Share this post


Link to post
Share on other sites
Err.... why all the git hate? It's actually quite good. I prefer mercurial, but there really is nothing wrong with git except the slightly larger learning curve compared to traditional central version control. Despite what people are saying, DVCS ARE faster than using a central repo. Local commits are practically instant, which encourages people to commit more often which creates a much better history of development which in turn makes merging much, much easier. We have been using mercurial for around six months and SVN for three years before that. Mercurial is [b]much [/b]more effective if you have more than one developer working in the same project at the same time.
0

Share this post


Link to post
Share on other sites
[quote name='Antheus' timestamp='1311087171' post='4837408']
C++ doesn't work for Linux kernel development. Simple as that.
[/quote]
Well unfortunately it's not that simple. C++, OO and even garbage collection work perfectly fine for [i]a[/i] kernel, they just don't work for the [i]Linux[/i] kernel. The reason being historical design decisions, but in no way technical or conceptual limitations of C++. The Linux kernel memory model was a design decision, not a necessity. Source compatibility with grep was a (very awkward) design decision. POSIX and its ABI are historical artifacts that should have been nuked ages ago.

At the bottom line, there is absolutely no technical reasons C++ wouldn't work on a Linux like kernel. The use of C was an explicit choice by the kernel developers. It was historically motivated and is fanatically upheld despite it being completely irrational nowadays. In fact the open source world, especially the Linux kernel developers, is a special corner case. Decisions are mainly driven by ideology and idolization (Linus, RMS, etc) rather than by technical or efficiency-based analysis. Due to the unfortunate fact that some of these popular idols are very far from being C++ experts, yet very vocal about their technically unfounded opinions, C-itis is still strong there.
0

Share this post


Link to post
Share on other sites
[quote name='Antheus' timestamp='1311087171' post='4837408']
Why don't Linux developers use Visual Studio? [...]C++ doesn't work for Linux kernel development. Simple as that.[/quote]No doubt about that as far as all the IDE things go, and I agree at least partly with other things. It's not what I'm saying though. I'm neither claiming that C++ would just work for the Linux kernel or that it would be equally or better suited. Obviously you can't just plug C++ in there and expect it to work, but I don't doubt that it would be possible to use C++ in kernel development (most issues that you pointed out are true, but solvable).
But that's not my point, my point is that because Mr. Torvalds says C++ is shit, that isn't necessarily so, and repeating the old mantras about how C is so much better and more efficient [i]when it isn't[/i] is just silly.

I'm against claims such as "C is more portable than C++" too. From the specification, C++ is more portable, because a lot fewer things are undefined.
In fact, it's funny to speak of C and portability in the context of Linux, since nothing is as non-portable as the (entirely written in C) Linux or any program running under it. All those "portable" programs depend on ./configure fixing their non-portability issues via macros, and [i]hardly one program compiled under one Linux distribution runs under another distribution, with the same kernel version on the same processor[/i]. Let's not even talk about a different version or processor.
I'm not saying that this would necessarily be any different with C++, but I object to the "ah... C++ is shit because C is soooooo much more portable". The claim just isn't real, especially not with software that needs stuff like [font="Courier New"]#define SIZEOF_INT 4[/font] to compile and that works on raw pointers depening on hardcoded offsets and such.

I'm also against the "good C programmer, shit C++ programmer" comparison. This one pisses me off in particular. There are as many bad C programmers as there are bad C++ programmers (and as there are C programmers who think they are C++ programmers, and Java programmers, Ruby programmers, and <insert any other language> programmers). You just can't compare a "good C programmer" to a "bad C++ programmer" and say: "see, C is much superior, because C++ programmers are shit".
Except that C++ with its much stricter rules and much better type checking [i]might indeed[/i] be able to catch a lot more stupid errors. The compiler catches 1-2 really stupid errors of mine per day, and I don't consider myself a particularly stupid programmer (not more stupid than anyone else, anyway). And guess what, I'm happy that the compiler finds these things early, it makes my life much happier.
Also, C++ with its much bigger standard library requires a "shit programmer" to implement a lot less boilerplate code, which means there is a lot less room for serious mistakes. Among the major reasons why Java and C# are successful is not so much that they are superior in some way, but the fact that they have very complete standard libraries that "just work".

Of course nobody can prevent someone from using a standard library in the most stupid way possible, but that applies to every language and every library, and isn't the fault of C++ in particular. I can write a hell of a stupid, inefficient program in C or in Java too, if you give me a few minutes.

[quote]Distributed VCS are many, git is just blindly accepted because Linus does it and he has to be right.[/quote]Yep, thats exactly it, and that's what I don't agree with. That, and the author's attitude.
[quote name='tstrimple' timestamp='1311090604' post='4837452']Err.... why all the git hate?[/quote]
It's not Git hate, you got that wrong, it's about the attitude, I only used Git as an example because its history contains a very "bloomy" description of said attitude.
Git performs kind of ok, there is little doubt about that, and if someone likes to use it, no objections. But it is not much superior to all other revision control systems for the average user, and certainly not the best thing since the invention of the wheel. It's not for everyone, either.
But most importantly, it's not like everything else is shit, just because Mr. Torvalds thinks so, and because he knows everything. The nasty things that I wrote in my previous post about Subversion are an almost word by word Torvalds quote. I didn't make those up, you can find them on the internet.

Granted, Mr. Torvalds started a Unix-like kernel project, and I didn't, so you could say that's 1:0 for him. But that does not make him God, or the supreme ruler of programming. If you're being honest, the Linux kernel in the early 1990s as conceived by Mr. Torvalds had mostly one truly good property, and that was that it didn't cost anything. The (so-called) contributions (which [i]in reality[/i] are the major, important part!) from people like Mr. Anvin, Miller, Molnar, Card, or Ts'o (incomplete list) are what actually made and makes Linux competitive today. Without these people, it would be nothing. Also, it is the hundreds (thousands?) of GNU programs and millions of man hours provided by GNU supporters which actually kept Linux running for two decades. We would not even be able to boot Linux without the GNU people.

So in one word, what I don't agree with is idolizing a person in such a way and justifying every stupid and nasty thing he says which is of course automatically true, because it's him.
1

Share this post


Link to post
Share on other sites
The reason why C is more portable than C++ is that to have a proper C++ implementation, you first need to have a proper C implementation. Implementing C is easier. Simpler. As such, there exists more C compilers for embedded systems than there are C++ compilers. Though, I am not aware of how standards compliant these compilers are, as I mainly work with GCC myself anyway, which often does the trick for most developers but not always, that's when the developer has to rely on the (often proprietary) implementation of the hardware manufacturer, which may be complete mess with all the undocumented/unsolved bugs and quirks.

[quote]

n fact, it's funny to speak of C and portability in the context of Linux, since nothing is as non-portable as the (entirely written in C) Linux or any program running under it. All those "portable" programs depend on ./configure fixing their non-portability issues via macros, and hardly one program compiled under one Linux distribution runs under another distribution, with the same kernel version on the same processor. Let's not even talk about a different version or processor.
I'm not saying that this would necessarily be any different with C++, but I object to the "ah... C++ is shit because C is soooooo much more portable". The claim just isn't real, especially not with software that needs stuff like #define SIZEOF_INT 4 to compile and that works on raw pointers depening on hardcoded offsets and such.


[/quote]

Examples please. And explanations as to what makes you think that binaries wouldn't work on different distros or kernel versions. And how is this related to C and C++ anyway? I recommend you to take a look at Single Unix Specification standards which define pretty much everything related to portability within Unix-like systems. The corner cases(e.g. distribution specific) are often handled individually. This is more about the scatteredness of the Linux distributions and the lack of (need to have) proper guidelines. This is both a strength and a weakness and is not related to this topic.




To my understanding there hasn't been any kind of glorifying towards Torvalds in this thread, so why the hate?

0

Share this post


Link to post
Share on other sites
How about [url="http://www.gnu.org/software/autoconf/"]autoconf[/url] as an example, the actual program used by 99% of linux programs to adjust their own code to be portable?

Very few open source developers distribute binaries that work on different linux systems either, they distribute source, simply because everybody has different versions of libraries, and trying to randomly run binary A from distro B on distro C just results in undefined external or missing shared object errors, unless you statically compile the lot.
Statically compiling a binary for the sake of portability is a dangerous proposition, as you are then left 'holding the baby' when it comes to all security updates for any libraries your application uses, not to mention your whole idea of a C program being 'small' then goes out of the window as you linked several libraries to it.

As for the kernel, drivers dont work across different versions quite simply because there is a constant compiled into each driver which must exactly match that of the kernel proper. Again, these are recompiled, not distributed as binarym unless you refer to binaries packaged for a particular distribution, which are designed to be compatible, but [b]only with that particular distribution and version[/b].

Case in point: The nvidia binary blob drivers. There is a binary blob that is compatible with the whole 2.6 range, and then there is a stub it attaches to that must be rebuilt for every kernel version. Edited by braindigitalis
0

Share this post


Link to post
Share on other sites
[quote name='Calmatory' timestamp='1311100358' post='4837550']
The reason why C is more portable than C++ is that to have a proper C++ implementation, you first need to have a proper C implementation.[/quote]

Really? Why?
0

Share this post


Link to post
Share on other sites
[quote name='Aardvajk' timestamp='1311112045' post='4837639']
[quote name='Calmatory' timestamp='1311100358' post='4837550']
The reason why C is more portable than C++ is that to have a proper C++ implementation, you first need to have a proper C implementation.[/quote]

Really? Why?
[/quote]

Well, (without taking in the fact that standard C library is also part of the standard C++ library, though they are hardly used in most embedded development) not strictly, and actually not at all with the upcoming C1x and C++0x standards, since they just depart the languages even further. But for example C++98 is pretty much compatible with C89 apart from few type-safety differences as mentioned before. As such, the logical step is to make a C(89) compiler and extend it to a full C++(98) compiler from there. Though most(if not all?) proprietary(and some open even) C compilers are not C89 compliant anyway, let alone C99.


As it is right now, there exists more C compilers for embedded devices than there exists C++ compilers. I'd claim that the main reason is that it is easier to implement a C compiler than it is to implement a C++ compiler. I guess today GCC takes care of cross compiling though, except for some rarer hardware.

Motivated by this thread, I decided to grab the good ol' The C++ Programming Language by BS and give it a go.. ..after I've got it collect dust for almost 3 years without ever really taking a deeper look at it.. .. UNITL NOW! :)


0

Share this post


Link to post
Share on other sites
I keep seeing this thread on active topics. It's kind of annoying me. I think i'll fix that now.
2

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