A posztsorozatban olyan tipikus programozási, konkrétabban kódolási hibákat, később szemantikai hibákat vesézek ki, amikkel szinte biztos, hogy szembesül az, akinek a C vagy a C++ az első programozási nyelve. A felsorolás persze szubjektív, a számomra legemlékezetesebb hibákat tárgyaljam, de többször puskázok Dennis Ritchie,  Bjarne Stroustrup alapműveire, amiben fel is hívják a figyelmet egy-egy hibalehetőségre, ezen kívül Koenig C csapdák és buktatók, és Dewhurst C++ hibaelhárító című könyeire.

A makró szigorúan nézve nem is a programozási nyelv része, hanem csak a fejlesztő munkáját segítő eszköz, amikor a fordító egyszerűsítve a fejlesztő által makróban meghatározott szöveggel cseréli le a forráskód összes, makróval hivatkozott részét.

Ennél egyszerűbb nem is lehetne, ugye? Természetesen ebben is van hibalehetőség az igen szigorú szintaxis miatt, ráadásul esetenként éppen olyan hibát eredményez, ami miatt a tanonc a hibát teljesen máshol kezdi el keresni, mint ahol az ténylegesen van, függően a makróban meghatározott szövegtől. Hogy még bonyolultabb legyen, esetenként implementációfüggő, hogy a fordító hogyan kezelje a makrókat.

A makró meghatározásának általános sémája:

Ami viszont nagyon nem mellékes, hogy a fordító véresen komolyan veszi, hogy a #define után egy szóközzel van elválasztva a makró neve és attól pontosan egy szóközzel van elválasztva a makró értéke, ami már mellékes, hogy mennyi szóközt tartalmaz, elvben, de arról később.

Vegyük az alábbi példát:

Ha nem tudjuk az előbb ismertetett ökölszabályt, akkor azt hihetnénk, hogy a

előfordulási helyén majd mindenhol az ((a)+1)-t építi be a fordító, valójában viszont ha a makrót úgy kezeljük, mintha függvény lenne a behívás helyén valami ilyesmi épülne be:

Ami teljesen világos, hogy mást csinál, ráadásul ez itt egy nagyon egyszerű eset.

A C-nél a C++nál gyorsan hozzá lehet szokni, hogy a forráskódban a szóköz gyakran csak szellősebbé teszi a forráskódot, ez a makróknál nem így van.