И все-таки, я убежден, что можно достигать этих целей без высказывания оценочных суждений о собеседнике. Ибо, как вы правильно сказали, неадекватов в сети очень много, и они точно так же пользуются этими приемами. И отличить одних от других порой невозможно. Поэтому можно не удивляться ситуации, когда один адекватный человек спровоцировав другого адекватного человека, наученного троллями в интернете, получил в итоге неадекватный ответ.
Множество бед в мире от банального недопонимания.
У меня нет вопросов к содержанию ваших замечаний, а лишь только к форме.
Мой вопрос касался буквально следующего: вряд ли ваше замечание о глубине фантазии собеседника наставит его на путь истинный, а лишь создаст конфликтную ситуацию на ровном месте. Что в общем-то подтверждается дискуссией далее. И вам таки пришлось развернуть свою мысль, так почему бы не сделать это сразу, минуя все эти спорные фразы?
Меня очень печалит тот факт, что люди упускают такие простые вещи из виду.
Всегда удивляло такое отношение к собеседнику.
Если вы знаете больше, напишите что именно неправильно. Зачем начинать обсуждать качества личности человека, делать какие-то вывод на его счет?
Кстати, очень интересно было бы посмотреть на вашу реализацию common_type.
Могу сказать, что в моем случае — это как раз один из тех примеров, когда пришлось делать условную компиляцию. Для GCC 2.х реализация оказалась настолько нетривиальна, что брать ее как основную мне не позволила совесть.
Сама статья про другое, но написана она была по мотивам создания практически такого же набора инструментов, как у вас. Платформа только различается и целевые компиляторы.
Вы не подумайте, мне очень близка ваша идея строгого соответствия «букве» закона. Но я, как практик, при столкновении с подобными трудностями в своей реализации, делая выбор между «поддерживать фичу с оговорками» или «не поддерживать вовсе» выбираю первое :)
Взять, например, задачу определения наличия функции-члена класса с заданной сигнатурой, которая нерешаема в рамках стандартного С++98. Однако, эта возможность была необходима в инструментарии, который я создавал. Без нее было бы слишком неудобно им пользоваться. Поэтому я пошел на этот компромисс.
Также приходилось сталкиваться в ситуацией, когда невозможно написать общий код для всей линейки нужных компиляторов, и таки приходилось делать условную компиляцию. Т.к. баги-фичи одних компиляторов были взаимоисключающими относительно других. Общий знаменатель был невозможен.
Таки шашечки или ехать? :)
В бусте тоже встречаются workaround`ы с нестандартными особенностями, обложенные проверками под конкретные компиляторы.
Ведь если мы работаем в условиях такой плохой поддержки стандарта, то сетовать на несоответствие стандарту некоторым образом лукавство, особенно, если код обеспечивает требуемое поведение.
Поэтому тут надо выбирать что важнее.
PS. Да, и я в курсе этих особенностей, т.к. сам некоторым образом решал подобную вашей задачу (пример: habr.com/post/277727), но для линейки старых GCC и Intel под Linux и BSD. Попробуйте вашу реализацию на GCC 2.x, возможно найдется множество интересных локальных задачек по нахождению обходных путей.
Борландовские версии к сожалению не работают, сегодня проверил :) Я долго пытался состряпать workaround, но похоже пациент совсем плохо умеет SFINAE — ничего не вышло.
Если автору важно поддерживать Borland C++, то вполне понятно почему он не применил это решение.
… проблема возникает с неполным типом T[] (массив без указания длины). Дело в том что данный тип не определяется некоторыми компиляторами (C++ Builder) при специализации шаблона, и универсальное решение здесь я пока что не нашел.
Нет, тут дело не в этом.
Проблема производительности в том, что если у нас есть переменная val целого типа, то компилятор в выражении
bool f = val;
может сгенерировать (внимание, ниже псевдокод для демонстрации поведения) нечто вроде такого:
bool f = val == 0 ? false : true;
Это предупреждение было призвано обозначить возможность потенциальной генерации такого кода в этом месте, на случай, если программист об этом не подумал.
Чтобы не быть голословным, приведу практический пример с дизассемблером: godbolt.org/g/FQG8Jk
Как видим, в безобидном присваивании появилось условие. Данный warning об этом.
При этом, если посмотреть выданную выше ссылку, то можно увидеть в ответе на report такие слова
My understanding of the history of C4800 was that it was introduced a very long time ago (~1990?) to address concerns for developers migrating from C.
Это коссвенно указывает на тоже самое, о чем я говорил выше. Т.к. в С не было типа bool, то программисты на нем, при переходе на С++ могли быть неприятно удивлены, что одинаковый внешне код в С++ приводит к генерации «лишних» инструкций, чего в С не наблюдалось. Поэтому на каких-то этапах это предупреждение действительно было полезно.
Функции с cv-seq (мерзкие типы) — это больная тема. Несколько лет назад в своей статье как раз затрагивал проблемы, связанные с интерпретацией таких типов компиляторами. :)
В книге «Шаблоны С++. Справочник разработчика», есть целый раздел, посвященный оптимизации таких выражений, для исключения создания «лишних» временных объектов. Описанный подход немного потерял актуальность с выходом новых стандартов, но для понимания сути очень полезно почитать, я думаю. Чтобы не слепо верить и не никогда использовать, а разобраться и делать осознанный выбор.
Присоединяюсь.
Года полтора назад писал к Вам в редакцию электронное письмо по этой теме, но никакого ответа, даже формального, к сожалению не дождался.
В числе прочих, очень бы хотелось снова увидеть на прилавках книги Р. Стивенса по сетевому программированию.
В MS имеют другую точку зрения на этот вопрос: их реализация просто игнорирует const в тех контекстах, где он недопустим.
Это следует и из ответа, который мне дали в багтрекере, и в принципе согласуется с практическими экспериментами ув. thedsi666 c VS.
Я о другом. Смысл искажается. Хотя конечно дело ваше.
Но хотя бы вставить пояснение того, что на самом деле означает слово "персональная" в этом контексте. А то ведь смысл этого слова в русском языке совсем не сочетается с тем, что имелось в виду в английском варианте.
gustedt.wordpress.com/2011/03/14/flexible-array-member
Множество бед в мире от банального недопонимания.
Мой вопрос касался буквально следующего: вряд ли ваше замечание о глубине фантазии собеседника наставит его на путь истинный, а лишь создаст конфликтную ситуацию на ровном месте. Что в общем-то подтверждается дискуссией далее. И вам таки пришлось развернуть свою мысль, так почему бы не сделать это сразу, минуя все эти спорные фразы?
Меня очень печалит тот факт, что люди упускают такие простые вещи из виду.
Если вы знаете больше, напишите что именно неправильно. Зачем начинать обсуждать качества личности человека, делать какие-то вывод на его счет?
Могу сказать, что в моем случае — это как раз один из тех примеров, когда пришлось делать условную компиляцию. Для GCC 2.х реализация оказалась настолько нетривиальна, что брать ее как основную мне не позволила совесть.
Вы не подумайте, мне очень близка ваша идея строгого соответствия «букве» закона. Но я, как практик, при столкновении с подобными трудностями в своей реализации, делая выбор между «поддерживать фичу с оговорками» или «не поддерживать вовсе» выбираю первое :)
Взять, например, задачу определения наличия функции-члена класса с заданной сигнатурой, которая нерешаема в рамках стандартного С++98. Однако, эта возможность была необходима в инструментарии, который я создавал. Без нее было бы слишком неудобно им пользоваться. Поэтому я пошел на этот компромисс.
Также приходилось сталкиваться в ситуацией, когда невозможно написать общий код для всей линейки нужных компиляторов, и таки приходилось делать условную компиляцию. Т.к. баги-фичи одних компиляторов были взаимоисключающими относительно других. Общий знаменатель был невозможен.
В бусте тоже встречаются workaround`ы с нестандартными особенностями, обложенные проверками под конкретные компиляторы.
Ведь если мы работаем в условиях такой плохой поддержки стандарта, то сетовать на несоответствие стандарту некоторым образом лукавство, особенно, если код обеспечивает требуемое поведение.
Поэтому тут надо выбирать что важнее.
PS. Да, и я в курсе этих особенностей, т.к. сам некоторым образом решал подобную вашей задачу (пример: habr.com/post/277727), но для линейки старых GCC и Intel под Linux и BSD. Попробуйте вашу реализацию на GCC 2.x, возможно найдется множество интересных локальных задачек по нахождению обходных путей.
Если автору важно поддерживать Borland C++, то вполне понятно почему он не применил это решение.
Проверил код ниже на C++ Builder 6 — работает.
zeroc.com/products/ice
Проблема производительности в том, что если у нас есть переменная val целого типа, то компилятор в выражении
может сгенерировать (внимание, ниже псевдокод для демонстрации поведения) нечто вроде такого:
Это предупреждение было призвано обозначить возможность потенциальной генерации такого кода в этом месте, на случай, если программист об этом не подумал.
Чтобы не быть голословным, приведу практический пример с дизассемблером:
godbolt.org/g/FQG8Jk
Как видим, в безобидном присваивании появилось условие. Данный warning об этом.
При этом, если посмотреть выданную выше ссылку, то можно увидеть в ответе на report такие слова
Это коссвенно указывает на тоже самое, о чем я говорил выше. Т.к. в С не было типа bool, то программисты на нем, при переходе на С++ могли быть неприятно удивлены, что одинаковый внешне код в С++ приводит к генерации «лишних» инструкций, чего в С не наблюдалось. Поэтому на каких-то этапах это предупреждение действительно было полезно.
А почему из перевода книги убрали 4 главы про System V?
Года полтора назад писал к Вам в редакцию электронное письмо по этой теме, но никакого ответа, даже формального, к сожалению не дождался.
В числе прочих, очень бы хотелось снова увидеть на прилавках книги Р. Стивенса по сетевому программированию.
Это следует и из ответа, который мне дали в багтрекере, и в принципе согласуется с практическими экспериментами ув. thedsi666 c VS.
Но хотя бы вставить пояснение того, что на самом деле означает слово "персональная" в этом контексте. А то ведь смысл этого слова в русском языке совсем не сочетается с тем, что имелось в виду в английском варианте.