Як давній програміст C #, нещодавно я прийшов дізнатися більше про переваги придбання ресурсів - це ініціалізація (RAII). Зокрема, я виявив, що ідіома C #:

using (var dbConn = new DbConnection(connStr)) {
    // do stuff with dbConn
}

має еквівалент С ++:

{
    DbConnection dbConn(connStr);
    // do stuff with dbConn
}

Це означає, що запам'ятовувати, щоб укласти використання ресурсів, таких DbConnectionяк usingблок, непотрібне в C ++! Це здається головною перевагою C ++. Це ще більш переконливим , якщо врахувати , клас , який має елемент примірника типу DbConnection, наприклад ,

class Foo {
    DbConnection dbConn;

    // ...
}

У C # мені потрібно було б реалізувати Foo IDisposableяк таке:

class Foo : IDisposable {
    DbConnection dbConn;

    public void Dispose()
    {       
        dbConn.Dispose();
    }
}

і що ще гірше, кожен користувач програми Fooповинен пам’ятати, щоб укласти його Fooв usingблок, наприклад:

   using (var foo = new Foo()) {
       // do stuff with "foo"
   }

Тепер, дивлячись на C # та його корені Java, мені цікаво ... чи розробники Java цілком оцінили те, від чого вони здавались, коли вони відмовились від стека на користь купи, відмовившись від RAII?

(Так само, чи Строуструп повністю оцінив значення RAII?)

Тепер, дивлячись на C # та його корені Java, мені цікаво ... чи розробники Java цілком оцінили те, від чого вони здавались, коли вони відмовились від стека на користь купи, відмовившись від RAII?

(Так само, чи Строуструп повністю оцінив значення RAII?)

Я впевнений, що Гослінг не отримав значення RAII під час створення Java. У своїх інтерв'ю він часто розповідав про причини відмови від дженерики та перевантаження операторів, але ніколи не згадував детермінованих деструкторів та RAII.

Як не дивно, навіть Строуструп не усвідомлював важливості детермінованих деструкторів у той час, коли він їх розробляв. Я не можу знайти цю цитату, але якщо ви насправді в ній можете знайти її серед його інтерв'ю тут: http://www.stroustrup.com/interviews.html

Так, дизайнери C # (і, я впевнений, Java) спеціально вирішили проти детермінованої доопрацювання. Я запитав Андерса Хейльсберга про це кілька разів у 1999-2002 роках.

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

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

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

У C # у вас є usingключове слово, яке з’явилося досить пізно в дизайні того, що стало C # 1.0. Вся IDisposableсправа досить жалюгідна, і хтось замислюється, чи було б більш елегантним usingпрацювати з синтаксисом деструктора C ++, який ~позначає ті класи, до яких IDisposableможна автоматично застосувати шаблон плит котла ?

Майте на увазі, що Java була розроблена в 1991-1995 роках, коли мова C ++ була значно іншою. Винятки (які зробили необхідний RAII ) та шаблони (що полегшило реалізацію розумних покажчиків) - це "новомодні" функції. Більшість програмістів на C ++ походили з C та звикли робити ручне управління пам'яттю.

Тому я сумніваюся, що розробники Java навмисно вирішили відмовитися від RAII. Однак для Java було зваженим рішенням віддавати перевагу референтній семантиці замість значущої семантики. Детерміновані руйнування важко здійснити мовою довідкової семантики.

То навіщо використовувати опорну семантику замість семантики значень?

Тому що це робить мову набагато простішою.

• Немає необхідності в синтаксичному розрізненні між Fooі Foo*або між foo.barі foo->bar.
• Немає потреби в перевантаженому призначенні, коли все завдання - це скопіювати покажчик.
• Немає потреби в конструкторах копій. ( Іноді виникає необхідність у чіткій функції копіювання, наприклад clone(). Багато об'єктів просто не потрібно копіювати. Наприклад, незмінні речі не роблять.)
• Не потрібно оголошувати privateконструктори копій і operator=робити клас, який не можна скопіювати. Якщо ви не хочете, щоб об’єкти класу були скопійовані, ви просто не записуєте функцію для його копіювання.
• У swapфункціях немає потреби . (Якщо ви не пишете якусь рутину.)
• Немає необхідності в C ++ 0x-стилі посилання на рецензію.
• Немає потреби в (N) RVO.
• Проблеми з нарізанням немає.
• Компілятору простіше визначити макети об’єктів, оскільки посилання мають фіксований розмір.

Основним недоліком еталонної семантики є те, що коли кожен об'єкт потенційно має кілька посилань на нього, стає важко знати, коли його видалити. Ви майже повинні мати автоматичне управління пам'яттю.

Java вирішила використовувати недетермінований збирач сміття.

Чи не може GC бути детермінованим?

Так, це може. Наприклад, C-реалізація Python використовує підрахунок посилань. А пізніше додано відстежувати GC для обробки циклічного сміття там, де знижки не вдається.

Але перерахунок рахунків жахливо неефективний. Багато оновлених процесорних циклів витрачалось на оновлення підрахунків. Ще гірше в багатопотоковому середовищі (на зразок виду Java, призначеного для), де ці оновлення потрібно синхронізувати. Набагато краще використовувати нульовий збірник сміття, поки вам не потрібно перейти на інший.

Можна сказати, що Java вирішила оптимізувати загальний випадок (пам'ять) за рахунок таких, що не є запальними ресурсами, як файли та сокети. Сьогодні, з огляду на прийняття RAII в C ++, це може здатися неправильним вибором. Але пам’ятайте, що значна частина цільової аудиторії для Java були програмістами C (або "C з класами"), які використовувались для явного закриття цих речей.

А як щодо C ++ / CLI "стек об'єктів"?

Вони просто синтаксичний цукор дляDispose ( оригінальне посилання ), як C # using. Однак це не вирішує загальну проблему детермінованого знищення, оскільки ви можете створити анонімний, gcnew FileStream("filename.ext")і C ++ / CLI не буде автоматично розпоряджатися нею.

Java7 представив щось подібне до заявки C # using: Пробні ресурси

tryзаяву , яке оголошує один або кілька ресурсів. Ресурс як об'єкт , який повинен бути закритий після того, як програма закінчить з ним. Заява- trywith-Resources забезпечує закриття кожного ресурсу в кінці оператора. Будь-який об'єкт, який реалізує java.lang.AutoCloseable, який включає всі об'єкти, які реалізує java.io.Closeable, може бути використаний як ресурс ...

Тож я гадаю, що вони або свідомо не вирішили не впроваджувати RAII, або тим часом змінили свою думку.

У Java навмисно немає об'єктів на основі стека (він же значень-об'єктів). Вони необхідні для автоматичного знищення об'єкта в кінці методу.

Через це і той факт, що Java збирається сміттям, детермінована доопрацювання більш-менш неможлива (наприклад, що робити, якщо на мій "локальний" об'єкт посилається десь інше? Тоді, коли метод закінчиться, ми не хочемо, щоб він був знищений ) .

Однак це добре в більшості з нас, тому що майже ніколи не виникає необхідності в детермінованій доопрацюванні, крім випадків взаємодії з рідними (C ++) ресурсами!

Чому у Java немає об'єктів на основі стека?

(Крім примітивів ..)

Тому що об'єкти на основі стека мають іншу семантику, ніж посилання на основі купи. Уявіть наступний код у С ++; що воно робить?

return myObject;

• Якщо myObjectце локальний об'єкт на основі стека, викликається конструктор копіювання (якщо результат присвоюється чомусь).
• Якщо myObjectце локальний об'єкт на основі стека, і ми повертаємо посилання, результат не визначений.
• Якщо myObjectце член / глобальний об'єкт, викликається конструктор копіювання (якщо результат присвоюється чомусь).
• Якщо myObjectє членом / глобальним об'єктом, а ми повертаємо посилання, повертається посилання.
• Якщо myObjectвказівник на локальний об'єкт на основі стека, результат не визначений.
• Якщо myObjectвказівник на член / глобальний об'єкт, цей покажчик повертається.
• Якщо myObjectвказівник на об'єкт на основі купи, цей покажчик повертається.

Тепер, що робить той же код у Java?

return myObject;

• Посилання на myObjectповертається. Не має значення, чи змінна локальна, членська чи глобальна; і немає жодних предметів на основі стека або випадкових покажчиків, яких слід турбувати.

Сказане вище показує, чому об’єкти на основі стека є дуже частою причиною помилок програмування в C ++. Через це дизайнери Java вивели їх; і без них немає сенсу використовувати RAII на Java.

Опис ваших отворів usingнеповний. Розглянемо таку проблему:

interface Bar {
    ...
}
class Foo : Bar, IDisposable {
    ...
}

Bar b = new Foo();

// Where's the Dispose?

На мою думку, не мати RAII та GC була поганою ідеєю. Якщо справа доходить до закриття файлів на Java, вона там malloc()і free()там.

Я досить стара. Я був там і бачив це і багато разів бив головою про це.

Я був на конференції в парку Херслі, де хлопці IBM розповідали нам, наскільки чудовою була ця абсолютно нова мова Java, лише хтось запитав ... чому не існує деструктора для цих об’єктів. Він не мав на увазі те, що ми знаємо як деструктора в C ++, але не було і фіналізатора (або у нього були фіналізатори, але вони в основному не працювали). Це повернення назад, і ми вирішили, що Java в цій точці була трохи іграшковою мовою.

тепер вони додали Finalisers до мовної специфікації, і Java побачила деяке прийняття.

Звичайно, пізніше всім сказали не ставити фіналізаторів на свої об'єкти, оскільки це надзвичайно сповільнило ГК. (як це потрібно було не тільки заблокувати купу, але перемістити об'єкти, що підлягають завершенню, до тимчасової області, оскільки ці методи не можна було викликати, оскільки GC призупинила роботу програми. Замість цього вони будуть викликані безпосередньо перед наступним Цикл GC) (і ще гірше, іноді фіналізатор ніколи не зателефонував би, коли програма закривалася. Уявіть, ніколи не закриваєте обробку файлів)

Тоді у нас був C #, і я пам’ятаю дискусійний форум на MSDN, де нам сказали, наскільки чудова ця нова мова C #. Хтось запитав, чому немає детермінованої доопрацювання, і хлопці з MS розповіли нам, як нам такі речі не потрібні, потім сказали нам, що нам потрібно змінити спосіб розробки програм, потім сказали нам, наскільки дивовижним є GC та як усі наші старі програми сміття і ніколи не працювало через всі кругові посилання. Тоді вони піддалися тиску і сказали нам, що вони додали цю схему ідентифікації до специфікації, яку ми могли б використати. Я подумав, що в цей час ми повернулися до ручного управління пам'яттю в додатках C #.

Звичайно, пізніше хлопці з MS виявили, що все, що вони нам сказали, це ... ну, вони зробили IDispose трохи більше, ніж просто стандартний інтерфейс, а пізніше додали оператор use. W00t! Вони зрозуміли, що детермінованої доопрацювання все-таки щось не вистачає в мові. Звичайно, ви все ще повинні пам’ятати, щоб розмістити його скрізь, тому його все-таки трохи посібник, але це краще.

То чому вони зробили це, коли їм могло було використовувати семантику стилю автоматично, розміщену на кожному блоці області з самого початку? Можливо, ефективність, але мені подобається думати, що вони просто не усвідомлювали. Як і в кінцевому підсумку вони зрозуміли, що вам все ще потрібні розумні покажчики в .NET (google SafeHandle), вони думали, що GC дійсно вирішить усі проблеми. Вони забули, що об'єкт - це не просто пам'ять, а GC призначений насамперед для управління пам'яттю. вони захопилися думкою, що GC впорається з цим, і забули, що ти туди вкладаєш інші речі, об’єкт - це не просто плівка пам'яті, яка не має значення, якщо ти її не видалиш на деякий час.

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

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

Отже, IMHO, спосіб .NET просто скопіював найбільший недолік Java - це її найбільша слабкість. .NET повинен був бути кращим C ++, а не кращою Java.

Брюс Еккель, автор книг "Мислення на Яві" та "Мислення на C ++" та член Комітету зі стандартів C ++, вважає, що в багатьох областях (не лише RAII) Гослінг та команда Java не зробили своїх домашнє завдання.

... Щоб зрозуміти, як мова може бути і неприємною, і складною, і одночасно добре розробленою, ви повинні пам’ятати про первинне дизайнерське рішення, на якому опинилося все на C ++: сумісність з C. Stroustrup вирішила - і правильно так , може здатися, що спосіб змусити маси програмістів C переміщуватися до об'єктів полягав у тому, щоб зробити хід прозорим: дозволити їм складати свій C код незмінним під C ++. Це було величезним обмеженням і завжди було найбільшою силою C ++ ... і його перевагою. Саме це зробило C ++ настільки ж успішним і настільки ж складним, як і воно.

Це також обдурило дизайнерів Java, які недостатньо добре зрозуміли C ++. Наприклад, вони вважали, що перевантаження операторів занадто важке для правильного використання програмістів. Що в основному вірно в C ++, оскільки C ++ має як розподіл стеків, так і розподіл купи, і ви повинні перевантажувати своїх операторів для обробки всіх ситуацій і не спричиняти витоків пам'яті. Справді важко. Однак Java має єдиний механізм розподілу сховища та збирач сміття, що робить перевантаження оператора тривіальним - як це було показано на C # (але це вже було показано в Python, який передував Java). Але впродовж багатьох років команда Java частково відзначала: "Перевантаження оператора занадто складна". Це та багато інших рішень, коли хтось явно не робив '

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

Коли я писав про те, як погано розроблені дженерики, я отримав таку ж відповідь, а також "ми повинні бути сумісні з попередніми (поганими) рішеннями, прийнятими на Яві". Останнім часом все більше і більше людей набувають достатнього досвіду роботи з Generics, щоб побачити, що їх дійсно дуже важко використовувати - дійсно, шаблони C ++ є набагато потужнішими та послідовнішими (і набагато простіше використовувати зараз, коли повідомлення про помилки компілятора є терпимими). Люди навіть серйозно сприймають реіфікацію - те, що може бути корисним, але не вкладе стільки вм'ятини в дизайн, який покалічений самостійними обмеженнями.

Список продовжується до того, що це просто нудно ...

Найкраща причина набагато простіша, ніж більшість відповідей тут.

Ви не можете передавати виділені об'єкти стека в інші потоки.

Зупиніться і подумайте над цим. Продовжуйте думати .... Тепер у C ++ не було тем, коли всі так захопилися RAII. Навіть Ерланг (окремі купи на нитку) стає примхливим, коли ви передаєте занадто багато предметів навколо. C ++ отримала модель пам'яті лише у C ++ 2011; тепер ви можете майже міркувати про сумісність у C ++, не звертаючись до "документації" вашого компілятора.

Java розроблялася з (майже) першого дня для декількох потоків.

У мене ще є стара копія "Мова програмування на C ++", де Stroustrup запевняє, що мені не потрібні теми.

Друга болюча причина - уникати нарізання.

У C ++ ви використовуєте більш мовні функції нижчого рівня загального призначення (деструктори автоматично викликаються на об'єктах на основі стека) для реалізації вищого рівня (RAII), і такий підхід - це те, що, здається, людям C # / Java не є занадто любить. Вони б швидше спроектували спеціальні інструменти високого рівня для конкретних потреб і надали їх програмістам готових, вбудованих у мову. Проблема з такими специфічними інструментами полягає в тому, що їх часто неможливо налаштувати (частково саме це робить їх таким простим у навчанні). При будівництві з менших блоків краще рішення може з’явитися з часом, тоді як якщо у вас є лише вбудовані конструкції високого рівня, це менш ймовірно.

Так так, я думаю (я насправді там не був ...) це було чітке рішення, метою якого було полегшити мову, але, на мою думку, це було поганим рішенням. Знову ж таки, я, як правило, віддаю перевагу програмістам C ++, які дають змогу заграти власну філософію, тому я трохи упереджений.

Ви вже викликали приблизний еквівалент цьому в C # Disposeметодом. Ява також є finalize. ПРИМІТКА: Я розумію, що завершення роботи Java не є детермінованим і відрізняється від того Dispose, я просто вказую, що вони обидва мають метод очищення ресурсів поряд з GC.

Якщо що-небудь C ++ стає біль, хоча тому, що об'єкт повинен бути фізично знищений. У мовах вищого рівня, таких як C # та Java, ми залежаємо від сміттєзбірника, щоб очистити його, коли на нього більше немає посилань. Немає такої гарантії, що об’єкт DBConnection в C ++ не має посилань або покажчиків на нього.

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

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