A lexikális elemekre ugyanaz a szintaktika vonatkozik mint a C++ nyelvben, kivéve az alábbi bővítéseket:
Kulcsszó használata azonosítóként. Előfordulhat, hogy szükségünk van egy más nyelven írt könyvtárbeli típusra, és ez véletlenül megegyezik egy kulcsszóval. Ilyenkor a fordítónak tudnia kell, hogy az a szándékozni kívánt típus azonosítója nem egy kulcsszó, hanem egy azonosító, különben fordítási hibát kapunk. Erre a célra bevezették az __identifier kulcsszót, mely az argumentumában egy kulcsszót vár.
Az alábbi példában egy operator nevű osztályt akarunk példányosítani, amely az operator.dll könyvtárban van megvalósítva:
Karakterláncok. Többféle sztring literál szerepelhet, a hagyományoson kívűl:
Az ANSI (nincs prefix) és a UNICODE (L prefixszel) sztring már ismerős lehet, a .NET (S prefixszel) sztringek újak, jobb teljesítményt nyújtanak mint a hagyományos C++ sztring literálok. A teljesen megegyező karakterláncok példányai ugyanarra a sztring objektumra mutatnak. A következő példa szemlélteti ezt a tulajdonságot:
A futtatás eredménye:
Fontos tulajdonság: C++ sztringeket bárhol használhatunk ott ahol .NET sztringeket használnánk, de fordítva nem működik.
Vegyük észre, hogy a fenti kódban használtuk a printf parancsot. Pusztán azért mert .NET típusokat és metódusokat használunk, nem jelenti azt, hogy elveszítjük a hagyományos felügyeletlen könyvtárainkat.
A C++/CLI tervezésekor a kód hordozhatóságát alárendelték a kód olvashatóságának. Ellentétben a Managed C++-al, több új nyelvi elemet is bevezettek a .NET programozás támogatására:
Új koncepció a "több szavas token", melyet whitespace-el törnek meg a közepén (pl. "ref class"); a ref önmagában csak egy azonosító. Az egyszavas tokenek többsége pedig környezet-érzékeny.
Az újonnan bevezetett kulcsszavak __-vel kezdődnek Managed C++-ban, és önmagukban állnak C++/CLI-ben, pl.: __abstract és abstract. Ahol nincs lényeges eltérés, nem térek ki külön a különbségekre.