Здесь явно не хватает информации о том, при каких условиях компилятор неявно добавляет специальные функции-члены. Популярно об этом разжевал в свое время Ховард Хинант, чей знаменитый доклад можно посмотреть здесь:https://www.youtube.com/watch?v=vLinb2fgkHk&t=2742s. А вот умные указатели тут вообще лишние, IMHO.
Все скрам-мастера, которых я лично знаю и которых наблюдал в реальной работе - это люди, которые не годятся даже в джуны-разработчики/тестеры. Это такие лютые дилетанты, которые пытаются управлять процессами. Понятно, что среди профессионалов они не пользуются авторитетом, а зачастую и уважения. Мне кажется в этом главная проблема скрам-мастеров.
Ожидал увидеть что-нибудь про SDLC, SAST... про что-нибудь, что призвано противостоять проблемам. Проблемы, кстати, толком тоже не раскрыты. Статья, как минимум, требует доработки.
Чисто из своего опыта. В своей команде мы избавились от скрам-мастера и ретро. Это реально не нужно конкретно нам. Как минимум, теперь нет раздражающих факторов. Производительность ни разу не упала при этом. Как показывает мой 20+ летний опыт в IT, сокращение количества "эффективных менеджеров", как правило, приводит к более здоровой обстановке в коллективе и, как следствие, более эффективной работе.
Очень часто скрам продают руководству как идеальное решение всех проблем. На деле появляются дополнительные эффективные менеджеры и всякие левые бизнес тренеры и консультанты, компетентность которых вызывает массу вопросов. И таки да, немного порядка скрам добавляет. Главная беда - это огромное время, затрачиваемое сотрудниками на церемонии и ритуалы скрама. Особенно когда особых проблем нет, но на ретро надо обязательно высосать из пальца улучшения и в следующем спринте потратить время на решение этих якобы проблем. Короче говоря, если в компании нет активных борцов с этим злом, то тут грусть и печаль.
Мой опыт показывает, что когда человек говорит, что знает C++, на деле оказывается, что даже половины языка он ничерта не знает, не говоря уж об STL. Смотрит на лямбду, к примеру, и спрашивает, это точно С++? Но это не сильно мешает ему писать вполне грамотный код, быстрый и безопасный.
Если взять и уволить всех этих "ключевых" сотрудников, то Сбер ничего не потеряет. Более того, уверен, даже выиграет. Такое количество эффективных менеджеров на одного работника походу только в этой организации.
Как говорится, работать удаленно не только приятно, но и круглосуточно. Есть компании, где менеджеры считают вполне нормальным привлечь сотрудника в 10 вечера якобы для решения срочного вопроса, ибо ты же все равно на удаленке. И есть даже такие, которых устраивает такое положение дел, типа я днем тогда могу своими делами заниматься, раз такое творится.
За совет спасибо! Я подумаю как тут лучше описать.
И кстати, forward преобразует lvalue в rvalue, только если передали аргумент как rvalue. Поэтому просто описать его работу одной и понятной фразой - сложная задача. Это move выполняет всегда cast к rvalue, а forward использует static_cast и сжатие ссылок. forward передает lvalue как l-value, а к rvalue применяет move, то есть приводит к rvalue;
Согласен. Где-то читал, что было предложение использовать то ли rvalue_cast, то ли cast_rvalue. Не суть уже. Универсальные ссылки тоже не устроили комитет. На cppcon2014 приняли решение именовать их как forwarding references.
В том же абзаце чуть ранее: если в качестве аргумента передано rvalue, то T выводится как бессылочный тип. Именно этот фокус и обеспечивает правильную работу forward.
_Val является l-value, т.к. имеет имя и нее можно взять адрес в памяти. Поэтому ее нужно далее сделать r-value с помощью std::move. Пожалуй, надо дополнить статью этим моментом. Спасибо!
Спасибо за статью, но, честно говоря, прочитав заголовок, я ожидал немного другое. Тут скорее "Пример плагиновой архитектуры приложения с использованием WinAPI и C++"
Компиляция на этапе выполнения в С++??? Впервые вижу такой термин в плюсах ))) Есть стойкое ощущение, что статья требует серьезной доработки.
Здесь явно не хватает информации о том, при каких условиях компилятор неявно добавляет специальные функции-члены. Популярно об этом разжевал в свое время Ховард Хинант, чей знаменитый доклад можно посмотреть здесь:https://www.youtube.com/watch?v=vLinb2fgkHk&t=2742s.
А вот умные указатели тут вообще лишние, IMHO.
Все скрам-мастера, которых я лично знаю и которых наблюдал в реальной работе - это люди, которые не годятся даже в джуны-разработчики/тестеры. Это такие лютые дилетанты, которые пытаются управлять процессами. Понятно, что среди профессионалов они не пользуются авторитетом, а зачастую и уважения. Мне кажется в этом главная проблема скрам-мастеров.
Ожидал увидеть что-нибудь про SDLC, SAST... про что-нибудь, что призвано противостоять проблемам. Проблемы, кстати, толком тоже не раскрыты. Статья, как минимум, требует доработки.
Чисто из своего опыта. В своей команде мы избавились от скрам-мастера и ретро. Это реально не нужно конкретно нам. Как минимум, теперь нет раздражающих факторов. Производительность ни разу не упала при этом. Как показывает мой 20+ летний опыт в IT, сокращение количества "эффективных менеджеров", как правило, приводит к более здоровой обстановке в коллективе и, как следствие, более эффективной работе.
Поясните, что значит "виртуальные вызовы невозможно оптимизировать"? Девиртуализация, существующая в современных компиляторах, получается блеф?
мне кажется, Страуструп юмор оценил бы
Было бы неплохо добавить, что зачастую первый принцип противоречит второму, и как решается эта проблема.
Очень часто скрам продают руководству как идеальное решение всех проблем. На деле появляются дополнительные эффективные менеджеры и всякие левые бизнес тренеры и консультанты, компетентность которых вызывает массу вопросов. И таки да, немного порядка скрам добавляет. Главная беда - это огромное время, затрачиваемое сотрудниками на церемонии и ритуалы скрама. Особенно когда особых проблем нет, но на ретро надо обязательно высосать из пальца улучшения и в следующем спринте потратить время на решение этих якобы проблем. Короче говоря, если в компании нет активных борцов с этим злом, то тут грусть и печаль.
Мой опыт показывает, что когда человек говорит, что знает C++, на деле оказывается, что даже половины языка он ничерта не знает, не говоря уж об STL. Смотрит на лямбду, к примеру, и спрашивает, это точно С++? Но это не сильно мешает ему писать вполне грамотный код, быстрый и безопасный.
Скорее std::array
Если взять и уволить всех этих "ключевых" сотрудников, то Сбер ничего не потеряет. Более того, уверен, даже выиграет. Такое количество эффективных менеджеров на одного работника походу только в этой организации.
Как говорится, работать удаленно не только приятно, но и круглосуточно. Есть компании, где менеджеры считают вполне нормальным привлечь сотрудника в 10 вечера якобы для решения срочного вопроса, ибо ты же все равно на удаленке. И есть даже такие, которых устраивает такое положение дел, типа я днем тогда могу своими делами заниматься, раз такое творится.
За совет спасибо! Я подумаю как тут лучше описать.
И кстати, forward преобразует lvalue в rvalue, только если передали аргумент как rvalue. Поэтому просто описать его работу одной и понятной фразой - сложная задача. Это move выполняет всегда cast к rvalue, а forward использует static_cast и сжатие ссылок. forward передает lvalue как l-value, а к rvalue применяет move, то есть приводит к rvalue;
Теперь понял. Это косяк, конечно. Обязательно поправлю. Спасибо большое!
Согласен. Где-то читал, что было предложение использовать то ли rvalue_cast, то ли cast_rvalue. Не суть уже. Универсальные ссылки тоже не устроили комитет. На cppcon2014 приняли решение именовать их как forwarding references.
В том же абзаце чуть ранее: если в качестве аргумента передано rvalue, то T выводится как бессылочный тип. Именно этот фокус и обеспечивает правильную работу forward.
_Val является l-value, т.к. имеет имя и нее можно взять адрес в памяти. Поэтому ее нужно далее сделать r-value с помощью std::move. Пожалуй, надо дополнить статью этим моментом. Спасибо!
Кроссплатформенное решение в первую очередь. Вариантов существует масса, и мне интересен опыт использования и, в частности, подводные камни.
Спасибо за статью, но, честно говоря, прочитав заголовок, я ожидал немного другое. Тут скорее "Пример плагиновой архитектуры приложения с использованием WinAPI и C++"