> E>>Во всех этих случаях GC был бы идеальным решением. > E>Ну, вообще-то, тут всё понятно что делать. Эти объекты какие-то уведомления наверное же рассылают о своей смерти? Или как-то можно проверить, что объект уже сдох? По хэндлу там, скажем? > > E>Если так, то заводишь прокси-объект, которым и владеет твоя часть программы. А сам прокси убивается когда на него больше нет ссылок и грохает управляемый им объект, перед этим. > E>Ну а когда управляемый объект присылант уведомление, что он разрушен, то прокси это дело запоминает и остаётся в таком вот получдохшем состоянии... > > Это на словах все просто. А на практике это выливается с неделю-другую выкуривания бамбука, реализации и тестирования.
А пару уже готовых shared/weak_ptr там использовать не получается? В либу жестко зашит голый указатель?
> А в языках с GC вообще никаких заморочек.
Зато они имеют тенденцию памяти жрать вдвое против реально необходимого
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[9]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Cyberax, Вы писали:
C>>В Бусте есть и intrusive_ptr с нулевым оверхедом — какие проблемы-то? E>А его тоже в STL переносят?
и его ,и еще много чего.
посмотри текущий драфт стандарта в соседней ветке.
Здравствуйте, eao197, Вы писали:
E>Это на словах все просто. А на практике это выливается с неделю-другую выкуривания бамбука, реализации и тестирования.
А может лучше день подумать и день попрогать?
E>А в языках с GC вообще никаких заморочек.
Вообще-то, как я понял, проблема в том, что ты не можешь контролировать момент разрушения каких-то объектов. Казалось бы, при чм тут GC? А если бы был у тебя GC, а объекты бы всё равно разрушались? Например по причине отгрузки DLL со всеми её статическими данными...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: велосипеды vs boost и пр "стандартные" решения
>>> Шаред птр в данном случае — абсолютно не критичны Правда практически обычно используют интрузивные шаред птр. > S>Только если слабые указатели не нужны.
> Часто можно обойтись интрузивными + обычные...
"Не нужны" именно это и означает — можно без проблем обойтись другими средствами. А вот чтобы не изобретать велосипеды в подобных: http://rsdn.ru/forum/message/2631426.aspx
Здравствуйте, jazzer, Вы писали:
E>>А ещё в одной конторе, где тоже запрещено, вообще нет графика посещения. Елинственное ограничение -- нельзя программировать для кого-то, кроме этой конторы Обе пока что весьма эффективны
J>Но это же ужасное ограничение! А если я пишу бустовские либы или у меня параллельный шароварный бизнес?
Ну вот ты там и не работаешь
Просто там все сотрудники совладельцы. Так что параллельный шароварный бизнес -- это как бы не совсем феер плей по отношению к партнёрам...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, Evgeniy13, Вы писали:
E>Ну, у адекватного программиста не уйдет больше минуты для того, чтобы начать пользоваться самопальными котейнерами.
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, Erop, Вы писали:
E>>Здравствуйте, Cyberax, Вы писали:
C>>>В Бусте есть и intrusive_ptr с нулевым оверхедом — какие проблемы-то? E>>А его тоже в STL переносят?
КЛ>а он настолько lightweight и independent, что его без труда можно вытащить as is
Ну безусловно иметь счетчик на борту самое безопасное и быстрое решение. Вот только я смысла этого примера http://boost.org/libs/smart_ptr/test/intrusive_ptr_test.cpp не понимаю. Доработки самого класса фактически равны написанию маленького велосипеда.
Re[9]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, Erop, Вы писали:
J>>Но это же ужасное ограничение! А если я пишу бустовские либы или у меня параллельный шароварный бизнес? E>Просто там все сотрудники совладельцы. Так что параллельный шароварный бизнес -- это как бы не совсем феер плей по отношению к партнёрам...
с какой это стати? Я вот работаю в банке — как мне это помешает писать и продавать игрушки для мобильников? И в каком месте это будет нечестно по отношению в банку, если мы ни в одной точке не конкуренты?
Вот если твой бизнес играет против общего — тогда оно конечно.
Здравствуйте, Константин Л., Вы писали:
КЛ>а он настолько lightweight и independent, что его без труда можно вытащить as is
Вау!
Какие люди и за велосипеды выступают!!!
Одна из основных проблем буста в том, что его нельзя брать по частям. Он всё время как-то меняется, и надо либо перевыдёргивать нужную тебе часть, либо поддерживать её самому. Получается тот же велосипед, но неудобный. Лучше уж совсем свой тогда...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, eao197, Вы писали:
E>В D вообще целый набор средств -- try-finally, RAII через scoped классы, scope(exit) конструкция:
E>Достоинство C++ в том, что он предлагает всего один механизм, универсальный. Но ценой этого является большая трудоемкость подгонки этого универсального механизма под конкретные условия. Наличие же дополнительных механизмов в других языках показывают, что упрощение наиболее частоупотребимых сценариев за счет специальных конструкций языка упрощает разработку.
E>Вот поэтому я с сарказмом и говорю о стандартных решениях стандартных проблем.
Здравствуйте, jazzer, Вы писали:
J>не видел ты настоящего самопального контейнера
Ну бывают и неудачные реализации спецификации "самопальный контейнер"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, jazzer, Вы писали:
J>>>Но это же ужасное ограничение! А если я пишу бустовские либы или у меня параллельный шароварный бизнес? E>>Просто там все сотрудники совладельцы. Так что параллельный шароварный бизнес -- это как бы не совсем феер плей по отношению к партнёрам...
J>с какой это стати? Я вот работаю в банке — как мне это помешает писать и продавать игрушки для мобильников? И в каком месте это будет нечестно по отношению в банку, если мы ни в одной точке не конкуренты?
Ну ИМ так удобно. Зато работать можно когда и где угодно...
ТЕБЕ это наверное не подходит. Тебе, видимо, больше нравится работать 8 часов в день, 5 дней в неделю...
J>Вот если твой бизнес играет против общего — тогда оно конечно.
Ну это как раб. время считать, сверхурочные там всякие. Многим работа в радость, вообще-то
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: велосипеды vs boost и пр "стандартные" решения
ситуациях (насчет ACE), шаред пойнтер как раз и предназначен.
Так не помог ему shared_pointer...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>И что значит — "не позволяет хранить обычные указатели на объект"? Он, вроде, именно их и хранит
E>Так писать нельзя:
Можешь объяснить, зачем тебе понадобилось так писать?
ты уж либо хочешь, чтоб указатель сам следил за тем, сколько у него ссылок (но тогда все должно иддти через него), либо быть готовым к тому, что в какой-то момент все накроется, потому что кончились ссылки.
Здравствуйте, Erop, Вы писали:
J>>с какой это стати? Я вот работаю в банке — как мне это помешает писать и продавать игрушки для мобильников? И в каком месте это будет нечестно по отношению в банку, если мы ни в одной точке не конкуренты?
E>Ну ИМ так удобно. Зато работать можно когда и где угодно... E>ТЕБЕ это наверное не подходит. Тебе, видимо, больше нравится работать 8 часов в день, 5 дней в неделю...
я к тому, что это пофиг, сколько у меня дополнительных бизнесов и источников дохода, пока они не против бизнеса, в котором ты совладелец.
А свободное время — это конечно, здорово
А проблема со временем решается заранее оговоренным объемом работы.
Вот у меня, например, в Москве группа была (музыыкальная), играли и зарабатывали ( ) деньги. Тоже нечестно?
J>>Вот если твой бизнес играет против общего — тогда оно конечно. E>Ну это как раб. время считать, сверхурочные там всякие. Многим работа в радость, вообще-то
Ну мне работа в радость, и что?
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>Если мне это было нужно, я всегда пользовался std::vector<my_fat_class*> с явным временем жизни. J>>Более того, я на полную катушку использовал std::vector<xxx::auto_ptr<my_fat_class> > (естественно, с соответствующей версией СТЛ), потому что мне вектор нужен был просто для удобного хранения, и я никогда не пытался его сортировать или делать еще что-то в этом роде. E>Ну это опасно, потому, что получается довольно незаметный подводный камень, о котором никто кроме тебя не помнит, пока ты не забудешь. ИМХО чем так использовать STL лучше совсем его не использовать
Вот еще Слишком много вкусностей в СТЛ, чтоб ради только этого отказаться от нее
А эту прогу писал я один и всегда помнил об этом, как "Отче наш"
E>Хотя проще конечно привинтить свой какой-нибудь shared_ptr Хоть бы из какой-нибудь версии буста выдрать. Другое дело, что тебе бустовского всемогутера прийдётся самому потом поддерживать, а, возможно, тебе не нужны все его прелести
это было в черт-те-лохматом году, когда никакого буста не было еще. Была только VC6.0 (без сервиспаков)
J>>нет, корень ситуации с почти любой фичей, которая существовала к 98-му году, но не попала в стандартную библиотеку (например, хеши) — это огромное желание получить наконец стандарт. Иначе мы бы первой версии стандарта ждали бы до 2009 года. E>Ну спорными оказались вещи, которые неочевидно как лучше сделать...
Увы, но даже на очевидные не хватало времени.
Кстати, буст появился именно тогда, в недрах комитета, как загон, в котором будут расти библиотеки, пока не станут достаточно вылизаанными для того, чтоб их можно было принять в стандарт.
E>Ну в моём понимании "нормальный программист" не включает в себя понятие "умеет прогать шаблоны". E>Мало того, чисто по опыту, "нормальный программист" ещё и противоречит "любит прогать шаблоны"
эээ... и кто же я после этого?
Здравствуйте, Programador, Вы писали:
P>Ну безусловно иметь счетчик на борту самое безопасное и быстрое решение. Вот только я смысла этого примера http://boost.org/libs/smart_ptr/test/intrusive_ptr_test.cpp не понимаю. Доработки самого класса фактически равны написанию маленького велосипеда.
Правда практически обычно используют интрузивные шаред птр.
Хоть бы из какой-нибудь версии буста выдрать. Другое дело, что тебе бустовского всемогутера прийдётся самому потом поддерживать, а, возможно, тебе не нужны все его прелести