• 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
stein102

Why is C++ the industry standard?

38 posts in this topic

[quote name='ChaoSXDemon' timestamp='1338491897' post='4945066']
[quote name='eugene2k' timestamp='1337977541' post='4943344']
[quote name='Alpha_ProgDes' timestamp='1337901594' post='4943051']
[quote name='saejox' timestamp='1337859676' post='4942865']
it has a little thing called "pointer"
[/quote]
So does every language in existence.
[/quote]
Uhh... no?
[/quote]

Uhh... yes? lol you just can't directly manipulate them in other languages... but they ALL USE POINTERS [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
[/quote]

Of course every language need to handle memory adresses, since it has to run on a computer...
But the whole point of the pointer concept is that you can manipulate them directly.
If you can't, I don't agree that you should call them "pointers", then you usually call them "references".
1

Share this post


Link to post
Share on other sites
[quote name='Reflexus' timestamp='1338510649' post='4945139']C++'s meta-language just sucks; I disagree that it improves any of the programmer's productivity.[/quote]
C++ template programming have a somewhat steep learning curve, but when you start being productive with it it is very good. It allows to rather quickly build powerful abstractions that have no runtime cost compared to a more classical (and time consuming) implementation. So yes, it does improve programmer productivity significantly.

C++11 have also improved template programming significantly when it comes to ease of use and readability.
1

Share this post


Link to post
Share on other sites
[quote name='ChaoSXDemon' timestamp='1338521047' post='4945181']
[quote name='Reflexus' timestamp='1338510649' post='4945139']
I hope someone understands this:
[url="http://www.jelovic.com/articles/why_java_is_slow.htm"]http://www.jelovic.c...ava_is_slow.htm[/url]

Personally, (although I am most experienced with C++) I don't like C++ much. I agree strongly with dilyan_rusev. I don't think C, either, is all that shiny enough for the C++ designers to completely ignore people's problems with it, just so they can continue to be fanatic about C's legacy. I would say C++'s contributions aren't much either. There's a chance that if you limit yourself to utilizing C++'s capabilities, you can complete your project(s) much sooner. C++'s meta-language just sucks; I disagree that it improves any of the programmer's productivity. I tried "D", but I honestly didn't try very hard, because it makes some big mistakes that Java has also made.
[/quote]

That is a nice article and frankly, it's got a point. However, I would like to point out that who ever wrote this is still thinking in an older mind set. Garbage Collection (GC) was a hot topic back in its birth dates just like how multi-core programming and languages that supports multi-thread optimally is a hot topic today. People back then wasn't sure if GC can be implemented on software or it needs hardware acceleration. Eventually, software was all that it needs. The point of bring this is the word "NEED". If you know your software NEEDS that 0.1s of optimization by using cache, then use C/C++ and do those crazy things! So why don't we NEED that optimization today?

The article mentioned that Java uses more memory. Is that a problem? NO...who isn't on a 64-bit machine that has more than 4096MB of RAM? Maybe people who DON'T CARE for that speed and some who just can't afford that cheap memory would still use an older system with less RAM. With that much RAM, we can AFFORD Java's heavier memory usage. Additionally, SSD are becoming more and more popular and page swapping on those isn't that bad. With that in mind, we should be focused on other things such as "Design Patterns", "Production Flow", "Prototyping" etc.

Unless you are writing some low level CORE library, honestly, WHO CARES?

CXD
[/quote]

Actually, Java using more memory [i]can[/i] very much be a problem depending on what you're doing. Mobile devices (Android's Dalvik comes to mind) or large industry systems may see this. I have a friend who works for one of the large database providers, and with so many virtual instances running, their Java implementation constantly drives down the available system memory. Even in normal game development, Java tends to simply [i]eat up[/i] memory, and depending on what you're doing, memory might be in short supply. I do a lot of procedural work, and end up using a lot of memory. I've hit the 4 GiB limit in the past with C++; Java would have been worse.

Your point about caching seems... well, wrong. Most VM/JIT implementations tend to be relatively cache unfriendly, and that can and will significantly hamper performance. Java isn't appropriate for many games [i]because[/i] of its system-agnostic nature - the programmer can and often will write better abstraction code than a JIT will generate.

ALSO, is there a REASON that you SEEM to enjoy PLACING EMPHASIS on things USING caps so OFTEN?

[quote name='ChaoSXDemon']
Uhh... yes? lol you just can't directly manipulate them in other languages... but they ALL USE POINTERS [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
[/quote]

Java doesn't have pointers, it has handles. They don't support manipulation, and do not necessarily [b]point[/b] to a memory address. They point to an arbitrary object. This is why Java doesn't call them pointers - because they don't behave exactly as such. Java is still pass-by-value (just like C), but they mask away much of the functionality. Not all languages even have these pseudo-pointers - some only have concepts equivalent to C++ references, which work via pass-by-reference. Edited by Ameise
2

Share this post


Link to post
Share on other sites
My guess is ubiquity. It's been around a while, there are thousands of libraries written for it, there's a lot of programmers that know it, it's taught in schools, it's a very refined language that has been optimized by 2 generations of computer programmers, ect. It's not the only language that CAN be used to write games, hell you can write a game in any language that can draw to the screen, but it certainly has proven the test of time in terms of performance, adaptability, and compatibility, unlike a lot of other languages that have been cooked up since 1984 and now.
0

Share this post


Link to post
Share on other sites
C++ is the most attractive language when measured in power, flexibility and speed. As power, flexibility and speed increase, the detracting elements like manual memory management, dealing with header files and in general writing more code than in other languages become lesser.

Company A develops software using C++/CLI. They have a managed Windows Forms front end on top of native C++ class libraries. They tap into the benefits of .NET on the managed side and vintage C++ libraries like VTK and ACIS on the native side all in one solution. The common thread is C++.
What other language can do this?
0

Share this post


Link to post
Share on other sites
[quote name='Ameise' timestamp='1338573578' post='4945379']
[quote name='ChaoSXDemon' timestamp='1338521047' post='4945181']
[quote name='Reflexus' timestamp='1338510649' post='4945139']
I hope someone understands this:
[url="http://www.jelovic.com/articles/why_java_is_slow.htm"]http://www.jelovic.c...ava_is_slow.htm[/url]

Personally, (although I am most experienced with C++) I don't like C++ much. I agree strongly with dilyan_rusev. I don't think C, either, is all that shiny enough for the C++ designers to completely ignore people's problems with it, just so they can continue to be fanatic about C's legacy. I would say C++'s contributions aren't much either. There's a chance that if you limit yourself to utilizing C++'s capabilities, you can complete your project(s) much sooner. C++'s meta-language just sucks; I disagree that it improves any of the programmer's productivity. I tried "D", but I honestly didn't try very hard, because it makes some big mistakes that Java has also made.
[/quote]

That is a nice article and frankly, it's got a point. However, I would like to point out that who ever wrote this is still thinking in an older mind set. Garbage Collection (GC) was a hot topic back in its birth dates just like how multi-core programming and languages that supports multi-thread optimally is a hot topic today. People back then wasn't sure if GC can be implemented on software or it needs hardware acceleration. Eventually, software was all that it needs. The point of bring this is the word "NEED". If you know your software NEEDS that 0.1s of optimization by using cache, then use C/C++ and do those crazy things! So why don't we NEED that optimization today?

The article mentioned that Java uses more memory. Is that a problem? NO...who isn't on a 64-bit machine that has more than 4096MB of RAM? Maybe people who DON'T CARE for that speed and some who just can't afford that cheap memory would still use an older system with less RAM. With that much RAM, we can AFFORD Java's heavier memory usage. Additionally, SSD are becoming more and more popular and page swapping on those isn't that bad. With that in mind, we should be focused on other things such as "Design Patterns", "Production Flow", "Prototyping" etc.

Unless you are writing some low level CORE library, honestly, WHO CARES?

CXD
[/quote]

Actually, Java using more memory [i]can[/i] very much be a problem depending on what you're doing. Mobile devices (Android's Dalvik comes to mind) or large industry systems may see this. I have a friend who works for one of the large database providers, and with so many virtual instances running, their Java implementation constantly drives down the available system memory. Even in normal game development, Java tends to simply [i]eat up[/i] memory, and depending on what you're doing, memory might be in short supply. I do a lot of procedural work, and end up using a lot of memory. I've hit the 4 GiB limit in the past with C++; Java would have been worse.

Your point about caching seems... well, wrong. Most VM/JIT implementations tend to be relatively cache unfriendly, and that can and will significantly hamper performance. Java isn't appropriate for many games [i]because[/i] of its system-agnostic nature - the programmer can and often will write better abstraction code than a JIT will generate.

ALSO, is there a REASON that you SEEM to enjoy PLACING EMPHASIS on things USING caps so OFTEN?

[quote name='ChaoSXDemon']
Uhh... yes? lol you just can't directly manipulate them in other languages... but they ALL USE POINTERS [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
[/quote]

Java doesn't have pointers, it has handles. They don't support manipulation, and do not necessarily [b]point[/b] to a memory address. They point to an arbitrary object. This is why Java doesn't call them pointers - because they don't behave exactly as such. Java is still pass-by-value (just like C), but they mask away much of the functionality. Not all languages even have these pseudo-pointers - some only have concepts equivalent to C++ references, which work via pass-by-reference.
[/quote]

Yeah for mobile device that's probably true :) And I didn't know that about Java pointers so thanks for the info :)

CXD
0

Share this post


Link to post
Share on other sites
[quote name='Ameise' timestamp='1338573578' post='4945379']
Actually, Java using more memory [i]can[/i] very much be a problem depending on what you're doing. Mobile devices (Android's Dalvik comes to mind) or large industry systems may see this. I have a friend who works for one of the large database providers, and with so many virtual instances running, their Java implementation constantly drives down the available system memory. Even in normal game development, Java tends to simply [i]eat up[/i] memory, and depending on what you're doing, memory might be in short supply. I do a lot of procedural work, and end up using a lot of memory. I've hit the 4 GiB limit in the past with C++; Java would have been worse.
[/quote]
Java does not tend to eat up memory.
Excessive memory usage has nothing to do with Java itself, it all depends on your very own coding style and that of used libraries.
Please do not feed age-old myths.
True is, that automated garbage collection can lead to mindless programming habits, but that usually has bad consequences in each and every language and environment.
0

Share this post


Link to post
Share on other sites
[quote name='6510' timestamp='1338621893' post='4945510']
[quote name='Ameise' timestamp='1338573578' post='4945379']
Actually, Java using more memory [i]can[/i] very much be a problem depending on what you're doing. Mobile devices (Android's Dalvik comes to mind) or large industry systems may see this. I have a friend who works for one of the large database providers, and with so many virtual instances running, their Java implementation constantly drives down the available system memory. Even in normal game development, Java tends to simply [i]eat up[/i] memory, and depending on what you're doing, memory might be in short supply. I do a lot of procedural work, and end up using a lot of memory. I've hit the 4 GiB limit in the past with C++; Java would have been worse.
[/quote]
Java does not tend to eat up memory.
Excessive memory usage has nothing to do with Java itself, it all depends on your very own coding style and that of used libraries.
Please do not feed age-old myths.
True is, that automated garbage collection can lead to mindless programming habits, but that usually has bad consequences in each and every language and environment.
[/quote]

Thank you :)
0

Share this post


Link to post
Share on other sites
[quote name='6510' timestamp='1338621893' post='4945510']
[quote name='Ameise' timestamp='1338573578' post='4945379']
Actually, Java using more memory [i]can[/i] very much be a problem depending on what you're doing. Mobile devices (Android's Dalvik comes to mind) or large industry systems may see this. I have a friend who works for one of the large database providers, and with so many virtual instances running, their Java implementation constantly drives down the available system memory. Even in normal game development, Java tends to simply [i]eat up[/i] memory, and depending on what you're doing, memory might be in short supply. I do a lot of procedural work, and end up using a lot of memory. I've hit the 4 GiB limit in the past with C++; Java would have been worse.
[/quote]
Java does not tend to eat up memory.
Excessive memory usage has nothing to do with Java itself, it all depends on your very own coding style and that of used libraries.
Please do not feed age-old myths.
True is, that automated garbage collection can lead to mindless programming habits, but that usually has bad consequences in each and every language and environment.
[/quote]

You can tell my friend who works on database servers where the client interface is written in Java that. Or any Android mobile developer. Java eats up memory because objects aren't nearly as simple as C++ objects. No matter what a Java program [i]will[/i] use more memory; it is impossible for it to use less. Even if it somehow generates perfect code for objects using JIT (which it won't) it still needs to maintain the JITs state in memory, as well as JVM state.
0

Share this post


Link to post
Share on other sites
[quote name='Ameise' timestamp='1338823708' post='4946139']
You can tell my friend who works on database servers where the client interface is written in Java that.
[/quote]
Oh yes, loading the database into memory and blaming Java for being slow...

[quote name='Ameise' timestamp='1338823708' post='4946139']
...Or any Android mobile developer.
[/quote]
FYI: You don't run Java on Android.
-2

Share this post


Link to post
Share on other sites
Alright, folks.

If we can't have a civil discussion without resorting to "yuh huh!" and "nuh uh!" all over the place, we're going to talk about something else.
0

Share this post


Link to post
Share on other sites
[quote name='6510' timestamp='1338829281' post='4946158']
[quote name='Ameise' timestamp='1338823708' post='4946139']
You can tell my friend who works on database servers where the client interface is written in Java that.
[/quote]
Oh yes, loading the database into memory and blaming Java for being slow...
[/quote]

I never said it was slow; I said it used up a large amount of memory. When your server(s) are handling tens of thousands of clients, the overhead of Java starts to become rather large, to the point that prototype C++ implementations use a substantial amount less. Java [i]will[/i] use more memory no matter what, due to the need to store metadata for practically [i]everything[/i].

[quote name='6510' timestamp='1338829281' post='4946158']
[quote name='Ameise' timestamp='1338823708' post='4946139']
...Or any Android mobile developer.
[/quote]
FYI: You don't run Java on Android.
[/quote]

No, you run Dalvik bytecode (as I've said many times in the mobile forum). However, Dalvik is bound by the [i]same[/i] constraints as the JVM in that to perform the same tasks (handling Java behavior, JIT) it still requires a substantial amount of overhead (in the form of metadata and a background running JIT).

[quote name='ApochPiQ' timestamp='1338830258' post='4946162']
Alright, folks.

If we can't have a civil discussion without resorting to "yuh huh!" and "nuh uh!" all over the place, we're going to talk about something else.
[/quote]

It [i]was[/i] civil at one point. I'm trying to give experiences from my professional career; if he wants actual data, he needs only ask for it, instead of insisting that I'm wrong without any evidence of his own to the contrary. Also, his rather openly hostile attitude isn't helping. Edited by Ameise
-1

Share this post


Link to post
Share on other sites
I'm going to close this thread, as its breaking down into a language war. I'm going to close with a quote from the one person who actually gave the reason for C++ being the industry 'standard language' as far as AAA games go.

[quote name='Washu' timestamp='1337832025' post='4942781']
Because it works on all the platforms a game studio needs to target. Specifically: Xbox 360, PS3, and sometimes PC.

Its not a matter of a "want" to use C++, but a matter of "what is required to operate on this platform?"

That being said, indie developers can use XNA to target the Xbox 360 platform, with limitations of course.
[/quote]
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