Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Не будет. Цены там от ОС не зависят. Разница там есть только в самом дешевом тарифе, где винда просто недоступна.
TK>>Давайте считать за 1eur будет виртуалка с 1Gb и 1Ядром. Сколько можно таких виртуалок купить за 12eur?

НС>Ты намеренно выделенное проигнорировал или действительно не заметил? А за 12 евров будет 4Гб и 2 ядра с любой ОС.

Да, читать и считать я умею так же как примерно представляю что ждать от современной серверной винды запущенной на 2-4Gb памяти.
12 виртуалок в итоге купить можно или есть какие-то ограничения типа не больше 1 одной в руки?

Здравствуйте, TK, Вы писали:

TK>Да, читать и считать я умею так же как примерно представляю что ждать от современной серверной винды запущенной на 2-4Gb памяти.

А я не примерно, я очень точно знаю. На 4ГБ просто супер все.

TK>12 виртуалок в итоге купить можно или есть какие-то ограничения типа не больше 1 одной в руки?

А зачем 12, если нужна одна?

Здравствуйте, TK, Вы писали:

TK>А какие проблемы?

Проблем никаких, просто бессмысленно. Нужны докерные контейнеры — покупай докерные контейнеры в облаке. А покупать даже не железку, а ВПС, а потом разворачивать на ней докер ...

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Проблем никаких, просто бессмысленно. Нужны докерные контейнеры — покупай докерные контейнеры в облаке. А покупать даже не железку, а ВПС, а потом разворачивать на ней докер ...

Обычно все просто ограничивается шаблоном виртуалки с предустановленным docker. Но в целом интересно — есть готовый compose — что надо покупать и где для его разворачивания в облаке?

Здравствуйте, Qbit86, Вы писали:

Q>Умиляет выпячивание кроссплатформенности в языке, где нет никакой речи об ABI.

Кроссплатформенность означает что код работает на огромном количестве платформ, начиная от древнего Commodore 64 и микроконтроллеров до веб-страниц внутри браузера.

Q>На C# в каких-то пределах (довольно широких) можно создать dll'ку, которая будет работать без перекомпиляций на iOS, Android, macOS (ранее OS X) и Windows. Это не вообще в теории, это то, что я реально делал (разрабатываю мобильные игры).
Q>В C++, чтобы распространять свою библиотеку, автору нужно либо вываливать исходники с инструкцией по сборке на 4+ компиляторах разных версий, либо собирать бинарники под разные ОС разными компиляторами самому, умножить на количество вариантов линковки с рантаймом, дебаг/релиз, мультитрединг и так далее.

Инфраструктурная проблема это как раз основная, а не то что там фантазируют об утечках и т.п. — я об этом говорил и ранее.
Собрать все зависимости на всех платформах, интерфейсы для всех сторонних языков, из этого всего на каждой платформе слепить пакеты — вот трудоёмкая и муторная задача. Если же сторонних зависимостей мало, а тем более платформ — то особо никаких инфраструктурных проблем нет. Например Unreal портировали в браузер/JS всего за несколько дней, и помимо этого есть ещё целая куча портов, в том числе QT.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

D>>>А ещё есть notepad, который даже скачивать не надо!!!
D>>>(VS Code — это же просто редактор же)
Q>>Это не просто редактор. Это платформа для экстеншнов,
EP>Расширяемый редактор.
Q>>с помощью которых он неплохо интегрируется с... да с чем угодно, под что написаны экстеншны.
EP>Также как и в других расширяемых редакторах а-ля Emacs, Vim, Sublime, Atom и даже отчасти Notepad++.
EP>От IDE отличается отсутствием первой буквы I, то есть Development Environment но недостаточно Integrated, хотя местами грань совсем размыта.

Ну на букву I там линтер, автокомплит, сборка, отладка, интегрированное средство сурс контроля. Даже peek definition с подчетом референсов над членами, как в студии. Чего еще не хватает для IDE? Кучи плывучих окошек?

Здравствуйте, Воронков Василий, Вы писали:

Q>>>с помощью которых он неплохо интегрируется с... да с чем угодно, под что написаны экстеншны.
EP>>Также как и в других расширяемых редакторах а-ля Emacs, Vim, Sublime, Atom и даже отчасти Notepad++.
EP>>От IDE отличается отсутствием первой буквы I, то есть Development Environment но недостаточно Integrated, хотя местами грань совсем размыта.
ВВ>Ну на букву I там линтер, автокомплит, сборка, отладка, интегрированное средство сурс контроля.

Это всё есть например в Emacs.

ВВ>Даже peek definition с подчетом референсов над членами, как в студии. Чего еще не хватает для IDE? Кучи плывучих окошек?

Наличие винегрета фич "как в IDE" не превращает автоматом в IDE. Для того чтобы быть IDE должна быть та самая "I", то есть интеграция всего этого между собой из коробки, от создания проекта до его развёртывания. Но как я уже сказал выше, действительно, местами грань очень размыта.

Здравствуйте, Qbit86, Вы писали:

V>>Когда периодически работаешь одновременно на С++ и на C#, то всегда возникает одно и то же устойчивое ощущение, что на C# ты связан по рукам и ногам.
Q>У меня возникает ощущение, что на C++ ты пытаешься бежать в воде или каком-то желе.

Значит, такое владение предметом.

Здравствуйте, Qbit86, Вы писали:

Q>>>Спасибо, такой фичи не надо. Нужна такая фича, чтобы варианты проверялись/энфорсились в момент чтения/написания обобщённого кода, а не когда-то потом при инстанцировании пользователем в непонятном месте.
V>>Тогда это будет не совсем обобщённый код, а так, обманка, типа генериков. Т.е. прибитие гвоздями к конкретным интерфейсам.
Q>Констрейнты и описания параметров «шаблонов» — это абсолютно нормальная практика во всех современных ЯП: Rust, Scala, Ceylon, Haxe, etc. Это как типы в строго и статически типизированном языке

Похоже, что ты забываешь, что речь всё еще о стадии компиляции и такое несоответствие "констрейнам" (возникни оно в коде) в С++ в любом случае именно на этой стадии обнаруживается. Более того, в С++ легко проверить наличие нужного метода/методов даже в декларативном стиле уже имеющимися ср-вами языка (т.е. ср-в языка достаточно для разработки библиотечных приблуд требуемой функциональности).

Если бы ты взял себе за труд проверить свой аргумент на его действенность, ты бы с пол-тыка нашел примеры на этот счет даже на этом сайте.


Q>ты же не говоришь, что типы ослабляют настоящую мощь void* или динамической типизации?

Пока что я говорю, что ты споришь сам с собой, т.к., будучи применённым к наблюдаемой объективной реальности, подобные "аргументы" просто не существуют в виде именно аргументов.


Q>Параметрический полиморфизм — обширная область в computer science и в частности теории типов, по ней пишут много книжек и пейперов. А ты говоришь «обманка типа генериков».

И снова ты прибегаешь к прямой лжи, пытаясь выдать генерики дотнета за параметрический полиморфизм как таковой. ))

Практически про любой современный язык, поддерживающий параметрический полиморфизм, можно рассуждать лишь в сравнительной степени (есть ранги такого полиморфизма и степень удовлетворения системы типов языка одному или нескольким рангам).

В общем, когда речь идёт о реализации параметрического полиморфизма в C# vs C++ — то тут что-либо обсуждать сложно, т.к. у этих языков явно разные весовые категории в плане такого полиморфизма. С++ частично поддерживает параметрический полиморфизм ранга 2, а дотнет даже 1-й ранг окучить не в состоянии.

Ну и степень consistency в реализации параметрического полиморфизма в дотнете — ниже всякой критики, там просто каша как она есть.
Тут даже далеко ходить не надо, например, в дотнете не существует возможности подписаться на некий полиморфный колбэк, хотя можно заменить делегат интерфейсом c полиморфным методом.

В этом смысле мне дотнет напоминает какой-нить скриптовый язык, типа Питона, с его непоследовательностями и даже откровенными глупостями в дизайне. Все-таки, плюсы куда как более строги и последовательны и, что примечательно при взгляде на новшества языка — сам язык двигается в сторону именно большей строгости и последовательности. Про C# можно сказать ровно противоположное — в язык стараются впихнуть массу "практически полезных вещей". При том, что сам язык не позволяет выражать многие из "полезных вещей" в библиотечной форме, такими вещами требуется нагружать компилятор и именно в этом моменте C# перестаёт отличаться от какого-нить "навороченного" скриптового языка, где любые языковые "вкусности" получаются исключительно и только через хардкодинг их в интерпретаторе.

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>Любые шаблонные выверты уже рефакторятся без проблем в сколь угодно больших проектах.
НС>Шаблон — штука текстовая. Получить нормальную метаинформацию можно только когда в него параметры подставлены. А до этого возможности по рефакторингу крайне ограничены.

У шаблона может быть базовый класс, могут быть собственные поля и методы, есть видимость других типов или свободных ф-ий, т.е. по многим вещам "видимость" прекрасная, по крайней мере в том объеме, в каком можно рефакторить генерики дотнета (т.е. в аналогичных сценариях параметрического полиморфизма) — возможности аналогичные.

Ну и Решарпер С++ в последних версиях выдаёт предупреждение, если в результате рефакторинга у нас может получиться некомпилирующийся код.

Например, где в дотнете принято при трансформации данных описывать акцессоры "по-месту" (навроде x => x.Y) для каждого уникального x, там в С++ ленивый программист может сделать некий шаблонный getY(x) и тогда, действительно, если у одного из типов переименовать поле Y, то потребуется ручное вмешательство затем. В тех случаях, где код будет написан в стиле дотнета (через лямбду с конкретными выводимыми типами по-месту), необходимых дополнительных действий не будет.

Понятно, что x => x.Y выглядит тривиально, это был лишь пример. В общем случае "оно" может быть не тривиальным, т.к. именно под нетривиальные объемы кода пишут те самые шаблоны "многоразового применения" — в этом их фишка.

Здравствуйте, vdimas, Вы писали:

V>У шаблона может быть базовый класс,

А может и не быть.

V> могут быть собственные поля и методы

Типы которых нельзя отресолвить до подстановки параметров.

Здравствуйте, Ночной Смотрящий, Вы писали:

V>> могут быть собственные поля и методы
НС>Типы которых нельзя отресолвить до подстановки параметров.

Угу, особенно в будущих применениях с будущими неизвестными типами.
Только при чем тут рефакторинг — я ХЗ.

Мы рефакторим уже имеющийся код, который видим Решарперу целиком, который прекрасно умеет подставлять параметры в шаблоны.

Здравствуйте, vdimas, Вы писали:

V>>> могут быть собственные поля и методы
НС>>Типы которых нельзя отресолвить до подстановки параметров.
V>Угу, особенно в будущих применениях с будущими неизвестными типами.
V>Только при чем тут рефакторинг — я ХЗ.

Да все при том же — рефакторинг в С++ штука весьма вероятностная, то ли повезет, то ли нет. Причем чем сложнее проект и больше пользы от рефакторинга, тем ниже вероятность что повезет.

V>Мы рефакторим уже имеющийся код, который видим Решарперу целиком, который прекрасно умеет подставлять параметры в шаблоны.

Было б что подставлять.

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>Угу, особенно в будущих применениях с будущими неизвестными типами.
V>>Только при чем тут рефакторинг — я ХЗ.
НС>Да все при том же — рефакторинг в С++ штука весьма вероятностная, то ли повезет, то ли нет. Причем чем сложнее проект и больше пользы от рефакторинга, тем ниже вероятность что повезет.

Мы будем обсуждать слухи или реальность? Или некую вчерашнюю реальность?
Я дал сроки относительно прошлого, начиная с которых можно считать, что рефакторинг в С++ вышел на новый уровень.

Да, инструменты рефакторинга С++ все последние годы не дотягивали до аналогичных из мира Джавы или Дотнета, потому что неоднозначность языка велика, т.е. инструмент рефакторинга должен быть не проще полноценного компилятора С++. Т.е., теоретически такой инструмент родить можно было давно, было бы кому и был бы спрос.

Решарпер, к примеру, "видит" не только исходники, но и параметры компиляции проекта, что в случае С++ важно, ес-но. Но это же позволяет отбросить любые спекуляции насчет "неоднозначности". Компилятор же однозначен при данных параметрах компиляции, верно?

Так же Решарпер "видит", какие h-файлы подключаются из каких cpp-файлов, опять и снова, с учетом настроенных include-директорий проекта, в том числе описанных через переменные окружения (обычная практика для С++).


V>>Мы рефакторим уже имеющийся код, который видим Решарперу целиком, который прекрасно умеет подставлять параметры в шаблоны.
НС>Было б что подставлять.

А ну ясно. "Баба Яга против".

Здравствуйте, Qbit86, Вы писали:

Q>Умиляет выпячивание кроссплатформенности в языке, где нет никакой речи об ABI.

При чем тут ABI?
Кроссплатформенным может быть исходный код, а не бинарный образ.


Q>На C# в каких-то пределах (довольно широких) можно создать dll'ку, которая будет работать без перекомпиляций на iOS, Android, macOS (ранее OS X) и Windows. Это не вообще в теории, это то, что я реально делал (разрабатываю мобильные игры).

Угу, "халва, халва".
В современной объективной реальности, действительно неплохую кросс-платформенность пока что показывает код на С/С++.
Чуть похуже Джава. Дотнет, считай, даже еще не начинал становиться кроссплатформенным, в сравнении с С/С++ или Джавой.


Q>В C++, чтобы распространять свою библиотеку, автору нужно либо вываливать исходники с инструкцией по сборке на 4+ компиляторах разных версий, либо собирать бинарники под разные ОС разными компиляторами самому.

Можно и так, почему бы и нет?
Тем более, когда процедура сборки проходит полностью автоматом под любую конфигурацию, с использованием какого-нить современного высокоуровневого движка описания билда? Тут даже уже не нового CMake достаточно для того, чтобы лишь улыбнуться в ответ на подобного рода спекуляции, бо программисту надо делать минимум телодвижений под каждую новую конфигурацию или не делать вовсе.

Здравствуйте, vdimas, Вы писали:

V>Мы будем обсуждать слухи или реальность? Или некую вчерашнюю реальность?
V>Я дал сроки относительно прошлого, начиная с которых можно считать, что рефакторинг в С++ вышел на новый уровень.

Оно может и вышел, но до уровня C#/Java еще очень далеко. И да, Resharper C++ я много ковырял, так что ничего нового ты не расскажешь.

Здравствуйте, Ночной Смотрящий, Вы писали:

V>>Мы будем обсуждать слухи или реальность? Или некую вчерашнюю реальность?
V>>Я дал сроки относительно прошлого, начиная с которых можно считать, что рефакторинг в С++ вышел на новый уровень.
НС>Оно может и вышел, но до уровня C#/Java еще очень далеко. И да, Resharper C++ я много ковырял, так что ничего нового ты не расскажешь.

Главное, чтобы ты отсебятины не рассказывал. Я-то сижу не для "ковыряния", а для полноценной работы в нем целый рабочий день.

Здравствуйте, vdimas, Вы писали:

V>Главное, чтобы ты отсебятины не рассказывал. Я-то сижу не для "ковыряния", а для полноценной работы в нем целый рабочий день.

Ну да, после сверхубогого кетчупа даже такое достижение как R# C++ воспринимается как откровение.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Получается из-за одного спорного момента ты включил д'Артаньяна

А ты думал, для чего там второй ник? ))

Здравствуйте, AndrewVK, Вы писали:

AVK>P.S. Вспоминается как в далеком 2006 на конференции, народ, видя с какой скоростью я набираю и правлю код в решарпере

Так навигация в Студии или в Студии+Решарпере?
Это совершенно различный экспириенс в той же VS2015.


AVK>замирал с открытыми ртами. А, казалось бы, и решарпер тогдашний был сильно попроще, и кетчуп для шарпа пока еще был весьма популярен. Ан нет, чего то не хватало.

Я в Решарпере в плюсах тоже набираю код так, будто он сам набирается, есть такое.

Да, плюсовый Решарпер отстаёт от дотнетного лет на 10, но этот разрыв сокращается с каждым обновлением. Вот, с последним обновлением резко улучшилась выводимость как раз типов внутри шаблонов (больное плюсовое место).

Но даже дотнетного Решарпера 10-тилетней давности было достаточно для резкого буста разработки.

Всё-таки, кардинальных изменений в плане навигации и рефакторинга в дотнетном Решарпере с 2006-го, считай, не было. Была поддержка новых фич постоянно развивающегося C# + улучшение скорости работы + ловля собственых внутренних ошибок + поддержка анализа кода "на лету" (с предложениями о замене) и т.д.

Анализ кода "на лету" в С++ идёт уже сразу же, в отличие от развития этой области с 0-ля в течении многих лет в дотнетном Решарпере. За пол-года ни одной внутренней ошибкой Решарпер в меня не плюнул (а помнится, дотнетный образца 2006-го года мог плевать в меня ошибками по нескольку раз в день).

В общем, я вангую быстрое преодоление отставания плюсового Решарпера от дотнетного по понятным причинам — не на пустом месте начали, есть уже куча наработок. Просто начали его разработку более чем на 10 лет позже.