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

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

lpd>>auto да, удобен. Как и умные указатели. Но 10 видов одного и того же по смыслу for не нужны.

E>не 10, а два — for (x = 0; x < 10; ++x) и for(x : list). И смысл у них как-бы разный... Или ты под for еще и while подразумеваешь?
Я считаю, что язык программирования должен быть простой как C++(или Java). С++11 и С++14 требуют изучения 10ков дополнительных вариантов синтаксиса для по-большей части редко нужных вещей. Т.е. усложнение языка во многих случаях не оправдано пользой.

E>Стандартная библиотеке в сборке просто таки элементарна — ее вообще обычно собирать не надо Переносимость обычно противоречит мощности — скажем на авр-ках нет потоков / файловой системы, а плюсы там чувствуют себя прекрасно
Стандартная библиотека в некоторых отношениях слабее библиотеки Java, при этом сложнее. Из-за чего часто получается, что в проекте используется много небольших библиотек, каждая из которых требует своих опций линковки на каждом из вариантов Linux.

lpd>>Собственно единственным большим плюсом Java и C#, помимо библиотек, видится сходство с C++.
E>Большой плюс явы и шарпа — управляемая среда исполнения, которая дает по рукам перед тем, как программа расстреляет стек скажем. А на си ничто не мешает его расстрелять и получить донельзя странную ошибку в произвольный момент времени
Контроль стека имеет теоретическую ценность: в реальности чтобы расстрелять стек нужны или бесконечная рекурсия, или неподходящий алгоритм, что выявить не столь сложно.

lpd>>У Java и C# донельзя тормозная VM, а сборка мусора реализуется при необходимости в C++, тем более что есть valgrind.

E>Она то может быть и реализуется, но как? boehm (или как-то так, не помню названия) — куча ограничений и тормоза вероятно еще почище явовских, смарт-поинтеры — довольно много ручной работы, не защищают от некоторых ошибок. valgrind есть только под линем...
Сборщик мусора при желании можно реализовать перегрузкой new/delete и умными указателями. Да, возможно, синтаксис будет несколько сложнее. Но сборка мусора недостаточная причина для использования VM. В том же objective c учет памяти опциональный.

lpd>>на C++ вообщем то тоже можно распространять код для разных платформ в одном исполняемом файле.

E>Да ладно. Начнем с разных форматов файлов и закончим разным АПИ на разных платформах...
Имею ввиду полностью разный исполняемый код для разных платформ в одном бинарном файле. Код может получаться из одного исходника C++, но с макросами для каждой ОС.

Если я правильно помню, при появлении Java основным достоинством декларировалась портабельность Java-апплетов, что неактуально. Других существенных достоинств Java, оправдывающих в 8 раз меньшую производительность, кроме теоретически полезной безопасности, обеспечиваемой JVM, по-моему нет.

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

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

lpd>>auto да, удобен. Как и умные указатели. Но 10 видов одного и того же по смыслу for не нужны.

E>не 10, а два — for (x = 0; x < 10; ++x) и for(x : list). И смысл у них как-бы разный... Или ты под for еще и while подразумеваешь?
Я считаю, что язык программирования должен быть простой как C++(или Java). С++11 и С++14 требуют изучения 10ков дополнительных вариантов синтаксиса для по-большей части редко нужных вещей. Т.е. усложнение языка во многих случаях не оправдано пользой.

E>Стандартная библиотеке в сборке просто таки элементарна — ее вообще обычно собирать не надо Переносимость обычно противоречит мощности — скажем на авр-ках нет потоков / файловой системы, а плюсы там чувствуют себя прекрасно
Стандартная библиотека в некоторых отношениях слабее библиотеки Java, при этом сложнее. Из-за чего часто получается, что в проекте используется много небольших библиотек, каждая из которых требует своих опций линковки на каждом из вариантов Linux.

lpd>>Собственно единственным большим плюсом Java и C#, помимо библиотек, видится сходство с C++.
E>Большой плюс явы и шарпа — управляемая среда исполнения, которая дает по рукам перед тем, как программа расстреляет стек скажем. А на си ничто не мешает его расстрелять и получить донельзя странную ошибку в произвольный момент времени
Контроль стека имеет теоретическую ценность: в реальности чтобы расстрелять стек нужны или бесконечная рекурсия, или неподходящий алгоритм, что выявить не столь сложно.

lpd>>У Java и C# донельзя тормозная VM, а сборка мусора реализуется при необходимости в C++, тем более что есть valgrind.

E>Она то может быть и реализуется, но как? boehm (или как-то так, не помню названия) — куча ограничений и тормоза вероятно еще почище явовских, смарт-поинтеры — довольно много ручной работы, не защищают от некоторых ошибок. valgrind есть только под линем...
Сборщик мусора при желании можно реализовать перегрузкой new/delete и умными указателями. Да, возможно, синтаксис будет несколько сложнее. Но сборка мусора недостаточная причина для использования VM. В том же objective c учет памяти опциональный.

lpd>>на C++ вообщем то тоже можно распространять код для разных платформ в одном исполняемом файле.

E>Да ладно. Начнем с разных форматов файлов и закончим разным АПИ на разных платформах...
Имею ввиду полностью разный исполняемый код для разных платформ в одном бинарном файле. Код может получаться из одного исходника C++, но с макросами для каждой ОС. Вроде как минимум PE-файлы Windows поддерживали вариант одного бинарника и для x86, и для Alpha.

Если я правильно помню, при появлении Java основным достоинством декларировалась портабельность Java-апплетов, что неактуально. Других существенных достоинств Java, оправдывающих в 8 раз меньшую производительность, кроме теоретически полезной безопасности, обеспечиваемой JVM, по-моему нет.