Timeline for Why do people use C if it is so dangerous?
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 13, 2016 at 6:35 | comment | added | Cem Kalyoncu | Unless you are using managed pointers in C++, there is nothing related to reference counting in C/C++. You probably pass data vector as a reference to the thread in C++ thus you won't be using reference counting anyway. Even if you used reference counting, element access will not take longer as inlining will get rid of extra function calls. There are no checks in release code about a nullptr either. Thus only overhead will be at the entry to the thread function and at the exit. | |
| Jun 12, 2016 at 22:42 | comment | added | supercat | @CemKalyoncu: On the flip side, a scanning GC makes it possible for code to manipulate references to owner-less immutable data holders more efficiently than can be readily accomplished in a reference-counted system, especially when the objects may be referenced via multiple threads. | |
| Jun 12, 2016 at 12:34 | comment | added | Cem Kalyoncu | People forget that there is the caching issue, as the objects are generally larger in managed languages as well as inability to control and predict allocations CPU cache misses increase, leading to much worse real life performance. JIT compiled managed languages might reach the speed of C/C++ in matrix multiplication but if it is games or GUI we are talking about, they don't come close. | |
| S Jun 8, 2016 at 19:38 | history | suggested | Cody | CC BY-SA 3.0 | Added stuff to address comments that appeared after I originally posted this. |
| Jun 8, 2016 at 16:19 | review | Suggested edits | |||
| S Jun 8, 2016 at 19:38 | |||||
| Jun 8, 2016 at 12:28 | comment | added | Luaan | @gbjbaanb It's not just CPUs being faster - a big deal is that C++ and C had decades to perfect their compilers and runtime, while Java started basically from zero (being designed as a multi-platform platform primarily). As the VM improved (e.g. the switch from interpreter to a JIT compiler, improved GC...), so did performance of Java applications. A lot of the edge C/C++ still has is in the "let's hope nothing breaks" approach - avoiding a lot of checks that are deemed "unnecessary". But it's still a huge memory hog - in fact, improvements to CPU usage often meant worse memory performance :) | |
| Jun 8, 2016 at 12:22 | comment | added | Luaan | C# has always been JIT compiled (unlike Java, where your comment is correct), and it was quite capable of very similar execution speeds to C++ from the get go if you knew what you were doing. That's 2003 - not something I'd consider recent. Raw speed isn't the main issue for games (especially with programmable shaders on the GPU), there are other things that made languages like C# more or less popular at times. Two main issues are APIs (which are heavily C-oriented, and the interfacing may be expensive) and GC (mostly for latency issues, not raw throughput). | |
| Jun 8, 2016 at 11:44 | comment | added | Peter Taylor | Nearly every large game was written in the language of the engine it used: the amount of work that would have needed duplicating was so large that no other technical consideration was even worth taking into account. Rendering is indeed expensive, but nowadays that's all written in shaders and the language of the logic loop is irrelevant. | |
| Jun 8, 2016 at 10:56 | comment | added | user20416 | When you say Javascript for Web do you mean client-side progamming with its proliferation of compile-to-Javascript languages; or server-side programming which has at least the same options as what you refer to as Windows programming? In truth, Javascipt is also suited for desktop application development (AKA Windows). Perhaps what you mean is that compiled languages like C# were less appropriate for the initially lighter demands of Web client-side programming. | |
| Jun 8, 2016 at 7:28 | comment | added | gbjbaanb | :@NPSF3000 usually the situation is that hardware has gotten better to the point where the inefficiencies a language imposes (or encourages in terms of its programming practices) are no longer noticed. eg. Early Java was awful and a memory hog, but then memory got cheaper and CPUs got faster and it didn't matter as much. In the end who cares if your game does 200fps or 120 fps?! | |
| Jun 8, 2016 at 3:12 | comment | added | NPSF3000 | "Even Unity is not all C#, huge chunks of it are C++" And? Games in Unity often use C# extensively, and have been around for quite some time now. Suggesting that C# is 'just recently reaching speeds' either needs more context, or runs the risk of being blind to this decades tech. | |
| Jun 8, 2016 at 0:10 | comment | added | luk32 | "C# for anything Windows" - Oh, that's such a fallacy. And you even provide an example. Unity. AFAIK It's not written it provides C# API because the language is nice an adaptable. It's really well designed. And I like c++ more, but the credit should be given where it's due. Maybe you mixed C# with .NET? They hang out together quite often. | |
| Jun 7, 2016 at 19:09 | review | First posts | |||
| Jun 12, 2016 at 9:29 | |||||
| Jun 7, 2016 at 19:06 | history | answered | Cody | CC BY-SA 3.0 |