20.2.5. Порівняння звичайної операції приведення типів з новими чотирма cast-операторами

Комусь з читачів могло б видатися, що описані вище чотири cast-оператори повністю замінюють традиційну операцію приведення типів. І тоді у них може виникнути таке запитання: "Чи варто завжди замість звичайної операції приведення типів використовувати новіші засоби?". Йдеться про те, що загального правила для всіх програмістів не існує. Оскільки нові оператори були створені для підвищення безпеки достатньо ризикованої операції приведення одного типу даних до іншого, багато С++-програмістів переконані у тому, що їх необхідно використовувати виключно з цією метою. І тут важко що-небудь заперечити. Інші ж програмісти вважають, що, оскільки традиційна операція приведення типів слугувала їм "вірою і правдою" протягом багатьох років, то від неї не варто так легко відмовлятися. Наприклад, для виконання простих і відносно безпечних операцій приведення типів (як ті, що потрібні під час виклику функцій введення-виведення read() і write(), описаних у попередньому розділі) "старий добрий" засіб цілком прийнятний.

Існує ще одна точка зору, з якою важко не погодитися: у процесі виконання операцій приведення поліморфних типів безумовно варто використовувати оператор dynamic_cast.

Розділ 21. Поняття про простори імен та інші ефективні програмні засоби

У цьому розділі буде описано основні поняття про простори імен і такі ефективні програмні засоби, як explicit-конструктори, покажчики на функції, static-члени, const-функції|-члени, альтернативний синтаксис ініціалізації членів-даних класу, оператори вказання на члени класу, ключове слово asm, специфікація компонування і функції перетворення.

21.1. Простори імен

Простір імен визначає деяку декларативну область.

Простори імен стисло розглянуто у розд. 2. Там було сказано, що вони дають змогу локалізувати імена ідентифікаторів, щоб уникнути конфліктних ситуацій з ними. У С++-середовищі програмування використовується величезна кількість імен змінних, функцій та імен класів. До введення поняття простору імен всі ці імена конкурували між собою за пам'ять в глобальному просторі імен, що і було причиною виникнення багатьох конфліктів. Наприклад, якби у Вашій програмі було визначено функцію toupper(), то вона могла б (залежно від переліку параметрів) перевизначити стандартну бібліотечну функцію toupper(), оскільки обоє імен мали б зберігатися в глобальному просторі імен. Конфлікти з іменами виникали раніше також під час використання однією програмою декількох бібліотек сторонніх виробників. У цьому випадку ім'я, що є визначеним у одній бібліотеці, конфліктувало з таким самим іменем з іншої бібліотеки. Така ситуація особливо неприйнятна під час використання однойменних класів. Наприклад, якщо у Вашій програмі визначено клас VideoMode, і в бібліотеці, що використовуються Вашою програмою, визначено клас з таким самим іменем, то конфлікту не уникнути.

Для вирішення описаної проблеми було створено ключове слово namespace. Оскільки воно локалізує видимість оголошених у ньому імен, то це означає, що простір імен дає змогу використовувати одне і те саме ім'я в різних контекстах, не викликаючи при цьому конфлікту імен. Можливо, найбільше від нововведення "поталанило" С++-бібліотеці стандартних функцій. До появи ключового слова namespace (яке було, звичайно ж, єдиним) всю С++-бібліотеку було визначено в глобальному просторі імен. З настанням namespace-''ери" С++-бібліотека визначається у власному просторі імен, що іменується std, який значно знизив ймовірність виникнення конфліктів імен. У своїй програмі програміст повинен створювати власні простори імен, щоб локалізувати видимість тих імен, які, на його думку, можуть стати причиною конфлікту. Це особливо важливо, якщо Ви займаєтеся створенням бібліотек класів або функцій.