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?
Why is C++ the industry standard?
[quote name='ChaoSXDemon' timestamp='1338521047' post='4945181']
[quote name='Reflexus' timestamp='1338510649' post='4945139']
I hope someone understands this:
http://www.jelovic.c...ava_is_slow.htm
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.
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 can 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 eat up 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 because 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?
Java doesn't have pointers, it has handles. They don't support manipulation, and do not necessarily point 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.
Yeah for mobile device that's probably true
And I didn't know that about Java pointers so thanks for the info CXD
Actually, Java using more memory can 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 eat up 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.
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 name='Ameise' timestamp='1338573578' post='4945379']
Actually, Java using more memory can 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 eat up 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.
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
[quote name='Ameise' timestamp='1338573578' post='4945379']
Actually, Java using more memory can 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 eat up 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.
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 will 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.
You can tell my friend who works on database servers where the client interface is written in Java that.
Oh yes, loading the database into memory and blaming Java for being slow...
...Or any Android mobile developer.
FYI: You don't run Java on Android.
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.
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 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.
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 will use more memory no matter what, due to the need to store metadata for practically everything.
[quote name='Ameise' timestamp='1338823708' post='4946139']
...Or any Android mobile developer.
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 same 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).
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.
It was 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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement