As a C++ developer I've recently been in the midst of the Exceptions debate. Exceptions as a feature of the C++ language have long divided the community, naively I've often put this down to their coming to the language from elsewhere (C perhaps) where exceptions were not the norm. This was a mistake, for in the projects I've previously worked upon the overhead of an exception compared to the ramifications of the error resulting in a crash have often totally outweighed the overhead, making deciding to employ an exception exceptionally easy (*bum bum*). Exceptions were the norm, still are and should be to you too (according to the C++ Core Guidelines https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Ri-except ). The difficulty, the dilemma if you will, comes not from the feature, but the cost. If you application domain demands high performance you can not risk using exceptions, the argument carries on therefore whether in not using them to avoi...
I have an important distinction to make clear... Cross Compiling is using a machine with a different processor type than the target machine for your program. So, you have a PC with an Intel Core 2 Duo in it, and you use a compiler to output an ARM executable, that is cross compiling. If you're on an Intel Core Duo toting 15" MacBook pro (from 2006 ) and you use that to produce the same ARM executable, that's still cross-compiling. BUT if you use that MacBook to generate a windows executable it's not cross compiling, as the processor is the same in both targets, you're not crossing over... Some folks argue this differently, because you're crossing between the Windows and Apple OS's you're cross-compiling. In my book, and by the definition given elsewhere, you're not, in this case you are cross-platform (the platform being the OS) but you're not cross compiling because the processors are the same family. That's all, I just wanted this out t...
One sore lesson to teach some developers is when to trust the compiler, once you've gotten that across you have to start teaching folks to stop re-inventing the wheel. If someone has already implemented a file handler, or a serial port abstraction, or a wrapper for some obscure feature, you need to evaluate that offering... To evaluate whether a library is worth using, firstly see if it works, then see how many folks actually use it, the more that use it then the more likely bugs will be flushed out and the whole thing has been tested. Leveraging this kind of mature code within your projects assists in bootstrapping the startup phase of new projects. Boost is a note worthy example of what I'm talking about here, many software shops (at least the ones I know) resist using open-source or third party libraries, they prefer to stick to in-house developed niche implementations until the very last moment, this of course slows development and completely symies innovation. Boost howeve...
Comments
Post a Comment