Advertisement
For the programmers who prefer C++ over other PL. why do you prefer C++.
just curious
just curious
Advertisement
Advertisement
-
-
Re: Question
Wed, July 19, 2006 - 10:38 PMIt's the only language supported (aside from C) for nearly all serious game development.
C/C++ also has libraries galore.
-
Re: Question
Wed, July 19, 2006 - 10:42 PMWhy is the runtime spped so much faster then other languages? Any technical explanation? -
-
Re: Question
Wed, July 19, 2006 - 11:16 PMThe speed up is relative to the language it's being compared to and what the code is actually doing. C++ is usually not faster than similar FORTRAN code for example.
Most aspects of C++ maps directly to or near the instruction level. C++ does little automatically for the programmer. For example, there is no expensive memory management garbage collection, runtime type checking (unless specified) or bounds/range checking. Obviously it's a complied language so it's going to be as fast or faster than (all?) interrupted languages or languages than run in a virtual machine on normal hardware. -
-
"interrupted" languages?
Thu, July 20, 2006 - 6:02 PM
Jon,
Do you mean "interpreted" or is there a type of programming language, the "interrupted" type, that i'm not aware of?
Regards,
John, just askin' :-)
Falling You - exploring the beauty of voice and sound
www.fallingyou.com
-
-
Re: Question
Thu, July 20, 2006 - 2:08 PMWhile you can do some pretty bonehead things in C++ and really slow things down, that isn't the case with C, which is what it's based on. Although C is usually regarded as a high level language, it isn't, not according the people that created it. (Pull out your old K&R if you don't believe me.) So, you can have a pretty good idea how your code will look after it's compiled and can avoid writing code in such a way that would have a disadvantage on the platform it will run on.
C++ builds on that and adds some very high level concepts on top of it without much overhead (again, if you know what the compiler will do). Also, because of the proliferation of C/C++, there have processors that have been made that were optimized to expect how C/C++ code will be laid out and execute better, such as faster access to stack than other memory, branch optimization that assumes the branch will be taken more often than not, etc.
Knowing what the compiler will do helps you to optimize for speed in several ways. For example, foo->bar->goober() causes a huge performance hit on many MIPS processors but not on Intel/AMD processors. Another example, knowing the target and compiler behavior on the platform I'm currently writing for lets me know that the first 4 paramaters to any function call will be passed in registers and not on the stack. So, I write functions with that in mind. I may also pad some data and structures out to multiples of 64 bytes and place them on 64 byte boundaries because of how that will align it with the processor's data cache and also give me a minor speed gain.
All this with the versatility of the language makes it a very good choice.
-
-
-
Re: Question
Thu, July 20, 2006 - 9:49 PMc++ is a good way to get both high-level oo capabilities and excellent performance for a variety of algorithmic tasks. Its a great choice when you need high performance, a relatively small packaging and runtime footprint, and over twenty years of industry development and support.
However - it is essentially C with some stuff on top of it, and past the minimal support for the language, it has had many more layers of stuff piled on top over the years, from the standard library, to ATL, to OS and library specific details you need to grapple with when you are coding. Sometimes seemingly simple things can be done five different ways and you need to know which one, where and why. For instance, strings of characters can be a nightmare to deal with if you dont know what you are doing; I can name probably 10 types of character strings on the Windows platform of the top of my head.
My point is that if you choose C or C++ for a given task you should be prepared for compiler errors that dont help you figure out what is wrong, elusive bugs, and myriad ways of doing things that equal slow and buggy development. It is a must for certain applications but IMO for most applications where performance is less important than development speed and low bug rate, I think managed languages like java or c# are just better choices.
Given all that - IMO C++ is the defacto standard for applications and systems programming. Any serious programmer must know it to some extent and for many tasks it is still the best\only choice even though it is starting to show its age. I do think however that sometime in the next 10 years or so we will see some newer, likely managed, environments emerge and become the new standards.
This is a very dogmatic topic however and I can guarantee you people will disagree with me, especially on the c++ alias :)
-J -
-
Re: Question
Fri, July 21, 2006 - 12:16 AMYou're right Jason. It is subjective and dogmatic. However, you are forgetting one intrinsic rule that is at the heart of it all. Programmers are lazy bastards. You show us a better way of doing something and we're all over it and it is the new standard. Period.
I used to program in 100% assembler, no matter the platform. Kickass macros did a lot for me that people used higher level languages to do. But I had those common functions at my fingertips, in assembler, and optimized the crap out of them.
But lo and behold, to my chagrin, there were ways to do what I had done and so much more. And to create it so much faster that the win in execution time seemed marginal. I've seen and used many other languages. You can compile Pascal and Basic, 100 times faster than C++. But no thanks, I've seen the result. Today, it still comes back to C/C++. I'm certain one day there will be a very smart language that will understand what the creator wants and put it in the most efficient terms. I'm certain you won't waste precious time on a keyboard for it either. But it isn't here yet. If it was this tribe would be deader than it is already. But we're not there yet. Soon, very soon, but not yet.
Just as I mentioned with my transition from assembler, there are tasks which can be written fast that are suited to languages other than C/C++, like parsing programs which may not be as fast but you can write so much faster that it isn't worth the effort. But for large scale programs and tasks, it's C/C++ or you're pulling out your processor manual.
-
-
Re: Question
Fri, April 27, 2007 - 4:20 PMMy cynical opinion is that people who use C++:
1) don't realize how much time they are wasting using C++ instead of a more productive language, or
2) realize how much time they are wasting and rationalize it away by referring to some C++ strengths, or
3) actually benefit from choosing C++ over another language
and that the number of people in the last category is small compared to the first two. I place myself in category #2, until relatively recently. -
-
Re: Question
Fri, April 27, 2007 - 6:02 PMThere is a fourth category actually - those who inherit c++ code. If you work on any major operating system you are in this category and I honestly cannot think of any other language one would write an operating system in to this day. Supposedly there is a microkernel written in Haskell but seriously, is that what you would choose if you were targetting major distribution as opposed to research? For system level as opposed to application level work I havent seen any other language that I would consider seriously... although the Singularity research group is doing MOST of their work in c#, the core is still unmanaged... Sometimes your job or problem domain simply dictates the language (it is still important to understand WHY though). -
-
Re: Question
Fri, April 27, 2007 - 7:43 PMThat's true, but people writing operating systems are rare compared to people writing higher-level code. And yeah, I agree, I forgot about poor saps who are stuck with C++ because they inherited code. However, I'd bet that if people stopped being in denial about how unproductive C++, they'd think harder about writing more code in it (and probably move in the direction of keeping C++ in its legacy sandbox and writing new code in some other language). -
-
Re: Question
Sat, April 28, 2007 - 9:53 PMSo put up or shut up. What is it's far superior replacement? -
-
Re: Question
Sat, April 28, 2007 - 10:32 PMIt depends on the problem domain. In many cases, Python. -
-
Re: Question
Sat, April 28, 2007 - 11:39 PMA lot of people really do seem to like that language. I admit however that I am not a fan of dynamic typing. I think we should be moving to a stronger static typing system a la ML or Haskell. I hate finding bugs at runtime (if you happen to hit that code path!) and want to provide the compiler with as much information as possible at compile time so it can help find problems in my thinking. I really should try it out tho :) C++'s compiler errors are actually ludicrously unhelpful many times. However java and c# both provide incredibly useful compile time help that really makes for better code. The idea in Haskel is basically that if it compiles it should be correct... Sounds kind of "pie in the sky" but its the right direction imo.... -
-
Re: Question
Sun, April 29, 2007 - 12:54 AMIt is impossible for the compiler to determine if your code is correct except in limited cases; this follows from undecidability of the halting problem. (See en.wikipedia.org/wiki/Halting_problem ). I recommend also reading mindview.net/WebLog/log-0025 . -
-
Re: Question
Sun, April 29, 2007 - 1:55 AMYep I was referring to the limited form of correctness that modern compilers can help you with.
After reading the weblog article tho I am still not convinced. He doesnt talk about the code where he places an object which does not implement Speak() in to his array and is program crashes at runtime. Strongly typed languages simply dont allow that kind of mistake unless you really try.
Yes you can make the argument that you should test every nook and cranny of your code. But it is impractical in any system of reasonable complexity. Trade-offs must be made with respect to what gets tested - otherwise there wouldnt be any bugs! In real systems you dont own all the code - and its the interactions of well tested subsystems that cause most problems. How Joe Developer to know that the api he is calling (which he doesnt own) calls another api that calls another api that calls another api that under certain circumstances tries to call Speak() on the object he passed in (which doesnt implement it!)? BOOM at runtime! Sucky.
Type systems are a well understood tool for eliminating this entire class of bug - plus IMO it helps you to better understand the problem domain you are modelling when you have to think about types.
dont even get me started about whitespace sensitivity ;)
-
-
-
-
-
-
-
Re: Question
Mon, April 30, 2007 - 5:18 PM
Ben,
Well, there is yet another category -- those (like me) who write code that has to run natively on multiple platforms (I regularly write code that has to run on Windows, Mac OSX and Linux, and keeping as much code cross-platform as possible is a requirement). Java isn't the answer here, because there isn't a Windows OS that comes with Java (and MS i'm sure would rather it stayed that way). The same applies to the other C-derivatives like C# and ObjC. As much as MS would like to have us coding in C#, as much as Apple would love to have us all doing ObjC, and as much as Sun would like all of us to do Java, if you are targeting multiple platforms and don't want to force your users to download special runtime environments like the JRE or Mono, or want to keep your apps as small / light as possible, C / C++ is the only real choice.
Java, C# and ObjC are fine languages, but until every OS comes with the JRE / CLR / ObjC runtime (without forcing the user to download it, either manually or via a huge app), they're not good choices for end-user apps that have to run on multiple platforms.
Regards,
John
Falling You - exploring the beauty of voice and sound
www.fallingyou.com
-
-
Re: Question
Mon, April 30, 2007 - 9:38 PMThe runtime is a fixed per-user cost. For some languages (such as C and C++), that cost is zero; for others, it's not. This cost comes in the form of network bandwidth and user time for downloads, and disk space and memory footprint for running apps.
On the other hand, using a les productive language (whatever that is for the project at hand) presents costs of its own, in terms of your development time, which directly translates to cost to your users, as they have to wait longer for you to add features to your product.
You are basically saying that the cost of a runtime is always greater than the cost in how long it takes you to deliver your product to the end user. I do not agree with that; I believe there are many cases where the cost of providing the runtime is a small price to pay for the productivity gains over C and C++. -
-
Re: Question
Mon, April 30, 2007 - 10:41 PM
Ben,
Oh, it's not always greater (i'm not saying that at all), but when the requirements are that the code has to run on multiple platforms, the engineering resources are limited (read: make the code as portable as possible) and "the download has to be under 500k", then ... well, that means C / C++ :-) For a lot of projects that don't have these requirements e.g. the machine is imaged by a corporate IT dept, or the delivery mechanism for the app isn't the (often slow from a users' perspective) internet, then other languages are fine; indeed, even a more responsible choice. I've used Perl for a great many things like this, which is not to say that Perl is the best higher-level lanuage around (i'd like to learn Python), only that for a different set of requirements, it's better than C / C++.
That being said, i'm more of a systems-level than an application-level developer. The sorts of projects i'm hired for almost never have GUI components, almost never have to interface to the user directly (they almost always run as services / daemons, and there is usually another higher level app that interacts with the user and in turn sends commands to me), and almost always have to run on lots of different platforms (for instance, one of the highly desirable goals of the project i'm on now is to have the code also be able to run on a PS3 / Wii / 360, and since almost every development platform out there, for any machine, is either MS- or gcc-based, C++ remained the best choice).
Regards,
John
Falling You - exploring the beauty of voice and sound
www.fallingyou.com
-
-
Re: Question
Tue, May 1, 2007 - 3:04 AMYeah, with those requirements you do have to optimize to the point where many languages are out of the picture. It is worth noting that a 3rd party stripped a Python interpreted down to 200k for use in embedded systems, but I can't vouch for it, I just heard about it.
-
-
-
-
