В сообщении указывалось "на другие, более качественные источники по данной тематике", Вы же привели пример статьи по матанализу. К сожалению, Вы или пропустили, или проигнорировали этот существенный момент. Смысл сообщения заключался в том, чтобы читателям, которым не удобен формат данной статьи, была доступна альтернативная статья, написанная более понятным простым языком. Хочется, чтобы данный спор принес все-таки определенную пользу.
Очень жаль, что за свои 40 лет Вы не научились конструктивно вести диалог и критиковать, но, уверяю Вас, еще не поздно начать эволюционировать. Откровенно говоря, не хочется даже думать, каким образом Вы проводите code-review, надеюсь не таким же, как Вы ведете данную переписку, а все-таки соблюдаете какие-то общепринятые нормы и этикет, рекомендую обратиться к словарю, чтобы понять значение данного слова. Также, к сожалению, по опыту знаю, что человек, утверждающий, что все знает, как правило, мягко говоря, не совсем компетентен. Считаю неправильным переходить на личности, но раз уж Вы себе позволили...
Уважаемый комментатор, могу только посоветовать Вам обратиться к моему ответу Tyiler. Следуя Вашей логике вся деловая переписка и / или техническая литература является плодом усилий llm. Возможно, Вам необходимо несколько повысить свой уровень грамотности, чтобы Вам не мерещились в каждом сообщении llm. Очень жаль, что обсуждение статьи превратилось в балаган, или, говоря Вашим языком - срач.
Всегда ли для Вас грамотная речь ассоциируется с "ллм"? Статья отмечена как обзор, и, с моей точки зрения она в полном объеме выполняет свое предназначение. И, надеюсь, позволит значительно уменьшить количество ошибок, допускаемых как начинающими, так и опытными разработчиками. Если у Вас есть ссылка на другие, более качественные источники по данной тематике, и Вы ими поделитесь, буду очень рад.
Отличная идея, также иногда нужно прогонять и комментарии через нейросеть, чтобы в одном предложении не встречалось и Вы, и ты. Безграмотная речь при написании комментариев несколько снижает доверие как к комментатору, так и к комментарию. Вам статья была полезной?
Пример кода действительно вводит в заблуждение, уточнение с НО будет справедливо только при условии, когда в приведенном коде = default будет заменен на = delete или же класс будет содержать только перемещаемое поле. Общий подход следующий - производится попытка использовать конструктор перемещения, если он noexcept, иначе производится попытка использовать конструктор копирования, если же и это невозможно, то остается только вызов небезопасного перемещающего конструктора. Также рекомендую комментатору придерживаться этических норм, это сделает обсуждение более продуктивным.
Спасибо за комментарий, за Ваше оценочное суждение, за советы, которые у Вас не спрашивали, за Ваши утверждения, но не за тактичность и не за вопросы, которых у Вас нет. У меня же к Вам единственный вопрос - статья была полезной?
Спасибо за комментарий. Также хотелось бы получить более конструктивную критику именно в контексте раскрываемой в статье темы, полезность, вторичность, плюсы, минусы, какие существенные моменты не учтены или искажены, чтобы на основании данных замечаний сделать статью более информативной и полезной для тех людей, которым данная тема интересна. Возможно, стоит дополнительно создать статью об этических нормах при написании как статей, так и комментариев.
Согласен со всеми четырьмя пунктами: 1. Структура и переходы можно улучшить. 2. Memory ordering ≠ барьер — это критическое различие, спасибо за примеры ARM/AMD. 3. seq_cst не инструмент отладки — это фундаментальная гарантия. 4. "Ограничивает" — правильный глагол, не "контролирует".
Спасибо за замечание. Вы правы, что существует 36 возможных комбинаций. Однако в статье я сознательно сосредоточился на трёх наиболее практичных сценариях для введения в тему. Валидных и полезных комбинаций значительно меньше, так как многие нарушают семантику операций (например, acquire на store). Для полного справочника действительно нужен отдельный материал. Согласен, что вопрос о привязке к типам — интересный дизайн-вопрос, но текущий API предоставляет гибкость, которая часто необходима.
Спасибо за конструктивный комментарий. Взял на заметку.
В сообщении указывалось "на другие, более качественные источники по данной тематике", Вы же привели пример статьи по матанализу. К сожалению, Вы или пропустили, или проигнорировали этот существенный момент. Смысл сообщения заключался в том, чтобы читателям, которым не удобен формат данной статьи, была доступна альтернативная статья, написанная более понятным простым языком. Хочется, чтобы данный спор принес все-таки определенную пользу.
Очень жаль, что за свои 40 лет Вы не научились конструктивно вести диалог и критиковать, но, уверяю Вас, еще не поздно начать эволюционировать. Откровенно говоря, не хочется даже думать, каким образом Вы проводите code-review, надеюсь не таким же, как Вы ведете данную переписку, а все-таки соблюдаете какие-то общепринятые нормы и этикет, рекомендую обратиться к словарю, чтобы понять значение данного слова. Также, к сожалению, по опыту знаю, что человек, утверждающий, что все знает, как правило, мягко говоря, не совсем компетентен. Считаю неправильным переходить на личности, но раз уж Вы себе позволили...
Уважаемый комментатор, могу только посоветовать Вам обратиться к моему ответу Tyiler. Следуя Вашей логике вся деловая переписка и / или техническая литература является плодом усилий llm. Возможно, Вам необходимо несколько повысить свой уровень грамотности, чтобы Вам не мерещились в каждом сообщении llm. Очень жаль, что обсуждение статьи превратилось в балаган, или, говоря Вашим языком - срач.
Всегда ли для Вас грамотная речь ассоциируется с "ллм"? Статья отмечена как обзор, и, с моей точки зрения она в полном объеме выполняет свое предназначение. И, надеюсь, позволит значительно уменьшить количество ошибок, допускаемых как начинающими, так и опытными разработчиками. Если у Вас есть ссылка на другие, более качественные источники по данной тематике, и Вы ими поделитесь, буду очень рад.
Отличная идея, также иногда нужно прогонять и комментарии через нейросеть, чтобы в одном предложении не встречалось и Вы, и ты. Безграмотная речь при написании комментариев несколько снижает доверие как к комментатору, так и к комментарию. Вам статья была полезной?
Пример кода действительно вводит в заблуждение, уточнение с НО будет справедливо только при условии, когда в приведенном коде
= default будет заменен на = delete или же класс будет содержать только перемещаемое поле. Общий подход следующий -производится попытка использовать конструктор перемещения, если онnoexcept, иначе производится попытка использовать конструктор копирования, если же и это невозможно, то остается только вызов небезопасного перемещающего конструктора. Также рекомендую комментатору придерживаться этических норм, это сделает обсуждение более продуктивным.Согласен, как и в случае, когда в классе есть поле, которое является только перемещаемым.
Спасибо за комментарий, исправил.
Спасибо за комментарий, за Ваше оценочное суждение, за советы, которые у Вас не спрашивали, за Ваши утверждения, но не за тактичность и не за вопросы, которых у Вас нет. У меня же к Вам единственный вопрос - статья была полезной?
Спасибо за комментарий. Также хотелось бы получить более конструктивную критику именно в контексте раскрываемой в статье темы, полезность, вторичность, плюсы, минусы, какие существенные моменты не учтены или искажены, чтобы на основании данных замечаний сделать статью более информативной и полезной для тех людей, которым данная тема интересна. Возможно, стоит дополнительно создать статью об этических нормах при написании как статей, так и комментариев.
Согласен со всеми четырьмя пунктами: 1. Структура и переходы можно улучшить. 2. Memory ordering ≠ барьер — это критическое различие, спасибо за примеры ARM/AMD. 3. seq_cst не инструмент отладки — это фундаментальная гарантия. 4. "Ограничивает" — правильный глагол, не "контролирует".
Спасибо за замечание. Вы правы, что существует 36 возможных комбинаций. Однако в статье я сознательно сосредоточился на трёх наиболее практичных сценариях для введения в тему. Валидных и полезных комбинаций значительно меньше, так как многие нарушают семантику операций (например, acquire на store). Для полного справочника действительно нужен отдельный материал. Согласен, что вопрос о привязке к типам — интересный дизайн-вопрос, но текущий API предоставляет гибкость, которая часто необходима.