Доброе время суток!

Что для вас значит C++?
В чем его привлекательность лично для вас ?

Было бы интересно почитать...

Здравствуйте SergeMS, Вы писали:
SMS>Доброе время суток!
SMS>Что для вас значит C++?
SMS>В чем его привлекательность лично для вас ?
SMS>Было бы интересно почитать...

Почему я НЕ люблю С++:
1. На нём пишут слишком много людей.
2. На нём пишут слишком много очень умных людей, до которых мне далеко
3. На нём можно написать почти всё, но при этом даже простая задача может превратиться в квест.
4. Нет единого стандарта, точнее он есть, но мало кто ему следует, поэтому большее количество времени уходит на пускание слюнок от вида возможностей и утирание слёз, от того что их нельзя использовать.
5. Памятью приходится управлять вручную. Все мы хорошие программисты, просто отличные, но рядом с нами всегда есть бездари, которым просто нельзя давать такую возможность.
6. С++ не динамический язык.
7. В С++ нет всех тех удобных конструкций, которые есть в С#.
8. В С++ нет единой стандартной библиотеки. Точнее она есть, но её все реализуют по-разному. К тому же она явно ориентирована на Unix с его Pipes and Filters.
9. С++ не аспектно-ориентированный язык.

... продолжу потом, когда ещё что вспомню

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

SMS>Доброе время суток!

SMS>Что для вас значит C++?
SMS>В чем его привлекательность лично для вас ?

Некоторые пункты почти содраны у Mishka.NET :)

1. На нём пишут очень много людей, и они написали кучу полезных библиотек.
2. На нём пишут очень много очень умных людей, до которых мне уже не далеко.
3. На нём можно написать почти всё.
4. Существует масса компиляторов C++ от разных производителей под разные платформы, и при этом они неплохо стандартизированы.
5. Памятью при необходимости можно управлять вручную.
6. C++ — полностью компилируемый язык.
7. В С++ есть почти все необходимое мне. А если чего и не хватает, так это почти всегда можно написать самому. Если же что-то нельзя дописать самому, то есть, например, такие вещи, как OpenC++.
8. В С++ есть удобная стандартная библиотека.
9. С++ не ориентирован на модные концепции программирования (которые зачастую и на концепции-то не тянут), но прекрасно подходит для почти любой из встреченных мне задач.
10. В C++ есть шаблоны.
11. Программы, написанные на C++, плохо поддаются reverse engineering, что немаловажно для коммерческих применений.
12. Я уже сейчас неплохо знаю C++, чего не скажешь о многих других языках.
13. За программирование на С++ мне платят деньги.

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

M.NET>4. Нет единого стандарта, точнее он есть, но мало кто ему следует, поэтому большее количество времени уходит на пускание слюнок от вида возможностей и утирание слёз, от того что их нельзя использовать.

Последнее время все выправляется.

M.NET>5. Памятью приходится управлять вручную. Все мы хорошие программисты, просто отличные, но рядом с нами всегда есть бездари, которым просто нельзя давать такую возможность.

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

M.NET>6. С++ не динамический язык.

Что понимается под динамическим? Динамическая типизация?
Динамическая типизация это очень очень плохо.

M.NET>8. В С++ нет единой стандартной библиотеки. Точнее она есть, но её все реализуют по-разному. К тому же она явно ориентирована на Unix с его Pipes and Filters.

Не вижу ничего ориентированного на Unix в STL.
Ты наверное плохо предстваляешь что такое Pipes в unix,
или плохо предстваляешь что такое STL.

M.NET>9. С++ не аспектно-ориентированный язык.
Клевый термин, а что он значит?

S>Некоторые пункты почти содраны у Mishka.NET

Черт побери, это похоже на правду! За что одни любят, за то другие — не любят этот же язык

Помните, у Страуструпа про while(*q++ = *p++);
"кто-то любит, а кто-то ненавидит C/C++ за такие конструкции".

А это в свою очередь означает, что не придумать такой язык, который бы всем-всем угодил.
И .net врядли будет панацеей.

Здравствуйте Sergey:

вот под шумок продолжу свой список:
S>1. На нём пишут очень много людей, и они написали кучу полезных библиотек.
1.1. Этих библиотек очень много и порой не понятно где и что искать
1.2. Они не стандартизованы
1.3. Использование библиотек, на подобии Loki, заставляет задумываться о том, что дебагеры ещё не доросли до необходимого уровня.

S>2. На нём пишут очень много очень умных людей, до которых мне уже не далеко.
Вот-вот ещё одним больше, что ж мне там делать

S>3. На нём можно написать почти всё.
... кроме динамических вещей (генерация классов в runtime) и аспекто-ориентированных (атрибуты, аспекты, плетения).

S>4. Существует масса компиляторов C++ от разных производителей под разные платформы, и при этом они неплохо стандартизированы.
А самый популярный компилятор от Microsoft по-прежнему не поддерживает частичную спецификацию шаблонов

S>5. Памятью при необходимости можно управлять вручную.
... и при это управлять криво, а также думать, что всё так и должно быть.

S>6. C++ — полностью компилируемый язык.
И что в этом хорошего? Скорость? Так ngen в .NET тоже производит полную компиляцию, при это по пути она (теоретически) учитывает особенности платформы.
6.1. Скомпилированная программа на С++ не учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться.

S>7. В С++ есть почти все необходимое мне. А если чего и не хватает, так это почти всегда можно написать самому. Если же что-то нельзя дописать самому, то есть, например, такие вещи, как OpenC++.
S>8. В С++ есть удобная стандартная библиотека.
то-то её ТерМиНус в пух и прах разнёс

S>9. С++ не ориентирован на модные концепции программирования (которые зачастую и на концепции-то не тянут), но прекрасно подходит для почти любой из встреченных мне задач.
S>10. В C++ есть шаблоны.
S>11. Программы, написанные на C++, плохо поддаются reverse engineering, что немаловажно для коммерческих применений.
Это да
S>12. Я уже сейчас неплохо знаю C++, чего не скажешь о многих других языках.
А я его уже неплохо забыл Чего и всем остальным желаю.
S>13. За программирование на С++ мне платят деньги.
А мне нет

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

M.NET>>4. Нет единого стандарта, точнее он есть, но мало кто ему следует, поэтому большее количество времени уходит на пускание слюнок от вида возможностей и утирание слёз, от того что их нельзя использовать.
A>Последнее время все выправляется.
Xa!

M.NET>>6. С++ не динамический язык.
A>Что понимается под динамическим? Динамическая типизация?
Хочу создавать классы на лету и их использовать. Хочу в зависимости от содержания класса выполнять разные действия (ну ка попробуй сериализацию на С++ забабахать)
A>Динамическая типизация это очень очень плохо.
Это почему же плохо?

M.NET>>8. В С++ нет единой стандартной библиотеки. Точнее она есть, но её все реализуют по-разному. К тому же она явно ориентирована на Unix с его Pipes and Filters.

A>Не вижу ничего ориентированного на Unix в STL.
А потоки ввода-вывода?

M.NET>>9. С++ не аспектно-ориентированный язык.
A>Клевый термин, а что он значит?
Аспекты

M.NET>6.1. Скомпилированная программа на С++ не учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться.

Мельком пробежал эту ветку, но на этой фразе чуть в обморок не упал. Где-то на этом сайте есть про "Этику программиста". Так ты ёё прочитай, там много чего умного написано. Например, НЕ ЗНАЕШЬ-НЕ ГОВОРИ. Если знаешь поверхностно, то тоже не говори. По-поводу твоего довода привожу контр-аргумент: Intel C++ Compiler. Этот учитывает все.

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

M.NET>Здравствуйте Sergey:

M.NET>вот под шумок продолжу свой список:
S>>1. На нём пишут очень много людей, и они написали кучу полезных библиотек.
M.NET>1.1. Этих библиотек очень много и порой не понятно где и что искать

Напоминает ситуацию с пивом, сыром и колбасой в СССР и России сейчас. Нету — плохо, есть на любой вкус — еще хуже, не понятно, чего покупать.

M.NET>1.2. Они не стандартизованы

А для какого языка/средства разработки стандартизированы? Для VB и Delphi?

M.NET>1.3. Использование библиотек, на подобии Loki, заставляет задумываться о том, что дебагеры ещё не доросли до необходимого уровня.

И не дорастут в ближайшем будущем, IMHO. До сишных макросов так и не доросли :). Но это не повод отказываться от шаблонов.

S>>2. На нём пишут очень много очень умных людей, до которых мне уже не далеко.
M.NET>Вот-вот ещё одним больше, что ж мне там делать ;)

S>>3. На нём можно написать почти всё.
M.NET>... кроме динамических вещей (генерация классов в runtime) и аспекто-ориентированных (атрибуты, аспекты, плетения).

А на кой нужна эта самая генерация классов в рантайме, если не секрет? Что-то ни одной задачи соответствующей не попадалось.

S>>4. Существует масса компиляторов C++ от разных производителей под разные платформы, и при этом они неплохо стандартизированы.
M.NET>А самый популярный компилятор от Microsoft по-прежнему не поддерживает частичную спецификацию шаблонов :(

А C# под *nix вообще нет. И будет ли, не понятно.

S>>5. Памятью при необходимости можно управлять вручную.
M.NET>... и при это управлять криво, а также думать, что всё так и должно быть.

Я написал — "при необходимости". Она не так часто возникает. Насчет "криво" — так это вообще наезд :) Если я вдруг заморачиваюсь с VirtualAlloc или просто с malloc/free или delete, это означает только то, что меня ну очень сильно прижала производительность. Кроме того, управление памятью вручную в C++ подразумевает не только ее динамическое выделение/освобождение, но и контроль за временем жизни объекта без необходимости повторно выделять память. Например, вот такие конструкции могут сильно облегчить жизнь:

    _bitmap.~Bitmap();
    new(&_bitmap) Bitmap;
    _bitmap.Create(w, h, depth);

S>>6. C++ — полностью компилируемый язык.
M.NET>И что в этом хорошего? Скорость? Так ngen в .NET тоже производит полную компиляцию, при это по пути она (теоретически) учитывает особенности платформы.

Ты будешь смеяться, но на *nix установка программы (написанной на С++) очень часто включает в себя компиляцию. Так что гибкость у C++ в этом отношении больше :).

M.NET>6.1. Скомпилированная программа на С++ не учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться.

При желании — легко учитывается. Контрвопрос — а написанная на чем программа (автоматически) учитывает объем памяти и тип процессора? и как она это делает? И что в данном контексте означает "пр." (прочее)?

S>>7. В С++ есть почти все необходимое мне. А если чего и не хватает, так это почти всегда можно написать самому. Если же что-то нельзя дописать самому, то есть, например, такие вещи, как OpenC++.
S>>8. В С++ есть удобная стандартная библиотека.
M.NET>то-то её ТерМиНус в пух и прах разнёс :)))

Если вы не любите кошек, значит, вы просто не умеете их готовить :) Мне его аргументы показались неубедительны.

S>>9. С++ не ориентирован на модные концепции программирования (которые зачастую и на концепции-то не тянут), но прекрасно подходит для почти любой из встреченных мне задач.
S>>10. В C++ есть шаблоны.
S>>11. Программы, написанные на C++, плохо поддаются reverse engineering, что немаловажно для коммерческих применений.
M.NET>Это да :up:
S>>12. Я уже сейчас неплохо знаю C++, чего не скажешь о многих других языках.
M.NET>А я его уже неплохо забыл :))) Чего и всем остальным желаю.
S>>13. За программирование на С++ мне платят деньги.
M.NET>А мне нет :-\

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

M.NET>>6.1. Скомпилированная программа на С++ не учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться.

W>Мельком пробежал эту ветку, но на этой фразе чуть в обморок не упал. Где-то на этом сайте есть про "Этику программиста". Так ты ёё прочитай, там много чего умного написано. Например, НЕ ЗНАЕШЬ-НЕ ГОВОРИ. Если знаешь поверхностно, то тоже не говори. По-поводу твоего довода привожу контр-аргумент: Intel C++ Compiler. Этот учитывает все.

Там бы следовало дописать "НЕ ПОНЯЛ — НЕ ЛЕЗЬ". Уж не знаю, что там учитывает Intel C++ Compiler, но как он может учесть тот факт, что в моем домашнем компьютере процессор — Athlon XP, а в рабочем — Pentium? При условии, что exe'шник на них исполняется один и тот же — о чем, собственно, и шла речь.

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

SMS>Доброе время суток!

SMS>Что для вас значит C++?
SMS>В чем его привлекательность лично для вас ?

SMS>Было бы интересно почитать...

Я немного неправильно сформулировал свой вопрос.
Это был философский вопрос, а не технический...

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

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

M.NET>>>6.1. Скомпилированная программа на С++ не учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться.

W>>Мельком пробежал эту ветку, но на этой фразе чуть в обморок не упал. Где-то на этом сайте есть про "Этику программиста". Так ты ёё прочитай, там много чего умного написано. Например, НЕ ЗНАЕШЬ-НЕ ГОВОРИ. Если знаешь поверхностно, то тоже не говори. По-поводу твоего довода привожу контр-аргумент: Intel C++ Compiler. Этот учитывает все.

S>Там бы следовало дописать "НЕ ПОНЯЛ — НЕ ЛЕЗЬ". Уж не знаю, что там учитывает Intel C++ Compiler, но как он может учесть тот факт, что в моем домашнем компьютере процессор — Athlon XP, а в рабочем — Pentium? При условии, что exe'шник на них исполняется один и тот же — о чем, собственно, и шла речь.

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

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

M.NET>>>>6.1. Скомпилированная программа на С++ не учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться.

W>>>Мельком пробежал эту ветку, но на этой фразе чуть в обморок не упал. Где-то на этом сайте есть про "Этику программиста". Так ты ёё прочитай, там много чего умного написано. Например, НЕ ЗНАЕШЬ-НЕ ГОВОРИ. Если знаешь поверхностно, то тоже не говори. По-поводу твоего довода привожу контр-аргумент: Intel C++ Compiler. Этот учитывает все.

S>>Там бы следовало дописать "НЕ ПОНЯЛ — НЕ ЛЕЗЬ". Уж не знаю, что там учитывает Intel C++ Compiler, но как он может учесть тот факт, что в моем домашнем компьютере процессор — Athlon XP, а в рабочем — Pentium? При условии, что exe'шник на них исполняется один и тот же — о чем, собственно, и шла речь.

W>Программный код компилируется оптимальным образом под конкретный интеловский 32 битный процессор и его архитектурные фичи. Причем есть случаи, на атлонах аналогичной конфигурации такие программы работают даже быстрее.

Вот о том и речь, что учитываются фичи процессора, которого у меня нет, а фичи моего процессора не учитываются. А если б учитывалось то, что нужно, оно, может, еще в два раза быстрее бы работало.

Единственное что мне нравится в с++ это шаблоны. Даже несмотря на свой корявый синтаксис и необходимость указывать все типы. Но, посмотрев на с#, убеждаешься в том, что с++ конкуренции не выдержит.

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

M.NET>>>6. С++ не динамический язык.
A>>Что понимается под динамическим? Динамическая типизация?
M.NET>Хочу создавать классы на лету и их использовать. Хочу в зависимости от содержания класса выполнять разные действия (ну ка попробуй сериализацию на С++ забабахать)

Да всегда была, да она не компилятором делается, да
надо иногда поработать.

A>>Динамическая типизация это очень очень плохо.
M.NET>Это почему же плохо?

Потому что не идет проверка во время компиляции.
Ты когда-нибудь на perl или python писал? Там
вообще нет понятия тип во время компиляции, в результате
все ошибки которые в C++ ловятся во время компиляции
там ловятся во время исполнения(т.е. у заказчика)

Т.е. кто-то поменял параметры функции и она больше
не вызывается старыми модулями, но понять это можно
только попытавшись ее вызвать

M.NET>>>8. В С++ нет единой стандартной библиотеки. Точнее она есть, но её все реализуют по-разному. К тому же она явно ориентирована на Unix с его Pipes and Filters.

A>>Не вижу ничего ориентированного на Unix в STL.
M.NET>А потоки ввода-вывода?

Не вижу какое это отношение имеет к pipes и к unix.
Понятие поток сейчас есть абсолютно везде, а не только в
unix(кто тут недавно упоминал сериализацию?)

M.NET>>>9. С++ не аспектно-ориентированный язык.
A>>Клевый термин, а что он значит?
M.NET>Аспекты

Аспекты чего?

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

W>Программный код компилируется оптимальным образом под конкретный интеловский 32 битный процессор и его архитектурные фичи. Причем есть случаи, на атлонах аналогичной конфигурации такие программы работают даже быстрее.

А как насчёт всяких там параметров командной строки для компилятора С++. Типа будем оптимизировать под Pentium или не будем? Да и потом, если специально не крутиться, то под IA64, прога может и не пахать или пахать не правильно. Я уж не говорю про такие вещи как poket PC. Так что хочется иметь один код для всех и не думать о том, что кто-то что-то поддерживает, а кто-то нет.

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

M.NET>>>6.1. Скомпилированная программа на С++ не учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться.

W>>Мельком пробежал эту ветку, но на этой фразе чуть в обморок не упал. Где-то на этом сайте есть про "Этику программиста". Так ты ёё прочитай, там много чего умного написано. Например, НЕ ЗНАЕШЬ-НЕ ГОВОРИ. Если знаешь поверхностно, то тоже не говори. По-поводу твоего довода привожу контр-аргумент: Intel C++ Compiler. Этот учитывает все.

S>Там бы следовало дописать "НЕ ПОНЯЛ — НЕ ЛЕЗЬ". Уж не знаю, что там учитывает Intel C++ Compiler, но как он может учесть тот факт, что в моем домашнем компьютере процессор — Athlon XP, а в рабочем — Pentium? При условии, что exe'шник на них исполняется один и тот же — о чем, собственно, и шла речь.

А как в этом случае может помоч ngen, о которой упоминалось в контексте (как противопоставление)?

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

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

M.NET>>>>>6.1. Скомпилированная программа на С++ не учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться.

W>>>>Мельком пробежал эту ветку, но на этой фразе чуть в обморок не упал. Где-то на этом сайте есть про "Этику программиста". Так ты ёё прочитай, там много чего умного написано. Например, НЕ ЗНАЕШЬ-НЕ ГОВОРИ. Если знаешь поверхностно, то тоже не говори. По-поводу твоего довода привожу контр-аргумент: Intel C++ Compiler. Этот учитывает все.

S>>>Там бы следовало дописать "НЕ ПОНЯЛ — НЕ ЛЕЗЬ". Уж не знаю, что там учитывает Intel C++ Compiler, но как он может учесть тот факт, что в моем домашнем компьютере процессор — Athlon XP, а в рабочем — Pentium? При условии, что exe'шник на них исполняется один и тот же — о чем, собственно, и шла речь.

W>>Программный код компилируется оптимальным образом под конкретный интеловский 32 битный процессор и его архитектурные фичи. Причем есть случаи, на атлонах аналогичной конфигурации такие программы работают даже быстрее.

S>Вот о том и речь, что учитываются фичи процессора, которого у меня нет, а фичи моего процессора не учитываются. А если б учитывалось то, что нужно, оно, может, еще в два раза быстрее бы работало.

Есть вам хочется, чтобы exe'шник сам оптимально подстраивался под конкреныю систему? Причем говорится, что с помощью C++ компиляторов, такую программу не скомпилировать. Я, конечно, много не знаю, но хочу задать вопрос, а где и каким образом такое вообще можно осуществить. Что бы код, специально не проектированный в расчете на поддержку конкретных платформы, при компиляции неким образом(хотелось бы знать каким, для меня это учень актуально) удовлетворял условию "учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться".

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

A>>>Динамическая типизация это очень очень плохо.
M.NET>>Это почему же плохо?

A>Потому что не идет проверка во время компиляции.
A>Ты когда-нибудь на perl или python писал? Там
A>вообще нет понятия тип во время компиляции, в результате
A>все ошибки которые в C++ ловятся во время компиляции
A>там ловятся во время исполнения(т.е. у заказчика)

A>Т.е. кто-то поменял параметры функции и она больше
A>не вызывается старыми модулями, но понять это можно
A>только попытавшись ее вызвать

Не-е. Значит я не динамическую типизацию имел ввиду Это-то понятно, что вредно.

A>>>Не вижу ничего ориентированного на Unix в STL.
M.NET>>А потоки ввода-вывода?
A>Не вижу какое это отношение имеет к pipes и к unix.
A>Понятие поток сейчас есть абсолютно везде, а не только в
A>unix(кто тут недавно упоминал сериализацию?)
Поток — это stream, а не thread. А ты знаешь что такое архитектурный паттерн Pipes and Filters? Он декларирует построение приложений таким образом, чтобы каждое из них имело входной поток и выходной поток (ну, и из-за того, что это на самом деле не идеально, нужен ещё отдельный поток для ошибок). Так вот Windows NT построен на основе другого паттерна — Microkernel. Там нет такого понятия как iostream, оно просто эмулируется (и во всём С++ виноват).

M.NET>>>>9. С++ не аспектно-ориентированный язык.
A>>>Клевый термин, а что он значит?
M.NET>>Аспекты
A>Аспекты чего?
э-э-э ... как бы тебе объяснить... аспекты приложения. Вот в объектно-ориентированном мире есть объекты, а в аспектно-ориентированном к объектам добавляют ещё некие аспекты (например, аспект безопасности, аспект записи в лог и пр.)

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

P>А как в этом случае может помоч ngen, о которой упоминалось в контексте (как противопоставление)?
Никак Просто NGen был упомянут в противопоставление того, что С++ компилирует программы.