Qraizer: Отнюдь, Dushevny. Даже если он так сделает, лямбда кончается раньше использования var2 и var3, и ругаться компилятор не должен. Но ругается, значит этот пример кода не соответствует оригинальному. То ли сама func1() тоже лямбда, то ли баланс {} где-то нарушен, то ли перепутаны переменные. А попробуй не перепутать, когда они называются одинаково и внутри, и снаружи. Очень напрягают const_cast<>ы. Я не вижу использования лямбды и следовательно нет никакой информации о константности её параметра, но даже так выходит, что реализация её контракта грубейшим образом нарушает собственные же гарантии. Тело цикла по current меняет свой параметр вне заголовка. И как будто этого мало, грубым образом нарушая контракты strtoul(): второй параметр неконстантный, первый константный, и когда они совпадают, для strtoul() это может оказаться полной неожиданностью, это прекрасный способ пострелять по конечностям. И что делает C-шная функция, не умеющая к тому же корректно сообщать об ошибках, в плюсовом коде? Почему не std::stoul()?
Код вроде бы под давние фишки языка, которым 10 лет в обед, но написан безалаберно. 100пудово индус писал. Если Виталь его портирует, пусть хоть в порядок приведёт, чтоб работало не на соплях.
Так теперь развелось десяток стандартов языка, и одни компиляторы не понимают код, написанный под другими.
Не слушай ничьих бредней. Есть Стандарт языка, и он одинаков для всех. Некоторые компиляторы, существующие на рынке десятки лет, могут поддерживать старые Стандартные решения для совместимости со старыми программными продуктами, но такое обычно настраивается. Другое дело, что компиляторы могут также вводить некие расширения Стандарта. Они естественно могут не поддерживаться другими компиляторами. Но на то они и расширения. Если хочешь портабельности, расширения языка в коде использовать нужно ограниченно и локализовано, а не где попало по всему коду.
просто раньше был один способ реализации какого-то кода или объявления какой-то структуры, а сейчас их 10 разных, из которых половина понимается только MSVS и только последними версиями...
Ну, 10 — это ты загнул. Нынче строку в число преобразовать можно тремя Плюсовыми способами и тремя (по Стандарту – двумя) Cшными. Каждый имеет свои плюсы и минусы. std::stringstream удобнейший, включая поддержку национальных предпочтений, но накладный, std::num_get<> неудобный, но значительно быстрее, строковые std::stoXX() самые быстрые, но работают только в C locale classic. Выбирай на вкус, что называется. Cшные по-любому нерекомендованы из-за типовой небезопасности и ненадёжной индикации ошибок. "Только MSVS" означает скорее всего лишь то, что код завязан на MSные расширения языка. Хорошо это или плохо, сказать трудно; однозначно плохо, когда использующий их программер не отличает их от Стандартных конструкций. Если ты думаешь, что у GNU меньше расширений, то вынужден огорчить, их там ещё больше, чем у MS.
Это очень полезная информация. Видимо, буду так делать. Потому как у меня есть готовая виртуалка с семеркой...
Дома на 10-ой ПРОшке проблем с 2017-ой точно нет. На работе стоит корпоративная 7-ка, и там она тоже как влитая работает без нареканий. 2017-ая тоже нынче поддерживает C++17 отлично (не буду говорить "безукоризненно", боюсь соврать), так что и она вполне, думаю, тебе подойдёт. За 2019 ничего сказать не могу, не юзал, но однозначно не должна быть хуже, и я почти уверен, что почти готовый C++20 в 2017 если и поддержат, то развивать точно не будут.
