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

W>Ну лично я именно массовых переходов наблюдал только два, это desktop для Win (С#) и банковская сфера (Java). Python вроде бы C++ не заменяет, а дополняет. Это вообще очень хорошо.
W>А вот ситуация с Go напоминает эксперимент.

Гугловцы так не думают.

W>Все-таки да, тенденция есть, я не спорю с вами. Я просто думаю, что вы слишком пессимизируете.
W>Не так уж и плохо тут (в С++) на самом деле, чтобы употреблять эпитеты вроде "планка терпения". Эмоционально как-то.

Я этот термин применяю ко всему. Потому что когда ставится вопрос "надо мигрировать", сработала именно поднятие над планкой терпения, и неважно, с какого языка/фреймворка/etc.

W>Потому что на волне популярности это делается, чтобы делать, а не затем, чтобы улучшить результат.

Те, кого стоит читать — пишут именно чтобы улучшить конкретный или общий результат. Ну, на 90%. Этого достаточно, чтобы определить себе рамки и методы для конструктивного общения.

W>Давайте в контексте ветки все-таки еще раз подумаем. Мы ведь тут говорим о стихийных разоблачающих статьях, коих большинство и кои появились именно из-за популярности С++,
W>а не потому что авторы провели всесторонний анализ на базе своего немалого опыта разработки. Все-таки даже претендующие на серьезность критические статьи нет-нет,
W>да и грешат нечестными бенчмарками, оценочными эмоциональными суждениями и т.п.

Их можно фильтровать — эмоциональные так точно, бенчмарки — сложнее, но тоже получается, когда надо.
А эмоциональный фактор тоже важен — когда он происходит из "ё500-й раз наткнулся на эту дебильную говнофичу".

W>Я говорил именно об этом, ведь контекст был задан именно такой.
W>Согласитесь, здравый, конструктивный анализ недостатков не будут называть хейтерством.

Не соглашусь. Дофига таких, что хейтерством называют любую критику, если в ней есть хоть 0.1% следа эмоций, или просто потому, что ругают их любимое средство. Здесь тоже полно такого, хотя обычно такие дискуссии собираются во flame.comp.

W>Есть такая книга, Inside The C++ Object Model. Она старая и во многом неактуальная, но там есть одна интересная вещь.

Книгу не видел. Посыл понятен. Кстати, автор там неправ:

W> Just last week I was chatting with an acquaintance who happens to
W> work for an IC testing manufacturer, and he said they don't use C++ because "it does things
W> behind your back." When I pressed him, he said that he understood that C++ calls malloc()
W> and free() without the programmer knowing it. This is of course not true.

потому что This is of course true, когда у тебя написано что-то типа c=a+b, где переменные — строки, матрицы или что-то подобное. Да, это делает и C, и многие другие. Но именно в C++ значительно легче потерять контроль за этим, и это тот случай, когда гегелевско-марксистское "переход количества в качество" реализуется в банальнейшем сценарии "говно вода поднялась выше рта".

W> Finding the right balance [between abstraction and pragmatism] requires knowledge,
W> experience, and above all, thought.

Безусловно. Но этот уровень баланса не просто очень высок — слишком часто он бессмысленно затратен.

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

N>Гугловцы так не думают.
Еще бы.

N>Я этот термин применяю ко всему. Потому что когда ставится вопрос "надо мигрировать", сработала именно поднятие над планкой терпения, и неважно, с какого языка/фреймворка/etc.
Ok.

N>Те, кого стоит читать — пишут именно чтобы улучшить конкретный или общий результат. Ну, на 90%. Этого достаточно, чтобы определить себе рамки и методы для конструктивного общения.
Чтобы понять, кого стоит читать, а кого нет, нужно сперва хорошо в это окунуться.
Вот вы, видимо, можете понять. И я могу. А кто-то нет.
Например, прав ли Торвальдс в своей оценке? Я уверен, много кто согласится, множество доказательств приведет. А кто-то другой, возможно тоже, но уже в защиту. Собственно из-за эмоциональности суждений ценность самой критики теряется, даже если она здравая. А если читать аргументы оправдывающие, или оспаривающие его мнение, то без собственного опыта так и не понять кто тут прав. В итоге проще не разбираться, а довериться тому, у кого для "вас" авторитет выше.

N>Их можно фильтровать — эмоциональные так точно, бенчмарки — сложнее, но тоже получается, когда надо.
N>А эмоциональный фактор тоже важен — когда он происходит из "ё500-й раз наткнулся на эту дебильную говнофичу".
Я не привык так реагировать на неодушевленное и вряд ли тут мы с вами придем к соглашению.

N>Не соглашусь. Дофига таких, что хейтерством называют любую критику, если в ней есть хоть 0.1% следа эмоций, или просто потому, что ругают их любимое средство. Здесь тоже полно такого, хотя обычно такие дискуссии собираются во flame.comp.
Такие есть с обеих сторон, об этом и речь.

W>>Есть такая книга, Inside The C++ Object Model. Она старая и во многом неактуальная, но там есть одна интересная вещь.

N>...когда гегелевско-марксистское "переход количества в качество" реализуется в банальнейшем сценарии "говно вода поднялась выше рта".
Очень сложно здесь рассуждать объективно, т.к. очень сильно влияет субъективный опыт.
Например я ни про один из инструментов, которыми я пользовался, не смог бы так сказать.
У вас опыт иной, и вы можете. Значит и тут мы с вами никогда не сойдемся.

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

N>Передёргиваете. Не всё "на автомате", но сильно больше, чем у C++, легче контролируемо и диагностируемо. И переусложнённость последнего это фактор, независимый от его unmanaged характера.

Не передергиваю, а подчеркиваю, что не настолько сильно, как многие хотят это показать. У C++ есть свои преимущества, причем весомые.

N>Если писать, как seen on national TV рекомендовано в книге, то работает без вреда.

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

N>Вроде ж позволяет? Типа p->~C()
N>Или уже запретили? Не следил за этим моментом.

Да написать-то можно все, что угодно. Только повторный вызов деструктора, как и любое обращение к членам объекта после окончания времени его жизни, квалифицируется стандаром языка как UB. Время жизни объекта заканчивается при входе в деструктор. При первом же входе, разумеется. И во многих случаях это UB приводит к реальным проблемам в runtime. Вот, пожалуйста, простейшая иллюстрация: https://ideone.com/mJUlON

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

KP>И я такого не говорю, C++ ж мой кормилец Просто сейчас появились инструменты, которые часто разумнее использоваться вместо C++

Если бы ты добавил к своему высказыванию "для определенного круга задач", то я сразу бы согласился. А попробуй-ка написать на чистом C#, без плюсов, какой-нибудь симулятор физического 3D мира с collision detection, и резолвингом взаимодействий. Я тебе наперед скажу, что будет: никто никуда не полетит. А вот формочки клепать — это да, на шарпе куда приятнее, чем на плюсах. Ну и вообще, разработка на C# существенно проще и быстрее, чем на плюсах, с этим тоже не поспоришь, конечно.

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

R>Если бы ты добавил к своему высказыванию "для определенного круга задач", то я сразу бы согласился. А попробуй-ка написать на чистом C#, без плюсов, написать какой-нибудь симулятор физического 3D мира с collision detection, и резолвингом взаимодействий. Я тебе наперед скажу, что будет: никто никуда не полетит.

На C# – не полетит, как и на любом другом языке с GC.
На Rust – наверное полетит и может быть (тут у меня серьезные сомнения, но всё же) будет проще в поддержке чем C++ реализация.

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

KP>На C# – не полетит, как и на любом другом языке с GC.
KP>На Rust – наверное полетит и может быть (тут у меня серьезные сомнения, но всё же) будет проще в поддержке чем C++ реализация.

К сожалению, мое знание Rust, а точнее, полное его отсутствие, несколько затрудняет мое участие в дискуссии по этому вопросу

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

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

O>Как говорится 40% С++ знает почти каждый. Проблема в том что это всегда разные 40%.

Уточнил бы, что дело не в знании C++, а в субъективных предпочтениях. И если первый вариант С++ понравился большинству программистов, то в последние 10 лет Страуструп его превратил в скобочного монстра, который у большинства вызывает отталкивающее впечатление. При этом C++ не занял ни одной новой ниши за это время.

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

N>3. Вместо того, чтобы сначала плодить проблемы работы с памятью, а потом их ловить — причём может оказаться, что диверсант сидит в чужом проприетарном коде, и ты фиг запинаешь его авторов исправить свою ошибку — можно изначально использовать инструмент, у которого этих проблем нет.
N>Собственно на этом выезжают managed среды, начиная с BASIC и Java: какой бы говнокод на них не писался и не импортировался, он не доведёт обстановку до совсем нерабочего состояния, если не использовать спец. средства, которые легко детектируются. А в unmanaged — наоборот.
Ну, как бэ, как человек который искал и устранял утечки памяти в JS и C#, могу сказать что в С++ с этим попроще(именно нахождение), хотя и опыта в С++ у меня намного больше, а последнии годы я вообще не сталкивался с такой проблемой как утечка памяти в С++.

O>>Как говорится 40% С++ знает почти каждый. Проблема в том что это всегда разные 40%.
lpd>Уточнил бы, что дело не в знании C++, а в субъективных предпочтениях.
Именно С++ позволяет писать "как на С", или "как на джаве/C#".
Джава в свою очередь не позволяет писать "как на С", как и С не позволяет писать "как на джаве".

lpd>И если первый вариант С++ понравился большинству программистов,
Большинству С программистов. Которые стали его воспринимать как расширенную версию С.

lpd>то в последние 10 лет Страуструп его превратил в скобочного монстра, который у большинства вызывает отталкивающее впечатление.
Просто не надо пытаться воспринимать С++ как расширенный С или как недоделанную джаву. Это самостоятельный язык программирования. У тех кто его воспринимает именно так никакого отталкивающего впечатления нету.

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

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

lpd>Уточнил бы, что дело не в знании C++, а в субъективных предпочтениях. И если первый вариант С++ понравился большинству программистов, то в последние 10 лет Страуструп его превратил в скобочного монстра, который у большинства вызывает отталкивающее впечатление. При этом C++ не занял ни одной новой ниши за это время.

Не нужно вот только от большинства выступать — "большинство" оно у всех разное.

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

O>Просто не надо пытаться воспринимать С++ как расширенный С или как недоделанную джаву. Это самостоятельный язык программирования. У тех кто его воспринимает именно так никакого отталкивающего впечатления нету.

Ну вот джава как была в бэкенде, там и есть, без вариадиков и rai. А С++ как был языком для низкоуровнего кода, так им и остался, только его испортили всеми этими умными указателями на шаблонах и вариадиками.
Лично я бы все новые фичи С++ заменил на опциональный GC и какое-нибудь упрощение линковки/сборки. На получившемся языке вдобавок можно было бы писать неущербный по скорости бэкенд.

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

KP>Не так элегантно как в C++, но всё же работает достаточно надежно:
KP>

KP>f := createFile("/tmp/defer.txt")
KP>defer closeFile(f)
KP>writeFile(f)
KP>

А тут есть гарантия, что не будет исключения или чего-то подобного между первой и второй строкой?

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


lpd>А С++ как был языком для низкоуровнего кода, так им и остался, только его испортили всеми этими умными указателями на шаблонах и вариадиками.
lpd>Лично я бы все новые фичи С++ заменил на опциональный GC и какое-нибудь упрощение линковки/сборки. На получившемся языке вдобавок можно было бы писать неущербный по скорости бэкенд.

+1
Кажется, Страуструп высказывался в том духе, что внутри C++ сидит другой, лучший язык, который стремится наружу (не смог найти оригинальную цитату). Вот только он никогда не вылупится: тянет назад требование обратной совместимости со всеми предыдущими версиями вплоть до K&R Си. Лучшие языки появляются вне .

CM>Уродская система разделения на h/cpp файлы.
Ее нет.

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

lpd>Ну вот джава как была в бэкенде, там и есть, без вариадиков и rai.
Ну, да потеснить С++ она не может.

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

lpd>только его испортили всеми этими умными указателями на шаблонах и вариадиками.
Умные указатели и RAII это одна из основных причин использования С++ вместо C.

lpd>Лично я бы все новые фичи С++ заменил на опциональный GC и какое-нибудь упрощение линковки/сборки. На получившемся языке вдобавок можно было бы писать неущербный по скорости бэкенд.
С#, скорость понятие относительное, кому-то хватает и Java и С#.

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

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

lpd>>Ну вот джава как была в бэкенде, там и есть, без вариадиков и rai.
S>Ну, да потеснить С++ она не может.
Ну вообще немало десктопных приложений c GUI написаны на джаве + Android, хотя это и два недоразумения. Но C++-то джаву/C# не потеснил никак за все годы.

lpd>>А С++ как был языком для низкоуровнего кода, так им и остался
S>Нет, С++ позволят управлять ресурсами в стиле С и как в управляемых языках только без переплаты.
Переплата c GC(если ты об этом) играет роль только в real-time приложениях, потому и нужно его сделать опциональным. Зато c GC не надо ломать голову нет ли круговых ссылок, и какой из unique_ptr<T>, shared_ptr<T> или weak_ptr<T> выбирать(отдельное спасибо за вырвиглазный синтаксис).

lpd>>только его испортили всеми этими умными указателями на шаблонах и вариадиками.
S>Умные указатели и RAII это одна из основных причин использования С++ вместо C.
Ну вроде очевидно, что основное отличие C++ это классы, с наследованием и полиморфизмом, которые на C++ удобны — поэтому он и прижился. Все остальное вместе с move-семантикой — уже на любителя.

lpd>>Лично я бы все новые фичи С++ заменил на опциональный GC и какое-нибудь упрощение линковки/сборки. На получившемся языке вдобавок можно было бы писать неущербный по скорости бэкенд.
S>С#, скорость понятие относительное, кому-то хватает и Java и С#.
Отностильно скорости тут уже обсуждали результаты профилирования stackoverflow.com(C#), и выяснилось, что в C# коде процессор проводит столько же времени, сколько в коде базы. То есть ускорение от C++ было бы заметно.
Да и для меня дело не в скорости JVM даже — мне больше нравится простая компиляция в машинные коды, а не в избыточный байткод.

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

KP>>Не так элегантно как в C++, но всё же работает достаточно надежно:
KP>>

KP>>f := createFile("/tmp/defer.txt")
KP>>defer closeFile(f)
KP>>writeFile(f)
KP>>

S>А тут есть гарантия, что не будет исключения или чего-то подобного между первой и второй строкой?

Есть. (А с чего бы ей не быть?)

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

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

KP>>>Не так элегантно как в C++, но всё же работает достаточно надежно:
KP>>>

KP>>>f := createFile("/tmp/defer.txt")
KP>>>defer closeFile(f)
KP>>>writeFile(f)
KP>>>

S>>А тут есть гарантия, что не будет исключения или чего-то подобного между первой и второй строкой?

N>Есть. (А с чего бы ей не быть?)
Многопоточноть?

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

O>>Как говорится 40% С++ знает почти каждый. Проблема в том что это всегда разные 40%.

lpd>Уточнил бы, что дело не в знании C++, а в субъективных предпочтениях. И если первый вариант С++ понравился большинству программистов, то в последние 10 лет Страуструп его превратил в скобочного монстра, который у большинства вызывает отталкивающее впечатление. При этом C++ не занял ни одной новой ниши за это время.

Страуструп давно не рулит развитием языка.
Остальное — я уже подробно высказался в этой ветке.

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

N>>3. Вместо того, чтобы сначала плодить проблемы работы с памятью, а потом их ловить — причём может оказаться, что диверсант сидит в чужом проприетарном коде, и ты фиг запинаешь его авторов исправить свою ошибку — можно изначально использовать инструмент, у которого этих проблем нет.
N>>Собственно на этом выезжают managed среды, начиная с BASIC и Java: какой бы говнокод на них не писался и не импортировался, он не доведёт обстановку до совсем нерабочего состояния, если не использовать спец. средства, которые легко детектируются. А в unmanaged — наоборот.
I>Ну, как бэ, как человек который искал и устранял утечки памяти в JS и C#, могу сказать что в С++ с этим попроще(именно нахождение),

О каких утечках памяти речь в JS и C#? В managed слое, или в переходном к unmanaged?

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

Вам, наверно, везёт, что не приходится использовать посторонние библиотеки?