Чому розумні покажчики так популярні?

Як я бачу, розумні покажчики широко використовуються у багатьох реальних проектах C ++.

Хоча якісь розумні покажчики, очевидно, вигідні для підтримки RAII та передачі права власності, також існує тенденція використання спільних покажчиків за замовчуванням як способу "вивезення сміття" , так що програмісту не доведеться думати про те, щоб розподілити стільки .

Чому спільні покажчики популярніші, ніж інтеграція належного сміттєзбірника, як Boehm GC ? (Або ти взагалі згоден, що вони популярніші, ніж фактичні ГК?)

Я знаю про дві переваги звичайних ГК перед підрахунком довідок:

• Звичайні алгоритми GC не мають проблем з еталонними циклами .
• Підрахунок посилань, як правило, повільніше, ніж власний GC.

Які причини використання інтелектуальних покажчиків для підрахунку довідок?

Деякі переваги довідкового підрахунку щодо вивезення сміття:

1. Низькі накладні витрати. Збирачі сміття можуть бути досить нав'язливими (наприклад, змусити вашу програму заморожуватись у непередбачувані часи, поки цикл збору сміття обробляється) та досить об'ємною пам'яттю (наприклад, слід пам’яті вашого процесу без необхідності зростає до багатьох мегабайт, перш ніж збирання сміття нарешті починається)

2. Більш передбачувана поведінка. За допомогою підрахунку посилань ви гарантуєте, що ваш об'єкт буде звільнений миттєво, коли остання посилання на нього піде. З іншого боку, зі збиранням сміття ваш об’єкт буде звільнений "колись", коли система обійде його. Для оперативної пам'яті це зазвичай не є великою проблемою на настільних комп'ютерах або слабо завантажених серверах, але для інших ресурсів (наприклад, ручки файлів) вам часто потрібно їх закрити як можна швидше, щоб потім уникнути можливих конфліктів.

3. Простіше. Підрахунок посилань можна пояснити за кілька хвилин, а здійснити через годину-дві. Збирачі сміття, особливо з гідними робочими характеристиками, надзвичайно складні, і мало хто їх розуміє.

4. Стандартний. C ++ включає підрахунок посилань (через shared_ptr) та друзів у STL, це означає, що більшість програмістів на C ++ знайомі з ним, і більшість C ++ код буде працювати з ним. Однак немає жодного стандартного сміттєзбірника C ++, це означає, що вам потрібно вибрати його і сподіватися, що він добре працює для вашого випадку використання - і якщо це не так, це вирішити проблему, а не мову.

Щодо передбачуваних недоліків підрахунку еталонів - не виявлення циклів - це проблема, але така, з якою я ніколи особисто не стикався за останні десять років використання підрахунку еталонів. Більшість структур даних є природно ациклічними, і якщо ви стикаєтесь із ситуацією, коли вам потрібні циклічні посилання (наприклад, батьківський вказівник у дереві), ви можете просто використовувати слабкий_птр або необроблений вказівник С для "зворотного напрямку". Поки ви знаєте про потенційну проблему під час проектування своїх структур даних, це не проблема.

Щодо продуктивності, у мене ніколи не було проблем із виконанням довідкового підрахунку. У мене виникли проблеми з виконанням збору сміття, зокрема з випадковими заморозками, які може спричинити GC, і єдине рішення ("не виділяти об'єкти") може бути також перефразоване як "не використовувати GC" .

Щоб отримати хороші показники роботи в GC, GC повинен мати можливість переміщати об'єкти в пам'яті. Такою мовою, як C ++, де ви можете безпосередньо взаємодіяти з місцями пам'яті, це майже неможливо. (Microsoft C ++ / CLR не враховується, оскільки він вводить новий синтаксис для покажчиків, керованих GC, і таким чином фактично є іншою мовою.)

Boehm GC, хоча витончена ідея, насправді є найгіршим з обох світів: вам потрібен malloc (), який повільніше, ніж хороший GC, і таким чином ви втрачаєте детерміновану поведінку розподілу / делокації без відповідного підвищення продуктивності покоління GC . Крім того, він необхідний консервативний, так що не обов’язково збирати все сміття.

Гарний, добре налаштований GC може бути чудовою справою. Але у такій мові, як C ++, виграші мінімальні, а витрати часто просто не варті.

Однак буде цікаво побачити, як C ++ 11 стає більш популярним, чи починають лямбди та семантику захоплення вести спільноту C ++ до тих самих проблем розподілу та життєвого циклу об'єктів, які спричинили спільноту Lisp винаходити GC в першу чергу місце.

Дивіться також мою відповідь на пов’язане питання на StackOverflow .

Як я бачу, розумні покажчики широко використовуються у багатьох реальних проектах C ++.

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

Хоча якісь розумні покажчики, очевидно, вигідні для підтримки RAII та передачі права власності, також існує тенденція використання спільних покажчиків за замовчуванням як способу "вивезення сміття", так що програмісту не потрібно думати про те, щоб розподілити стільки .

Це погана ідея, оскільки вам все одно потрібно турбуватися про цикли.

Чому спільні покажчики популярніші, ніж інтеграція належного сміттєзбірника, як Boehm GC? (Або ти взагалі згоден, що вони популярніші, ніж фактичні ГК?)

Ох, так багато речей не так з вашим мисленням:

1. GC Boehm - це не "належний" GC в будь-якому сенсі цього слова. Це справді жахливо. Він консервативний, тому він протікає і неефективний по конструкції. Дивіться: http://flyingfrogblog.blogspot.co.uk/search/label/boehm

2. Об'єктивно вказівники об'єктивно ніде не такі популярні, як GC, оскільки переважна більшість розробників зараз використовує мови GC'd і не мають потреби в загальних вказівниках. Подивіться на Java та Javascript на ринку праці порівняно з C ++.

3. Ви, здається, обмежуєте розгляд C ++, оскільки, я припускаю, ви вважаєте, що GC - це дотична проблема. Це не ( єдиний спосіб отримати гідний GC - це спроектувати мову та VM для неї з самого початку), тому ви вводите упередженість вибору. Люди, які дуже хочуть належного збору сміття, не дотримуються C ++.

Які причини використання інтелектуальних покажчиків для підрахунку довідок?

Ви обмежені на C ++, але хочете, щоб у вас було автоматичне управління пам'яттю.

У MacOS X та iOS, а також у розробників, які використовують Objective-C або Swift, підрахунок посилань популярний, оскільки він обробляється автоматично, а використання сміття значно зменшилось, оскільки Apple більше не підтримує його (мені кажуть, що програми використовують збирання сміття буде порушено в наступній версії MacOS X, а збір сміття ніколи не реалізовувався в iOS). Я насправді серйозно сумніваюся, що коли-небудь було багато програмного забезпечення, яке використовувало збирання сміття, коли воно було доступне.

Причина позбавлення від збирання сміття: він ніколи не працював надійно в середовищі стилю С, де вказівники могли «втекти» на місця, недоступні сміттєзбірникам. Apple твердо вірить і вважає, що підрахунок посилань відбувається швидше. (Ви можете робити будь-які претензії щодо відносної швидкості, але Apple ніхто не зміг переконати). І врешті-решт, ніхто не використовував збирання сміття.

Перше, що дізнається будь-який розробник MacOS X або iOS - це керувати еталонними циклами, тому це не є проблемою для справжнього розробника.

Найбільший недолік збирання сміття в C ++ полягає в тому, що це неможливо отримати правильно:

• У програмі C ++ вказівники не живуть у власній спільноті, а їх змішують з іншими даними. Таким чином, ви не можете відрізнити покажчик від інших даних, які, як буває, мають бітовий шаблон, який можна інтерпретувати як дійсний вказівник.

  Наслідок: Будь-який збирач сміття C ++ буде просочувати предмети, які слід збирати.

• У C ++ ви можете робити арифметику вказівника для отримання покажчиків. Таким чином, якщо ви не знайдете вказівник на початок блоку, це не означає, що на цей блок не можна посилатися.

  Наслідок: Будь-який збирач сміття C ++ повинен враховувати ці коригування, трактуючи будь-яку послідовність бітів, яка трапляється в будь-якій точці блоку, включаючи відразу після закінчення, як дійсний покажчик, на який посилається блок.

  Примітка: жоден C ++ збирач сміття не може обробляти код такими хитрощами:

  int* array = new int[7];
  array--;    //undefined behavior, but people may be tempted anyway...
  for(int i = 1; i <= 7; i++) array[i] = i;
  

  Правда, це викликає невизначене поведінку. Але якийсь існуючий код є більш розумним, ніж корисний, і він може викликати попереднє переселення сміттєзбірником.