Как адаптация в стиле «взял и запустил» (либо заработало сразу, либо пара тикетов и заработало) будет дороже переписывания софта, исходников которого уже скорее всего нет, на другую ОС?
Вы упомянули время, но в условиях тех же терминалов, которые пока что могут поработать еще пару месяцев на винде, по моему деньги важнее времени.
Программист с 25-летним опытом, если не вышел на пенсию или не переквалифицировался в менеджера, наверняка кучу денег попросит.
Да и не факт что такой археологией заинтересовать его можно.
А желающих рыться в этой документации и учиться (наверняка относительно долго), получая скорее всего бесполезный опыт тоже много?
Менять железо невыпускаемое уже много лет?
Откуда вы знаете что система простая? И даже если конкретно эта система простая, думаете нет древних систем которые жутко сложные? Тем более простую систему просто периписать, разве не так?
Есть предел у принципа «работает — не трогай»
Полгига рамы в случае современных браузеров это в пределах погрешности ;)
А вообще может вы и правы, возможно и правда такое дополнение слишком тяжелым было. Моё мнение похоже несколько предвзято, потому что долго приходилось пользоваться достаточно мощным компьютером с медленным и нестабильным интернетом, поэтому тяну всё в офлайн…
Ну то есть понятно, что вы пытаетесь покрыть максимальную аудиторию, и к тому же выпускать продукты с пересекающейся функциональностью не очень выгодно. Но очень хочется оставить на компьютере CLion единственной IDE. Думаю и вам приятно будет.
Можете заодно пояснить мотивацию политики «всё что связано с VS (toolchain, projects) — только ReSharper и никак не Clion»? Кроме желания продавать два продукта естественно.
Я получил как-то ответ, что Clion нацелен на кросс-платформенную разработку, и VS тут не в тему. Но
а). Не кросс-платформенные инструменты (Valgrind, LLDB) не получили такую же реакцию
б). VS не исключает кросс-платформенность. Тот же Cmake генерирует VS проекты, а V8, например, под Win больше ничем не собрать.
Запрос на gprof я и запостил ;)
Valgrind, как и Makefile(а заодно Qt, Visual Studio, Autotools) это один из самых популярных фич-реквестов уже давно. Но и объем работы для них, очевидно, немаленький, поэтому продолжаем ждать.
Хотелось бы поддержку Valgrind, gprof и импорт/поддержку других систем сборки.
И баг с буфером обмена очень противный. Но вы конечно, медленно но верно движетесь к идеалу. Спасибо вам за это.
Да, на багзилле.
Чтобы обратили внимания, кроме того, что надо как можно правильнее и подробнее заполнять баг, желательно выставить tracking flags. Даже если он будет не совсем верный, вам его поправят, но внимание точно обратят.
Запостите багрепорт с запросом фичи. Опишите как вы видите качественную реализацию. Или даже напишите патч и отправьте его мозилле.
Напомню принципы СПО:
принципы СПО
Видишь голую жопу — сшей трусы и отдай владельцу жопы.
Не умеешь шить — сообщи владельцу жопы, где трусы можно купить.
Не знаешь где купить — просто скажи владельцу жопы «А у вас жопа голая!».
Не хочешь делать ничего из предложенного — заткнись, не твое дело.
Существует простое правило:
const модифицирует то, что написано прямо перед ним, за исключением (какой С++ без исключений) случая, когда это первое слово в строке. В этом случае, очевидно, модифицирует то, что прямо после.
И сразу легко понять что
const int ** const p4
это константный указатель на указатель на константный int.
ИМХО — внешняя утилита «полностью отдельная от компиляции» должна иметь свои отдельные файлы.
А если по каким то причинам мы не хотим делать так, а хотим чтобы добавить новую сущность в файлы исходников, то нежелание при этом менять компилятор выглядит странно. Если уж добавляем новую сущность в исходники, то изменение при этом компилятора никак не может считаться минусом — это необходимость.
Можно было закодировать go generate whitespace'ами — их ведь тоже компилятор не учитывает. Но это костыль, как и магические комментарии, и вставлять его на относительно раннем этапе развития языка довольно странно.
Если тема достаточно подробно рассмотрена в статье, то необязательно знать весь язык, чтобы ее обсудить.
Если конкретно описанный в статье принцип выглядит неудобным и нелогичным и это обоснованно аргументами — это конструктивная критика.
Раз уж мы засовываем директивы внешнего инструмента прямо в код, то пусть компилятор их учитывает.
Альтернатива — отдельный файл GENERATE например с содержанием по типу:
Меня удивляет, что конструктивную, в общем-то, критику вы выставляете как неадекватные выкрики Go-хейтеров. И тонкие намеки в виде десятка минусов, вы, видимо, воспринимаете как гонения теми самыми хейтерами.
Попробуйте честно и технически конструктивно отвечать на вопросы, даже если они выставляют Go не в лучшем свете, что в первом комментарии за вас более-менее сделал neolink
Аргументы ad hominem тоже чести вам не делают.
При этом перевод-то неплохой и исходная статья хоть и спорная, но интересная.
ИМХО.
Вы упомянули время, но в условиях тех же терминалов, которые пока что могут поработать еще пару месяцев на винде, по моему деньги важнее времени.
Да и не факт что такой археологией заинтересовать его можно.
Менять железо невыпускаемое уже много лет?
Откуда вы знаете что система простая? И даже если конкретно эта система простая, думаете нет древних систем которые жутко сложные? Тем более простую систему просто периписать, разве не так?
Есть предел у принципа «работает — не трогай»
А вообще может вы и правы, возможно и правда такое дополнение слишком тяжелым было. Моё мнение похоже несколько предвзято, потому что долго приходилось пользоваться достаточно мощным компьютером с медленным и нестабильным интернетом, поэтому тяну всё в офлайн…
Удобнее было бы конечно если бы распознавал на локальном компьютере
Зачем — как раз по-моему вполне очевидно. Хочется одну IDE для все проектах на плюсах. С той же целью у вас и просят поддерживать кучу вещей: Makefile, Qt, Arduino, cross-compilation, Autotools, VS toolchain, SCons, Gradle, ninja, CUDA, intel compiler, Bazel, GLSL ES — это только с первой страницы, то есть с более-менее большим количеством голосов.
Ну то есть понятно, что вы пытаетесь покрыть максимальную аудиторию, и к тому же выпускать продукты с пересекающейся функциональностью не очень выгодно. Но очень хочется оставить на компьютере CLion единственной IDE. Думаю и вам приятно будет.
Я получил как-то ответ, что Clion нацелен на кросс-платформенную разработку, и VS тут не в тему. Но
а). Не кросс-платформенные инструменты (Valgrind, LLDB) не получили такую же реакцию
б). VS не исключает кросс-платформенность. Тот же Cmake генерирует VS проекты, а V8, например, под Win больше ничем не собрать.
Valgrind, как и Makefile(а заодно Qt, Visual Studio, Autotools) это один из самых популярных фич-реквестов уже давно. Но и объем работы для них, очевидно, немаленький, поэтому продолжаем ждать.
Баг с буфером обмена.
И баг с буфером обмена очень противный. Но вы конечно, медленно но верно движетесь к идеалу. Спасибо вам за это.
Чтобы обратили внимания, кроме того, что надо как можно правильнее и подробнее заполнять баг, желательно выставить tracking flags. Даже если он будет не совсем верный, вам его поправят, но внимание точно обратят.
Единообразия нет все равно.
«Правило в стиле С++» ничуть не сложнее, что модифицирует первый const знают все.
Напомню принципы СПО:
Не умеешь шить — сообщи владельцу жопы, где трусы можно купить.
Не знаешь где купить — просто скажи владельцу жопы «А у вас жопа голая!».
Не хочешь делать ничего из предложенного — заткнись, не твое дело.
const модифицирует то, что написано прямо перед ним, за исключением (какой С++ без исключений) случая, когда это первое слово в строке. В этом случае, очевидно, модифицирует то, что прямо после.
И сразу легко понять что
это константный указатель на указатель на константный int.
А если по каким то причинам мы не хотим делать так, а хотим чтобы добавить новую сущность в файлы исходников, то нежелание при этом менять компилятор выглядит странно. Если уж добавляем новую сущность в исходники, то изменение при этом компилятора никак не может считаться минусом — это необходимость.
Можно было закодировать go generate whitespace'ами — их ведь тоже компилятор не учитывает. Но это костыль, как и магические комментарии, и вставлять его на относительно раннем этапе развития языка довольно странно.
Если конкретно описанный в статье принцип выглядит неудобным и нелогичным и это обоснованно аргументами — это конструктивная критика.
Альтернатива — отдельный файл GENERATE например с содержанием по типу:
Попробуйте честно и технически конструктивно отвечать на вопросы, даже если они выставляют Go не в лучшем свете, что в первом комментарии за вас более-менее сделал neolink
Аргументы ad hominem тоже чести вам не делают.
При этом перевод-то неплохой и исходная статья хоть и спорная, но интересная.
ИМХО.