Зауваження. Присвоєння x=x інколи вважають синонімом порожнього оператора. Чи завжди воно безпечне? Для фундаментальних типів — так. Проте з оглядом на майбутнє зауважимо, що у разі програмованих типів обчислення лівобічного значення може призвести до руйнування правобічного (див. підрозділ 4.6.3).
2.3.3. Перетворення типів
Тепер звернімося до проблеми, якої за строгої типізації не мало б бути, а саме до перетворення типів. Воно виникає, зокрема, у мішаних арифметичних виразах, що водночас містять об’єкти різних числових типів. Навіть у мовах програмування зі скромним набором числових типів (один цілий і один дійсний тип) виникає проблема обчислення мішаних виразів вигляду k*x, де k — ціле число, а x — дійсне. Оскільки результат має бути дійсний, то доцільно виконати перетворення величини k до дійсного типу та застосувати операцію множення дійсних чисел. До того ж навряд чи можна очікувати, що в наборі команд комп’ютера є арифметичні операції для всіх можливих комбінацій арифметичних типів. Тому для виконання будь-якої операції над числовими даними різних типів доводиться здійснювати потрібні зведення типів. Так, щоб додати коротке ціле число до довгого, його перетворюють на довге. Щоб помножити ціле число на дійсне, його слід перетворити на дійсне. Як виконати додавання короткого та довгого дійсних чисел? Спочатку необхідно зробити з короткого дійсного числа довге, потім визначити тип результату залежно від типу об’єкта, що його зберігатиме.
Так у програмі виникають неявні перетворення типів (implicit type conversion), про окремі з яких компілятор може попереджати, водночас залишаючи інші непоміченими. Строга типізація, узагалі кажучи, мала б заборонити використання мішаних виразів і, відповідно, неявних перетворень. Однак традиція перетворень так укоренилися, що типізації довелося поступитися. Із перетвореннями типів ми знову зустрінемося в об’єктному програмуванні.
У мові C++ діє концепція розширення типу (promotion), згідно з якою в разі змішування типів простіші перетворюються на складніші, які забезпечують ширший діапазон значень. У разі одночасного використання аргументів різних типів у виразах компілятор, де це потрібно, автоматично перетворює типи. Так, якщо арифметичні операції виконують над інтегральними типами (наприклад, char і short), вони розширюються до цілого типу int; коротші дійсні типи перетворюються на відповідні довші. Якщо йдеться про виконання присвоєння, то обчислений у правій частині результат перед зберіганням набуде типу лівобічного значення value.
Окрім неявних можливі також явні перетворення типів (type cast) за допомогою кількох особливих операцій перетворення. Зокрема, мова C++ успадкувала від C дві «старомодні» операції: вирази int(monday) та (int)monday перетворюють константу monday типу week на значення цілого типу. Обернене перетворення — (week)i чи week (i).
Зауваження. Перетворення типів у програмах, узагалі кажучи, небажані — передусім тому, що вони не завжди коректні. Хотілося б принаймні мати можливість контролювати всі перетворення, які відбуваються в програмі. При цьому особливо небезпечними вважаються «старомодні» перетворення. Проблема в тому, що вони замасковані: немає іншого ефективного способу виявляти місця, де вони виконуються, окрім як перечитати всі тексти.
Власні перетворення мова С++ виконує більш диференційовано за допомогою операцій const_cast, dynamic_cast, reinterpret_cast і static_cast, кожна з яких має спеціальне призначення. Останнє перетворення, наприклад static_cast (monday), діє так, як аналогічне перетворення в мові C. Його статичність означає, що всі потрібні перевірки виконуються на етапі компіляції. Це найнадійніше з перетворень. Призначення інших перетворень розглянемо пізніше.
Перевага явного позначення для операцій перетворення полягає в тому, що їх можна легко знайти в програмі, виконавши простий пошук за словом «_cast».
2.4. Указники
Програмування роботи з пам’яттю — найважливіша і разом з тим найнебезпечніша з погляду надійності частина C/C++-програм. Якщо до розглянутих раніше сталих і змінних можна застосувати термін пряме адресування, оскільки імена адресують значення безпосередньо (direct addressing), і відповідальність за зв’язок змінної з її адресою несе компілятор, то указники(pointers) роблять це непрямо (indirect addressing), а за коректність адреси відповідає сама програма. Якщо проаналізувати можливі джерела помилок при застосуванні прямої адресації порівняно з непрямою, то побачимо, що до помилок, викликаних неініціалізованими змінними чи указниками, будуть додані помилки обчислення адрес. Володіння технікою програмування указників — своєрідний «вищий пілотаж» у процедурному програмуванні.
2.4.1. Указник як засіб непрямого адресування
Щоб указник мав значення, попередньо потрібно надати йому це значення, зв’язавши указник з адресою певного місця пам’яті. Якщо воно невідоме на момент визначення указника, то слід ініціалізувати його нулем. На рис. 2.1 наведено приклад визначення й ініціалізації указника, значення якого — нульова адреса. 

Говорять, що такий указник на жодне місце в пам’яті не вказує, а тому його значення невизначене. Невизначений указник певною мірою безпечний, оскільки рівність нулеві можна перевірити. Він стає небезпечним (призводить до аварійного завершення програми) у разі спроби звернутися до значення, що міститься за нульовою адресою.
Невизначений указник не слід плутати із «засміченим» (теж у певному розумінні невизначеним або, точніше кажучи, визначеним некоректно). Якщо звичайну змінну було визначено без ініціалізації, наприклад так:
double х;
чого за правилами гарного тону слід уникати, то для неї відведено місце, до якого ще не потрапило змістовне значення: відповідна область пам’яті просто містить «сміття». Маємо коректне лівобічне та невизначене правобічне значення змінної. Так само незаданим або, інакше кажучи, «засміченим» буде значення неініціалізованого указника px. Однак у такому разі воно набагато небезпечніше, тому що може виявитись адресою області пам’яті, не призначеної чи навіть забороненої для використання за допомогою цього указника. Некоректним у такому разі стає лівобічне значення, а питання коректності правобічного за цієї умови вже навіть не виникає: наслідки можуть стати непередбачуваними (рис. 2.2). Указники, що ведуть «у нікуди», називають завислими (dangling pointer):
double* px;

Зауваження. Розглядаючи техніку роботи з указниками, можна провести аналогію між структурами керування та структурами даних. Як уже було сказано під час вивчення парадигм, структуроване програмування повністю витіснило з практики вживання оператора переходу goto. Так само, як оператор переходу призводить до важко контрольованих передавань керування в програмі, використання указників може спричинити виникнення несистематизованих зв’язків між даними. Тому під час роботи з пам’яттю потрібно скрізь, де це можливо, надавати перевагу безпечнішим рішенням, наприклад відсилкам (підрозділ 2.5), особливо якщо мова йде про передавання параметрів. Проте це виходить за межі можливостей мови C. Тому, дотримуючись її правил, доводиться використовувати звичайні указники, особливо для обміну значеннями параметрів. При цьому варто дотримуватися дисципліни програмування, яка б виключала виникнення некоректних значень указників. Від багатьох помилок убезпечують найпростіші правила: указник потрібно ініціалізувати в момент створення (невизначений указник ініціалізується нулем) і знову робити невизначеним у разі видалення значення, на яке він указував. Далі (у підрозділі 5.5) будуть запропоновані безпечніші рішення, що ґрунтуються на використанні вдосконалених безпечних інтелектуальних указників.
Указники, подібно до будь-яких інших змінних, мають значення, але це лише адреси, що вказують на самі дані. У попередньому прикладі указник px містить «сміття», а тому вказує невідомо на що. Важко уявити, до яких наслідків може призвести спроба записати дані за такою адресою. У кращому випадку це спричинить вихід за межі пам’яті, в гіршому — потрапляння до не призначеної для програми області й, можливо, ненавмисного псування життєво важливих даних.