sutton050

I was wondering around in some system code and found a strange behaviour between two modes in a piece of code, where the code switches from double to triple buffer mode there's a problem, we've already got two buffers of everything we just want to allocate another but the underlying structure for sets of buffers wants to own them all... So the code went from: SetOfBuffers { Buffer* one; Buffer* two; } To: SetOfBuffers { Buffer* one; Buffer* two; Buffer* three; } Creating the third buffer is fine: SetOfBuffers::three = malloc(X); But, the first two is a re-alloc, to reuse the existing buffer: SetOfBuffers::One = realloc(OldSet::one, X); SetOfBuffers::Two = realloc(OldSet::two, X); The problem?  I'd start to modify the values in the new set of buffers, the third buffer being used and present.  Then the first buffer would be changed present... The second buffer changed present and the information is wrong (I over simplify massively here). Anyway, I was remotely SSH'd

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 avoid

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