sutton050

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

A long time ago, in an office far away from where I now sit, I once worked with a chap I still refer to as the best programmer I've ever met. This was a guy who could take the whole code base, in Delphi, home and over a single weekend re-write it in Java. This was a guy who I saw, from scratch, write a C controller for an embedded PIC to capture an image from a supposedly incompatible TTL driven camera and then an analyzer for the captured images which would detect and show motion, making for our common employer their best ever selling product a cheap security motion detection system, which didn't rely on relatively expensive high resolution cameras. It was awe inspiring as a newly graduated programmer, whom had a huge background in DOS programming, but whom had never worked in Enterprise level development before. I sat next to what I still regard as near genius. This very same chap was also the worst programmer I've ever worked with. Because he was so highly functioning he

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        -32768 to 32767   unsigned short     2         16             0 to 65535   short              2         16        -32768 to 32767   unsigned int       2         16             0 to 65535   int                2         16        -32768 to 32767   unsigned long      4         32             0 to 4294967295   long               4         32   -2147483648 to 2147483647   <pointer>          4         32  

This is a plea, from the bottom of my rotten black heart, please... Please... PLEASE stop miss using the inline directive in your C and C++. Now, I can't blame you for this, I remember back in the 90's being actually taught (at degree level) "use inline to make a function faster", and this old lie still bites today. inline does not make your function faster, it simply forces the compiler to insert "inline" another copy of the same code whenever you call it, so this code: #include <iostream> inline void Hello() {     std::cout << "Hello"; } int main () {     Hello();     Hello();     Hello(); } Turns into the effective output code of: int main () {     std::cout << "Hello";     std::cout << "Hello";     std::cout << "Hello"; } What does this mean in practice?  Well, you saves yourself a JMP into the function, and the position on the stack holding the return address, and the RET from the fun

I'm having difficulty communicating with some folks about the beauty of cmake and using ccmake to leverage that beauty. These are folks whom are either completely ignorant of what a makefile should look like, are happy to manage their own or at worst case are folks put off of makefiles by having inherited projects which have spiralled out of control with mammoth makefiles and a propensity to being so complex as to prevent any cost-effective entry grade for new developers to key into - i.e. they're too hard to learn, or obfuscated sufficiently to allow established developers to retain their positions of glory and power. I don't subscribe to that ethos however, and believe that as a leader in development you should facilitate everyone to be being able to do everyone else's development role, be that starting a new project or continuing an old. It perhaps comes from my being able to work alone and defining a role which others are then keyed into, I have been forced to allow

I'm going to be controvertial... Nothing new about that, but here is comes... Are you ready? If you are a C++ programmer, and you are using sprintf, you are not writing C++. There, I've said it, I can't take it back.  Obviously now, I need to qualify this statement, so lets begin.  Obviously, I am over simplifying, and C++ programs can contain calls to sprintf and still be put through the C++ compiler to receive working object code, so I'm not discounting the use of sprintf in C++ programs. What I'm trying to tell you is that, if you are writing C++, designing C++, and sprintf is your goto method of truncating and outputting various raw data formats together as a string, then you are NOT thinking C++. You are infact thinking C... Lets hear why this might be a bad idea... Its about how you are thinking, you are not thinking in the skill-set you think you are.  And though I make a point about sprintf, I am talking about anything within C, if you happen to elect to use

What does " const " mean to you?  Does it just mean a value can not be changed?  If so, you may want to read on! Const is one of those things, which though not unique to C++ is given more meaning when you leverage C++ fully, const allows you to not only define a value as invariant, but also to instruct other programmers coming to your code how a value should be used, how when it is passed as a parameter it should be treated and ultimately how to protect data from needless alteration, de-synchronisation or simple corruption. Const is therefore your friend, and if you've come to C++ from C, Java, C#, Python or one of the other myriad of languages which don't treat const with as much relevance as C++ you may want to read more than I can say on the topic.  Bjarne Stroustrop (the inventor of C++) and other authors on the topic (notably Scott Meyers & Herb Sutter) explain in much more detail than I ever could, but for brevity here are two examples of const from my own c

Whilst cutting code I employ a coding style, which I enforce, whereby I output the scope of the variable being used with a prefix. "l_" for Local "m_" for Member "c_" for constant "e_" for enum And so forth, for static, parameter and a couple of others.  I also allow compounds of these, so a static constant would be: "sc_" This is useful in many languages, and imperative in those which are not type strict, such as Python. Some confuse this with "Hungarian Notation", it's not.  Hungarian notation is the practice of prefixing a type notification to the variable name, for example "an integer called count" might be "iCount". I have several problems with anyone using Hungarian Notation, and argue against it thus. With modern code completion and IDE lookup tools this is really not needed, with useful and meaningful naming of your variables the type is not needed and finally there are multiple types with the s