То чому саме так завжди рекомендується використовувати const якомога частіше? Мені здається, що використання const може бути більше болем, ніж допомогою C ++. Але знову ж таки, я підходжу до цього з точки зору пітона: якщо ви не хочете, щоб щось було змінено, не змінюйте цього. Отже, з урахуванням сказаного, …
Я вже неодноразово читав, що забезпечення коректності const у вашому коді C або C ++ - це не тільки хороша практика щодо ремонтопридатності, але також може дозволити вашому компілятору виконувати оптимізацію. Однак я також прочитав повну протилежність - це зовсім не впливає на продуктивність. Отже, чи є у вас приклади, …
Сенс коректності полягає у можливості забезпечити подання екземпляра, який не може бути змінений або видалений користувачем. Компілятор підтримує це, вказуючи, коли ви порушуєте constness із функції const або намагаєтесь використовувати функцію non-const об'єкта const. Тож, не копіюючи підхід const, чи існує методологія, яку я можу використовувати в C #, яка …
Я знаю, що це покращує читабельність і робить програму менш схильною до помилок, але наскільки це покращує продуктивність? І на додаток, яка основна різниця між посиланням та constпокажчиком? Я б припустив, що вони зберігаються в пам'яті по-різному, але як так?
Припустимо, я маю такий тип дзвінка: struct mutable_callable { int my_mutable = 0; int operator()() { // Not const return my_mutable++; } }; Зауважте, що mutable_callable має non-const, operator()що змінює змінну члена ..... Тепер припустимо, що я створюю std::functionсвій тип: std::function<int()> foo = mutable_callable{}; Тепер я можу це зробити: void …
У мене є обгортка для якогось фрагмента спадкового коду. class A{ L* impl_; // the legacy object has to be in the heap, could be also unique_ptr A(A const&) = delete; L* duplicate(){L* ret; legacy_duplicate(impl_, &L); return ret;} ... // proper resource management here }; У цьому застарілому коді функція, …