Здравствуйте, Videoman, Вы писали:
V>Наступил на интересные грабли с MSVC 2017, код: V>Код собирается, но работает не правильно — (возвращает не 4-ку).
V> Если убрать constexpr то результат для меня предсказуемый (хоть возможно это и UB).
По правилам С++ результат определён и равен числу 4 вне зависимости от наличия или отсутствия constexpr.
Здравствуйте, Videoman, Вы писали:
V>Да, я в курсе про несколько студий. Сам на ней начиная с 6-й. Проекты волнами переписывались и плавно переходили, начиная с 2008-й. Просто последнее время думаешь, а не появится ли больше глюков чем решится старых проблем. Вот и осторожно спрашиваю, действительно ли стоит переходить на 2022 . Если там что то еще полезное с точки зрения С++, кроме пофикшенного и обновленного компилятора ?
В VS2022 Вы можете благополучно использовать компилятор от VS2017 (Надо только не забыть при инсталляции установить нужные toolset и не обновлять проекты студии). Сам так сейчас так работаю. Проекты компилируются компилятором совместимым с VS2017 и с ключом std++17. Потихоньку переедем на последний компилятор и с++20.
VS2017 на наших проектах (не огромных, но и не маленьких) регулярно (типа раз в неделю) грохалась... VS2022 64 битная. Может из-за этого (а может нет) у меня сейчас падений студии не наблюдается.
#include <string_view>
using namespace std::literals;
static constexpr auto str = "ABCD"sv;
template<typename it_t>
constexpr it_t func(it_t it) noexcept
{
return it + 1;
}
int main()
{
int result = 0;
constexpr auto it_beg = str.begin();
constexpr auto it1 = func(it_beg);
constexpr auto it2 = func(it1);
constexpr auto it3 = func(it2);
constexpr auto it4 = func(it3);
result = result + (it1 - it_beg);
result = result + (it2 - it1);
result = result + (it3 - it2);
result = result + (it4 - it3);
return result;
}
Код собирается, но работает не правильно — (возвращает не 4-ку). Глянув на ассемблер, можно понять почему: компилятор в памяти генерирует 5-ть экземпляров str и естественно их итераторы несовместимы друг с другом и результат их вычитания не определен.
Вопрос к знатокам: что происходит, в чем я не прав, где тупанул? Если убрать constexpr то результат для меня предсказуемый (хоть возможно это и UB).
Здравствуйте, Videoman, Вы писали:
V>Код собирается, но работает не правильно — (возвращает не 4-ку). Глянув на ассемблер, можно понять почему: компилятор в памяти генерирует 5-ть экземпляров str и естественно их итераторы несовместимы друг с другом и результат их вычитания не определен. V>Вопрос к знатокам: что происходит, в чем я не прав, где тупанул? Если убрать constexpr то результат для меня предсказуемый (хоть возможно это и UB).
Включи оптимизацию Вообще от подобных компиляторов больше вреда чем пользы.
Здравствуйте, kov_serg, Вы писали:
_>Включи оптимизацию Вообще от подобных компиляторов больше вреда чем пользы.
Включить можно, но проблемы это не решает. Код работать будет в зависимости от фазы луны. А вообще: что я нарушил-то? Почему код c constexpr не эквивалентен коду без него? Что вообще происходит-то, объясни?
Если string_view заменить на const char[] — то всё работает
Здравствуйте, watchmaker, Вы писали:
W>Конечно, это баг в компиляторе. W>Например, на него тут тоже жалуются: https://developercommunity.visualstudio.com/t/static-inline-constexpr-char-bad-code-gen/1573213#T-N1580875
Спасибо большое за ответ! Пол дня потратил что бы выяснить в чем же тут засада, а оказался опять баг . Что-то везет мне на баги компилятора последнее время.
W>По правилам С++ результат определён и равен числу 4 вне зависимости от наличия или отсутствия constexpr.
Фуф, равновесие вселенной опять восстановлено.
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, watchmaker, Вы писали:
W>>Конечно, это баг в компиляторе. W>>Например, на него тут тоже жалуются: https://developercommunity.visualstudio.com/t/static-inline-constexpr-char-bad-code-gen/1573213#T-N1580875 V>Спасибо большое за ответ! Пол дня потратил что бы выяснить в чем же тут засада, а оказался опять баг . Что-то везет мне на баги компилятора последнее время.
Может есть возможность обновить компилятор ?
Скажем, в 2022 очень много багов починили по сравнению с 2017.
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, _NN_, Вы писали:
_NN>>Может есть возможность обновить компилятор ? _NN>>Скажем, в 2022 очень много багов починили по сравнению с 2017.
V>Надо будет думать. А как там со всем остальным? Для кроссплатформенной разработки появилось что-нибудь новое?
Что такое остальное ?
Расширения студии уже подтянулись.
Здравствуйте, Videoman, Вы писали:
_NN>>Может есть возможность обновить компилятор ? _NN>>Скажем, в 2022 очень много багов починили по сравнению с 2017.
V>Надо будет думать. А как там со всем остальным? Для кроссплатформенной разработки появилось что-нибудь новое?
несколько студий можно ставить параллельно, они не мешаю друг другу. На всякий случай не сносить сразу 2017, вдруг что не срастется с проектом (например, в одном проекте с гитхаба пришлось помучаться, чтобы скомпилился в 2019, какие-то там проблемы с версиями СДК и подобная муть)
Здравствуйте, wl., Вы писали:
wl.>несколько студий можно ставить параллельно, они не мешаю друг другу. На всякий случай не сносить сразу 2017, вдруг что не срастется с проектом (например, в одном проекте с гитхаба пришлось помучаться, чтобы скомпилился в 2019, какие-то там проблемы с версиями СДК и подобная муть)
Да, я в курсе про несколько студий. Сам на ней начиная с 6-й. Проекты волнами переписывались и плавно переходили, начиная с 2008-й. Просто последнее время думаешь, а не появится ли больше глюков чем решится старых проблем. Вот и осторожно спрашиваю, действительно ли стоит переходить на 2022 . Если там что то еще полезное с точки зрения С++, кроме пофикшенного и обновленного компилятора ?
Здравствуйте, Serg27, Вы писали:
S>Здравствуйте, Videoman, Вы писали:
S>В VS2022 Вы можете благополучно использовать компилятор от VS2017 (Надо только не забыть при инсталляции установить нужные toolset и не обновлять проекты студии). Сам так сейчас так работаю. Проекты компилируются компилятором совместимым с VS2017 и с ключом std++17. Потихоньку переедем на последний компилятор и с++20.
А компилятор будет использоваться новый исправленный, в режиме С++17, или из старого toolset-а ? Если новый, то нужно будет видимо ставить вопрос о переходе, т.к. сейчас у меня, например при компиляции webrtclib от Google, релизный код собранный компилятором от 2017-ой студи просто не работает: падает. Помогает только раздельная сборка CLang-ом.
S>VS2017 на наших проектах (не огромных, но и не маленьких) регулярно (типа раз в неделю) грохалась... VS2022 64 битная. Может из-за этого (а может нет) у меня сейчас падений студии не наблюдается.
Да она достаточно глючная, вообще. У меня часто при смене конфигурации 32/64/Debug/Release перестает работать сборка. Иногда только удаление папки .vs помогает.
Здравствуйте, Videoman, Вы писали: V>А компилятор будет использоваться новый исправленный, в режиме С++17, или из старого toolset-а ? Если новый, то нужно будет видимо ставить вопрос о переходе, т.к. сейчас у меня, например при компиляции webrtclib от Google, релизный код собранный компилятором от 2017-ой студи просто не работает: падает. Помогает только раздельная сборка CLang-ом.
При установке надо будет поставить галочку на нужном toolset (см. скриншот). Там можно выбрать нужные toolset начиная от VS2015, причем их может быть в рабочей установке несколько. Отличается ли компилятор в toolset 141 из VS2022 от родного toolset в VS2017 — не знаю. Но я бы на месте MS (из общих соображений беспроблемного перехода на новую версию VS) сделал бы их одинаковыми. Т.е. новых проблем с компиляцией не должно появится.
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, Serg27, Вы писали:
V>Вот такое выдала мне 22-я студия при запуске инсталлятора: Image: vsinstaller.jpg V>Мне уже страшно
Ну миллионы пользователей как-то это прошли...
По сообщению об ошибке на русском очень трудно получить какую либо информацию об ошибки в Интернет. Поэтому я всегда использую английский язык с рабочими инструментами. После небольшого поиска и замены русского сообщения на английское — "The source layout directory is too long. The layout directory name must be less than" в выдаче google сразу появляется куча сообщений на эту тему. Сухой остаток — перенесите оффлайн установщик в место на диске с более коротким path. См. например — форум
Я, как человек ленивый, не пользовался offline установщиком (уж очень он здоровый). Пользовался как все online установщиком — проблем нет.
Здравствуйте, Serg27, Вы писали:
S>Я, как человек ленивый, не пользовался offline установщиком (уж очень он здоровый). Пользовался как все online установщиком — проблем нет.
Ну спасибо кеп! Просто неожиданное начало было. Естественно нужно скопировать куда-то на пути меньшей длины. У меня просто всё лежит на NAS, там пути длинные. Как-то я раньше, видимо случайно, на такое не нарывался. Сейчас проверил 2017 — тоже самое.