Нет, тут дело не в этом.
Проблема производительности в том, что если у нас есть переменная 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.
Я о другом. Смысл искажается. Хотя конечно дело ваше.
Но хотя бы вставить пояснение того, что на самом деле означает слово "персональная" в этом контексте. А то ведь смысл этого слова в русском языке совсем не сочетается с тем, что имелось в виду в английском варианте.
Because different programming languages have different behaviors when handling exceptions, the exception handling ABI provides a mechanism for supplying personalities. An exception handling personality is defined by way of a personality function (e.g. __gxx_personality_v0 in C++), which receives the context of the exception, an exception structure containing the exception object type and value, and a reference to the exception table for the current function. The personality function for the current compile unit is specified in a common exception frame.
Исходя из этой цитаты, на мой взгляд, personality function не может переводиться как "персональная функция", а скорее как "функция, отражающая особенности [конкретного механизма исключений]". Но данный перевод теряет лаконичность оригинальной фразы. Поэтому возможно лучше оставить это словосочетание без перевода (например со сноской на детальное объяснение того, что это значит), так же, как вы поступили с landing pads.
Я цитировал черновик С++14, но видимо немного более старый, чем сейчас есть на сайте.
Но, видимо, изменения откатили обратно (и это прошло мимо меня). Вот, например, патч для gcc по поводу этого.
Признаю свою вину, что не сверился с последним черновиком.
Вы были правы.
Простите, но мое чувство справедливости не дает проигнорировать этот момент.
Тут речь, вообще-то, о плюсах, в которых нет VLA.
Дело в том, что уже есть, правда называются они не VLA (см. цитаты). Тот же параграф, что вы цитировали выше, в новом стандарте претерпел изменения:
In a declaration T D where D has the form
D1 [ expressionopt] attribute-specifier-seqopt
и ниже:
If the expression, after converting to std::size_t, is a core constant expression whose value is N, the
type of the identifier of D is “derived-declarator-type-list array of N T”. Otherwise, the type of the identifier of D is “derived-declarator-type-list array of runtime bound of T” and
the value of the expression designates the number of elements N in the array.
Короче говоря неконстанту в размере массива писать теперь официально можно и это не ошибка.
Я к чему говорю: мой ответ касался вашего замечания, что переменная плохо ищется потому, что у нее короткое имя — логично было предположить, что вы не знаете про grep, и/или регулярки.
Но контекст-то нужно учитывать. Я сперва озвучил цифры не просто так. В контексте, который я описывал, именно короткое имя является причиной «плохого поиска» и именно поэтому, чтобы смочь составить регулярку, нужно знать достаточно о вариантах применения, дабы отразить это в выражении. Если варианты неизвестны, то поиск сильно затрудняется.
Вы должно быть забыли поставить запятую, т.к. из того, что имя короткое совсем не следует, что оно плохо ищется :) Например вот вам команда с регуляркой «навскидку», которую я бы на вашем месте использовал «grep -rnIE "\bL\b[^\"]*"» — скипает бинарные файлы и «широкие» строки, выводит только строки с их номерами в файле, где используется одинокая большая Эл.
Допустим мы представим, что я не знаю про регулярки (только допустим). Допустим, что я не умею пользоваться grep (только допустим). Теперь допустим я решил попробовать поискать таким образом у себя и получил лог в полтора миллиона строк (и это я еще обрезал поиск только по h, c и cpp). «Плохо ищется» означало, я не получу обозримый лог поиска. Я получу портянку на пару недель изучения :) Во-вторых, если к твоей регулярке добавить еще поиск вхождения по «define», то становится гораздо проще. Но это ведь нужно знать, что там надо писать define, компилятор об это не говорит. Хорошо, допустим я знаю про это (я знал, выше писал, сработал паттерн), но я все равно не нашел подобным образом ничерта. Потому что искал по коду комплекса, где у меня развалилась сборка, а макрос этот злосчастный был во внешних зависимостях.
ну выдаст компилер ошибку, переименовать переменную не так трудно ведь?
При всем уважении, но «должны» это не про реальные проекты. Бывает всякое, я как-то боролся с проблемой, потому что некто определил макрос L. Было несколько переменных внутри структур с таким же названием, кроме того, — это лексема для указания «широких» строк. Размер проекта примерно 700мб исходного кода. Причем раньше это работало (много лет), но стало разваливаться при обновлении версии компилятора. По-другому включилась последовательность h-ников и все, приехали. Найти это при таких объемах было чрезвычайно сложно, во-первых потому, что имя короткое и оно плохо ищется. Во-вторых ошибка вовсе не указывала на проблемное место, а всплывала за много «километров» от него, с совершенно невразумительной диагностикой. Если бы у меня на тот момент уже не выработался паттерн: «видишь непонятную хрень — виноваты макросы», я бы потратил еще больше времени.
Так что, при всем уважении, ваши рассуждении просто говорят о том, что вы никогда не имели дел с legacy такого объема.
Это же не сегфолт в рантайме, исправить легко.
Сегфолты, к слову, обычно проще исправить, чем такое.
zeroc.com/products/ice
Проблема производительности в том, что если у нас есть переменная val целого типа, то компилятор в выражении
может сгенерировать (внимание, ниже псевдокод для демонстрации поведения) нечто вроде такого:
Это предупреждение было призвано обозначить возможность потенциальной генерации такого кода в этом месте, на случай, если программист об этом не подумал.
Чтобы не быть голословным, приведу практический пример с дизассемблером:
godbolt.org/g/FQG8Jk
Как видим, в безобидном присваивании появилось условие. Данный warning об этом.
При этом, если посмотреть выданную выше ссылку, то можно увидеть в ответе на report такие слова
Это коссвенно указывает на тоже самое, о чем я говорил выше. Т.к. в С не было типа bool, то программисты на нем, при переходе на С++ могли быть неприятно удивлены, что одинаковый внешне код в С++ приводит к генерации «лишних» инструкций, чего в С не наблюдалось. Поэтому на каких-то этапах это предупреждение действительно было полезно.
А почему из перевода книги убрали 4 главы про System V?
Года полтора назад писал к Вам в редакцию электронное письмо по этой теме, но никакого ответа, даже формального, к сожалению не дождался.
В числе прочих, очень бы хотелось снова увидеть на прилавках книги Р. Стивенса по сетевому программированию.
Это следует и из ответа, который мне дали в багтрекере, и в принципе согласуется с практическими экспериментами ув. thedsi666 c VS.
Но хотя бы вставить пояснение того, что на самом деле означает слово "персональная" в этом контексте. А то ведь смысл этого слова в русском языке совсем не сочетается с тем, что имелось в виду в английском варианте.
Приведу цитату из LLVM manual:
Исходя из этой цитаты, на мой взгляд, personality function не может переводиться как "персональная функция", а скорее как "функция, отражающая особенности [конкретного механизма исключений]". Но данный перевод теряет лаконичность оригинальной фразы. Поэтому возможно лучше оставить это словосочетание без перевода (например со сноской на детальное объяснение того, что это значит), так же, как вы поступили с landing pads.
У нас много legacy, при чем это касается не только софта, но и всяких бюрократических моментов.
Может быть стоит добавить эту информацию в багрепорт?
К сожалению, в моем случае перспектива перехода на С++11 на работе кажется фантастической :)
Но, видимо, изменения откатили обратно (и это прошло мимо меня). Вот, например, патч для gcc по поводу этого.
Признаю свою вину, что не сверился с последним черновиком.
Вы были правы.
Дело в том, что уже есть, правда называются они не VLA (см. цитаты). Тот же параграф, что вы цитировали выше, в новом стандарте претерпел изменения:
и ниже:
Короче говоря неконстанту в размере массива писать теперь официально можно и это не ошибка.
Но контекст-то нужно учитывать. Я сперва озвучил цифры не просто так. В контексте, который я описывал, именно короткое имя является причиной «плохого поиска» и именно поэтому, чтобы смочь составить регулярку, нужно знать достаточно о вариантах применения, дабы отразить это в выражении. Если варианты неизвестны, то поиск сильно затрудняется.
Допустим мы представим, что я не знаю про регулярки (только допустим). Допустим, что я не умею пользоваться grep (только допустим). Теперь допустим я решил попробовать поискать таким образом у себя и получил лог в полтора миллиона строк (и это я еще обрезал поиск только по h, c и cpp). «Плохо ищется» означало, я не получу обозримый лог поиска. Я получу портянку на пару недель изучения :) Во-вторых, если к твоей регулярке добавить еще поиск вхождения по «define», то становится гораздо проще. Но это ведь нужно знать, что там надо писать define, компилятор об это не говорит. Хорошо, допустим я знаю про это (я знал, выше писал, сработал паттерн), но я все равно не нашел подобным образом ничерта. Потому что искал по коду комплекса, где у меня развалилась сборка, а макрос этот злосчастный был во внешних зависимостях.
При всем уважении, но «должны» это не про реальные проекты. Бывает всякое, я как-то боролся с проблемой, потому что некто определил макрос L. Было несколько переменных внутри структур с таким же названием, кроме того, — это лексема для указания «широких» строк. Размер проекта примерно 700мб исходного кода. Причем раньше это работало (много лет), но стало разваливаться при обновлении версии компилятора. По-другому включилась последовательность h-ников и все, приехали. Найти это при таких объемах было чрезвычайно сложно, во-первых потому, что имя короткое и оно плохо ищется. Во-вторых ошибка вовсе не указывала на проблемное место, а всплывала за много «километров» от него, с совершенно невразумительной диагностикой. Если бы у меня на тот момент уже не выработался паттерн: «видишь непонятную хрень — виноваты макросы», я бы потратил еще больше времени.
Так что, при всем уважении, ваши рассуждении просто говорят о том, что вы никогда не имели дел с legacy такого объема.
Сегфолты, к слову, обычно проще исправить, чем такое.