Yeah, not sure what I was going for with the first sentence. Just the whole "use the C runtime libraries instead of the C++ ones" peeved me in its unnecessity. I mean, the idea of "don't use what you don't need" is pretty damn straightforward. As for manual memory management... eh, you'd be hard-pressed to need that level of precision on most projects. The thing linked at the bottom elaborates in a way that makes it make more sense to me, at least. I mean, his example of "design rationalle" in Boost really only applies in the sense of "if you're not making a generic library, don't make shit generic unless you can re-use it in your own code."
I believe that first one is probably a matter of running into a compiler-specific library. Linking against cmath in Visual Studio and linking against it in a GCC compiler or some other compiler is very different.
As for memory management, every performance-critical application needs to do it. Which is to say games and any product that takes more than a second to do at least one of its features. Garbage collection is why Minecraft has terrible performance, for example, with its characteristic frame stuttering every other second for upwards of 100ms+ if you have a bunch of mods loaded and it starts running low on memory. Console games almost always use their own custom memory management tech due to the constraints on those platforms. Memory allocation and deallocation calls to the OS are themselves slow, and so even PC games often use their own custom memory management tech -- especially if they want to multithread their engine.
The problem with RAII is that it isn't explicit. It's pretty common practice to have an empty constructor, have an Init function to do the real construction, have an empty destructor, then have a Release or Kill or Destroy function to do the real deconstruction. Reason being that Resource Acquisition Is Often Not Initialization; especially because memory is not the only kind of resource which may need to be acquired for an object. It also makes things explicit, which is beneficial for readability.
And really, that's what it comes down to: A programming language is an interface between a multitude of human brains and the machine. It doesn't exist to type code faster, it exists to allow for the creation of an accurate mental model of what the hardware is doing in a minimal amount of time and effort. If it needs external documentation, stop using C++ and write your gobble-de-gook in assembly so as to let everybody know it's indecipherable garbage from the outset. If you go through half a dozen levels of templates before your program actually runs any code, congratulations, you are special! Special in that you will be the only human who ever understands how your terrible code works. Even the compiler will have a hard time matching itself up against your brilliance! The most expertly written code, the sort that's a joy to work with, is that which you can sit a first year student fresh out of fundamentals of C++ in front of and have them understand not only what the machine is doing with the code, but why you are having it do that.
Author
Topic: if self.isCoder(): post() #Programming Thread (Read 883218 times)