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

L>>Внезапно "затолкать Java" превратилось в "Написать на языке, к которому есть фронтенд к GCC".
L>>Ловкость рук и никакого мошенства, да.
С>Я там про Аду писал, вообще-то. Вам нужен компилятор Ады не на gcc?

Туда можно запихать Java Card и Аду...

Только оказывается, что "запихать" — это скомпилировать в итоге тем же gcc, не получив в итоге ни одного из плюсов "запиховываемого" языка.

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

R>>И даже на этом веселуха еще не заканчивается — обязательно ведь найдется грамотей, который позовет Dispose (прямо либо через using) для входного стрима.
J>Он и так задиспозится, стрим дазиспозится ридером. Это вообще в .NET стандарт, все ридеры по умолчанию закрывают переданный им конструктор стрим. + Обычно есть перегруженный конструктор с флажком, который явно говорит закрывать или нет стрим.

Ну этот же пример можно переписать с набором каких-нибудь других классов, не покрываемых требованиями .NET стандарта. Мы же сейчас не ридеры и стримы обсуждаем, а вопросы владения ресусами и их освобождения. И как ни верти, ответсвенность за правильное освобождение ресурсов, в общем смысле этого слова, в управляемых языках лежит на плечах пользовательского кода. И тут разработчики этих языков оказываются ровно в той же ситуации, что и разработчики языка C его ручным управлением памятью.

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

W>Если ошибки сегментации — это одна из причин "нелюбви", то где эта "нелюбовь" проявляется по отношению к другим подобным языкам, где выстрелы в ногу также легки? Например в языке Си. Но похоже, что никакой "нелюбви" к Си нет.

Си я даже не рассматриваю как язык высокоуровневой разработки. Мне кажется, он безнадёжно устарел даже на низком уровне, где сейчас почти всегда практичнее взять хотя бы тот же C++, не говоря о Rust и т.п. Про покойника или хорошо, или ничего.

Просто тема о C++. Не перечислять же все плохие языки. Хороших тоже много; мне, например, нравятся на данный момент Go, Haskell и Elixir.

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

N>>А ещё — какое-то свойство становится недостатком не само по себе, а попав в комплекс с другими свойствами. Даже с популярностью, потому что масштаб его воздействия как недостатка становится выше терпимого предела.

W>Если говорить абстрактно, то да. Но если говорить про C++, то похоже вы несколько сгущаете краски.
W>Будь это так, то все уже давно бы отказались от него. А если нет, то терпимый предел все-таки чуть повыше.

Так и отказываются же. Java, C#, Rust, Go — это всё примеры, как массово уходят от C++ только потому, что не осиливают или сложность, или непредсказуемость и отсутствие надёжности контроля за использованием памяти.
А у меня на глазах был даже переход C++ -> Python, потому что дал неглючащий результат. Правда, это было в 2003. Сейчас туда бы выбрали Java.
А "все" никогда не будет (или будет лет через 100) — есть же и сейчас те, кто на Cobol или RPG что-то пишет.

Просто для уровня "переносимого ассемблера" альтернатив мало, а "переносимого ассемблера с плюшками" так и совсем нет.
Поэтому ниша есть. Но когда можно задачу реализовать на чём-то ином, пусть даже теряя в эффективности — это делают.
"Бутербродное" построение давно стало нормой. Где-то C# + C++/CLI + C//C++, где-то Python поверх C, где-то Java поверх C++...

N>>Ну а в случае C++ его известные недостатки очень сильно вылазят боком, поэтому переход на другие средства, если можно, или пинания разработчиков, чтобы исправить — нормальная реакция от того, кто хочет с большей пользой тратить свои усилия.
W>Ну так я ниже, буквально над вашим постом написал, что если будут объективные причины заменить на другие средства, то заменят — и это нормально,
W>а не будут каталогизировать недостатки

Почему это не будут? Недостатки надо знать, о них надо говорить, их надо каталогизировать и сводить в таблички. Надо, чтобы о них знали и менеджеры, и юниоры/интерны...

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

W>>Если ошибки сегментации — это одна из причин "нелюбви", то где эта "нелюбовь" проявляется по отношению к другим подобным языкам, где выстрелы в ногу также легки? Например в языке Си. Но похоже, что никакой "нелюбви" к Си нет.

K>Си я даже не рассматриваю как язык высокоуровневой разработки. Мне кажется, он безнадёжно устарел даже на низком уровне, где сейчас почти всегда практичнее взять хотя бы тот же C++, не говоря о Rust и т.п. Про покойника или хорошо, или ничего.

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

K>Просто тема о C++. Не перечислять же все плохие языки. Хороших тоже много; мне, например, нравятся на данный момент Go, Haskell и Elixir.

Я надеюсь, на тему Elixir была шутка. Erlang уже сам по себе для 2018-2019 давно неадекват, но он хотя бы в основном разумно построен в своих рамках. А Elixir — говноподелка прыщавых хипстеров, которые не сумели ничего нормально придумать, начиная с тупейших глюков синтаксиса, зато накидали понтов.

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

R>Ну этот же пример можно переписать с набором каких-нибудь других классов, не покрываемых требованиями .NET стандарта. Мы же сейчас не ридеры и стримы обсуждаем, а вопросы владения ресусами и их освобождения. И как ни верти, ответсвенность за правильное освобождение ресурсов, в общем смысле этого слова, в управляемых языках лежит на плечах пользовательского кода. И тут разработчики этих языков оказываются ровно в той же ситуации, что и разработчики языка C его ручным управлением памятью.

Так выше приводили же пример на шарпе с using? Можно ограничить ресурс скоупом точно так же, как и в С++. Плюс дополнительная фича — если криворукий программист не вызвал close(), ресурс автоматически освобоится сам когда GC удалит объект.

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

scf>Так выше приводили же пример на шарпе с using? Можно ограничить ресурс скоупом точно так же, как и в С++.

Здесь два момента:

1. Конструкция using полезна только в тех случаях, когда объект создается и уничтожается в рамках одного блока, что значительно беднее возможностей, предоставляемых плюсовым RAII;

2. Криворукий юзер может тупо забыть написать "using", или наоборот, сделать это не там, где нужно, или не так, как нужно, не в той последовательности. Или напишет код так, что Dispose будет зваться в двух разных местах для одного и того же объекта. В общем, все те же "радости", что и для ручного управления памятью в C.

scf>Плюс дополнительная фича — если криворукий программист не вызвал close(), ресурс автоматически освобоится сам когда GC удалит объект.

Мы это проходили Этот момент настолько недетерменирован, что практически полностью бесполезен.

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

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

L>Только оказывается, что "запихать" — это скомпилировать в итоге тем же gcc, не получив в итоге ни одного из плюсов "запиховываемого" языка.

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

N>Я надеюсь, на тему Elixir была шутка. Erlang уже сам по себе для 2018-2019 давно неадекват, но он хотя бы в основном разумно построен в своих рамках. А Elixir — говноподелка прыщавых хипстеров, которые не сумели ничего нормально придумать, начиная с тупейших глюков синтаксиса, зато накидали понтов.

Если честно, Elixir у меня ещё в планах на изучение. Go знаю хорошо, Haskell изучал, но не применял на практике.

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

N>>Я надеюсь, на тему Elixir была шутка. Erlang уже сам по себе для 2018-2019 давно неадекват, но он хотя бы в основном разумно построен в своих рамках. А Elixir — говноподелка прыщавых хипстеров, которые не сумели ничего нормально придумать, начиная с тупейших глюков синтаксиса, зато накидали понтов.

K>Если честно, Elixir у меня ещё в планах на изучение. Go знаю хорошо, Haskell изучал, но не применял на практике.

Тогда лучше посмотрите просто на Erlang
Функциональный, параллельный с CSP, кластеризуемый прозрачным образом. Лучшая (до сих пор) реализация обновления кода на ходу, прозрачного для пользователей. Неплохая стандартная библиотека, особенно всякие сетевизмы. Особенно любим в вебе, видеораздаче и т.п.
Недостатки: медленный (чистая динамика), отвратительное поведение под плотным входящим потоком (последнее мне убило два проекта и я его больше не хочу; но есть масса народу, которому это пофиг).

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

scf>Так выше приводили же пример на шарпе с using? Можно ограничить ресурс скоупом точно так же, как и в С++. Плюс дополнительная фича — если криворукий программист не вызвал close(), ресурс автоматически освобоится сам когда GC удалит объект.

Я недавно в Питоне нарвался — было в цикле что-то вроде

    open(target, 'a').write(data)

и... исчерпались файловые дескрипторы

Правильно такие вещи писать как

    with open(target, 'a') as tg:
        tg.write(data)

with — тут аналог C# using.

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

А ведь в Питоне GC более агрессивный, чем в C# — по умолчанию по счётчику ссылок сразу собирается.
Но не помогло.

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

scf>>Так выше приводили же пример на шарпе с using? Можно ограничить ресурс скоупом точно так же, как и в С++.
R>Здесь два момента:
R>1. Конструкция using полезна только в тех случаях, когда объект создается и уничтожается в рамках одного блока, что значительно беднее возможностей, предоставляемых плюсовым RAII;

Не совсем. Ничто не мешает создать "страж"-объект, который хранит ссылку на целевой. Что-то вроде unique_ptr в C++ с его возможностями reset() на новое значение и move владения. И это просто, хотя и нужно об этом позаботиться.

R>2. Криворукий юзер может тупо забыть написать "using", или наоборот, сделать это не там, где нужно, или не так, как нужно, не в той последовательности. Или напишет код так, что Dispose будет зваться в двух разных местах для одного и того же объекта. В общем, все те же "радости", что и для ручного управления памятью в C.

Лишний Dispose обычно не вредит. Пропустить с помощью стража и using — сложно.

А вот обеспечить для объекта, сидящего где-то глубоко в недрах иерархии, немедленное освобождение — вот тут, да, mission impossible.

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

N>Тогда лучше посмотрите просто на Erlang
N>параллельный с CSP

Простите за злостный оффтоп, но из CSP в Erlang-е что?

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

N>>Тогда лучше посмотрите просто на Erlang
N>>параллельный с CSP

S>Простите за злостный оффтоп, но из CSP в Erlang-е что?

Обмен сообщениями между процессами в VM, и вся логика на нём.
(Если это не тот CSP, который вы ожидаете — я заранее согласен. Но мне это неинтересно, и никогда не было.)

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

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

N>>>А ещё — какое-то свойство становится недостатком не само по себе, а попав в комплекс с другими свойствами. Даже с популярностью, потому что масштаб его воздействия как недостатка становится выше терпимого предела.

W>>Если говорить абстрактно, то да. Но если говорить про C++, то похоже вы несколько сгущаете краски.
W>>Будь это так, то все уже давно бы отказались от него. А если нет, то терпимый предел все-таки чуть повыше.

N>Так и отказываются же. Java, C#, Rust, Go — это всё примеры, как массово уходят от C++ только потому, что не осиливают или сложность, или непредсказуемость и отсутствие надёжности контроля за использованием памяти.
N>А у меня на глазах был даже переход C++ -> Python, потому что дал неглючащий результат. Правда, это было в 2003. Сейчас туда бы выбрали Java.
N>А "все" никогда не будет (или будет лет через 100) — есть же и сейчас те, кто на Cobol или RPG что-то пишет.

Ну лично я именно массовых переходов наблюдал только два, это desktop для Win (С#) и банковская сфера (Java). Python вроде бы C++ не заменяет, а дополняет. Это вообще очень хорошо.
А вот ситуация с Go напоминает эксперимент.
C Rust — еще больше. Да и Rust претендует и на замену Cи.
У этих двух товарищей тоже достаточно противников и говорят они в таких же сгущенных красках (все пропало, шеф!). Чего я конечно же тоже не разделяю.
Все-таки да, тенденция есть, я не спорю с вами. Я просто думаю, что вы слишком пессимизируете.
Не так уж и плохо тут (в С++) на самом деле, чтобы употреблять эпитеты вроде "планка терпения". Эмоционально как-то.

W>>Ну так я ниже, буквально над вашим постом написал, что если будут объективные причины заменить на другие средства, то заменят — и это нормально,
W>>а не будут каталогизировать недостатки

N>Почему это не будут? Недостатки надо знать, о них надо говорить, их надо каталогизировать и сводить в таблички. Надо, чтобы о них знали и менеджеры, и юниоры/интерны...

Потому что на волне популярности это делается, чтобы делать, а не затем, чтобы улучшить результат.
Давайте в контексте ветки все-таки еще раз подумаем. Мы ведь тут говорим о стихийных разоблачающих статьях, коих большинство и кои появились именно из-за популярности С++,
а не потому что авторы провели всесторонний анализ на базе своего немалого опыта разработки. Все-таки даже претендующие на серьезность критические статьи нет-нет,
да и грешат нечестными бенчмарками, оценочными эмоциональными суждениями и т.п.
Я говорил именно об этом, ведь контекст был задан именно такой.
Согласитесь, здравый, конструктивный анализ недостатков не будут называть хейтерством.
Есть такая книга, Inside The C++ Object Model. Она старая и во многом неактуальная, но там есть одна интересная вещь.
Это вступление, которое призвано обозначить, что книга позиционируется как борьба с эмоциональной оценкой инструмента.

Rather than answering the individual myself, I forwarded his letter to Steve Vinoski of Hewlett-Packard, with
whom I had previously corresponded regarding the efficiency of C++. Here is an excerpt from his response:

    I have heard a number of people over the years voice opinions similar to those of your
    colleagues. In every case, those opinions could be attributed to a lack of factual knowledge
    about the C++ language. Just last week I was chatting with an acquaintance who happens to
    work for an IC testing manufacturer, and he said they don't use C++ because "it does things
    behind your back." When I pressed him, he said that he understood that C++ calls malloc()
    and free() without the programmer knowing it. This is of course not true. It is this sort of
    "myth and legend" that leads to opinions such as those held by your colleagues….
    Finding the right balance [between abstraction and pragmatism] requires knowledge,
    experience, and above all, thought. Using C++ well requires effort, but in my experience the
    returns on the invested effort can be quite high.

I like to think of this book, then, as my answer to this individual, and, I hope, a repository of knowledge to
help put to rest many of the myths and legends surrounding C++.

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

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

N>Не совсем. Ничто не мешает создать "страж"-объект, который хранит ссылку на целевой. Что-то вроде unique_ptr в C++ с его возможностями reset() на новое значение и move владения. И это просто, хотя и нужно об этом позаботиться.

Все эти телодвижения очень напоминают закаты солнца вручную. У хваленых управляемых языков, у которых, якобы, все на автомате, по сравнению с "переусложненным" C++.

N>Лишний Dispose обычно не вредит.

Обычно не вредит, но иногда может, как повезет. Возможность тяп-ляп-программирования лично для меня преимущество так себе. Или давайте дружно поругаем C++ за то, что он не позволяет повторные вызовы деструкторов?

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

_>Хотел бы поинтересоваться у знающих людей, за что весь мир недолюбливает плюсы. Конкретно у меня данный язык вызывает симпатию (возможно потому, что это мой самый первый более менее освоенный язык программирования);
_>Поделитесь впечатлением и опытом программирования с использованием языка С++?
_>Холивары просьба не разводить, иначе уйдём не в ту степь обсуждения

Отсутствие вменяемой модульности и стандарта бинарной совместимости. Уродская система разделения на h/cpp файлы. Крайне тормозной компилятор. Убогая стандартная библиотека. И еще всякие мелкие разности из-за любви Страуструпа к усложнизму.

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

L>>Здравствуйте, Слава, Вы писали:
L>>Только оказывается, что "запихать" — это скомпилировать в итоге тем же gcc, не получив в итоге ни одного из плюсов "запиховываемого" языка.
С>GCC умеет компилировать Аду. Не в си, а в машинный код. Плюсы вы получите во время разработки на Аде и использования её рантайма (если он есть на целевой платформе, можно и без него).

Можно озвучить плюсы? Только с учетом того, что рантайм — фантастика, там не просто динамической памяти нет, там памяти вообще почти совсем нет

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

N>>Не совсем. Ничто не мешает создать "страж"-объект, который хранит ссылку на целевой. Что-то вроде unique_ptr в C++ с его возможностями reset() на новое значение и move владения. И это просто, хотя и нужно об этом позаботиться.

R>Все эти телодвижения очень напоминают закаты солнца вручную. У хваленых управляемых языков, у которых, якобы, все на автомате, по сравнению с "переусложненным" C++.

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

N>>Лишний Dispose обычно не вредит.

R>Обычно не вредит, но иногда может, как повезет.

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

R> Возможность тяп-ляп-программирования лично для меня преимущество так себе. Или давайте дружно поругаем C++ за то, что он не позволяет повторные вызовы деструкторов?

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

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

R>P.S. При этом заметь, я не иду в атаку с криками "Долой C#!" и "Java — отстой!". Повторюсь: в каждом инструменте есть свои слабые и сильные стороны и нужно просто уметь их исполльзовать.

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