А>отсюда мой глупый вопрос: неужели так сложно написать компилятор, который следит за количеством ссылок?
Несложно. См. .NET, Java А>тогда бы все autp_ptr, shared_ptr, сгинули и был бы простой и эффективный код..
Ничего даром не бывает. За автоматическую уборку мусора надо платить. В С++ считается, что нельзя обязывать человека платить за то, что ему не нужно.
Да здравствует мыло душистое и веревка пушистая.
Re[6]: глупый вопрос по основам с++
От:
Аноним
Дата:
10.02.04 07:57
Оценка:
ПК>Очевидно, это шутка.
Фууу, слава Богу. Напугал, понимаешь
Re[4]: глупый вопрос по основам с++
От:
Аноним
Дата:
10.02.04 07:15
Оценка:
Интересно, где это и как это компилятор тайком от меня вставляет new?
глупый вопрос по основам с++
От:
Аноним
Дата:
09.02.04 14:22
Оценка:
основная тенденция в современном с++, как я это понимаю, использование контейнеров и умных указателей для динамического выделения памяти. все это требует подсчета ссылок и прочих дополнительных расходов.
отсюда мой глупый вопрос: неужели так сложно написать компилятор, который следит за количеством ссылок?
тогда бы все autp_ptr, shared_ptr, сгинули и был бы простой и эффективный код..
Re: глупый вопрос по основам с++
От:
Аноним
Дата:
09.02.04 14:25
Оценка:
Как и за чем должен компилятор следить на этапе выполнения? Что мешает тебе такому умному ("неужели так сложно") написать эффективный сборщик мусора и не задавать больше таких вопросов? А еще лучше пользуйся джавой или С#
Re[2]: глупый вопрос по основам с++
От:
Аноним
Дата:
09.02.04 14:36
Оценка:
нет, в java и c# следит виртуальная машина, а я бы хотел, чтобы компилятор, когда из области видимости ушел последний указатель встраивал delete obj;.
Re[2]: глупый вопрос по основам с++
От:
Аноним
Дата:
09.02.04 14:39
Оценка:
если я был бы крутой, то не задавал бы глупых вопросов
Re[3]: глупый вопрос по основам с++
От:
Аноним
Дата:
09.02.04 14:41
Оценка:
А>если я был бы крутой, то не задавал бы глупых вопросов
Здравствуйте, Аноним, Вы писали:
А>основная тенденция в современном с++, как я это понимаю, использование контейнеров и умных указателей для динамического выделения памяти. все это требует подсчета ссылок и прочих дополнительных расходов. А>отсюда мой глупый вопрос: неужели так сложно написать компилятор, который следит за количеством ссылок?
А ты попробуй
А если серьезно, то Страуструп в "design & evolution" пишет, что реализация garbage-collector-а серьезно ударит по эффективности.
Кроме того, существует множество типов умных указалелей, предназначенных для решения разных задач.
Например std::auto_ptr и boost::shared_ptr — вещи совершенно разные. Требовать от компилятора поддержки всех типов — нереально. Навязывать какой-то один тип — ... ну, ты понимаешь
ЗЫ
есть задачи, где без "чистых" указателей не обойтись, или их использование дает существенное преимущество (повышает эффективность).
А>нет, в java и c# следит виртуальная машина, а я бы хотел, чтобы компилятор, когда из области видимости ушел последний указатель встраивал delete obj;.
Для того, чтобы понять, что из видимости ушел последний указатель, ему придется предпринимать определенные действия. Считать ссылки, в частности. Ты говоришь о том, что этот код будет встроен непосредственно в программу, а не в исполняющую среду. Такая программа сама по себе станет исполняющей средой самой себе. И будет это стоить тактов и объема.
Здравствуйте, Вы писали:
> неужели так сложно написать компилятор, который следит за количеством ссылок?
Почти во всех случаях, когда этим может заниматься компилятор, динамическое
выделение памяти не нужно вообще. А в тех случаях, когда это компилятору не по
плечу, остается только сборка мусора или подсчет ссылок. Выбирай
Posted via RSDN NNTP Server 1.7 "Bedlam"
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Вы писали:
> нет, в java и c# следит виртуальная машина, а я бы хотел, чтобы компилятор, > когда из области видимости ушел последний указатель встраивал delete obj;.
Еще лучше: компилятор C++ умеет автоматически вставлять не только delete,
но и new! В тех случаях, когда компилятор может отследить выход переменной
из области видимости, лучше пользоваться не динамической памятью, а создавать
объекты "в стеке".
Posted via RSDN NNTP Server 1.7 "Bedlam"
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re[4]: глупый вопрос по основам с++
От:
Аноним
Дата:
09.02.04 16:05
Оценка:
стек безусловно хорош, но иногда хочется большие куски памяти выделить или безопасный в смысле исключений код написать.
Здравствуйте, Вы писали:
> стек безусловно хорош, но иногда хочется большие куски памяти выделить > или безопасный в смысле исключений код написать.
В этом случае минимум накладных расходов обеспечит что-нибудь типа std::auto_ptr
или boost::scoped_ptr. Никаких счетчиков ссылок, "компилятор" лучше не справится.
Posted via RSDN NNTP Server 1.7 "Bedlam"
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, elvic, Вы писали:
E>А динамический код как писать прикажете? Например создать в цикле N обьектов, в зависимости от вводимой юзверем информации...
А в чем проблемы? От простейшего парсера до полноценного транслятора — все в твоих руках
P.S. ActiveX-скриптинг еще есть — вообще ничего делать не надо, все уже сделали до тебя
Здравствуйте, elvic, Вы писали:
E>А динамический код как писать прикажете? Например создать в цикле N обьектов, в зависимости от вводимой юзверем информации...