А я не мечтал, я просто писал и пишу так, что бы было понятно, а не что бы кому то угодить с правилами, ну и соответственно принимал последствия, 2/3 моя высшая оценка по сочинению, зато мне так было намного проще чем если бы я заставлял себя писать "правильно"
Всегда было интересно, а за чем сначало учить "правильно" писать, а потом ещё и учить "правильно" читать/произносить. Может всем будет проще сразу делать и то и то просто правильно? Ответ - так исторически сложилось конечно все объясняет, но тогда где же наши твердые знаки на концах слов и прочие "правильные" вещи?
Вы забыли про инфы и не сигнальные наны. Их как будете сортировать? Они ж как нулы в эскуэле, не сравнимы сами с собой, а наны ещё и ни с чем другим. Вот когда их исключите из массива вот тогда у вас вик ордеринг получится. Хотел написать сначало, что стронг, но кажется два нуля не позволяют это сказать, но я не уверен. Правильная сортировка даблов это сложно.
В целом я с вами согласен, но на практике такой тип скорее всего будет и так маленький по размеру, поэтому такая оптимизация будет скорее всего бессмысленной, ибо вам придется хранить такие объекты в куче + виртуальность либо в варианте либо иметь 2 контейнера. В общем на практике найти применение этому сложно.
Зачем нужен этот новый оператор? Самый простой и обоснованный ответ это автоматическая генерация всех остальных операторов. Самое важное в нем то, что компилятор может предоставить дефолтную реализацию. Что это значит на практике?
struct X{
private: int data = {};
public: constexpr auto operator <=>(const &X, const &X) = default;)
}
Все, объекты класса Х теперь можно сравнивать друг с другом - не надо писать километры бойлер плэйт кода. Когда это не сработает? Тогда когда есть члены класса у которых нет дефолтного оператора <=> тогда придется немного повозиться и определить аж 2 оператора: == и вот этот новый спэйсшип, остальные будут сгенерированы сами, но это все равно сильно меньше чем дедовским способом и самое главное у вас не будет места для тупой опечатки, семантика всех операторов будет согласованной и корректной.
Есть ещё одно место зачем он нужен, например вызов дженерик сортировки для массива флотов/даблов это вообще-то УБ, внезапно да? Вот у этих самых сторонников дедовских способов щас уверен подгорело, сто лет так пишем и никаких УБ не видели. Есть даже целый ток от Шона (забыл фамилию), который из адоба, который детально объясняет почему так. Так вот что бы писать алгоритмы правильно и выставлять наружу требования к типам собственно и нужны эти новые типы одеринга и именно поэтому они разные, а не как тут товарищ выше предлагал все в один энум запихать. Алгоритм может быть перегружен для правильной сортировки даблов как раз за счёт разных типов одеринга, да и чего угодно с партиал одерингом, называется топологическая сортировка и работает совсем не так как ваши эти квик сорты, которые вообще говоря требуют вик одеринга.
Зачем на практике нужно различать Вик и Стронг я пока не нашел, а в чем разница спросите вы? Ну при Стронг одеринге и == ГАРАНТИРОВАНО можете использовать хоть правый хоть левый операнд в ЛЮБОЙ функции и получать один и тот же результат. Ну это только если человек который реализовывал спэйсшип возвращающий Стронг ордеринг понимал в чем разница и не допустил ошибок.
Я хз где это ограничение вообще можно применить, ну вот Инты у них Стронг ордеринг, а у структуры где есть много полей, и сравнение ведётся только по части из них по определению Вик ордеринг, ну и чё?
Этот момент конечно очень слабо освящён и допустить ошибку очень просто если сами реализуете, а не компилятор дефолт генерит можно по ошибке/не знанию/не пониманию объявить тип возвращаемого значения оператора спэйсшип как Стронг ордеринг, но это почти навярнека ошибка иначе вы бы использовали дефолтную реализацию.
Опишите подробнее ваш не удачный опыт использования:
с++ или язык с рефлексией
рантайм/позднее связывание/интерфейсы или как здесь шаблоны/дженерики/компилтайм
Описание самих зависимостей обрабатывается в рантайме или как здесь в компил тайме
Какая именно боль у вас от ДИ
Ответы на эти вопросы сильно меняют ощущения от использования. Вот автор выставляет одним из главных достоинств скорость работы, которая ему важна в лоу латенси коде, а на самом деле сам факт компил тайма намного важнее скорости.
Если собралось, то доброй половины проблем которые вы имеете с интерфейсами просто не будет, а если не собралось, то конечно вы сначало проклянете все эти шаблоны с их очень понятными ошибками, но потом когда все таки почините, то снова будете рады тому, что это не интерфейсы.
А ещё вам не надо на каждую зависимость писать интерфейс и еслииу вас моки то при каждом изменение интерфейса вам не надо делать его 3 раза, а ещё в дебаге вы увидите настоящие типы ВСЕХ зависимостей сразу и одновременно, а не какой-нибудь пимпл который пока не пробьешься сквозь стэк не узнаешь и то по одной штуке за раз. Ну и само собой без виртуальных вызовов конечно же сильно быстрее, но это уже как раз вишенка, а не сам торт.
Я уже не вспомню и навярнека буду сейчас использовать не правильные термины, но здесь на Хабре была когда-то давно статья где рассказывается, что энергия уходит на смену состояния вентилей, так вот придумали такую схему при которой эта энергия запасается и может быть высвобождена при реверсе состояния. В обычной же схеме ничего не запасается, а цпу работает как сопротивление - всегда нагревается при смене состояния. Таким образом новая схема на какие то хер десятых потреблела меньше энергии и меньше грелась. Так вот, вот эту энергию, необходимую для смены состояния, и можно считать полезной работой. И тогда КПД цпу действительно в районе 1% процента.
В дополнение к тому что выше, частично можно, пишите код в функциях/лямбдах с пометкой constexpr.
Не любой код можно запихнуть в constexpr, не все УБ будут отловлены, но если компилятор ругнеться на УБ то это точно УБ, а не может да может нет как с ворнингами.
Программа может быть написана так, что желание или нежелание избежать UB на это не влияет
Извините, я не понимаю, что вы хотите сказать.
Я знаком с вопросом более чем
Ну, хорошо, тогда я сделал все что мог, что бы помочь вам избавиться от ложных убеждений, но если честно то как вы разъясняли суть некоторых багов у меня вызывает сомнения в том, что вы до конца разобрались с вопросом. Я не стал придираться к некоторым другим формулировкам, потому что там по сути нормально и можно игнорировать некоторые не точности, но вот эти 2 объяснения были не верны в корне.
Из опыта я знаю, что если люди допускают небольшие не точности ВМЕСТЕ с не корректными формулировками, то это верный индикатор не полного понимания проблемы.
Но опять, же вы художник вы так видите, я не против, считайте мои комментарии адресованными не вам, а тем кто будет читать эту статью, пусть они сами решают с какой версией соглашаться.
Рекомендую ознакомиться с историей вопроса и пройти по всем ссылкам https://stackoverflow.com/questions/48067323/c-why-cant-this-be-a-nullptr в дополнение к стэку так же рекомендую заглянуть в современный стандарт https://en.cppreference.com/w/c/language/operator_member_access смотрите секцию dereferencing, а ещё вы можете найти здесь же на Хабре статьи про УБ + ещё здесь есть серия статей от компилятора строителя, можете написать в личку этим людям, а ещё можете написать вопрос в комитет для разъяснения, вот прям тут вызывайте российского представителя к сожалению не могу правильно написать имя юзера из мобильного Фокса, antoshka из Яндекса
Даже не собираюсь, УБ по определению может сгенерировать любой код, в том числе тот на чье поведение вы расчитываете, но это не значит что код с таким поведением будет сгенерирован в другом компиляторе включая тот же самый с другими флагами.
проблема не в дейли, а в том, что вы не слушаете, что говорят ваши коллеги, а ваши коллеги не прислушиваются к тому, что говорите вы.
Я почти согласен с этим, за исключением того, что я не считаю это проблемой, а скорее нормой. Почему вы считаете что это проблема?
Как вы считаете, что больше соответствует заявленным принципам аджайла (я напомню - люди важнее процессов)
Кто хочет приходит на дэйли слушает, если есть что сказать говорит, кто не хочет не участвуют/приходит, кто считает более удобным пишет в чат, что хотел сказать и читает автоматически сгенерированную стенограмму онлайн собрания.
Все ходят на дэйли, хотят не хотят не важно, все что то говорят есть что сказать или нет не важно, все хотя бы делают вид что слушает интересно или нет не важно
Не так, что кто-то делится проблемой когда он зашёл в тупик и всрал уже немало времени на безуспешные попытки решения, а сильно заранее, ещё на этапе начала решения проблемы.
Ну на самом деле, людям не очевидно, что чей либо совет сработает лучше чем их собственные идеи. Я наблюдал это неоднократно. А ещё это довольно редкая ситуация когда совет действительно дельный, а не бестолковый, собственно поэтому и не очевидно, что лучше последовать чьему то совету, а не сразу делать по своему.
Я склонен считать, что дэйли это форма микороменеджмента, которая может быть полезна если у вас в команде превалируют люди с недостатком опыта и/или у кого сложности с тайм менеджментом.
Мне кажется как то получше чем то что есть. + это должно работать как то так для присваивания
ExList = { 1, 2 } =>
if ExList.IsNull () { ExList = new() { 1, 2 } }
else { ExList.Clear(); ExList = { 1, 2 } }
И как то так для добавления
if ExList.IsNull() { ExList = new() {1, 2 } }
else { ExList.Add(1); ExList(2); }
Я не очень представляю в каком случае будет иметь смысл НЕ инициализировать объект заданными значениями если он нулл, а кидать исключение как сейчас делает такой синтаксис, ну и явный += как то заметней чем разное поведение в зависимости от отсутвия наличия new ()
Вообще как раз мнение людей не пишущих на этом языке о синтаксисе часто менее предвзяты чем мнение тех кто пишет на нем каждый день, так что зря товарища выше минусят.
Компиляторы почему-то предпочитают второе, поэтому объект мьютекса никогда не блокируется.
Ну это не так. Тот код эквивалентен
{ auto _ = std::unique_lock(m);}
Мьютекс блокируется и сразу разблокируется и это не то же самое, что он вообще не блокируется.
Формально ошибки нет, мы можем вызывать функции класса, не обращаясь к данным экземпляра этого класса. В этом конкретном случае у нас получается вырожденная функция класса.
Это тоже не верно, формальная ошибка заключается в том, что нельзя разыменовывать нулевой указатель. Мало того, современный приличный компилятор вот такой код (вместе с телом ифа) просто удалит ни на секунду не задумываясь как заведомое УБ.
Ну у нас все так и было, команда где 6-7 человек, дэйли ~10 минут, в одно и тоже время. А теперь почему я нахожу это бесполезным:
вот те советы которые мне изредка давали коллеги были не просто нейтральными, а почти всегда вредными, потому что за несколько секунд они не понимали тех проблем о которых я говорил, а мои проблемы всегда сложные, лёгкие я и так быстро решаю
Мои редкие советы, когда я точно знал в чем у них проблема, игнорировались что потом приводило к дискашенам на ревью и не понимаем зачем что то менять если и так зашибись
Большая часть того потока слов которые попадали в мои уши была обсалютно бесполезна для меня
Никакое дэйли никогда не спасет вас от вопросов от менеджера потому что у него нет времени читать джиру или спросить то же самое у ПО он просто напрямую у вас спросит все что хочет знать и не один раз и не один менеджер, правда это не часто и менеджеров не много, но бывает
Я сначало следовал ритуалу делал как говорили, смотрел как это работает и только потом меня начало от этого тошнить когда я увидел, что это не работает как минимум для меня. Но я не припомню что бы советы других членов команды не мне кому то помогали, никто не вспоминал о том что было сказано на дэйли после дэйли, я пару раз на это натыкался когда напоминал, что другой человек это уже говорил на дэйли.
Ваши описания тоже выглядят как маркетинг они обезличены, в них только положительные гипотетические кейсы - как в теории это может помочь, как из буклета по скраму, в них нет вашего личного опыта, что ещё больше заставляет меня сомневаться в них.
Как конкретно вам помогает дэйли? Почему вы верите, что другим членам команды это помогает, как вы об этом узнаете? Почему по вашему тоже самое не сработает если делать это асинхронно в общем чате, который не обязателен для немедленного чтения? А вы так пробовали? А вы пробовали вообще без дэйли? У вас есть базавая линия с которой нужно сравнивать?
Если одна сторона стучит кулаком и ставит условия в ультимативной форме, то хорошего сотрудничества не выйдет.
Так команда это те кто собственно и делает дело, при этом все обязательства никуда не уходят. Ну это как вы придёте к хирургу и начнёте с его командой (а у него команда) договариваться не о том что вам нужно, а о том как они это будет делать. Только потому что вы деньги платите.
Какая вам(как тому кто платит деньги) разница есть у них дэйли ретро и демки и какой длины спринт, если проекты движутся в правильном направлении с удовлетворительной скоростью? Это по сути аналог микороменеджмента на уровне команды. Да иногда надо, если есть проблемы и команда не может их решить сама, но если проблем нет зачем это?
есть отдельный трехнедельный спринт именно на разгребание техдолга
Я не могу говорить за всех, но у меня сложилось впечатление, что многим разработчикам на самом деле пофигу хороший код плохой код, к тому же очень часто критерий хорошести произвольный. У нас есть определение тех долга, это проблемы которые не видны пользователям, но замедляют разработку.
Дело в том, что то что замедляет меня не замедляет Васю, а то что замедляет Васю не беспокоит меня. Раньше у нас было много крашей и я починил ключевые системные вещи, это не значит что я в одиночку все починил, но я сделал то что никто другой не смог. Краши теперь редкость и я больше не вижу особого смысла что то менять фиксить тот самый долг. Да очевидно я фиксил не тех долг а краши, они по определению не тех долг, хотя все называли это тех долгом. А теперь остался тех долг и мне все равно как его будут или не будут фиксить. Оно работает, люди привыкли к тому что есть и они не хотят перепривыкать.
Да оно кривое, но работает. Да там много табличек туда не ходи этого не делай ну и что? Ну переделаем на другое и что? Будут другие таблички и по началу даже снова краши пока люди привыкнут к новому, да и самое главное я (могу ошибаться) не вижу желание у людей что то менять - работает же.
Есть конечно популисты которые мыслят лозунгами (хотя на практике свою экспертизу не подтвердили) которые готовы менять одно на другое согласно лозунгу. И мне приходиться тратить время на демократию, на разоблачение этих лозунгов в нашем случае. А когда речь идёт о действительно потенциально разумных изменениях то понимают это единицы у остальных нету хард скилов и для них это не убедительно. Это очень похоже на религиозные споры креаценистов со сторонниками эволюции.
Это я к чему, хард скилы решают, есть ли смысл в том что бы что то менять на другое или нет. При недостатке хард скилов любая элегантная система может и будет использована не так как задумывалось.
Тимлид отправился договариваться со стейкхолдерами что теперь мы им будем демонстрировать сделанное не каждые две недели, а раз в полтора месяца
Ключевая часть, для меня, в этом предложении - пошел договариваться, т.е. не проинформировал о смене спринта по решению команды, а пошел на поклон с прошением. Это конечно лучше чем бан на обсуждение, но все же до заявленных ценностей аджайла не дотягивает.
Да, сейчас много где есть перекос в обратную сторону ("софт важнее хард"), это просто вопрос времени, рано или поздно нормализуется.
Я бы хотел разделять с вами этот оптимистичный взгляд как я делал это раньше, но у меня все больше свидетельств тому, что этого не произойдет. Ну например, этот перекос начинается уже с младшей школы. С одной стороны я не против, что детей учат договариваться друг с другом да и вообще общаться, с другой стороны их забывают научить собственно дело делать и вот это мне уже не нравится. А происходит так потому что учить дело делать оказывается сложнее чем учить догавариваться, КПИ по делу выглядят сильно хуже чем КПИ по болталогии. Т.е. как раньше уже не будет, никакого баланса не будет, но это не значит, что это проблема или плохо, может быть уровень хард скилов закастылюет АИ когда нибудь, но мне это не нравится, потому что здесь и сейчас мне приходиться периодически страдать из за этого.
Бегите оттуда
Ну нет, я в полне доволен своей конторой и моим положением в ней. К тому же недавно произошли изменения в этом плане, у нас появился процес по изменению процесса, но я пока не в курсе работает это или нет. Но мне это уже мало интересно, я сменил роль с члена команды на роль свободного самурая - стаф девелопер, я теперь вне команды, у меня нет дэйли, спринтов, демо, минимум митингов и я наконец-то просто занят делом без лишних присяданий. Время от времени меня отвлекают от построения космических кораблей когда надо что то починить, а у других почему то не получается (подозреваю недостаток тех самых хард скилов), но в целом я нахожу это даже полезной сменой деятельности.
Вот чем я не доволен так это попытками сделать из меня я даже не знаю кого полу менеджера полу тех лида - у нас это называется тех домэйн гардиан. Человек который определяет курс партии по какому то широкому тех вопросу ( ну например вопрос многопоточности/асинхронщины или управления памятью или гуй и т.д.) и заодно менеджерит список тех долга тасков по этому вопросу. Болтавни очень много и меня это напрягает, а толку я пока не увидел - тех долг не уменьшается. Какая то смесь демократии (условием становления гардионом является убеждение других в верности курса) с отсутствием власти, я не смогу прийти на планирование к команде и сказать вы берете этот тикет в спринт. Я только должен грумить этот бэклог и ждать как с моря погоды, что тикеты будут браться в спринт и делаться, сам при этом я их делать не должен - передача знаний и вообще скэйлинг моих возможностей с одного юнита - меня, на много юнитов которые мне при этом не подчиняются. Я вообще не хочу вот в это все, но меня зачем то туда пихают.
Короче какая то очередная хрень из мира эффективного менеджмента в которую я не верю, но посмотрю как пойдет, может это я не прав, хорошо хоть есть с кем сравнивать, у других пока что тоже 0 результатов, так что может это все таки хрень, а не я дурак.
А я не мечтал, я просто писал и пишу так, что бы было понятно, а не что бы кому то угодить с правилами, ну и соответственно принимал последствия, 2/3 моя высшая оценка по сочинению, зато мне так было намного проще чем если бы я заставлял себя писать "правильно"
Всегда было интересно, а за чем сначало учить "правильно" писать, а потом ещё и учить "правильно" читать/произносить. Может всем будет проще сразу делать и то и то просто правильно? Ответ - так исторически сложилось конечно все объясняет, но тогда где же наши твердые знаки на концах слов и прочие "правильные" вещи?
Да, спасибо что напомнили его имя, вот тот самый ток https://m.youtube.com/watch?v=2FAi2mNYjFA
Ну может и так только код все равно продолжит работать, а не
Т.е. действия вполне возможны и результат тоже ясный - нан, но вот флаг эксепции может стоять, а может и нет - ну ладно.
Я из мира с++, а тут у нас можно почти все что угодно, https://en.cppreference.com/w/cpp/types/numeric_limits/signaling_NaN
Вы забыли про инфы и не сигнальные наны. Их как будете сортировать? Они ж как нулы в эскуэле, не сравнимы сами с собой, а наны ещё и ни с чем другим. Вот когда их исключите из массива вот тогда у вас вик ордеринг получится. Хотел написать сначало, что стронг, но кажется два нуля не позволяют это сказать, но я не уверен. Правильная сортировка даблов это сложно.
В целом я с вами согласен, но на практике такой тип скорее всего будет и так маленький по размеру, поэтому такая оптимизация будет скорее всего бессмысленной, ибо вам придется хранить такие объекты в куче + виртуальность либо в варианте либо иметь 2 контейнера. В общем на практике найти применение этому сложно.
Зачем нужен этот новый оператор? Самый простой и обоснованный ответ это автоматическая генерация всех остальных операторов. Самое важное в нем то, что компилятор может предоставить дефолтную реализацию. Что это значит на практике?
Все, объекты класса Х теперь можно сравнивать друг с другом - не надо писать километры бойлер плэйт кода. Когда это не сработает? Тогда когда есть члены класса у которых нет дефолтного оператора <=> тогда придется немного повозиться и определить аж 2 оператора: == и вот этот новый спэйсшип, остальные будут сгенерированы сами, но это все равно сильно меньше чем дедовским способом и самое главное у вас не будет места для тупой опечатки, семантика всех операторов будет согласованной и корректной.
Есть ещё одно место зачем он нужен, например вызов дженерик сортировки для массива флотов/даблов это вообще-то УБ, внезапно да? Вот у этих самых сторонников дедовских способов щас уверен подгорело, сто лет так пишем и никаких УБ не видели. Есть даже целый ток от Шона (забыл фамилию), который из адоба, который детально объясняет почему так. Так вот что бы писать алгоритмы правильно и выставлять наружу требования к типам собственно и нужны эти новые типы одеринга и именно поэтому они разные, а не как тут товарищ выше предлагал все в один энум запихать. Алгоритм может быть перегружен для правильной сортировки даблов как раз за счёт разных типов одеринга, да и чего угодно с партиал одерингом, называется топологическая сортировка и работает совсем не так как ваши эти квик сорты, которые вообще говоря требуют вик одеринга.
Зачем на практике нужно различать Вик и Стронг я пока не нашел, а в чем разница спросите вы? Ну при Стронг одеринге и == ГАРАНТИРОВАНО можете использовать хоть правый хоть левый операнд в ЛЮБОЙ функции и получать один и тот же результат. Ну это только если человек который реализовывал спэйсшип возвращающий Стронг ордеринг понимал в чем разница и не допустил ошибок.
Я хз где это ограничение вообще можно применить, ну вот Инты у них Стронг ордеринг, а у структуры где есть много полей, и сравнение ведётся только по части из них по определению Вик ордеринг, ну и чё?
Этот момент конечно очень слабо освящён и допустить ошибку очень просто если сами реализуете, а не компилятор дефолт генерит можно по ошибке/не знанию/не пониманию объявить тип возвращаемого значения оператора спэйсшип как Стронг ордеринг, но это почти навярнека ошибка иначе вы бы использовали дефолтную реализацию.
Опишите подробнее ваш не удачный опыт использования:
с++ или язык с рефлексией
рантайм/позднее связывание/интерфейсы или как здесь шаблоны/дженерики/компилтайм
Описание самих зависимостей обрабатывается в рантайме или как здесь в компил тайме
Какая именно боль у вас от ДИ
Ответы на эти вопросы сильно меняют ощущения от использования. Вот автор выставляет одним из главных достоинств скорость работы, которая ему важна в лоу латенси коде, а на самом деле сам факт компил тайма намного важнее скорости.
Если собралось, то доброй половины проблем которые вы имеете с интерфейсами просто не будет, а если не собралось, то конечно вы сначало проклянете все эти шаблоны с их очень понятными ошибками, но потом когда все таки почините, то снова будете рады тому, что это не интерфейсы.
А ещё вам не надо на каждую зависимость писать интерфейс и еслииу вас моки то при каждом изменение интерфейса вам не надо делать его 3 раза, а ещё в дебаге вы увидите настоящие типы ВСЕХ зависимостей сразу и одновременно, а не какой-нибудь пимпл который пока не пробьешься сквозь стэк не узнаешь и то по одной штуке за раз. Ну и само собой без виртуальных вызовов конечно же сильно быстрее, но это уже как раз вишенка, а не сам торт.
Я уже не вспомню и навярнека буду сейчас использовать не правильные термины, но здесь на Хабре была когда-то давно статья где рассказывается, что энергия уходит на смену состояния вентилей, так вот придумали такую схему при которой эта энергия запасается и может быть высвобождена при реверсе состояния. В обычной же схеме ничего не запасается, а цпу работает как сопротивление - всегда нагревается при смене состояния. Таким образом новая схема на какие то хер десятых потреблела меньше энергии и меньше грелась. Так вот, вот эту энергию, необходимую для смены состояния, и можно считать полезной работой. И тогда КПД цпу действительно в районе 1% процента.
А в чем собственно беда? Сахар он на то и сахар что бы вот такие неконсистености скыравать за простым синтаксисом, ну или я не понял о чем вы.
В дополнение к тому что выше, частично можно, пишите код в функциях/лямбдах с пометкой constexpr.
Не любой код можно запихнуть в constexpr, не все УБ будут отловлены, но если компилятор ругнеться на УБ то это точно УБ, а не может да может нет как с ворнингами.
Извините, я не понимаю, что вы хотите сказать.
Ну, хорошо, тогда я сделал все что мог, что бы помочь вам избавиться от ложных убеждений, но если честно то как вы разъясняли суть некоторых багов у меня вызывает сомнения в том, что вы до конца разобрались с вопросом. Я не стал придираться к некоторым другим формулировкам, потому что там по сути нормально и можно игнорировать некоторые не точности, но вот эти 2 объяснения были не верны в корне.
Из опыта я знаю, что если люди допускают небольшие не точности ВМЕСТЕ с не корректными формулировками, то это верный индикатор не полного понимания проблемы.
Но опять, же вы художник вы так видите, я не против, считайте мои комментарии адресованными не вам, а тем кто будет читать эту статью, пусть они сами решают с какой версией соглашаться.
Рекомендую ознакомиться с историей вопроса и пройти по всем ссылкам https://stackoverflow.com/questions/48067323/c-why-cant-this-be-a-nullptr в дополнение к стэку так же рекомендую заглянуть в современный стандарт https://en.cppreference.com/w/c/language/operator_member_access смотрите секцию dereferencing, а ещё вы можете найти здесь же на Хабре статьи про УБ + ещё здесь есть серия статей от компилятора строителя, можете написать в личку этим людям, а ещё можете написать вопрос в комитет для разъяснения, вот прям тут вызывайте российского представителя к сожалению не могу правильно написать имя юзера из мобильного Фокса, antoshka из Яндекса
Даже не собираюсь, УБ по определению может сгенерировать любой код, в том числе тот на чье поведение вы расчитываете, но это не значит что код с таким поведением будет сгенерирован в другом компиляторе включая тот же самый с другими флагами.
Я почти согласен с этим, за исключением того, что я не считаю это проблемой, а скорее нормой. Почему вы считаете что это проблема?
Как вы считаете, что больше соответствует заявленным принципам аджайла (я напомню - люди важнее процессов)
Кто хочет приходит на дэйли слушает, если есть что сказать говорит, кто не хочет не участвуют/приходит, кто считает более удобным пишет в чат, что хотел сказать и читает автоматически сгенерированную стенограмму онлайн собрания.
Все ходят на дэйли, хотят не хотят не важно, все что то говорят есть что сказать или нет не важно, все хотя бы делают вид что слушает интересно или нет не важно
Ну на самом деле, людям не очевидно, что чей либо совет сработает лучше чем их собственные идеи. Я наблюдал это неоднократно. А ещё это довольно редкая ситуация когда совет действительно дельный, а не бестолковый, собственно поэтому и не очевидно, что лучше последовать чьему то совету, а не сразу делать по своему.
Я склонен считать, что дэйли это форма микороменеджмента, которая может быть полезна если у вас в команде превалируют люди с недостатком опыта и/или у кого сложности с тайм менеджментом.
ExList += { 1, 2 } // add semantic
ExList = { 1, 2 } // assign semantic
Мне кажется как то получше чем то что есть. + это должно работать как то так для присваивания
ExList = { 1, 2 } =>
if ExList.IsNull () { ExList = new() { 1, 2 } }
else { ExList.Clear(); ExList = { 1, 2 } }
И как то так для добавления
if ExList.IsNull() { ExList = new() {1, 2 } }
else { ExList.Add(1); ExList(2); }
Я не очень представляю в каком случае будет иметь смысл НЕ инициализировать объект заданными значениями если он нулл, а кидать исключение как сейчас делает такой синтаксис, ну и явный += как то заметней чем разное поведение в зависимости от отсутвия наличия new ()
Вообще как раз мнение людей не пишущих на этом языке о синтаксисе часто менее предвзяты чем мнение тех кто пишет на нем каждый день, так что зря товарища выше минусят.
Ну это не так. Тот код эквивалентен
Мьютекс блокируется и сразу разблокируется и это не то же самое, что он вообще не блокируется.
Это тоже не верно, формальная ошибка заключается в том, что нельзя разыменовывать нулевой указатель. Мало того, современный приличный компилятор вот такой код (вместе с телом ифа) просто удалит ни на секунду не задумываясь как заведомое УБ.
Ну у нас все так и было, команда где 6-7 человек, дэйли ~10 минут, в одно и тоже время. А теперь почему я нахожу это бесполезным:
вот те советы которые мне изредка давали коллеги были не просто нейтральными, а почти всегда вредными, потому что за несколько секунд они не понимали тех проблем о которых я говорил, а мои проблемы всегда сложные, лёгкие я и так быстро решаю
Мои редкие советы, когда я точно знал в чем у них проблема, игнорировались что потом приводило к дискашенам на ревью и не понимаем зачем что то менять если и так зашибись
Большая часть того потока слов которые попадали в мои уши была обсалютно бесполезна для меня
Никакое дэйли никогда не спасет вас от вопросов от менеджера потому что у него нет времени читать джиру или спросить то же самое у ПО он просто напрямую у вас спросит все что хочет знать и не один раз и не один менеджер, правда это не часто и менеджеров не много, но бывает
Я сначало следовал ритуалу делал как говорили, смотрел как это работает и только потом меня начало от этого тошнить когда я увидел, что это не работает как минимум для меня. Но я не припомню что бы советы других членов команды не мне кому то помогали, никто не вспоминал о том что было сказано на дэйли после дэйли, я пару раз на это натыкался когда напоминал, что другой человек это уже говорил на дэйли.
Ваши описания тоже выглядят как маркетинг они обезличены, в них только положительные гипотетические кейсы - как в теории это может помочь, как из буклета по скраму, в них нет вашего личного опыта, что ещё больше заставляет меня сомневаться в них.
Как конкретно вам помогает дэйли? Почему вы верите, что другим членам команды это помогает, как вы об этом узнаете? Почему по вашему тоже самое не сработает если делать это асинхронно в общем чате, который не обязателен для немедленного чтения? А вы так пробовали? А вы пробовали вообще без дэйли? У вас есть базавая линия с которой нужно сравнивать?
Так команда это те кто собственно и делает дело, при этом все обязательства никуда не уходят. Ну это как вы придёте к хирургу и начнёте с его командой (а у него команда) договариваться не о том что вам нужно, а о том как они это будет делать. Только потому что вы деньги платите.
Какая вам(как тому кто платит деньги) разница есть у них дэйли ретро и демки и какой длины спринт, если проекты движутся в правильном направлении с удовлетворительной скоростью? Это по сути аналог микороменеджмента на уровне команды. Да иногда надо, если есть проблемы и команда не может их решить сама, но если проблем нет зачем это?
Я не могу говорить за всех, но у меня сложилось впечатление, что многим разработчикам на самом деле пофигу хороший код плохой код, к тому же очень часто критерий хорошести произвольный. У нас есть определение тех долга, это проблемы которые не видны пользователям, но замедляют разработку.
Дело в том, что то что замедляет меня не замедляет Васю, а то что замедляет Васю не беспокоит меня. Раньше у нас было много крашей и я починил ключевые системные вещи, это не значит что я в одиночку все починил, но я сделал то что никто другой не смог. Краши теперь редкость и я больше не вижу особого смысла что то менять фиксить тот самый долг. Да очевидно я фиксил не тех долг а краши, они по определению не тех долг, хотя все называли это тех долгом. А теперь остался тех долг и мне все равно как его будут или не будут фиксить. Оно работает, люди привыкли к тому что есть и они не хотят перепривыкать.
Да оно кривое, но работает. Да там много табличек туда не ходи этого не делай ну и что? Ну переделаем на другое и что? Будут другие таблички и по началу даже снова краши пока люди привыкнут к новому, да и самое главное я (могу ошибаться) не вижу желание у людей что то менять - работает же.
Есть конечно популисты которые мыслят лозунгами (хотя на практике свою экспертизу не подтвердили) которые готовы менять одно на другое согласно лозунгу. И мне приходиться тратить время на демократию, на разоблачение этих лозунгов в нашем случае. А когда речь идёт о действительно потенциально разумных изменениях то понимают это единицы у остальных нету хард скилов и для них это не убедительно. Это очень похоже на религиозные споры креаценистов со сторонниками эволюции.
Это я к чему, хард скилы решают, есть ли смысл в том что бы что то менять на другое или нет. При недостатке хард скилов любая элегантная система может и будет использована не так как задумывалось.
Не угадали, это был сарказм.
Ключевая часть, для меня, в этом предложении - пошел договариваться, т.е. не проинформировал о смене спринта по решению команды, а пошел на поклон с прошением. Это конечно лучше чем бан на обсуждение, но все же до заявленных ценностей аджайла не дотягивает.
Я бы хотел разделять с вами этот оптимистичный взгляд как я делал это раньше, но у меня все больше свидетельств тому, что этого не произойдет. Ну например, этот перекос начинается уже с младшей школы. С одной стороны я не против, что детей учат договариваться друг с другом да и вообще общаться, с другой стороны их забывают научить собственно дело делать и вот это мне уже не нравится. А происходит так потому что учить дело делать оказывается сложнее чем учить догавариваться, КПИ по делу выглядят сильно хуже чем КПИ по болталогии. Т.е. как раньше уже не будет, никакого баланса не будет, но это не значит, что это проблема или плохо, может быть уровень хард скилов закастылюет АИ когда нибудь, но мне это не нравится, потому что здесь и сейчас мне приходиться периодически страдать из за этого.
Ну нет, я в полне доволен своей конторой и моим положением в ней. К тому же недавно произошли изменения в этом плане, у нас появился процес по изменению процесса, но я пока не в курсе работает это или нет. Но мне это уже мало интересно, я сменил роль с члена команды на роль свободного самурая - стаф девелопер, я теперь вне команды, у меня нет дэйли, спринтов, демо, минимум митингов и я наконец-то просто занят делом без лишних присяданий. Время от времени меня отвлекают от построения космических кораблей когда надо что то починить, а у других почему то не получается (подозреваю недостаток тех самых хард скилов), но в целом я нахожу это даже полезной сменой деятельности.
Вот чем я не доволен так это попытками сделать из меня я даже не знаю кого полу менеджера полу тех лида - у нас это называется тех домэйн гардиан. Человек который определяет курс партии по какому то широкому тех вопросу ( ну например вопрос многопоточности/асинхронщины или управления памятью или гуй и т.д.) и заодно менеджерит список тех долга тасков по этому вопросу. Болтавни очень много и меня это напрягает, а толку я пока не увидел - тех долг не уменьшается. Какая то смесь демократии (условием становления гардионом является убеждение других в верности курса) с отсутствием власти, я не смогу прийти на планирование к команде и сказать вы берете этот тикет в спринт. Я только должен грумить этот бэклог и ждать как с моря погоды, что тикеты будут браться в спринт и делаться, сам при этом я их делать не должен - передача знаний и вообще скэйлинг моих возможностей с одного юнита - меня, на много юнитов которые мне при этом не подчиняются. Я вообще не хочу вот в это все, но меня зачем то туда пихают.
Короче какая то очередная хрень из мира эффективного менеджмента в которую я не верю, но посмотрю как пойдет, может это я не прав, хорошо хоть есть с кем сравнивать, у других пока что тоже 0 результатов, так что может это все таки хрень, а не я дурак.