Козленок который считал до десяти
В детстве я ржал над мультиком, где козленок должен всех пересчитать, а иначе кораблик потонет.
Сейчас я работаю программистом и мне уже нифига не смешно.
я, кажется,слишком тупенькая для таких постов)) но объясните, пожалуйста, кого вам надо считать? =D Вот с экономистами выше я понимаю о чём речь) А кого считают программисты?)
раскрыть ветку (1)
Если не поверил сколько зверушек на корабле, может оказаться, что:
1) одна из зверушек - зомби и обращение к ней взорвет корабль
2) зверушек больше, чем помещается в корабль и лишние уничтожают мир своим существованием
3) зверушек меньше, чем надо потому что некоторых прибил под дороге и забыл об этом
И это только начало...
1) одна из зверушек - зомби и обращение к ней взорвет корабль
2) зверушек больше, чем помещается в корабль и лишние уничтожают мир своим существованием
3) зверушек меньше, чем надо потому что некоторых прибил под дороге и забыл об этом
И это только начало...
показать ответы
Спасибо) теперь понятно, почему вам уже "нифига не смешно"))
P.S. блин, а ведь это логично, странно, что сама не поняла...хотя я же сразу сказала, что тупенькая)
раскрыть ветку (1)
логично - значит объяснил хорошо.
Сами не поняли - потому что были не в контексте.
Это критическая ошибка нашего образования, называть человека тупым. Нельзя так делать, особенно по отношению к себе!
показать ответы
раскрыть ветку (1)
поясню: shared_ptr при любом неправильном использовании только добавляет проблем. Например я видел shared_ptr как аргумент асинхронной функции обратного вызова (межпоточного каллбэка).
В больших же проектах это сразу крест. Без строжашей организации и дисциплины, разумеется. А у нас почти всегда так.
показать ответы
Странно видеть такой комментарий от программиста. Какой у Вас опыт работы?
Даже большие компании используют этот шаблон, там, где это необходимо.
https://github.com/search?q=org%3Afacebook%20shared_ptr&...
Кроме того, этот класс не просто так пришёл в стандарт, сначала появившись в Boost, а сама техника совместного доступа и подсчёта ссылок была заложена ещё в Windows COM (Component Object Model). https://ru.wikipedia.org/wiki/Component_Object_Model
(далее идёт эльфийская жесть, слабонервным просьба не читать)
Кроме того, неправильно использовать shared_ptr довольно сложно (если не брать значение указателя с помощью shared_ptr::get() и не класть его ещё куда-нибудь, а работать только через operator-\>). Сам по себе shared_ptr довольно "неудобная" структура для программистов, привыкших работать напрямую с указазателями, потому что заставляет их думать о области жизни объектов. Там, где не ясно, сколько будет жить объект в памяти, или, другими словами, не ясно, кто владеет объектом - на помощь приходит shared_ptr.
А про Ваш пример (надеюсь вы про std::function, созданную с помощью std::bind - мне остаётся только догадываться, т.к. Вы просто накидали умных слов), чем будет отличаться ситуация, если вы вместо shared_ptr в этом месте будете использовать указатели?
раскрыть ветку (1)
так, давайте сразу расставим точки над i:
я ни в коем случае не говорю что shared_ptr это плохо.
Мой месседж - сам по себе shared_ptr в неумелых руках только добавит ебли. И это был целенаправленный ответ на комментарий #comment_63160497.
показать ответы
Мне стыдно спрашивать, но в чем косяк шаред птра в колбэке? Пользователь колбека заберет его и где-то сохранит? Я чет не придумаю как лучше оформить передачу обьекта из асинхронной операции колбеком
раскрыть ветку (1)
мой месседж был в том, что в проекте должно быть жестко прописано, где живет shared_ptr, а так же область его жизни. Это должно быть прописано на этапе архитектуры, жестко соблюдаться в дизайне и реализовано красивым кодом.
В описываемом мною примере вместо того, чтобы разобраться когда в проекте объект жив а когда нет - его просто отправляли куда-нибудь в рассчете на то, что shared_ptr сам решит все проблемы.
Естественно само по себе решение, может и не плохое. Просто достаточно редкое, узкое, специфичное и просто нарывается на то, чтобы провести инспекцию - а чем руководтствовались люди, когда выбирали именно такой подход.
показать ответы
Что по-вашему "красивый код"?
> В описываемом мною примере вместо того, чтобы разобраться когда в проекте объект жив а когда нет - его просто отправляли куда-нибудь в рассчете на то, что shared_ptr сам решит все проблемы.
Если везде используется shared_ptr, то такое обращение вполне нормально. Единственным ограничением является то, что если планируется дёргать методы объекта, который хранится в shared_ptr, из разных потоков, то эти методы должны быть thread safe (т.е. сами заботиться о синхронизации доступа к переменным-членам объекта).
> Просто достаточно редкое, узкое, специфичное и просто нарывается на то, чтобы провести инспекцию - а чем руководтствовались люди, когда выбирали именно такой подход.
А какой подход по-вашему здесь выбирают те, которые ничем не руководствуются?
Явные указатели? Явные new / delete?
Поищите на github по слову shared_ptr, чтобы понять, что это не такое редкое решение. Не даром оно попало в стандарт языка C++. А в редакции C++14 вообще можно программировать без new/delete (см. std::make_shared, std::make_unique).
Редкость заключается в том, что объектов, которые требуют разделения доступа к себе в многопоточном приложении не так много; да и сами многопоточные приложения - это подкласс всех приложений. В однопоточном приложении можно обойтись явным конструированием подобъектов в конструкторе класса или с помощью std::unique_ptr.
В дополнение приведу ссылку на мой комментарий по этой же теме: #comment_63178054
раскрыть ветку (1)
если из моего сообщения вы подумали, что shared_ptr - это плохо, то Вы меня не так поняли.
И давайте определимся, о чем мы говорим, а то я не понимаю что отвечать.
показать ответы
Не надо отрекаться от своего мнения. Вы сказали:
> Просто достаточно редкое, узкое, специфичное и просто нарывается на то, чтобы провести инспекцию - а чем руководтствовались люди, когда выбирали именно такой подход.
Откуда очевидно следует, что Вы пренебрежительно относистесь к новым возможностям С++ в лице shared_ptr.
Если Вы teamlead, я совсем не завидую Вашим подчинённым. Если нет, ещё не поздно пересмотреть своё отношение к нововведениям в стандарте C++.
С shared_ptr что-либо сломать довольно сложно, если строго следовать правилу, что время хранимого в shared_ptr указателя должно быть в рамках времени жизни shared_ptr: чтоб все на право и налево не раскидывали вызовы shared_ptr::get() и не сохраняли полученные из них указатели. Такого рода проблемы выявляются на code review.
раскрыть ветку (1)
Любая вещь в неумелых руках добавит ебли. В частности - указатели. std::shared_ptr в частности связывает ебущегося по рукам и ногам, чтобы он нигде не накосячил. Приведите мне хоть один пример использования shared_ptr без оператора get() и new (т.к. для создания есть метод std::make_shared) в котором можно бы было нарваться на проблемы shared_ptr?
С указателями таких проблем масса. Одна обработка исключений чего стоит: невнимательность при обработке исключения может привести к пропущенному вызову delete/free для указателя и обычной утечки памяти. Поэтому использование указателей добавит БОЛЬШЕ ебли.
раскрыть ветку (1)
А я и не говорю, что надо использовать raw pointers.
Вижу, что до Вас мой месседж не дошел. Продолжать дискуссию без взаимопонимания не вижу смысла.