Здравствуйте, jazzer, Вы писали:
J>Ты так и не ответил, в чем нечестность состоит.
Ну насколько я понимаю, те люди договорились, что про объёмы работ друг друга не парят, тем более, что они обычно трудносравнимы, а вот "на сторону" не программируют. У них такое вот представление о честности.
А если ты то тут, то там работаешь, а кто-то все силы на ваш совместный проект кладёт, то это кому-то может показаться нечестным
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, jazzer, Вы писали:
E>>Ну это опасно, потому, что получается довольно незаметный подводный камень, о котором никто кроме тебя не помнит, пока ты не забудешь. ИМХО чем так использовать STL лучше совсем его не использовать J>Вот еще Слишком много вкусностей в СТЛ, чтоб ради только этого отказаться от нее
Ну можно было отказаться от STL именно в этом месте J>А эту прогу писал я один и всегда помнил об этом, как "Отче наш"
Ну приколлективной разработке это неприемлемо. Согласись, что такой код всё-таки опасен
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, Sergey, Вы писали:
>> Так не помог ему shared_pointer... S>Я думаю, он его и не пробовал...
Откуда знаешь?
А ещё вопрос, как бы он мог помочь, кстати?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, jazzer, Вы писали:
J>>>И что значит — "не позволяет хранить обычные указатели на объект"? Он, вроде, именно их и хранит J>Можешь объяснить, зачем тебе понадобилось так писать?
Чтобы пояснить чего не позволяет хранить shared_ptr
J>ты уж либо хочешь, чтоб указатель сам следил за тем, сколько у него ссылок (но тогда все должно иддти через него), либо быть готовым к тому, что в какой-то момент все накроется, потому что кончились ссылки.
Ну в случае шаредптра эту нужду обычно покрывают за счёт слабых указателей.
скажем есть узел дерева. Он имеет указатели на детей в виде shared_ptr, а детям тоже нужен указатель на отца, но невладеющий. Так как детё нельзя укокошить раньше отца. И чего делать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>Ты так и не ответил, в чем нечестность состоит. E>Ну насколько я понимаю, те люди договорились, что про объёмы работ друг друга не парят, тем более, что они обычно трудносравнимы, а вот "на сторону" не программируют. У них такое вот представление о честности. E>А если ты то тут, то там работаешь, а кто-то все силы на ваш совместный проект кладёт, то это кому-то может показаться нечестным
жуть какая
портят людей деньги, портят
Уже и на гитаре не поиграешь, и с женой лишний час в постели не проведешь — ведь другой в это время может работать, хоть и график свободный
Здравствуйте, jazzer, Вы писали:
J>портят людей деньги, портят J>Уже и на гитаре не поиграешь, и с женой лишний час в постели не проведешь — ведь другой в это время может работать, хоть и график свободный
Ну конкретно эти люди договорились только о коммерческом программировании. Жена и гитара никак не возбранялись У одного, кстати, была группа, где он играл, а его жена пела
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Programador, Вы писали:
P>>Ну безусловно иметь счетчик на борту самое безопасное и быстрое решение. Вот только я смысла этого примера http://boost.org/libs/smart_ptr/test/intrusive_ptr_test.cpp не понимаю. Доработки самого класса фактически равны написанию маленького велосипеда.
J>достаточно просто написать внешние функции J>
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
КЛ>>А что мешает инстанциировать шаблоны на нормальном компайлере и потом юзать инстанциации?
E>Ну так и сделали примерно. Но мешает сложность шаблонных конструкций. E>Вот как, например, ты представляешь при таком подхде выбор перегруженной функции?
это может быть довольно трудоемко, согласен. Тут нужен компромисс м/у эффекта от использования шаблона и стоимости их инстанциации на нормальной компайлере и встравиании их.
Re[10]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, jazzer, Вы писали:
J>>>>И что значит — "не позволяет хранить обычные указатели на объект"? Он, вроде, именно их и хранит J>>Можешь объяснить, зачем тебе понадобилось так писать? E>Чтобы пояснить чего не позволяет хранить shared_ptr
аргумент из серии int *p = new int; delete p; delete p;
J>>ты уж либо хочешь, чтоб указатель сам следил за тем, сколько у него ссылок (но тогда все должно иддти через него), либо быть готовым к тому, что в какой-то момент все накроется, потому что кончились ссылки.
E>Ну в случае шаредптра эту нужду обычно покрывают за счёт слабых указателей.
E>скажем есть узел дерева. Он имеет указатели на детей в виде shared_ptr, а детям тоже нужен указатель на отца, но невладеющий. Так как детё нельзя укокошить раньше отца. И чего делать?
так тебе чего надо-то? чтоб они сами за собой чистили? если нет — достаточно простых голых указателей.
какие отношения между узлами — кто кого имеет право прибивать?
пока что ничего непонятно.
насчет weak_ptr — а что тебе не нравится-то, я так и не понял? слово weak?
P.S. По-моему, на какой-то такой вопрос я уже отвечал здесь, показывал, что все отлично чистится в правильном порядке независимо от сценария убиения. Дежа вю
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
КЛ>>чушь. Либо у тебя фиговый опыт, либо с тобой что-то не так. E>Ну возможно у тебя нет опыта, как хорошо жить без STL и буста... E>Конечно с голым C++ жить ещё хуже... E>А что касается могео опыта, то я думаю, что ты, например пользуешься программой, которую писал в том числе и я
Какой? Мне серьезно интересно.
[]
Минус тебе поставил, тк ты не написал про очень важный нюанс: "Применение STL/boost может иметь отрицательный эффект по сравнению с применением аналогичных библиотек".
Тут я пожалуй, соглашусь.
Re[14]: велосипеды vs boost и пр "стандартные" решения
>>> Так не помог ему shared_pointer... > S>Я думаю, он его и не пробовал... > Откуда знаешь?
А откуда знаешь, что не помог?
> А ещё вопрос, как бы он мог помочь, кстати?
Во владельце — shared_ptr на объект, в потребителях (Event_Handler в данном случае) — weak_ptr. При необходимости обращения к объекту из потребителя из weak_ptr конструируется shared_ptr. Если объект уже убит, конструктор shared_ptr кинет исключение boost::bad_weak_ptr.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[10]: велосипеды vs boost и пр "стандартные" решения
Erop wrote:
>>> shared_ptr<T> p1 = CreateT(); >>> T* p2 = p1*.get()*; >>> shared_ptr<T> p3 = p2; > .>Можно, только что ты хочешь этим сказать?? > А разве не получится проблем с владением?
Дык ты сам их захотел. Вот они и появились. Или я не понял, что ты хочешь от этого кода. Может тебе нужне weak_ptr?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Константин Л., Вы писали:
КЛ>>а он настолько lightweight и independent, что его без труда можно вытащить as is
E>Вау! E>Какие люди и за велосипеды выступают!!!
вы мне льстите
E>Одна из основных проблем буста в том, что его нельзя брать по частям. Он всё время как-то меняется, и надо либо перевыдёргивать нужную тебе часть, либо поддерживать её самому. Получается тот же велосипед, но неудобный. Лучше уж совсем свой тогда...
ну кое-что можно брать частями. Поддерживать совсем необязательно, по крайней мере это нужно делать довольно редко. Совсем свой иногда может обойтись в копеечку/время. И не забывай, что буст пишут профи, велосипеды — в основном нет.
Здравствуйте, Константин Л., Вы писали:
КЛ>Какой? Мне серьезно интересно.
Ну я не хочу/могу разглашать место работы.
Особенно на форуме.
Одна из офисных программ, или другая, или ещё одна
Ещё могу такую подсказку сказать, когда искали для российских школ комплект общеупотребительных открытых программ, как альтернативу проеприетарных прог, то аналога одной из наших программ не нашли...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, Sergey, Вы писали:
S>Во владельце — shared_ptr на объект, в потребителях (Event_Handler в данном случае) — weak_ptr. При необходимости обращения к объекту из потребителя из weak_ptr конструируется shared_ptr. Если объект уже убит, конструктор shared_ptr кинет исключение boost::bad_weak_ptr.
Пардон! Если можно менять саморазрушающийся объект, то и проблем никаких. Просто он в прокси взводит фладок "я умер" и всё. Даже без shared_ptr всё получится. Хоть на автоматических объектах...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Константин Л., Вы писали:
КЛ>ну кое-что можно брать частями. Поддерживать совсем необязательно, по крайней мере это нужно делать довольно редко. Совсем свой иногда может обойтись в копеечку/время. И не забывай, что буст пишут профи, велосипеды — в основном нет.
1) Код который не надо поддерживать -- это миф.
2) Профи или не профи пишут внутренние библиотеки зависит от персонала. Конечно если у вас в комании работают чуваки, которые вовсе и не профи а ламеры ламерами и ничего кроме, как использовать буст не умеют... Хотя я надеюсь, что это не так
3) Перед актом велосипелостроительства, в буст можно заглянуть и подумать зачем им всё это. И не только в буст...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: велосипеды vs boost и пр "стандартные" решения
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, jazzer, Вы писали:
J>P.S. По-моему, на какой-то такой вопрос я уже отвечал здесь, показывал, что все отлично чистится в правильном порядке независимо от сценария убиения. Дежа вю
Я знаю как пользоваться бустовскими умными указателями.
Я просто скромно указывал, что за shared_ptr неизбежно приползёт weak_ptr...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[16]: велосипеды vs boost и пр "стандартные" решения
> S>Во владельце — shared_ptr на объект, в потребителях (Event_Handler в данном случае) — weak_ptr. При необходимости обращения к объекту из потребителя из weak_ptr конструируется shared_ptr. Если объект уже убит, конструктор shared_ptr кинет исключение boost::bad_weak_ptr. > > Пардон! Если можно менять саморазрушающийся объект, то и проблем никаких. Просто он в прокси взводит фладок "я умер" и всё. Даже без shared_ptr всё получится. Хоть на автоматических объектах...
Понятно, что и без shared_ptr всё получится. Просто придется повторять часть его функциональности. Зачем, если оно уже есть готовое и отлаженное?
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Re[17]: велосипеды vs boost и пр "стандартные" решения
Здравствуйте, Sergey, Вы писали:
S>Понятно, что и без shared_ptr всё получится. Просто придется повторять часть его функциональности. Зачем, если оно уже есть готовое и отлаженное?
Возможно без shared_ptr будет даже проще. Но это не важно. Главное, что в приведённом случае это всё не помогает
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском