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 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...

I am a huge fan of using the language to communicate my intent, especially when it comes to function parameters, I've talked about this before in terms of simple typing (by utilising "using" statements - to give meaning to simple/trivial types) and const correctness. But being Christmas, I've had a C++ gift or two, and one of them is C++ High Performance by Victor Sehr and Bjorn Andrist , I've only spent a few minutes looking through this book, but one comment did jump out at me as odd... Not overtly wrong, just odd to me, maybe a different way to look at things... No, I'm not talking about their constant calling back to compare with Java (rolls eyes) I'm talking about the two stanza's at the bottom: "C++ Arguments passed as references indicates that null values are not allowed" No, no that's not the point of references, the point is that you do not allocate memory for and copy the values from the passed resource into a local value for us...

Harping back to my prior post about learning to program, when I spoke at my old Uni, I spoke to a lovely trio of ladies, whom wanted to be programmer/computer folks... And one thing struck me, was how narrow their knowledge was. When they asked me how I got into programming and I explained that when I learned to program in the 1990's there was no github, indeed there was no internet, you could not just go and download a program or join an open source project.  If you wanted tool, and had no BBS dial up to find someone with something like it, you wrote your own. I wrote code to record kills in games on the Atari ST, I wrote text editors for the ST and DOS (EGA graphics FTW), I write 2D painting programs for DOS.... I distinctly remember my college tutor seeing my using DOS interrupt 11 to control the mouse and his saying "you're the first person I've seen work that out"... I didn't work it out by trial and error though, I worked it out by reading, about the DOS...

I was asked this very interesting question this week... "Can you learn to be a programmer?"... Lets be clear, the question is can you be a programmer, not can you learn to program.  I believe anyone can learn to use a programming language, to drive their computer to perform a task for them, after all computers are tools and everyone can learn to use any tool. Be a person trying to write a batch script, create a spreadsheet to do their home accounts, throwing together some python to process a few text files or creating a whole compiled program of some kind, pretty much anyone can make themselves, with a book, a little internet searching and enough time, appear on that bell-curve of skill. Does this therefore make everyone a programmer?  I think it most certainly does not.  I can pick up a saw and a hammer, I have in my time knocked out some dovetail joints and repaired the odd chest of draws, does that make me a carpenter?.. NOPE... And likewise, if that self same carpente...

As a programmer I spend a lot of my time either looking at a screen, using a keyboard or both.  As such over the years I've gotten quite particular about both, I like a nice crisp screen (or more than one to be honest) and I like my keyboard to be mechanical and be one I enjoy working with, rubber domed plastic crap from hell... For eight to ten hours a day, no thank you. The screens, today it's easier to get nice screens, so I focus more on what's on them, which will generally be my IDE or text editor of choice on the Operating System I happen to be on at the time. And I've come to loath the themes available in some IDE's but only in very specific circumstances... Lets take the majority one of my time, Microsofts Visual Studio, it comes with a dark and light theme, I like both... I LIKE BOTH... But I like them in different circumstances.  The Dark theme I like when I'm in my own dark room, when it's late at night, when I'm not interacting with others.  ...

A few of you maybe aware of the book on Python I wrote , and published, last year?  And I've had at least one reader get in touch for a second part.  Unfortunately my gaze has passed over Python and returned to where I live.  The world of C++. I have a particular problem with the C++ developers I'm meeting of late, they're either simply not C++ programmers, being an actual mix of good and bad C programmers or just not programmers at all (in one case).  Then even when they are very good C Programmers, there's been a mix of the up-take on ideas and feature benefits of modern C++ itself. Its to and for these fair folk I have begun to write about C++, a new book, based on my own real experience but tempered with where I believe teams and individuals are going wrong when converting their skills to modern C++. For the programmers reading here now, it starts with a chapter zero... Lets take a sneak-peek.... Chapter 0: Introducing C++ It is incredibly hard to introduce the C...

I'm just looking at an old C Compiler, the first C compiler I ever used, actually... And, I'll be honest, I didn't live with C long, I moved into C++ pretty quickly.  So much so, I never actually read the this C Compiler's Documentation, here for posterity, is an exert... Pre-defined Data Types ----------------------       Type        sizeof      Bits            Range       ----        ------      ----            -----   unsigned char      1          8             0 to 255   char               1          8          -128 to 127   enum               2         16      ...

When I say not working, I do not mean the function does not work, of course it works.  What I mean is that left to it's on devices the GCC compiler can actually chose to not perform a memset in certain circumstances, you can read more detail about this in the official bug list . So, what's going on?  Well, I have a piece of code which uses a common buffer, each function locks a mutex (std::lock_guard), fills out the buffer and then transmits over USB to target devices, crucially I then want to clear the common buffer. The purpose of this architecture is to keep sensitive information being transmitted through the buffer present for as little time as possible (i.e. the time between filling out and transmit, ~35ms) rather than filling out, transmitting and leaving the data in the buffer; as the time between calls may be anything up to 5 seconds, plenty of time for someone to halt the program and inspect memory dispositions. In pseudo code therefore our sequence looks something li...