Переход на x64, измененный интерфейс, упрощенная персонализация и версия IDE для macOS. Компания Microsoft анонсировала Visual Studio (VS) 2022. Разработчиков ждет крупное обновление впервые за три года.
Переход на 64-разрядную версию
Впервые Visual Studio (VS) будет 64-разрядной. В компании заявляют, что благодаря этому в Windows можно будет открывать, редактировать, запускать и отлаживать даже самые большие и сложные решения. При этом переход на х64 не меняет типы или разрядность приложений, которые создаются с помощью VS. Среда разработки по-прежнему будет инструментом для разработки 32-разрядных приложений.
Обновленный пользовательский интерфейс
Некоторые из изменений — это тонкие косметические штрихи, которые модернизируют пользовательский интерфейс. В целом, по словам разработчиков Microsoft, стремятся снизить сложность и когнитивную нагрузку, чтобы пользователи могли сосредоточиться на работе, не покидая рабочую зону VS.
Среди заявленных визуальных изменений:
Обновленные значки для большей четкости, разборчивости и контрастности;
Новый шрифт Cascadia Code — для лучшей читаемости и поддержки лигатур;
Обновленные и улучшенные темы продуктов;
Интеграция с продуктом Accessibility Insights — для раннего обнаружения проблем доступности.
Согласно описанию, в Visual Studio 2022 будет:
Поддерживать создание облачных приложений с помощью Azure;
Иметь полную поддержку .NET 6 и его единой платформы для веб-приложений, клиентских и мобильных API как для разработчиков Windows, так и Mac. Это включает в себя пользовательский интерфейс многоплатформенного приложения .NET (.NET MAUI) для кроссплатформенных клиентских приложений в Windows, Android, macOS и iOS;
Включать надежную поддержку рабочей нагрузки C++ с новыми функциями повышения производительности, инструментами C++ 20 и IntelliSense. Новые возможности С++ 20 упростят управление большими базами кода, а улучшенная диагностика сделает проще отладку сложных проблем с помощью шаблонов и концепций.
Диагностика и отладка
VS 2020 будет включать улучшения производительности в основном отладчике с дополнительными функциями, такими как flame-диаграммы в профилировщике, зависимые брейкпойнты и интегрированные возможности декомпиляции.
Совместная работа и парное программирование
Согласно документации, в Visual Studio 2022 Live Share появится:
Интегрированный текстовый чат для мгновенного обсуждения кода без переключения контекста;
Возможность запланировать повторяющие сеансы, с сохранением одной и той же ссылки, что упростит совместную работу с частными контактами;
Политика сеансов для определения требований соответствия для совместной работы. Например, должны ли терминалы чтения/записи быть общими.
Среди прочих новшеств и обновлений специалисты компании выделяют:
Новая более мощная поддержка Git и GitHub с фиксацией кода, отправкой запросов на вытягивание и слияние ветвей;
Улучшенный поиск кода, в том числе за пределами загружаемой области;
Современная среда разработки для Mac .NET IDE;
Упрощенная персонализация. Разработчикам будет гораздо проще настроить IDE от Microsoft под себя.
Ожидается, что 64-разрядная версия Visual Studio 2022 Preview 1 появится летом 2021-го. Финальный релиз планируется выпустить ближе к концу года.
Здравствуйте, licedey, Вы писали:
L>Впервые Visual Studio (VS) будет 64-разрядной.
А они могут технически объяснить, как они этого добились и как они этого НЕ добились предыдущие 20 лет? Надеюсь, идиотизм типа 'COM' таки выпилен? И я надеюсь, там не спрятан нигде под капотом ублюдочный Electron?
L>В компании заявляют, что благодаря этому в Windows можно будет открывать, редактировать, запускать и отлаживать даже самые большие и сложные решения.
А разве не для этого они все уши прожужжали тем, что "вынесли языковой сервис в отдельное приложение"?!!
Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов! (это у меня теплится последняя надежда на интеллект разрабов)
Сколько приложений ни пишу, ну никак не получается заструячить в солюшен больше 3 проектов! (остальные подцепляются чисто как DLLки)
Если ты работаешь над одним проектом, максимум ещё пара проектов могут висеть в виде сорсов, чтобы синхронизировать улучшения. Это просто твой ЧЕЛОВЕЧЕСКИЙ МАКСИМУМ. Зачем там десятки(!) проектов в иде сорсов — уму не растяжимо.
K>Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов!
И больше засовывают. Если это не хелловорлды, а промышленные решения, у которых кодовая база нарабатывается не первое десятилетие. K>Если ты работаешь над одним проектом, максимум ещё пара проектов могут висеть в виде сорсов, чтобы синхронизировать улучшения. Это просто твой ЧЕЛОВЕЧЕСКИЙ МАКСИМУМ. Зачем там десятки(!) проектов в иде сорсов — уму не растяжимо.
Чтобы сразу видеть в отладчике, что там происходит, как только это потребуется. А не опрашивать 10 человек где правильные исходники dll, и ещё неделю пытаться сбилдить.
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
L> Интегрированный текстовый чат для мгновенного обсуждения кода без переключения контекста; L> Возможность запланировать повторяющие сеансы, с сохранением одной и той же ссылки, что упростит совместную работу с частными контактами; L> Политика сеансов для определения требований соответствия для совместной работы. Например, должны ли терминалы чтения/записи быть общими.
Студию целиком засунули в teams что ли? Вся ваша разработка на сервере большого брата в реальном времени и под запись, с автоматическим наложением режектов на пуллреквесты при употреблении слова black?
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
Я поставил VS preview 2019, и создал в нём тестовый проект, чтобы чекнуть модули си++20. А он мне нагенерил на 100 мегов временных файлов. А это у меня в дроп боксе лежало. Ужас короче. Надеюсь в 2022 такого объёма не будет.
Здравствуйте, Sm0ke, Вы писали:
S>Я поставил VS preview 2019, и создал в нём тестовый проект, чтобы чекнуть модули си++20. А он мне нагенерил на 100 мегов временных файлов.
Это потому, что их никто по рукам не бьет.
S>Надеюсь в 2022 такого объёма не будет.
Здравствуйте, kaa.python, Вы писали:
KP>О, изменение в иконках второе по важности после перевода на 64 бита. Да я смотрю МС все забавнее и забавнее
К черту x64, иконки — вот что важно, лучше бы они еще и были не просто битмапы, а прямо вот каждая кнопка — отдельное виндовой окошко с OpenGL поверхностью и чтобы иконки медленно врощались при наведении курсора. Ну или хотя бы мигали:
Здравствуйте, RonWilson, Вы писали:
vsb>>Windows XP поддерживается?
RW>Еще пока и качать нечего, ближе к лето обещали вроде. Не удивлюсь, что будет поддержка Windows 10/2019 и .. и всё
Как я понимаю, полноценная поддержка была в VS 2017. В VS 2019 полноценной поддержки не было, но была возможность установить и использовать SDK с компилятором от 2017. Интересно, как тут будет.
Здравствуйте, vsb, Вы писали:
KP>>Просто любопытно, а нахрена?
vsb>Есть софт, который работает с Oracle 9i, а этот оракл работает только под XP. Мигрировать не хотят.
Здравствуйте, RonWilson, Вы писали:
KP>>>Просто любопытно, а нахрена?
vsb>>Есть софт, который работает с Oracle 9i, а этот оракл работает только под XP. Мигрировать не хотят.
RW>А зачем тогда эта студия?
Да так, просто. Хочется последними достижениями пользоваться там, где можно. Конечно не критично.
Здравствуйте, vsb, Вы писали:
RW>>А зачем тогда эта студия?
vsb>Да так, просто. Хочется последними достижениями пользоваться там, где можно. Конечно не критично.
Просто после увиденного Live share и прочих утех, лично я не понял зачем 2019 вообще, ну кроме как компилятор свежий из коробки. Да и то, довольно часто очередное обновление пропускается у нас т.к. ошибки в C++ компиляторе (понятия не имею как они их находят, вполне возможно что просто прогоняют сборку ту часть кодовой базы, что на плюсах и тесты).
Здравствуйте, Kolesiki, Вы писали:
K>Сколько приложений ни пишу, ну никак не получается заструячить в солюшен больше 3 проектов! (остальные подцепляются чисто как DLLки)
Ну, я отключил в OpenCV тесты, включил примеры и оказалось 535 проектов. В принципе, всё грузится быстро, работает тоже, модульность хорошая у библиотеки. Проблемы начнутся только тогда, когда надо будет ересобирать десятки проектов на CUDA, если они должны поддерживать сразу несколько поколений видеокарт. Тогда при сборке будет тормозить уже nvcc, а не студия.
K>Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов! (это у меня теплится последняя надежда на интеллект разрабов).
Здравствуйте, Kolesiki, Вы писали:
K>Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов! (это у меня теплится последняя надежда на интеллект разрабов) K>Сколько приложений ни пишу, ну никак не получается заструячить в солюшен больше 3 проектов! (остальные подцепляются чисто как DLLки) K>Если ты работаешь над одним проектом, максимум ещё пара проектов могут висеть в виде сорсов, чтобы синхронизировать улучшения. Это просто твой ЧЕЛОВЕЧЕСКИЙ МАКСИМУМ. Зачем там десятки(!) проектов в иде сорсов — уму не растяжимо.
Я сам четыре года собирал солюшен в котором было 70 проектов. Вроде ничего страшного для энтерпрайза. А 4ГБ мало для интелисенса. Или тебе не нужен интелисенс?
Здравствуйте, bnk, Вы писали:
bnk>А 4ГБ мало для интелисенса.
Как должен работать тот интеллисенс, чтоб ему было мало даже полугигабайта, не говоря уже о четырех?
У меня все чаще возникает ощущение, что большинство современных программистов давно и полностью потеряло ощущение реальности. Оценки делаются лишь исходя из того, что они видят вокруг. Если вокруг видно десяток поделий, которым требуется гигабайт памяти — значит, это и есть объективная потребность. А то, что когда-то то же самое прекрасно обходилось максимум десятками мегабайт, давно и прочно забыто.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У меня все чаще возникает ощущение, что большинство современных программистов давно и полностью потеряло ощущение реальности. Оценки делаются лишь исходя из того, что они видят вокруг. Если вокруг видно десяток поделий, которым требуется гигабайт памяти — значит, это и есть объективная потребность. А то, что когда-то то же самое прекрасно обходилось максимум десятками мегабайт, давно и прочно забыто.
То, что когда-то хватало десятков мегабайт и вполне устраивал lexicon для dos не значит, что раньше решались были такие задачи, которые требуют десятков гигабайт сегодня.
Здравствуйте, RonWilson, Вы писали:
RW>То, что когда-то хватало десятков мегабайт и вполне устраивал lexicon для dos
Во времена Lexicon для DOS типовым объемом памяти был один мегабайт, и больше нескольких сотен килобайт в ОЗУ требовалось лишь особо прожорливым программам.
RW>не значит, что раньше решались были такие задачи, которые требуют десятков гигабайт сегодня.
Такие задачи решались и раньше. Но мы отвлеклись от вопроса об IntelliSense. Сможете обосновать его потребности в памяти, заявленные выше?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Во времена Lexicon для DOS типовым объемом памяти был один мегабайт, и больше нескольких сотен килобайт в ОЗУ требовалось лишь особо прожорливым программам.
Во временя лексикона были OCR системы, например?
RW>>не значит, что раньше решались были такие задачи, которые требуют десятков гигабайт сегодня.
ЕМ>Такие задачи решались и раньше. Но мы отвлеклись от вопроса об IntelliSense. Сможете обосновать его потребности в памяти, заявленные выше?
Понятие не имею много это или мало, в одном из проектов, в котором сейчас участвую, несколько тысяч проектов в одном из солюшенов, сколько там база intellisense занимает, опять же, понятие не имею, но точно знаю что на вполне обычной машине это дело не тормозит, на загрузке, да, подтормаживает, но не более. Учитывая, что intellisense должен работать быстро (иначе зачем он вообще нужен), сомневаюсь, что его откровенные дураки писали с мыслью как бы побольше раздуть базу данных символов.
Здравствуйте, Евгений Музыченко, Вы писали:
bnk>>А 4ГБ мало для интелисенса.
ЕМ>Как должен работать тот интеллисенс, чтоб ему было мало даже полугигабайта, не говоря уже о четырех?
Ну я (да и другие) ниже приводили примеры — просто добавь 50-100 проектов в солюешн
Здравствуйте, RonWilson, Вы писали:
RW>Во временя лексикона были OCR системы, например?
Они были за десятки лет до лексикона. Вообще, когда что-то кажется совсем новым, очень полезно ознакомиться с историей.
RW>в одном из проектов, в котором сейчас участвую, несколько тысяч проектов в одном из солюшенов
Между ними столько же перекрестных связей, и со всеми работают одновременно?
RW>intellisense должен работать быстро
Он должен работать не медленнее ручной правки кода. Только зачем ему для этого гигабайты? Где можно найти оценку потребности в памяти, в зависимости от количества строк, функций, проектов, модулей или еще чего?
Здравствуйте, Евгений Музыченко, Вы писали:
RW>>Во временя лексикона были OCR системы, например?
ЕМ>Они были за десятки лет до лексикона. Вообще, когда что-то кажется совсем новым, очень полезно ознакомиться с историей.
Не надо ни с какой историей быть знакомым чтобы понимать разницу сегоднешнего технологического уровня и того, чтобы было в том веке.
RW>>в одном из проектов, в котором сейчас участвую, несколько тысяч проектов в одном из солюшенов
ЕМ>Между ними столько же перекрестных связей, и со всеми работают одновременно?
Иногда да, работают, но не всегда.
RW>>intellisense должен работать быстро
ЕМ>Он должен работать не медленнее ручной правки кода. Только зачем ему для этого гигабайты? Где можно найти оценку потребности в памяти, в зависимости от количества строк, функций, проектов, модулей или еще чего?
Задайте этот вопрос разработчикам, вполне возможно они очень захотят отчитаться именно перед вами за свои технические решения.
Здравствуйте, RonWilson, Вы писали:
RW>Не надо ни с какой историей быть знакомым чтобы понимать разницу сегоднешнего технологического уровня и того, чтобы было в том веке.
С историей нужно быть знакомым хотя бы затем, чтобы понимать, что далеко не все совершенствуется, многое деградирует. Само по себе наличие технологического уровня не гарантирует того, что все делается технически оптимально. Экономическая оптимальность более вероятна.
ЕМ>>со всеми работают одновременно?
RW>Иногда да, работают, но не всегда.
Тогда на каком основании Вы оцениваете потребность IntelliSense в оперативной памяти, исходя из количества проектов?
RW>Задайте этот вопрос разработчикам, вполне возможно они очень захотят отчитаться именно перед вами за свои технические решения.
Из этого следует, что Вы даже близко не представляете себе реальной потребности софта в памяти, и судите сугубо интуитивно.
Здравствуйте, Евгений Музыченко, Вы писали:
RW>>Задайте этот вопрос разработчикам, вполне возможно они очень захотят отчитаться именно перед вами за свои технические решения.
ЕМ>Из этого следует, что Вы даже близко не представляете себе реальной потребности софта в памяти, и судите сугубо интуитивно.
Точно так же как и Вы, иначе бы не задавали вопрос зависимости размера базы intellisense и количества проектов. С одной лишь разницей — меня это не тревожит вообще никак.
Здравствуйте, Евгений Музыченко, Вы писали:
bnk>>просто добавь 50-100 проектов в солюешн
ЕМ>За счет чего сам факт добавления проектов в солюшен должен автоматически приводить к увеличению потребности IntelliSense в памяти?
Ну зачем же буквально воспринимать
Я имел в виду, не пустых проектов, а с достаточно большим количеством кода внутри каждого из них.
Здравствуйте, bnk, Вы писали:
bnk>Я имел в виду, не пустых проектов, а с достаточно большим количеством кода внутри каждого из них.
Так я понял, что проекты не пустые. Остается непонятным, откуда взялась потребность в гигабайтах ОЗУ для IntelliSense. Есть ли аргументы, выходящие за пределы "ну, эта... оно там все такое... крутое!!!"?
Здравствуйте, Евгений Музыченко, Вы писали:
RW>>Во временя лексикона были OCR системы, например?
ЕМ>Они были за десятки лет до лексикона. Вообще, когда что-то кажется совсем новым, очень полезно ознакомиться с историей.
По факту, это совсем разный уровень. Например, тогдашняя база для проверки качества OCR — MNIS уже много лет считается слишком простой для алгоритмов. И если выходит алгоритм, протестированный только на ней, то его критикуют. Уже давно качество на MNIST 99.999%. Так что не стоит сравнивать.
Так и во всем: по факту объем исходников вырос на порядок, сложность компиляции сильно выросла из-за шаблонов, подсказки стали на порядок умнее. Но нет, ресурсов на все это нам жалко.
Здравствуйте, Nuzhny, Вы писали:
N>сложность компиляции сильно выросла из-за шаблонов
Точнее — из-за неумеренного их применения. Когда из-за отсутствия языковых средств приходилось городить пачки хитровложенных макросов — это объявлялось злом, а сейчас нормой жизни (а то и особой доблестью) считается городить на шаблонах то, что давно должно быть в языке (и заодно избавлять от изрядной части той сложности компиляции).
N>подсказки стали на порядок умнее.
Где можно увидеть тот порядок? Я много сравнивал VS 2019 с VS 2008, но качественной разницы в IntelliSense и подсказках не увидел. Небольшая количественная есть, но и только.
N>Но нет, ресурсов на все это нам жалко.
На хорошее дело ресурсов не жалко. Жалко, когда аппетиты софта растут во много раз, а функциональность растет от силы на десятки процентов.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Точнее — из-за неумеренного их применения. Когда из-за отсутствия языковых средств приходилось городить пачки хитровложенных макросов — это объявлялось злом, а сейчас нормой жизни (а то и особой доблестью) считается городить на шаблонах то, что давно должно быть в языке (и заодно избавлять от изрядной части той сложности компиляции).
Не уверен на счёт именно неумеренного. Например, при активном использовании boost в проекте(ах) оперативная память тает на глазах. Но и boost нужен, всё это заменять велосипедами не хочется. Сейчас потихоньку заменяю кусочки на stl новых стандартов.
N>>подсказки стали на порядок умнее. ЕМ>Где можно увидеть тот порядок? Я много сравнивал VS 2019 с VS 2008, но качественной разницы в IntelliSense и подсказках не увидел. Небольшая количественная есть, но и только.
О, я легко замечаю. Раньше подсказки путались в простейших шаблонах, сейчас они более в контексте и вывозят везде, вообще везде. Шаблоны, auto — легко. Вот я пишу код и реально радуюсь подсказкам. Для сравнения у меня проекты кроссплатформенные и пишутся параллельно на Линуксе в Qt Creator — у него заметно хуже с этим, но при этом он заметно легче и работает быстрее.
ЕМ>На хорошее дело ресурсов не жалко. Жалко, когда аппетиты софта растут во много раз, а функциональность растет от силы на десятки процентов.
Ну надо ещё учитывать, что не всякие зависимости линейные. Тебя же не удивляет, что, например, тепловыделение процессоров зависит от их частоты в кубе? Почему такого не может быть в софте? Небольшие усложнения вполне могут требовать ресурсов на порядки больших.
Отмечу, что этот "идиотизм" многократно повторен по спирали, и сейчас его менее продвинутые версии (которыми еще только все это предстоит) известны как protobuf, thrift, и прочие RPC.
K>Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов! (это у меня теплится последняя надежда на интеллект разрабов) K>Сколько приложений ни пишу, ну никак не получается заструячить в солюшен больше 3 проектов! (остальные подцепляются чисто как DLLки)
Чтоб два раза не вставать. Во всех больших конторах solution'ы столь велики, что содержал заведомо больше "проектов" чем их даже возможно просто скачать на компьютер разработчика.
И занимаются разработкой не один, а тысячи.
Здравствуйте, Nuzhny, Вы писали:
N>По факту, это совсем разный уровень. Например, тогдашняя база для проверки качества OCR — MNIS уже много лет считается слишком простой для алгоритмов. И если выходит алгоритм, протестированный только на ней, то его критикуют. Уже давно качество на MNIST 99.999%. Так что не стоит сравнивать. N>Так и во всем: по факту объем исходников вырос на порядок, сложность компиляции сильно выросла из-за шаблонов, подсказки стали на порядок умнее. Но нет, ресурсов на все это нам жалко.
А главное, для распознавания подавай сканы в высоком разрешении, т.к. с низким, как в 90-е, софт не справится. Ой.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, bnk, Вы писали:
K>>Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов! (это у меня теплится последняя надежда на интеллект разрабов)
bnk>Я сам четыре года собирал солюшен в котором было 70 проектов.
Я вот про такие "гиперсолюшены" и говрю — нахрена?? Неужели ты правишь все 70 проектов, что тебе нужны все их исходники?
Очевидно, что из 70 проектов, лично ты ответственнен только за часть. И даже из этой части, некоторые проекты уже допилены или по кр. мере не требуют вмешательства — их выносим в простые DLLки и референсим.
И повторюсь, даже просто как человек, ты не в состоянии править 10 проектов сразу. Тогда зачем держать их в виде сорсов? Если возникнет ошибка, студия всё равно откроет тебе их сорсы.
Здравствуйте, SkyDance, Вы писали:
K>> Надеюсь, идиотизм типа 'COM' таки выпилен?
SD>Отмечу, что этот "идиотизм" многократно повторен по спирали, и сейчас его менее продвинутые версии (которыми еще только все это предстоит) известны как protobuf, thrift, и прочие RPC.
COM вообще не про RPC, ты ничего не напутал??
K>>Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов! (это у меня теплится последняя надежда на интеллект разрабов) K>>Сколько приложений ни пишу, ну никак не получается заструячить в солюшен больше 3 проектов! (остальные подцепляются чисто как DLLки)
SD>Чтоб два раза не вставать. Во всех больших конторах solution'ы столь велики, что содержал заведомо больше "проектов" чем их даже возможно просто скачать на компьютер разработчика. SD>И занимаются разработкой не один, а тысячи.
Ерунда. Проектов на ТЫСЯЧИ разрабов — едва ли не десяток на весь мир. Я именно про разрабов, а не околопроектную шушару. И очевидно, любой (правильно спроектированный!) проект разделяется на подмодули, где никакими "тысячами разрабов" и не пахнет. Каждый пилит свой модуль, который при правильном интерфейсе с системой, не нуждается в десятках других проектов. Чем лучше разделяешь функции модулей, тем более они независимы и реюзабельны. И снова мы приходим к тому, что разрабу вообще нафиг не упёрлись "десятки проектов в солюшене" — достаточно иметь несколько своих проектов (опять же, не все в виде сорсов!) + интеграционные.
Ну и?? Снова вопрос про безалаберные солюшены с сотнями проектов — ЗАЧЕМ??
Здравствуйте, Евгений Музыченко, Вы писали:
N>>подсказки стали на порядок умнее.
ЕМ>Где можно увидеть тот порядок? Я много сравнивал VS 2019 с VS 2008, но качественной разницы в IntelliSense и подсказках не увидел.
Подтверждаю. Мелкомягкие за 20(!) лет студии чем только не занимались, но только не качеством подсказок! Как был тупой список всего, что только можно вкорячить, таким и остался.
Контекст? Не, не слышали! Локальные переменные? Да нафиг ты нам упёрся со своими сложностями — ищи их в общем списке!
Сами мелкомягкие сознались (в одном из моих issues), что текущий механизм — плохой и его будут переделывать (включая абсолютно идиотскую идею контекстного меню "только на расширение").
Собственно, я потому и взялся однажды заменить этот бардак собственным механизмом — не тут-то было! Оказывается, ты можешь только ДОПОЛНЯТЬ интеллисенс, но не заменять!! Как до такого вообще можно было додуматься?????
Бестолковый механизм интеллисенса + такой же бестолковый метод его наполнения = "современная IDE, помогающая разработчику". Позорники!
Здравствуйте, Kolesiki, Вы писали:
K>>>Да и так, в целом, откуда пишутся такие монструё****бища, которым мало 4ГБ в проекте? Ну не засовывают же они в один солюшен сотни проектов! (это у меня теплится последняя надежда на интеллект разрабов)
bnk>>Я сам четыре года собирал солюшен в котором было 70 проектов.
K>Неужели ты правишь все 70 проектов, что тебе нужны все их исходники?
Нет конечно
Просто "здесь так принято". Исторически сложилось. Никто уже и не вспомнит зачем там все эти проекты и что они вообще делают.
Но наверное зачем-то нужны. К тому же вся эта хрень завязана на систему сборки и деплоя. Которой занимается другой отдел.
Да, речь не про плюсы, если что.
COM это и есть RPC (а если добавить D, чтоб получился DCOM, так это еще и out-of-process, и даже как бы cross-machine RPC).
K>Ерунда. Проектов на ТЫСЯЧИ разрабов — едва ли не десяток на весь мир.
Во-первых, намного больше.
Во-вторых, именно эти проекты и тащат за собой больше всего денег.
K>Ну и?? Снова вопрос про безалаберные солюшены с сотнями проектов — ЗАЧЕМ??
Потому что сделать хорошую модульную архитектуру, решение с multi-repo (а не mono-repo на десятки и сотни гигабайт исходников) намного _СЛОЖНЕЕ_ чем научить IDE работать с огромными помойками на тысячи и десятки тысяч проектов.
Здравствуйте, Nuzhny, Вы писали:
N>Тебя же не удивляет, что, например, тепловыделение процессоров зависит от их частоты в кубе? Почему такого не может быть в софте? Небольшие усложнения вполне могут требовать ресурсов на порядки больших.
Зависимость тепловыделения от частоты — объективный закон природы, не людьми придуманный. А программирование — дисциплина, полностью созданная людьми, поэтому рост требований к ресурсам на порядки из-за небольших усложнений — это либо лень, либо криворукость, третьего не дано.
Здравствуйте, RonWilson, Вы писали: KP>>О, изменение в иконках второе по важности после перевода на 64 бита. Да я смотрю МС все забавнее и забавнее RW>К черту x64, иконки — вот что важно, лучше бы они еще и были не просто битмапы, а прямо вот каждая кнопка — отдельное виндовой окошко с OpenGL поверхностью и чтобы иконки медленно врощались при наведении курсора. Ну или хотя бы мигали:
Вот вы смеётесь, а в интерфейсе можно бесконечно скруглять и раскруглять углы, и каждый раз про это писать анонс. MS сейчас только этим и занимается. Как оно при этом умудряется ломать очередные апдейты операционки — йанипанимаю.... И это нифига не смешно.
Я 2019 уже не ставлю, потому что нет вменяемой возможности установить и зарегаться в ней офф-лайн. И как я понимаю, лучше не стало, с учётом упоминаний team-а.
Скрытый текст
Не, я конечно поставлю 2022 посмотреть, что нового для простого юзера, но особых надежд не питаю. У меня есть небольшой пользовательский опыт, я сам (недо)писал редактор кода, плотно использовал VS и Idea, замучив всех друзей-пользователей того и другого вокруг на тему юзабилити, сам маньячно истыкал мышкой обе IDE, и у меня пока грустные выводы. Был бы я умным и не рукожопым, я бы доделал свой редактор и сделал свою IDE. Проблема для меня в навигации по проекту. Когда проект/файлы разрастаются, даже при хорошем порядке в коде и голове, часто приходится долго позиционироваться в нужные места.
Здравствуйте, CEMb, Вы писали:
CEM>Вот вы смеётесь, а в интерфейсе можно бесконечно скруглять и раскруглять углы, и каждый раз про это писать анонс. MS сейчас только этим и занимается. Как оно при этом умудряется ломать очередные апдейты операционки — йанипанимаю.... И это нифига не смешно.
Операционки еще ладно, подумаешь — машина вообще перестала загружаться на этот случай как раз их храню актуальный Windows Image Backup, чтобы за минут пять откатить на работающую, а не мучаться с профанацией restore point. Вот когда ломают в своих обновлениях компилятор, это уже точно не смешно.
Здравствуйте, SkyDance, Вы писали:
SD>Отмечу, что этот "идиотизм" многократно повторен по спирали, и сейчас его менее продвинутые версии (которыми еще только все это предстоит) известны как protobuf, thrift, и прочие RPC.
А в чем там проблема-то?
Вот есть protobuf, открытая технология, позвлояет сохранять сложные структуры в бинароном виде и пересылать их.
В чем тут "идиотизм" и какая здоровая альтернатива?
Здравствуйте, Nuzhny, Вы писали:
N>О, я легко замечаю. Раньше подсказки путались в простейших шаблонах, сейчас они более в контексте и вывозят везде, вообще везде. Шаблоны, auto — легко. Вот я пишу код и реально радуюсь подсказкам. Для сравнения у меня проекты кроссплатформенные и пишутся параллельно на Линуксе в Qt Creator — у него заметно хуже с этим, но при этом он заметно легче и работает быстрее.
clang backend попробуй. Медленее, но разбирает всё.
Здравствуйте, SkyDance, Вы писали:
SD>Потому что сделать хорошую модульную архитектуру, решение с multi-repo (а не mono-repo на десятки и сотни гигабайт исходников) намного _СЛОЖНЕЕ_ чем научить IDE работать с огромными помойками на тысячи и десятки тысяч проектов.
Поменять сложившуюся архитектуру большого проекта в энерпрайзе нужны стальные яйца, политический вес и железная воля. Далеко не всегда все это есть в одном месте. Поэтому да, проще докупить железа и допилить IDE.
S>Поменять сложившуюся архитектуру большого проекта в энерпрайзе нужны стальные яйца, политический вес и железная воля. Далеко не всегда все это есть в одном месте. Поэтому да, проще докупить железа и допилить IDE.
Здравствуйте, SkyDance, Вы писали:
K>>COM вообще не про RPC, ты ничего не напутал??
SD>COM это и есть RPC (а если добавить D, чтоб получился DCOM, так это еще и out-of-process, и даже как бы cross-machine RPC).
С таким же успехом и овёс можно считать чем-то относящимся ко скачкам.
Ключевой момент COM — модульные приложения, где каждый модуль — чёрный ящик, у которого можно спросить интерфейсы. Remote там никаким боком, там ключевое — Component.
K>>Ну и?? Снова вопрос про безалаберные солюшены с сотнями проектов — ЗАЧЕМ??
SD>Потому что сделать хорошую модульную архитектуру, решение с multi-repo (а не mono-repo на десятки и сотни гигабайт исходников) намного _СЛОЖНЕЕ_ чем научить IDE работать с огромными помойками на тысячи и десятки тысяч проектов.
Вообще не понимаю, к чему ты это приплёл.
Когда у тебя есть громадный проект, он всё равно ДАЖЕ ФИЗИЧЕСКИ состоит из кучи независимых вещей. Та же IDE — кажется большой, но на деле остоит из ядра и плагинов. Ну и накой тысячу проектов лепить в один солюшен, если ты всё равно пишешь ОДИН плагин и пару связанных проектов рядом?? Никто и никогда не работает с сотней проектов, просто мозгов не хватит. А если они ещё и взаимозависимы, то это вообще жопа, а не архитектура.
Здравствуйте, StatujaLeha, Вы писали:
SL>Вот есть protobuf, открытая технология, позвлояет сохранять сложные структуры в бинароном виде и пересылать их. SL>В чем тут "идиотизм" и какая здоровая альтернатива?
Протобуф придумали гугловские долбоклюи. Для начала, это БИНАРНАЯ хрень. Т.е. сразу отсекаем вменяемый дебаг, логи и т.п. Затем, сама идея: отдельным инструментом генерить сериализатор и потом тщательно следить за его актуальностью.
Альтернатива? JSON, конечно! Несмотря на избыточность с т.з. процессора или сети, даёт гигантскую интероперабельность! Не нужно изобретать никаких Corba, DCOM, REST и прочую ересь, да ещё и оглядываться на совместимость little/big-endian. Просто юзаешь JSON-RPC и имеешь все благá мира.
Здравствуйте, licedey, Вы писали:
L>Ожидается, что 64-разрядная версия Visual Studio 2022 Preview 1 появится летом 2021-го. Финальный релиз планируется выпустить ближе к концу года.
Здравствуйте, Kolesiki, Вы писали:
K>Протобуф придумали гугловские долбоклюи. Для начала, это БИНАРНАЯ хрень. Т.е. сразу отсекаем вменяемый дебаг, логи и т.п. Затем, сама идея: отдельным инструментом генерить сериализатор и потом тщательно следить за его актуальностью.
K>Альтернатива? JSON, конечно! Несмотря на избыточность с т.з. процессора или сети, даёт гигантскую интероперабельность! Не нужно изобретать никаких Corba, DCOM, REST и прочую ересь, да ещё и оглядываться на совместимость little/big-endian. Просто юзаешь JSON-RPC и имеешь все благá мира.
Так плюс protobuf — это эффективность: т.е. минимальные дополнительные издержки на передачу структурированного объекта из одного места в другое.
А у JSON-а будет в этом плане дикий оверхед: как в плане объема данных, так и по производительности(разбор полученной структуры сложнее, чем десериализация).
Пока мне видится, что оба решения найдут свою нишу.
Если у Вас появится необходимость слать много сообщений с одного компьютера(скажем, 100к/сек), то разве Вы сходу возьмете JSON, не взглянув на protobuf?
Здравствуйте, Kolesiki, Вы писали:
K>Протобуф придумали гугловские долбоклюи. Для начала, это БИНАРНАЯ хрень. Т.е. сразу отсекаем вменяемый дебаг, логи и т.п. Затем, сама идея: отдельным инструментом генерить сериализатор и потом тщательно следить за его актуальностью.
Дебажиться можно, потому что исходники генерируются и они у тебя есть, опыт такой есть.
Отдельный сериализотор — это тоже не проблема, если его правильно использовать: с проектом таскаем только proto файлы, генерация идёт на этапе конфигурирования в cmake.
K>Ключевой момент COM — модульные приложения, где каждый модуль — чёрный ящик, у которого можно спросить интерфейсы. Remote там никаким боком, там ключевое — Component.
Нет. Ключевой компонент СОМ — это бинарно совместимый протокол (потому что генерируется из IDL). Это ровно то же, чем является, скажем, protobuf, thrift, или другие подобные фреймворки (когда описывается не только упаковка, но еще и всякие соглашения о том, как версионировать протокол, — тот самый QueryInterface, для тех, кто помнит).
K> Ну и накой тысячу проектов лепить в один солюшен, если ты всё равно пишешь ОДИН плагин и пару связанных проектов рядом??
Потому что тебе надо всегда работать с самой свежей версией этих "связанных проектов". Ибо 20,000 разработчиков вносят изменения общей частотой в 10 Гц и больше.
K> Никто и никогда не работает с сотней проектов, просто мозгов не хватит.
Ты путаешь "работает над" и "работает с".
Ты можешь работать НАД одним проектом. Но при этом работать С тысячей других (которые ты сам не меняешь, но свежую версию иметь обязан).
K> А если они ещё и взаимозависимы, то это вообще жопа, а не архитектура.
Нео, просыпайся. Реальный мир крупных корпораций именно такой. Архитектура? Это классное слово, неприменимое к реальности работы огромных корпораций.
Здравствуйте, RonWilson, Вы писали:
RW> почему-то шрифт стал каким-то пухлым:
Это у мелкомягких рожи от халявных денег опухли, щёки на глаза давят, видеть стало сложно — вот шрифт и увеличили!
В этом "наконец-то 64-битном" поделии танцоров боюсь одного — опять всё выльется в местечковые улучшения вроде шрифтов и иконок, ну ещё от COM-шлака избавятся, но могут нагородить "в угоду совместимости" те же костыли, только перекомпиленные под 64 бита. Тогда такая студия точно не нужна — будет мильён багов и на 2 пофикшеных 5 свежесозданных. (всё как в Win10! Традиции предков.)
Здравствуйте, StatujaLeha, Вы писали:
SL>Так плюс protobuf — это эффективность
В мире гигабитных сетей и гигагерцевых камней выжимать полтора байта — такая себе "эффективность"!
Всё ведь ещё и от данных зависит: если у тебя много ЧИСЕЛ или мультимедия какая — да, всё бинарное, протоБуф во всей красе. Но много ли таких узконаправленных сервисов?!
Любую СУБД возьми — имя-фамилия, адрес, URLы всякие, комменты, названия субъектов, описание товаров и т.п. — всё строки. А строке что в протобуф, что в JSON — те же байты.
Ну и не забываем, во что выливается затачивание проекта на один язык или одну технологию. JSON позволяет написать сервис на C#, заюзать из LISP, передать JSON-результат ASM'овой библиотеке где-то на мэйнфрэймах, а выход снова засосать JSON'ом в Перл. Да, конечно же на каждой платформе придётся написать свой JSON-парсер, но без оглядки на little/big endian, на сопутствующие тулзы и т.п. Более того — даже не нужно никаких описаний API, чтобы понять, ЧТО тебе возвратил JSON-сервис — всё самоочевидно. Т.е. взаимодействие команд, проектов, библиотек выходит на новый, независимый уровень. Даже странно, что этим "межгалактическим языком" не стал XML.
SL>Пока мне видится, что оба решения найдут свою нишу.
Согласен. Только у JSON ниша на порядок шире. Для типичного десктоп-разраба вообще нет смысла говорить о каких-то протобуфах, а на вебе и подавно.
Здравствуйте, SkyDance, Вы писали:
K>> Ну и накой тысячу проектов лепить в один солюшен, если ты всё равно пишешь ОДИН плагин и пару связанных проектов рядом??
SD>Потому что тебе надо всегда работать с самой свежей версией этих "связанных проектов". Ибо 20,000 разработчиков вносят изменения общей частотой в 10 Гц и больше.
Вот оно, "поколение смузи"! (nuget-изобретатели походу тоже едва ПТУ закончили) "самой свежей"??? А ты в курсе, что именно "самое свежее" напрочь ломает процесс разработки? А ты в курсе, как делается мерж в DVCS? (я не про команды, а ПРАВИЛА, железные законы совместной разработки) Походу, что нет.
SD>Нео, просыпайся. Реальный мир крупных корпораций именно такой. Архитектура? Это классное слово, неприменимое к реальности работы огромных корпораций.
Если бесноватые индусы замонстрячили 1000 проектов в одну кучу, поверь — долго это г*** не протянет. Да и студия не обязана поощрять такой маразм. Архитектуры бывают разные, но старшие умные товарищи всё же рекомендуют low coupling.
Здравствуйте, Kolesiki, Вы писали:
K>В мире гигабитных сетей и гигагерцевых камней выжимать полтора байта — такая себе "эффективность"!
Посмотри видео Jeff Dean для чего они ввели протобуф и что гугл на этом поимел.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
K>Вот оно, "поколение смузи"! (nuget-изобретатели походу тоже едва ПТУ закончили) "самой свежей"??? А ты в курсе, что именно "самое свежее" напрочь ломает процесс разработки? А ты в курсе, как делается мерж в DVCS? (я не про команды, а ПРАВИЛА, железные законы совместной разработки) Походу, что нет.
Расскажи об этом подробнее компаниям типа google, facebook, а то они, бедные, не знают, и вынуждены делать всякие странные вещи вроде bazel/buck для работы с терабайтными моно-репозиториями.
K>Если бесноватые индусы замонстрячили 1000 проектов в одну кучу, поверь — долго это г*** не протянет.
Срочно беги шортить акции американских ИТ-гигантов! Наваришься!
Здравствуйте, RonWilson, Вы писали:
КД>>Думал будет работать долго, но у неё там опять что-то внутри сломалось и пришлось перезапускать.
RW> это что-то новое — раньше ломалось и быстро заканчивалось, а теперь новая фича (видимо) ломается, но медленно
Ага.
Поигрался немного (была слабая надежда) и вернулся назад в 2019.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, SkyDance, Вы писали:
K>>Вот оно, "поколение смузи"! (nuget-изобретатели походу тоже едва ПТУ закончили) "самой свежей"??? А ты в курсе, что именно "самое свежее" напрочь ломает процесс разработки? А ты в курсе, как делается мерж в DVCS? (я не про команды, а ПРАВИЛА, железные законы совместной разработки) Походу, что нет.
SD>Расскажи об этом подробнее компаниям типа google, facebook
О! Теперь ещё и "не сотвори себе кумира" подъехало. Ты СВОЕЙ головой будешь думать или так и будешь пенять "Жираф большой — ему видней!"?
КД>Работает поотзывчивей. Выжрала больше 5GB.
Майнит или сдаёт комп в аренду? КД>Бум надеяться, что телеметрия работает и они подобные проблемы порешают
И подобные порешают, и новых подгрузят для решания.
Друга ищи не того, кто любезен с тобой, кто с тобой соглашается, а крепкого советника, кто полезного для тебя ищет и противится твоим необдуманным словам.
Как до такого вообще можно было додуматься????? 
