Здравствуйте, minorlogic, Вы писали:
M>Если же вы предролагаете копировать и данные по указателю , тогда возникает вопрос , а почему там указатель а не агрегированный мембер ?
потому что там указатель на базовый класс. На интерфейс, если угодно.
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, jazzer, Вы писали:
H>>>Или, может, Вы родились, уже зная Си++ и STL? J>>Конечно же, нет. Я работал на part-time за $350 в месяц. И ни в какие конторы уровня Яндекса или Google не лез. Потому что отлично осознавал свой тогдашний уровень. LM>Буржуин! Я с 200 начинал
Не волнуйся, все эти заработанные непосильным трудом деньги через пару лет превратились в тыкву
И вместо квартиры мы с женой купили холодильник — хватило в обрез
веселые времена были
Здравствуйте, konsoletyper, Вы писали:
K>Кстати, небольшой оффтоп — сейчас пишу на C# и тяжело приходится без const — приходится явно писать интерфейс вида IConstXXX и наследовать от него IXXX. Хотя, const тоже пораждает немало граблей. Так что, может оно и к лучшему.
Поподробнее о выделенном можно?
Здравствуйте, greenrat, Вы писали:
G>Я уж не говорю, что boost просто не смотрел (все равно начальство не даст добро ).
И не смотри. Потом без него не сможешь
J>Конечно, можно и тут навертеть чего-нть, нагенерить traits и специальных классов, которые будут умными указателями и при этом будут уметь с этими traits работать, но это уже будет совершенно нетривиально.
Да написать новую политику копирования — это ж несколько строк. Берешь SmartPtr из Loki, создаешь политику, которая наследуется от DeepCopy, определяешь функцию Clone как тебе угодно, подсовываешь эту политику в SmartPtr и все. Дело нескольких минут.
А головной боли с конструкторами копирования и операторами присваивания гораздо больше. При добавлении нового члена в класс нужно не забыть его добавить в КК и ОП. А если КК и ОП генерируются компилятором, то он сам все сделает — можно расслабиться и получать удовольствие. :beer:
G>>>Я уж не говорю, что boost просто не смотрел (все равно начальство не даст добро :)) ). LM>>И не смотри. Потом без него не сможешь:) B>Я тоже не смотрел. Что, настолько опасно подсесть? :)
Представь: ты всю жизнь собирал велосипеды, а тут тебе подарили велосипедный завод :))
Здравствуйте, branco, Вы писали:
S>>Представь: ты всю жизнь собирал велосипеды, а тут тебе подарили велосипедный завод B>Ну, про boost::AntiСopiable уже наслышан. Попробуем продвинуться дальше.
Вообще-то он noncopyable.
Здравствуйте, branco, Вы писали:
G>>>Я уж не говорю, что boost просто не смотрел (все равно начальство не даст добро ). LM>>И не смотри. Потом без него не сможешь B>Я тоже не смотрел. Что, настолько опасно подсесть?
Посмотри boost::bind и пойми насколько просто стело делать callback-и и threadfunc(если использовать boost::thread)
class A
{
public:
long ID_;
....
};
std::vector<A> x;
Здравствуйте, sraider, Вы писали:
J>>Конечно, можно и тут навертеть чего-нть, нагенерить traits и специальных классов, которые будут умными указателями и при этом будут уметь с этими traits работать, но это уже будет совершенно нетривиально.
S>Да написать новую политику копирования — это ж несколько строк. Берешь SmartPtr из Loki, создаешь политику, которая наследуется от DeepCopy, определяешь функцию Clone как тебе угодно, подсовываешь эту политику в SmartPtr и все. Дело нескольких минут.
Ну Локи — да, а вот в бусте — нет
В принципе, по этому поводу Александреску с бустовцами грызся в довольно грубой форме.
Он очень оскорбился, что shared_ptr вставят в новый стандарт, а про него ни словом не упомянут.
На что ему вежливо ответили, что с его стороны, к сожалению, не видно оформленного по всем правилам пропозла для стандарта.
А жаль, мне его подход больше нравится.
S>А головной боли с конструкторами копирования и операторами присваивания гораздо больше. При добавлении нового члена в класс нужно не забыть его добавить в КК и ОП. А если КК и ОП генерируются компилятором, то он сам все сделает — можно расслабиться и получать удовольствие.
Если есть Локи — то да. Если нет — то нет, зачастую проще написать конструктор самому. Ты же не будешь утверждать, что SmartPtr из Локи тривиален.
Ну и, кстати, оператор присваивания по умолчанию даже с такими клёвыми умными членами не обеспечивает сильной гарантии безопасности.
Т.е. если у тебя два клонирующихся члена и клонирование второго возбуждает исключение — главный объект оказывается в интересном состоянии.
Здравствуйте, jazzer, Вы писали:
J>Ну и, кстати, оператор присваивания по умолчанию даже с такими клёвыми умными членами не обеспечивает сильной гарантии безопасности. J>Т.е. если у тебя два клонирующихся члена и клонирование второго возбуждает исключение — главный объект оказывается в интересном состоянии.
Это почему?
Здравствуйте, LuciferMoscow, Вы писали:
K>>Кстати, небольшой оффтоп — сейчас пишу на C# и тяжело приходится без const — приходится явно писать интерфейс вида IConstXXX и наследовать от него IXXX. Хотя, const тоже пораждает немало граблей. Так что, может оно и к лучшему. LM>Поподробнее о выделенном можно?
Это вообще тема отдельная. Как то на форуме обсуждали множественно наследование. Вероятно, разработчики Java/C# решили, что обилие в программе const/mutable может сделать код нечитабельным и запутанным, как и в случае с множественным наследованием. А с интерфейсам всё проще — передали методу объект, реализующий такой-то интерфейс, а метод только согласно этому интерфейсу действовать и может, всё просто и понятно. В язык можно понатащить чего угодно, упрощающего жизнь, только порой такая неумеренность может жизнь усложнить. Думаю, тут нужно соблюдать меру и не ударяться в одну из крайностей (слишком просто, слишком сложно). Вот, например, в C++ есть const, зато нет паттерн-матчинга и алгебраических типов. В одних задачах приходится материться на разработчиков C++, в других случаях на разработчиков Немерле. Правда как показала моя практика (насчёт всеобщей не знаю), на разработчиков Nemerle (да и C#) мне приходилось материться гораздо меньше.
Мне бы было интересно узнать, что по этому поводу говорят сами разработчики. Правда, скорее всего, они говорят как раз о простоте языка. Ну не знаю, это вопрос спорный.
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, jazzer, Вы писали:
J>>Ну и, кстати, оператор присваивания по умолчанию даже с такими клёвыми умными членами не обеспечивает сильной гарантии безопасности. J>>Т.е. если у тебя два клонирующихся члена и клонирование второго возбуждает исключение — главный объект оказывается в интересном состоянии. LM>Это почему?
Потому что первый член уже успешно скопировался.
В результате ты получаешь объект, у которого один член новый, а другой — старый.
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, minorlogic, Вы писали:
M>>Очень здравая мысль. Я считаю что такие весчи необходимо делать только в очень маленьком к-ве случаев , например смартпоинтер. M>>Для тривиальных , небиблиотечных классов — это дурной тон.
AJD>Аргументы?
Банальнейший пример из жизни.
Я написал конструктор копирования , а некто потом добавил новый мембер в класс... И теперь раз когда такое происходит , надо не забыть вставить копирование мембера в констрктор копирования и т.д.
... K>Я считаю, что знание синтаксиса вообще является второстепенным. Выучить синтаксис любого языка программирования можно за несколько дней, если понимать концепции, которые этот синтаксис отражает. Но для экзаменатора вопросы по синтаксису — это самое очевидное, что он может предложить кандидату.
Последний рекорд , я слышал что С++ можно за 2 недели выучить , а вы за несколько дней !
LM>Посмотри boost::bind и пойми насколько просто стело делать callback-и и threadfunc(если использовать boost::thread)
Ну для callback'ов лучше все-таки boost::function.
bind для другого предназначен.
ЗЫ: в boost::lambda лучше вообще не смотри. Сначала крыша съедет, а потом придется посылать лесом все конторы, где boost запрещён по т.н. "административным" причинам (в переводе на русский — это когда тим лид не знает буста).
J>В принципе, по этому поводу Александреску с бустовцами грызся в довольно грубой форме. J>Он очень оскорбился, что shared_ptr вставят в новый стандарт, а про него ни словом не упомянут. J>На что ему вежливо ответили, что с его стороны, к сожалению, не видно оформленного по всем правилам пропозла для стандарта. J>А жаль, мне его подход больше нравится.
А мне не жаль, нет ничего хуже, чем разбираться в плохо оформленном коде, без грамотных описаний. Стандарт сделан так, что его даже дуболом должен уметь понять.
).
