Хотелось бы обратиться к спецам по С++ и по компилятору VS2013 в частности:
Вот такой простой метод класса в конфигурации release выдает: warning C4702: unreachable code в release конфигурации. В debug конфигурации все Ок, Cрабатывают точки останова и метод гарантированно вызывается.
Предупреждение выдается пачкой, порядка 20-ти одинаковых записей, по ходу, на стадии линковки для каждого объектника где используется. Не пойму как интерпретировать это предупреждение? Если это нормально, то как можно подавить?
Здравствуйте, Videoman, Вы писали:
V>Предупреждение выдается пачкой, порядка 20-ти одинаковых записей, по ходу, на стадии линковки для каждого объектника где используется. Не пойму как интерпретировать это предупреждение? Если это нормально, то как можно подавить?
Здравствуйте, uzhas, Вы писали:
U>ворнинг не от линкера, а от компилятора
да, от него
U>давайте мин. пример и точную ошибку, чтобы знать на какую строчку в коде и как именно ругается
Не могу, так как проект очень большой. Могу класс скинуть весь. Класс обертка для буфера аналогично ASIO библиотеке:
Здравствуйте, Videoman, Вы писали:
V>Хотелось бы обратиться к спецам по С++ и по компилятору VS2013 в частности:
Попробуйте обновить компилятор, в старом было такое ошибочное предупреждение.
МС теперь снова выпустила компилятор плюс библиотеки в виде отдельной инсталляции.
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Попробуйте обновить компилятор, в старом было такое ошибочное предупреждение. AWW>МС теперь снова выпустила компилятор плюс библиотеки в виде отдельной инсталляции.
AWW>Скачать можно тут — http://landinghub.visualstudio.com/visual-cpp-build-tools
AWW>Новые компиляторы от MS можно ставить в старую студию.
Спасибо за совет, но есть нюансы:
1. Хотелось бы точно понять, что это баг, а не реальная проблема в коде
2. Я не могу так просто менять toolset, так как код использую не я один и нужно иметь веские причины в включать административные процедуры для всех разработчиков, чего не хотелось бы делать пока.
Здравствуйте, Videoman, Вы писали:
V>Спасибо за совет, но есть нюансы: V>1. Хотелось бы точно понять, что это баг, а не реальная проблема в коде V>2. Я не могу так просто менять toolset, так как код использую не я один и нужно иметь веские причины в включать административные процедуры для всех разработчиков, чего не хотелось бы делать пока.
Да это такой баг, вы можете его игнорировать. Его можно убрать если переписать декларацию класса и убрать (по-моему inline). То есть можете по-экперементировать — Ибо я просто не помню всех деталей.
По второму пункту — если проект большой то сильно не рекомендую вам менять на переправе 2013 тулсет, на 140-ой там вылезет миллион предупреждений. Но если все варнинги исправить то переезд легкий.
Здравствуйте, VTT, Вы писали:
VTT>Почему методы в cpp файле помечены как inline? Вообще зачем тут cpp файл?
Это я прогнал на автомате, все в .h файле конечно. Привычка от классов с реализацией в .cpp.
VTT>Зачем сделан перемещающий конструктор, который копирует?
Для отладки кода, на всякий случай. Такой подход ни на что не влияет.
VTT>Еще const_cast бесполезен, так как m_data и так имеет тип const void*
Принято, исправил. Была копи-паста из другого класса.
VTT>Метод Size выглядит безвредно, однако стоит проверить еще все места его использования.
Вот тут и весь вопрос??? Для кода есть куча юнит-тестов и по ним все работает как надо и в release-e.
VTT>А статический анализатор студии на это место не ругается?
Нет
Здравствуйте, uzhas, Вы писали:
U>вспомнил. у нас такие ворнинги выплыли на VS2015 и тоже в релизе. в коде все окейно. глюк студии U>багу на ms connect не нашел
Похоже на глюк, причем, все-таки, когда линкер делает whole-optimization, потому-что на стадии компиляции все Ок, а вот перед линковкой, сразу пачка предупреждений подряд.
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Да это такой баг, вы можете его игнорировать. Его можно убрать если переписать декларацию класса и убрать (по-моему inline). То есть можете по-экперементировать — Ибо я просто не помню всех деталей.
AWW>По второму пункту — если проект большой то сильно не рекомендую вам менять на переправе 2013 тулсет, на 140-ой там вылезет миллион предупреждений. Но если все варнинги исправить то переезд легкий.
Пришлось подавить предупреждение, но вообще печально, что он перекочевал и в VS2015, а может уже и дальше.
VTT>>Метод Size выглядит безвредно, однако стоит проверить еще все места его использования. V>Вот тут и весь вопрос??? Для кода есть куча юнит-тестов и по ним все работает как надо и в release-e.
Можно попробовать в лоб закомментировать использование этого метода и выявить проблемное место в вызывающем коде.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>Можно попробовать в лоб закомментировать использование этого метода и выявить проблемное место в вызывающем коде.
Не уверен что правильно вас понял. Если закоментировать использование этого метода, то выдается 100500 мест с ошибками, где это метод вызывается. Более того, метод как бы работает правильно, т.к. по логике внешним классам получить размер не от куда, кроме как через этот метод, и написанные юнит-тесты проходятся.
Здравствуйте, Videoman, Вы писали:
V>Похоже на глюк, причем, все-таки, когда линкер делает whole-optimization, потому-что на стадии компиляции все Ок, а вот перед линковкой, сразу пачка предупреждений подряд.
когда линкер делает whole-optimization, то вызывает компилятор, чтобы что-нибудь докомпилировать для своих нужд (можно увидеть в процессах cl.exe)
Здравствуйте, uzhas, Вы писали:
U>когда линкер делает whole-optimization, то вызывает компилятор, чтобы что-нибудь докомпилировать для своих нужд (можно увидеть в процессах cl.exe)
Да я не спорю про "кишки" (реализацию). Я просто уточнил, что по времени вывода предупреждений, что похоже на время линкера или перед ним. Это просто чтобы уточнить стадию сборки, без деталей.
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, VTT, Вы писали:
VTT>>Можно попробовать в лоб закомментировать использование этого метода и выявить проблемное место в вызывающем коде.
V>Не уверен что правильно вас понял. Если закоментировать использование этого метода, то выдается 100500 мест с ошибками, где это метод вызывается. Более того, метод как бы работает правильно, т.к. по логике внешним классам получить размер не от куда, кроме как через этот метод, и написанные юнит-тесты проходятся.
Мне кажется, что это предупреждение выдается из-за проблемы в вызывающем коде.
Например, где-то вылезает неопределенное поведение, этот вызов выкидывается, но дигностика указывает в сам метод, так как точнее не получилось.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
на первом проходе всей этой компиляции isDebug() от чего-то не разрешается, а Size() подставляется, а на втором, когда линкер запускает cl докомпилировать что там получилось isDebug() уже разрешается, но из-за подстановки предупреждают не там.
Вообще минимальный пример рулит. Если сделаешь его, например методом комминтирования половины кода в TU, в которой выдаётся предупреждение, то скорее всего и сам поймёшь, что происходит...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском