Козленок который считал до десяти
В детстве я ржал над мультиком, где козленок должен всех пересчитать, а иначе кораблик потонет.
Сейчас я работаю программистом и мне уже нифига не смешно.
В детстве я ржал над мультиком, где козленок должен всех пересчитать, а иначе кораблик потонет.
Сейчас я работаю программистом и мне уже нифига не смешно.
я, кажется,слишком тупенькая для таких постов)) но объясните, пожалуйста, кого вам надо считать? =D Вот с экономистами выше я понимаю о чём речь) А кого считают программисты?)
или там
Найдите кто-нибудь эту же ветку на пикабу и скиньте ссылку, чтобы история целиком не повторялась.
Ошибка: робот погибает при попадании в него гранаты (именно от попадания, а не от взрыва) Д - дизайнер, П - программист.
Д: программисты всё сломали! почему так получается?!
П: естественно так получается! потому, что у гранаты масса 100 кг! зачем вы это сделали?
Д: да?! а чтобы граната в воде тонула!
П: а почему она с нормальной массой не тонет?
Д: а потому что у воды плотность большая! (прим.: больше, чем у ртути)
П: а почему плотность такая большая?!
Д: а чтобы ящики деревянные плавали!
П: а почему они иначе не плавают?!
Д: а потому что у них масса 50 кг!
П: а зачем такая масса?!
Д: а иначе они некрасиво разваливаются!
столб убрать проще простого. Холостые - не комильфо. Использование низкоуровнего языка программирования решает! Пьер Безухов должен был пройти курсы сноубордиста и по тому, подскользнувшись, не упал бы. А значит все атрибуты сохранены и нет никаких косяков.
долой руби! да здравствует ассемблер
ну конечная цель это чтобы Безухов просто не упал. Без замены обуви, погоды и грязи
как такое реализовать?
Цель получить работающую главу :)
Можно манипулировать Наташей Ростовой
1 Она может гулять в каске
2 Она может сделать реверанс в момент выстрела, при виде Царя таким образом пуля не попадет в голову
3 Да и вообще можно сделать её ниндзей которая ловит пули зубами.
Все зависит от ТЗ :)
Это наверное очень смешно только для тех, кто не сечёт ровным счётом ничего в программировании. Как я.
Спасибо) теперь понятно, почему вам уже "нифига не смешно"))
P.S. блин, а ведь это логично, странно, что сама не поняла...хотя я же сразу сказала, что тупенькая)
логично - значит объяснил хорошо.
Сами не поняли - потому что были не в контексте.
Это критическая ошибка нашего образования, называть человека тупым. Нельзя так делать, особенно по отношению к себе!
а когда зверушка - то есть, то нет?
попробуй сосчитай ее!
а еще, когда при обращении к одной зверушке - вдруг начинают плодиться другие в неисчислимых колличествах
4)Null pointer exception - зверушка была капитаном корабля, но её нет
5)Type mismatch - зверушка на самом деле стул.или атом.или ещё один корабль, но точно не зверушка.
в некоторых языках добавляется ещё немножко ада, в visual basic script - type mismatch не обязательно означает несоответствие типов.
Печаль в том, что если погрузил зверушек в кораблик больше, чем кораблик вмещает, ты узнаешь только отдавая кораблик хозяину. И приходится искать в списках пассажиров на всех остановках, где допустил эту оплошность.
Но разве весь посыл мультфильма, что сам факт счета меняет реальность и спсает ситуацию, вот в ваших примерах подобного не объяснено. Зомби будет зомби в не заваисимости посчитали его или нет итд.
поясню: shared_ptr при любом неправильном использовании только добавляет проблем. Например я видел shared_ptr как аргумент асинхронной функции обратного вызова (межпоточного каллбэка).
В больших же проектах это сразу крест. Без строжашей организации и дисциплины, разумеется. А у нас почти всегда так.
Сколько учишься? - На первом курсе такого точно не преподают, чтобы начитающих изучать программирование лишний раз не запутывать.
Там, где начитается многопоточность, уже начинают рассказывать.
Ну, указатели вообще можно не использовать :)
Нужны они для создания динамических объектов в памяти, которые строго не привязаны к какому либо объекту. Например, ты написал какой-то суперский класс, хочешь поделиться с другим человеком, но раскрывать исходники не хочешь. Тогда ты создаёшь DLL (если Windows), заголовочный файл с описанием абстрактного класса, и 2 метода внутри DLL, которые будут экспортироваться. Первый возвращает указатель на абстрактный класс (new), а второй вызывает для него delete. Потому что у каждого модуля может быть свой менеджер памяти. Внутри библиотеки наследуешься от абстрактного класса и реализуешь все методы.
Ну а тот, кто захочет твой супер-класс использовать, должен будет знать описание абстрактного класса и использовать эти 2 метода.
Приминения у указателей есть. В Си вообще всё на указателях держится. А в современном С++ почти для всех остальных задач можно найти уже готовые решения и использовать их без использования указателей. Зависит от того, за чем Вы гонитесь - простотой кода или его быстродействием.
мой месседж был в том, что в проекте должно быть жестко прописано, где живет 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
если из моего сообщения вы подумали, что shared_ptr - это плохо, то Вы меня не так поняли.
И давайте определимся, о чем мы говорим, а то я не понимаю что отвечать.
Не надо отрекаться от своего мнения. Вы сказали:
> Просто достаточно редкое, узкое, специфичное и просто нарывается на то, чтобы провести инспекцию - а чем руководтствовались люди, когда выбирали именно такой подход.
Откуда очевидно следует, что Вы пренебрежительно относистесь к новым возможностям С++ в лице shared_ptr.
Если Вы teamlead, я совсем не завидую Вашим подчинённым. Если нет, ещё не поздно пересмотреть своё отношение к нововведениям в стандарте C++.
С shared_ptr что-либо сломать довольно сложно, если строго следовать правилу, что время хранимого в shared_ptr указателя должно быть в рамках времени жизни shared_ptr: чтоб все на право и налево не раскидывали вызовы shared_ptr::get() и не сохраняли полученные из них указатели. Такого рода проблемы выявляются на code review.
Странно видеть такой комментарий от программиста. Какой у Вас опыт работы?
Даже большие компании используют этот шаблон, там, где это необходимо.
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 в этом месте будете использовать указатели?
так, давайте сразу расставим точки над i:
я ни в коем случае не говорю что shared_ptr это плохо.
Мой месседж - сам по себе shared_ptr в неумелых руках только добавит ебли. И это был целенаправленный ответ на комментарий #comment_63160497.
Любая вещь в неумелых руках добавит ебли. В частности - указатели. std::shared_ptr в частности связывает ебущегося по рукам и ногам, чтобы он нигде не накосячил. Приведите мне хоть один пример использования shared_ptr без оператора get() и new (т.к. для создания есть метод std::make_shared) в котором можно бы было нарваться на проблемы shared_ptr?
С указателями таких проблем масса. Одна обработка исключений чего стоит: невнимательность при обработке исключения может привести к пропущенному вызову delete/free для указателя и обычной утечки памяти. Поэтому использование указателей добавит БОЛЬШЕ ебли.
А я и не говорю, что надо использовать raw pointers.
Вижу, что до Вас мой месседж не дошел. Продолжать дискуссию без взаимопонимания не вижу смысла.
Козленок научился считать до 10 и имел ввиду это умение очевидным, объяснял всем зверям, что считать - это легко и (!) не больно. Но звери в меру своей необразованности не понимали даже о чем идет речь. Козленку приходилось объяснять каждому встречному как это "считать". Звери обижались на козленка, сердились за то, что он их считает, и гнались за ним (видимо хотели пиздюлей дать). Гнались-гнались, и добежали до корабля, который может выдержать только 10 пассажиров. Корабль тонул, капитан-гусь начал искать кого-то на корабле, кто умеет считать. Только когда козленок посчитал всех, их оказалось 10, корабль перестал тонуть.
Суть есть аллегория: козелок = программист, звери = пользователи. Программист умеет что-то делать и зачастую считает свои способностями элементарными, в то время как пользователи вообще не понимают о чем им хочет сказать программист и только злятся на него.
От лодки не откажусь, спасибо за внимание.
Например, в Objective C, требуется вручную удалять все объекты, которые ты насоздавал во время работы вьюшки (обычно экран приложения). Если ты где то добавил какой то объект (может быть как картинка, текстовое поле, так и обычное числовое значение), то при закрытии вьюшки его надо удалить, иначе он будет сидеть в памяти, а при повторном открытии-закрытии этой вьюшки таких объектов будет всё больше и больше, в результате в конце концов приложение просто может упасть от недостатка памяти. И не так то просто найти в здоровенном приложении из кучи экранов этот memory-leak (утечка памяти, когда она где-то выделяется приложению, и обратно не отдается). Желательно пересчитывать, сколько ты объектов насоздавал и сколько удаляется когда не нужно.
ps. Хотя может быть речь идёт о другом языке программирования, и другом применении умения считать (мне, например, как то, пришлось вспоминать тригонометрию с арккосинусами при расчёте траекторрии движения шарика)