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

J>Мои 5 копеек про достоинства C++
J>Возможность работать на системах с очень ограниченными ресурсами, вроде микроконтроллеров. Яву вы туда не запихнете.

Если не ошибаюсь, J2ME и NetCompact позволяли работать на очень слабых системах. А на совсем слабых возможности c++ точно не нужны (если каждая типизация шаблона будет создавать отдельный шмат кода — то в микросистемах оно только вредит).

J>Возможность написать класс "по кусочкам". Т.е. я сначала пишу определение самого класса, без определений его методов. А потом, ниже определяю все его методы. Очень удобно читать код. Не знаю про Яву, в Питоне надо писать все одним блоком, и когда в класс распухает на много строк, становится очень неудобно иметь со всем этим дело. В C# вроде аналогичная ситуация.

До современных возможностей не дотягивает: в C# вы можете нарезать класс на столько partial реализаций, сколько вам будет угодно, при необходимости отдельно реализуя каждый интерфейс в своём partial-классе.


J>То, что есть отдельные .h и .cpp файлы, позволяет работать над исходниками по-отдельности. Перекомпилировать только то, что требуется. Если я поменял только .cpp файл, перекомпилируется только он.

Зато если поменялся .h(pp) файл перекомпилируется пол проекта. В том же C# или Java изменение одного класса влияет исключительно на зависимые от него сборки, и то только в том случае если изменился интерфейс.

J>Считаю, что маленькая стандартная библиотека — преимущество. Она может быть реализована на обширнейшем количестве систем.
Я бы еще ее подсократил, или расчленил на опциональные компоненты. Например, не везде существуют файлы и потоки ввода/вывода — взять те же микроконтроллеры. В оконных приложениях Windows, потоки cout/cin не имеют смысла. Я бы даже time.h сделал бы опциональным. Если у вас есть обширная стандартная библиотека, она влечет зависимости от наличия фич платформы, которые не везде присутствуют. Хотя опять же, опциональность компонентов библиотеки может спасти ситуацию.

Напоминаю, что CPPшники гордятся тем, что "платишь только за то что используешь" — то есть ширина и глубина стандартной библиотеки не мешает использовать только те функции из неё, которые необходимы. Остальное отрежет линкер.

ЗЫ. Просьба: не используйте список — сайт глючит при цитировании списка (например все мои ответы помечаются как цитаты, даже если сам тег "list" убран), приходится убирать все его теги.

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

J>Мои 5 копеек про достоинства C++
J>Возможность работать на системах с очень ограниченными ресурсами, вроде микроконтроллеров. Яву вы туда не запихнете.

Если не ошибаюсь, J2ME и NetCompact позволяли работать на очень слабых системах. А на совсем слабых возможности c++ точно не нужны (если каждая типизация шаблона будет создавать отдельный шмат кода — то в микросистемах оно только вредит).

J>Возможность написать класс "по кусочкам". Т.е. я сначала пишу определение самого класса, без определений его методов. А потом, ниже определяю все его методы. Очень удобно читать код. Не знаю про Яву, в Питоне надо писать все одним блоком, и когда в класс распухает на много строк, становится очень неудобно иметь со всем этим дело. В C# вроде аналогичная ситуация.

До возможностей современных языков не дотягивает: в C# вы можете нарезать класс на столько partial реализаций, сколько вам будет угодно, при необходимости отдельно реализуя каждый интерфейс в своём partial-классе.


J>То, что есть отдельные .h и .cpp файлы, позволяет работать над исходниками по-отдельности. Перекомпилировать только то, что требуется. Если я поменял только .cpp файл, перекомпилируется только он.

Зато если поменялся .h(pp) файл перекомпилируется пол проекта. В том же C# или Java изменение одного класса влияет исключительно на зависимые от него сборки, и то только в том случае если изменился интерфейс.

J>Считаю, что маленькая стандартная библиотека — преимущество. Она может быть реализована на обширнейшем количестве систем.
Я бы еще ее подсократил, или расчленил на опциональные компоненты. Например, не везде существуют файлы и потоки ввода/вывода — взять те же микроконтроллеры. В оконных приложениях Windows, потоки cout/cin не имеют смысла. Я бы даже time.h сделал бы опциональным. Если у вас есть обширная стандартная библиотека, она влечет зависимости от наличия фич платформы, которые не везде присутствуют. Хотя опять же, опциональность компонентов библиотеки может спасти ситуацию.

Напоминаю, что CPPшники гордятся тем, что "платишь только за то что используешь" — то есть ширина и глубина стандартной библиотеки не мешает использовать только те функции из неё, которые необходимы. Остальное отрежет линкер.

ЗЫ. Просьба: не используйте список — сайт глючит при цитировании списка (например все мои ответы помечаются как цитаты, даже если сам тег "list" убран), приходится убирать все его теги.