4) І ще невеликий сюрприз: вартість Turbo Delphi Pro знизилася до 250 $.
Ось так, коротенько.
Всього в темі 1215 повідомлень
>> Всього повідомлень в темі: 1215; сторінок: 122; поточна сторінка: 47
Відповідь на "повідомлення 752« (Сергій Тарасов)
___________________________
Ви не повинні переписувати номери кубиків, ви повинні обращаяться до столу з проханням видати кубик певних характеристик.
Зрозуміло. Але що видасть стіл? Копію кубика або таки його номер (посилання)?
Відповідь на "повідомлення 749« (Антон Григор'єв)
___________________________
Як компроміс можна взяти рішення, прийняте в Modula-3. Там два види посилань: відслідковують і неотслежіваемих.
TYPE TracedPtr = REF MyType;
UntracedPtr = UNTRACED REF MyType;
VAR tp: TracedPtr;
up: UntracedPtr;
NEW (tp); NEW (up); (* Tp і up створюються в різних купах *)
DISPOSE (tp); (* Те саме, що tp: = NIL *)
DISPOSE (up); (* Up знищується *)
Відповідь на "повідомлення 749« (Антон Григор'єв)
___________________________
Забули ви про головну проблему автоматичного управління пам'яттю через підрахунок посилань (інтерфейси і т.п.) - неможливість звільнення циклічних посилань. Так що особисто я цей варіант за альтернативу GC не вважаю.
Я і намагався про це сказати :)
Що стосується мене, то я і без дула пістолета можу зізнатися, що поки мова йде про об'єкти, що використовують тільки пам'ять, я просто насолоджуюся можливістю створювати їх, не думаючи про знищення. Але мені часто доводиться мати справу і з об'єктами, що використовують інші ресурси, і для нормальної роботи з ними мені необхідний зручний інструмент.
Але тут можна хоча б написати набір системних об'єктів, які всі складнощі з with / using заховають всередині своїх методів. І прикладному програмісту вже не доведеться боротися з явним звільненням ресурсів.
Відповідь на "повідомлення 750« (Стен)
___________________________
Відповідь на "повідомлення 747« (Сергій Тарасов)
___________________________
>>> Контейнер вляется власником об'єктів. Він надає власний інтерфейс доступу до них. Він же керує їх часом життя.
>>> Типовий приклад - список об'єктів.
Дуже об'ємне визначення контейнера. Десять об'єктів-кубиків "лежать" на столі (список), я "переписав" собі в зошит номери всіх зелених кубиків. Отримав новий список в зошиті. Де тут контейнер?
Стіл, зрозуміло.
Ви не повинні переписувати номери кубиків, ви повинні обращаяться до столу з проханням видати кубик певних характеристик.
Відповідь на "повідомлення 748« (panda)
___________________________
Відповідь на "повідомлення 747« (Сергій Тарасов)
___________________________
Типовий приклад - список об'єктів.
Це - не типовий приклад. Це "Hello, world".
Подивіться »повідомлення 738« - там наводився хороший приклад. На об'єкт може бути більше одного посилання і тоді контейнери не рятують. Якщо ви пишете системну бібліотеку, якою користуватимуться прикладні програмісти, то це - буденна ситуація.
Приклад типовий, а в 738 повідомленні - типова груба помилка.
Дуже об'ємне визначення контейнера. Десять об'єктів-кубиків "лежать" на столі (список), я "переписав" собі в зошит номери всіх зелених кубиків. Отримав новий список в зошиті. Де тут контейнер? Після чого "спалив" зошит. Список зник, а об'єкти немає.
Якщо ж ви мені почнете доводити, що може трапитися помилка, коли стіл з кубиками уже розібраний, а список в зошиті ще є, і це неправильно. Я звичайно з вами погоджуся, але яким чином цей приклад є обґрунтуванням того, що GC непотрібний / шкідливий?
Відповідь на "повідомлення 745« (panda)
___________________________
Забули ви про головну проблему автоматичного управління пам'яттю через підрахунок посилань (інтерфейси і т.п.) - неможливість звільнення циклічних посилань. Так що особисто я цей варіант за альтернативу GC не вважаю.
Що стосується мене, то я і без дула пістолета можу зізнатися, що поки мова йде про об'єкти, що використовують тільки пам'ять, я просто насолоджуюся можливістю створювати їх, не думаючи про знищення. Але мені часто доводиться мати справу і з об'єктами, що використовують інші ресурси, і для нормальної роботи з ними мені необхідний зручний інструмент.
Відповідь на "повідомлення 747« (Сергій Тарасов)
___________________________
Типовий приклад - список об'єктів.
Це - не типовий приклад. Це "Hello, world".
Подивіться »повідомлення 738« - там наводився хороший приклад. На об'єкт може бути більше одного посилання і тоді контейнери не рятують. Якщо ви пишете системну бібліотеку, якою користуватимуться прикладні програмісти, то це - буденна ситуація.
Відповідь на "повідомлення 745« (panda)
___________________________
Відповідь на "повідомлення 745« (panda)
___________________________
Противники GC завжди готові привести масу прикладів, коли це незручно. Але навіть "під дулом пістолета" відмовляються визнавати, що в їх житті були такі випадки, коли ручне управління пам'яттю для безлічі об'єктів, що передаються між контейнерами, перетворювалося в сущий кошмар.
Напевно, мені не траплялося настільки складних проектів. Але бачте, помилкове звільнення / незвільнення пам'яті з-під об'єктів дуже часто є наслідком помилок в проектуванні системи в цілому. Тому збирач сміття лише "ховає" наслідки цих помилок, але не вирішує їх.
>> Всього повідомлень в темі: 1215; сторінок: 122; поточна сторінка: 47