Re[8]: Чем так привлекателен C++ ? - Философия программирования

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

Что для вас значит 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 был упомянут в противопоставление того, что С++ компилирует программы.

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

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

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

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

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

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

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

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

W>Есть вам хочется, чтобы exe'шник сам оптимально подстраивался под конкреныю систему? Причем говорится, что с помощью C++

Небольшое уточнение — не exe'шник, а дистрибутив.

W>компиляторов, такую программу не скомпилировать. Я, конечно, много не знаю, но хочу задать вопрос, а где и каким образом такое вообще можно осуществить. Что бы код, специально не проектированный в расчете на поддержку конкретных платформы, при компиляции неким образом(хотелось бы знать каким, для меня это учень актуально) удовлетворял условию "учитывает специфику платформу (тип процессора, объём памяти и пр.) на которой она будет выполняться".

Именно это, как утверждает Mishka.NET, теоретически возможно в .NET. В том, что это качественно будет реализовано на практике, я сильно сомневаюсь.
Ну а для C/C++ нечто подобное реализуется с незапамятных времен — клиенту поставляется исходный код программы и набор скриптов, который эти исходники компилит. Компилятор поставляется, разумеется, вместе с ОС. Специфика платформы учитывается в основном в конфигурационных скриптах.

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

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

Вот с этого и надо было начинать

.NET тем и отличается, что позволяет это делать. Прога хранится в виде IL (Intermediate Language), а перед выполнением компилируется в native code того процессора, который ты сейчас используешь (вот тебе и оптимизация). Недостаток этого метода — прога стартует слишком медленно.

Ладно, оставим этот спор. Автор вопроса написал, что его интересут не техническая, а эстеттическая сторона дела. Всего хорошего.

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

M.NET>Поток — это stream, а не thread.

Я в курсе. Я это и имел ввиду.

А ты знаешь что такое архитектурный паттерн Pipes and Filters? Он декларирует построение приложений таким образом, чтобы каждое из них имело входной поток и выходной поток (ну, и из-за того, что это на самом деле не идеально, нужен ещё отдельный поток для ошибок). Так вот Windows NT построен на основе другого паттерна — Microkernel. Там нет такого понятия как iostream, оно просто эмулируется (и во всём С++ виноват).

Хм. Помоему они там есть во всяком случае Windows NT
появилось когда Microsoft попыталась сделать windows
совместимым с posix. Правда им это надоело достиаточно быстро.

А микроядро у них появилось на сколько я помню в XP
Win2000 еще не микроядерная.

M.NET>э-э-э ... как бы тебе объяснить... аспекты приложения. Вот в объектно-ориентированном мире есть объекты, а в аспектно-ориентированном к объектам добавляют ещё некие аспекты (например, аспект безопасности, аспект записи в лог и пр.)

Хм. переназванные объекты ядра? Или весь смысл в том что как
раз не ядра?

M.NET>>э-э-э ... как бы тебе объяснить... аспекты приложения. Вот в объектно-ориентированном мире есть объекты, а в аспектно-ориентированном к объектам добавляют ещё некие аспекты (например, аспект безопасности, аспект записи в лог и пр.)

A>Хм. переназванные объекты ядра? Или весь смысл в том что как
A>раз не ядра?

Короче, над тобой издеваются

Нет бы пояснить

Давай я тебе, как полный ламер в этом вопросе, поясню. За неточности не отвечаю

Ты написал объект и он работает в middletier звене каком-то. А другой кто-то (может, MS, а может Вася) написал...хм...как называется-то? аспект? — и теперь есть возможность применения на административном уровне к твоему объекту некоторой функциональности. Админ это может настроить.

Типичные примеры — запись вызовов метода в лог, проверка security (а разрешено ли данному юзеру вызывать этот метод?), поддержка распределенных транзакций и т.п. Много разных фич.

COM+ короче.

Архитектурно реализуется перехваткой обращений к методам объекта, благо там и так прокси разнообразные просто кишат

Ну а в C# есть... даже не в C# а в .NET, пожалуй.. поддержка этого дела. Ты можешь создать объект, а потом заставить другой объект вклиниваться в вызовы методов первого. В "Inside C#" Арчера есть немного об этом.

>Недостаток этого метода — прога стартует слишком медленно.

Для этого есть ngen и кеш нативных имаджей (кажется есть).

M.NET>Никак

Просто NGen был упомянут в противопоставление того, что С++ компилирует программы.

Кстати, об NGen. Как я понял, при работе ngen генерится нативный код, но исходный IL не выкидывается. А почему??? Отпала бы нужда во всяких обфускаторах и других подобных извращениях?

Может, дело в обеспечении целостности сборки, контролируемой цифровой подписью?

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

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

Тут народ в дебри ушел технические

Для меня это:
1. Красивый и лаконичный язык. Классический пример с копированием элементов массива это показывает

2. Язык с шаблонами. Насколько я знаю, их боьлше нет нигде. (Если не прав — поправьте)
3. Универсальное средство для решения почти любых задач. Об этом уже писали.
4. Стандартный язык для выражения идей. Примеры в книгах по проектированию и прочим теоретическим вещам как правило приводятся на С/С++

Вот, ИМХО...

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

S>13. За программирование на С++ мне платят деньги.

Остальные аргумены здесь были явно лишними.

— Старшина! Почему ваша батарея не веле огонь!!!
— Томоу есть несколько причин. Во-первых, кончились снаряды...

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

IT>И .net врядли будет панацеей.

Дык .NET — это не язык. Там можно и на C++, и на C# и на JScript и на Перле с Эфилом, да и на MSIL-е по памяти пройтись без проблем.

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

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

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

Не знаешь в данном случае как раз ты. Да еще и наезжаешь... Так что про этику это тебе нужно читать.

Ты попробуй скомпилировать одну версию для Первого пня, Третьего пня, Атлона и Пня четвертого. Я уже не говорю о разных 64-битных приблудах. Ну, а Интел тут вообще в данном случае не пременим будет. Технологии с джит-компиляциией это позволяют. Жаль что пока что только теоритически. Но MS и Sun-у нужно зарабатывать на жизнь, так что в следующих версиях все это точно воплатится в жизнь.

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

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

Без использования специфичных для процессора инструкций серьезного увеличения скорости добиться нельзя. А специфичные не будет пахать на всех платформах. На сегодня 90% програм компилируется под Первый пень. А он вообще ничего не умел. Джит производит компиляцию прямо на конечной машине и может применять все самые навороченные оптимизации. Об этом Машка и говорил.

PS

Ну, и на счет супер скорости Интеловского компилятора. В основном это плод некорректного сравнения. Самая мощьная оптимизация доступная современным компиляторам — это банальный автоматический инлайнинг функций. Так вот у интела опция -O3 врубает эту фичу. У MS же ее нужно включать отдельно (опцией -Ob2). Так вот большинство тестов где Инетел впереди планеты всей не включали -Ob2 для компиляторов от MS. Интел безспорно хороший оптимизирущий компилятор. Но ДИКО медленный и все же не дающий реальных приимуществ на обыйденных алгоритмах. Ну, а когда его используют для получения кода совместимого с P1, то рекордов там точно не добьешся.

Джиты пока что в зачаточном состоянии. Я почти уверен, что лет черз пять они будут обгонять нэтивные компиляторы в половине задачь.

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

>>Недостаток этого метода — прога стартует слишком медленно.

IT>Для этого есть ngen и кеш нативных имаджей (кажется есть).

Ага. В бете было даже ощютимое ускорение. Жаль тольк к релизу оно исчезло.

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

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

Это одна из фичей. Тебе не нежна другим нужна. Например, можно динамически создать обертку для таблицы БД или ускорить выполнение задачи. Например, регулярные выражения в .NET поддерживаю динамическую герерацию кода. Это позволяет избежать оверхэда накладываемого интерпретацией регэкспов. В общем позволяет заменить интерпретацию компиляцией (но в рантайме и автоматически).

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

Уже месяца два как есть.

Не слышал такого слова "Ротор"? MS (вроде совместно с королом) выделили из .NET независящую от платформы серверную часть и портировала ее под Фришку. Все исходники есть. Портировать это дело под разные Линухи проблем не составит.

S>Например, вот такие конструкции могут сильно облегчить жизнь:

S>

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

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

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

.

Вот из-за этой гибкости обычные люди и избегают Линуксы.

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

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

Тебе уже говорили. Програма записывается на промежуточном языке. Перед выполнением (или при инсталляции) она компилируется в машинный код. При этом известнв все характеристики машины на которм все это будет выполняться.

IT>>И .net врядли будет панацеей.

VD>Дык .NET — это не язык. Там можно и на C++, и на C# и на JScript и на Перле с Эфилом, да и на MSIL-е по памяти пройтись без проблем.

Я говорю, что

а) языка, приятного всем — не придумать
б) .net — отчасти это попытка "примирить" языки за счет объединения на низком уровне.

и говорю, что мне кажется, что проблемы "языковых войн" до конца .net не решит, потому что сам язык приходится менять (см. MC++, VB/NET, Delphi.NET) чтобы он годился в .NET. Хотя, могу ошибаться.

VD>Например, регулярные выражения в .NET поддерживаю динамическую герерацию кода. Это позволяет избежать оверхэда накладываемого интерпретацией регэкспов. В общем позволяет заменить интерпретацию компиляцией (но в рантайме и автоматически).

Вообще да, это клево... Компиляция арифметических выражений, например.
Не так чтобы уж очень часто надо, но зато когда надо — супер! И, ведь, при этом — по идее код компилится достаточно безопасный!

1. На нём пишут много людей. А значит не я один такой, кому этот язык нравится.
2. На нём пишут много умных людей, т.е. есть с кем посоветоваться.
3. На нём можно написать ВСЕ. И неправда, что это так уж сложно.
4. Памятью можно управлять вручную. Это замечательно! Я в любой момент знаю, что НА САМОМ ДЕЛЕ делает моя программа.
5. Объектная ориентированность.
6. Контроль типов во время компиляции, а не выполнения. На языках, подобных BASIC и Perl отсутствие контроля типов часто приводит к головной боли.
7. Windows (по крайней мере начиная с 2000) написана на этом языке. По-моему для программирования в этой операционной системе лучше использовать ее РОДНОЙ язык.
8. Это достаточно низкоуровневый язык. На нем вполне можно писать даже драйверы.
9. На этом языке достаточно легко реализовать какую-нибудь компонентную модель (типа COM). И эти модели успешно существуют уже достаточно давно.

Конечно, у этого языка (как и у других) есть недостатки. Но на мой взгляд преимущества все же перевешивают. Возьмите для сравнения так называемый Object Pascal (на самом деле — Delphi). Нигде в мире, кроме как в Delphi этот язык не используется (насколько я знаю, хотя могу ошибаться). В тоже время язык C++ очень распространен и существует практически на всех платформах.

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

E>7. Windows (по крайней мере начиная с 2000) написана на этом языке. По-моему для программирования в этой операционной системе лучше использовать ее РОДНОЙ язык.

Ничего подобного!!! 2000 в основном написана на C!!! Это официальная информация M$!!!

E>8. Это достаточно низкоуровневый язык. На нем вполне можно писать даже драйверы.

Только не надо палку перегибать... Специальный компилятор.... да.
Но назвать C++ достаточно низкоуровневым??? Это вы хватили. Пообщайся с Стауструпом

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

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

VD>Это одна из фичей. Тебе не нежна другим нужна. Например, можно динамически создать обертку для таблицы БД или ускорить выполнение задачи. Например, регулярные выражения в .NET поддерживаю динамическую герерацию кода. Это позволяет избежать оверхэда накладываемого интерпретацией регэкспов. В общем позволяет заменить интерпретацию компиляцией (но в рантайме и автоматически).

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

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

VD>Уже месяца два как есть. :) Не слышал такого слова "Ротор"? MS (вроде совместно с королом) выделили из .NET независящую от платформы серверную часть и портировала ее под Фришку. Все исходники есть. Портировать это дело под разные Линухи проблем не составит.

И шо, че-нибудь гуевое на нем можно слабать? Под BSD?

S>>Например, вот такие конструкции могут сильно облегчить жизнь:

S>>

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

VD>Нда. Я так понимаю выглядит это так: Человек пытаетя прочесть этот код, свихивается и попадает в психушку. После чего его жизнь становится лехкой и беззаботной. :)

Ты, видимо, тоже перешел в стадию забывания C++? Это всего лишь самый простой способ избежать возни с указателями в случае, если требуется повторная инициализация объекта.

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

VD>Вот из-за этой гибкости обычные люди и избегают Линуксы. :( Ну, и еще эта гибкость приводит к тому что появляются разные COM-ы и CORBA-ы. Мегабайты кода в которых закрывают отсталость языка и пытаются приклеить к нему компонентно-ориентированные посылы.

Как раз философский разговор пошел... Лично меня от компонентного подхода воротит. Но это уже тема для другого топика. Да и гибкость, что плюсовая, что нетовская, обычному человеку не нужна. Потому что даже драйверы для компьютерного железа, равно как и само железо, уже давно принято выдавать на-гора с кучей ошибок. Не говоря уж о компиляторах, библиотеках и прочем софте. А уж если от компилятора еще на порядок больше интеллекта потребуется, чтобы учитывать "пр." характеристики машины, тут такое начнется...
Кстати, насчет отсталости — от чего именно отстал С++? Уместнее говорить об убогости или неполноценности. Беда только в том, что для меня С# ничем его не лучше. Нужен-то (мне, а не MS) кардинально другой язык, а не очередная Java с рюшечками.

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

VD>Тебе уже говорили. Програма записывается на промежуточном языке. Перед выполнением (или при инсталляции) она компилируется в машинный код. При этом известнв все характеристики машины на которм все это будет выполняться.

Вот меня списочек этих характеристик и интересует. Тех, которые могут учитываться при кодогенерации. Исключая количество оперативки и тип процессора. И особенно — как именно они будут учитываться. Поскольку ссылка на какие-то мифические характеристики, которые будут учитываться при компиляции, выглядит как демагогия. Короче говоря, толку от того, что эти характеристики известны (кроме, разве что, типа процессора), не предвидится.

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

IT>Ты написал объект и он работает в middletier звене каком-то. А другой кто-то (может, MS, а может Вася) написал...хм...как называется-то? аспект? — и теперь есть возможность применения на административном уровне к твоему объекту некоторой функциональности. Админ это может настроить.

На самом деле не админ, а программер. Создаём аспект, говорим в нём, что если кто-то, например, вызвал метод с такой сигнатурой, то надо выполнить такой-то код. Или, куда интереснее, если произошло исключение в таких-то методах, то выполнить то-то и то-то. То бишь — один чел пишет прогу не думая об обработке исключений, security и пр. А другие пишут к его коду соответствующие аспекты.

IT>COM+ короче.
COM+ поддерживает только зачатки аспектной ориентации.

IT>Архитектурно реализуется перехваткой обращений к методам объекта, благо там и так прокси разнообразные просто кишат

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

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

IT>Кстати, об NGen. Как я понял, при работе ngen генерится нативный код, но исходный IL не выкидывается. А почему??? Отпала бы нужда во всяких обфускаторах и других подобных извращениях?

IL он должен выкинуть, а вот метаданные должны бы остаться.

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

VD>Уже месяца два как есть.

Не слышал такого слова "Ротор"? MS (вроде совместно с королом) выделили из .NET независящую от платформы серверную часть и портировала ее под Фришку. Все исходники есть. Портировать это дело под разные Линухи проблем не составит.

Адрес-то кинь

А то я тут с местными Java-любителями борюсь, как бы хотелось их всех на C# пересадить...

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

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

E>>7. Windows (по крайней мере начиная с 2000) написана на этом языке. По-моему для программирования в этой операционной системе лучше использовать ее РОДНОЙ язык.

E>Ничего подобного!!! 2000 в основном написана на C!!! Это официальная информация M$!!!

Что-то мне не верится, я не думаю что все эти COM
объекты написаны на C. Там без ATL очень геморойно все
это делается, а COM-ов в Winmdows понастоящему дохрена.

>В "Inside C#" Арчера есть немного об этом.
M.NET>Ну-ка ткни пальцем где такое написано, я это уже давно ищу — не знал что в .NET это есть.

Inside C#, Tom Archer, Andrew Whitechapel, MSPress
Chapter 6. Context Attributes

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

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

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

E>>>7. Windows (по крайней мере начиная с 2000) написана на этом языке. По-моему для программирования в этой операционной системе лучше использовать ее РОДНОЙ язык.

E>>Ничего подобного!!! 2000 в основном написана на C!!! Это официальная информация M$!!!

A>Что-то мне не верится, я не думаю что все эти COM
A>объекты написаны на C. Там без ATL очень геморойно все
A>это делается, а COM-ов в Winmdows понастоящему дохрена.

Я же говорю Основную часть, а не всю!!!

E>>Ничего подобного!!! 2000 в основном написана на C!!! Это официальная информация M$!!!

A>Что-то мне не верится, я не думаю что все эти COM
A>объекты написаны на C. Там без ATL очень геморойно все
A>это делается, а COM-ов в Winmdows понастоящему дохрена.

Дохрена-то дохрена, и, все же, думаю, основной объем кода Win2k — это не COM.

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

M.NET>IL он должен выкинуть, а вот метаданные должны бы остаться.
А вот фигушки, кажется...

S>Ага, а потом сгенерированный код опять интерпретируется. Супер. Никакого оверхеда.

Почему это? Ты сгенерил метод, записал в него IL.
При первом вызове метода он скомпилируется в native, при последующих — уже будет использоваться настоящий native.

S>И шо, че-нибудь гуевое на нем можно слабать? Под BSD?
Есть еще не-MS проект, Mono. www.go-mono.com. Есть GTK#. И вроде как mono + gtk# дают возможность делать кроссплатформенный гуй. Есть уже вроде Qt#. Тоже. В Mono также обещают кроссплатформенный Windows.Forms. В общем, пока энтузиазм у народа есть

Поживем — увидим.

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

IT>Дохрена-то дохрена, и, все же, думаю, основной объем кода Win2k — это не COM.

Сухая статистика: у меня Windows 2000, в папке WINNT\SYSTEM32
1978 файлов с расширением Dll общий объем 306 Mb
Из них 609 файлов содержат внутри функцию DllGetClassObject
т.е. связаны с COM-ом. Их общий объем 145Mb т.е. почти половина.

Еще у меня 69 OCX объемом 16Mb и 48 ax объемом 5 Mb
Уже получается больше половины по объему. Т.е. половина
dll в Windows связана с COM и скорее всего написана на C++.

Плюс к этому непонятное количество остальных dll тоже
написана на C++.

Итак какой мы из этого можем сделать вывод?

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

A>Здравствуйте Igor Trofimov, Вы писали:

IT>>Дохрена-то дохрена, и, все же, думаю, основной объем кода Win2k — это не COM.

A>Сухая статистика: у меня Windows 2000, в папке WINNT\SYSTEM32
A>1978 файлов с расширением Dll общий объем 306 Mb
A>Из них 609 файлов содержат внутри функцию DllGetClassObject
A>т.е. связаны с COM-ом. Их общий объем 145Mb т.е. почти половина.

A>Еще у меня 69 OCX объемом 16Mb и 48 ax объемом 5 Mb
A>Уже получается больше половины по объему. Т.е. половина
A>dll в Windows связана с COM и скорее всего написана на C++.

A>Плюс к этому непонятное количество остальных dll тоже
A>написана на C++.

A>Итак какой мы из этого можем сделать вывод?

WINDOWS MUST DIE

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

S>>Ага, а потом сгенерированный код опять интерпретируется. Супер. Никакого оверхеда.

IT>Почему это? Ты сгенерил метод, записал в него IL.
IT>При первом вызове метода он скомпилируется в native, при последующих — уже будет использоваться настоящий native.

Это верно только для нормальных компов. Карманные native image не хранят из-за недостатка памяти, а компилируют каждый раз.

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

S>>Ага, а потом сгенерированный код опять интерпретируется. Супер. Никакого оверхеда.

IT>Почему это? Ты сгенерил метод, записал в него IL.
IT>При первом вызове метода он скомпилируется в native, при последующих — уже будет использоваться настоящий native.

Ага, при следующем разборе регулярного выражения я запишу поверх него новый код, который опять будет компилироваться в native. Где выигрыш?

S>>И шо, че-нибудь гуевое на нем можно слабать? Под BSD?
IT>Есть еще не-MS проект, Mono. www.go-mono.com. Есть GTK#. И вроде как mono + gtk# дают возможность делать кроссплатформенный гуй. Есть уже вроде Qt#. Тоже. В Mono также обещают кроссплатформенный Windows.Forms. В общем, пока энтузиазм у народа есть ;) Поживем — увидим.

Вопрос был не о наличии подобных проектов, а об их работоспособности, текущей и потенциальной. Энтузиазм ведь имеет тенденцию со временем испаряться :). Ximian одна за MS не успеет, а народ вполне может на mono забить. Кстати, о Qt# я ничего не слышал — оно чье? На сайте trolltech про нее вроде ничего нет.

M.NET>Это верно только для нормальных компов. Карманные native image не хранят из-за недостатка памяти, а компилируют каждый раз.

Ну, а теперь прикинь вероятность сочетания

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

И потом — сейчас не о частных случаях речь, а о принципе.

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

S>Ага, при следующем разборе регулярного выражения я запишу поверх него новый код, который опять будет компилироваться в native. Где выигрыш?

Зачем же записывать поверх новый код для того же выражения?

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

. Ximian одна за MS не успеет, а народ вполне может на mono забить. Кстати, о Qt# я ничего не слышал — оно чье? На сайте trolltech про нее вроде ничего нет.

Сырые все конечно страшно, что тут говорить... Про qt# — ссылка на www.go-mono.com кажется была.

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

E>>7. Windows (по крайней мере начиная с 2000) написана на этом языке. По-моему для программирования в этой операционной системе лучше использовать ее РОДНОЙ язык.

E>Ничего подобного!!! 2000 в основном написана на C!!! Это официальная информация M$!!!

Цитирую Рихтера: "Ядро Windows 2000 написано в основном на С и С++, поэтому система легко портируется (переносится) на процессоры с другими архитектурами."
Если кода на C там больше, чем C++, ну что же... Тогда я неправ. Но все таки C++ там присутствует...

E>>8. Это достаточно низкоуровневый язык. На нем вполне можно писать даже драйверы.

E>Только не надо палку перегибать... Специальный компилятор.... да.
E>Но назвать C++ достаточно низкоуровневым??? Это вы хватили.

Я никого не призываю писать низкоуровневые программы на C++. Я просто говорю, что на С++ это МОЖНО делать. У C++ присутствуют ВСЕ возможности языка C, а именно на C пишутся драйверы для Win2000.

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

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

S>>Ага, при следующем разборе регулярного выражения я запишу поверх него новый код, который опять будет компилироваться в native. Где выигрыш?

IT>Зачем же записывать поверх новый код для того же выражения? :))

Ровно затем же, зачем Влад предлагал его несколько раз парсить на С++ :)

S>>Вопрос был не о наличии подобных проектов, а об их работоспособности, текущей и потенциальной. Энтузиазм ведь имеет тенденцию со временем испаряться :). Ximian одна за MS не успеет, а народ вполне может на mono забить. Кстати, о Qt# я ничего не слышал — оно чье? На сайте trolltech про нее вроде ничего нет.

IT>Сырые все конечно страшно, что тут говорить... Про qt# — ссылка на www.go-mono.com кажется была.

Спасибо, нашел. Тока оно GPL. Нафиг-нафиг такие либы и рантаймы. Я предпочитаю MIT License :)))

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

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

E>>>7. Windows (по крайней мере начиная с 2000) написана на этом языке. По-моему для программирования в этой операционной системе лучше использовать ее РОДНОЙ язык.

E>>Ничего подобного!!! 2000 в основном написана на C!!! Это официальная информация M$!!!

E>Цитирую Рихтера: "Ядро Windows 2000 написано в основном на С и С++, поэтому система легко портируется (переносится) на процессоры с другими архитектурами."

Объясняю второй раз: Рихтер не уточнил...
А вот пишет разработчик:

(Книга "Внутреннее устройство Windows 2000")

В основном ядро Windows было написанно на C....

Небольшая часть на C++
И Ассемблере.

E>>Только не надо палку перегибать... Специальный компилятор.... да.
E>>Но назвать C++ достаточно низкоуровневым??? Это вы хватили.

E>Я никого не призываю писать низкоуровневые программы на C++. Я просто говорю, что на С++ это МОЖНО делать. У C++ присутствуют ВСЕ возможности языка C, а именно на C пишутся драйверы для Win2000.

Объясняю снова (будьте внимательны), я не сказал: "На C++ нельзя писать драйверы", я сказал:
"C++ не есть достаточно низкоуровневым, хотя бы так же как C -- вы не согласны. Это мнение Страугструпа, вропчем не только мнение, а и цель при создании..."

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

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

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

A>Тут народ в дебри ушел технические :maniac:
A>:)

A>Для меня это:
A>1. Красивый и лаконичный язык. Классический пример с копированием элементов массива это показывает ;)
A>2. Язык с шаблонами. Насколько я знаю, их боьлше нет нигде. (Если не прав — поправьте)
A>3. Универсальное средство для решения почти любых задач. Об этом уже писали.
A>4. Стандартный язык для выражения идей. Примеры в книгах по проектированию и прочим теоретическим вещам как правило приводятся на С/С++

A>Вот, ИМХО... :)

1. Есть языки и покрасивей и полаконичней. Но из-за разных причин менее популярные.
2. Шаблоны, на мой взгляд, один из способов ввести полиморфизм в C++. Есть языки с объектами, где не нужно указывать ни типы входных значений, ни определять какие-либо интерфейсы. Все эти операции проделывает компилятор. Например, можно сказать, что у объекта А есть метод М который принимает в качестве параметра некоторый объект С, от которого требуется только, что бы он имел метод DoSomething с такими то аргументами (причем аргументы не обязаны иметь конкретный тип, если методу он не интересен). Компилятор сам вычислит и проверит все нужные типы.

object Ob =
   method Add(a,b) = a.Plus(b);
end

В результате у объекта Ob будет метод Add который принимает две переменных произвольного типа с условием, что у a есть метод Plus(typeof(b)).
3. А зачем нужна универсальность, если драйверы удобно писать на одном языке, а GUI на другом?
4. Я думаю, это из-за того, что С++ самый популярный язык.

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

E>В основном ядро Windows было написанно на C....

E>Небольшая часть на C++
E>И Ассемблере.

Ну почувствуй разницу между утверждениями "ядро Windows в основном написано на C" и своим предыдущим утверждением "Windows в основном написана на C"

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

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

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

VD>Без использования специфичных для процессора инструкций серьезного увеличения скорости добиться нельзя. А специфичные не будет пахать на всех платформах. На сегодня 90% програм компилируется под Первый пень. А он вообще ничего не умел. Джит производит компиляцию прямо на конечной машине и может применять все самые навороченные оптимизации. Об этом Машка и говорил.

JIT это плохо т.к. фактически является самомодифицирующимся кодом который
плохо переносится Windows. В частности это значит что при загрузке
2 копий программы она займет в памяти двойное место, а не одинарное
как с обыкновенным exe.

Впрочем MS обещала уметь конвертировать IL в нативный код при
установке программы, вот это было бы полезно. Кто нибудь из дотнетеров
проясните это уже сделано? И на сколько это популярно?

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

A>В частности это значит что при загрузке
A>2 копий программы она займет в памяти двойное место, а не одинарное
A>как с обыкновенным exe.

Вот это место по-подробнее можно

A>Впрочем MS обещала уметь конвертировать IL в нативный код при
A>установке программы, вот это было бы полезно. Кто нибудь из дотнетеров
A>проясните это уже сделано? И на сколько это популярно?

Есть такая утилита NGen.exe, которая может создать native image. Но, на сколько я знаю, её нужно использовать до того, как программа будет упакована в инсталятор.

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

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

A>>В частности это значит что при загрузке
A>>2 копий программы она займет в памяти двойное место, а не одинарное
A>>как с обыкновенным exe.

M.NET>Вот это место по-подробнее можно

Когда ты запускаешь exe файл то он не загружается в память
а просто отображается с помощью CreateFileMapping т.е.
условно становится частью файла подкачки.

Таким образом
1) Если часть файла не будет нужна, то ее не выкинут в swap
а просто выкинут, а потом подгрузят прямо из exe.(С этим связан
эффект что загруженный exe файл нельзя стереть или изменить)
2) Файл не загружается сразу, а просто отражается на память
и загружается по мере надобности. Т.е. даже если у тебя файл
размером в 100 Mb то загрузится только то что попользовано
(загружается все страницами по 4K)
3) Если ты загрузил 100 копий программы, то образ
exe в памяти на самом деле общий для них всех.

(Все сказанное касается и dll пока их не коснется rebase
который тоже фактически является модификация кода. Не касается модулей
загруженых с сети или сменных носителей. Подробней можно
узнать в Рихтере или статье К.Касперски "Паковать или не паковать"
в одном из журналов "программист")

Но как только приложение начинает изменять свой код, то Windows
уже не может предсказать что получится и выделяет отдельную страницу
памяти(COPY_ON_WRITE) именно поэтому всякие exepacker-ы это
плохо т.к. занимают свою память. Windows не может знать что
у них все равно образ один и тот же, вдруг они из вредности
распаковываются в другой код.

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

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

IT>и говорю, что мне кажется, что проблемы "языковых войн" до конца .net не решит, потому что сам язык приходится менять (см. MC++, VB/NET, Delphi.NET) чтобы он годился в .NET. Хотя, могу ошибаться.

В общем и целом пока что пострадал только один язык — VB. Остальные толко расширены. Тот же MC++ компилирует любые исходники. Можно даже COM лабать.

A>Это касается всего самомодифицирующегося кода, в том числе и
A>JIT компиляторов которые тоже создают код на лету.

Ты уверен, что все устроено именно так в CLR?

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

A>>Это касается всего самомодифицирующегося кода, в том числе и
A>>JIT компиляторов которые тоже создают код на лету.

IT>Ты уверен, что все устроено именно так в CLR?

Нет, но других путей реализации я не вижу.

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

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

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

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

Как всегда бывает во флеймах, сопр тем дальше от сути, чем больше во флейме сообщений :(
Я вот не выдержал и решил сказать... А, ну так вот. Следуя примеру Мишки.НЕТ, сначала скажу за что я
не люблю С++ (да так оно и проще будет :)) ).
А не люблю я его вот за что:

За (местами) довольно корявый синтаксис
За множество случаев, где происходит неявное приведение типов
За то, что в его модели обработки исключений отсутствует конструкция try..finally :))
За его стандартную библиотеку (я не имею ввиду STL)
За его модель организации исходного кода (h, cpp)
За слишком много моментов с undefinite behavior и implementation-dependent
За все то, что не любят в универсальных языках программирования

Большинство этих, на мой взгляд, недостатков обусловлено backward compability, а без него С++ был бы
изначально обречен на провал.Еще больше "недостатков" привносят в язык отдельные его реализации :))

За все остальное лублу я ехо, мать-о так :super:

P.S. Но тем не менее, С++, на мой взгляд, выпоняет роль ОПП-ассемблера и сколько бы у него не было
недостатков, знать его не помашает. :user:

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

A>JIT это плохо т.к. фактически является самомодифицирующимся кодом который
A>плохо переносится Windows.

Я бы уточнил... не Windows а x86-й архитектурой. И не "самомодифицирующимся", а динамически создваваемый. Но по сути ты прав.

A> В частности это значит что при загрузке
A>2 копий программы она займет в памяти двойное место, а не одинарное
A>как с обыкновенным exe.

Когда-то Windows 3.х оптимизировала работу с памятью путем загрузки всего в одно адресное пространство. Память экономилась радикально но любая программа могла положить всю ОС. В NT сделали компромисный вариант и стали разделять только статические модули. Это (на практике) привело к невероятному росту потребленя памяти. Но тут к счастью эта самя память подешевела. В .Net безопастный код можно сново поместить в один процесс. В принципе это может потенциально даже сократить потребление памяти. Вот только жаль что это никому не нужно. Всем нужна в первую очередь скорость, безопастность и простота использования. В .NET все это есть. Ну, а загрузка модулей... Она почти не работала уже в NT. Те кто программирует на VC должны были заметить, что при загрузке почти любого процесса выскакивают сообщения о том что "модуль перемещен...". Это означат, что модуль нельзя разместить в ту точку адресного простраства где его предпологал разместить программист (обычно все на это просто плюют). При этом точно так же как и в .NET для модуля выделяется просраство в динамическом свопфайле и получается копия. Если уж говорить об экономии, то нужно обратить внимание на то, что размер исполняемых модулей обычно несравнимо мал по сравнению с данными приложения, а они по определению должны копироваться. Учитывая все это становится понятно, что на сегодня эканомия на загрузке модулей не стоит свечь.

A>Впрочем MS обещала уметь конвертировать IL в нативный код при
A>установке программы, вот это было бы полезно. Кто нибудь из дотнетеров
A>проясните это уже сделано? И на сколько это популярно?

Так тот самый ngen.exe и АПИ на котором он сделан как раз это и позволяют сделать. Вот толко толку от этого никакого нет. Ускоряется толко закрузка. Траты на поддержание CLR нисравнимы с мизирным выигрышем получаемым от прикомпиляции. К тому же есть еще сообщежение в пользу джита. Если происходит джит нескольких модулей (длл-ек), то джит может (пока что потенциально) делать более полную оптимизацию. Так можно будет делать инлайн-подстановки фуниций из другого модуля и избавляться от позднего совязывания (в смысле вызовов черз указаели) которое в ином случае неизбежно для компонентных архитектур.

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

M.NET>Есть такая утилита NGen.exe, которая может создать native image. Но, на сколько я знаю, её нужно использовать до того, как программа будет упакована в инсталятор.

Нет. Ее, а лоуче АПИ на котором она сделана, нужно использовать в самом инсталляторе. Предкомиляция должна делаться на конечной машине.

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

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

Повторяю... никакого самомодифицирующегося кода в .NET нет. Там есть джит-компилякия. Перед вызовом процедуры она компилируется в код процессора и выполнение происходит так же как это былобы если создать код обычным компилятором.

Оверхед есть. Код же нужно скомпилировать. Но это делается один раз (обычно при старте приложниея). Далее скорость выполнения оптимальная.

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

S>И шо, че-нибудь гуевое на нем можно слабать? Под BSD?

И шо она тебе надо? :))

Интероп есть. Подключай тот же Qt и лабай гуи. Может тебе памятник поставят (нерукотворный). ;)

S>Ты, видимо, тоже перешел в стадию забывания C++? Это всего лишь самый простой способ избежать возни с указателями в случае, если требуется повторная инициализация объекта.

Ну, я бы не стал так сильно экономить и воспользовался бы отдельными хелперами.

S>Как раз философский разговор пошел...

:)

S>Лично меня от компонентного подхода воротит. Но это уже тема для другого топика.

Это точно. Но сразу предупреждаю, заклюют. :)

S> Да и гибкость, что плюсовая, что нетовская, обычному человеку не нужна. Потому что даже драйверы для компьютерного железа, равно как и само железо, уже давно принято выдавать на-гора с кучей ошибок. Не говоря уж о компиляторах, библиотеках и прочем софте. А уж если от компилятора еще на порядок больше интеллекта потребуется, чтобы учитывать "пр." характеристики машины, тут такое начнется...

Вот сразу видно, что ты не понимаешь компонентного подхода. А ведь идея проса — разделяй и властвуй. На оптимизацию джита можно осадить отдельную команду. Качество ее работы можно легко проверить. Зато в конце мы получаем значительное упрощение в создании компиляторов. В бетах .NET шел пример... настоящий компилятор С++. Такого раньше небыло. И возможно стало это именно потому, что компилятор разделен на составляющие. И главную из них (оптимизатор и герератор машинного кода) писать уже не нужно.

S>Кстати, насчет отсталости — от чего именно отстал С++? Уместнее говорить об убогости или неполноценности. Беда только в том, что для меня С# ничем его не лучше. Нужен-то (мне, а не MS) кардинально другой язык, а не очередная Java с рюшечками.

Об недостатках С++ здесь говорилось не мало. Есть и неприятие нового, и отрицание разумного, и консервация проблем. Но вот для меня главное, что С++ совершенно не имеет средств создания компонентных архитектур. Я 7 лет занимался COM-ом и сейчас смело могу сказать, что CLR это лучшая реализация идей СОМ-а из всего что я видел. Причем очень важно, то что теперь можно заниматься программированием задачи, а не вечной наклюпкой объходов и замазок с целью хоть как-то упростить себе жизнь.

S>Вот меня списочек этих характеристик и интересует. Тех, которые могут учитываться при кодогенерации. Исключая количество оперативки и тип процессора.

Забавно... а что тип процессора и объем памяти это жуе не характеристики. Или они не важны? Или чистый компилятор может их учитывать тоже?

S> И особенно — как именно они будут учитываться. Поскольку ссылка на какие-то мифические характеристики, которые будут учитываться при компиляции, выглядит как демагогия. Короче говоря, толку от того, что эти характеристики известны (кроме, разве что, типа процессора), не предвидится.

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

Учитываться могут и тип шины. И количество процессоров в системе. И скорость работы жестких дисков. И скорость сетевых соеденений. Да моло ли чего?

Вопрос в том, что на сегодня это все только планы. Более того в том же .NET есть рад недостатков котрые уменьшают выигрыш. Так отсуствие шаблонов приводит к нунужным виртуальным вызовам и как слествие потере производительности.

Раньше я тоже не верил, что "интерпретаторы" могут паказвать результаты хотябы близкие к компиляторам. Но с появлением джитов, я поменыл свою точку зрения. Тесты показывают, что скорость выполнения кода у того же .NET зачастую выше чем у BCC или VC6. Ну, а если сравнить скрость работы .NET-программы и ее аналога на VB6 (который между прочим позволяет получать полностью компилированные модули) показывает, что современные "интерпретаторы" очень даже ничего.

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

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

VD>>Уже месяца два как есть.

Не слышал такого слова "Ротор"? MS (вроде совместно с королом) выделили из .NET независящую от платформы серверную часть и портировала ее под Фришку. Все исходники есть. Портировать это дело под разные Линухи проблем не составит.

M.NET>Адрес-то кинь

А то я тут с местными Java-любителями борюсь, как бы хотелось их всех на C# пересадить...

Вот RSDN CD #1

Или у производителя http://msdn.microsoft.com/downloads/default.asp?URL=/downloads/sample.asp?url=/msdn-files/027/001/901/msdncompositedoc.xml (~ 11 меговый архив).

Основываясь на мнении товарища Анакрино это на 90% исходники CLR-а.

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

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

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

DS>Как всегда бывает во флеймах, сопр тем дальше от сути, чем больше во флейме сообщений

Я не ожидал, что мой вопрос породит столь бурную дискуссию

Мне просто хотелось узнать, что думает народ по этому поводу. А он превратился в такой флейм

Может ввести какие-нибудь правила на ответы (чтобы они не отклонялись от темы) ?
Или чтобы автор сообщения мог закрыть тему, если там начинают появляться ответы, не относящиеся к теме ...

Господа!

Давайте не будем спорить!

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

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

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

А я его и не люблю и люблю — я с ним (в нём?) работаю.

Изменить его не могу, а потому и принимаю как есть, с достоинствами и недостатками.

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

А на одном языке пусть "разговаривает" процессор, раз железяка и камень!

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

SMS>Я не ожидал, что мой вопрос породит столь бурную дискуссию

SMS>Мне просто хотелось узнать, что думает народ по этому поводу. А он превратился в такой флейм

Да это, повторюсь, обычное явление

SMS>Может ввести какие-нибудь правила на ответы (чтобы они не отклонялись от темы) ?
SMS>Или чтобы автор сообщения мог закрыть тему, если там начинают появляться ответы, не относящиеся к теме ...

Я вот тоже как-то над чем-то подобным думал. Но пришел к выводу, что эту проблему нормальным способом не решить. А не нормальных способов не надо

Тем более, что иногда, хоть спор и уходит в сторону, все женекоторые интересности проскакивают

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

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

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

VD>Повторяю... никакого самомодифицирующегося кода в .NET нет. Там есть джит-компилякия. Перед вызовом процедуры она компилируется в код процессора и выполнение происходит так же как это былобы если создать код обычным компилятором.

VD>Оверхед есть. Код же нужно скомпилировать. Но это делается один раз (обычно при старте приложниея). Далее скорость выполнения оптимальная.

VD>Если тот же регэксп применяется один два раза, то вреямя затрачиваемое на компиляцию может привысит выигрыш от выполнения оптимизированного машинного кода. Но если регэксп нужно применять часто (а это очень типичная ситуация), то выигрыш будет существенный.

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

S>>И шо, че-нибудь гуевое на нем можно слабать? Под BSD?

VD>И шо она тебе надо? :))

Мне вообще-то под Солярку и СКО надо.

VD>Интероп есть. Подключай тот же Qt и лабай гуи. Может тебе памятник поставят (нерукотворный). ;)

Биндинги к Qt писать упаришься. А те, что есть — GPL. Нет уж, нафиг такое счастье.

S>>Ты, видимо, тоже перешел в стадию забывания C++? Это всего лишь самый простой способ избежать возни с указателями в случае, если требуется повторная инициализация объекта.

VD>Ну, я бы не стал так сильно экономить и воспользовался бы отдельными хелперами.

С ними геморроя больше. А так — убил один объект, создал на его месте новый, и никаких тебе указателей — ни умных, ни глупых.

S>>Лично меня от компонентного подхода воротит. Но это уже тема для другого топика.

VD>Это точно. Но сразу предупреждаю, заклюют. :)

Пофигу. Нехай злобствуют.

S>> Да и гибкость, что плюсовая, что нетовская, обычному человеку не нужна. Потому что даже драйверы для компьютерного железа, равно как и само железо, уже давно принято выдавать на-гора с кучей ошибок. Не говоря уж о компиляторах, библиотеках и прочем софте. А уж если от компилятора еще на порядок больше интеллекта потребуется, чтобы учитывать "пр." характеристики машины, тут такое начнется...

VD>Вот сразу видно, что ты не понимаешь компонентного подхода. А ведь идея проса — разделяй и властвуй.

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

VD>На оптимизацию джита можно осадить отдельную команду. Качество ее работы можно легко проверить. Зато в конце мы получаем значительное упрощение в создании компиляторов. В бетах .NET шел пример... настоящий компилятор С++. Такого раньше небыло. И возможно стало это именно потому, что компилятор разделен на составляющие. И главную из них (оптимизатор и герератор машинного кода) писать уже не нужно.

То-то они до сих пор нормальный плюсовый компилятор никак не выпустят :) А насчет отдельного оптимизатора и генератора машинного кода, так это любой фронт-енд С++ -> С так устроен.

S>>Кстати, насчет отсталости — от чего именно отстал С++? Уместнее говорить об убогости или неполноценности. Беда только в том, что для меня С# ничем его не лучше. Нужен-то (мне, а не MS) кардинально другой язык, а не очередная Java с рюшечками.

VD>Об недостатках С++ здесь говорилось не мало. Есть и неприятие нового, и отрицание разумного, и консервация проблем. Но вот для меня главное, что С++ совершенно не имеет средств создания компонентных архитектур.

Компонентные архитектуры — недостижимый в реальных условиях идеал.

VD>Я 7 лет занимался COM-ом и сейчас смело могу сказать, что CLR это лучшая реализация идей СОМ-а из всего что я видел. Причем очень важно, то что теперь можно заниматься программированием задачи, а не вечной наклюпкой объходов и замазок с целью хоть как-то упростить себе жизнь.

COM мне тоже не нравиться :) Вернее, не все в нем нравится. А программированием задачи и так занимаюсь :) На С++ :))

S>>Вот меня списочек этих характеристик и интересует. Тех, которые могут учитываться при кодогенерации. Исключая количество оперативки и тип процессора.

VD>Забавно... а что тип процессора и объем памяти это жуе не характеристики. Или они не важны? Или чистый компилятор может их учитывать тоже?

Не о том спич. Насчет типа процессора и объема памяти просто-напросто никто не спорит.

S>> И особенно — как именно они будут учитываться. Поскольку ссылка на какие-то мифические характеристики, которые будут учитываться при компиляции, выглядит как демагогия. Короче говоря, толку от того, что эти характеристики известны (кроме, разве что, типа процессора), не предвидится.

VD>Может учитываться прорва характеристик. Так даже тип ОС может полиять на так какие алгоритмы применять. Для клиента нужно экономить память и максимально быстро откликаться на запросы, а для сервера напротив — обеспечивать максимальную пакетную производительность.

И ты всерьез полагаешь, что компилятор это может учесть? Причем сделать это лучше (хотя бы не намного хуже), чем программист?

VD>Учитываться могут и тип шины. И количество процессоров в системе. И скорость работы жестких дисков. И скорость сетевых соеденений. Да моло ли чего?

Не смеши :)))

VD>Вопрос в том, что на сегодня это все только планы. Более того в том же .NET есть рад недостатков котрые уменьшают выигрыш. Так отсуствие шаблонов приводит к нунужным виртуальным вызовам и как слествие потере производительности.

VD>Раньше я тоже не верил, что "интерпретаторы" могут паказвать результаты хотябы близкие к компиляторам. Но с появлением джитов, я поменыл свою точку зрения. Тесты показывают, что скорость выполнения кода у того же .NET зачастую выше чем у BCC или VC6. Ну, а если сравнить скрость работы .NET-программы и ее аналога на VB6 (который между прочим позволяет получать полностью компилированные модули) показывает, что современные "интерпретаторы" очень даже ничего.

Это смотря как тесты выбирать.

VD>Через пару лет, когда идеи оптимизации воплотятся в жизнь, думаю компиляторы начнут отставать. Хотя конечно никаких супер-прорывов не будет.

Да нет ни у кого никаких особенных идей по этому поводу, IMHO. А если б и были, что мешает применить их к компиляторам?

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

Ну так. Чего ж тут неясного. И если тебе надо этот регексп применить к каждой строке файла — то лучше сперва его скомпилить!

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

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

IT>Ну так. Чего ж тут неясного. И если тебе надо этот регексп применить к каждой строке файла — то лучше сперва его скомпилить!

Неясно, че там интерпретировать при поиске текста регэкспами, реализованном на C++. Там достаточно построить конечный автомат (один раз для каждого регулярного выражения), и уже им искать. И я сильно сомневаюсь, что эта реализация КА (через таблицу состояний) будет работать медленней, чем код, сгенерированный из генерируемого программой описания КА на С#.

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

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

Именно.

S>Мне вообще-то под Солярку и СКО надо.

Ну, тоды тебе на Яву. Покрайней мере пока. Или можешь сам портнуть. Только я почти уверен, что выигрыш в скорости получаемый на .NET исчезнет, так как из CLI похоже выдрано все что касается оптимизации. :(

S>Биндинги к Qt писать упаришься. А те, что есть — GPL. Нет уж, нафиг такое счастье.

Ну, ты же ведь гипотетически спрашивал. :) Тебе и ответили... можно, но не стоит. Вот COM вот уже 4 года как портирован на юниксы. Что же теперь бежать под Салярку все переписывать? К тому же под писями она почила. :( Любимый тобой СКО тоже чувствует себя погано. Остается Фршишка и Линух. Я бы на метсе ребят из Редмонта тоже бы сделал выбор в пользу Шришьки. :)

S>С ними геморроя больше. А так — убил один объект, создал на его месте новый,

Во-во. Даже такой маленький кусок кода уже трудночитаем. Что же будет в реальном проекте. :(
Нет уж я предпочитаю так:

    CBitmap hbmp1;
    CBitmap hbmp2;
    ...

Если нужно память экономить, то:

    CBitmap hbmp;
    ...
    hbmp.Clear();
    hbmp.Attach(hSomeApiBmp);
    ...

Ну, и т.п.

>и никаких тебе указателей — ни умных, ни глупых.

А хелперы — это просто обертки. Они не обязательно являются умными и указателями. ;)

S>Идея хорошая, только в реальной жизни часто дешевле оказывается всякую мелочевку (и не только) самому писать. Глюкавые компоненты с закрытым кодом — полная лажа. А неглюкавых нет и не будет, пока революции в языках программирования не произойдет.

Да с твом настроем на жизнь не просто жить. :)

Ну, а исходники... Вот как раз .NET тут помог. Базовые мещи можно взять в Роторе (CLI), а остальное... на то есть Анакрино (.NET-ый дизассемблер). Я уже не мало с его помощью проблем решил.

S>То-то они до сих пор нормальный плюсовый компилятор никак не выпустят :)

А ты действительно видил гараздо более быстрые? Тогда глянь нашего шустрика:
http://www.rsdn.ru/article/?devtools/perftest.xml
http://www.rsdn.ru/article/?devtools/perftest2.xml
http://www.rsdn.ru/article/?devtools/perftest3.xml

Особенно забавны тесты Pi и FloatTest2. Там VC7 делает Интела в разы. Причем это очень типичные вичислительные тесты. Еще раз повторяю. Многие кто превозносят Интел просто некорректно проводят тесты. Главная оптимизация по скорости — это инлайнподстановка. Интел делает ее автоматом если включить -O3. Для VC ее нужно включать отдельным ключем (-Ob2). Все выданные мной тесты (где Интел был впереди на белом коне) грешат этой ошибкой. Они обычно вообще не включают дополнительные опции оптимизации кроме -O2 (или -Ox).

S>А насчет отдельного оптимизатора и генератора машинного кода, так это любой фронт-енд С++ -> С так устроен.

Не совсем так. На сколько я занаю толко VC7 кладет в объектники промежуточный код. Остальные помещают туда обычный машинный код. Так что логическое разделение может у них и есть, но физического нет точно. К тому же каждый компилятор на сегодня имеет свой опитизатор и кодогенератор. А тут предлагется сделать эти часть стандартными. Причем теперь даже жалкие JScript и VBS будут пользоваться всеми его приемуществами.

Вот, к примеру, представь... живет фанат перла... любит он этот перл до... но скорость ему перловая не нарвится. Если ждать пока создатели перла создадут компилятор и доведут его до ума, то можео и состариться, а так берем джит пишим простенький генератор MSIL-а и... и получаем производительность сравнимую с C#.

S>Компонентные архитектуры — недостижимый в реальных условиях идеал.

Да? А мы как-то ими пользуемся. :-\ В .NET любой класс по определению компонент. Да и COM-мом пользоваться можно. Хоть и тяжело...

S>COM мне тоже не нравиться :) Вернее, не все в нем нравится. А программированием задачи и так занимаюсь :) На С++ :))

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

S>Не о том спич. Насчет типа процессора и объема памяти просто-напросто никто не спорит.

Вот я тебя и спрашиваю. Что мало того что это будет учитываться? Сейчас то программы расчитаны на среднюю температуру по больнице. :)

S>И ты всерьез полагаешь, что компилятор это может учесть? Причем сделать это лучше (хотя бы не намного хуже), чем программист?

Дык его тоже прогаммист пишит. К тому же некоторые оптимизации в .NET и Яве уже есть. Та же многопроцессорность уже обрабатывается по разному. И менеджер память назный.

VD>>Учитываться могут и тип шины. И количество процессоров в системе. И скорость работы жестких дисков. И скорость сетевых соеденений. Да моло ли чего?

S>Не смеши :)))

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

S>Это смотря как тесты выбирать.

А тут ка не выбирай. Теоритические приемущества есть. На практике отставание минимельно. Еще лет пять и теория будет давать диведенты. Ты думаешь почему MS и Sun так драться начали?

VD>>Через пару лет, когда идеи оптимизации воплотятся в жизнь, думаю компиляторы начнут отставать. Хотя конечно никаких супер-прорывов не будет.

S>Да нет ни у кого никаких особенных идей по этому поводу, IMHO. А если б и были, что мешает применить их к компиляторам?

Извени. Я забыл букмарк в начале своих слов постивить. Ну, ты это... того... прочти их еще раз. Думаю ответ я давал раза 4. :)

Короче, дурака не включай. Сам понимаешь что мешает, что что процессоров очень много и то что компоненты (ну хоть те же длл-ки) оптимизироваться могут только в пределах одного проекта. К тому же кто тебе сказал что не применяются? В том же VC7 есть такая опция "Глобал оптимизэйшон". Так вот она пишит в объектники не машинный код, а язык а-ля MSIL. А кодогенерацией занимается линкер.

Просто динамическая оптимизация это еще большая задача чем обычная. Ну, да у MS, Sun и IBM на нее деньги должны найтись. :) Пущай мучаются...

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

IT>Ну так. Чего ж тут неясного. И если тебе надо этот регексп применить к каждой строке файла — то лучше сперва его скомпилить!

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

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

S>Неясно, че там интерпретировать при поиске текста регэкспами, реализованном на C++. Там достаточно построить конечный автомат (один раз для каждого регулярного выражения), и уже им искать. И я сильно сомневаюсь, что эта реализация КА (через таблицу состояний) будет работать медленней, чем код, сгенерированный из генерируемого программой описания КА на С#.

Ну, тогда попробуй написать на С++ обычный if. Но так чтобы он лбые выражения мог обработать.

У тебя выйдет огроменный и тормозной код. А ведь можно примерно так:

if(SearchElem.Type == Str)
  Compiler.Gen("if(strcmp(SearchElem, xxx) >= 0) ...)");
else if(SearchElem.Type == Int)
  Compiler.Gen("if(SearchElem >= xxx) ...)");
...
Compiler.Exec();

И никакого полиморфизма и никаких тормозов.

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

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

Вот, посмотри. ;)

http://www.rsdn.ru/forum/message.asp?mid=83138&only

Здравствуйте Максимов Андрей, Вы писали:

A>>Итак какой мы из этого можем сделать вывод?

МА>WINDOWS MUST DIE

Я плакаль

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

VD>В общем и целом пока что пострадал только один язык — VB. Остальные толко расширены. Тот же MC++ компилирует любые исходники. Можно даже COM лабать.

VB тоже не пострадал, он переродился. Помнишь сказку про Иванушку-дурачка? Куда он там, в котёл с кипятком нырял? А вынырнул царевичем

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

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

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

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

Поздно оправдываться. Ты породил очередную Holy War.

От себя скажу — C++ rules forever, C# rules forever сразу после C++.

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

IT>От себя скажу — C++ rules forever, C# rules forever сразу после C++.

Сразу после C++ это по времени? Тогда когда оно начнется если C++ будет
рулить 'forever'

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

S>>Мне вообще-то под Солярку и СКО надо.

VD>Ну, тоды тебе на Яву. Покрайней мере пока. Или можешь сам портнуть. Только я почти уверен, что выигрыш в скорости получаемый на .NET исчезнет, так как из CLI похоже выдрано все что касается оптимизации. :(

Не, мне тоды на C++ :)

S>>Биндинги к Qt писать упаришься. А те, что есть — GPL. Нет уж, нафиг такое счастье.

VD>Ну, ты же ведь гипотетически спрашивал. :) Тебе и ответили... можно, но не стоит. Вот COM вот уже 4 года как портирован на юниксы. Что же теперь бежать под Салярку все переписывать? К тому же под писями она почила. :( Любимый тобой СКО тоже чувствует себя погано. Остается Фршишка и Линух. Я бы на метсе ребят из Редмонта тоже бы сделал выбор в пользу Шришьки. :)

Сдохла или нет, а у потенциальных (и очень жирных) клиентов оно стоит и еще долго проживет. Соляру под писи саны, кстати, вроде передумали бросать.

S>>С ними геморроя больше. А так — убил один объект, создал на его месте новый,

VD>Во-во. Даже такой маленький кусок кода уже трудночитаем. Что же будет в реальном проекте. :(

Это дело привычки. Тебе — трудночитаем, мне — нет.

VD>Нет уж я предпочитаю так:

VD>

VD>    CBitmap hbmp1;
VD>    CBitmap hbmp2;
VD>    ...
VD>

А потом разбирайся, какую битмапу использовать. Нафиг.

VD>Если нужно память экономить, то:
VD>

VD>    CBitmap hbmp;
VD>    ...
VD>    hbmp.Clear();
VD>    hbmp.Attach(hSomeApiBmp);
VD>    ...
VD>

Злые разработчики библиотеки забыли приделать к классу wxBitmap (а это был он) функцию Clear(). На самом деле, такие ситуации очень часто встречается.

>>и никаких тебе указателей — ни умных, ни глупых.

VD>А хелперы — это просто обертки. Они не обязательно являются умными и указателями. ;)

Вот тут поподробнее — как они мне без указателей один объект грохнут и другой создадут? И нафиг вообще нужны? Их же самому писать придется, вместо двух строчек кода...

S>>Идея хорошая, только в реальной жизни часто дешевле оказывается всякую мелочевку (и не только) самому писать. Глюкавые компоненты с закрытым кодом — полная лажа. А неглюкавых нет и не будет, пока революции в языках программирования не произойдет.

VD>Да с твом настроем на жизнь не просто жить. :)

VD>Ну, а исходники... Вот как раз .NET тут помог. Базовые мещи можно взять в Роторе (CLI), а остальное... на то есть Анакрино (.NET-ый дизассемблер). Я уже не мало с его помощью проблем решил.

S>>То-то они до сих пор нормальный плюсовый компилятор никак не выпустят :)

VD>А ты действительно видил гараздо более быстрые? Тогда глянь нашего шустрика:
VD>http://www.rsdn.ru/article/?devtools/perftest.xml
VD>http://www.rsdn.ru/article/?devtools/perftest2.xml
VD>http://www.rsdn.ru/article/?devtools/perftest3.xml

Там не отмечен один факт — VC 6/7 не является полноценным компилятором C++ :)

VD>Особенно забавны тесты Pi и FloatTest2. Там VC7 делает Интела в разы. Причем это очень типичные вичислительные тесты. Еще раз повторяю. Многие кто превозносят Интел просто некорректно проводят тесты. Главная оптимизация по скорости — это инлайнподстановка. Интел делает ее автоматом если включить -O3. Для VC ее нужно включать отдельным ключем (-Ob2). Все выданные мной тесты (где Интел был впереди на белом коне) грешат этой ошибкой. Они обычно вообще не включают дополнительные опции оптимизации кроме -O2 (или -Ox).

Что-то вы там с интелом нашаманили. Я, помнится, в вашем "шустрике" одну ошибку нашел — че, следующую искать?

S>>А насчет отдельного оптимизатора и генератора машинного кода, так это любой фронт-енд С++ -> С так устроен.

VD>Не совсем так. На сколько я занаю толко VC7 кладет в объектники промежуточный код. Остальные помещают туда обычный машинный код. Так что логическое разделение может у них и есть, но физического нет точно. К тому же каждый компилятор на сегодня имеет свой опитизатор и кодогенератор. А тут предлагется сделать эти часть стандартными. Причем теперь даже жалкие JScript и VBS будут пользоваться всеми его приемуществами.

Front-end'ы для C++ обычно генерируют сишный код. А дальше можешь компилировать его своим любимым оптимизирующим компилятором C. Можешь даже клиенту в таком виде поставлять, чтоб он на target-системе все сам скомпилировал — украсть куски из него будет не намного проще, чем из MSIL'а.

VD>Вот, к примеру, представь... живет фанат перла... любит он этот перл до... но скорость ему перловая не нарвится. Если ждать пока создатели перла создадут компилятор и доведут его до ума, то можео и состариться, а так берем джит пишим простенький генератор MSIL-а и... и получаем производительность сравнимую с C#.

S>>Компонентные архитектуры — недостижимый в реальных условиях идеал.

VD>Да? А мы как-то ими пользуемся. :-\ В .NET любой класс по определению компонент. Да и COM-мом пользоваться можно. Хоть и тяжело...

С трудом, наверное, пользуетесь. Чужими компонентами, по крайней мере. Иначе с чего вдруг свой контейнер писать стали — чужих мало, что ли?

S>>COM мне тоже не нравиться :) Вернее, не все в нем нравится. А программированием задачи и так занимаюсь :) На С++ :))

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

Само собой, но в основном они дают повышенную падучесть :) Опять же, что называть компонентными технологиями? Вот плагины к FAR'у — это компоненты или нет?

S>>Не о том спич. Насчет типа процессора и объема памяти просто-напросто никто не спорит.

VD>Вот я тебя и спрашиваю. Что мало того что это будет учитываться? Сейчас то программы расчитаны на среднюю температуру по больнице. :)

Скажем так, большинство программ, но не все. Тот же 3D Studio MAX учитывает и объем памяти, и тип процессора.

S>>И ты всерьез полагаешь, что компилятор это может учесть? Причем сделать это лучше (хотя бы не намного хуже), чем программист?

VD>Дык его тоже прогаммист пишит. К тому же некоторые оптимизации в .NET и Яве уже есть. Та же многопроцессорность уже обрабатывается по разному. И менеджер память назный.

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

VD>>>Учитываться могут и тип шины. И количество процессоров в системе. И скорость работы жестких дисков. И скорость сетевых соеденений. Да моло ли чего?

S>>Не смеши :)))

VD>Ну, ну. Вот как по-твоему если компонент хочет сделать вызов по сети, то для диалапа и для 100 мб эзернета код должен быть одинаковый? Даже сейчас народ вынесет такой код в отдельную длл-ку и сделает две реализации. Ну, а динамическая архитектура позволяет сделать этот процесс бедее гибким и безшевным.

Не отклоняйся от темы:) Речь шла о том, что компилятор сам (не) сможет сгенерировать из одного и того же исходника разный код для диалапа и эзернета.

S>>Это смотря как тесты выбирать.

VD>А тут ка не выбирай. Теоритические приемущества есть. На практике отставание минимельно. Еще лет пять и теория будет давать диведенты. Ты думаешь почему MS и Sun так драться начали?

Они по жизни драчливые :) Лет семь уже деруться — есть что делить, однако. А если все с джитами и нетами хорошо будет, так я на них и ругаться перестану.

VD>>>Через пару лет, когда идеи оптимизации воплотятся в жизнь, думаю компиляторы начнут отставать. Хотя конечно никаких супер-прорывов не будет.

S>>Да нет ни у кого никаких особенных идей по этому поводу, IMHO. А если б и были, что мешает применить их к компиляторам?

VD>Извени. Я забыл букмарк в начале своих слов постивить. Ну, ты это... того... прочти их еще раз. Думаю ответ я давал раза 4. :)

VD>Короче, дурака не включай. Сам понимаешь что мешает, что что процессоров очень много и то что компоненты (ну хоть те же длл-ки) оптимизироваться могут только в пределах одного проекта. К тому же кто тебе сказал что не применяются? В том же VC7 есть такая опция "Глобал оптимизэйшон". Так вот она пишит в объектники не машинный код, а язык а-ля MSIL. А кодогенерацией занимается линкер.

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

VD>Просто динамическая оптимизация это еще большая задача чем обычная. Ну, да у MS, Sun и IBM на нее деньги должны найтись. :) Пущай мучаются...

Динамическая — это когда? В рантайме? А она что, бесплатная?

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

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

S>>Неясно, че там интерпретировать при поиске текста регэкспами, реализованном на C++. Там достаточно построить конечный автомат (один раз для каждого регулярного выражения), и уже им искать. И я сильно сомневаюсь, что эта реализация КА (через таблицу состояний) будет работать медленней, чем код, сгенерированный из генерируемого программой описания КА на С#.

VD>Ну, тогда попробуй написать на С++ обычный if. Но так чтобы он лбые выражения мог обработать. :)

VD>У тебя выйдет огроменный и тормозной код. А ведь можно примерно так:
VD>

VD>if(SearchElem.Type == Str)
VD>  Compiler.Gen("if(strcmp(SearchElem, xxx) >= 0) ...)");
VD>else if(SearchElem.Type == Int)
VD>  Compiler.Gen("if(SearchElem >= xxx) ...)");
VD>...
VD>Compiler.Exec();
VD>

VD>И никакого полиморфизма и никаких тормозов.

Я когда-то делал примерно так:

for ( ; cur_char != '\0' && state != state_missing && state != state_found; ++cur_char)
    state = statearray[state][cur_char];

Основные затраты — на построение графа переходов КА (statearray), выполняемое при разборе выражения.

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

S>Я когда-то делал примерно так:

S>

S>for ( ; cur_char != '\0' && state != state_missing && state != state_found; ++cur_char)
S>    state = statearray[state][cur_char];
S>

S>Основные затраты — на построение графа переходов КА (statearray), выполняемое при разборе выражения.

С Юникодом такая халява не покатит. Не заводить же полупустой Array на все 60k символов. Зато можно сгенерировать прямолинейный код с чем-нибудь типа if 'a' <= ch <= 'z' goto STATE_123;

S>>Я когда-то делал примерно так:

S>>

S>>for ( ; cur_char != '\0' && state != state_missing && state != state_found; ++cur_char)
S>>    state = statearray[state][cur_char];
S>>

S>>Основные затраты — на построение графа переходов КА (statearray), выполняемое при разборе выражения.

А>С Юникодом такая халява не покатит. Не заводить же полупустой Array на все 60k символов. Зато можно сгенерировать прямолинейный код с чем-нибудь типа if 'a' <= ch <= 'z' goto STATE_123;

Я думал, идею я ясно показал. Эта конструкция тоже тривиально реализуется без ран-тайм кодогенерации, например, так:

int i;
for (i = 0; i < intervals_size; ++i)
{
    if (interval[i].min <= cur_char && cur_char <= interval[i].max)
         break;
}
state = statearray[state][i];

Разреженный массив можно и другими способами реализовать, было бы желание. Можно и готовую библиотеку найти, при необходимости. В этом примере statearray тоже, кстати, можно сделать разреженным — у него довольно-таки регулярная структура.

PS:
А вот Бойер-Мур-Хоршпул для юникода вроде сильно извратный должен получиться.

Руками можно все, что угодно реализовать, но
1) Если ты заранее реализуешь RegExp, который тебе нужен, — зачем мучаться пусть его код сгенерирует программа.
2) Если ты задаешь его во время исполнения, то какая разница генерируется код или автомат тем более, что у тебя есть возможность выбора между этими возможностями.
Т.е. генерация кода явно не мешает, а в некоторых случаях может быть более выгодной. Вообще, генерация кода on-line открывает такие возможности, что я бы MSIL выучил только за то ... И рег. выражения только частный случай. Представь, что клиент сначала передает формат в котором будет посылать данные, сервер генерирует эффективный парсер и спокойно забирает данные.

Здравствуйте Аноним, Вы писали:

А>Руками можно все, что угодно реализовать, но
А>1) Если ты заранее реализуешь RegExp, который тебе нужен, — зачем мучаться пусть его код сгенерирует программа.

Никто и не собирается мучаться, есть же boost::regex :)

А>2) Если ты задаешь его во время исполнения, то какая разница генерируется код или автомат тем более, что у тебя есть возможность выбора между этими возможностями.

Вот я и говорю — разницы никакой, для регулярных выражений кодогенерация нафиг не нужна.

А>Т.е. генерация кода явно не мешает, а в некоторых случаях может быть более выгодной. Вообще, генерация кода on-line открывает такие возможности, что я бы MSIL выучил только за то ...

Дополнительные возможности редко мешают :) А для рантаймовой генерации кода, буде такая необходимость возникнет, мне хватает ассемблера x86.

А>И рег. выражения только частный случай.

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

А>Представь, что клиент сначала передает формат в котором будет посылать данные, сервер генерирует эффективный парсер и спокойно забирает данные.

Представил. Это примерно из той же категории, что и робот-гитарист Вертер:) Ты хоть раз парсер писал? А генератор парсеров? А кто в клиенте будет на ходу придумывать формат и генерировать для него грамматику? И, самый главный вопрос — зачем?

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

S>Представил. Это примерно из той же категории, что и робот-гитарист Вертер:) Ты хоть раз парсер писал? А генератор парсеров? А кто в клиенте будет на ходу придумывать формат и генерировать для него грамматику? И, самый главный вопрос — зачем?

Да писал. Грамматику незачем генерировать. Клиент может поддерживать лишь часть ее. Кроме того, что такого в том, что клиент придумывает формат? Вполне можно написать, хотя, согласен, не просто, генератор парсеров по заданной грамматике из потока в дерево разбора. Тогда, например, можно будет легко написать свой интерпретатор простенького языка, не заморачиваясь с yaccами и lexами.

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

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

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

IT>>>И .net врядли будет панацеей.

VD>>Дык .NET — это не язык. Там можно и на C++, и на C# и на JScript и на Перле с Эфилом, да и на MSIL-е по памяти пройтись без проблем. ;)

IT>Я говорю, что

IT>а) языка, приятного всем — не придумать
IT>б) .net — отчасти это попытка "примирить" языки за счет объединения на низком уровне.

ИМХО, больше похоже на попытку причесать все языки под одну гребёнку .NET :maniac:

IT>и говорю, что мне кажется, что проблемы "языковых войн" до конца .net не решит, потому что сам язык приходится менять (см. MC++, VB/NET, Delphi.NET) чтобы он годился в .NET. Хотя, могу ошибаться.

Вот-вот :crash:

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

VD>Так тот самый ngen.exe и АПИ на котором он сделан как раз это и позволяют сделать. Вот толко толку от этого никакого нет. Ускоряется толко закрузка. Траты на поддержание CLR нисравнимы с мизирным выигрышем получаемым от прикомпиляции. К тому же есть еще сообщежение в пользу джита. Если происходит джит нескольких модулей (длл-ек), то джит может (пока что потенциально) делать более полную оптимизацию. Так можно будет делать инлайн-подстановки фуниций из другого модуля и избавляться от позднего совязывания (в смысле вызовов черз указаели) которое в ином случае неизбежно для компонентных архитектур.

Свежо предание... По идее, такую подстановку можно делать только при уверенности, что модуль, откуда инлайнирована функция, — никогда не будет заменён. А как эту уверенность создать?

Здравствуйте Аноним, Вы писали:

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

S>>Представил. Это примерно из той же категории, что и робот-гитарист Вертер:) Ты хоть раз парсер писал? А генератор парсеров? А кто в клиенте будет на ходу придумывать формат и генерировать для него грамматику? И, самый главный вопрос — зачем?

А>Да писал. Грамматику незачем генерировать. Клиент может поддерживать лишь часть ее. Кроме того, что такого в том, что клиент

Правильно, незачем. И парсер для этой грамматики незачем генерировать. И вообще это — полный бред.

А>придумывает формат? Вполне можно написать, хотя, согласен, не просто, генератор парсеров по заданной грамматике из потока в дерево разбора. Тогда, например, можно будет легко написать свой интерпретатор простенького языка, не заморачиваясь с yaccами и lexами.

Ты не ответил на главный вопрос — зачем это делать, если это решается гораздее более простыми средствами?

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

Бред. Что мешает в C++ программах делать самомодифицирующиеся ассемблерные вставки?

А>PS. Прошу заметить, что меня абсолютно не интересует, возможно ли реальное примение этих возможностей в коммерческих проектах. Лично мне они нравятся и я буду применять их в личных целях.

Вирусы писать, не иначе :)

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

[...]

S>>>Лично меня от компонентного подхода воротит. Но это уже тема для другого топика.

VD>>Это точно. Но сразу предупреждаю, заклюют.

S>Пофигу. Нехай злобствуют.

Поддерживаю.

Во первых речь идет не столько о самомодификации, сколько о генерации кода. На С++ все, что можно сделать, это сгенерировать программу на нем же или другом языке и скомпилировать (вариант компиляции сразу в машинный код слишком сложный и требует непотребного количества времени). Но не у всех есть компиляторы, да и не факт, что твоя программа скомпилируется без всяких вопросов (вдруг нет каких-то библиотек или еще чего). .NET предлагает хорошую альтернативу в самом себе.
Про простые средства я не понял. Чего может быть проще, чем написать БНФ + немного информации для lexer'а и скормить это программе, которая выдаст тебе компилятор из исходного файла в дерево. Если использовать yacc, lex выйдет сложнее, а если писать руками, то и говорить нечего. Конечно, этот пример довольно специальный, но можно предположить, например, что пользователь делает что-нибудь в GUI (модель нейронной сети, например), а программа затем генерирует код для обучения и выполнения конкретно этой нейронной сети.
>>Бред. Что мешает в C++ программах делать самомодифицирующиеся ассемблерные вставки?
Мешает то, что большую подпрограмму так не напишешь, а автоматически генерировать ассемблер гораздо сложнее, чем MSIL, кроме того, при этом лишаешься оптимизации (и может быть переносимости), проверки типов и т.п.

Здравствуйте Аноним, Вы писали:

А>Во первых речь идет не столько о самомодификации, сколько о генерации кода. На С++ все, что можно сделать, это сгенерировать программу на нем же или другом языке и скомпилировать (вариант компиляции сразу в машинный код слишком сложный и требует непотребного количества времени). Но не у всех есть компиляторы, да и не факт, что твоя программа скомпилируется без всяких вопросов (вдруг нет каких-то библиотек или еще чего). .NET предлагает хорошую альтернативу в самом себе.
А>Про простые средства я не понял. Чего может быть проще, чем написать БНФ + немного информации для lexer'а и скормить это программе, которая выдаст тебе компилятор из исходного файла в дерево.

Но ведь это можно и "на ходу" из примитивов строить.

А> Если использовать yacc, lex выйдет сложнее, а если писать руками, то и говорить нечего. Конечно, этот пример довольно специальный, но можно предположить, например, что пользователь делает что-нибудь в GUI (модель нейронной сети, например), а программа затем генерирует код для обучения и выполнения конкретно этой нейронной сети.

Мммм... А не утонешь с необходимым тестированием/доказательством корректности генератора? ИМХО, на примитивах всё же чуть надежнее выйдет. Ну а далее дерево примитивов — хошь в C, хошь в C++, хошь в Pascal...

>>>Бред. Что мешает в C++ программах делать самомодифицирующиеся ассемблерные вставки?
А>Мешает то, что большую подпрограмму так не напишешь, а автоматически генерировать ассемблер гораздо сложнее, чем MSIL, кроме того, при этом лишаешься оптимизации (и может быть переносимости), проверки типов и т.п.

Дык! Если тебе контроль типов на самом нижнем уровне нужен, так это означает, что наверху куча ошибок заложена. ИМХО — неправильно это.

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

S>Соляру под писи саны, кстати, вроде передумали бросать.

Хорошо если так.

S>А потом разбирайся, какую битмапу использовать. Нафиг.

Я обычно разбираюсь сначало.

S>Злые разработчики библиотеки забыли приделать к классу wxBitmap (а это был он) функцию Clear(). На самом деле, такие ситуации очень часто встречается.

Ты случаем на VB или Дельфи не переписал? Забыли не забыли... добавь и живи спокойно дальше.

VD>>А хелперы — это просто обертки. Они не обязательно являются умными и указателями.

S>Вот тут поподробнее — как они мне без указателей один объект грохнут и другой создадут? И нафиг вообще нужны? Их же самому писать придется, вместо двух строчек кода...

Они обычно используется для временных объектов. Их время жизни определяет время жизни обертываемого объекта. Ну, а если нужно порулить вручную, то для этого и делают разные Attach-и, Detach-и и Clear-ы.

S>Там не отмечен один факт — VC 6/7 не является полноценным компилятором C++

Ну, это уже демогогия. Тебе шашечки или ехать? Этот компилятор один из самых популярных. 99% созданного кода на нем компилируется.

S>Что-то вы там с интелом нашаманили. Я, помнится, в вашем "шустрике" одну ошибку нашел — че,

Вот эта ошибка и давала Интелу приимущество. Как поправили, он сразу из лидеров вышел.

S>следующую искать?

Ищи хуже не будет.

У нас нет задачи кого-то выгородить.

S>Front-end'ы для C++ обычно генерируют сишный код. А дальше можешь компилировать его своим любимым оптимизирующим компилятором C. Можешь даже клиенту в таком виде поставлять, чтоб он на target-системе все сам скомпилировал — украсть куски из него будет не намного проще, чем из MSIL'а.

Так из мсила как раз украсть все очень легко. Там такое тайпинфо...

VD>>Да? А мы как-то ими пользуемся.

В .NET любой класс по определению компонент. Да и COM-мом пользоваться можно. Хоть и тяжело...

S>С трудом, наверное, пользуетесь. Чужими компонентами, по крайней мере. Иначе с чего вдруг свой контейнер писать стали — чужих мало, что ли?

Да в то время не дофига было. Да и сейчас нормальные можно по палцам счесть. Ну, а компонентами чужими пользуемся. Не все же с нуля писать. Попробуй например на досуге web-броузер написать... а ведь в виде ActiveX-а его подцепить ничего не стоит. Ну, или тот же сриптинг...

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

S>Само собой, но в основном они дают повышенную падучесть

Опять же, что называть компонентными технологиями? Вот плагины к FAR'у — это компоненты или нет?

Ты случам не с Салярки пишешь? Вот и мне кажется из IE запушенного под одной из версий Виндов. Так вот они почти полностью из компонентов состоят. И как видишь живут. Про падучесть это форменный предрассудок. Программы падают из-за ошибок, а не из-за применения тех или иных программных парадигм.

S>Скажем так, большинство программ, но не все. Тот же 3D Studio MAX учитывает и объем памяти, и тип процессора.

Видимо по этому это он медленнее всех рендерит конечные сцены.

Если он что-то и учитывает, то это реализовано на компонентной основе. Это конечно лучше чем ничего, но по сравнению с полной оптимизацией все же не так здорово.

S>Многопроцессорность тривиально обрабатывается и в программах на C++.

Можешь назвать хотябы 3 штуки? И не рендереры. Я лично знаю, только SQL-серверы, да и то только Oracle, MS и почивший Informix. Тут же речь идет, о том что от второго процессора могут начать выигрывать большинство программ.

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

Дык потоки — это часть того же .NET и Явы. Так что они довольно много знают. Достаточно, чтобы распаралеллить многие вычисления. Представь, при инсталяции на конкретную систему му узаем что есть четыре процесора... мы копилируем код системных библиотек так, чтобы они параллелили все что получится для этих четырех камней. На системе с двумя камнями параллелим для двух. Ну, а если процессор один, то выкидываем лишний код. На системе без процессора включаем совтвэа-эмулейшон.

VD>>Ну, ну. Вот как по-твоему если компонент хочет сделать вызов по сети, то для диалапа и для 100 мб эзернета код должен быть одинаковый? Даже сейчас народ вынесет такой код в отдельную длл-ку и сделает две реализации. Ну, а динамическая архитектура позволяет сделать этот процесс бедее гибким и безшевным.

S>Не отклоняйся от темы

Речь шла о том, что компилятор сам (не) сможет сгенерировать из одного и того же исходника разный код для диалапа и эзернета.

Дык комиляторы тоже люди делают, к тому же мне пофигу почему что-то будет работать бысрее. Мне нужен результат, ну, а то что он получин на подставах и домашних заготовках, меня не интересует. Главное, что в средах типа .NET такие оптимизации можно сделать, а в компиляруемых все нужно будет делать самому.

VD>>А тут ка не выбирай. Теоритические приемущества есть. На практике отставание минимельно. Еще лет пять и теория будет давать диведенты. Ты думаешь почему MS и Sun так драться начали?

S>Они по жизни драчливые

Ошибаешься они дерутся только за деньги. Причем исглючительно за большие.

S> Лет семь уже деруться — есть что делить, однако. А если все с джитами и нетами хорошо будет, так я на них и ругаться перестану.

Дык с ними уже и сейчас все не так плохо. Я вот перестал.

VD>>Короче, дурака не включай. Сам понимаешь что мешает, что что процессоров очень много и то что компоненты (ну хоть те же длл-ки) оптимизироваться могут только в пределах одного проекта. К тому же кто тебе сказал что не применяются? В том же VC7 есть такая опция "Глобал оптимизэйшон". Так вот она пишит в объектники не машинный код, а язык а-ля MSIL. А кодогенерацией занимается линкер.

S>Да мне по барабану, кто там кодогенерацией занимается и какое внутренне представление данных использует связка компилятор+линкер.

Ты спросил "почему такие технологии в компиляторах не используют?". Я ответил что пытаются...

S> Если же кодогенератор у них общий, с какого перепугу джит обгонит машинный код?

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

S> А начсет DLL'к под разные процы, так это уже есть.

Есть. Кто же спорит. Только мола (задача то не тривиальная) и оптимизируется только чать кода. А тут можно оптимизировать весь. Что же тут плохого?

VD>>Просто динамическая оптимизация это еще большая задача чем обычная. Ну, да у MS, Sun и IBM на нее деньги должны найтись.

Пущай мучаются...

S>Динамическая — это когда? В рантайме?

Да. Джит работает сразу после запуска приложения.

S> А она что, бесплатная?

Кто она? Оптимизатор входит в рантаймподсистему .NET и Явы...

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

S>Основные затраты — на построение графа переходов КА (statearray), выполняемое при разборе выражения.

А если создаь код, то разбирать нужно будет намного меньше. Ты серьезно чститаешь что сособен создать интерпретирующий код который будет работать хотябы так же как скомпилированный (да еще и специально созданный для конкретного случая)?

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

ГВ>Свежо предание... По идее, такую подстановку можно делать только при уверенности, что модуль, откуда инлайнирована функция, — никогда не будет заменён. А как эту уверенность создать?

Дык комиляция же производится прямо перед первым выполнением. Побочным эффектом явялется то, что модуль можно выгрузить только вместе с AppDoman-ом (с виртуальным приложением).

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

S>Бред. Что мешает в C++ программах делать самомодифицирующиеся ассемблерные вставки?

Ну, во первых это будет не С++, а во-вторых, у меня как-то один программист делал динамический вызов фуниции. Ну, потрахался неделю на асм-е... кое что получилось. А кода пришлось другие типы данных обрабатывать, то мы прикопали его год (на вский пожарный) и переписали все на не ачень красивом дисптче. Те так элегантно и намного тормозней, но работает. Короче тяжело это и опасно. С промежуточными языкмии все наоборот. Там все это дело заключено в специльные обертки и относительно не сложно. Ну, а производительность та же.

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

E>1. На нём пишут много людей. А значит не я один такой, кому этот язык нравится.
Ну, вот я на русском пишу. Это же не значит, что он мне нравится.

E>2. На нём пишут много умных людей, т.е. есть с кем посоветоваться.
А сколько умных людей пишит на хинди...
E>3. На нём можно написать ВСЕ. И неправда, что это так уж сложно.
Всё? Ну, а где тогда искуственный интелект?

E>4. Памятью можно управлять вручную. Это замечательно! Я в любой момент знаю, что НА САМОМ ДЕЛЕ делает моя программа.
Ой ли? И что проходов по памяти днями никогда не искал?
E>5. Объектная ориентированность.
Эка невидаль. Где ее сегодня нет?
E>6. Контроль типов во время компиляции, а не выполнения. На языках, подобных BASIC и Perl отсутствие контроля типов часто приводит к головной боли.
Ты когда последний раз Бейсик видел? Я вот вчера VB смотрел. Так там с контролем типов все впорядке.
Ты мне лучще вот эту кострукцию объясни:

...
IItf2 pItf2 = NULL;
pItf1->QueryInterface(IID_pItf2, (void**)&pItf1);

Если С++ так безупречин, то зачем люди придумали такой варварский способ приведения типов? И вообще зачем нужен void* в таком строгом и красивом языке?

E>7. Windows (по крайней мере начиная с 2000) написана на этом языке.

Кто тебе это сказал? Ядро всю жизнь писалось на C. Ну, а отдельные компоненты и на VBScript пишутся. Скоро многое будет на .NET.

E> По-моему для программирования в этой операционной системе лучше использовать ее РОДНОЙ язык.

"Родной язык" — это круто!

Но тогда ух переходи на С.

E>8. Это достаточно низкоуровневый язык. На нем вполне можно писать даже драйверы.
От чего же "даже"?
E>9. На этом языке достаточно легко реализовать какую-нибудь компонентную модель (типа COM). И эти модели успешно существуют уже достаточно давно.

Ты хоть сам пробывал? Вот мне кажется, что сложновато все как-то.

E>Конечно, у этого языка (как и у других) есть недостатки. Но на мой взгляд преимущества все же перевешивают. Возьмите для сравнения так называемый Object Pascal (на самом деле — Delphi). Нигде в мире, кроме как в Delphi этот язык не используется (насколько я знаю, хотя могу ошибаться). В тоже время язык C++ очень распространен и существует практически на всех платформах.

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

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

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

Для меня лично — это свобода! Это возможность выражать свои мысли непосредственно на языке, не думая о том, как нужно преобразовать понятия в конструкции кода или как обойти искусственные ограничения, наложенные автором языка "чтобы новичкам было проще изучать". C++ — единственный известный мне высокоуровневый язык, написанный "программистом для программистов" в стиле хакерства начала 60-х прошлого века в MIT. Этот язык дает в твои руки неограниченную мощность, которой, если правильно пользоваться, можно воротить горы. И при этом всем он еще и элегантен, в отличие от других мощных языков типа языков ассемблера.

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

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

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

E>>3. На нём можно написать ВСЕ. И неправда, что это так уж сложно.
VD>Всё? Ну, а где тогда искуственный интелект?

Все, для чего известны эффективные алгоритмы.

E>>4. Памятью можно управлять вручную. Это замечательно! Я в любой момент знаю, что НА САМОМ ДЕЛЕ делает моя программа.
VD>Ой ли? И что проходов по памяти днями никогда не искал?
А никто не говорит, что управлять памятью вручную нужно путем явного вызова new и delete.
Существует большое количество решений типа аллокаторов, которые безо всяких накладных расходов позволяют реализовать надежную и эффективную модель распределения памяти.

E>>6. Контроль типов во время компиляции, а не выполнения. На языках, подобных BASIC и Perl отсутствие контроля типов часто приводит к головной боли.
VD>Ты когда последний раз Бейсик видел? Я вот вчера VB смотрел. Так там с контролем типов все впорядке.
А как насчет PERL?

/* Думаешь, тут люди что такое NLP не знают? */

VD>Ты мне лучще вот эту кострукцию объясни:
VD>

VD>...
VD>IItf2 pItf2 = NULL;
pItf1->>QueryInterface(IID_pItf2, (void**)&pItf1);
VD>

VD>Если С++ так безупречин, то зачем люди придумали такой варварский способ приведения типов? И вообще зачем нужен void* в таком строгом и красивом языке?

Это проблемы не C++, а COM, который к C++ отношения не имеет. Ты когда-нибудь SOM видел? Вот это простая и красивая объектная модель. И вообще, большая часть решений на C++ от M$ элегатнтостью не отличаются, что не означает, что невозможно строить элегантные решения вообще, ибо это зависит от уровня программиста.

E>>9. На этом языке достаточно легко реализовать какую-нибудь компонентную модель (типа COM). И эти модели успешно существуют уже достаточно давно.

VD>Ты хоть сам пробывал? Вот мне кажется, что сложновато все как-то.

Ну, хотя бы вышеупомянутый SOM.

E>>Конечно, у этого языка (как и у других) есть недостатки. Но на мой взгляд преимущества все же перевешивают. Возьмите для сравнения так называемый Object Pascal (на самом деле — Delphi). Нигде в мире, кроме как в Delphi этот язык не используется (насколько я знаю, хотя могу ошибаться). В тоже время язык C++ очень распространен и существует практически на всех платформах.

VD>И что от этого его изучать будет проще? Или он чем-то лучше станет? Язык конечно хороший. Но для нацинающего явно сложноват.

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

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

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

VD>Это одна из фичей. Тебе не нежна другим нужна. Например, можно динамически создать обертку для таблицы БД или ускорить выполнение задачи. Например, регулярные выражения в .NET поддерживаю динамическую герерацию кода. Это позволяет избежать оверхэда накладываемого интерпретацией регэкспов. В общем позволяет заменить интерпретацию компиляцией (но в рантайме и автоматически).

При этом обязательно наличие компилятора. Тогда чем это отличается от *nix платформ, где компилятор есть везде. В компании, где я работаю, готовится стартовать проект OODB, где запросы будут преобразовываться в C++ код, компилироваться и выполняться. В чем есть отличие от .NET?

S>>Например, вот такие конструкции могут сильно облегчить жизнь:

S>>

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

VD>Нда. Я так понимаю выглядит это так: Человек пытаетя прочесть этот код, свихивается и попадает в психушку. После чего его жизнь становится лехкой и беззаботной.

Это если мозгов хватает только на то, чтобы на C# писать.

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

.

VD>Вот из-за этой гибкости обычные люди и избегают Линуксы.

Просто люди боятся линуксов — надо же, надо еще и учить команды консоли! А виндах все приятно и все можно мышкой делатью

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

VD>Тебе уже говорили. Програма записывается на промежуточном языке. Перед выполнением (или при инсталляции) она компилируется в машинный код. При этом известнв все характеристики машины на которм все это будет выполняться.

А чем принципиально хранение программы в промежуточном коде отличается от хранения программы в исходном коде?

Здравствуйте m.a.g., Вы писали:

mag>Все, для чего известны эффективные алгоритмы.

Значит все таки не всё... :)

mag>А никто не говорит, что управлять памятью вручную нужно путем явного вызова new и delete.
mag>Существует большое количество решений типа аллокаторов, которые безо всяких накладных расходов позволяют реализовать надежную и эффективную модель распределения памяти.

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

VD>>Ты когда последний раз Бейсик видел? Я вот вчера VB смотрел. Так там с контролем типов все впорядке.
mag>А как насчет PERL?

На счет Перла все в порядке. Его на пять минут посмеяться родили, а он возьми да выживи. :) Это своего рада приложение к регэкспам.

mag>/* Думаешь, тут люди что такое NLP не знают? */

Дык я и сам пока не пойму о чем ты? :)

mag>Это проблемы не C++, а COM

Аааа. Я то думал — это попытки обойти проблемы C++ связанные с тем что язык вообще не ориентирован на связь с рантаймом.

mag>, который к C++ отношения не имеет.

Надо мужикам рассказать... До тебя все думали, что COM писали на C++ и, что у C++ было взято очень многое.

mag>Ты когда-нибудь SOM видел? Вот это простая и красивая объектная модель.

Ты бы ссылку дал, что ли...

mag>И вообще, большая часть решений на C++ от M$ элегатнтостью не отличаются, что не означает, что невозможно строить элегантные решения вообще, ибо это зависит от уровня программиста.

Да вот Линх другое дело... одна элентщина. :)

VD>>Ты хоть сам пробывал? Вот мне кажется, что сложновато все как-то.

mag>Ну, хотя бы вышеупомянутый SOM.

Если этот твой сом такой крутой. Что же о нем никто не знает? Она хоть сколько языков поддерживает. И как реализует информацию о типах для рантайма?

Здравствуйте m.a.g., Вы писали:

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

VD>>Это одна из фичей. Тебе не нежна другим нужна. Например, можно динамически создать обертку для таблицы БД или ускорить выполнение задачи. Например, регулярные выражения в .NET поддерживаю динамическую герерацию кода. Это позволяет избежать оверхэда накладываемого интерпретацией регэкспов. В общем позволяет заменить интерпретацию компиляцией (но в рантайме и автоматически).

mag>При этом обязательно наличие компилятора.

Кто тебе сказал? В .NET есть специльный нэймспэйс Emit, позволяющий генерировать код. Можно конечно и компилировать, но... К тому же есть еще такая штука — CODDOM. С ее попощью можно генерировать код не зависящий от языка и реинжинирить его. VS.NET сериализует контролы прямо в код по средствам CODDOM-а.

mag> Тогда чем это отличается от *nix платформ, где компилятор есть везде. В компании, где я работаю, готовится стартовать проект OODB, где запросы будут преобразовываться в C++ код, компилироваться и выполняться. В чем есть отличие от .NET?

Несравнимо более быстрая компиляция. Ну и тем что очень многое уже сделано. Т.е. есть большая начальная база.

mag>Это если мозгов хватает только на то, чтобы на C# писать.

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

mag>Просто люди боятся линуксов — надо же, надо еще и учить команды консоли! А виндах все приятно и все можно мышкой делатью

После этой фразы нужно пальцы веером делать.

mag>А чем принципиально хранение программы в промежуточном коде отличается от хранения программы в исходном коде?

1. Они уже обработаны транслятором и их окончательная компиляция происходит очень быстро.
2. Не доступны исходники. Т.е. можно делать коммерческие проекты с закрытым кодом.
3. Можно применять простые методы вирификации кода. Простые, так как отсуствует парсинг и т.п.
4. В сборках присутствует информация о типах которую можно легко читать в рантайме (и не талько).

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

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

S>>Основные затраты — на построение графа переходов КА (statearray), выполняемое при разборе выражения.

VD>А если создаь код, то разбирать нужно будет намного меньше.

Нет. Однохренственно.

VD>Ты серьезно чститаешь что сособен создать интерпретирующий код который будет работать хотябы так же как скомпилированный (да еще и специально созданный для конкретного случая)?

Я уже устал повторять, что при поиске регулярного выражения нечего интерпретировать — это всего лишь поиск.

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

ГВ>Здравствуйте Igor Trofimov, Вы писали:

IT>>а) языка, приятного всем — не придумать
IT>>б) .net — отчасти это попытка "примирить" языки за счет объединения на низком уровне.

ГВ>ИМХО, больше похоже на попытку причесать все языки под одну гребёнку .NET :maniac:

сам-то понял, чё написал?

опять сказки про злого Дядю Билла, который всех "причесывает"...

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

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

S>>>Например, вот такие конструкции могут сильно облегчить жизнь:

S>>>

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

VD>>Нда. Я так понимаю выглядит это так: Человек пытаетя прочесть этот код, свихивается и попадает в психушку. После чего его жизнь становится лехкой и беззаботной. :)

S>Ты, видимо, тоже перешел в стадию забывания C++? Это всего лишь самый простой способ избежать возни с указателями в случае, если требуется повторная инициализация объекта.

это пример что назывется "некачественного кода". Если это не приложение типа "намалякал-забыл", то подобный "самый простой способ" приведет к головной боли читающего/пишущего в будущем. Для серъезных долгоживущих и эволюционирующих проектов такая практика в чем-то катастрофична. Это хаки. Хакеры не строят, хакеры ломают...

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

S>>А потом разбирайся, какую битмапу использовать. Нафиг.

VD>Я обычно разбираюсь сначало. ;)

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

S>>Злые разработчики библиотеки забыли приделать к классу wxBitmap (а это был он) функцию Clear(). На самом деле, такие ситуации очень часто встречается.

VD>Ты случаем на VB или Дельфи не переписал? Забыли не забыли... добавь и живи спокойно дальше. :)

Ты всерьез считаешь, что добавить функцию к одному из классов кроссплатформенной библиотеки существенно проще, чем написать две строчки кода? Для добавления функции у меня дня три только на переписку с разработчиками библиотеки уйдет.

VD>>>А хелперы — это просто обертки. Они не обязательно являются умными и указателями. ;)

S>>Вот тут поподробнее — как они мне без указателей один объект грохнут и другой создадут? И нафиг вообще нужны? Их же самому писать придется, вместо двух строчек кода...

VD>Они обычно используется для временных объектов. Их время жизни определяет время жизни обертываемого объекта. Ну, а если нужно порулить вручную, то для этого и делают разные Attach-и, Detach-и и Clear-ы.

Объект не временный. Clear'а у него нет. Ы?

S>>Там не отмечен один факт — VC 6/7 не является полноценным компилятором C++ :)

VD>Ну, это уже демогогия. Тебе шашечки или ехать? Этот компилятор один из самых популярных. 99% созданного кода на нем компилируется.

Не далее чем в четверг в очередной раз пришлось вспомнить про Q241949. Достало. А еще больше достало шаблоны упрощать, когда VC отказывается их компилировать без всяких видимых причин. По целому дню иногда уходит на обход ошибок в компиляторе. Это теперь называется "ехать"?

S>>Front-end'ы для C++ обычно генерируют сишный код. А дальше можешь компилировать его своим любимым оптимизирующим компилятором C. Можешь даже клиенту в таком виде поставлять, чтоб он на target-системе все сам скомпилировал — украсть куски из него будет не намного проще, чем из MSIL'а.

VD>Так из мсила как раз украсть все очень легко. Там такое тайпинфо... :)

VD>>>Да? А мы как-то ими пользуемся. :-\ В .NET любой класс по определению компонент. Да и COM-мом пользоваться можно. Хоть и тяжело...

S>>С трудом, наверное, пользуетесь. Чужими компонентами, по крайней мере. Иначе с чего вдруг свой контейнер писать стали — чужих мало, что ли?

VD>Да в то время не дофига было. Да и сейчас нормальные можно по палцам счесть.

Вот и я о том же.

VD>Ну, а компонентами чужими пользуемся. Не все же с нуля писать. Попробуй например на досуге web-броузер написать... а ведь в виде ActiveX-а его подцепить ничего не стоит.

Да, броузер тяжело. Цепляем в качестве ActiveX. 30% времени, которое лично мне приходиться тратить на поддержку (это уже из отфильтрованных эникейщиками жалоб юзеров), уходит именно на разбирательства с "особенностями" разных версий этого самого броузера. Все никак не выкрою время выкинуть его нафиг и воткнуть wxHTML вместо IE. Хотя придется.

VD>Ну, или тот же сриптинг...

Что такое "сриптинг"? Если это встроенный в программу язык, то меня этим не запугать.

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

S>>Само собой, но в основном они дают повышенную падучесть :) Опять же, что называть компонентными технологиями? Вот плагины к FAR'у — это компоненты или нет?

VD>Ты случам не с Салярки пишешь? Вот и мне кажется из IE запушенного под одной из версий Виндов. Так вот они почти полностью из компонентов состоят. И как видишь живут. Про падучесть это форменный предрассудок.

Угу, только 99% этих компонентов написаны одной фирмой. Которая меняет 60% этих компонентов в каждом SP. Довольно далеко от компонентного подхода, IMHO.

VD>Программы падают из-за ошибок, а не из-за применения тех или иных программных парадигм.

Ты отрицаешь, что применение разных парадигм программирования приводит к разному среднему количеству ошибок в программах?

S>>Скажем так, большинство программ, но не все. Тот же 3D Studio MAX учитывает и объем памяти, и тип процессора.

VD>Видимо по этому это он медленнее всех рендерит конечные сцены. :)

VD>Если он что-то и учитывает, то это реализовано на компонентной основе. Это конечно лучше чем ничего, но по сравнению с полной оптимизацией все же не так здорово.

Ты пока не сказал, какой именно смысл ты вкладываешь в понятие "компонентная основа". Я, например, не считаю компонентыми две DLL'ки, скомпилированные из одного кода под разные процессоры.

S>>Многопроцессорность тривиально обрабатывается и в программах на C++.

VD>Можешь назвать хотябы 3 штуки? И не рендереры. Я лично знаю, только SQL-серверы, да и то только Oracle, MS и почивший Informix. Тут же речь идет, о том что от второго процессора могут начать выигрывать большинство программ.

Ты, видимо, забыл, как работает CreateThread? Почти любая многопоточная программа выигрывает от использования нескольких процессоров.

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

VD>Дык потоки — это часть того же .NET и Явы. Так что они довольно много знают. Достаточно, чтобы распаралеллить многие вычисления.

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

VD>Представь, при инсталяции на конкретную систему му узаем что есть четыре процесора... мы копилируем код системных библиотек так, чтобы они параллелили все что получится для этих четырех камней. На системе с двумя камнями параллелим для двух. Ну, а если процессор один, то выкидываем лишний код. На системе без процессора включаем совтвэа-эмулейшон. :)

И что, в .Net есть средства, поддерживающие это? В программе на C++ я просто узнаю количество процессоров и создаю столько же рабочих потоков, если мне не влом распараллеливать вычисления. Что именно должно происходить в .NET — программе, чтобы сделать то же самое, но автоматически (не спрашивая количество процессоров)? ИМХО, это уже из области искуственного интеллекта, который, к тому же, будет мешать, а не помогать программисту. Этакий Bob In Your Code (TM) :)

S>> Лет семь уже деруться — есть что делить, однако. А если все с джитами и нетами хорошо будет, так я на них и ругаться перестану.

VD>Дык с ними уже и сейчас все не так плохо. Я вот перестал. :)

VD>>>Короче, дурака не включай. Сам понимаешь что мешает, что что процессоров очень много и то что компоненты (ну хоть те же длл-ки) оптимизироваться могут только в пределах одного проекта. К тому же кто тебе сказал что не применяются? В том же VC7 есть такая опция "Глобал оптимизэйшон". Так вот она пишит в объектники не машинный код, а язык а-ля MSIL. А кодогенерацией занимается линкер.

S>>Да мне по барабану, кто там кодогенерацией занимается и какое внутренне представление данных использует связка компилятор+линкер.

VD>Ты спросил "почему такие технологии в компиляторах не используют?". Я ответил что пытаются...

S>> Если же кодогенератор у них общий, с какого перепугу джит обгонит машинный код?

VD>Не перегибай. Кодогенераторы разные, принцип похож. Ну, а джит обгоняет потому, что код компилируется под конкретный прцессор и объекм памяти, а компилятор работает у программиста который возможно даже не знает что за процессор будет у пользователя.

Ещще не факт, что кодогенератор у пользователя знает про процессор, который у этого пользователя установлен. Железо в последнее время чаще софта обновляться стало :)

S>> А начсет DLL'к под разные процы, так это уже есть.

VD>Есть. Кто же спорит. Только мола (задача то не тривиальная) и оптимизируется только чать кода. А тут можно оптимизировать весь. Что же тут плохого?

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

VD>>>Просто динамическая оптимизация это еще большая задача чем обычная. Ну, да у MS, Sun и IBM на нее деньги должны найтись. :) Пущай мучаются...

S>>Динамическая — это когда? В рантайме?

VD>Да. Джит работает сразу после запуска приложения.

S>> А она что, бесплатная?

VD>Кто она? Оптимизатор входит в рантаймподсистему .NET и Явы...

Я не про $$$, а про секунды. Оптимизация — процесс не быстрый.

Здравствуйте Аноним, Вы писали:

S>>>>

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

VD>>>Нда. Я так понимаю выглядит это так: Человек пытаетя прочесть этот код, свихивается и попадает в психушку. После чего его жизнь становится лехкой и беззаботной. :)

S>>Ты, видимо, тоже перешел в стадию забывания C++? Это всего лишь самый простой способ избежать возни с указателями в случае, если требуется повторная инициализация объекта.

А>это пример что назывется "некачественного кода". Если это не приложение типа "намалякал-забыл", то подобный "самый простой способ" приведет к головной боли читающего/пишущего в будущем. Для серъезных долгоживущих и эволюционирующих проектов такая практика в чем-то катастрофична.

Ты хочешь сказать, что этот код хуже, чем

 delete _bitmap;
 _bitmap = new Bitmap;
 _bitmap->Create(w, h, depth)

Тогда уж будь добр, обоснуй :) Только отмазки насчет того, что ты или человек, который будет править этот код, не знает C++ в достаточном для понимания этого кода объеме, не принимаются.

А>Это хаки. Хакеры не строят, хакеры ломают...

Где тут хак, блин? Все в соответствии со стандартом — 12.4.12 и 18.4.1.3

Здравствуйте VladD2, Вы писали:
mag>>При этом обязательно наличие компилятора.

VD>Кто тебе сказал? В .NET есть специльный нэймспэйс Emit, позволяющий генерировать код. Можно конечно и компилировать, но... К тому же есть еще такая штука — CODDOM. С ее попощью можно генерировать код не зависящий от языка и реинжинирить его. VS.NET сериализует контролы прямо в код по средствам CODDOM-а.

А что есть Emit, как не компилятор? Тольк по-другому назван...

mag>> Тогда чем это отличается от *nix платформ, где компилятор есть везде. В компании, где я работаю, готовится стартовать проект OODB, где запросы будут преобразовываться в C++ код, компилироваться и выполняться. В чем есть отличие от .NET?

VD>Несравнимо более быстрая компиляция.

Данные в студию, плз.

VD>Ну и тем что очень многое уже сделано. Т.е. есть большая начальная база.

Опять-таки, данные в студию. Под юниксы пишут уже 20 лет. Написано явно больше

mag>>Это если мозгов хватает только на то, чтобы на C# писать.

VD>Ну, что я могу сказать... Хам, только и всего. Заметь. Народ из верхней двадцадки себе такого не позволяет. Хотя знают явно больше твоего.

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

mag>>Просто люди боятся линуксов — надо же, надо еще и учить команды консоли! А виндах все приятно и все можно мышкой делатью

VD>После этой фразы нужно пальцы веером делать.

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

mag>>А чем принципиально хранение программы в промежуточном коде отличается от хранения программы в исходном коде?

VD>1. Они уже обработаны транслятором и их окончательная компиляция происходит очень быстро.

А какой смысл оптимизировать одноразовую операцию? Ведь речь шла о тюнинге программы на конкретной машине.

VD>2. Не доступны исходники. Т.е. можно делать коммерческие проекты с закрытым кодом.

А что насчем большого количества информации о типах (или как там она называется)? В .NET я с этим не сталкивался, но ту же java можно диз... не дизассемблировать... можно восстановить исходный текст.

VD>3. Можно применять простые методы вирификации кода. Простые, так как отсуствует парсинг и т.п.

Можно чуть поподробнее?

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

mag>>Все, для чего известны эффективные алгоритмы.
VD>Значит все таки не всё...

Все, что можно реализовать на C# — точно

mag>>А никто не говорит, что управлять памятью вручную нужно путем явного вызова new и delete.
mag>>Существует большое количество решений типа аллокаторов, которые безо всяких накладных расходов позволяют реализовать надежную и эффективную модель распределения памяти.

VD>Во-во. Существует большое количество чего угодно. Но у меня вот, даже самые опытные программисты время от времени проходятся по памяти.

А для этого есть Bounds Checker и прочее. Для профилактики разок запустить раз в день — все отлавливается превосходно.

VD>>>Ты когда последний раз Бейсик видел? Я вот вчера VB смотрел. Так там с контролем типов все впорядке.
mag>>А как насчет PERL?

VD>На счет Перла все в порядке. Его на пять минут посмеяться родили, а он возьми да выживи.

Это своего рада приложение к регэкспам.

mag>>/* Думаешь, тут люди что такое NLP не знают? */
VD>Дык я и сам пока не пойму о чем ты?

О резкой смене темы. В исходном сообщении было про бейсик и перл, про бейсик сказал, а вот про перл умолчал, вроде бы ненамеренно...

mag>>Это проблемы не C++, а COM
VD>Аааа. Я то думал — это попытки обойти проблемы C++ связанные с тем что язык вообще не ориентирован на связь с рантаймом.

Не понял фразу. Что есть "связь с рантаймом"?

mag>>, который к C++ отношения не имеет.
VD>Надо мужикам рассказать... До тебя все думали, что COM писали на C++ и, что у C++ было взято очень многое.

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

mag>>Ты когда-нибудь SOM видел? Вот это простая и красивая объектная модель.
VD>Ты бы ссылку дал, что ли...

Да загнулся он, из-за плохого менеджмента

mag>>И вообще, большая часть решений на C++ от M$ элегатнтостью не отличаются, что не означает, что невозможно строить элегантные решения вообще, ибо это зависит от уровня программиста.

VD>Да вот Линх другое дело... одна элентщина.

Да там до последнего времени тоже C++ не пахло. pure c, вообще-то везде юзался.

VD>>>Ты хоть сам пробывал? Вот мне кажется, что сложновато все как-то.

mag>>Ну, хотя бы вышеупомянутый SOM.

VD>Если этот твой сом такой крутой. Что же о нем никто не знает? Она хоть сколько языков поддерживает. И как реализует информацию о типах для рантайма?

Почему никто не знает — см. выше.
Поддерживает она все, на что есть маппинг OMG IDL.
В метаклассах.

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

S>Ты всерьез считаешь, что добавить функцию к одному из классов кроссплатформенной библиотеки существенно проще, чем написать две строчки кода? Для добавления функции у меня дня три только на переписку с разработчиками библиотеки уйдет.

S>Объект не временный. Clear'а у него нет. Ы?

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

S>Не далее чем в четверг в очередной раз пришлось вспомнить про Q241949. Достало. А еще больше достало шаблоны упрощать, когда VC отказывается их компилировать без всяких видимых причин. По целому дню иногда уходит на обход ошибок в компиляторе. Это теперь называется "ехать"?

У вас прсто не правильный подход. Пистаь нужно на VC, а уж потом портировать (делать код совместимым с...) на другие компиляторы. В других компиляторах тоже есть свои проблемы. Это специфика бумажного стандарта (нет эталона).

VD>>Да в то время не дофига было. Да и сейчас нормальные можно по палцам счесть.

S>Вот и я о том же.

О чем? До фига не до фига. Есть же! В другом виде вообще нет.

S>Да, броузер тяжело. Цепляем в качестве ActiveX. 30% времени, которое лично мне приходиться тратить на поддержку (это уже из отфильтрованных эникейщиками жалоб юзеров), уходит именно на разбирательства с "особенностями" разных версий этого самого броузера. Все никак не выкрою время выкинуть его нафиг и воткнуть wxHTML вместо IE. Хотя придется.

Ну-ну. После этого проблемы с поддержкой продукта конечно кончатся... вместе с клиентами. :)

S>Угу, только 99% этих компонентов написаны одной фирмой.

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

S> Которая меняет 60% этих компонентов в каждом SP. Довольно далеко от компонентного подхода, IMHO.

Опять приувеличение. Сейчас MS придерживается политики использования параллельно нескольких мерсий компонентнов. Тот же XML-парсер можно установить несколько версий на одну машину.

VD>>Программы падают из-за ошибок, а не из-за применения тех или иных программных парадигм.

S>Ты отрицаешь, что применение разных парадигм программирования приводит к разному среднему количеству ошибок в программах?

Парадигты — это абстракции очень высокого уровня. От них ошибок быть не может. Все зависти от конкретных реализаций и условий.

S>Ты пока не сказал, какой именно смысл ты вкладываешь в понятие "компонентная основа". Я, например, не считаю компонентыми две DLL'ки, скомпилированные из одного кода под разные процессоры.

Добавь к длл-кам описание и введи понятие класс/компонент (нечто объеденяющее данные и методы их обработки) и получится компонентная технология. Собственно COM тоже на длл-ках от части основан.

VD>>Можешь назвать хотябы 3 штуки? И не рендереры. Я лично знаю, только SQL-серверы, да и то только Oracle, MS и почивший Informix. Тут же речь идет, о том что от второго процессора могут начать выигрывать большинство программ.

S>Ты, видимо, забыл, как работает CreateThread? Почти любая многопоточная программа выигрывает от использования нескольких процессоров.

Ты все же назови эту загадочную "любую программу". ;) А то вон в Ворде этих CreateThread-ов как грязи, а второй процессор ему нафиг не нужен. Под Win32 написание многопоточных приложений выигрывающих от второго процессора — это неординарная задача. Да и под Уних тоже самое. Тот же Оракл до сих пор плюет на потоки и параллелится на уровне процессов.

VD>>Дык потоки — это часть того же .NET и Явы. Так что они довольно много знают. Достаточно, чтобы распаралеллить многие вычисления.

S>Они не знают, сколь долго какой поток будет выполняться и как скоро потребуются результаты. Программист же, как правило, имеет об этом представление.

Дык чтобы сделать qsort использующий два процессора и не нужно знать скль долго будет жить некий поток. К тому же все действия с потоками осуществляются через библиотеки, а они являются частью рантайма. Так что можно сказать что вся информация есть. Ты же скармливаешь рантайму готовый код...

VD>>Представь, при инсталяции на конкретную систему му узаем что есть четыре процесора... мы копилируем код системных библиотек так, чтобы они параллелили все что получится для этих четырех камней. На системе с двумя камнями параллелим для двух. Ну, а если процессор один, то выкидываем лишний код. На системе без процессора включаем совтвэа-эмулейшон. :)

S>И что, в .Net есть средства, поддерживающие это?

Для серверного рантайма есть. Клиентский они почему-то считают однопроцесорным.

S>В программе на C++ я просто узнаю количество процессоров...

Во-во. Просто попытаешься все сделать сам. Таких как ты много было. Но вот программы которые маштабируются на SMP-системах можно по пальцам сосчитать. Речь идет о том, что потоки будут частично контролироваться рантаймом, и о том, что рабоать с ними станет на порядки проще. В С++ нет даже самого понятия потока. В crt есть кое какие функции, но все это фигня на послом масле.

S> и создаю столько же рабочих потоков, если мне не влом распараллеливать вычисления. Что именно должно происходить в .NET — программе, чтобы сделать то же самое, но автоматически (не спрашивая количество процессоров)?

Дык ты просто пишишь многопоточный код, а рантайм разбирается насклько нужно этот код действительно делать многопоточным. Т.е. он берет информацию из ОС, твой код и творчески его компилирует.

S> ИМХО, это уже из области искуственного интеллекта, который, к тому же, будет мешать, а не помогать программисту. Этакий Bob In Your Code (TM) :)

Вот только не пойму почему ИИ должен мешать. Если его зачатки есть в программе, то это же просто здорово!

S>Ещще не факт, что кодогенератор у пользователя знает про процессор, который у этого пользователя установлен. Железо в последнее время чаще софта обновляться стало :)

Дык по умолчанию все джитится (компилируется перед использованием). Да и предкомплированные вещи спокойно перекомпилировать можно.

VD>>Есть. Кто же спорит. Только мола (задача то не тривиальная) и оптимизируется только чать кода. А тут можно оптимизировать весь. Что же тут плохого?

S>Я уже говорил — то же делается на C++ компиляцией программы на машине конечного пользователя. А плохого то, что дав не много (оптимизацию на конечной машине и т.д.), .NET отбирает куда больше.

И что же? Да и почему не много? Исходники-то к серьезным коммерческим программам не поставляют. А так автоматическая оптимизация. Причем без единой строчки кода. Что тут плохого. Главное реализовать это все с умом. И оптимизатор отшлифовать под реальные камни.

VD>>Да. Джит работает сразу после запуска приложения.

S>>> А она что, бесплатная?

VD>>Кто она? Оптимизатор входит в рантаймподсистему .NET и Явы...

S>Я не про $$$, а про секунды. Оптимизация — процесс не быстрый.

А... Ну, вот ты и сравни... Сколько твоя программа будет загружаться и сколько работать. Если ты пишишь утилиту командной строки выполняющую одно-два действия, то время джита для тебя может оказаться критичным. Но если ты пишишь серверное- или GUI-приложение, то компяляция всего лишь замедлит загрузку такого приложения. Для серверного приложения — это вообще не критично. Для клиентского — медленная загрузка. Решение в случае консоли и гуи является ngen (пре джит).

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

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

S>Тогда уж будь добр, обоснуй

Только отмазки насчет того, что ты или человек, который будет править этот код, не знает C++ в достаточном для понимания этого кода объеме, не принимаются.

Тебе уже сказали, что по человечески это выглядело бы примерно так:

CBitmap bmp(...);
...
bmp.Clear();
bmp.Create(w, h, depth);

Кто виноват, что у тебя библиотеки кривые?

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

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

S>>Тогда уж будь добр, обоснуй :) Только отмазки насчет того, что ты или человек, который будет править этот код, не знает C++ в достаточном для понимания этого кода объеме, не принимаются.

VD>Тебе уже сказали, что по человечески это выглядело бы примерно так:
VD>

VD>CBitmap bmp(...);
VD>...
VD>bmp.Clear();
VD>bmp.Create(w, h, depth);
VD>

VD>Кто виноват, что у тебя библиотеки кривые?

Кривые они или нет — это другой вопрос. А вот то, что оставаясь в рамках стандарта C++ я могу легко эту "кривизну" обойти, причем без лишних затрат и гемора — это большой плюс для C++.

А насчет кривости — накой нужна Clear, если есть деструктор? Меньше кода, меньше ошибок.

Здравствуйте m.a.g., Вы писали:

mag>А что есть Emit, как не компилятор? Тольк по-другому назван...

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

VD>>Несравнимо более быстрая компиляция.

mag>Данные в студию, плз.

У нас проекты на С++ компилируются 20 синут на Атлоне 2000+. Джит же на той же машине проходит в доли секунд. В .NET все лежит в сборках. У сборок свои способы импрта/экспорта расчитанные на динамическую загрузку. Никаких инклюдов. Все разобрано и сложено в пи-код. Компиляция в таких условиях впревращается в контекстную замену. Только оптимизация время и отнимает. Если тебе нечего делать, найди код по больше и проверь. У меня еще дел хватает.

VD>>Ну и тем что очень многое уже сделано. Т.е. есть большая начальная база.

mag>Опять-таки, данные в студию. Под юниксы пишут уже 20 лет. Написано явно больше ;)

Данные чего? Того что есть огромный нэймспэйс Emit и не меньший CODDOM? В Юниксах этого от родясь небыло. В Яве разве что, да и то... К тому же юникс был создан где-то 30 лет назад. Винды и те уже 15 лет насчитывают. Но толку от этого никакого. Вон гляди, выбросили к чертям архитектуру микроядра и наклепали популистский Линукс. :-/

mag>Прошу прощения у всех, кого оскорбил вышеотквоченной фразой. Вышел из себя, что было не хорошо,

Не надо так. Мы же тут тебя не пытаемся оскорбить. Не хочишь спорить просто отойдит.

mag>но весьма неприятно, когда тебе говорят, что весьма простая и понятная конструкция языка, который ты считаешь наиболее приемлемым для своего типа мышления, может вызвать только сумасшествие.

Ну, так и люди разные бывают и развите идет вперед. То что было нормальным 5 лет назад. На сегодня уже может оказаться устаревшим. К С++ не даром претензии предявляют. Многие кто сейчас смотрит в сторону .NET проффесионально писали (пишут) на С++. И я в том числе. Проблемы и достоинства этого языка эти люди знают не по наслышке. Я, например, не понимаю зачем защищать недостатки? И почему их нельзя исправлять?

Такие вещи как шаблоны, множественное наследование и полноценные деструкторы для объектов размещаемых в стеке, на мой взгляд были выбрашены совершенно напрасно. И я об этом говорю тем кто безоглядно влюблен в .NET и Яву. Мне нужно средство стремящееся к идеалу, а не консервируемое из последних сил или новомодное. В .NET много конструктивных идей. Но есть и недостатки. По собственным ощущениям могу сказать, что приимущества явно перевешивают. К тому же и язык и среда не собираются консервироваться в текущем состоянии.

Ну, а на счет конкретной конструкции... Я высказал свое мнение. Не согласен? Ну, значит мы остались при своих мнениях. Не бить же по этому поводу друг-другу морды? :) Я тебе показал, как бы тоже код написал бы я. И попытался обяснить почему...

mag>Назови мне пять главных причин, по которым люди не переходят под Линукс. Уверен, что там будет "слишком там все сложно".

Обязательно! А так хочешь? Согласись кода в Windows не меньше чем Linux, а значит и сложность систем одинаково велика. Но простой смертный спакойно начинает работать с виндами и мучиется в линуксе. От части это связано просто с отсуствием софта, от части с маркетингом, но в сумме получатся выбор. И выбор получатся не в сторону линукс.

Кстати, я до сих пор не понимаю как этот урод (я про ОС Линукс) смог вообще занять место на рынке? Ведь есть и ско и салярка и фришка и cgi-шная ось. Тут тоже явно прослеживается маркетинг и наличие тех самых мелочей которые упращают жизнь пользователя.

VD>>1. Они уже обработаны транслятором и их окончательная компиляция происходит очень быстро.

mag>А какой смысл оптимизировать одноразовую операцию? Ведь речь шла о тюнинге программы на конкретной машине.

Ты что называешь одноразовой операцией? Парсинг и синтаксический разбор? Дык, это очень дорогостоящие операции. Компиляция CLI под фришкой занимает несколько часов. Представь что будет если в исходниках поставить виндузу? К тму же джит подразумевает компиляцию непосредственно перед выполнением и операция становится не одноразовой. Ты же сам говорил, "а что если процессор изменится?".

VD>>2. Не доступны исходники. Т.е. можно делать коммерческие проекты с закрытым кодом.

mag>А что насчем большого количества информации о типах (или как там она называется)? В .NET я с этим не сталкивался, но ту же java можно диз... не дизассемблировать... можно восстановить исходный текст.

С Явой для этого придумали обфускаторы (они уродуют все так чтобы обратный инжениринг не дал нормального кода). С .NET вроде что-то должно было встроено в систему, но что я не знаю. В любом случае это не исходный код.

VD>>3. Можно применять простые методы вирификации кода. Простые, так как отсуствует парсинг и т.п.

mag>Можно чуть поподробнее?

Код можно грузить из разных мест. Так на сервер его можно потавить с диска. На клиента же код может поподать и из Инета. Верификация может гарантировать клиенту, что код полученый из ненадежного источника не содержит опастных системных вызовов или опасной работы с памятью (мсил ведь ничем не отличается по возможностям от ассемблера). Делая .NET MS хотел полностью вытеснить Яву с клиента. А аплеты были некоторым приемуществом Явы.

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

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

S>>Ты всерьез считаешь, что добавить функцию к одному из классов кроссплатформенной библиотеки существенно проще, чем написать две строчки кода? Для добавления функции у меня дня три только на переписку с разработчиками библиотеки уйдет.

S>>Объект не временный. Clear'а у него нет. Ы?

VD>Ну, что я могу сказать... хреновая значит библиотека. В любом случае тот, код кроме как к бардаку не приведет.

Ну все, на стенку полез :) Нормальная библиотека. А вот чем тебе не понравились две строчки стандартного
кода на С++, я не пойму.

S>>Не далее чем в четверг в очередной раз пришлось вспомнить про Q241949. Достало. А еще больше достало шаблоны упрощать, когда VC отказывается их компилировать без всяких видимых причин. По целому дню иногда уходит на обход ошибок в компиляторе. Это теперь называется "ехать"?

VD>У вас прсто не правильный подход. Пистаь нужно на VC, а уж потом портировать (делать код совместимым с...) на другие компиляторы. В других компиляторах тоже есть свои проблемы. Это специфика бумажного стандарта (нет эталона).

Дык что самое смешное, так и делаем. Пишу, например, манипуляторы вывода для специфичных типа в basic_ostream. Все работает, все замечательно. Через некоторое время (месяца два) использую эти классы в другом месте — все работает ровно до тех пор, пока в одной из функций не объявляю локальную переменную типа CString. После чего — internal compiler error :)) Через день траха и шаманства (код то был рабочий, и переписывать/по новой отлаживать его влом) меняю basic_ostream на ostream (если ты забыл, это специализация basic_ostream<char, char_traits<char> > ) — все компиляется. Вот такой вот прикольный компилятор :???: Шаблоны ему слишком сложными показались, мать его...

VD>>>Да в то время не дофига было. Да и сейчас нормальные можно по палцам счесть.

S>>Вот и я о том же.

VD>О чем? До фига не до фига. Есть же! В другом виде вообще нет.

Много всего есть в виде C++ классов с открытым кодом нахаляву. Гораздо лучше чем кот в мешке за немалые деньги.

S>>Да, броузер тяжело. Цепляем в качестве ActiveX. 30% времени, которое лично мне приходиться тратить на поддержку (это уже из отфильтрованных эникейщиками жалоб юзеров), уходит именно на разбирательства с "особенностями" разных версий этого самого броузера. Все никак не выкрою время выкинуть его нафиг и воткнуть wxHTML вместо IE. Хотя придется.

VD>Ну-ну. После этого проблемы с поддержкой продукта конечно кончатся... вместе с клиентами. :)

Посмотрим. Но вот сколько клиентов мы потеряли, включив в дистрибутив MDAC 2.6...

S>>Угу, только 99% этих компонентов написаны одной фирмой.

VD>Ну, не приувеличивай. Есть еще пара сотен компаний специализирующихся на компонентах. Самые большие (Инфрагистик, Видеософт, ...) зарабатывают на этом немалые деньги. Их продукцией пользуются миллионы прогаммистов во всем мире.

А этот прием ведения дискуссии называется демагогией — речь шла о компонентах, из которых состоит полвинды. Ты хочешь сказать, что MS использует в винде компоненты более чем двух сотен компаний, причем именно в качестве компонентов, т.е. не имея исходного кода?

S>> Которая меняет 60% этих компонентов в каждом SP. Довольно далеко от компонентного подхода, IMHO.

VD>Опять приувеличение. Сейчас MS придерживается политики использования параллельно нескольких мерсий компонентнов. Тот же XML-парсер можно установить несколько версий на одну машину.

Только потом хер чего работать будет :) Причем сразу ты этого не заметишь :) И для MS это не компоненты, поскольку у нее есть исходные коды, а не только сигнатуры/документация.

VD>>>Программы падают из-за ошибок, а не из-за применения тех или иных программных парадигм.

S>>Ты отрицаешь, что применение разных парадигм программирования приводит к разному среднему количеству ошибок в программах?

VD>Парадигты — это абстракции очень высокого уровня. От них ошибок быть не может. Все зависти от конкретных реализаций и условий.

Ну, скажем, процедурное программирование пришло на смену spagetti. Ты хочешь сказать, среднее количество ошибок на килобайт екзешника при этом не уменшилось?

S>>Ты пока не сказал, какой именно смысл ты вкладываешь в понятие "компонентная основа". Я, например, не считаю компонентыми две DLL'ки, скомпилированные из одного кода под разные процессоры.

VD>Добавь к длл-кам описание и введи понятие класс/компонент (нечто объеденяющее данные и методы их обработки) и получится компонентная технология. Собственно COM тоже на длл-ках от части основан.

Так вот я утверждаю, что на сегодняшний день единственно полное описание этих Dll'к — это их исходный код. Мысль понятна?

VD>>>Можешь назвать хотябы 3 штуки? И не рендереры. Я лично знаю, только SQL-серверы, да и то только Oracle, MS и почивший Informix. Тут же речь идет, о том что от второго процессора могут начать выигрывать большинство программ.

S>>Ты, видимо, забыл, как работает CreateThread? Почти любая многопоточная программа выигрывает от использования нескольких процессоров.

VD>Ты все же назови эту загадочную "любую программу". ;) А то вон в Ворде этих CreateThread-ов как грязи, а второй процессор ему нафиг не нужен. Под Win32 написание многопоточных приложений выигрывающих от второго процессора — это неординарная задача. Да и под Уних тоже самое. Тот же Оракл до сих пор плюет на потоки и параллелится на уровне процессов.

Орфографию проверять и печатать ему второй процессор не помогает, надо полагать?

VD>>>Дык потоки — это часть того же .NET и Явы. Так что они довольно много знают. Достаточно, чтобы распаралеллить многие вычисления.

S>>Они не знают, сколь долго какой поток будет выполняться и как скоро потребуются результаты. Программист же, как правило, имеет об этом представление.

VD>Дык чтобы сделать qsort использующий два процессора и не нужно знать скль долго будет жить некий поток. К тому же все действия с потоками осуществляются через библиотеки, а они являются частью рантайма. Так что можно сказать что вся информация есть. Ты же скармливаешь рантайму готовый код...

Для одного qsort'а — не надо. А если одновременно с qsort'ом выполняются другие вычисления (еще один qsort, а процессоров всего 2), то очень даже не вредно будет знать, кто из них будет считать дольше и чьи результаты первее понадобяться.

VD>>>Представь, при инсталяции на конкретную систему му узаем что есть четыре процесора... мы копилируем код системных библиотек так, чтобы они параллелили все что получится для этих четырех камней. На системе с двумя камнями параллелим для двух. Ну, а если процессор один, то выкидываем лишний код. На системе без процессора включаем совтвэа-эмулейшон. :)

S>>И что, в .Net есть средства, поддерживающие это?

VD>Для серверного рантайма есть. Клиентский они почему-то считают однопроцесорным.

Что именно? И правда интересно.

S>>В программе на C++ я просто узнаю количество процессоров...

VD>Во-во. Просто попытаешься все сделать сам. Таких как ты много было. Но вот программы которые маштабируются на SMP-системах можно по пальцам сосчитать. Речь идет о том, что потоки будут частично контролироваться рантаймом, и о том, что рабоать с ними станет на порядки проще. В С++ нет даже самого понятия потока. В crt есть кое какие функции, но все это фигня на послом масле.

Есть в posix и boost, этого почти достаточно.

S>> и создаю столько же рабочих потоков, если мне не влом распараллеливать вычисления. Что именно должно происходить в .NET — программе, чтобы сделать то же самое, но автоматически (не спрашивая количество процессоров)?

VD>Дык ты просто пишишь многопоточный код, а рантайм разбирается насклько нужно этот код действительно делать многопоточным. Т.е. он берет информацию из ОС, твой код и творчески его компилирует.

Не верю.

S>> ИМХО, это уже из области искуственного интеллекта, который, к тому же, будет мешать, а не помогать программисту. Этакий Bob In Your Code (TM) :)

VD>Вот только не пойму почему ИИ должен мешать. Если его зачатки есть в программе, то это же просто здорово!

S>>Ещще не факт, что кодогенератор у пользователя знает про процессор, который у этого пользователя установлен. Железо в последнее время чаще софта обновляться стало :)

VD>Дык по умолчанию все джитится (компилируется перед использованием). Да и предкомплированные вещи спокойно перекомпилировать можно.

VD>>>Есть. Кто же спорит. Только мола (задача то не тривиальная) и оптимизируется только чать кода. А тут можно оптимизировать весь. Что же тут плохого?

S>>Я уже говорил — то же делается на C++ компиляцией программы на машине конечного пользователя. А плохого то, что дав не много (оптимизацию на конечной машине и т.д.), .NET отбирает куда больше.

VD>И что же? Да и почему не много? Исходники-то к серьезным коммерческим программам не поставляют. А так автоматическая оптимизация. Причем без единой строчки кода. Что тут плохого. Главное реализовать это все с умом. И оптимизатор отшлифовать под реальные камни.

VD>>>Да. Джит работает сразу после запуска приложения.

S>>>> А она что, бесплатная?

VD>>>Кто она? Оптимизатор входит в рантаймподсистему .NET и Явы...

S>>Я не про $$$, а про секунды. Оптимизация — процесс не быстрый.

VD>А... Ну, вот ты и сравни... Сколько твоя программа будет загружаться и сколько работать. Если ты пишишь утилиту командной строки выполняющую одно-два действия, то время джита для тебя может оказаться критичным. Но если ты пишишь серверное- или GUI-приложение, то компяляция всего лишь замедлит загрузку такого приложения. Для серверного приложения — это вообще не критично. Для клиентского — медленная загрузка. Решение в случае консоли и гуи является ngen (пре джит).

VD>Думаю, в будующем сделают системы которые будут делать автоматический преджит при первом обращении и перекомпиляцию при изменении некторых внешних составлющих. :???:

Здравствуйте m.a.g., Вы писали:

VD>>Значит все таки не всё...

mag>Все, что можно реализовать на C# — точно

Теоритически. На практике может банально не хватить времени и сил.

VD>>Во-во. Существует большое количество чего угодно. Но у меня вот, даже самые опытные программисты время от времени проходятся по памяти.

mag>А для этого есть Bounds Checker и прочее. Для профилактики разок запустить раз в день — все отлавливается превосходно.

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

mag>О резкой смене темы. В исходном сообщении было про бейсик и перл, про бейсик сказал, а вот про перл умолчал, вроде бы ненамеренно...

Вообще-то в исходном сообщении было про С++.

Ну, а ты говорил о строгой типизации. Которй "нет" в бэйсике и перле. Про перл я и не спорю.

mag>>>Это проблемы не C++, а COM
VD>>Аааа. Я то думал — это попытки обойти проблемы C++ связанные с тем что язык вообще не ориентирован на связь с рантаймом.

mag>Не понял фразу. Что есть "связь с рантаймом"?

А то и есть. Все проверки в С++ делаются во время компиялции. Для остальных случаев предлагается вручную шарить по памяти. Это прошлый век. На сегдня нужно использовать рантайм-сервисы типа рефлекшена (динамической информации о типах).

mag>>>, который к C++ отношения не имеет.
VD>>Надо мужикам рассказать... До тебя все думали, что COM писали на C++ и, что у C++ было взято очень многое.

mag>А какая разница на чем писано?

Да! Вот! Какая разница... И что же ты тогда к этому С++ прилип?

mag>Главное, что пытались сделать универсальную систему, вот она такой уродливой и получилась

Она свои задачи прекрасно решает. Уродливой она выглядит из-за полного отсутствия в тогдашних языках какой-либо рантайм-поддержки.

Ты можешь предложить замену для QI? Да так чтобы она не противоречила пипизации С++ и была доступна из других языков и в рантайме?

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

Вот и был изобретен .NET где сразу оговариваются (стандартизуются) некоторые моменты. Т.е. вместо того чтобы подгонять компонентную модель под устаревшие языки было принято решение предявить некоторые требования к самим языкам.

mag>>>Ты когда-нибудь SOM видел? Вот это простая и красивая объектная модель.
VD>>Ты бы ссылку дал, что ли...

mag>Да загнулся он, из-за плохого менеджмента

Жаль. А то COM получатся единственная (если не считать Яву и .NET) компонентная технология дожившая до зрелости.

VD>>Если этот твой сом такой крутой. Что же о нем никто не знает? Она хоть сколько языков поддерживает. И как реализует информацию о типах для рантайма?

mag>Почему никто не знает — см. выше.
mag>Поддерживает она все, на что есть маппинг OMG IDL.

OMG IDL к компонентам никакого отношения не имеет. Он был создан для CORBA. Ну, а CORBA — это действительно разновидность объектного RPC.

mag>В метаклассах.

Т.е. бинарной совместимости там не было?

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

S>А насчет кривости — накой нужна Clear, если есть деструктор? Меньше кода, меньше ошибок.

Есть такая штука — культура программирования.

Ну, а ошибок больше там где грязнее код. Хотя это тоже всего лишь наблюдения.

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

S>А насчет кривости — накой нужна Clear, если есть деструктор? Меньше кода, меньше ошибок.

Мне, кстити, больше ненравится не прямой вызов деструктора, а прямой вызов конструктора. Ну и общее применение одного экземпляра объекта для двух виртуальных объектов. Одно дело симантика подключить/отключить, а другой рукопашный вызов конструктора. Хотя невозможность вызова виртульных методов из деструктора в С++ наталкивает на подобный код. Но это всего лишь еще один недостаток языка.

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

S>Ну все, на стенку полез :) Нормальная библиотека. А вот чем тебе не понравились две строчки стандартного
S>кода на С++, я не пойму.

Тем что это, как сказал один аноним, хакерство. Хотя и отвечающее стандарту. Такой код трудно воспринимать. Экономия от него не большая, а вот проблем с пониманием он может вызвать не мало. Не очень понимаю, почему нельзя быо создать новый экземпляр и присвоить его этому. Ну, или еще как нибудь по-человечески. В конце концов есть такое правило — "не удивляй без крайней необходимости.".

S>Дык что самое смешное, так и делаем. Пишу, например, манипуляторы вывода для специфичных типа в basic_ostream. Все работает, все замечательно. Через некоторое время (месяца два) использую эти классы в другом месте — все работает ровно до тех пор, пока в одной из функций не объявляю локальную переменную типа CString. После чего — internal compiler error :))

Ну, глючат все компиляторв. Это же ведь программы. Я как-то раз задал пол часа не мог понять почему gcc вылетает при компиляции. Потом переставил переменные местами и все зарабтало.

S>Через день траха и шаманства (код то был рабочий, и переписывать/по новой отлаживать его влом) меняю basic_ostream на ostream (если ты забыл, это специализация basic_ostream<char, char_traits<char> > ) — все компиляется. Вот такой вот прикольный компилятор :???: Шаблоны ему слишком сложными показались, мать его...

У нас почти все на шаблонах и проблем не видно.

S>Много всего есть в виде C++ классов с открытым кодом нахаляву. Гораздо лучше чем кот в мешке за немалые деньги.

Ну-ну. Мечтать не вредно. Дай ссылочку на контейнер (а-ля VB) в исходниках да еще и на халяву.

S>Посмотрим.

Посмотрим...

S>Но вот сколько клиентов мы потеряли, включив в дистрибутив MDAC 2.6...

И сколько же? Я так понимаю вместо этого можно было датастрим ручками разбирать?

S>>>Угу, только 99% этих компонентов написаны одной фирмой.

VD>>Ну, не приувеличивай. Есть еще пара сотен компаний специализирующихся на компонентах. Самые большие (Инфрагистик, Видеософт, ...) зарабатывают на этом немалые деньги. Их продукцией пользуются миллионы прогаммистов во всем мире.

S>А этот прием ведения дискуссии называется демагогией — речь шла о компонентах

Ты задал — вопрос используем ли мы компоненты других производителей. Я сказал — да. Ты сказал — что все компоненты делаются одним производителем. Я сказал — нет. Где здесь демогогия?

S>, из которых состоит полвинды. Ты хочешь сказать, что MS использует в винде компоненты более чем двух сотен компаний, причем именно в качестве компонентов, т.е. не имея исходного кода?

А вот это уже и в правду демогогия. Кстит MS действительно использует чужие компоненты. Правда конечно не всех 200 производителей.

VD>>Опять приувеличение. Сейчас MS придерживается политики использования параллельно нескольких мерсий компонентнов. Тот же XML-парсер можно установить несколько версий на одну машину.

S>Только потом хер чего работать будет :) Причем сразу ты этого не заметишь :)

У нас все работает. Может проблема в руках людей делающих инсталляторы?

S>И для MS это не компоненты, поскольку у нее есть исходные коды, а не только сигнатуры/документация.

Класс! Значит компонент — это или нет определяется наличием у тебя исходников. Ну, а как же быть с компонентами которые поставляются вместе с исходниками?

S>Ну, скажем, процедурное программирование пришло на смену spagetti.

А последнее это парадигма? :)

S> Ты хочешь сказать, среднее количество ошибок на килобайт екзешника при этом не уменшилось?

Я хочу сказать, что если сравнить процедурное программирование и ОО, то количество ошибок будет одинаковым и зависящем от класса программиста, используемого языка, качества транслятора, качества библиотек, и еще тучи параметров. В С++, к примеру, ты можешь спрятать управление жизнью ресурсом в конструктор и деструктор обертки. А в ОПасклае нет. Так как деструктор нужно вызывать вручную. Если же сравнивать компонентный подход... Да с чем его вообще можно сравнивать? Он пока что единственный для решения этого класса задач.

S>Так вот я утверждаю, что на сегодняшний день единственно полное описание этих Dll'к — это их исходный код. Мысль понятна?

Ну глупость утверждаешь. Исходный код вообще малопригодное описание. Попробуй сделать "простенький" парсер и вызвать методы динамически (в рантайме). А ведь есть тот-же COM с его tlb по которым динамические вызовы делаются элементарно. Ну, а в .NET это вообще встроеная возможность любого языка.

VD>>Ты все же назови эту загадочную "любую программу". ;) А то вон в Ворде этих CreateThread-ов как грязи, а второй процессор ему нафиг не нужен. Под Win32 написание многопоточных приложений выигрывающих от второго процессора — это неординарная задача. Да и под Уних тоже самое. Тот же Оракл до сих пор плюет на потоки и параллелится на уровне процессов.

S>Орфографию проверять и печатать ему второй процессор не помогает, надо полагать?

Ты когда нибудь открывал в ворде большие документы? Вот я тебе могу сказать, что разницы в количестве процессоров не чувствется. Что есть второй процессор, что нет. :( Проверка же орфографии тоже особо не ускоряется, да и толку от нее нет. На больших документах она все равно отключается. Зато ускорение процессора дает ощутимый результат.

VD>>Для серверного рантайма есть. Клиентский они почему-то считают однопроцесорным.

S>Что именно? И правда интересно.

Ну, открывай мсдн и читай. Или дезасемблируй Анакриной. В основном как я понимаю там оптимизация GC, но наворотили они не моло.

S>Есть в posix и boost, этого почти достаточно.

Я не знаю кому достаточно, но вот софта маштабируемого раз два и обчелся. Если .NET переломит эту ситуация, я буду тлько рад. Ну, а нет, так хуже уже точно не будет. В конце концов работать с потоками в .NET уже сегодня намного проще чем на С++.

Явный offtopic, но не удержался:

Здравствуйте VladD2, Вы писали:
...
VD>Жаль. А то COM получатся единственная (если не считать Яву и .NET) компонентная технология дожившая до зрелости.
...
VD>OMG IDL к компонентам никакого отношения не имеет. Он был создан для CORBA. Ну, а CORBA — это действительно разновидность объектного RPC.

По-моему COM-Java и COM-.NET неправильное противопоставление (сравнение). DCOM-CORBA более логично. Следовательно в Ваших словах намечается противоречие:
либо COM — компонентная технология, значит и CORBA не просто OO RPC;
либо CORBA просто OO RPC, а значит и COM.
Как считаете?
(Замечание на последок. В спецификации 2.6 OMG CORBA появилась компонентная технология. Реализации ростут как на дрожжах.)

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

E>По-моему COM-Java и COM-.NET неправильное противопоставление (сравнение). DCOM-CORBA более логично. Следовательно в Ваших словах намечается противоречие:
E>либо COM — компонентная технология, значит и CORBA не просто OO RPC;

А кто сказал что COM == DCOM? DCOM — это расширение COM-а позволяющее таскать данные по сети. Т.е. это ORPC для COM. CORBA — это чистый ORPC. В новой вестии вроде намечались какие-то компонентные расширения. Но я пока их не видел.

E>либо CORBA просто OO RPC, а значит и COM.
E>Как считаете?

Считаю что у вас произошла подмена понятий.

E>(Замечание на последок. В спецификации 2.6 OMG CORBA появилась компонентная технология. Реализации ростут как на дрожжах.)

Вот когда их увидим, то и говорить будем.

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

mag>>Почему никто не знает — см. выше.
mag>>Поддерживает она все, на что есть маппинг OMG IDL.

VD>OMG IDL к компонентам никакого отношения не имеет. Он был создан для CORBA. Ну, а CORBA — это действительно разновидность объектного RPC.

Но, тем не менее, интерфейсы SOM описывались (к сожалению, в прошедшем времени) на OMG IDL.

mag>>В метаклассах.

VD>Т.е. бинарной совместимости там не было?

Нет. Была идея сделать небольшую и красивую компонентную модель специально для C++.

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

... пропущено

Чтобы не уходить в другую строну от топика ответьте http://www.rsdn.ru/forum/message.asp?mid=90650 пожалуйста.

Здравствуйте m.a.g., Вы писали:

VD>>Т.е. бинарной совместимости там не было?

mag>Нет. Была идея сделать небольшую и красивую компонентную модель специально для C++.

Или это компонентная модель. Или это "специально для C++". Мне не нужна компонентная модель для одного языка. Мы делаем комерческие проекты, а не пишим для души.

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

E>Чтобы не уходить в другую строну от топика ответьте http://www.rsdn.ru/forum/message.asp?mid=90650 пожалуйста.

Ответил.

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

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

S>>Ну все, на стенку полез :) Нормальная библиотека. А вот чем тебе не понравились две строчки стандартного
S>>кода на С++, я не пойму.

VD>Тем что это, как сказал один аноним, хакерство. Хотя и отвечающее стандарту. Такой код трудно воспринимать. Экономия от него не большая, а вот проблем с пониманием он может вызвать не мало. Не очень понимаю, почему нельзя быо создать новый экземпляр и присвоить его этому. Ну, или еще как нибудь по-человечески. В конце концов есть такое правило — "не удивляй без крайней необходимости.".

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

S>>Дык что самое смешное, так и делаем. Пишу, например, манипуляторы вывода для специфичных типа в basic_ostream. Все работает, все замечательно. Через некоторое время (месяца два) использую эти классы в другом месте — все работает ровно до тех пор, пока в одной из функций не объявляю локальную переменную типа CString. После чего — internal compiler error :))

VD>Ну, глючат все компиляторв. Это же ведь программы. Я как-то раз задал пол часа не мог понять почему gcc вылетает при компиляции. Потом переставил переменные местами и все зарабтало.

Ну так я о чем и толкую — весьма посредственный компилятор этот VC 6.0. Явно не заслуживающий своей популярности.

S>>Через день траха и шаманства (код то был рабочий, и переписывать/по новой отлаживать его влом) меняю basic_ostream на ostream (если ты забыл, это специализация basic_ostream<char, char_traits<char> > ) — все компиляется. Вот такой вот прикольный компилятор :???: Шаблоны ему слишком сложными показались, мать его...

VD>У нас почти все на шаблонах и проблем не видно.

Значит, не слишком навороченные шаблоны используете.

S>>Много всего есть в виде C++ классов с открытым кодом нахаляву. Гораздо лучше чем кот в мешке за немалые деньги.

VD>Ну-ну. Мечтать не вредно. Дай ссылочку на контейнер (а-ля VB) в исходниках да еще и на халяву.

Вот комовских контейнеров я и вправду не видал — не любит OpenSource community за рамки языков выходить. Зато есть почти все, чтобы обходиться без COM.

S>>Но вот сколько клиентов мы потеряли, включив в дистрибутив MDAC 2.6...

VD>И сколько же?

Да около сотни, наверное.

VD>Я так понимаю вместо этого можно было датастрим ручками разбирать?

Датастрим — это где? MDAC у нас потянулся из-за грида, который был нужен, чтоб показывать данные нашего же OLE DB провайдера. Выкинули с радостью и грид, и MDAC.

S>>>>Угу, только 99% этих компонентов написаны одной фирмой.

VD>>>Ну, не приувеличивай. Есть еще пара сотен компаний специализирующихся на компонентах. Самые большие (Инфрагистик, Видеософт, ...) зарабатывают на этом немалые деньги. Их продукцией пользуются миллионы прогаммистов во всем мире.

S>>А этот прием ведения дискуссии называется демагогией — речь шла о компонентах

VD>Ты задал — вопрос используем ли мы компоненты других производителей. Я сказал — да. Ты сказал — что все компоненты делаются одним производителем. Я сказал — нет. Где здесь демогогия?

Видимо, тв и вправду забыл, о чем речь шла. Напоминаю — не о тех компонентах, которые вы используете, а о тех, из которых винда состоит:

VD>Ты случам не с Салярки пишешь? Вот и мне кажется из IE запушенного под одной из версий Виндов. Так вот они почти полностью из компонентов состоят. И как видишь живут. Про падучесть это форменный предрассудок.

S>Угу, только 99% этих компонентов написаны одной фирмой. Которая меняет 60% этих компонентов в каждом SP. Довольно далеко от S>компонентного подхода, IMHO.

S>>, из которых состоит полвинды. Ты хочешь сказать, что MS использует в винде компоненты более чем двух сотен компаний, причем именно в качестве компонентов, т.е. не имея исходного кода?

VD>А вот это уже и в правду демогогия. Кстит MS действительно использует чужие компоненты. Правда конечно не всех 200 производителей.

Угу, и исходники MS из сторонних поставщиков тоже вытрясти не в состоянии :)

VD>>>Опять приувеличение. Сейчас MS придерживается политики использования параллельно нескольких мерсий компонентнов. Тот же XML-парсер можно установить несколько версий на одну машину.

S>>Только потом хер чего работать будет :) Причем сразу ты этого не заметишь :)

VD>У нас все работает. Может проблема в руках людей делающих инсталляторы?

Только конечному пользователю это уже не интересно — ему систему переставлять надо :)

S>>И для MS это не компоненты, поскольку у нее есть исходные коды, а не только сигнатуры/документация.

VD>Класс! Значит компонент — это или нет определяется наличием у тебя исходников. Ну, а как же быть с компонентами которые поставляются вместе с исходниками?

S>>Ну, скажем, процедурное программирование пришло на смену spagetti.

VD>А последнее это парадигма? :)

Не худшая парадигма, чем анархия :)

S>> Ты хочешь сказать, среднее количество ошибок на килобайт екзешника при этом не уменшилось?

VD>Я хочу сказать, что если сравнить процедурное программирование и ОО, то количество ошибок будет одинаковым и зависящем от класса программиста, используемого языка, качества транслятора, качества библиотек, и еще тучи параметров. В С++, к примеру, ты можешь спрятать управление жизнью ресурсом в конструктор и деструктор обертки. А в ОПасклае нет. Так как деструктор нужно вызывать вручную. Если же сравнивать компонентный подход... Да с чем его вообще можно сравнивать? Он пока что единственный для решения этого класса задач.

S>>Так вот я утверждаю, что на сегодняшний день единственно полное описание этих Dll'к — это их исходный код. Мысль понятна?

VD>Ну глупость утверждаешь.

Ну тогда признавайся — сколько раз тебе приходилось в отладчике внутри, скажем, MFC'шного кода лазить? И это при вполне добротной документации, практически лучшей в отрасли. Сколько времени тебе наличие исходников сэкономило?

VD> Исходный код вообще малопригодное описание. Попробуй сделать "простенький" парсер и вызвать методы динамически (в рантайме). А ведь есть тот-же COM с его tlb по которым динамические вызовы делаются элементарно. Ну, а в .NET это вообще встроеная возможность любого языка.

А зачем мне что-то в рантайме парсить и вызывать? Чем хуже жесткий набор интерфейсов?

VD>>>Ты все же назови эту загадочную "любую программу". ;) А то вон в Ворде этих CreateThread-ов как грязи, а второй процессор ему нафиг не нужен. Под Win32 написание многопоточных приложений выигрывающих от второго процессора — это неординарная задача. Да и под Уних тоже самое. Тот же Оракл до сих пор плюет на потоки и параллелится на уровне процессов.

S>>Орфографию проверять и печатать ему второй процессор не помогает, надо полагать?

VD>Ты когда нибудь открывал в ворде большие документы? Вот я тебе могу сказать, что разницы в количестве процессоров не чувствется. Что есть второй процессор, что нет. :( Проверка же орфографии тоже особо не ускоряется, да и толку от нее нет. На больших документах она все равно отключается. Зато ускорение процессора дает ощутимый результат.

И че, переписанный под .нет он летать на двухпроцессорной тачке начнет? С чего бы вдруг?

S>>Что именно? И правда интересно.

VD>Ну, открывай мсдн и читай. Или дезасемблируй Анакриной. В основном как я понимаю там оптимизация GC, но наворотили они не моло.

Ну здрасте — я думал мы про Фому беседуем, а ты оказывается, про Ерему :) При чем тут оптимизация GC, если в C++ GC мало кому нужен?
Ты тут чуть ли не про AI рассказывал, а оказывается — это всего лишь реализация многопоточного GC (нетривиальная, должно быть, штука).

S>>Есть в posix и boost, этого почти достаточно.

VD>Я не знаю кому достаточно, но вот софта маштабируемого раз два и обчелся. Если .NET переломит эту ситуация, я буду тлько рад. Ну, а нет, так хуже уже точно не будет. В конце концов работать с потоками в .NET уже сегодня намного проще чем на С++.

Ну дак если .NET сама не умеет потоки плодить (в том же qsort) по числу процессоров, то о каком переломе ситуации идет речь?

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

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

S>>А насчет кривости — накой нужна Clear, если есть деструктор? Меньше кода, меньше ошибок.

VD>Есть такая штука — культура программирования. :) Ну, а ошибок больше там где грязнее код. Хотя это тоже всего лишь наблюдения.

Именно. А код тем грязнее, чем больше в нем ненужных объектов и указателей :)

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

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

S>>А насчет кривости — накой нужна Clear, если есть деструктор? Меньше кода, меньше ошибок.

VD>Мне, кстити, больше ненравится не прямой вызов деструктора, а прямой вызов конструктора.

И правильно не нравиться. Прямой вызов конструктора — хак, не поддерживаемый языком (но допускаемый некотороми компиляторами). Вместо этого есть placement new.

VD>Ну и общее применение одного экземпляра объекта для двух виртуальных объектов. Одно дело симантика подключить/отключить, а другой рукопашный вызов конструктора. Хотя невозможность вызова виртульных методов из деструктора в С++ наталкивает на подобный код. Но это всего лишь еще один недостаток языка.

Прекрасная теория на голом месте. Объект мне там был нужен ровно один, просто ему (это битмап для сохранения куска изображения) надо было поменять размер, чего битмэп не поддерживает :).

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

S>А еще есть правило — не вводить новые сущности без необходимости и не выполнять действия, нужды в которых нет.

И к чему здесь это? Да и вообще что ты под сущьностями здесь понимаешь?

S>Если у кого-то проблемы с пониманием шаблонов C++, так что мне, и их не использовать?

Да и под шаблонами?

А вообще... плюй на все лепи как получается. Код же пишится не для того чтобы его читали другие!

S>Ну так я о чем и толкую — весьма посредственный компилятор этот VC 6.0. Явно не заслуживающий своей популярности.

Он ее уже заслужил. Для работы и его за глаза хватает. Он делался в 96-97 коду и для тех времен он был очень даже ничего. Теперь есть VC7 он по новее.

VD>>У нас почти все на шаблонах и проблем не видно.

S>Значит, не слишком навороченные шаблоны используете.

А нам работать нужно, а не выпендриваться. Проблемы свои решаем. Остальное не наше дело.

VD>>Ну-ну. Мечтать не вредно. Дай ссылочку на контейнер (а-ля VB) в исходниках да еще и на халяву.

S>Вот комовских контейнеров я и вправду не видал — не любит OpenSource community за рамки языков выходить. Зато есть почти все, чтобы обходиться без COM.

Да нихрена путного там нет. Одни игры студентов. Вон Моно уже год делают и что толку?

S>Датастрим — это где? MDAC у нас потянулся из-за грида, который был нужен, чтоб показывать данные нашего же OLE DB провайдера. Выкинули с радостью и грид, и MDAC.

Да ребят что-то у вас там совсем криво. Какой же смысл в OLE DB если ADO не используется? И как же вы без грида то? Хотя можно было бы его и самим написать...

S>Угу, и исходники MS из сторонних поставщиков тоже вытрясти не в состоянии :)

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

VD>>У нас все работает. Может проблема в руках людей делающих инсталляторы?

S>Только конечному пользователю это уже не интересно — ему систему переставлять надо :)

Ну, значит найдет поставцика котоый сделает не только систему но и инсталлятор к ней. ;)

S>>>Ну, скажем, процедурное программирование пришло на смену spagetti.

VD>>А последнее это парадигма? :)

S>Не худшая парадигма, чем анархия :)

А мне кажется это она и есть.

S>>>Так вот я утверждаю, что на сегодняшний день единственно полное описание этих Dll'к — это их исходный код. Мысль понятна?

VD>>Ну глупость утверждаешь.

S>Ну тогда признавайся — сколько раз тебе приходилось в отладчике внутри, скажем, MFC'шного кода лазить?

Ни разу. Я MFC не люблю. Но какое это отношение имеет к твоему утверждению?

S> И это при вполне добротной документации, практически лучшей в отрасли. Сколько времени тебе наличие исходников сэкономило?

Да я не против наличия исходников. Но, ни наличие, ни отсуствие исходников к С++ не изменит того факта, что язык морально устарел и ребует реформы. :)

VD>> Исходный код вообще малопригодное описание. Попробуй сделать "простенький" парсер и вызвать методы динамически (в рантайме). А ведь есть тот-же COM с его tlb по которым динамические вызовы делаются элементарно. Ну, а в .NET это вообще встроеная возможность любого языка.

S>А зачем мне что-то в рантайме парсить и вызывать? Чем хуже жесткий набор интерфейсов?

Тем что все что ты пишишь будет компилирваться как единая сущьность. Вот у нас проекты по двадцать минут копиилируются. Виндовс вобще часами... Ну, еще к твоей программе никто расширение сделать не сможет. Да моного у компонентный технолгий приимуществ. Убеждать тех кто считает, что это никчемная идея я не буду. Вон на ixbt есть Рыбинкин. Так он вообще считает, что С++ это извращение идей ОО и вообще уродство, а С (и его убогий интерпретатор на массивах) лучшее в мире средство разработки. Его всем миром пытались убедить в обратном, но никакого толку в этм нет. Если моги приросли к старому и на горизонте нет задач которые были бы сложенее чем те что ты уже решал, то понять зачем нужно новое невозможно. Вот понадобятся тебе атрибуты компонентной технологии, вот тогда ты и сам задумешься изобретать ли тебе велосипед или взять готовый.

S>И че, переписанный под .нет он летать на двухпроцессорной тачке начнет? С чего бы вдруг?

Дык люди всю рантайм-подсистему для этого затачивают.

S>Ну здрасте — я думал мы про Фому беседуем, а ты оказывается, про Ерему :) При чем тут оптимизация GC, если в C++ GC мало кому нужен?

Он многим там нужнет. Вот только встроить его туда безшовно без изменения языка невозможно. Слабоват язык. Расширяется хреново, а Страуступ перешел в стан консерваторов. :)

S>Ты тут чуть ли не про AI рассказывал, а оказывается — это всего лишь реализация многопоточного GC (нетривиальная, должно быть, штука).

Я сразу сказал, что сделано на сегодня не много. Но уже хоть что-то. В обычном мире (анмэнеджет) и того нет.

S>Ну дак если .NET сама не умеет потоки плодить (в том же qsort) по числу процессоров, то о каком переломе ситуации идет речь?

Дык вот они и делают рантайм который будет учитывать особенности железа.

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

VD>>Есть такая штука — культура программирования.

Ну, а ошибок больше там где грязнее код. Хотя это тоже всего лишь наблюдения.

S>Именно. А код тем грязнее, чем больше в нем ненужных объектов и указателей

Понимаешь ли в чем дело?... Объектов должно быть не много и не мало, а в самый раз. И указатли нужы только там где они нужны. И грязь появляется там где человек не хочет думать о коллективе в котором он работает.

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

VD>А вообще... плюй на все лепи как получается. Код же пишится не для того чтобы его читали другие!

Ладно, эта тема исчерпала себя.

S>>Ну так я о чем и толкую — весьма посредственный компилятор этот VC 6.0. Явно не заслуживающий своей популярности.

VD>Он ее уже заслужил. Для работы и его за глаза хватает. Он делался в 96-97 коду и для тех времен он был очень даже ничего.

И ни в одном из пяти сервис паков практически ни одну серьезную ошибку, связанную с шаблонами, не исправили.

VD>Теперь есть VC7 он по новее.

И почти такой же убогий :) Не, кое-что, конечно поправили, но ключевые фичи шаблонов до сих пор не поддерживаются. Blitz++ под него не компилиться (абыдна), от буста — только половина (еще абыдней).

VD>>>У нас почти все на шаблонах и проблем не видно.

S>>Значит, не слишком навороченные шаблоны используете.

VD>А нам работать нужно, а не выпендриваться. Проблемы свои решаем. Остальное не наше дело.

Проблемы у всех разные.

VD>>>Ну-ну. Мечтать не вредно. Дай ссылочку на контейнер (а-ля VB) в исходниках да еще и на халяву.

S>>Вот комовских контейнеров я и вправду не видал — не любит OpenSource community за рамки языков выходить. Зато есть почти все, чтобы обходиться без COM.

VD>Да нихрена путного там нет. Одни игры студентов. Вон Моно уже год делают и что толку?

Надо просто смотреть на те проекты, которые лет пять-десять делают :) Если их за это время не забросили, значит жить будут.

S>>Датастрим — это где? MDAC у нас потянулся из-за грида, который был нужен, чтоб показывать данные нашего же OLE DB провайдера. Выкинули с радостью и грид, и MDAC.

VD>Да ребят что-то у вас там совсем криво. Какой же смысл в OLE DB если ADO не используется? И как же вы без грида то? Хотя можно было бы его и самим написать...

OLE DB юзается напрямую, грид теперь свой, затраты на поддержку этого кода стремятся к нулю. А если клиентам нужен доступ к нашему провайдеру через ADO, пусть сами его ставят — мы тут не причем, все вопросы к MS :) Конечно, такие перлы как MDAC 2.6 MS не часто выдает, но вот последствия от них уж больно неприятные.

S>>Угу, и исходники MS из сторонних поставщиков тоже вытрясти не в состоянии :)

VD>А какая разница? Компонент интересен своей отчуждаемостью, а не тем есть ли у него исходники или нет.

Я совсем не против компонентов с исходниками :) Только таких что-то не попадается...

S>>>>Так вот я утверждаю, что на сегодняшний день единственно полное описание этих Dll'к — это их исходный код. Мысль понятна?

VD>>>Ну глупость утверждаешь.

S>>Ну тогда признавайся — сколько раз тебе приходилось в отладчике внутри, скажем, MFC'шного кода лазить?

VD>Ни разу. Я MFC не люблю. Но какое это отношение имеет к твоему утверждению?

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

S>> И это при вполне добротной документации, практически лучшей в отрасли. Сколько времени тебе наличие исходников сэкономило?

VD>Да я не против наличия исходников. Но, ни наличие, ни отсуствие исходников к С++ не изменит того факта, что язык морально устарел и ребует реформы. :)

Я тоже не отрицаю того факта, что в C++ много не хватает. Но GC уж точно не является самой востребованной фичей.

VD>>> Исходный код вообще малопригодное описание. Попробуй сделать "простенький" парсер и вызвать методы динамически (в рантайме). А ведь есть тот-же COM с его tlb по которым динамические вызовы делаются элементарно. Ну, а в .NET это вообще встроеная возможность любого языка.

S>>А зачем мне что-то в рантайме парсить и вызывать? Чем хуже жесткий набор интерфейсов?

VD>Тем что все что ты пишишь будет компилирваться как единая сущьность. Вот у нас проекты по двадцать минут копиилируются. Виндовс вобще часами... Ну, еще к твоей программе никто расширение сделать не сможет. Да моного у компонентный технолгий приимуществ. Убеждать тех кто считает, что это никчемная идея я не буду. Вон на ixbt есть Рыбинкин.

Угу, а в фидо обитает Луговский, так он ничего, кроме функциональных языков не переваривает и вообще ведет себя неадекватно. Ну и что с того?

VD>Так он вообще считает, что С++ это извращение идей ОО и вообще уродство, а С (и его убогий интерпретатор на массивах) лучшее в мире средство разработки.

Я тоже считаю, что C++ — это коммерчески успешное извращение идей ОО. Уродства в C++ тоже хватает. А C — вообще древнее убожество. Не видел, правда, С99, но думаю, и там ситуация не сахар. Только вот ничего более путного пока, к сожалению, не сделали. И вряд ли в ближайшем будущем сделают. Хотя могли бы.

VD>Его всем миром пытались убедить в обратном, но никакого толку в этм нет. Если моги приросли к старому и на горизонте нет задач которые были бы сложенее чем те что ты уже решал, то понять зачем нужно новое невозможно.

Я ж не говорю, что новое не нужно. Я говорю, что сделали это новое как всегда, а не как лучше. Отобрали больше, чем добавили.

VD>Вот понадобятся тебе атрибуты компонентной технологии, вот тогда ты и сам задумешься изобретать ли тебе велосипед или взять готовый.

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

S>>И че, переписанный под .нет он летать на двухпроцессорной тачке начнет? С чего бы вдруг?

VD>Дык люди всю рантайм-подсистему для этого затачивают.

В чем именно эта заточка заключается? Про GC я уже слышал.

S>>Ну здрасте — я думал мы про Фому беседуем, а ты оказывается, про Ерему :) При чем тут оптимизация GC, если в C++ GC мало кому нужен?

VD>Он многим там нужнет. Вот только встроить его туда безшовно без изменения языка невозможно.

Безболезненно GC вообще никуда не встроить. C GC ведь не определен момент вызова деструкторов, что очень фигово при работе с внешними объектами. Так что или Finilize руками вызывай, или delete не забывай писать — хрен редьки не слаще.

VD>Слабоват язык. Расширяется хреново, а Страуступ перешел в стан консерваторов. :)

Это еще вопрос, кто больший консерватор — Страуступ или Мокрософт. Они б сначала для имеющегося языка компилятор реализовали, а потом новые идеи толкали. Подозреваю, что в комитете им примерно это же и сказали бы, если б они туда с новшествами сунулись.

S>>Ты тут чуть ли не про AI рассказывал, а оказывается — это всего лишь реализация многопоточного GC (нетривиальная, должно быть, штука).

VD>Я сразу сказал, что сделано на сегодня не много. Но уже хоть что-то. В обычном мире (анмэнеджет) и того нет.

В обычном мире это просто не нужно.

S>>Ну дак если .NET сама не умеет потоки плодить (в том же qsort) по числу процессоров, то о каком переломе ситуации идет речь?

VD>Дык вот они и делают рантайм который будет учитывать особенности железа.

И что, этот рантайм будет плодить потоки без участия программиста, ориентируясь по контексту вычислений? Когда MS реализует это в своем рантайме, железо будет само учитывать свои особенности :) Оно уже сейчас зачастую делает это лучше софта.

Здравствуйте Аноним, Вы писали:

[...]

ГВ>>ИМХО, больше похоже на попытку причесать все языки под одну гребёнку .NET :maniac:

А>сам-то понял, чё написал?

Конечно. Вот ещё раз CLS перечитаю, если найду. И докажу. ;) Возможно.

А>опять сказки про злого Дядю Билла, который всех "причесывает"...

И то верно — он никого не причёсывает, все сами "причёсываются". ;)

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

ГВ>И то верно — он никого не причёсывает, все сами "причёсываются".

Интересно, когда Страус все причесывает своими кривыми идеями, то это нормально и называется "стандартизация", ну, если MS стандарты клепать начинает, то это называется "причесывание всех под одну гребенку" и "угнетение невинно обиженных".

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

VD>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>И то верно — он никого не причёсывает, все сами "причёсываются". ;)

VD>Интересно, когда Страус все причесывает своими кривыми идеями, то это нормально и называется "стандартизация", ну, если MS стандарты клепать начинает, то это называется "причесывание всех под одну гребенку" и "угнетение невинно обиженных". :)))

Во-первых, не один Страус. Там ещё и комитет ANSI есть.
А во-вторых — ИМХО, Страус больше апеллирует к интеллектуальности, а MS — к её отсутствию. Типа: "Вот вам рецепт и всем срочно радоваться!" Вторая позиция понятна для продавцов, но... программисты, ИМХО, всё-таки больше тяготеют к первому.

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

ГВ>Во-первых, не один Страус. Там ещё и комитет ANSI есть.
ГВ>А во-вторых — ИМХО, Страус больше апеллирует к интеллектуальности, а MS — к её отсутствию. Типа: "Вот вам рецепт и всем срочно радоваться!" Вторая позиция понятна для продавцов, но... программисты, ИМХО, всё-таки больше тяготеют к первому.

Да к маразму старческому (не по годам) этот Страуструп апеллирует. А MS решает проблемы кторые перед ней стаят. Этот орел как то ляпнул, что мол GC интересная и хорошая идея, но мол, ее легко можно реализовать средствами языка. Вот Мишка.Нэт попробывал риалзоват... вошло как у тебя, много кода и совершенно не применимо на практике.

Хочет решать проблемы средствами самого языка? Пожалуйста... только пусть этот язык расширят, чтобы можно было делать то что нужно. И не через одно место автогеном, а просто и лаконично.

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

VD>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Во-первых, не один Страус. Там ещё и комитет ANSI есть.
ГВ>>А во-вторых — ИМХО, Страус больше апеллирует к интеллектуальности, а MS — к её отсутствию. Типа: "Вот вам рецепт и всем срочно радоваться!" Вторая позиция понятна для продавцов, но... программисты, ИМХО, всё-таки больше тяготеют к первому.

VD>Да к маразму старческому (не по годам) этот Страуструп апеллирует.

Ладно, давай без личностей ;)

VD>А MS решает проблемы кторые перед ней стаят.

Путём создания волны новых? Кстати, у тебя интересная, почти фрейдистская описка: последнее слово должно быть "стаВят" или "стОят"? Если "ставят", то хрен они что исправили в том же компиляторе C++, а если "стоят", то это её проблемы, пусть себе решает на здоровье. Нет. я не против маркетинга, я просто стараюсь ему не подчиняться.

VD>Этот орел как то ляпнул, что мол GC интересная и хорошая идея, но мол, ее легко можно реализовать средствами языка. Вот Мишка.Нэт попробывал риалзоват... вошло как у тебя, много кода и совершенно не применимо на практике. :(

Значит, не особо нуждались, раз не стали применять. ;) (ИМХО)

VD>Хочет решать проблемы средствами самого языка? Пожалуйста... только пусть этот язык расширят, чтобы можно было делать то что нужно. И не через одно место автогеном, а просто и лаконично.

Да пусть его хоть в рамках определения реализуют! Тогда только будет ясно, что именно в него надо добавлять.

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

IT>>Архитектурно реализуется перехваткой обращений к методам объекта, благо там и так прокси разнообразные просто кишат

Ну а в C# есть... даже не в C# а в .NET, пожалуй.. поддержка этого дела. Ты можешь создать объект, а потом заставить другой объект вклиниваться в вызовы методов первого. В "Inside C#" Арчера есть немного об этом.
M.NET>Ну-ка ткни пальцем где такое написано, я это уже давно ищу — не знал что в .NET это есть.

Есть конечно.
Вот это чем не аспекты-перехватчики?
http://www.rsdn.ru/forum/message.asp?mid=85528&only

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

VD>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>И то верно — он никого не причёсывает, все сами "причёсываются". ;)

VD>Интересно, когда Страус все причесывает своими кривыми идеями, то это нормально и называется "стандартизация", ну, если MS стандарты клепать начинает, то это называется "причесывание всех под одну гребенку" и "угнетение невинно обиженных". :)))

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

Здравствуйте <Аноним>, Вы писали:

А>Подобные заявления означают, что ты вообще ничего не понимаешь в том, как происходила стандартизация C++ и больше говорят о тебе, чем о Страуструпе. Ты бы почитал что-нибудь.

Ты бы прежде чем народ обкакивать представился бы что ли, а то некрасиво получается однако.

... Янус v1.0alpha (только для тестовых целей)

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

M.NET>Здравствуйте Igor Trofimov, Вы писали:

IT>>Ты написал объект и он работает в middletier звене каком-то. А другой кто-то (может, MS, а может Вася) написал...хм...как называется-то? аспект? — и теперь есть возможность применения на административном уровне к твоему объекту некоторой функциональности. Админ это может настроить.

M.NET>На самом деле не админ, а программер. Создаём аспект, говорим в нём, что если кто-то, например, вызвал метод с такой сигнатурой, то надо выполнить такой-то код. Или, куда интереснее, если произошло исключение в таких-то методах, то выполнить то-то и то-то. То бишь — один чел пишет прогу не думая об обработке исключений, security и пр. А другие пишут к его коду соответствующие аспекты.

IT>>COM+ короче.
M.NET>COM+ поддерживает только зачатки аспектной ориентации.

Я так понял, спор уже зашёл о run-time-поддержке выполнения с подгрузкой нового кода на лету без остановки и перекомпиляции всего приложения и даже системы.
Интересный момент. В C# такое возможно на уровне классов? В Java -- да, в С/C++ -- нет.

Небольшой пример для Java: интерфейс и "пусковик" пишутся и компилируются на самой ранней стадии, а вот классы, реализующие интерфейс, пишутся значительно позднее и могут подключаться к работающей системе на лету, тем самым реализуется в run-time нужный аспект.

public interface Figure {
   ...
   void paint();
}

Классы, написанные и откомпилированные позднее:

public class Oval implements Figure {
   ...//Реальный код
   public void paint() {
      ...//Реальный код
   }
}

public class Rectangle implements Figure {
   ...//Реальный код
   public void paint() {
      ...//Реальный код
   }
}

Запускаем любой код, реализующий интерфейс Figure:

import java.util.Properties;
import java.io.*;

public class FigureLauncher {
   private FigureLauncher() {//Синглетон
      super();
   }
   public static void main(String args[]) {
      try {
         String fileproperties = args[0];
         InputStream propStream = new FileInputStream(fileproperties);
         Properties properties = new Properties();
         properties.load(propStream);
         String launchableClassName = properties.getProperty("launchableclass");
         Class serviceClass = Class.forName(launchableClassName);
         Object serviceObject = serviceClass.newInstance();
         //Работаем с объектом:
         (Figure)serviceObject....//...
         (Figure)serviceObject.paint();
      } catch (Exception e) {
         System.out.println("Ошибка:");
         e.printStackTrace();
      }
   }
}

Файл настроек пусковика (структуру можно усложнить):

#FigureLaunch.prooperties
launchableclass=Rectangle

IT>>Архитектурно реализуется перехваткой обращений к методам объекта, благо там и так прокси разнообразные просто кишат ;) Ну а в C# есть... даже не в C# а в .NET, пожалуй.. поддержка этого дела. Ты можешь создать объект, а потом заставить другой объект вклиниваться в вызовы методов первого. В "Inside C#" Арчера есть немного об этом.
M.NET>Ну-ка ткни пальцем где такое написано, я это уже давно ищу — не знал что в .NET это есть.

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

ZEN>Я так понял, спор уже зашёл о run-time-поддержке выполнения с подгрузкой нового кода на лету без остановки и перекомпиляции всего приложения и даже системы.
ZEN>Интересный момент. В C# такое возможно на уровне классов? В Java -- да, в С/C++ -- нет.
В шарпе такое намного проще, ввиду того что компиляторы в виде классов есть в рантайме, умеют компилировать в память, стандартный класслоадер умеет shadow copy files, а Reflection.Emit позволяет формировать сборки в памяти вобще без компиляторов.

IT>>>Архитектурно реализуется перехваткой обращений к методам объекта, благо там и так прокси разнообразные просто кишат

Ну а в C# есть... даже не в C# а в .NET, пожалуй.. поддержка этого дела. Ты можешь создать объект, а потом заставить другой объект вклиниваться в вызовы методов первого. В "Inside C#" Арчера есть немного об этом.
M.NET>>Ну-ка ткни пальцем где такое написано, я это уже давно ищу — не знал что в .NET это есть.
Посмотри в ремоутинге.

... Янус v1.0alpha (только для тестовых целей)

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

VD>>Да к маразму старческому (не по годам) этот Страуструп апеллирует.

ГВ>Ладно, давай без личностей

Так ты первый заговорил о велиичии личностей "Страус больше апеллирует к интеллектуальности".

ГВ>Путём создания волны новых? Кстати, у тебя интересная, почти фрейдистская описка: последнее слово должно быть "стаВят" или "стОят"? Если "ставят", то хрен они что исправили в том же компиляторе C++, а если "стоят", то это её проблемы, пусть себе решает на здоровье. Нет. я не против маркетинга, я просто стараюсь ему не подчиняться.

Второе (стоят). Ты подчиняешся догмам, хотя сам понимаешь, что что-то нужно менять.

ГВ>Значит, не особо нуждались, раз не стали применять.

(ИМХО)

Просто реализовать удобный GC без поддержки компилятора невозможно. А Страуструп просто языком молол без соображения. У него похоже догмы еще глубже сидят. Ну, возможно пора давать дорогу молодым.

ГВ>Да пусть его хоть в рамках определения реализуют! Тогда только будет ясно, что именно в него надо добавлять.

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

Оппс...Поспешил. Синтаксическая ошибка.

<...>
     Class serviceClass = Class.forName(launchableClassName);
     Object serviceObject = serviceClass.newInstance();
     //Работаем с объектом:
     (Figure)serviceObject....//...<<--Синтаксическая ошибка.
     (Figure)serviceObject.paint();<<--Синтаксическая ошибка.
<...>

Исправляю:

<...>
     Class serviceClass = Class.forName(launchableClassName);
     Object serviceObject = serviceClass.newInstance();
     //Работаем с объектом:
     ((Figure)serviceObject)....//...<<-- уже правильно
     ((Figure)serviceObject).paint();//<<-- уже правильно
<...>

Так ещё лучше:

<...>
     Class serviceClass = Class.forName(launchableClassName);
     Object serviceObject = serviceClass.newInstance();
     //Работаем с объектом:
     Figure f = (Figure)serviceObject;//Преобразуем ссылку к нужному типу
     f....//...
     f.paint();
<...>

Здравствуйте Аноним, Вы писали:

А>Подобные заявления означают, что ты вообще ничего не понимаешь в том, как происходила стандартизация C++ и больше говорят о тебе, чем о Страуструпе. Ты бы почитал что-нибудь.

Я я что-нибудь почитал. Но стандарт от этого прямее не стал. Да и у MS многое стандартизовано. Тот же .NET. Да и для меня нет разницы между стандартами дефакто и бумажными. Первые мне даже больше нарвятся. Они к жизни ближе. Я когда писал на С, всегда предпочитал вариант Ричи, чем ансишный.

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

<....>
VD>А мне трехэтажные кострукции не нужны. Они расширяют язык не туда. Нужно решать проблемы людей, а они придумывают ерунду которая все равно не решает всех проблем, но создает огромные проблемы у разработчиков компиляторов.

Согласен. Можно посмотреть на CORBA: такая огромная спецификация, а чтобы разрабатывать под неё придётся знать всё...:)

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

ZEN>Я так понял, спор уже зашёл о run-time-поддержке выполнения с подгрузкой нового кода на лету без остановки и перекомпиляции всего приложения и даже системы.
ZEN>Интересный момент. В C# такое возможно на уровне классов? В Java -- да, в С/C++ -- нет.

Нет, спор идёт о другом (конкретно аспектах). То, что ты имеешь в виду называется Reflection. Этот механизм присутствует и в Java и в .NET.

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

VD>Я когда писал на С, всегда предпочитал вариант Ричи, чем ансишный.

Ты такое больше не пиши! А то слабонервные могут в обморок упасть. И твоя совесть будет мучиться из-за шишек на их головах.

Расскажи-ка мне про преимущества Си Кернигана и Ритчи на примере следующего фрагмента:

double sqrt(x)
double x;
{
/* какой-то код */
}

main()
{
    double z = sqrt(2);
}

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

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

ZEN>>Я так понял, спор уже зашёл о run-time-поддержке выполнения с подгрузкой нового кода на лету без остановки и перекомпиляции всего приложения и даже системы.
ZEN>>Интересный момент. В C# такое возможно на уровне классов? В Java -- да, в С/C++ -- нет.
AVK>В шарпе такое намного проще, ввиду того что компиляторы в виде классов есть в рантайме, умеют компилировать в память, стандартный класслоадер умеет shadow copy files, а Reflection.Emit позволяет формировать сборки в памяти вобще без компиляторов.

В Java такое тоже возможно (сам компилятор написан на Java): хоть из массива, хоть из потока, хоть с COM-порта.

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

ZEN>В Java такое тоже возможно (сам компилятор написан на Java): хоть из массива, хоть из потока, хоть с COM-порта.

А знаешь, что стандартная Java не поддерживает? Компиляцию динамически созданного кода в native код процессора.

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

ZEN>В Java такое тоже возможно (сам компилятор написан на Java): хоть из массива, хоть из потока, хоть с COM-порта.
Возможно, но никакого API под это нет, нужно писать свой класслоадер.

... Янус версия 1.0 alpha 2

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

VD>>>Да к маразму старческому (не по годам) этот Страуструп апеллирует.
ГВ>>Ладно, давай без личностей ;)
VD>Так ты первый заговорил о велиичии личностей "Страус больше апеллирует к интеллектуальности".

Ну, если бы не он был автором и "ведущим кем-то там" по разработке языка, то я упомянул бы другого. Я аргументировал только его подходом, а не личными качествами (маразмом там, старостью, генальностью и пр.) Аналогично и про MS. Возможно, фраза была несколько неудачно построена... :(

ГВ>>Путём создания волны новых? Кстати, у тебя интересная, почти фрейдистская описка: последнее слово должно быть "стаВят" или "стОят"? Если "ставят", то хрен они что исправили в том же компиляторе C++, а если "стоят", то это её проблемы, пусть себе решает на здоровье. Нет. я не против маркетинга, я просто стараюсь ему не подчиняться.

VD>Второе (стоят). Ты подчиняешся догмам, хотя сам понимаешь, что что-то нужно менять.

Опять к личностям. OK. Тогда назови хоть одну из тех догм, которым я, по твоему мнению, подчиняюсь.

ГВ>>Значит, не особо нуждались, раз не стали применять. ;) (ИМХО)

VD>Просто реализовать удобный GC без поддержки компилятора невозможно.

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

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

От блин! :) Vlad, давай больше Страуса вообще не будем упоминать. И Гейтса лично тоже. :)

ГВ>>Да пусть его хоть в рамках определения реализуют! Тогда только будет ясно, что именно в него надо добавлять.

VD>А мне трехэтажные кострукции не нужны. Они расширяют язык не туда. Нужно решать проблемы людей, а они придумывают ерунду которая все равно не решает всех проблем, но создает огромные проблемы у разработчиков компиляторов.

Ты хочешь сказать, что что-то может решить все проблемы? Этакий философский камень? ;)

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

ГВ>Ну, если бы не он был автором и "ведущим кем-то там" по разработке языка, то я упомянул бы другого. Я аргументировал только его подходом, а не личными качествами (маразмом там, старостью, генальностью и пр.) Аналогично и про MS. Возможно, фраза была несколько неудачно построена...

Правильно интеллектуальность не качество.

ГВ>Опять к личностям. OK. Тогда назови хоть одну из тех догм, которым я, по твоему мнению, подчиняюсь.

"С++ законченый язык. Его средствами можно реализовать хоть черта лысого, а занчит менять в нем ничего не нужно."

ГВ>От блин!

Vlad, давай больше Страуса вообще не будем упоминать. И Гейтса лично тоже.

Ну, тогда и на MS нечего клепать.

VD>>А мне трехэтажные кострукции не нужны. Они расширяют язык не туда. Нужно решать проблемы людей, а они придумывают ерунду которая все равно не решает всех проблем, но создает огромные проблемы у разработчиков компиляторов.

ГВ>Ты хочешь сказать, что что-то может решить все проблемы? Этакий философский камень?

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

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

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

ZEN>>В Java такое тоже возможно (сам компилятор написан на Java): хоть из массива, хоть из потока, хоть с COM-порта.

M>А знаешь, что стандартная Java не поддерживает? Компиляцию динамически созданного кода в native код процессора.

Это не проблема написать на Java, например, Pascal-компилятор для DOS/Windows (теория компиляторов знакома, надеюсь?). Но вот вопрос: зачем это нужно, когда многие вещи в самой Java делаются проще и быстрее(JIT) чем во многих старых компилируемых языках (операции по управлению памятью для строк, например). Так что возражения типа "в нативном коде быстрее будет" не принимаются -- просто это из другой области.

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

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

ZEN>>В Java такое тоже возможно (сам компилятор написан на Java): хоть из массива, хоть из потока, хоть с COM-порта.
AVK>Возможно, но никакого API под это нет, нужно писать свой класслоадер.

Для COM-порта есть JavaAPI.
Свой класслоадер наследуешь от абстрактного класса java.lang.ClassLoader, переопрееляешь пару-тройку методов и всё. :))

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

ГВ>>Ну, если бы не он был автором и "ведущим кем-то там" по разработке языка, то я упомянул бы другого. Я аргументировал только его подходом, а не личными качествами (маразмом там, старостью, генальностью и пр.) Аналогично и про MS. Возможно, фраза была несколько неудачно построена... :(

VD>Правильно интеллектуальность не качество. ;)

Смешно. :)

ГВ>>Опять к личностям. OK. Тогда назови хоть одну из тех догм, которым я, по твоему мнению, подчиняюсь.

VD>"С++ законченый язык. Его средствами можно реализовать хоть черта лысого, а занчит менять в нем ничего не нужно."

А вот и неверно. :P Не нужно "улучшать" не реализованное ещё по сути средство. Вот будут компиляторы — тогда и обсудим. А поменять в C++ кое-что мне тоже хотелось бы.

ГВ>>От блин! :) Vlad, давай больше Страуса вообще не будем упоминать. И Гейтса лично тоже. :)

VD>Ну, тогда и на MS нечего клепать.

Я на неё и не клепаю. Пусть делает что хочет! Просто, ИМХО, отдаю себе отчёт, что её действия продиктованы маркетинговыми соображениями. И следы этого подхода есть, в том числе, и в языке программирования, который (возможно, — ошибочно) противопоставлен другому языку, с гораздо более развитой моделью. Следы эти таковы, что C# "упростился" для ускорения изучения, но из него выброшено много, ИМХО, важного. Прежде всего, того, что касается комбинирования абстракций. Вот, собственно.

[...]

VD>Я хочу сказать, что если проблемы есть, то их нужно решать, а не городить огород на ровном месте и не объяснять, что мол, а мне и так нравится.

Один из вопросов, который предлагается задать себе авторам предложений по расширению C++:

"Можно ли это сделать имеющимися средствами языка?"

Может, несколько переврал текст, но смысл, вроде, не исказил. Кстати, я абсолютно согласен с тем, что если что-то можно сделать имеющимися средствами, то "нечего огород городить" (c) за счёт расширения языка, как такового. Зачем создавать дополнительную сущность?

Например, я показал тебе "делегатами", что такую, в частности, штуку можно сделать на базе обычного C++. ==> Незачем вводить такое языковое расширение.

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

ZEN>Для COM-порта есть JavaAPI.
ZEN>Свой класслоадер наследуешь от абстрактного класса java.lang.ClassLoader, переопрееляешь пару-тройку методов и всё.

Ты не понял о чем речь. Посмотри на классы из System.Reflection.Emit. Подобного в джаве нет.

... Янус версия 1.0 alpha 2

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

ГВ>А вот и неверно. :P Не нужно "улучшать" не реализованное ещё по сути средство. Вот будут компиляторы — тогда и обсудим. А поменять в C++ кое-что мне тоже хотелось бы.
Это уже не смешно. За сколько там лет существования С++ не сделали ни одного нормального компилятора. Так может сам язык в этом виноват?

ГВ>Я на неё и не клепаю. Пусть делает что хочет! Просто, ИМХО, отдаю себе отчёт, что её действия продиктованы маркетинговыми соображениями. И следы этого подхода есть, в том числе, и в языке программирования, который (возможно, — ошибочно) противопоставлен другому языку, с гораздо более развитой моделью.
Елки палки, устали уже тебе объяснять что модель у С++ довольно однобоко развита. Вся его развитость начинается и заканчивается шаблонами и множественным наследованием реализаций. Когда же тебе приводят кучу вещей когда шарп намного гибче плюсов, ты либо говоришь что это не имеет отношения к языку либо не нужно. Знаешь, уже не интересно. Можно сколь угодно доказывать идеологическую правильность плюсов но практика говорит что на шарпе проекты пишутся быстрее и сменьшим количеством ошибок. И код получается значительно понятнее и легче модифицируемым.

ГВ> Следы эти таковы, что C# "упростился" для ускорения изучения, но из него выброшено много, ИМХО, важного.
Знаешь, даже у древних людей много это было больше двух. А здесь пока ничего кроме шаблонов и множ. наследования реализаций я пока не слышал.

ГВ>Прежде всего, того, что касается комбинирования абстракций. Вот, собственно.
С++ и рядом не стоял в плане создания всевозможных прокси-классов. Вот тебе и твое комбинирование.

ГВ>"Можно ли это сделать имеющимися средствами языка?"

ГВ>Может, несколько переврал текст, но смысл, вроде, не исказил. Кстати, я абсолютно согласен с тем, что если что-то можно сделать имеющимися средствами, то "нечего огород городить" (c) за счёт расширения языка, как такового. Зачем создавать дополнительную сущность?

Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

... Янус версия 1.0 alpha 2

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

AVK>Здравствуйте <Аноним>, Вы писали:

А>>Подобные заявления означают, что ты вообще ничего не понимаешь в том, как происходила стандартизация C++ и больше говорят о тебе, чем о Страуструпе. Ты бы почитал что-нибудь.

AVK>Ты бы прежде чем народ обкакивать представился бы что ли, а то некрасиво получается однако.

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

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

VD>Здравствуйте Аноним, Вы писали:

А>>Подобные заявления означают, что ты вообще ничего не понимаешь в том, как происходила стандартизация C++ и больше говорят о тебе, чем о Страуструпе. Ты бы почитал что-нибудь.

VD>Я я что-нибудь почитал. Но стандарт от этого прямее не стал. Да и у MS многое стандартизовано. Тот же .NET. Да и для меня нет разницы между стандартами дефакто и бумажными. Первые мне даже больше нарвятся. Они к жизни ближе. Я когда писал на С, всегда предпочитал вариант Ричи, чем ансишный.

Многое стандартизовано? Что например? А, ну конечно, я совершенно забыл про ECMA стандарт на C#. Интересно, смогут ли они так же быстро протащить его через ISO? Что касается варианта Ричи vs ANSI, то эту чушь я даже комментировать не буду.

Здравствуйте <Аноним>, Вы писали:

А>Неужели менее красиво, чем рассуждать о том, в чем совершенно не разбираешься
Вот лично вас я не знаю и уровень ваш не неизвестен. Кто такой Влад я знаю, и сколько он на С++ питсал я тоже знаю. Так что пока что доверия больше ему.

А> и при этом коверкать фамилии людей, которые уж точно знают гораздо больше?
Не стоит возводить себе идолов, это грех. Вон Эйнштейн на что гениальный физик, но в квантовую механику так и не поверил до своей смерти, хотя сам же заложил ее основы. Любым людям свойственно ошибаться, даже гениальным.

... Янус версия 1.0 alpha 2

Здравствуйте <Аноним>, Вы писали:

А>Многое стандартизовано? Что например? А, ну конечно, я совершенно забыл про ECMA стандарт на C#.
Есть еще стандарт на CLI того же ECMA.

... Янус версия 1.0 alpha 2

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

VD>>"С++ законченый язык. Его средствами можно реализовать хоть черта лысого, а занчит менять в нем ничего не нужно."

ГВ>А вот и неверно. :P Не нужно "улучшать" не реализованное ещё по сути средство. Вот будут компиляторы — тогда и обсудим. А поменять в C++ кое-что мне тоже хотелось бы.

Дык еще немножко и улучшать уже будет нечего.

У них же "немгожко" — это лет пять.

ГВ>Я на неё и не клепаю. Пусть делает что хочет! Просто, ИМХО, отдаю себе отчёт, что её действия продиктованы маркетинговыми соображениями.

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

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

Да нет там никакой "модели". Там груда фичь. Так и в Шарпе их не мало. Модель там, кстати, куда стройнее. Вот добавят шаблоны и вообще про С++ можно будет забыть (ну, в большинстве случаев).

ГВ>Следы эти таковы, что C# "упростился" для ускорения изучения

И дла укорения работы. Это, по-моему, куда важнее.

ГВ>, но из него выброшено много, ИМХО, важного. Прежде всего, того, что касается комбинирования абстракций. Вот, собственно.

Вот не любишь ты по русски выражаться.

"комбинирования абстракций" — это множественное наследование или шаблоны?

ГВ>Один из вопросов, который предлагается задать себе авторам предложений по расширению C++:

ГВ>"Можно ли это сделать имеющимися средствами языка?"

А я бы добавил: И насколько эти срдства выразительны, и дают ли они приемлемый результат?

ГВ>Может, несколько переврал текст, но смысл, вроде, не исказил. Кстати, я абсолютно согласен с тем, что если что-то можно сделать имеющимися средствами, то "нечего огород городить" (c) за счёт расширения языка, как такового. Зачем создавать дополнительную сущность?

Чтобы жить проще.

В С++ избыточность была исконно. Большинство прогаммистов используют его процентов на 10. Может по этому поводу С++ кастрировать?

ГВ>Например, я показал тебе "делегатами", что такую, в частности, штуку можно сделать на базе обычного C++. ==> Незачем вводить такое языковое расширение.

Это не обычный С++. И та гора кода которую ты наворотил как раз и показывает, что столь необходимую и часто встречающуюся концепцию нужно было интегрировать в язык. Кроме теории есть еще жизнь и она подсказывает очень простые истенны: не удобно — значит не используем, удобно — используем. А про концепции и полноту — это демогогия. Ты сам прекрасно понимаешь, что от изменения поведения указателей на методы никакая концепция не пострадает. Это всего лишь не желание людей признавать (а может осозновать) свои ошибки.

Еще раз задаю вопрос: Что плохого было бы если в язык добавили хотябы указатели на методы в стиле делегатов?

Здравствуйте Аноним, Вы писали:

А>Неужели менее красиво, чем рассуждать о том, в чем совершенно не разбираешься и при этом коверкать фамилии людей, которые уж точно знают гораздо больше?

Не тебе судить о том, что я знаю, а что нет. Сам то даже представиться боишься.

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

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

A>Расскажи-ка мне про преимущества Си Кернигана и Ритчи на примере следующего фрагмента:

A>

A>double sqrt(x)
A>double x;
A>{
A>/* какой-то код */
A>}

A>main()
A>{
A>    double z = sqrt(2);
A>}
A>

Не нужно доводить до маразма. Ричевский С времен второго (а может и третьего, уже не помню) издания Кернигана совершенно удобоваримый стандарт. Ансишный тех времен был вообще не удобен. По крайней мере реализованный в MC C 5.

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

А>>Неужели менее красиво, чем рассуждать о том, в чем совершенно не разбираешься и при этом коверкать фамилии людей, которые уж точно знают гораздо больше?

VD>Не тебе судить о том, что я знаю, а что нет. Сам то даже представиться боишься.

<moderator>
Алё, гараж, calm down, please.
</moderator>

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

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>А вот и неверно. :P Не нужно "улучшать" не реализованное ещё по сути средство. Вот будут компиляторы — тогда и обсудим. А поменять в C++ кое-что мне тоже хотелось бы.
AVK>Это уже не смешно. За сколько там лет существования С++ не сделали ни одного нормального компилятора. Так может сам язык в этом виноват?

Думаю, что здесь, действительно, одна из причин — относительная сложность C++ как языка и долгая возня с принятием его стандартного описания, а вторая причина — знаменитое "и так сойдёт, всё равно никто этим не пользуется". ИМХО, не в последнюю очередь по этим прчинам притормозилось развитие многих инструментальных средств, в том числе — и библиотек.

ГВ>>Я на неё и не клепаю. Пусть делает что хочет! Просто, ИМХО, отдаю себе отчёт, что её действия продиктованы маркетинговыми соображениями. И следы этого подхода есть, в том числе, и в языке программирования, который (возможно, — ошибочно) противопоставлен другому языку, с гораздо более развитой моделью.
AVK>Елки палки, устали уже тебе объяснять что модель у С++ довольно однобоко развита. Вся его развитость начинается и заканчивается шаблонами и множественным наследованием реализаций. Когда же тебе приводят кучу вещей когда шарп намного гибче плюсов, ты либо говоришь что это не имеет отношения к языку либо не нужно.

Подожди, Andrew. Я говорил именно о языке. Меня интересовали аргументы оппонетов, которые они смогут привести, исходя именно из языковой модели, без привлечения runtime и возможностей стандартных библиотек. А понеслось всё разом. Глупо было бы спорить, утверждая, что на данный момент рантайм C++ так же развит в смысле поддержки RTTI, как и для .NET-овских языков. Но, с другой стороны, рантайм для C++ — это целевая операционная система (кстати, практически все) + процессор (аналогично) + стандартные библиотеки ОС. Ммм... Хорошо, конечно, если .NET распространится также широко в смыле количества "охваченных" платформ, но... я пока в этом сомневаюсь. А потому и старался абстрагироваться от подобных аргументов, поскольку считаю, что целевая ОС/процессор — это то, что всегда должно быть возможно поменять, не потеряв плодов своей работы. Ну не моя вина, что чаще всего программы пишутся, лишь "слегка приподнимаясь" над уровнем базовой ОС или используемой библиотеки и её архитектуры.

AVK>Знаешь, уже не интересно. Можно сколь угодно доказывать идеологическую правильность плюсов но практика говорит что на шарпе проекты пишутся быстрее и сменьшим количеством ошибок. И код получается значительно понятнее и легче модифицируемым.

Естественно, если груда идиом уже внесена в язык и предоставлена здоровенная библиотека. Только мне кажется, что не всё так просто...

ГВ>> Следы эти таковы, что C# "упростился" для ускорения изучения, но из него выброшено много, ИМХО, важного.
AVK>Знаешь, даже у древних людей много это было больше двух. А здесь пока ничего кроме шаблонов и множ. наследования реализаций я пока не слышал.

Ну не сравнивай, пожалуйста, два принципа и две "штуки чего-то". Кроме того, эти две концепции — совсем не "мало". Из C++ достаточно убрать "одно" — шаблоны и язык потеряет очень много.

ГВ>>Прежде всего, того, что касается комбинирования абстракций. Вот, собственно.
AVK>С++ и рядом не стоял в плане создания всевозможных прокси-классов. Вот тебе и твое комбинирование.

Ну что тут сказать. Хорошо, если C#/.NET позволяют это делать просто, быстро и надёжно. Сама по себе среда, как я понимаю, спроектирована для поддержки таких решений.

ГВ>>"Можно ли это сделать имеющимися средствами языка?"

ГВ>>Может, несколько переврал текст, но смысл, вроде, не исказил. Кстати, я абсолютно согласен с тем, что если что-то можно сделать имеющимися средствами, то "нечего огород городить" (c) за счёт расширения языка, как такового. Зачем создавать дополнительную сущность?

AVK>Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

Ну да, правильно. ;) И нет никакой необходимости расширять C++ ради них. На нём всё прекрасно реализуется. А то, что сопряжение модели COM с языком C++ выполнено, ИМХО, не очень удобно, так это отнюдь не проблема не C++.

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

ГВ>Думаю, что здесь, действительно, одна из причин — относительная сложность C++ как языка и долгая возня с принятием его стандартного описания, а вторая причина — знаменитое "и так сойдёт, всё равно никто этим не пользуется". ИМХО, не в последнюю очередь по этим прчинам притормозилось развитие многих инструментальных средств, в том числе — и библиотек.
А ты как думал. И эти моменты язык тоже учитывать обязан.

ГВ>Подожди, Andrew. Я говорил именно о языке.

Знаешь, по мере развития языки становятся все менее отделимы от окружения. Разговаривать о шарпе или джаве отдельно от их рантайма бессмысленно.
GC это свойство языка или рантайма? Boxing/unboxing? У дотнета вобще есть специфика, ввиду его ориентированности на много языков собственно язык играет очень маленькую роль. И проблемы плюсов по большей части связаны не с языком как таковым а со скудностью рантайма.

ГВ> Меня интересовали аргументы оппонетов, которые они смогут привести, исходя именно из языковой модели, без привлечения runtime и возможностей стандартных библиотек.
Ну нельзя этого делать. Шарп или джава бесполезны без своего окружения.

ГВ>Хорошо, конечно, если .NET распространится также широко в смыле количества "охваченных" платформ, но... я пока в этом сомневаюсь.
Есть еще джава.

ГВ>Естественно, если груда идиом уже внесена в язык и предоставлена здоровенная библиотека. Только мне кажется, что не всё так просто...
А мне не кажется, я пробовал и поэтому знаю.

ГВ>Ну не сравнивай, пожалуйста, два принципа и две "штуки чего-то". Кроме того, эти две концепции — совсем не "мало". Из C++ достаточно убрать "одно" — шаблоны и язык потеряет очень много.
Но назвать это "много" и "сильно порезано" мягко говоря преувеличение.

AVK>>С++ и рядом не стоял в плане создания всевозможных прокси-классов. Вот тебе и твое комбинирование.
ГВ>Ну что тут сказать. Хорошо, если C#/.NET позволяют это делать просто, быстро и надёжно. Сама по себе среда, как я понимаю, спроектирована для поддержки таких решений.
В том числе и для этого.

AVK>>Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

ГВ>Ну да, правильно.

И нет никакой необходимости расширять C++ ради них. На нём всё прекрасно реализуется.
СОМ это прекрасно? Странное у тебя чувство красоты. Отвратительно реализуется надо признать.

ГВ> А то, что сопряжение модели COM с языком C++ выполнено, ИМХО, не очень удобно, так это отнюдь не проблема не C++.
CORBA тоже красотой не блещет. И почему ничего лучше пока не сделали? Вот когда я увижу нормальную компонентную модель на С++ я поверю в это.

... Янус версия 1.0 alpha 2

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

VD>Здравствуйте Аноним, Вы писали:

А>>Неужели менее красиво, чем рассуждать о том, в чем совершенно не разбираешься и при этом коверкать фамилии людей, которые уж точно знают гораздо больше?

VD>Не тебе судить о том, что я знаю, а что нет. Сам то даже представиться боишься.

Почему не мне? Из того, что ты написал, кое-какие выводы сделать можно. Я уж как-нибудь сам решу о чем мне судить. И, кстати, не надо себе льстить. Ну кого мне здесь бояться? Просто я не настолько большой фанат RSDN, чтобы регистрироваться.

VD>Я говорил о том, что ни комитет, ни Страуструп не хотят исправлять свои явные недоработки и ошибки. А так же о том, что у товарища начинается старческие болезни в юном возрасте. А сделать такие выводы позволяет его публичные выступления. Возьми хотя бы его бред о реализации GC средствами С++. И это в языке который сидит по уши в 80-ых, где даже нет нормального способа получить информацию о типах в рантайме.

Если какой язык и сидит по уши в 80-х, то это C#. Его объектная модель очень похожа на объектные модели самых первых объектно-ориентированных языков.

Здравствуйте <Аноним>, Вы писали:

А>Почему не мне? Из того, что ты написал, кое-какие выводы сделать можно.
Пока никаких, отни пустые слова

А> Я уж как-нибудь сам решу о чем мне судить.
Только оставляй тогда свои суждения при себе

А>И, кстати, не надо себе льстить. Ну кого мне здесь бояться? Просто я не настолько большой фанат RSDN, чтобы регистрироваться.
Хреновая отмазка. Для того чтобы зарегистрироваться на RSDN совсем не обязательно быть ее фанатом. В конце концов мог бы просто в письме придставится.

А>
А>Если какой язык и сидит по уши в 80-х, то это C#. Его объектная модель очень похожа на объектные модели самых первых объектно-ориентированных языков.
Подобные суждения свидетельствуют о том что ты просто не представляешь себе что такое шарп и дотнет.
Мне вобще нравится позиция что мол я знаю что такое дотнет только по слухам но это дерьмо. И разбиратся с ним я не буду потому что дерьмо.

... Янус версия 1.0 alpha 2

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

ГВ> Меня интересовали аргументы оппонетов, которые они смогут привести, исходя именно из языковой модели, без привлечения runtime и возможностей стандартных библиотек.

Так дело в том, что на сегадня современный язык должен быть тесно и безшовно интегрирован с рантаймом. Это требование времени не просто слова. Их необходимость подтверждает сама жизнь.

ГВ>А понеслось всё разом. Глупо было бы спорить, утверждая, что на данный момент рантайм C++ так же развит в смысле поддержки RTTI, как и для .NET-овских языков. Но, с другой стороны, рантайм для C++ — это целевая операционная система (кстати, практически все) + процессор (аналогично) + стандартные библиотеки ОС. Ммм...

Слова... слова... рантайм С++ — это CRT + STL. Последнюю и рантаймом назвать нельзя.

ГВ>Хорошо, конечно, если .NET распространится также широко в смыле количества "охваченных" платформ

Ну, Ява тоже почти везде есть. И почему ты тогда о ней не говоришь? Может быть просто по тому, что потребителю в основном нужен софт для Виндовс? А тогда что говорить о переносимости? В конце концов переносимее С языка нет. Что же теперь и С++ выбрасить?

ГВ>Естественно, если груда идиом уже внесена в язык и предоставлена здоровенная библиотека. Только мне кажется, что не всё так просто...

Заметь! При этом сам язык куда компактнее плюсов, очень быстро компилируется и прекрасно парстся (что критичиски важно для визуальных сред).

AVK>>Знаешь, даже у древних людей много это было больше двух. А здесь пока ничего кроме шаблонов и множ. наследования реализаций я пока не слышал.

Ну, еще const зря покоцали.

ГВ>Ну не сравнивай, пожалуйста, два принципа и две "штуки чего-то". Кроме того, эти две концепции — совсем не "мало". Из C++ достаточно убрать "одно" — шаблоны и язык потеряет очень много.

Между прочим шаблоны вещь относительно молодая. На плюсах писали и раньше когда компиляторы шаблонов еще не поддерживали. Вон глянь на MFC...

AVK>>Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

ГВ>Ну да, правильно.

И нет никакой необходимости расширять C++ ради них. На нём всё прекрасно реализуется.

А-га. А .NET и Ява от сырости завелись.

AVK>А то, что сопряжение модели COM с языком C++ выполнено, ИМХО, не очень удобно, так это отнюдь не проблема не C++.

А чья? Почему в CORBA все еще сложнее и запутаннее, хотя она только сейчас до компонентности добирается?

Почитай Бокса. У него есть замечательный анализ COM-а. Там как раз рассматриваются особенности COM-а и объясняется почему это сделано, так, а не иначе. Думаю тебя несколько удивит, что практически все нвеено недоработанностью того самого С++. Главный недостаток стандарта С++ — это то, что рантай в нем практически не оговорен. Все сводится к идеомам 70-ых.

Здравствуйте Аноним, Вы писали:

А> Просто я не настолько большой фанат RSDN, чтобы регистрироваться.

A! Ну-ну...

А>Если какой язык и сидит по уши в 80-х, то это C#. Его объектная модель очень похожа на объектные модели самых первых объектно-ориентированных языков.

И что можешь привести хоть один язык 80-ых который имел бы похожую модель, а за одно предоставлял бы средства типа рефлекшена?

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

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Думаю, что здесь, действительно, одна из причин — относительная сложность C++ как языка и долгая возня с принятием его стандартного описания, а вторая причина — знаменитое "и так сойдёт, всё равно никто этим не пользуется". ИМХО, не в последнюю очередь по этим прчинам притормозилось развитие многих инструментальных средств, в том числе — и библиотек.
AVK>А ты как думал. И эти моменты язык тоже учитывать обязан.

Это — деградация в чистом виде. Сейчас объясню, почему я так думаю.

Я немного сгущу краски, но всё-таки...

Хочешь интересную аналогию? Яркий, пример языка непосредственно производного от своего "окружения" (рантайма) — Ассемблер какого-то процессора. ИМХО, языки выского уровня как раз и строились для отсечения программиста от рантайм-окружения с помощью математических или иных абстракций. Ну например: LISP — лямба-исчисление, PROLOG — хорновские дизъюнкты, SQL — реляционная алгебра. В то же время языки "системного" программирования базируются на императивной концепции — PL/1, C. И ещё инженерно-расчётные — Fortran, Basic. Не учитываю здесь исследовательские проекты и прочее.

Проектирование систем (а прикладная программа, особенно большая — тоже система. Да, их часто пишут бесситемно, но это к делу не относится) всё равно тяготеет к предсказуемости поведения системы, в противном случае она просто неустойчива. Как часть решения — языки со статической сильной типизацией. Потому-то, ИМХО, и считается неуёмный RTTI и манипуляции кодом "на лету" признаком "плохого стиля". Таким образом вносится нестабильность в систему, да и добавляется ручной работы. А зачем работать руками, когда часть согласования абстракций можно переложить на транслятор? Только абстракции нужно выбрать правильно.

Развитие языков системного программирования в объектно-ориентированные (C++, Ada и ещё, кажется CLU — но последний, ИМХО, полуисследовательский) произошло, ИМХО, на базе "всасывания" модели Simula-67 и Smalltalk, которые сами по себе появились из... по-моему, это называется исчисление на фреймах (фреймы/слоты — пра-образ нынешних классов/методов, по совместительству — подраздел исследований в области ИИ). Только отказались от единственного базового класса ради жёсткой типизации, что само по себе делается ради поддержки детерминированности поведения системы. При этом, обрати внимание — в распространённых языках всегда вводится абстракция от вычислительной среды. Увы, императивная, поскольку языки связаны фон-неймановской архитектурой, но — абстракция. Цель, ИМХО, обеспечить максимальную переносимость и эффективность.

Кстати, цели у всех одни и те же — поменьше поработать + побольше получить денег за выданный результат, в данном случае — снизить объём механической работы, путём поиска адекватных абстракций.

ИМХО, в таком способе развития есть немалая польза и для окружающих всё это хозяйство наук. Если ахитектура исполнительной среды и языки высокого уровня относительно свободны один от другого, то можно развивать и то и другое за счёт развития теории трансляции и использования новых методов, прежде всего — математических. То есть, "удалённость" взаимной абстракции растёт так или иначе, но при этом развивается и теоретическая база. Обратная дорога — суть немедленная деградация.

Программная система синтезирует математические и аппаратные абстракции. У шаблонов в этом смысле — много положительных качеств с рациональной точки зрения. С одной стороны — можно построить очень сложную абстракцию, с другой — эффективно превратить её в исполняемый код. И при этом остаться в рамках парадигмы сильной типизации и контроля компилятора, т.е. — минимизации механической работы. ИМХО, языки системного программирования как раз и двигаются (двигались?) в эту сторону и generic-программирование — очень неплохая ступенька в этом развитии.

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

Однако, когда возник бум программирования, то что произошло? Да то, что и должно было произойти — привлеклась масса попросту неквалифицированных специалистов, у которых превалирует примитивный ("императивный") способ изложения: "делай раз — будет так, делай два — будет эдак и точка". Они просто не натренированы выражать своё абстрактное мышление в математических терминах и строить абстракции — тоже. То есть, фактически, произошёл "откат" в... примерно 50-е — 60-е годы. Такие спецы составляют сейчас абсолютное большинство (по крайней мере, в своём окружении пересчитывал неоднократно :( ). Они же — основная масса потребителей средств программирования, которые, в ориентации на тупую аудиторию уже конструктивно ограничиваются. В них попросту нет того, что могло бы быть. Нет анализа семантики программы, нет построителей графов, нет никаких встроенных математических механизмов, что разумно было бы ожидать от сред поддержки програмирования. Ни хрена этого нет! Есть только набор "методов", бантики-картиночки и встроенная поддержка построения (ах, извините — "организации") всей этой толпы и раздачи ей малоквалифицированной работы. Но это-то ладно. Однако здесь есть ещё очень интересная завязка на то, что при таких делах интеллектуальные средства развиться просто не смогут! Их же тоже будут писать под управлением таких же менеджеров, бестолковых аналитиков и т.п. Они же просто массой всех задавят.

Вот тебе и "язык должен учитывать все эти проблемы...". Проблемы кого? Проблемы недоучившихся школьников? То есть, давайте превратим всех в недоучившихся школьников, потому что так основной массе будет удобнее? Что-то в этом есть неверное, а конкретно — игнорирование интеллектуальной основы (ИМХО).

И что мы получаем на сегодняшний день (кстати, протяженност этого "дня" — уже где-то лет тридцать)? .NET — явно определяет ограничения на комбинаторику своих языков за счёт навязывания структуры reflection+RTTI. А если отказаться от reflection, то целесообразность .NET представляется очень сомнительной. Да, он подходит для части языков, но есть же и другие (ну да — тот самый, очень "сложный", в первую очередь ;) ), тем более — признанные разработчиками! То есть, по сути, частное окружение пытается навязать свою модель разработчикам, которым, по идее, не должно быть до него никакого дела. JVM в данном случае — чуть "иная" система, поскольку разработана для поддержки одного языка. Но .NET-то рвётся в гегемоны! Но сделан-то он для "упрощения"...

ГВ>>Подожди, Andrew. Я говорил именно о языке.

AVK>Знаешь, по мере развития языки становятся все менее отделимы от окружения. Разговаривать о шарпе или джаве отдельно от их рантайма бессмысленно.

Это следствие бушующего идиотизма, извини за прямоту и не прими в свой адрес. ИМХО, это признак деградации. Поскольку создаёт жёсткую зависимость разработчиков от платформы, на которой их программы будут работать. Язык высокого уровня отделяет разработчика от исполнительной системы.

AVK>GC это свойство языка или рантайма? Boxing/unboxing?

GC — свойство рантайма, Boxing/Unboxing — способ совмещения managed- и unmanaged-кода. То есть, попросту — ещё один способ организации взаимодействия. Принципиального новшества нет!

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

Блеск! Ассемблер как парадигматическая основа всех основ!

AVK>И проблемы плюсов по большей части связаны не с языком как таковым а со скудностью рантайма.

Не я один хотел бы получить развитый компилятор/интерпретатор/анализатор/type-info-генератор для С++.

ГВ>> Меня интересовали аргументы оппонетов, которые они смогут привести, исходя именно из языковой модели, без привлечения runtime и возможностей стандартных библиотек.
AVK>Ну нельзя этого делать. Шарп или джава бесполезны без своего окружения.

Угу. А шарп — так вообще надстройка над CLR и не более того.

ГВ>>Хорошо, конечно, если .NET распространится также широко в смыле количества "охваченных" платформ, но... я пока в этом сомневаюсь.
AVK>Есть еще джава.

Java, кстати, кажется и на .NET реализована. Что доказывает их подобие и косвенно — ориентацию .NET на перехват инициативы у Java. Но никак не на подержку неограниченного повышения эффективности одного человека.

ГВ>>Естественно, если груда идиом уже внесена в язык и предоставлена здоровенная библиотека. Только мне кажется, что не всё так просто...
AVK>А мне не кажется, я пробовал и поэтому знаю.

Что я думаю о сложностях — см. выше. Всё очень сильно взаимосвязано.

ГВ>>Ну не сравнивай, пожалуйста, два принципа и две "штуки чего-то". Кроме того, эти две концепции — совсем не "мало". Из C++ достаточно убрать "одно" — шаблоны и язык потеряет очень много.
AVK>Но назвать это "много" и "сильно порезано" мягко говоря преувеличение.

ИМХО — нет, поскольку это откат назад в грубом виде. Кстати, на такой оборот речи меня навела дискуссия Vlad2-Аноним где-то в соседних ветках. (http://www.rsdn.ru/forum/?mid=93371)

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

AVK>>>С++ и рядом не стоял в плане создания всевозможных прокси-классов. Вот тебе и твое комбинирование.
ГВ>>Ну что тут сказать. Хорошо, если C#/.NET позволяют это делать просто, быстро и надёжно. Сама по себе среда, как я понимаю, спроектирована для поддержки таких решений.
AVK>В том числе и для этого.

Но появятся ли новые?...

AVK>>>Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

ГВ>>Ну да, правильно. ;) И нет никакой необходимости расширять C++ ради них. На нём всё прекрасно реализуется.
AVK>СОМ это прекрасно? Странное у тебя чувство красоты. Отвратительно реализуется надо признать.

Это была фигура речи, только для оттенения того, что на C++ это всё-таки было реализовано. Я тоже не считаю COM образцом красоты.

ГВ>> А то, что сопряжение модели COM с языком C++ выполнено, ИМХО, не очень удобно, так это отнюдь не проблема не C++.
AVK>CORBA тоже красотой не блещет. И почему ничего лучше пока не сделали? Вот когда я увижу нормальную компонентную модель на С++ я поверю в это.

А слабо самому сделать то, что ты считаешь "нормальной компонентной моделью"? ;)

Извини, предыдущее случайно поспешно отправил

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

VD>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>> Меня интересовали аргументы оппонетов, которые они смогут привести, исходя именно из языковой модели, без привлечения runtime и возможностей стандартных библиотек.

VD>Так дело в том, что на сегадня современный язык должен быть тесно и безшовно интегрирован с рантаймом. Это требование времени не просто слова. Их необходимость подтверждает сама жизнь.

Аргумент к морали. Некорректно. Извини. Начинаешь из воздуха и заканчиваешь тем же. Жизнь подтверждает много разных необходимостей.

ГВ>>А понеслось всё разом. Глупо было бы спорить, утверждая, что на данный момент рантайм C++ так же развит в смысле поддержки RTTI, как и для .NET-овских языков. Но, с другой стороны, рантайм для C++ — это целевая операционная система (кстати, практически все) + процессор (аналогично) + стандартные библиотеки ОС. Ммм...

VD>Слова... слова... рантайм С++ — это CRT + STL. Последнюю и рантаймом назвать нельзя.

Естественно. C++ — компилируемый язык.

ГВ>>Хорошо, конечно, если .NET распространится также широко в смыле количества "охваченных" платформ

VD>Ну, Ява тоже почти везде есть. И почему ты тогда о ней не говоришь?

Просто мы на нетовскую тему завелись.

VD>Может быть просто по тому, что потребителю в основном нужен софт для Виндовс? А тогда что говорить о переносимости? В конце концов переносимее С языка нет. Что же теперь и С++ выбрасить?

C++ удобнее C в том смысле, что позволяет получать программы с тем же быстродействием (и даже выше), но с более дешёвым сопровождением. Если он не по-дурацки применён, конечно.

ГВ>>Естественно, если груда идиом уже внесена в язык и предоставлена здоровенная библиотека. Только мне кажется, что не всё так просто...

VD>Заметь! При этом сам язык куда компактнее плюсов, очень быстро компилируется и прекрасно парстся (что критичиски важно для визуальных сред).

Угу. Заметил. Знаешь, сам факт приведения такого аргумента — уже не очень хороший признак. Скорее всего — признак тупости визуальных сред. Ведь можно держать внутреннее представление программы в виде графа, к примеру и докомпилировать его по ходу редактирования, а не возиться с исходниками каждый раз.

AVK>>>Знаешь, даже у древних людей много это было больше двух. А здесь пока ничего кроме шаблонов и множ. наследования реализаций я пока не слышал.

VD>Ну, еще const зря покоцали.

Мдаа.. Устойчивость софта делает нам ручкой. Медленно-медленно... Если это всё ориентировано на полупрофессионалов, то каша раньше или позже нам гарантирована!

ГВ>>Ну не сравнивай, пожалуйста, два принципа и две "штуки чего-то". Кроме того, эти две концепции — совсем не "мало". Из C++ достаточно убрать "одно" — шаблоны и язык потеряет очень много.

VD>Между прочим шаблоны вещь относительно молодая. На плюсах писали и раньше когда компиляторы шаблонов еще не поддерживали. Вон глянь на MFC...

...сплюнь и больше не заглядывай.

C++ без шаблонов теряет огромную часть своих достоинств и комбинационых возможностей.

AVK>>>Вот тебе COM и CORBA и привели в качестве примера подобной реализации.

ГВ>>Ну да, правильно. И нет никакой необходимости расширять C++ ради них. На нём всё прекрасно реализуется.

VD>А-га. А .NET и Ява от сырости завелись.

Ну я понимаю. Ждать стандарта не хотелось, да и возиться с относительно сложными генераторами/парсерами — тоже. Тут ява подвернулась. А MS уж мимо пройти не могла.

AVK>>А то, что сопряжение модели COM с языком C++ выполнено, ИМХО, не очень удобно, так это отнюдь не проблема не C++.

VD>А чья? Почему в CORBA все еще сложнее и запутаннее, хотя она только сейчас до компонентности добирается?

Уж не C++ ли ты хочешь в этом обвинить? А может, это всё-таки распри OMG какие-нибудь виноваты?

VD>Почитай Бокса. У него есть замечательный анализ COM-а. Там как раз рассматриваются особенности COM-а и объясняется почему это сделано, так, а не иначе. Думаю тебя несколько удивит, что практически все нвеено недоработанностью того самого С++. Главный недостаток стандарта С++ — это то, что рантай в нем практически не оговорен. Все сводится к идеомам 70-ых.

URL кинь, если не жалко. Постараюсь прокомментировать.

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

ГВ>Хочешь интересную аналогию? Яркий, пример языка непосредственно производного от своего "окружения" (рантайма) — Ассемблер какого-то процессора.
Неправильный пример, причем сильно неправильный. У Ассемблера своего рантайма 0. Весь его рантайм зависит от ОС, системы команд процессора, архитектуры компьютера и т.д. В нашем же случае мы имеет стандартизованный рантайм, одинаковый на любом компьютере.

ГВ>ИМХО, языки выского уровня как раз и строились для отсечения программиста от рантайм-окружения с помощью математических или иных абстракций.
А сейчас вместо отсечения языка стали отсекать его рантайм. Джава тому примером. Почему ты решил что это хуже? В плане переносимости наоборот намного лучше. Я уже тебе писал — для джавы совместимость бинарная, что по определению на порядок большая степень изоляции от окружения. Думаешь для чего еще выдумали JVM и CLR.

ГВ>PROLOG — хорновские дизъюнкты,
Какие? Ты где такой термин откопал? Его нгазывают логическрим языком, реляционным, языком исчисления предикатов, но вот такое вижу впервые.
В общем хороший пример — язык очень глубоко завязан на свой рантайм, там даже БД встроена в рантайм и поддерживается на уровне языка. Впорочем лисп, как ты понимаешь, тоже без своего окружения ничто, это вобще скрипт по сути.

ГВ> SQL — реляционная алгебра.
А вот тут как раз пример твоего подхода. Стандартизировали язык, а про рантайм как то забыли. В результате у каждого sql-сервера, у каждого odbc-драйвера для настольных СУБД свой диалект. Очень хорошо иллюстрирует результаты попыток создания языка в отрыве от окружения.

ГВ>Проектирование систем (а прикладная программа, особенно большая — тоже система. Да, их часто пишут бесситемно, но это к делу не относится) всё равно тяготеет к предсказуемости поведения системы, в противном случае она просто неустойчива. Как часть решения — языки со статической сильной типизацией. Потому-то, ИМХО, и считается неуёмный RTTI и манипуляции кодом "на лету" признаком "плохого стиля".
Ты по моему чего то не понимаешь. Это для инженерных расчетов можно себе позволить перекомпилировать исходники на каждый чих. А теперь представь себе следующую ситуацию — у нас сетка скажем из 100 машинок. На них стоит некий софт, в соответствии с "хорошим" стилем собранный статической линковкой. Все это работает в режиме 24х7. 1 час простоя обходится скажем в $10K. И вот теперь представь — для 5 рабочих мест ты что то поменял. Менять придется везде.
В общем глупо объяснять преимущества компонентных технологий. Они существенно увеличивают надежность системы. У тебя видимо несколько специфическая предметная облась если ты этого не замечаешь.

ГВ> Таким образом вносится нестабильность в систему, да и добавляется ручной работы. А зачем работать руками, когда часть согласования абстракций можно переложить на транслятор? Только абстракции нужно выбрать правильно.
Следуя твоей логике нужно отказаться и от полиморфизма. Ибо рефлекшен по сути и есть полиморфизм, только более высокого уровня нежели тот который обеспечивается виртуальными методами.

ГВ>При этом, обрати внимание — в распространённых языках всегда вводится абстракция от вычислительной среды. Увы, императивная, поскольку языки связаны фон-неймановской архитектурой, но — абстракция. Цель, ИМХО, обеспечить максимальную переносимость и эффективность.
Т.е ты утверждаешь что переносимость С++ выше чем переносимость джавы? Не смешно.

ГВ>Кстати, цели у всех одни и те же — поменьше поработать + побольше получить денег за выданный результат, в данном случае — снизить объём механической работы, путём поиска адекватных абстракций.
Вот тебе и пытаются сказать что рефлекшен существенно уменьшает объем ручной работы, поскольку позволяет создавать абстракции более высокого уровня.

ГВ>ИМХО, в таком способе развития есть немалая польза и для окружающих всё это хозяйство наук. Если ахитектура исполнительной среды и языки высокого уровня относительно свободны один от другого, то можно развивать и то и другое за счёт развития теории трансляции и использования новых методов, прежде всего — математических. То есть, "удалённость" взаимной абстракции растёт так или иначе, но при этом развивается и теоретическая база. Обратная дорога — суть немедленная деградация.
Что то джава уже лет пять наверное деградирует, но все никак не развалится окончательно. Это мне напоминает социализм и капитализм.

А потом — ты хоть раз видел программу на С++ компилирующуюся и под уних и под Win32? Я видел. Там половина кода в #ifdef ХХХ. Поэтому реально портируют софт с использованием cygwin. А это как раз и есть тот самый рантайм. Поэтому про переносимость С++ не надо, хреновая она совсем.

ГВ>То есть, языки системного программирования принципиально
Очень расплывчатый термин. Нет таких языком программирования. Есть задачи. Вот для этих задач (я имею ввиду написание ОС-специфичных вещей) С++ и нужен. И не потому что он обеспечивает высокую степень абстракции а наоборот, слишком тонкий слой отделяет его от ОС.

ГВ>Однако, когда возник бум программирования, то что произошло? Да то, что и должно было произойти — привлеклась масса попросту неквалифицированных специалистов, у которых превалирует примитивный ("императивный") способ изложения: "делай раз — будет так, делай два — будет эдак и точка".
Т.е. ты меня и Влада считаешь неквалифицированными программистами?

ГВ> Они просто не натренированы выражать своё абстрактное мышление в математических терминах и строить абстракции — тоже.
Однако почему то на джаве и шарпе у меня получается писать быстрее и качественнее.
Следуя твоей логике — если это так то это означает что я не умею строить абстракций?

ГВ>То есть, фактически, произошёл "откат" в... примерно 50-е — 60-е годы. Такие спецы составляют сейчас абсолютное большинство (по крайней мере, в своём окружении пересчитывал неоднократно

). Они же — основная масса потребителей средств программирования, которые, в ориентации на тупую аудиторию уже конструктивно ограничиваются.
Попробуй взглянуть на это с другой стороны. В софтостроении потихонечку произошла маленькая революция. Возможно это и возвращение старых идей, но на новом уровне. Тебе же объясняют — на шарпе получается писать намного быстрее и намного качественней даже профессионалам. А то что язык дисциплинирует тех самых чайников это его плюс. Джава в большей степени, шарп в меньшей. Тут альтернатива простая — либо средненькие программеры, либо никакие. В последнее время я предпочитаю брать на работу людей незнакомых с тем что применяется. Научить значительно проще чем переучить.

ГВ> В них попросту нет того, что могло бы быть. Нет анализа семантики программы, нет построителей графов, нет никаких встроенных математических механизмов, что разумно было бы ожидать от сред поддержки програмирования. Ни хрена этого нет!
Оно и в плюсах ничего нет. Математика не поспевает за программиролванием. Пожалуй единственным успешным применением математики в программировании является теория множеств и теория графов. При чем sql сервера потихоньку вылазят из своих реляционных штанишек. Жесткая связь с математическими теориями означает практически отсутствие развития. Использовать надо, но они не должны быть определяющими.

ГВ> Есть только набор "методов", бантики-картиночки и встроенная поддержка построения (ах, извините — "организации") всей этой толпы и раздачи ей малоквалифицированной работы. Но это-то ладно. Однако здесь есть ещё очень интересная завязка на то, что при таких делах интеллектуальные средства развиться просто не смогут! Их же тоже будут писать под управлением таких же менеджеров, бестолковых аналитиков и т.п. Они же просто массой всех задавят.
Дорогой ты мой, их не посылать надо а делать из них нормальных спецов. Других нет.

ГВ>Вот тебе и "язык должен учитывать все эти проблемы...".
Обязательно. Иначе это не язык а абстракция.

ГВ>Проблемы кого? Проблемы недоучившихся школьников?
Да

ГВ> То есть, давайте превратим всех в недоучившихся школьников,
Не надо превращать. Они уже есть.

ГВ> потому что так основной массе будет удобнее? Что-то в этом есть неверное, а конкретно — игнорирование интеллектуальной основы (ИМХО).
А нету других. Если нужно будет платить больше тысячи каждому программисту (а именно столько стоят сейчас более менее нормальные спецы) то 80% проектов просто загнутся.

ГВ>(ну да — тот самый, очень "сложный", в первую очередь

Тот самый очень сложный под дотнет есть. MC++ называется.

ГВ>), тем более — признанные разработчиками! То есть, по сути, частное окружение пытается навязать свою модель разработчикам, которым, по идее, не должно быть до него никакого дела.
Любой язык вынужден что то навязывать. Даже ассемблер. Не бывает абсолютно универсального языка.

ГВ>Это следствие бушующего идиотизма, извини за прямоту и не прими в свой адрес.
Я все больше убеждаюсь в том что говорить о вкусе устриц можно только с тем кто их ел.

ГВ> ИМХО, это признак деградации. Поскольку создаёт жёсткую зависимость разработчиков от платформы, на которой их программы будут работать. Язык высокого уровня отделяет разработчика от исполнительной системы.
Язык высокого уровня отделяет разработчика от меняющегося окружения, а не от рантайма. Пока я от тебя не услышал чем плоха подвязка на рантайм, при условии что рантайм всегда стандартен.

ГВ>GC — свойство рантайма,
Вот вот.

ГВ> Boxing/Unboxing — способ совмещения managed- и unmanaged-кода.
Абсолютно неверно.

AVK>>И проблемы плюсов по большей части связаны не с языком как таковым а со скудностью рантайма.
ГВ>Не я один хотел бы получить развитый компилятор/интерпретатор/анализатор/type-info-генератор для С++.
Так в чем проблема то?

AVK>>Есть еще джава.
ГВ>Java, кстати, кажется и на .NET реализована.
J#.

ГВ>Что доказывает их подобие
И гибкость CLR.

ГВ>Но никак не на подержку неограниченного повышения эффективности одного человека.
Практика показывает что эффективность он таки повышает.

ГВ>ИМХО — нет, поскольку это откат назад в грубом виде. Кстати, на такой оборот речи меня навела дискуссия Vlad2-Аноним где-то в соседних ветках. (http://www.rsdn.ru/forum/?mid=93371)
Опять же, ты попробуй. Джава и дотнет это вобщем то уникальные явления. Ничего похожего до них не было.

ГВ>Нас грубо подталкивают к эффективности реализации примитивных систем, но усложняют деятельность более высокого порядка.
Как раз наоборот получается. Когда мы пытаемся что то простенькое писать, зачастую на С++ получается не хуже, иногда даже лучше. А вот когда дело доходит до чего то тяжелого тогда и начинают работать все достоинства дотнета или джавы.

AVK>>В том числе и для этого.
ГВ>Но появятся ли новые?...
Почему нет?

AVK>>СОМ это прекрасно? Странное у тебя чувство красоты. Отвратительно реализуется надо признать.

ГВ>Это была фигура речи, только для оттенения того, что на C++ это всё-таки было реализовано. Я тоже не считаю COM образцом красоты.
Ну уж очень фигово надо признать.

AVK>>CORBA тоже красотой не блещет. И почему ничего лучше пока не сделали? Вот когда я увижу нормальную компонентную модель на С++ я поверю в это.
ГВ>А слабо самому сделать то, что ты считаешь "нормальной компонентной моделью"?

А зачем? Она в дотнете уже есть. Опять же, так как в свое время я пытался это сделать то убежден что ничего существенно лучше COM на С++ не сделаешь.

... Янус версия 1.0 alpha 2

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

ГВ>>Хочешь интересную аналогию? Яркий, пример языка непосредственно производного от своего "окружения" (рантайма) — Ассемблер какого-то процессора.
AVK>Неправильный пример, причем сильно неправильный. У Ассемблера своего рантайма 0. Весь его рантайм зависит от ОС, системы команд процессора, архитектуры компьютера и т.д. В нашем же случае мы имеет стандартизованный рантайм, одинаковый на любом компьютере.

Да, runtime-обвязки у него фактически нет, но он — производное от своей платформы. Слово "окружение" у меня преднамеренно было взято в кавычки.

ГВ>>ИМХО, языки выского уровня как раз и строились для отсечения программиста от рантайм-окружения с помощью математических или иных абстракций.
AVK>А сейчас вместо отсечения языка стали отсекать его рантайм. Джава тому примером. Почему ты решил что это хуже? В плане переносимости наоборот намного лучше. Я уже тебе писал — для джавы совместимость бинарная, что по определению на порядок большая степень изоляции от окружения. Думаешь для чего еще выдумали JVM и CLR.

От окружения класса целевой машины — несомненно, но не от своего собственного. Целевой машиной Java грубо можно считать JVM. Да, Java-программы можно переносить в бинарном виде. При наличии JVM или её аналога на целевой аппаратной платформе (есть почти везде, даже на .NET). Чего, кстати, нельзя пока сказать о C# (пока что).

Только смотри что получается! Вместо несовместимости OS1 <-> OS2 получим в итоге несовместимость VM1 <-> VM2. То же самое — только в профиль.

ГВ>>PROLOG — хорновские дизъюнкты,
AVK>Какие? Ты где такой термин откопал? Его нгазывают логическрим языком, реляционным, языком исчисления предикатов, но вот такое вижу впервые.

Посмотри, например, здесь.

AVK>В общем хороший пример — язык очень глубоко завязан на свой рантайм, там даже БД встроена в рантайм и поддерживается на уровне языка. Впорочем лисп, как ты понимаешь, тоже без своего окружения ничто, это вобще скрипт по сути.

Для них, кстати, явно вводится понятие абстрактной машины (PROLOG-машина, LISP-машина и т.п.). А для PROLOG, по-моему, до сих пор способа трансляции в исполняемый код толком не нашли.

ГВ>> SQL — реляционная алгебра.
AVK>А вот тут как раз пример твоего подхода. Стандартизировали язык, а про рантайм как то забыли. В результате у каждого sql-сервера, у каждого odbc-драйвера для настольных СУБД свой диалект. Очень хорошо иллюстрирует результаты попыток создания языка в отрыве от окружения.

Извини, не понял, что ты имел ввиду. Какой ещё рантайм у SQL? SQL же — язык запросов. У него рантаймов может быть — вагон и две телеги. Потому и стандартизируется язык как таковой. Просто, как всегда, крупным мануфактурерам до балды что там ANSI вытворяет. ИМХО, — это результат того, что они отбивают друг у друга клиентов и стараются удержать своих. Вполне естественно.

Однако те окружения, о которых мы тут говорим — собственность одного производителя (MS или Sun).

ГВ>>Проектирование систем (а прикладная программа, особенно большая — тоже система. Да, их часто пишут бесситемно, но это к делу не относится) всё равно тяготеет к предсказуемости поведения системы, в противном случае она просто неустойчива. Как часть решения — языки со статической сильной типизацией. Потому-то, ИМХО, и считается неуёмный RTTI и манипуляции кодом "на лету" признаком "плохого стиля".
AVK>Ты по моему чего то не понимаешь. Это для инженерных расчетов можно себе позволить перекомпилировать исходники на каждый чих. А теперь представь себе следующую ситуацию — у нас сетка скажем из 100 машинок. На них стоит некий софт, в соответствии с "хорошим" стилем собранный статической линковкой. Все это работает в режиме 24х7. 1 час простоя обходится скажем в $10K. И вот теперь представь — для 5 рабочих мест ты что то поменял. Менять придется везде.

Пример слегка натянутый, но ... Так в чём проблема-то?

Остановка работы станции на 1 мин, копирование нового .EXE и перезапуск новой программы. И так на 5-и станциях. Всё.

И потом, если всё так критично, то известно об этом обычно с самого начала работы и проектные решения для подобных манипуляций должны приниматься заранее (есть, правда и другие практики, но это "не моя уже вина" (c) ). Так что, если я буду менять что-то для 5-и рабочих мест (и только для них), то обеспечу, чтобы остальные 95 остались нетронутыми.

И уж поверь, что для такого случая я в самую последнюю очередь подумаю о Java, .NET и тем более — COM.

Кстати, безотносительно используемых технологий мне всё равно придётся тормозить часть приложения (или всё), чтобы отключить удаляемые модули, если, конечно статическая линковка сделана в варианте .EXE+.DLL.

AVK>В общем глупо объяснять преимущества компонентных технологий. Они существенно увеличивают надежность системы. У тебя видимо несколько специфическая предметная облась если ты этого не замечаешь.

Я вполне понимаю их премущества но не в области повышения надёжности или быстродействия. Только относительно гибкости.

ГВ>> Таким образом вносится нестабильность в систему, да и добавляется ручной работы. А зачем работать руками, когда часть согласования абстракций можно переложить на транслятор? Только абстракции нужно выбрать правильно.
AVK>Следуя твоей логике нужно отказаться и от полиморфизма. Ибо рефлекшен по сути и есть полиморфизм, только более высокого уровня нежели тот который обеспечивается виртуальными методами.

Это наивное следствие из логики предложения. ИМХО — апофеоз попыток таких согласований — это шаблоны, которые позволяют разделить алгоритмы и структуры данных в объектном стиле.

ГВ>>При этом, обрати внимание — в распространённых языках всегда вводится абстракция от вычислительной среды. Увы, императивная, поскольку языки связаны фон-неймановской архитектурой, но — абстракция. Цель, ИМХО, обеспечить максимальную переносимость и эффективность.
AVK>Т.е ты утверждаешь что переносимость С++ выше чем переносимость джавы? Не смешно.

Я этого не утверждаю, а обозначаю своё видение целей.

ГВ>>Кстати, цели у всех одни и те же — поменьше поработать + побольше получить денег за выданный результат, в данном случае — снизить объём механической работы, путём поиска адекватных абстракций.
AVK>Вот тебе и пытаются сказать что рефлекшен существенно уменьшает объем ручной работы, поскольку позволяет создавать абстракции более высокого уровня.

ИМХО, снова не всё так просто. Вот поддержку комонентных технологий и аспектно-ориентированного подхода вижу, но это — просто перенос композиционных подходов компонентных технологий. Перенос подходов, которые, в частности, видоизменены для поддержки перехвата вызовов функций, — одного из элементов реализаци аспектно-ориентированного подхода. Да, набор библиотек, теоретически, может быть больше, манипулировать ими несколько проще, но причём тут абстракция высокого уровня? ИМХО, абстракция высокого уровня — это разделение алгоритмов на элементы, их перекомпоновка и применение к конкретным структурам данных, также обобщаемым.

ГВ>>ИМХО, в таком способе развития есть немалая польза и для окружающих всё это хозяйство наук. Если ахитектура исполнительной среды и языки высокого уровня относительно свободны один от другого, то можно развивать и то и другое за счёт развития теории трансляции и использования новых методов, прежде всего — математических. То есть, "удалённость" взаимной абстракции растёт так или иначе, но при этом развивается и теоретическая база. Обратная дорога — суть немедленная деградация.
AVK>Что то джава уже лет пять наверное деградирует, но все никак не развалится окончательно. Это мне напоминает социализм и капитализм.

Ничего с ней не сделается. Что мне нравится в Java — так это честность: язык — это язык, виртуальная машина его поддержки — это виртуальная машина поддержки языка. А .NET подаётся как единая суперплатформа, у которой будет гора языков с нивелированными до её уровня возможностями.

AVK>А потом — ты хоть раз видел программу на С++ компилирующуюся и под уних и под Win32? Я видел. Там половина кода в #ifdef ХХХ. Поэтому реально портируют софт с использованием cygwin. А это как раз и есть тот самый рантайм. Поэтому про переносимость С++ не надо, хреновая она совсем.

Программы можно писать по-разному. Из того, что ты сейчас сказал, можно сделать только тот вывод, что программу авторам просто лень было переписывать для кроссплатформенности. Или она изначально бестолково спроектирована. Абстракции уровня ОС не стоит смешивать с прикладной логикой — это, извини, альфа и омега.

ГВ>>То есть, языки системного программирования принципиально
AVK>Очень расплывчатый термин. Нет таких языком программирования. Есть задачи. Вот для этих задач (я имею ввиду написание ОС-специфичных вещей) С++ и нужен. И не потому что он обеспечивает высокую степень абстракции а наоборот, слишком тонкий слой отделяет его от ОС.

Это одно из его преимуществ перед другими. С одной стороны — возможность притереться к базовой ОС (как правило, написанной на C), а с другой — создавать систему взаимодействующих абстракций. То, что C++ нередко понимается как преемник C — ошибка понимающих, поскольку C больше похож на аппроксимацию ассемблера, а у C++ — совершенно другая идея.

ГВ>>Однако, когда возник бум программирования, то что произошло? Да то, что и должно было произойти — привлеклась масса попросту неквалифицированных специалистов, у которых превалирует примитивный ("императивный") способ изложения: "делай раз — будет так, делай два — будет эдак и точка".
AVK>Т.е. ты меня и Влада считаешь неквалифицированными программистами?

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

И по-любому, я к конкретным личностям не апеллирую. Почему ты всё время пытешься сделать поспешные выводы относительно личностей?

ГВ>> Они просто не натренированы выражать своё абстрактное мышление в математических терминах и строить абстракции — тоже.
AVK>Однако почему то на джаве и шарпе у меня получается писать быстрее и качественнее.
AVK>Следуя твоей логике — если это так то это означает что я не умею строить абстракций?

Я не буду переходить на личности. Умеешь ты строить абстракции или нет — не мне решать. Мы с тобой спорим. Цель спора с моей стороны — доказать, что C++ — один из лучших инструментов и ещё надолго таким останется. Ты доказываешь, что C++ пора в отстойник, его место занимают другие — новые языки и платформы. OK, вполне нормальный предмет спора. Ты приводишь одни аргументы, я другие. Лучше всего было бы, если бы аргументы касались только особенностей языков и платформ, статистических сведений, оценки целей и целесообразностей и т.п. — не касаясь конкретных личностей и их качеств. "Каков мой собеседник" — меня в данном контексте не интересует и не служит в моих глазах аргументом более значимым, чем логически и рационально обоснованное высказывание. Если тебя что-то лично задевает, даже в моих обобщающих высказываниях — скажи, что тебя это задело или постарайся от этого абстрагироваться или укажи на неправомерность обобщения. А то мы так до драки дойдём.

Относительно Java скажу, что работа на таком языке проще (чем на C++) в каких-то аспектах, но пока дело не доходит до сложных вещей вроде унификации элементов построения программы. Здесь обязательно скажется отсутствие шаблонов.

ГВ>>То есть, фактически, произошёл "откат" в... примерно 50-е — 60-е годы. Такие спецы составляют сейчас абсолютное большинство (по крайней мере, в своём окружении пересчитывал неоднократно

). Они же — основная масса потребителей средств программирования, которые, в ориентации на тупую аудиторию уже конструктивно ограничиваются.
AVK>Попробуй взглянуть на это с другой стороны. В софтостроении потихонечку произошла маленькая революция. Возможно это и возвращение старых идей, но на новом уровне. Тебе же объясняют — на шарпе получается писать намного быстрее и намного качественней даже профессионалам. А то что язык дисциплинирует тех самых чайников это его плюс. Джава в большей степени, шарп в меньшей. Тут альтернатива простая — либо средненькие программеры, либо никакие. В последнее время я предпочитаю брать на работу людей незнакомых с тем что применяется. Научить значительно проще чем переучить.

Но в данном случае ты учишь их конкретным технологиям, а не замещаешь курс философии и теории программирования. Верно?

ГВ>> В них попросту нет того, что могло бы быть. Нет анализа семантики программы, нет построителей графов, нет никаких встроенных математических механизмов, что разумно было бы ожидать от сред поддержки програмирования. Ни хрена этого нет!
AVK>Оно и в плюсах ничего нет.

Да и не нужно "в плюсах". Нужно — "для плюсов".

AVK>Математика не поспевает за программиролванием.

Особенно, если учесть, что всё, что мы тут обсуждаем было теоретически сформулировано ещё, думаю, в 40-х — 70-х гг. Ну да, не хватало элементной базы и производительности. Так этого и сейчас — не сады.

AVK>Пожалуй единственным успешным применением математики в программировании является теория множеств и теория графов.

Если "успешность" — это повсеместность применения, так по такому критерию математике вообще надеяться не на что. ИМХО, это не столько успешность, сколько массовость. Так что же, отменять математику? (Ну, это я утрирую)

AVK>При чем sql сервера потихоньку вылазят из своих реляционных штанишек.

Не успев даже влезть в них полностью.

AVK>Жесткая связь с математическими теориями означает практически отсутствие развития. Использовать надо, но они не должны быть определяющими.

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

ГВ>> Есть только набор "методов", бантики-картиночки и встроенная поддержка построения (ах, извините — "организации") всей этой толпы и раздачи ей малоквалифицированной работы. Но это-то ладно. Однако здесь есть ещё очень интересная завязка на то, что при таких делах интеллектуальные средства развиться просто не смогут! Их же тоже будут писать под управлением таких же менеджеров, бестолковых аналитиков и т.п. Они же просто массой всех задавят.
AVK>Дорогой ты мой, их не посылать надо а делать из них нормальных спецов. Других нет.

Вопросы: 1. Что понимается под словами "нормальный спец"? (Я свои критерии, пусть и приблизительные предложил.) 2. Кто будет делать? (Если следовать им, то это — работа учебных заведений.) 3. И захотят ли они сами этого? (ИМХО — нет.)

ГВ>>Вот тебе и "язык должен учитывать все эти проблемы...".
AVK>Обязательно. Иначе это не язык а абстракция.

А в противном случае это — гипертрофированный калькулятор.

ГВ>>Проблемы кого? Проблемы недоучившихся школьников?
AVK>Да

Не согласен. Это задача языка, на котором учатся применять фон-неймановскую и императивную модель.

ГВ>> То есть, давайте превратим всех в недоучившихся школьников,
AVK>Не надо превращать. Они уже есть.

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

ГВ>> потому что так основной массе будет удобнее? Что-то в этом есть неверное, а конкретно — игнорирование интеллектуальной основы (ИМХО).
AVK>А нету других. Если нужно будет платить больше тысячи каждому программисту (а именно столько стоят сейчас более менее нормальные спецы) то 80% проектов просто загнутся.

Знаешь, а мне не жалко. Может, оставшиеся 20% смогут поднять свой уровень. Хотя... тут и твоя правда есть. Никто не может гарантировать, что оставшиеся действительно будут менять свой уровень.

ГВ>>(ну да — тот самый, очень "сложный", в первую очередь

AVK>Тот самый очень сложный под дотнет есть. MC++ называется.

Но это же не полный C++. А впрочем, это общая проблема...

ГВ>>), тем более — признанные разработчиками! То есть, по сути, частное окружение пытается навязать свою модель разработчикам, которым, по идее, не должно быть до него никакого дела.
AVK>Любой язык вынужден что то навязывать. Даже ассемблер. Не бывает абсолютно универсального языка.

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

ГВ>>Это следствие бушующего идиотизма, извини за прямоту и не прими в свой адрес.
AVK>Я все больше убеждаюсь в том что говорить о вкусе устриц можно только с тем кто их ел.

Я — тоже.

ГВ>> ИМХО, это признак деградации. Поскольку создаёт жёсткую зависимость разработчиков от платформы, на которой их программы будут работать. Язык высокого уровня отделяет разработчика от исполнительной системы.
AVK>Язык высокого уровня отделяет разработчика от меняющегося окружения, а не от рантайма. Пока я от тебя не услышал чем плоха подвязка на рантайм, при условии что рантайм всегда стандартен.

Вот этим последним предложением. Рантайм вряд ли будет всегда стандартен, в том смысле, что один и тот же рантайм будет везде и везде одинаков. Тем более — такая махина.
Как Intel x86 — просто распространённый процессор, и не более того. Есть ещё и другие. И будут появляться другие. И почти наверняка появятся свои версии Intermediate-рантаймов ещё у кого-нибудь. И понесётся. Получим те же точно, старые как мир проблемы, только "в профиль".

ГВ>> Boxing/Unboxing — способ совмещения managed- и unmanaged-кода.
AVK>Абсолютно неверно.

Хорошо, не прав. Способ превращения элементарных данных в объекты.

AVK>>>И проблемы плюсов по большей части связаны не с языком как таковым а со скудностью рантайма.
ГВ>>Не я один хотел бы получить развитый компилятор/интерпретатор/анализатор/type-info-генератор для С++.
AVK>Так в чем проблема то?

Сделать предлагаешь? Может быть, когда-нибудь.

AVK>>>Есть еще джава.
ГВ>>Java, кстати, кажется и на .NET реализована.
AVK>J#.

ГВ>>Что доказывает их подобие
AVK>И гибкость CLR.

И то, что MS очень хочет выбить Java. A la guerre come a la guerre. А вот гибкость... Множественное наследование где?

ГВ>>Но никак не на подержку неограниченного повышения эффективности одного человека.
AVK>Практика показывает что эффективность он таки повышает.

Охарактеризуй задачи на которых так происходит, если не трудно.

ГВ>>ИМХО — нет, поскольку это откат назад в грубом виде. Кстати, на такой оборот речи меня навела дискуссия Vlad2-Аноним где-то в соседних ветках. (http://www.rsdn.ru/forum/?mid=93371)
AVK>Опять же, ты попробуй. Джава и дотнет это вобщем то уникальные явления. Ничего похожего до них не было.

Как-нибудь пороюсь в инете по этому поводу. Навскидку могу вспомнить только то, что Pascal исходно компилировался в P-код.

ГВ>>Нас грубо подталкивают к эффективности реализации примитивных систем, но усложняют деятельность более высокого порядка.
AVK>Как раз наоборот получается. Когда мы пытаемся что то простенькое писать, зачастую на С++ получается не хуже, иногда даже лучше. А вот когда дело доходит до чего то тяжелого тогда и начинают работать все достоинства дотнета или джавы.

Извини, не сочти за личный наезд, но это — иллюстрация неумения пользоваться C++ (ИМХО). Может быть, моё высказывание в твоих глазах — иллюстрация моего неумения писать большие программы. Приведи, pls., описание какого-нибудь подходящего конкретного случая.

AVK>>>В том числе и для этого.
ГВ>>Но появятся ли новые?...
AVK>Почему нет?

Некому будет создавать.

AVK>>>СОМ это прекрасно? Странное у тебя чувство красоты. Отвратительно реализуется надо признать.

AVK>>>CORBA тоже красотой не блещет. И почему ничего лучше пока не сделали? Вот когда я увижу нормальную компонентную модель на С++ я поверю в это.
ГВ>>А слабо самому сделать то, что ты считаешь "нормальной компонентной моделью"?

AVK>А зачем? Она в дотнете уже есть.

Не царское это дело — ставить свою программу в зависимость от...

AVK>Опять же, так как в свое время я пытался это сделать то убежден что ничего существенно лучше COM на С++ не сделаешь.

Расскажи про использованные подходы. Интересно. Может, покритикую, может — поспорим.

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

ГВ>Только смотри что получается! Вместо несовместимости OS1 <-> OS2 получим в итоге несовместимость VM1 <-> VM2. То же самое — только в профиль.
Вобще то на VM стандарт есть.

AVK>>А вот тут как раз пример твоего подхода. Стандартизировали язык, а про рантайм как то забыли. В результате у каждого sql-сервера, у каждого odbc-драйвера для настольных СУБД свой диалект. Очень хорошо иллюстрирует результаты попыток создания языка в отрыве от окружения.

ГВ>Извини, не понял, что ты имел ввиду. Какой ещё рантайм у SQL?
SQL-сервер и VM выполнения запросов.

ГВ> SQL же — язык запросов. У него рантаймов может быть — вагон и две телеги. Потому и стандартизируется язык как таковой. Просто, как всегда, крупным мануфактурерам до балды что там ANSI вытворяет.
А как ты думаешь, почему? Вобще то производителям обычно выгодно придерживаться стандартов.

ГВ> ИМХО, — это результат того, что они отбивают друг у друга клиентов и стараются удержать своих. Вполне естественно.
Только SQL'92 они все же поддерживают. И потом я не зря сказал что все. Ну положим оракль может позволить себе поступать подоьбным образом, но MySQL что, тоже подобным образом клиентов отбивает? PostgreSQL? InterBase? Просто SQL'92 оказался слишком отвязан от рантайма и реальной жизни и просто не справился с меняющейся средой. Для современного сервера считается нормой поддержка хранимых процедур и триггеров. А вот этого SQL'92 обеспечить не в состоянии.
Вот и вышел пример отвязки языка от рантайма там где этого делать не следовало. Чтобы получить универсальный SQL нужно стандартизировать рантайм, а этого сделано не было.

ГВ>Однако те окружения, о которых мы тут говорим — собственность одного производителя (MS или Sun).
На CLR есть ECMA стандарт. А вот Win32 кстати является собственностью MS.

ГВ>Пример слегка натянутый, но ... Так в чём проблема-то?

Остановка работы станции на 1 мин, копирование нового .EXE и перезапуск новой программы. И так на 5-и станциях. Всё.

Ага, а где гарантия что старый клиент с новым конфликтовать не будет?

ГВ>

И уж поверь, что для такого случая я в самую последнюю очередь подумаю о Java, .NET и тем более — COM.

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

ГВ>Я вполне понимаю их премущества но не в области повышения надёжности или быстродействия. Только относительно гибкости.
Быстродействия нет, надежности да, причем в разы. Это практический опыт.

AVK>>Т.е ты утверждаешь что переносимость С++ выше чем переносимость джавы? Не смешно.
ГВ>Я этого не утверждаю, а обозначаю своё видение целей.
Это прямо следует из твоих утверждений.

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

ГВ>ИМХО, снова не всё так просто.
Ну устал я уже с тобой спорить. Просто, не просто, но я это пробовал. Эффект есть, причем очень большой. Не веришь? Попробуй.

AVK>>Что то джава уже лет пять наверное деградирует, но все никак не развалится окончательно. Это мне напоминает социализм и капитализм.

ГВ>Ничего с ней не сделается. Что мне нравится в Java — так это честность: язык — это язык, виртуальная машина его поддержки — это виртуальная машина поддержки языка.
Да прям уж. А чего так народ на JVM ругается что он очень сильно на язык заточен? Подвязана джава на свой рантайм, причем очень сильно.

ГВ> А .NET подаётся как единая суперплатформа, у которой будет гора языков с нивелированными до её уровня возможностями.
Знаешь, я в отличие от тебя не смотрю как что подается а беру и пробую. А на то что и как подается мне плевать.

ГВ>Программы можно писать по-разному.
Ну да, конечно. Я писать не умею а ты умеешь.

ГВ>Это одно из его преимуществ перед другими.
И это же его недостаток. Следствие этого — трудность написания тех самых больших и сложных проектов.

ГВ> С одной стороны — возможность притереться к базовой ОС (как правило, написанной на C), а с другой — создавать систему взаимодействующих абстракций. То, что C++ нередко понимается как преемник C — ошибка понимающих, поскольку C больше похож на аппроксимацию ассемблера, а у C++ — совершенно другая идея.
Идея другая, а реализация похожа.

AVK>>Т.е. ты меня и Влада считаешь неквалифицированными программистами?
ГВ>У меня нет на это оснований, ввиду того, что критерии квалификации,
Ну а как воспринимать тогда твои слова о том что на дотнете проще писать проекты только неквалифицированным программистам?
Вот лично мне большинство проектов проще писать на дотнете.

ГВ>Почему ты всё время пытешься сделать поспешные выводы относительно личностей?
Знаешь, я делаю логичные выводы из твоих предпосылок.

AVK>>Следуя твоей логике — если это так то это означает что я не умею строить абстракций?
ГВ>Я не буду переходить на личности.
Знаешь, ты хорошую позицию выбрал. Намеки делаешь, а как тебя за них спрашивают то говоришь что ты такого не имел ввиду. Очень странное ощущуение возникает от такого общения.

ГВ>Цель спора с моей стороны — доказать, что C++ — один из лучших инструментов и ещё надолго таким останется.
Тогда не надо делать таких высказываний. Я тебе привел в качестве аргумента свой опыт реализации проектов на джаве, а теперь уже и на дотнете. А ты мне, (о да, прямо кого либо ты не упоминаешь) говоришь что мол некие программисты пишут некие программы на дотнете лучше потому что они не умеют строить абстракции на С++. Знаешь, у меня с логикой все в порядке и я еще в состоянии сделать соответствующие выводы.

ГВ> Ты доказываешь, что C++ пора в отстойник, его место занимают другие — новые языки и платформы.
Нет, я доказываю что ему пора меняться.

ГВ>Относительно Java скажу, что работа на таком языке проще (чем на C++) в каких-то аспектах, но пока дело не доходит до сложных вещей вроде унификации элементов построения программы. Здесь обязательно скажется отсутствие шаблонов.
Ты просто привык ими пользоваться. Вполне неплохо живется и без них.

ГВ>Но в данном случае ты учишь их конкретным технологиям, а не замещаешь курс философии и теории программирования. Верно?
Не совсем. Прежде всего я их учу как правильно программировать, как обеспечить надежность кода, как обеспечить легкую ее модифицируемость и т.д. и т.п. А конкретике они учатся сами. Максимум что в этом плане я иногда делаю это сажусь и пишу какие то особо сложные куски вместе с ними.

AVK>>Математика не поспевает за программиролванием.
ГВ>Особенно, если учесть, что всё, что мы тут обсуждаем было теоретически сформулировано ещё, думаю, в 40-х — 70-х гг. Ну да, не хватало элементной базы и производительности. Так этого и сейчас — не сады.
Это не математика.

ГВ>Если "успешность" — это повсеместность применения, так по такому критерию математике вообще надеяться не на что. ИМХО, это не столько успешность, сколько массовость. Так что же, отменять математику? (Ну, это я утрирую)
Не отменять, но и не делать ее определяющей. Я по моему ясно выразился.

AVK>>При чем sql сервера потихоньку вылазят из своих реляционных штанишек.
ГВ>Не успев даже влезть в них полностью.

Ну это уже издержки развития.

AVK>>Жесткая связь с математическими теориями означает практически отсутствие развития. Использовать надо, но они не должны быть определяющими.
ГВ>То есть, невозможно показать структурный граф программы или функции и просто посчитать характеристики его ребер? Позволю себе в этом с тобой не согласиться.
Я еще раз повторюсь — Не отменять, но и не делать ее определяющей.

ГВ>Вопросы: 1. Что понимается под словами "нормальный спец"?
Человек который способен решать поставленные задачи и при этом решать их качественно.

ГВ>2. Кто будет делать? (Если следовать им, то это — работа учебных заведений.)
Это зависит от обстоятельств. Как правило это руководитель группы.

ГВ>3. И захотят ли они сами этого? (ИМХО — нет.)
А им деваться будет некуда. Либо они учатся решать поставленные задачи либо идут лесом.

AVK>>Обязательно. Иначе это не язык а абстракция.
ГВ>А в противном случае это — гипертрофированный калькулятор.
Нет, это нормальный инструмент.

AVK>>А нету других. Если нужно будет платить больше тысячи каждому программисту (а именно столько стоят сейчас более менее нормальные спецы) то 80% проектов просто загнутся.
ГВ>Знаешь, а мне не жалко. Может, оставшиеся 20% смогут поднять свой уровень. Вот в этом все и дело. Тебе шашечки а тем кто деньги платит нужно ехать.

AVK>>Тот самый очень сложный под дотнет есть. MC++ называется.
ГВ>Но это же не полный C++. А впрочем, это общая проблема...
Полный + managed расширения. Множественное наследование и шаблоны там есть, так что все в порядке

AVK>>Любой язык вынужден что то навязывать. Даже ассемблер. Не бывает абсолютно универсального языка.
ГВ>Абсолютно согласен. Именно поэтому идеального языка не может быть, как и идеального процессора. А что мы имеем в случае .NET? Попытку нивелировать все .NET-языки под её лад.
Ну там достаточно простора для вариаций. А вобще увеличение ограничений от ассемблера через С, С++ к дотнету очень хорошо прослеживается. Не вижу причин считать что ограничения С++ еще позволительны а дотнета уже нет.

AVK>>Я все больше убеждаюсь в том что говорить о вкусе устриц можно только с тем кто их ел.
ГВ>Я — тоже.

Ну у меня был достаточно длительный опыт общения с С++. Да и Владу и IT я в общем то доверяю.

AVK>>Язык высокого уровня отделяет разработчика от меняющегося окружения, а не от рантайма. Пока я от тебя не услышал чем плоха подвязка на рантайм, при условии что рантайм всегда стандартен.

ГВ>Вот этим последним предложением. Рантайм вряд ли будет всегда стандартен, в том смысле, что один и тот же рантайм будет везде и везде одинаков.
Пример джавы показывает что это не так.

ГВ>Как Intel x86 — просто распространённый процессор, и не более того. Есть ещё и другие. И будут появляться другие.
Вот вот. А С++ не очень в плане совместимости.

ГВ> И почти наверняка появятся свои версии Intermediate-рантаймов ещё у кого-нибудь.
За сколько там лет существования джавы несовместимых рантаймов пока не появилось.

ГВ>>> Boxing/Unboxing — способ совмещения managed- и unmanaged-кода.
AVK>>Абсолютно неверно.
ГВ>Хорошо, не прав. Способ превращения элементарных данных в объекты.
Вот это и есть решение той же проблемы которую решают шаблоны. Да, в плане производительности не фонтан, но на удобство построения абстракций это не влияет.

AVK>>Так в чем проблема то?
ГВ>Сделать предлагаешь? Может быть, когда-нибудь.
Вот. А в дотнете уже есть.

ГВ>>>Что доказывает их подобие
AVK>>И гибкость CLR.
ГВ>И то, что MS очень хочет выбить Java. A la guerre come a la guerre. А вот гибкость... Множественное наследование где?

Рефлекшен где?

AVK>>Практика показывает что эффективность он таки повышает.
ГВ>Охарактеризуй задачи на которых так происходит, если не трудно.
ERP, Web

AVK>>Опять же, ты попробуй. Джава и дотнет это вобщем то уникальные явления. Ничего похожего до них не было.
ГВ>Как-нибудь пороюсь в инете по этому поводу. Навскидку могу вспомнить только то, что Pascal исходно компилировался в P-код.
При чем тут P-код? Вон VB от рождения был пикодным. Однако от этого подобием джавы или дотнета он не становится.

ГВ>Извини, не сочти за личный наезд, но это — иллюстрация неумения пользоваться C++ (ИМХО).
Вот вот. Все твои аргументы сводятся к тому что ты считаешь себя знатоком построения абстракций.

ГВ>>>А слабо самому сделать то, что ты считаешь "нормальной компонентной моделью"?

AVK>>А зачем? Она в дотнете уже есть.
ГВ>Не царское это дело — ставить свою программу в зависимость от...

Мне не шашечки, мне ехать. Написание художественных программ я оставлю на потом.

AVK>>Опять же, так как в свое время я пытался это сделать то убежден что ничего существенно лучше COM на С++ не сделаешь.
ГВ>Расскажи про использованные подходы. Интересно. Может, покритикую, может — поспорим.
Было давно, лет эдак 6 назад, да и не хочется мне это обсуждать.

... Янус версия 1.0 alpha 2

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

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Только смотри что получается! Вместо несовместимости OS1 <-> OS2 получим в итоге несовместимость VM1 <-> VM2. То же самое — только в профиль.
AVK>Вобще то на VM стандарт есть.

На C++ тоже стандарт есть. И всем известно, как он соблюдается

А у MS вообще нездоровая тяга все "улучшать" на свой вкус.

Не помню, кто сказал, что законы существуют, чтобы их нарушать.

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

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Только смотри что получается! Вместо несовместимости OS1 <-> OS2 получим в итоге несовместимость VM1 <-> VM2. То же самое — только в профиль.
AVK>Вобще то на VM стандарт есть.

Я имел ввиду, например то, что Java/.NET будет несовместима с Java/Sun и т.п.

AVK>>>А вот тут как раз пример твоего подхода. Стандартизировали язык, а про рантайм как то забыли. В результате у каждого sql-сервера, у каждого odbc-драйвера для настольных СУБД свой диалект. Очень хорошо иллюстрирует результаты попыток создания языка в отрыве от окружения.

См. ниже.

ГВ>>Извини, не понял, что ты имел ввиду. Какой ещё рантайм у SQL?
AVK>SQL-сервер и VM выполнения запросов.

ГВ>> SQL же — язык запросов. У него рантаймов может быть — вагон и две телеги. Потому и стандартизируется язык как таковой. Просто, как всегда, крупным мануфактурерам до балды что там ANSI вытворяет.
AVK>А как ты думаешь, почему? Вобще то производителям обычно выгодно придерживаться стандартов.

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

ГВ>> ИМХО, — это результат того, что они отбивают друг у друга клиентов и стараются удержать своих. Вполне естественно.
AVK>Только SQL'92 они все же поддерживают. И потом я не зря сказал что все. Ну положим оракль может позволить себе поступать подоьбным образом, но MySQL что, тоже подобным образом клиентов отбивает? PostgreSQL? InterBase? Просто SQL'92 оказался слишком отвязан от рантайма и реальной жизни и просто не справился с меняющейся средой. Для современного сервера считается нормой поддержка хранимых процедур и триггеров. А вот этого SQL'92 обеспечить не в состоянии.
AVK>Вот и вышел пример отвязки языка от рантайма там где этого делать не следовало. Чтобы получить универсальный SQL нужно стандартизировать рантайм, а этого сделано не было.

OK, хороший пример на самом деле. Но заметь, что если бы стандарт оговаривал ещё и реализацию VM, то это существенно усложнило бы выход новых игроков на рынок. Проиграли бы все. И ANSI — в том числе.

Кстати, SQL'92 достаточно сложный стандарт и его полная поддержка тоже есть не везде. (IB, если не ошибаюсь — Entry Level).

ГВ>>Однако те окружения, о которых мы тут говорим — собственность одного производителя (MS или Sun).
AVK>На CLR есть ECMA стандарт. А вот Win32 кстати является собственностью MS.

OK, CLR/ECMA.

ГВ>>Пример слегка натянутый, но ... Так в чём проблема-то?

Остановка работы станции на 1 мин, копирование нового .EXE и перезапуск новой программы. И так на 5-и станциях. Всё.

AVK>Ага, а где гарантия что старый клиент с новым конфликтовать не будет?

Только в том, что новый клиент обеспечит поддержку функциональности старого. Это — моя обязанность как разработчика, который решает проблемы клиента. Как же иначе-то?

ГВ>>

И уж поверь, что для такого случая я в самую последнюю очередь подумаю о Java, .NET и тем более — COM.

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

Я тоже считаю, что в определённом смысле такие технологии необходимы, но в разумных пределах.

ГВ>>Я вполне понимаю их премущества но не в области повышения надёжности или быстродействия. Только относительно гибкости.
AVK>Быстродействия нет, надежности да, причем в разы. Это практический опыт.

Я вижу причину повышения надёжности в том, что исходно задана спецификация на функционирование компонента. Т.е., — введены ограничения. Плюс — предоставлен ряд готовых отлаженных механизмов управления компонентами. Т.е., — причина — в конкретике, а не в парадигме.

AVK>>>Т.е ты утверждаешь что переносимость С++ выше чем переносимость джавы? Не смешно.
ГВ>>Я этого не утверждаю, а обозначаю своё видение целей.
AVK>Это прямо следует из твоих утверждений.

Потенциально — да, поскольку C++ не тащит за собой рантайма. Но на данный момент, увы, это только потенциально.

AVK>>>Вот тебе и пытаются сказать что рефлекшен существенно уменьшает объем ручной работы, поскольку позволяет создавать абстракции более высокого уровня.
ГВ>>ИМХО, снова не всё так просто.
AVK>Ну устал я уже с тобой спорить. Просто, не просто, но я это пробовал. Эффект есть, причем очень большой. Не веришь? Попробуй.

Верю, верю.

Но пробовать без понимания (даже интуитивного) — не буду.

AVK>>>Что то джава уже лет пять наверное деградирует, но все никак не развалится окончательно. Это мне напоминает социализм и капитализм.
ГВ>>Ничего с ней не сделается. Что мне нравится в Java — так это честность: язык — это язык, виртуальная машина его поддержки — это виртуальная машина поддержки языка.
AVK>Да прям уж. А чего так народ на JVM ругается что он очень сильно на язык заточен? Подвязана джава на свой рантайм, причем очень сильно.

Я понял, что некорректно высказался. Вернее будет: JVM+Java — одно целое.

ГВ>> А .NET подаётся как единая суперплатформа, у которой будет гора языков с нивелированными до её уровня возможностями.
AVK>Знаешь, я в отличие от тебя не смотрю как что подается а беру и пробую. А на то что и как подается мне плевать.

А я вот смотрю и стараюсь выяснить, чем является что-то до того, как начну его использовать, тем более, использовать так, что пути назад потом не окажется. Затем уже я вывожу своё отношение к способу подачи этого самого чего-то. Почему, кстати, и остановился на C++, а не на Delphi в своё время. Кстати, благодарен тебе за оппонирование в этой и других дискуссиях. Заставил (косвенно) поразбираться с .NET и C#. Спасибо. Платформа меня заинтересовала в чём-то.

ГВ>>Программы можно писать по-разному.
AVK>Ну да, конечно. Я писать не умею а ты умеешь.

Не нужно обобщать на общее "умение" или "неумение". Если всякое моё сомнение и сослагательное наклонение расценивать как намёк серии "Здесь все дураки, а я умный", то ничего хорошего, не выйдет. Уверен, что у меня тоже хватает ошибок в доводах. Но искать их — удел оппонентов.

Моя задача — максимально логично с моей точки зрения их скомпоновать.

ГВ>>Это одно из его преимуществ перед другими.
AVK>И это же его недостаток. Следствие этого — трудность написания тех самых больших и сложных проектов.

ИМХО, самый большой недостаток C++ в том, что он заставляет делать выбор, но с моей точки зрения это — очень большое его преимущество и трактуется как предоставление свободы манёвра.

ГВ>> С одной стороны — возможность притереться к базовой ОС (как правило, написанной на C), а с другой — создавать систему взаимодействующих абстракций. То, что C++ нередко понимается как преемник C — ошибка понимающих, поскольку C больше похож на аппроксимацию ассемблера, а у C++ — совершенно другая идея.
AVK>Идея другая, а реализация похожа.

Ну так он и создавался с учётом того, что очень много C-программистов и софта на C. Так что, прямое наследование C увы, было неизбежным. А отказ от модели объектов в стиле Smalltalk (общий базовый объект) — следствие требования сильной типизации и эффективности выполнения. Тот факт, что, например, идиомы C (например, const char *) затаскиваются на самый верхний уровень создаваймых на C++ абстракций, ИМХО, следствие неосознанного подхода. C++ включает C как подмножество, а не как однозначное руководство к действию!

AVK>>>Т.е. ты меня и Влада считаешь неквалифицированными программистами?
ГВ>>У меня нет на это оснований, ввиду того, что критерии квалификации,
AVK>Ну а как воспринимать тогда твои слова о том что на дотнете проще писать проекты только неквалифицированным программистам?
AVK>Вот лично мне большинство проектов проще писать на дотнете.

Воспринимать мои слова лучше всего в отвязке от персоналий, в каковой контекст они и были помещены. "И шо за манера всё на свой счёт принимать?"

Это — раз. Два. С другой стороны — а уж не ради ли неквалифицированных программистов, в частности, в дотнетовский C# внесены упрощения и сандартизированы идиомы? А? Уж не для них ли произведено "упрощение и развитие C++"? Естественно, что на дотнете писать проще всем, независимо от уровня квалификации (в тех терминах, в которых я её определял). Однако, в этом мире ничего не бывает однозначного. То есть, упростив модель, другим концом заблокировали возможность реализации сложных комбинаций, которые не всем были "по силам".

Из вышесказанного, ИМХО, никак не следует, что я отношусь к тебе, как к неквалифицированому программисту.
А тебе просто советую. Прежде, чем делать скоротечные выводы и обижаться, подумать, например о корректности моего определения термина "квалификация".

ГВ>>Почему ты всё время пытешься сделать поспешные выводы относительно личностей?
AVK>Знаешь, я делаю логичные выводы из твоих предпосылок.

Но крайне поспешно, по отношению только к себе, и к тем, кому ты доверяешь, и абсолютно необоснованно обижаешься, чем сбиваешь дискуссию в сторону выяснений личных отношений. Ты вполне мог контраргументировать, например, обвинив меня в неуместном обобщении. Было бы интересно. А так... Знаешь, просто нерационально это — так активно бросаться на обобщения. Их может быть много и разных, они могут быть корректными или нет. На всех энергии не напасёсси.

AVK>>>Следуя твоей логике — если это так то это означает что я не умею строить абстракций?
ГВ>>Я не буду переходить на личности.
AVK>Знаешь, ты хорошую позицию выбрал. Намеки делаешь, а как тебя за них спрашивают то говоришь что ты такого не имел ввиду. Очень странное ощущуение возникает от такого общения.

Если кто-то увидел в моих словах намёк на отрицательную оценку своей личности, извините, это уж не мои трудности. ИМХО, это просто нерационально и попахивает этаким "гусарством", типа "а кто тут против C#/C++/Java/VB...! Так он меня <отрицательный эпитет вписать> считает?". Если ты хочешь уличить меня в некорректности аргументов того или иного класса — уличай, а не превращай форум в склоку и выяснение личных отношений.

Последи за своими выводами и характером вопросов. Ты берешь моё очень общее высказывание, не потрудившись оценить корректности предпосылок, примериваешь его на себя. Вероятно, по тем или иным причинам находишь, что в данном контексте (неизвестно, корректном или нет!) на тебя накладывается отрицательная оценка и бросаешься на оппонента с вызывающими и провоцирующими вопросами, т.е., — атакуешь, аргументируя на совершенно ином уровне. Какой я могу сделать из этого вывод? А такой, что ты очень трепетно относишься к признанию своей правоты, и очень агрессивно даже косвенному её оспариванию. Извини, но в таком случае стоило выходить из спора раньше. Хотя, конечно, я понимаю, что концептуальные споры — достаточно опасная штука.

В противовес такой позиции я — не боюсь признания своей неправоты и при доказанной их некорректности корректирую свои взгляды и суждения. Так что? У кого из нас должно сложиться "странное ощущение"?

ГВ>>Цель спора с моей стороны — доказать, что C++ — один из лучших инструментов и ещё надолго таким останется.
AVK>Тогда не надо делать таких высказываний. Я тебе привел в качестве аргумента свой опыт реализации проектов на джаве, а теперь уже и на дотнете. А ты мне, (о да, прямо кого либо ты не упоминаешь) говоришь что мол некие программисты пишут некие программы на дотнете лучше потому что они не умеют строить абстракции на С++.

Я не понимаю, что оскорбительного в признании умения/неумения строить абстракции какой-то глубины на C++? Я вот, например, плохо знаю дотнет и спокойно отношусь к тому, что меня тыкают носом в это незнание. Сегодня — не знаю, завтра — знаю. Что здесь обидного? А у моей уверенности в том, что немного людей может хорошо программировать на C++ тоже рациональные основы. Мне вот, практически не приходилось близко сталкиваться с людьми (кроме как на форумах RSDN), которые уверенно оперируют конструкциями вроде двухуровневых вложенных шаблонов или частичной специализации. Тогда как наивных вопросов по шаблонам и воплей об их сложности — более чем достаточно.

С дргой стороны... ну, про простоту дотнета я уже писал.

AVK>Знаешь, у меня с логикой все в порядке и я еще в состоянии сделать соответствующие выводы.

Только ты их однобоко очень делаешь. Часто видишь повод для обиды, вместо того, чтобы сказать, что у тебя, к примеру, нет подходящих (контр-)аргументов, или я неправомерно привожу свои.

ГВ>> Ты доказываешь, что C++ пора в отстойник, его место занимают другие — новые языки и платформы.
AVK>Нет, я доказываю что ему пора меняться.

Извини, я тебя неверно интерпретировал. Однако, ИМХО, некорректно требовать изменения C++ (общего) на основании своего неудачного опыта (ИМХО, частного случая), или на основании столкновения с неудачной его реализацией (MSVC6). Тогда как возможность реализации какой-либо идиомы на C++ даже в одном-единственном случае (частное решение) вполне себе основание для того, чтобы не изменять его ради этой идиомы. Чистый рационализм.

Хотя, безусловно, я вижу достаточно веские причины для отказа от использования того же C++ в силу и при условии: а) невозможности использовать его в полную.силу (отклонения MSVC6) и б) невозможности сменить транслятор.

ГВ>>Относительно Java скажу, что работа на таком языке проще (чем на C++) в каких-то аспектах, но пока дело не доходит до сложных вещей вроде унификации элементов построения программы. Здесь обязательно скажется отсутствие шаблонов.
AVK>Ты просто привык ими пользоваться. Вполне неплохо живется и без них.

Да, но теряется возможность оторвать алгоритмы от структур данных и сделсть это в объектном стиле и с минимальной потерей быстродействия (ИМХО!!!).
На самом деле, ИМХО, здесь надо сравнивать метрики и функциональность аналогичных программ, написанных на C++ (не кастрированном! и с привлечением независимых библиотек) и Java/C#.

ГВ>>Но в данном случае ты учишь их конкретным технологиям, а не замещаешь курс философии и теории программирования. Верно?
AVK>Не совсем. Прежде всего я их учу как правильно программировать, как обеспечить надежность кода, как обеспечить легкую ее модифицируемость и т.д. и т.п. А конкретике они учатся сами. Максимум что в этом плане я иногда делаю это сажусь и пишу какие то особо сложные куски вместе с ними.

ИМХО, — здраво с практической точки зрения. Вопрос: а рассказываешь ли ты им о том, что желательно выделять подобные элементы из разных модулей программы в устойчивые идиомы?

AVK>>>Математика не поспевает за программиролванием.
ГВ>>Особенно, если учесть, что всё, что мы тут обсуждаем было теоретически сформулировано ещё, думаю, в 40-х — 70-х гг. Ну да, не хватало элементной базы и производительности. Так этого и сейчас — не сады.
AVK>Это не математика.

Хорошо. Изменю формулировку. Идеи существовали давно (Simula появилась в 67 году, про AOSD пока ничего сказать не могу). Как следствие, придётся временно признать твой довод о том, что математика не поспевает за програмированием. Я поищу доказательства обратного. Кстати, здесь лежит моделирование перехвата вызовов методов на языке формальной семантики.

ГВ>>Если "успешность" — это повсеместность применения, так по такому критерию математике вообще надеяться не на что. ИМХО, это не столько успешность, сколько массовость. Так что же, отменять математику? (Ну, это я утрирую)
AVK>Не отменять, но и не делать ее определяющей. Я по моему ясно выразился.

"Ближе к жизни!" — если я правильно тебя понял. Тоже вариант, но жизнь (вернее, её восприятие) изменчива, а то, что обосновано логически (в частности — с испоьзованием математического аппарата) — в меньшей степени. Мне не нравится гонка за "жизнью", как за совокупностью господствующих стереотипов и я чаще вижу в этом просто моду, как выражение отношения к статистическим данным, собранным в одной группе людей и, возможно, неправомерно обобщённой на другую (первая обычно много меньше второй).

AVK>>>При чем sql сервера потихоньку вылазят из своих реляционных штанишек.
ГВ>>Не успев даже влезть в них полностью.

AVK>Ну это уже издержки развития.

И погони за модой, ИМХО... Мне лично всегда казалось, что это глупость — развивать процедурные языки для баз данных (несмотря на то, что ими почти все пользуются). В результате создаётся соблазн "быстрых решений" и... распыление усилий на разные реализации одних и тех же абстракций.

AVK>>>Жесткая связь с математическими теориями означает практически отсутствие развития. Использовать надо, но они не должны быть определяющими.
ГВ>>То есть, невозможно показать структурный граф программы или функции и просто посчитать характеристики его ребер? Позволю себе в этом с тобой не согласиться.
AVK>Я еще раз повторюсь — Не отменять, но и не делать ее определяющей.

Я не думаю, что в данном случае математика стала бы определяющим фактором, но анализ каких-то аспектов программы мог бы оказаться проще. Кстати, подобные продукты есть, например, на www.powersoftware.com. Но мне, признаться, они не понравились в силу того, что очень криво обрабатывают C++.

AVK>
ГВ>>Вопросы: 1. Что понимается под словами "нормальный спец"?
AVK>Человек который способен решать поставленные задачи и при этом решать их качественно.

Каковы задачи? Каковы критерии качества?

ГВ>>2. Кто будет делать? (Если следовать им, то это — работа учебных заведений.)
AVK>Это зависит от обстоятельств. Как правило это руководитель группы.

Руководитель группы — практик. Без собственнной теоретической и практической подготовки его ученики или не сумеют сделать обобщений, или потратят на это уйму времени.

ГВ>>3. И захотят ли они сами этого? (ИМХО — нет.)
AVK>А им деваться будет некуда. Либо они учатся решать поставленные задачи либо идут лесом.

Здесь надо обсудить решаемые задачи. Мне вот приходилось экспертную систему за ~месяц писать, вместе с интерпретатором языка. Так что, давай обсудим масштаб решаемых задач. ИМХО (!) — он должен при вышеуказанных (п.2) раскладах "сжиматься" до простых практических задач с чётко ограниченным контекстом.

AVK>>>Обязательно. Иначе это не язык а абстракция.
ГВ>>А в противном случае это — гипертрофированный калькулятор.
AVK>Нет, это нормальный инструмент.

Хорошо, принимаю, что ты считаешь инструмент такого рода нормальным. (Здесь я не накладываю ни на кого отрицательных оценок)

AVK>>>А нету других. Если нужно будет платить больше тысячи каждому программисту (а именно столько стоят сейчас более менее нормальные спецы) то 80% проектов просто загнутся.
ГВ>>Знаешь, а мне не жалко. Может, оставшиеся 20% смогут поднять свой уровень.
AVK>Вот в этом все и дело. Тебе шашечки а тем кто деньги платит нужно ехать.

Ты совершенно прав. Предлагаю разобраться в значении этих терминов с учётом времени эксплуатации программы, её мутабельности и т.п.

AVK>>>Тот самый очень сложный под дотнет есть. MC++ называется.
ГВ>>Но это же не полный C++. А впрочем, это общая проблема...
AVK>Полный + managed расширения. Множественное наследование и шаблоны там есть, так что все в порядке

А какие шаблоны там есть? Частичная специализация есть? Насколько я знаю — нет.

AVK>>>Любой язык вынужден что то навязывать. Даже ассемблер. Не бывает абсолютно универсального языка.
ГВ>>Абсолютно согласен. Именно поэтому идеального языка не может быть, как и идеального процессора. А что мы имеем в случае .NET? Попытку нивелировать все .NET-языки под её лад.
AVK>Ну там достаточно простора для вариаций. А вобще увеличение ограничений от ассемблера через С, С++ к дотнету очень хорошо прослеживается. Не вижу причин считать что ограничения С++ еще позволительны а дотнета уже нет.

Я вижу причины так считать, поскольку модель .NET заставляет выворачивать реализацию абстракции в своих терминах. Термины, ИМХО, пока ещё достаточно специфичны.

AVK>>>Я все больше убеждаюсь в том что говорить о вкусе устриц можно только с тем кто их ел.
ГВ>>Я — тоже.

AVK>Ну у меня был достаточно длительный опыт общения с С++. Да и Владу и IT я в общем то доверяю.

Аналогично. Но глядя на аргументацию (Влада, в частности) я прихожу к выводу о том, что она часто спровоцирована покалеченной реализацией C++ компилятором VC++. Отсюда (и из других наблюдений) делаю вывод, что Влад просто не может быть единственным в своём роде, то есть какой-то процент голосов "за" дотнет собрал за счёт именно подобных ситуаций. Думаешь, я сомневаюсь в его интеллектуальных качествах? Или — в твоих? Поверь — нисколько. Я сомневаюсь в правомерности употребления каких-то аргументов и не более того.

Я и сам нахлебался с VC++ проблем именно из-за отсутствия нормальной реализации шаблонов. А отсюда не получил своевременно достаточного опыта их использования, да и не сделал того, что хотел сделать. Но отказываться от них и от C++ не собираюсь, уж слишком велики были потенциальные пряники в плане повышения эффективности труда. А потому и "машу перьями" ("ерепенюсь" и т.п. — пусть эпитет подберут те, кто на это мастер) в адрес C#/Java, когда вижу, что по модели языки... ИМХО — не очень.

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

), либо за счёт разбиения программы на "цельные" в прикладном смысле модули — и тогда приходится работать большой командой. Первый подход очень трудно осуществлять в большой команде — даже больше 2-3 чел., но пряники просто охренительны и шаблоны оказывают здесь огромную помощь. Кстати, разумеется, что первый подход ни в коем случае не исключает использования второго, но структура модулей выбирается исходя из требований deployment. Результат достижим и в том и в другом случаях, но во втором мы получаем с большой вероятностью потерю внутренней унификации, а отсюда — бо-о-ольшой ворох проблем в будущем. Ну, сам, вероятно, знаешь. Так вот, я — сторонник первого подхода. Можно обсудить его рациональность или отсутствие таковой.

AVK>>>Язык высокого уровня отделяет разработчика от меняющегося окружения, а не от рантайма. Пока я от тебя не услышал чем плоха подвязка на рантайм, при условии что рантайм всегда стандартен.
ГВ>>Вот этим последним предложением. Рантайм вряд ли будет всегда стандартен, в том смысле, что один и тот же рантайм будет везде и везде одинаков.
AVK>Пример джавы показывает что это не так.

Хм... Я встречал отзывы, что всё-таки надо учитывать особености GC той или иной JVM. Так что, мне кажется, что твоё обобщение далековато от реальности.

ГВ>>Как Intel x86 — просто распространённый процессор, и не более того. Есть ещё и другие. И будут появляться другие.
AVK>Вот вот. А С++ не очень в плане совместимости.

Увы, это так. Но посмотрим, как всё сложится дальше. Как я недавно выяснил, IBM VAC++, Intel, GCC 2.95.2, Comeau весьма близко подошли к реализации стандарта.

ГВ>> И почти наверняка появятся свои версии Intermediate-рантаймов ещё у кого-нибудь.
AVK>За сколько там лет существования джавы несовместимых рантаймов пока не появилось.

Я, пожалуй, перегнул палку, но имелось ввиду, что а) мелкие несовместимости всё равно будут, б) скорее всего появятся реализации других рантаймов для других языков. ИМХО, свято место...

ГВ>>>> Boxing/Unboxing — способ совмещения managed- и unmanaged-кода.
AVK>>>Абсолютно неверно.
ГВ>>Хорошо, не прав. Способ превращения элементарных данных в объекты.
AVK>Вот это и есть решение той же проблемы которую решают шаблоны. Да, в плане производительности не фонтан, но на удобство построения абстракций это не влияет.

ИМХО, — слабоватая альтернатива шаблонам в целом. Недостаток производительности может щёлкнуть по носу при глубоко структурированных абстракциях.

AVK>>>Так в чем проблема то?
ГВ>>Сделать предлагаешь? Может быть, когда-нибудь.
AVK>Вот. А в дотнете уже есть.

В дотнете нету C++. Вот почему. "Наличием C++" я называю такую реализацию, которая поддерживает трансляцию в исполняемый код (или же, интерпретацию) входного языка, соответствующего описанию ANSI C++. Судя по всему, у MSVC7 серьёзные проблемы с этим.

ГВ>>>>Что доказывает их подобие
AVK>>>И гибкость CLR.
ГВ>>И то, что MS очень хочет выбить Java. A la guerre come a la guerre. А вот гибкость... Множественное наследование где?

AVK>Рефлекшен где?

Да где-где...

У разработчиков трансляторов спросить надо.

AVK>>>Практика показывает что эффективность он таки повышает.
ГВ>>Охарактеризуй задачи на которых так происходит, если не трудно.
AVK>ERP, Web

А чуть подробнее можно? Я уже просил тебя привести хоть часть метрик твоей ERP. Кстати, ты ничего не ответил.

AVK>>>Опять же, ты попробуй. Джава и дотнет это вобщем то уникальные явления. Ничего похожего до них не было.
ГВ>>Как-нибудь пороюсь в инете по этому поводу. Навскидку могу вспомнить только то, что Pascal исходно компилировался в P-код.
AVK>При чем тут P-код? Вон VB от рождения был пикодным. Однако от этого подобием джавы или дотнета он не становится.

Не стандартизовали, поскольку никому не было нужды распихивать его по всем платформам.

ГВ>>Извини, не сочти за личный наезд, но это — иллюстрация неумения пользоваться C++ (ИМХО).
AVK>Вот вот. Все твои аргументы сводятся к тому что ты считаешь себя знатоком построения абстракций.

Скажем так, пока что — получается. И я считаю умение выделять и комбинировать абстракции одним из основных необходимых "умений" программиста. У программиста просто нет другого оружия для противостояния нарастанию сложности систем. Либо постоянное мутирование абстракций, либо — "комбинаторный взрыв". Вот и всё.

ГВ>>>>А слабо самому сделать то, что ты считаешь "нормальной компонентной моделью"?

AVK>>>А зачем? Она в дотнете уже есть.
ГВ>>Не царское это дело — ставить свою программу в зависимость от...

AVK>Мне не шашечки, мне ехать. Написание художественных программ я оставлю на потом.

Рационализм простой. Клиенты могут быть и на Windows (от 95 до XP), и на Unix, и на IPX/SPX, и на Token Ring.
Так что, что такое "шашечки", и что такое "ехать" — очень достойно отдельного обсуждения.

AVK>>>Опять же, так как в свое время я пытался это сделать то убежден что ничего существенно лучше COM на С++ не сделаешь.
ГВ>>Расскажи про использованные подходы. Интересно. Может, покритикую, может — поспорим.
AVK>Было давно, лет эдак 6 назад, да и не хочется мне это обсуждать.

Ну, не хочешь — не будем.

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

ГВ>Я имел ввиду, например то, что Java/.NET будет несовместима с Java/Sun и т.п.
Ну и что? Это взаимозаменяемые вещи. Т.е. если приложение написано под .NET то нет никакого смысла пытаться запустить его на JVM. Это не аппаратура или ОС которые со средствами разработки не пересекаются.

ГВ>OK, CLR/ECMA.
Знаешь в чем отличие стандарта от нестандарта? MS не имеет права запретить кому либо использовать стандарт.

ГВ>Только в том, что новый клиент обеспечит поддержку функциональности старого. Это — моя обязанность как разработчика, который решает проблемы клиента. Как же иначе-то?
Да, ты явно не занимался никогда администрированием достаточно большой системы. Когда на разных машинах существуют разные версии одного и того же софта это начинает напоминать ад.

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

Я тоже считаю, что в определённом смысле такие технологии необходимы, но в разумных пределах.
Ну слава богу. А разумные пределы нужны всегда и везде.

AVK>>Быстродействия нет, надежности да, причем в разы. Это практический опыт.
ГВ>Я вижу причину повышения надёжности в том, что исходно задана спецификация на функционирование компонента. Т.е., — введены ограничения.
Вот в дотнете эти ограничения и называются интерфейсом.

ГВ> Плюс — предоставлен ряд готовых отлаженных механизмов управления компонентами. Т.е., — причина — в конкретике, а не в парадигме.
Про парадигму никто и не спорит.

ГВ>Потенциально — да, поскольку C++ не тащит за собой рантайма. Но на данный момент, увы, это только потенциально.
А все потому что нельзя создать язык полностью отвязанным от окружения. Попыток создать такие языки было много, но результата никакого. Только джава научилась обеспечивать относительно приемлемую переносимость, да и то проблемы и там есть.

ГВ>Верю, верю.

Но пробовать без понимания (даже интуитивного) — не буду.
Аппетит приходит во время еды

Серьезно. Я в свое время, когда писал на паскале и С++ тоже джаву считал извращением. А потом пришлось работать на ней. Через пару месяцев работы мое мое мнение поменялось кардинально. И когда потом пришлось опять что то делать на С++ то он просто раздражал своей недоделанностью.

AVK>>Знаешь, я в отличие от тебя не смотрю как что подается а беру и пробую. А на то что и как подается мне плевать.
ГВ>А я вот смотрю и стараюсь выяснить, чем является что-то до того, как начну его использовать, тем более, использовать так, что пути назад потом не окажется. Затем уже я вывожу своё отношение к способу подачи этого самого чего-то. Почему, кстати, и остановился на C++, а не на Delphi в своё время. Кстати, благодарен тебе за оппонирование в этой и других дискуссиях. Заставил (косвенно) поразбираться с .NET и C#. Спасибо. Платформа меня заинтересовала в чём-то.
Я несколько раз накололся и теперь у меня есть твердое убеждение — чтобы оценить технологию надо попытаться ее применить для решения конкретных задач, пусть и учебных.

ГВ>С другой стороны — а уж не ради ли неквалифицированных программистов, в частности, в дотнетовский C# внесены упрощения и сандартизированы идиомы?
Нет, не ради. Даже самый квалифицированный программист иногда делает ошибки. И долг языка попытаться свести количество этих ошибок к минимуму.

ГВ> Естественно, что на дотнете писать проще всем, независимо от уровня квалификации (в тех терминах, в которых я её определял).
О том и речь. А главная цель языка программирования — служить средством выражения алгоритмов.

ГВ> Однако, в этом мире ничего не бывает однозначного. То есть, упростив модель, другим
Да не упрощал никто модель. Кое в чем классы дотнета значительно сложнее классов С++. Просто акценты сдвинуты. С++ пляшет как бы от железа, а шарп от задач.

AVK>>Нет, я доказываю что ему пора меняться.
ГВ>Извини, я тебя неверно интерпретировал. Однако, ИМХО, некорректно требовать изменения C++ (общего) на основании своего неудачного опыта (ИМХО, частного случая),
Если бы это был только мой опыт. А то я слышал одни и теже жалобы на С++ уже от многих людей.

AVK>>Ты просто привык ими пользоваться. Вполне неплохо живется и без них.
ГВ>Да, но теряется возможность оторвать алгоритмы от структур данных и сделсть это в объектном стиле и с минимальной потерей быстродействия (ИМХО!!!).
Да не теряется такая возможность, просто реализуется по другому. Ценой потери быстродействия конечно.

ГВ>На самом деле, ИМХО, здесь надо сравнивать метрики и функциональность аналогичных программ, написанных на C++ (не кастрированном! и с привлечением независимых библиотек) и Java/C#.
Каких например? Я вот например в свое время сравнивал C++, Дельфи и джаву на предмет написания серверов приложений. На последней это делалось не в пример проще и красивее. На шарпе я думаю получилось бы еще лучше.

AVK>>Не совсем. Прежде всего я их учу как правильно программировать, как обеспечить надежность кода, как обеспечить легкую ее модифицируемость и т.д. и т.п. А конкретике они учатся сами. Максимум что в этом плане я иногда делаю это сажусь и пишу какие то особо сложные куски вместе с ними.
ГВ>ИМХО, — здраво с практической точки зрения. Вопрос: а рассказываешь ли ты им о том, что желательно выделять подобные элементы из разных модулей программы в устойчивые идиомы?
Да, конечно.

ГВ>Хорошо. Изменю формулировку. Идеи существовали давно (Simula появилась в 67 году, про AOSD пока ничего сказать не могу).
Идеи чего, ООП? А при чем здесь математика? (Simula это кстати не совсем ООП, она сильно ориентирована на конкретные задачи моделирования, первым универсальным ООП языком был смоллтолк)

AVK>>Не отменять, но и не делать ее определяющей. Я по моему ясно выразился.
ГВ>"Ближе к жизни!" — если я правильно тебя понял. Тоже вариант, но жизнь (вернее, её восприятие) изменчива, а то, что обосновано логически (в частности — с испоьзованием математического аппарата) — в меньшей степени. Мне не нравится гонка за "жизнью", как за совокупностью господствующих стереотипов и я чаще вижу в этом просто моду, как выражение отношения к статистическим данным, собранным в одной группе людей и, возможно, неправомерно обобщённой на другую (первая обычно много меньше второй).
Тут все на самом деле просто — если математика обеспечивает выполнение поставленных задач то хорошо. А вот если не выполняет то не надо считать что делать нечего, надо забивать на математику и переходить к эмпирике.

ГВ>И погони за модой, ИМХО...
Не за модой а за решением новых задач. Я думаю применение слова мода здесь неуместно.

ГВ> Мне лично всегда казалось, что это глупость — развивать процедурные языки для баз данных (несмотря на то, что ими почти все пользуются).
Опять же — до серверов приложений тогда еще никто не додумался. В свое время появление хранимых процедур резко увеличило надежность и стабильность бизнес-приложений.

AVK>>Человек который способен решать поставленные задачи и при этом решать их качественно.
ГВ>Каковы задачи?
Которые поставлены.

ГВ> Каковы критерии качества?
Зависит от задачи. Точнее не сами критерии а их вес.

AVK>>Полный + managed расширения. Множественное наследование и шаблоны там есть, так что все в порядке

ГВ>А какие шаблоны там есть?
Те же что и в VC. ATL к примеру компилируется.

ГВ> Частичная специализация есть? Насколько я знаю — нет.
Выражайся по понятнее — кто такая частичная специализация?

ГВ>Я вижу причины так считать, поскольку модель .NET заставляет выворачивать реализацию абстракции в своих терминах. Термины, ИМХО, пока ещё достаточно специфичны.
Просто дотнет дальше отошел от конкретики железок.

AVK>>Ну у меня был достаточно длительный опыт общения с С++. Да и Владу и IT я в общем то доверяю.
ГВ>Аналогично.
Да, но у Влада и IT был опыт общения с дотнетом.

ГВ>Но глядя на аргументацию (Влада, в частности) я прихожу к выводу о том, что она часто спровоцирована покалеченной реализацией C++ компилятором VC++.
Я в свое время писал на BC++.

ГВ>А потому и "машу перьями" ("ерепенюсь" и т.п. — пусть эпитет подберут те, кто на это мастер) в адрес C#/Java, когда вижу, что по модели языки... ИМХО — не очень.
Я думаю что ничего ты пока не видишь и не увидишь пока не попробуешь что нибудь реализовать.

AVK>>Пример джавы показывает что это не так.
ГВ>Хм... Я встречал отзывы, что всё-таки надо учитывать особености GC той или иной JVM.
В основном в плане производительности. Да и потихоньку это правят.

ГВ>Так что, мне кажется, что твоё обобщение далековато от реальности.
В основном это связано со старыми JVM, теперь ситуация получше.

ГВ>Я, пожалуй, перегнул палку, но имелось ввиду, что а) мелкие несовместимости всё равно будут,
Мелкие несовместимости есть таже между разными поколениями процессоров. Вот только стараются чтобы они так и оставались мелкими и несущественными.

ГВ> б) скорее всего появятся реализации других рантаймов для других языков. ИМХО, свято место...
Я уже говорил — вряд ли кому понадобится запускать один и тот же код на разных рантаймах.

AVK>>Вот это и есть решение той же проблемы которую решают шаблоны. Да, в плане производительности не фонтан, но на удобство построения абстракций это не влияет.
ГВ>ИМХО, — слабоватая альтернатива шаблонам в целом.
Вся их функциональность реализуема. Просто не надо пытаться делать это так как это делали при помощи шаблонов.

AVK>>Вот. А в дотнете уже есть.
ГВ>В дотнете нету C++.
Исть!

ГВ>Вот почему. "Наличием C++" я называю такую реализацию, которая поддерживает трансляцию в исполняемый код (или же, интерпретацию) входного языка, соответствующего описанию ANSI C++. Судя по всему, у MSVC7 серьёзные проблемы с этим.
Судя по чему?

ГВ>А чуть подробнее можно? Я уже просил тебя привести хоть часть метрик твоей ERP. Кстати, ты ничего не ответил.
Я ответил, но глюканул инет и всесь постинг накрылся медным тазом. Перебивать было лень. Вкратце — для системы писанной на джаве это тысячи документов в день, справочник наименований около десятка тысяч (автозапчасти), 3 территориально разнесенных склада, около сотни рабочих мест. Остальное не замеряли.

AVK>>При чем тут P-код? Вон VB от рождения был пикодным. Однако от этого подобием джавы или дотнета он не становится.
ГВ>Не стандартизовали, поскольку никому не было нужды распихивать его по всем платформам.
Даже если бы его стандартизовали ничего бы от этого не изменилось.

ГВ>Скажем так, пока что — получается.
У меня, как ни странно, тоже.

ГВ> И я считаю умение выделять и комбинировать абстракции одним из основных необходимых "умений" программиста. У программиста просто нет другого оружия для противостояния нарастанию сложности систем. Либо постоянное мутирование абстракций, либо — "комбинаторный взрыв". Вот и всё.
Вот дотнет и является очередным оружием в этой войне.

... Янус версия 1.0 alpha 3

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

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Я имел ввиду, например то, что Java/.NET будет несовместима с Java/Sun и т.п.
AVK>Ну и что? Это взаимозаменяемые вещи. Т.е. если приложение написано под .NET то нет никакого смысла пытаться запустить его на JVM. Это не аппаратура или ОС которые со средствами разработки не пересекаются.

Почти уверен, что Java-программы будут пытаться таскать с JVM на .NET. Например.

ГВ>>OK, CLR/ECMA.
AVK>Знаешь в чем отличие стандарта от нестандарта? MS не имеет права запретить кому либо использовать стандарт.

Верю. Хотя ECMA — это далеко не ANSI/ISO. Так что, пока ещё верю в то, что "ECMA-стандарт" — только одна из карт в колоде Microsoft.

ГВ>>Только в том, что новый клиент обеспечит поддержку функциональности старого. Это — моя обязанность как разработчика, который решает проблемы клиента. Как же иначе-то?
AVK>Да, ты явно не занимался никогда администрированием достаточно большой системы. Когда на разных машинах существуют разные версии одного и того же софта это начинает напоминать ад.

Занимался

Только ты сам ввёл очень жёсткие ограничения. Вот и всё.

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

Я тоже считаю, что в определённом смысле такие технологии необходимы, но в разумных пределах.
AVK>Ну слава богу. А разумные пределы нужны всегда и везде.

Правильно, и трансмутировать каждый чих программы в компонент как элемент компонентной технологии — ИМХО-неразумно. Компонентный deployment — на здоровье.

AVK>>>Быстродействия нет, надежности да, причем в разы. Это практический опыт.
ГВ>>Я вижу причину повышения надёжности в том, что исходно задана спецификация на функционирование компонента. Т.е., — введены ограничения.
AVK>Вот в дотнете эти ограничения и называются интерфейсом.

ИМХО, они везде называются интерфейсом. И на самом деле, от их определённости многое зависит. Но их нужно определять в любой сложной разработке.

ГВ>>Потенциально — да, поскольку C++ не тащит за собой рантайма. Но на данный момент, увы, это только потенциально.
AVK>А все потому что нельзя создать язык полностью отвязанным от окружения. Попыток создать такие языки было много, но результата никакого. Только джава научилась обеспечивать относительно приемлемую переносимость, да и то проблемы и там есть.

Не только в рантайме дело. На C++ ещё относительно долго принимался стандарт. А рантайм у него очень маленький. Стандартные библиотеки не в счёт.

ГВ>>Верю, верю.

Но пробовать без понимания (даже интуитивного) — не буду.
AVK>Аппетит приходит во время еды

Серьезно. Я в свое время, когда писал на паскале и С++ тоже джаву считал извращением. А потом пришлось работать на ней. Через пару месяцев работы мое мое мнение поменялось кардинально. И когда потом пришлось опять что то делать на С++ то он просто раздражал своей недоделанностью.

Ну что же, я могу только посокрушаться по этому поводу. С другой стороны — если это был 96-98 гг, то ничего удивительного.

AVK>>>Знаешь, я в отличие от тебя не смотрю как что подается а беру и пробую. А на то что и как подается мне плевать.
ГВ>>А я вот смотрю и стараюсь выяснить, чем является что-то до того, как начну его использовать, тем более, использовать так, что пути назад потом не окажется. Затем уже я вывожу своё отношение к способу подачи этого самого чего-то. Почему, кстати, и остановился на C++, а не на Delphi в своё время. Кстати, благодарен тебе за оппонирование в этой и других дискуссиях. Заставил (косвенно) поразбираться с .NET и C#. Спасибо. Платформа меня заинтересовала в чём-то.
AVK>Я несколько раз накололся и теперь у меня есть твердое убеждение — чтобы оценить технологию надо попытаться ее применить для решения конкретных задач, пусть и учебных.

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

ГВ>>С другой стороны — а уж не ради ли неквалифицированных программистов, в частности, в дотнетовский C# внесены упрощения и сандартизированы идиомы?
AVK>Нет, не ради. Даже самый квалифицированный программист иногда делает ошибки. И долг языка попытаться свести количество этих ошибок к минимуму.

Истинно так.

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

ГВ>> Естественно, что на дотнете писать проще всем, независимо от уровня квалификации (в тех терминах, в которых я её определял).
AVK>О том и речь. А главная цель языка программирования — служить средством выражения алгоритмов.

Не согласен. Я думаю, что главная цель языка программирования пока ещё — помочь человеку выразить структуру (данных, поведения — уже неважно) и сделать это так, чтобы минимизировать другие сопутствующие расходы.

ГВ>> Однако, в этом мире ничего не бывает однозначного. То есть, упростив модель, другим
AVK>Да не упрощал никто модель. Кое в чем классы дотнета значительно сложнее классов С++. Просто акценты сдвинуты. С++ пляшет как бы от железа, а шарп от задач.

Я имел ввиду модель композиции абстракций. ИМХО, C++ как раз "пляшет" не от железа, а от фон-неймановской архитектуры. А то, что шарп пляшет от задач — "бяда, бяда — огорчение" (c). Думаешь, шарп — последний?

AVK>>>Нет, я доказываю что ему пора меняться.
ГВ>>Извини, я тебя неверно интерпретировал. Однако, ИМХО, некорректно требовать изменения C++ (общего) на основании своего неудачного опыта (ИМХО, частного случая),
AVK>Если бы это был только мой опыт. А то я слышал одни и теже жалобы на С++ уже от многих людей.

Я имел ввиду, что опыт и жалобы в данном случае — не лучшие советчики.

AVK>>>Ты просто привык ими пользоваться. Вполне неплохо живется и без них.
ГВ>>Да, но теряется возможность оторвать алгоритмы от структур данных и сделсть это в объектном стиле и с минимальной потерей быстродействия (ИМХО!!!).
AVK>Да не теряется такая возможность, просто реализуется по другому. Ценой потери быстродействия конечно.

В это-то и весь прикол. Не спорю, что шаблоны можно заменить соответствующими структурами, построенными на базе общего корневого класса и RTTI, однако весь вопрос в переходе от количества к качеству. Пример. На C++ разные хитрые вопросы решаются возвратом объекта, уничтожаемого по окончании вызова. При этом и конструктор и деструктор благополучно реализуются inline. Вычислительные накладные расходы — минимальны, можно даже свести почти к 0. В случае с рантайм-обработкой таких конструкций потери будут раз в несколько выше, т.к. объект будет а) распределяться в хипе, б) дополнительно анализироваться на предмет приведения типа, в) передаваться GC. Никуда от этого не денешься. Когда таких усложнений накопится много, производительность системы упадёт в разы (может быть — на порядок или больше). А это уже — качественный скачок. И далеко не всегда его можно допускать. Отсюда мораль — придётся менять реализацию.

ГВ>>На самом деле, ИМХО, здесь надо сравнивать метрики и функциональность аналогичных программ, написанных на C++ (не кастрированном! и с привлечением независимых библиотек) и Java/C#.
AVK>Каких например? Я вот например в свое время сравнивал C++, Дельфи и джаву на предмет написания серверов приложений. На последней это делалось не в пример проще и красивее. На шарпе я думаю получилось бы еще лучше.

Здесь надо конкретные условия оценить. Что за серверы приложений? Под какую функциональность, нагрузку? Я вот пару лет назад пришёл к выводу, что C++ для реализации СП в разы лучше Java.

AVK>>>Не совсем. Прежде всего я их учу как правильно программировать, как обеспечить надежность кода, как обеспечить легкую ее модифицируемость и т.д. и т.п. А конкретике они учатся сами. Максимум что в этом плане я иногда делаю это сажусь и пишу какие то особо сложные куски вместе с ними.
ГВ>>ИМХО, — здраво с практической точки зрения. Вопрос: а рассказываешь ли ты им о том, что желательно выделять подобные элементы из разных модулей программы в устойчивые идиомы?
AVK>Да, конечно.

ГВ>>Хорошо. Изменю формулировку. Идеи существовали давно (Simula появилась в 67 году, про AOSD пока ничего сказать не могу).
AVK>Идеи чего, ООП? А при чем здесь математика? (Simula это кстати не совсем ООП, она сильно ориентирована на конкретные задачи моделирования, первым универсальным ООП языком был смоллтолк)

Верно. Только ООП родилось как практическое применение фреймов/слотов. А это уже — подраздел исследований ИИ, один из способов структурирования знаний.

AVK>>>Не отменять, но и не делать ее определяющей. Я по моему ясно выразился.
ГВ>>"Ближе к жизни!" — если я правильно тебя понял. Тоже вариант, но жизнь (вернее, её восприятие) изменчива, а то, что обосновано логически (в частности — с испоьзованием математического аппарата) — в меньшей степени. Мне не нравится гонка за "жизнью", как за совокупностью господствующих стереотипов и я чаще вижу в этом просто моду, как выражение отношения к статистическим данным, собранным в одной группе людей и, возможно, неправомерно обобщённой на другую (первая обычно много меньше второй).
AVK>Тут все на самом деле просто — если математика обеспечивает выполнение поставленных задач то хорошо. А вот если не выполняет то не надо считать что делать нечего, надо забивать на математику и переходить к эмпирике.

Никто и не поспорит с таким постулатом. Но и эмпирику, ИМХО, надо уметь быстро-быстро систематизировать. Иначе — большой комбинаторный ба-бах (неизбежно).

ГВ>>И погони за модой, ИМХО...
AVK>Не за модой а за решением новых задач. Я думаю применение слова мода здесь неуместно.

Не согласен, мода, ИМХО — суть то, о чём все жужжат на каждом углу. Ну а производители что? "Вы хотели — вот вам!" Из тысячи жужжащих может быть один толком понимает о чём жужжит.

ГВ>> Мне лично всегда казалось, что это глупость — развивать процедурные языки для баз данных (несмотря на то, что ими почти все пользуются).
AVK>Опять же — до серверов приложений тогда еще никто не додумался. В свое время появление хранимых процедур резко увеличило надежность и стабильность бизнес-приложений.

Не согласен. Была мода на "ОО-всё-что-угодно", сразу же замелькали термины "объектно-реляционная БД" и т.д., и т.п. На самом деле — задача совмещения императивной и декларативной модели до сих пор толком не решена. Уродств реализаций программ в терминах процедур SQL я насмотрелся по уши. ИМХО, это — абсолютный тупик, поскольку всё упирается в совмещение транзакций, пошагового исполнения и слабых выразительных возможностей тех же SQL-процедурных языков. Для триггеров они ещё подходят, для чего-то намного более сложного — нет.

В данном случае результат "надежность и стабильность бизнес-приложений" стоит рассматривать только в контексте условий его возникновения: кто, когда и в каких условиях писал и т.п.

AVK>>>Человек который способен решать поставленные задачи и при этом решать их качественно.
ГВ>>Каковы задачи?
AVK>Которые поставлены.

Охарактеризуй задачи, если не затруднит.

ГВ>> Каковы критерии качества?
AVK>Зависит от задачи. Точнее не сами критерии а их вес.

Так... Скажи, а внутренняя структура программы подвергается оценке? То есть, содержатся ли в критериях качества какие-либо оценки внутренней структуры программы, например: ширина/высота дерева наследования, количество связей классов, объём использованных абстракций, связность классов или нет?

AVK>>>Полный + managed расширения. Множественное наследование и шаблоны там есть, так что все в порядке

ГВ>>А какие шаблоны там есть?
AVK>Те же что и в VC. ATL к примеру компилируется.

ГВ>> Частичная специализация есть? Насколько я знаю — нет.
AVK>Выражайся по понятнее — кто такая частичная специализация?

Что мы там о вкусе устриц говорили?

Шутка.

Частичная специализация позволяет изменить реализацию шаблона для определённых заданных случаев его аргументов. Ну, например:

// Вот это - общий шаблон (1)
template<class T, class U> class A { ... };

// А это - частичная специализация для тех случаев,
// когда вторым аргументом шаблона A<x,y> является тип int. (2)
template<class T> class A<T, int> { ... };

// Использование (ну очень кратко):
A<double, double> a; // Инстанцирование генерится из (1)
A<double, [b]int[b]> b; // Инстанцирование генерится из (2)

Подробнее см. ANSI/ISO-14882:1998, 14.5.4.

Если компилятор не поддерживает частичной специализации, то приходится безумно извращаться и корёжить всё структуру абстракций. Или бросать эту затею нахрен и выворачиваться с помощью виртуальных функций и т.п.
MSVC поддерживает только "полную" специализацию, т.е., позволяет сделать особую реализацию шаблона только полностью специфицировав его аргументы. Приведённый пример пришлось бы делать примерно так:

// Вот это - общий шаблон (1)
template<class T, class U> class A { ... };

// А вот теперь мы не можем задать частичную специализаию, поэтому извращаемся,
// перечисляя специализации со торым аргументом типа int.
template<> class A<int, int> { ... };
template<> class A<double, int> { ... }; // (2)
template<> class A<char*, int> { ... };

// Использование (ну очень кратко):
A<double, double> a; // Инстанцирование генерится из (1)
A<double, [b]int[b]> b; // Инстанцирование генерится из (2)

Ну, и так далее. Отсутствие частичной специализации очень мешает, например, при разработке системных библиотек.

ГВ>>Я вижу причины так считать, поскольку модель .NET заставляет выворачивать реализацию абстракции в своих терминах. Термины, ИМХО, пока ещё достаточно специфичны.
AVK>Просто дотнет дальше отошел от конкретики железок.

C++ не так уж и близок к конкретике железок. Единственная привязка (да и то — implementation-dependent) — размерность "фундаментальных" типов. Ну а указатели... Фон-неймановская модель, извините, куда же здесь без адресов?

AVK>>>Ну у меня был достаточно длительный опыт общения с С++. Да и Владу и IT я в общем то доверяю.
ГВ>>Аналогично.
AVK>Да, но у Влада и IT был опыт общения с дотнетом.

Но судя по всему, не было опыта общения с нормальным C++. Отсюда, ИМХО, и часть скепсиса в оценках.

ГВ>>Но глядя на аргументацию (Влада, в частности) я прихожу к выводу о том, что она часто спровоцирована покалеченной реализацией C++ компилятором VC++.
AVK>Я в свое время писал на BC++.

Он тоже не намного лучше по части шаблонов. А если ты писал на BC++ ранних версий, так это вообще ужас был.

ГВ>>А потому и "машу перьями" ("ерепенюсь" и т.п. — пусть эпитет подберут те, кто на это мастер) в адрес C#/Java, когда вижу, что по модели языки... ИМХО — не очень.
AVK>Я думаю что ничего ты пока не видишь и не увидишь пока не попробуешь что нибудь реализовать.

Уже кое-что прояснилось.

У меня с индукцией всё в порядке.

AVK>>>Пример джавы показывает что это не так.
ГВ>>Хм... Я встречал отзывы, что всё-таки надо учитывать особености GC той или иной JVM.
AVK>В основном в плане производительности. Да и потихоньку это правят.

Ну, ещё J# заиграет всеми красками...

ГВ>> б) скорее всего появятся реализации других рантаймов для других языков. ИМХО, свято место...
AVK>Я уже говорил — вряд ли кому понадобится запускать один и тот же код на разных рантаймах.

Не верю, поскольку зачем тогда MS выставлять CLR как common language... Так что, — понадобится, я уверен. .NET — считай, ещё один процессор, так что для крупных разработчиков Windows-приложений возни частично прибавится — будут версии Windows NT/.NET/9x/CE/CE.NET и т.п. Почти аналогично — и для юниксоидов. Почти наверняка появится "улучшенный" Perl, "улучшенный" Eiffel и т.п. Вобщем — будет каша как всегда.

AVK>>>Вот это и есть решение той же проблемы которую решают шаблоны. Да, в плане производительности не фонтан, но на удобство построения абстракций это не влияет.
ГВ>>ИМХО, — слабоватая альтернатива шаблонам в целом.
AVK>Вся их функциональность реализуема. Просто не надо пытаться делать это так как это делали при помощи шаблонов.

Не смешно. Если заменять шаблоны даже виртуальными функциями, проигрыш в быстродействии — порядок или около того. Это же кумулятивный эффект — попробуй сравнить быстродействие с plain-int и с boxed-int (я не знаю конкретных цифр). А процессорные мощности всегда будут небесконечными.

AVK>>>Вот. А в дотнете уже есть.
ГВ>>В дотнете нету C++.
AVK>Исть!

Если предположить, что C++ — это множественное наследование и простейшие шаблоны (контейнеры + ATL), то твоё утверждение истинно, если же учесть, что исходная посылка состоит в том, что C++ — это ещё и поддержка частичной специализации и ещё кучи комбинационных возможностей шаблонов — то твоё утверждение ложно.

ГВ>>Вот почему. "Наличием C++" я называю такую реализацию, которая поддерживает трансляцию в исполняемый код (или же, интерпретацию) входного языка, соответствующего описанию ANSI C++. Судя по всему, у MSVC7 серьёзные проблемы с этим.
AVK>Судя по чему?

Судя по отзывам в форуме C/C++ и по результатам попыток трансляции делегатов Владом.

ГВ>>А чуть подробнее можно? Я уже просил тебя привести хоть часть метрик твоей ERP. Кстати, ты ничего не ответил.
AVK>Я ответил, но глюканул инет и всесь постинг накрылся медным тазом. Перебивать было лень. Вкратце — для системы писанной на джаве это тысячи документов в день, справочник наименований около десятка тысяч (автозапчасти), 3 территориально разнесенных склада, около сотни рабочих мест. Остальное не замеряли.

Интересует что-нибудь из этого: количество экранов, модулей, таблиц, общий объём исходников.

AVK>>>При чем тут P-код? Вон VB от рождения был пикодным. Однако от этого подобием джавы или дотнета он не становится.
ГВ>>Не стандартизовали, поскольку никому не было нужды распихивать его по всем платформам.
AVK>Даже если бы его стандартизовали ничего бы от этого не изменилось.

Согласен, поскольку он нафиг не нужен. Я просто иллюстрировал идею о промежуточной трансляции в P-код.

ГВ>>Скажем так, пока что — получается.
AVK>У меня, как ни странно, тоже.

OK.

ГВ>> И я считаю умение выделять и комбинировать абстракции одним из основных необходимых "умений" программиста. У программиста просто нет другого оружия для противостояния нарастанию сложности систем. Либо постоянное мутирование абстракций, либо — "комбинаторный взрыв". Вот и всё.
AVK>Вот дотнет и является очередным оружием в этой войне.

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

[skip]

............. 2080-й год, отрывки из 39998792394234 сообщения в данном сабже, тема плавно перешла в формулировку "Чем же так привлекателен С#", в споре учавствуют внук Геннадия Васильева, приверженец чистого творческого программинга по старинке на С Шарп, и правнучатый племянник Андрея Владимировича, представителя нового поколения системных архитекторов, предпочитающих программировать клацая на менюшки и кнопочки, заполняя всевозможные визарды, и расскрашивая панельки построенных в визардах окошек в модные современные цвета.

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

Внучатый Племянник Андрея Владимировича> Твои старые технологии и никому непонятные ( да и не нужные )абсракции не в состоянии в течении полутора часов развернуть хорошо масштабируемое приложение для бизнес среды большого предприятия с несколькими сотнями тысяч рабочих мест, со сложными бизнес связями и развитыми инфраструктурами, принятыми в современном воркфлоу. И всю эту сложнейшую систему я в состоянии построить в течении нескольких часов, благодаря новейшей технологии генерации систем подобного рода на лету, разработки ведущего лидера в этой области "МегаСуперСофт". И все что мне при этом нужно — это заполнить несколько сотен визардов и форм, нажать кнопку Финиш и откинуться на спинку стула, наблюдая за рождением моего детища!!!

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

ГВ>Почти уверен, что Java-программы будут пытаться таскать с JVM на .NET. Например.
Ты мне не расскажешь зачем?

ГВ>Ну что же, я могу только посокрушаться по этому поводу. С другой стороны — если это был 96-98 гг, то ничего удивительного.
А что — С++ с 96 года сильно изменился?

AVK>>Нет, не ради. Даже самый квалифицированный программист иногда делает ошибки. И долг языка попытаться свести количество этих ошибок к минимуму.

ГВ>Истинно так.

Что частично решается средствами C++, а вернее — шаблонами. Такое же частичное решение — атрибуты классов и рантайм-контроль. Применение последнего всегда приводит к увеличению вычислительной нагрузки. Притом — весьма нехилому.
Ну не так все на самом деле страшно. Приводит, да. Но не забывай что рантайм оптимизирован именно для таких операций. Так что в итоге все получается вполне приемлемо.

AVK>>О том и речь. А главная цель языка программирования — служить средством выражения алгоритмов.

ГВ>Не согласен. Я думаю, что главная цель языка программирования пока ещё — помочь человеку выразить структуру (данных, поведения — уже неважно) и сделать это так, чтобы минимизировать другие сопутствующие расходы.
Ну так это и есть средство выражения.

AVK>>Если бы это был только мой опыт. А то я слышал одни и теже жалобы на С++ уже от многих людей.
ГВ>Я имел ввиду, что опыт и жалобы в данном случае — не лучшие советчики.
Лучшего советчика чем опыт я не знаю. И уж точно не буду полагатся на маркетинговую трепотню. На сайте МС написано одно, в статьях другое, а когда лезешь в фреймворк оказывается что третье.

AVK>>Да не теряется такая возможность, просто реализуется по другому. Ценой потери быстродействия конечно.

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

ГВ> Пример. На C++ разные хитрые вопросы решаются возвратом объекта, уничтожаемого по окончании вызова. При этом и конструктор и деструктор благополучно реализуются inline. Вычислительные накладные расходы — минимальны, можно даже свести почти к 0. В случае с рантайм-обработкой таких конструкций потери будут раз в несколько выше, т.к. объект будет а) распределяться в хипе, б) дополнительно анализироваться на предмет приведения типа, в) передаваться GC.
У как все сложно. На самом деле всего этого можно избежать. 1) В шарпе есть еще структуры — они могут и в стеке быть. 2)в GC ничего передавать не нужно — он сам все находит.

ГВ> Никуда от этого не денешься.
Вот опять ты не в курсе про наличие value-типов в дотнете и принципы работы GC и поэтому делаешь неверные выводы.

ГВ> Когда таких усложнений накопится много, производительность системы упадёт в разы (может быть — на порядок или больше). А это уже — качественный скачок. И далеко не всегда его можно допускать. Отсюда мораль — придётся менять реализацию.
Все это так, но можно привести и обратные примеры.

AVK>>Каких например? Я вот например в свое время сравнивал C++, Дельфи и джаву на предмет написания серверов приложений. На последней это делалось не в пример проще и красивее. На шарпе я думаю получилось бы еще лучше.
ГВ>Здесь надо конкретные условия оценить. Что за серверы приложений?
Ну все тоже самое — ERP, Web

ГВ>Под какую функциональность, нагрузку?
Под приличную

ГВ> Я вот пару лет назад пришёл к выводу, что C++ для реализации СП в разы лучше Java.
Не вижу чем. Что это за сервер приложений который надо перекомпилировать при изменении бизнес-логики? Нормальный сервер приложений должен на лету подхватывать изменения в бизнес-правилах и не прекращать работу клиентов если это возможно. Почитай в форуме по дотнету, топик "Разработка учетных систем с использованием .NET" — человек задал несколько вопросов как раз в этом плане и привел набор требований к такому серверу. Вот и прикинь какой кровью отольется их реализация на С++.
Что же касается С++ для веб-приложений — тут то ты надеюсь спорить не будешь?

ГВ>>>Хорошо. Изменю формулировку. Идеи существовали давно (Simula появилась в 67 году, про AOSD пока ничего сказать не могу).
AVK>>Идеи чего, ООП? А при чем здесь математика? (Simula это кстати не совсем ООП, она сильно ориентирована на конкретные задачи моделирования, первым универсальным ООП языком был смоллтолк)
ГВ>Верно. Только ООП родилось как практическое применение фреймов/слотов. А это уже — подраздел исследований ИИ, один из способов структурирования знаний.
Ну математика то здесь при чем? Если конечно не назвать computer science математикой.

ГВ>Никто и не поспорит с таким постулатом. Но и эмпирику, ИМХО, надо уметь быстро-быстро систематизировать. Иначе — большой комбинаторный ба-бах (неизбежно).
Систематизацию никто не отрицает. Только не надо называть все информационные науки математикой.

AVK>>Не за модой а за решением новых задач. Я думаю применение слова мода здесь неуместно.
ГВ>Не согласен, мода, ИМХО — суть то, о чём все жужжат на каждом углу. Ну а производители что? "Вы хотели — вот вам!" Из тысячи жужжащих может быть один толком понимает о чём жужжит.
Вон все жужжат про веб сервисы. А на самом деле вещь достаточно узкоспециальная и отнюдь не вундерваффе программных технологий. Мне хватило пару дней чтобы разобраться. Зато в дотнете есть ремоутинг который в разы гибче и удобнее веб-сервисов, и тоже при должном желании вполне многоплатформенный, а о нем почему то не жужжат. Так что меньше надо слушать что жужжат и тем более не стоит по этому жужжанию оценивать программные технологии. Лучше взять документацию и почитать.

AVK>>Опять же — до серверов приложений тогда еще никто не додумался. В свое время появление хранимых процедур резко увеличило надежность и стабильность бизнес-приложений.
ГВ>Не согласен. Была мода на "ОО-всё-что-угодно", сразу же замелькали термины "объектно-реляционная БД" и т.д., и т.п. На самом деле — задача совмещения императивной и декларативной модели до сих пор толком не решена.
Увы да. Хотя идея очень красивая. Правда говорят что каше все же довели до ума. Вон компакт прислали, все никак руки не дойдут посмотреть.

ГВ> Уродств реализаций программ в терминах процедур SQL я насмотрелся по уши.
До SQL было еще хуже.

ГВ>ИМХО, это — абсолютный тупик, поскольку всё упирается в совмещение транзакций, пошагового исполнения и слабых выразительных возможностей тех же SQL-процедурных языков. Для триггеров они ещё подходят, для чего-то намного более сложного — нет.
Я тебе еще раз повторюсь — в современных продуктах ХП используются очень интенсивно до сих пор. И только массовое использование серверов приложений способно их оттуда вытолкнуть. Но сервера приложений штука довольно таки сложная, серверный софт все же сильно отличается по требованиям от настольного. Вот поэтому и появились Java2 и .NET чтобы получить языки и платформы которые были бы удобны для создания этого самого серверного софта.

AVK>>Которые поставлены.
ГВ>Охарактеризуй задачи, если не затруднит.
Ты чего — издеваешся? Ты нить разговора не утерял? Как я их могу охарактеризовать?

ГВ>>> Каковы критерии качества?
AVK>>Зависит от задачи. Точнее не сами критерии а их вес.
ГВ>Так... Скажи, а внутренняя структура программы подвергается оценке? То есть, содержатся ли в критериях качества какие-либо оценки внутренней структуры программы, например: ширина/высота дерева наследования, количество связей классов, объём использованных абстракций, связность классов или нет?
Не так подробно — есть критерий простота модификации, в том числе и глубокой.

AVK>>Просто дотнет дальше отошел от конкретики железок.

ГВ>C++ не так уж и близок к конкретике железок. Единственная привязка (да и то — implementation-dependent) — размерность "фундаментальных" типов. Ну а указатели... Фон-неймановская модель, извините, куда же здесь без адресов?
Ориентирован он, еще как ориентирован. Он зависит от порядка следования байтов в машинном слове к примеру.
Т.е. если на разных машинах порядок следования разный то надо это специально учитывать. Зависит от длинны машинного слова — int то он каждый раз иной.

AVK>>Да, но у Влада и IT был опыт общения с дотнетом.
ГВ>Но судя по всему, не было опыта общения с нормальным C++. Отсюда, ИМХО, и часть скепсиса в оценках.
Судя по твоим словам нормальные С++ компиляторы только появились, и то, точно ты не знаешь потому что не смотрел. Так что видимо и у тебя такого опыта не было.

ГВ>Он тоже не намного лучше по части шаблонов. А если ты писал на BC++ ранних версий, так это вообще ужас был.
По первости на 3.1, потом на 4.5 и немножко на 5.0.

AVK>>В основном в плане производительности. Да и потихоньку это правят.
ГВ>Ну, ещё J# заиграет всеми красками...
J# не есть язык для основной разработки. Это просто средство для переноса джава-программ.

ГВ>>> б) скорее всего появятся реализации других рантаймов для других языков. ИМХО, свято место...
AVK>>Я уже говорил — вряд ли кому понадобится запускать один и тот же код на разных рантаймах.
ГВ>Не верю, поскольку зачем тогда MS выставлять CLR как common language... Так что, — понадобится, я уверен. .NET — считай, ещё один процессор, так что для крупных разработчиков Windows-приложений возни частично прибавится — будут версии Windows NT/.NET/9x/CE/CE.NET и т.п. Почти аналогично — и для юниксоидов. Почти наверняка появится "улучшенный" Perl, "улучшенный" Eiffel и т.п. Вобщем — будет каша как всегда.
дотнет должен быть бинарно совместим. Так что каши не будет.

AVK>>Я ответил, но глюканул инет и всесь постинг накрылся медным тазом. Перебивать было лень. Вкратце — для системы писанной на джаве это тысячи документов в день, справочник наименований около десятка тысяч (автозапчасти), 3 территориально разнесенных склада, около сотни рабочих мест. Остальное не замеряли.
ГВ>Интересует что-нибудь из этого: количество экранов,
Не считали
ГВ> модулей,
Какие модули в джаве? Ты о чем?
ГВ> таблиц,
где то сотни две с половиной — три.
ГВ> общий объём исходников.
Тоже как то не интересновался. Несколько мегабайт.

AVK>>Даже если бы его стандартизовали ничего бы от этого не изменилось.
ГВ>Согласен, поскольку он нафиг не нужен. Я просто иллюстрировал идею о промежуточной трансляции в P-код.
P-код при наличии джита нужен только для бинарного и переносимого представления. Исполняется все равно нативный код.

... Янус версия 1.0 alpha 3

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

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Почти уверен, что Java-программы будут пытаться таскать с JVM на .NET. Например.
AVK>Ты мне не расскажешь зачем?

Один из примеров приведён тобой (см. ниже).

ГВ>>Ну что же, я могу только посокрушаться по этому поводу. С другой стороны — если это был 96-98 гг, то ничего удивительного.
AVK>А что — С++ с 96 года сильно изменился?

Не столько C++, сколько инструменты, его поддерживающие. Кроме того, стандарт был принят-таки в 98 г.

ГВ>>... Что частично решается средствами C++, а вернее — шаблонами. Такое же частичное решение — атрибуты классов и рантайм-контроль. Применение последнего всегда приводит к увеличению вычислительной нагрузки. Притом — весьма нехилому.
AVK>Ну не так все на самом деле страшно. Приводит, да. Но не забывай что рантайм оптимизирован именно для таких операций. Так что в итоге все получается вполне приемлемо.

OK, предположим.

AVK>>>Если бы это был только мой опыт. А то я слышал одни и теже жалобы на С++ уже от многих людей.
ГВ>>Я имел ввиду, что опыт и жалобы в данном случае — не лучшие советчики.
AVK>Лучшего советчика чем опыт я не знаю. И уж точно не буду полагатся на маркетинговую трепотню. На сайте МС написано одно, в статьях другое, а когда лезешь в фреймворк оказывается что третье.

Точно. Только ты уже повёлся на маркетинг. Прежде всего тем, что поверил, что ещё немного и .NET будет повсюду и в подавляющем большинстве. MS будет подкармливать .NET-овцев, а IBM, Sun и иже с ними будут подкармливать OSF.

AVK>>>Да не теряется такая возможность, просто реализуется по другому. Ценой потери быстродействия конечно.

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

Да. И именно об этом мы и дискутируем.

И часть этого вопроса — глубина структуры представления вещей и её зависимость от разных факторов, среди которых — итоговое быстродействие и суммарная компактность — не самые последние.

ГВ>> Пример. На C++ разные хитрые вопросы решаются возвратом объекта, уничтожаемого по окончании вызова. При этом и конструктор и деструктор благополучно реализуются inline. Вычислительные накладные расходы — минимальны, можно даже свести почти к 0. В случае с рантайм-обработкой таких конструкций потери будут раз в несколько выше, т.к. объект будет а) распределяться в хипе, б) дополнительно анализироваться на предмет приведения типа, в) передаваться GC.
AVK>У как все сложно. На самом деле всего этого можно избежать. 1) В шарпе есть еще структуры — они могут и в стеке быть. 2)в GC ничего передавать не нужно — он сам все находит.

1. Структуры — это всё-таки не совсем классы. 2. Ну какая разница: сам GC находит или ему передают?

ГВ>> Никуда от этого не денешься.
AVK>Вот опять ты не в курсе про наличие value-типов в дотнете и принципы работы GC и поэтому делаешь неверные выводы.

Про value-типы и структуры я знаю, но мой пример как раз таки предполагал передачу объекта (экземпляра класса).

ГВ>> Когда таких усложнений накопится много, производительность системы упадёт в разы (может быть — на порядок или больше). А это уже — качественный скачок. И далеко не всегда его можно допускать. Отсюда мораль — придётся менять реализацию.
AVK>Все это так, но можно привести и обратные примеры.

Примеры в студию!

ГВ>> Я вот пару лет назад пришёл к выводу, что C++ для реализации СП в разы лучше Java.
AVK>Не вижу чем. Что это за сервер приложений который надо перекомпилировать при изменении бизнес-логики? Нормальный сервер приложений должен на лету подхватывать изменения в бизнес-правилах и не прекращать работу клиентов если это возможно. Почитай в форуме по дотнету, топик "Разработка учетных систем с использованием .NET" — человек задал несколько вопросов как раз в этом плане и привел набор требований к такому серверу. Вот и прикинь какой кровью отольется их реализация на С++.

Не надо домысливать. Никто не собирался перекомпилировать сервер на C++ при изменении прикладной логики.

AVK> Что же касается С++ для веб-приложений — тут то ты надеюсь спорить не будешь?

Поспорил бы, особенно с учётом того, что для меня термин "Web-приложение" звучит подобно "VGA-приложению" или "GUI-приложению", но не вижу в этом смысла.

ГВ>>>>Хорошо. Изменю формулировку. Идеи существовали давно (Simula появилась в 67 году, про AOSD пока ничего сказать не могу).
AVK>>>Идеи чего, ООП? А при чем здесь математика? (Simula это кстати не совсем ООП, она сильно ориентирована на конкретные задачи моделирования, первым универсальным ООП языком был смоллтолк)
ГВ>>Верно. Только ООП родилось как практическое применение фреймов/слотов. А это уже — подраздел исследований ИИ, один из способов структурирования знаний.
AVK>Ну математика то здесь при чем? Если конечно не назвать computer science математикой.

Математика — инструмент, а как называется наука, её использующая, в данный момент не важно.

ГВ>>Никто и не поспорит с таким постулатом. Но и эмпирику, ИМХО, надо уметь быстро-быстро систематизировать. Иначе — большой комбинаторный ба-бах (неизбежно).
AVK>Систематизацию никто не отрицает. Только не надо называть все информационные науки математикой.

OK, не буду обобщать в смысле названия (это была в определённом смысле метафора), хотя инструменты из теории множеств и булевой алгебры используются нередко.

AVK>>>Не за модой а за решением новых задач. Я думаю применение слова мода здесь неуместно.
ГВ>>Не согласен, мода, ИМХО — суть то, о чём все жужжат на каждом углу. Ну а производители что? "Вы хотели — вот вам!" Из тысячи жужжащих может быть один толком понимает о чём жужжит.
AVK>Вон все жужжат про веб сервисы. А на самом деле вещь достаточно узкоспециальная и отнюдь не вундерваффе программных технологий. Мне хватило пару дней чтобы разобраться. Зато в дотнете есть ремоутинг который в разы гибче и удобнее веб-сервисов, и тоже при должном желании вполне многоплатформенный, а о нем почему то не жужжат. Так что меньше надо слушать что жужжат и тем более не стоит по этому жужжанию оценивать программные технологии. Лучше взять документацию и почитать.

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

AVK>>>Опять же — до серверов приложений тогда еще никто не додумался. В свое время появление хранимых процедур резко увеличило надежность и стабильность бизнес-приложений.
ГВ>>Не согласен. Была мода на "ОО-всё-что-угодно", сразу же замелькали термины "объектно-реляционная БД" и т.д., и т.п. На самом деле — задача совмещения императивной и декларативной модели до сих пор толком не решена.
AVK>Увы да. Хотя идея очень красивая. Правда говорят что каше все же довели до ума. Вон компакт прислали, все никак руки не дойдут посмотреть.

OK, Cache потом.

ГВ>>ИМХО, это — абсолютный тупик, поскольку всё упирается в совмещение транзакций, пошагового исполнения и слабых выразительных возможностей тех же SQL-процедурных языков. Для триггеров они ещё подходят, для чего-то намного более сложного — нет.
AVK>Я тебе еще раз повторюсь — в современных продуктах ХП используются очень интенсивно до сих пор. И только массовое использование серверов приложений способно их оттуда вытолкнуть. Но сервера приложений штука довольно таки сложная, серверный софт все же сильно отличается по требованиям от настольного. Вот поэтому и появились Java2 и .NET чтобы получить языки и платформы которые были бы удобны для создания этого самого серверного софта.

Я отлично знаю, что в современных приложениях ХП используются до сих пор и очень активно. Но моя оценка подобных реализаций от этого не меняется. Это всего лишь означает широко распространённое уродство, считающееся нормой.

AVK>>>Которые поставлены.
ГВ>>Охарактеризуй задачи, если не затруднит.
AVK>Ты чего — издеваешся? Ты нить разговора не утерял? Как я их могу охарактеризовать?

Нить разговора я не утерял

Просто ответ весьма интересный: "- Что делаете?", "- Что скажут!". Я имел ввиду характеристику задач в смысле — системные, прикладные, "GUI" и т.п. Ну да ладно, проехали. На самом деле, мне было интересно, какую классификацию ты сам выберешь.

ГВ>>>> Каковы критерии качества?
AVK>>>Зависит от задачи. Точнее не сами критерии а их вес.
ГВ>>Так... Скажи, а внутренняя структура программы подвергается оценке? То есть, содержатся ли в критериях качества какие-либо оценки внутренней структуры программы, например: ширина/высота дерева наследования, количество связей классов, объём использованных абстракций, связность классов или нет?
AVK>Не так подробно — есть критерий простота модификации, в том числе и глубокой.

OK. А как выносится предположение о характере предполагаемой модификации? Модификаии могут быть разными. Здесь обобщения, ИМХО, неуместны.

AVK>>>Просто дотнет дальше отошел от конкретики железок.

ГВ>>C++ не так уж и близок к конкретике железок. Единственная привязка (да и то — implementation-dependent) — размерность "фундаментальных" типов. Ну а указатели... Фон-неймановская модель, извините, куда же здесь без адресов?
AVK>Ориентирован он, еще как ориентирован. Он зависит от порядка следования байтов в машинном слове к примеру.
AVK>Т.е. если на разных машинах порядок следования разный то надо это специально учитывать. Зависит от длинны машинного слова — int то он каждый раз иной.

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

AVK>>>Да, но у Влада и IT был опыт общения с дотнетом.
ГВ>>Но судя по всему, не было опыта общения с нормальным C++. Отсюда, ИМХО, и часть скепсиса в оценках.
AVK>Судя по твоим словам нормальные С++ компиляторы только появились, и то, точно ты не знаешь потому что не смотрел. Так что видимо и у тебя такого опыта не было.

К сожалению. И мне действительно очень много неудобств доставило отсутствие нормальной поддержки шаблонов в MSVC. Сравнение же компиляторов, на которое я нередко опираюсь лежит на: http://www.cuj.com/roundup/a.htm?topic=reference

ГВ>>Он тоже не намного лучше по части шаблонов. А если ты писал на BC++ ранних версий, так это вообще ужас был.
AVK>По первости на 3.1, потом на 4.5 и немножко на 5.0.

Мда. Именно их я и имел ввиду...

AVK>>>В основном в плане производительности. Да и потихоньку это правят.
ГВ>>Ну, ещё J# заиграет всеми красками...
AVK>J# не есть язык для основной разработки. Это просто средство для переноса джава-программ.

См. начало постинга.

Ты спрашивал — зачем понадобится таскать программы с платформы на платформу.

ГВ>>>> б) скорее всего появятся реализации других рантаймов для других языков. ИМХО, свято место...
AVK>>>Я уже говорил — вряд ли кому понадобится запускать один и тот же код на разных рантаймах.
ГВ>>Не верю, поскольку зачем тогда MS выставлять CLR как common language... Так что, — понадобится, я уверен. .NET — считай, ещё один процессор, так что для крупных разработчиков Windows-приложений возни частично прибавится — будут версии Windows NT/.NET/9x/CE/CE.NET и т.п. Почти аналогично — и для юниксоидов. Почти наверняка появится "улучшенный" Perl, "улучшенный" Eiffel и т.п. Вобщем — будет каша как всегда.
AVK>дотнет должен быть бинарно совместим. Так что каши не будет.

С чем он должен быть бинарно совместим? ИМХО — только с самим собой. (Я не забыл, что он потенциально может ездить по любым аппаратным платформам). Вся прочая совместимость — только через исходники или "интероп". Иного пути нет.

AVK>>>Я ответил, но глюканул инет и всесь постинг накрылся медным тазом. Перебивать было лень. Вкратце — для системы писанной на джаве это тысячи документов в день, справочник наименований около десятка тысяч (автозапчасти), 3 территориально разнесенных склада, около сотни рабочих мест. Остальное не замеряли.
ГВ>>Интересует что-нибудь из этого: количество экранов,
AVK>Не считали

Попробуйте посчитать. Особенно в соотношении с другими показателями могут получиться интересные цифры.

ГВ>> модулей,
AVK>Какие модули в джаве? Ты о чем?

А... Java. Тогда — количесто классов. Одним словом — количество deployment items.

ГВ>> таблиц,
AVK>где то сотни две с половиной — три.
ГВ>> общий объём исходников.
AVK>Тоже как то не интересновался. Несколько мегабайт.

Вот как раз этот объём и хорошо бы соотнести с числом экранов.

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

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

AVK>>А что — С++ с 96 года сильно изменился?
ГВ>Не столько C++, сколько инструменты, его поддерживающие. Кроме того, стандарт был принят-таки в 98 г.
Вот только что роадмап почитал — MS заявляет что в следующем релизе студии он реализует стандарт на 90%. Да, хорош язык коль такой монстр как MS смог реализовать 90% только к 8 версии.

AVK>>Лучшего советчика чем опыт я не знаю. И уж точно не буду полагатся на маркетинговую трепотню. На сайте МС написано одно, в статьях другое, а когда лезешь в фреймворк оказывается что третье.
ГВ>Точно. Только ты уже повёлся на маркетинг.
Давай ты не будешь за меня говорить, ладно? Когда я заинтересовался дотнетом еще никакого маркетинга не было. Была бета которую я скачал и посмотрел. Посмотрел потому что мне было интересно.

ГВ> Прежде всего тем, что поверил, что ещё немного и .NET будет повсюду и в подавляющем большинстве.
Глупости какие. Не поверил я в это. Когда я впервые увидел дотнет еще непонятно было когда он выдет. Просто я заинтересовался и попробовал сделать пару маленьких проектов, мне понравилось. Ты вобще странный человек — когда я тебе говорю что чтобы разобраться с технологией надо что то попытаться на ней сделать. Ты говоришь что это неправильно. И ты же обвиняешь меня в том что я повелся на маркетинг. Что то логика хромает.

AVK>>У как все сложно. На самом деле всего этого можно избежать. 1) В шарпе есть еще структуры — они могут и в стеке быть. 2)в GC ничего передавать не нужно — он сам все находит.

ГВ>1. Структуры — это всё-таки не совсем классы.
Практически классы. Вся разница в том что они value ну и нет static initializers, всю логику в конструктор надо выносить.

ГВ> 2. Ну какая разница: сам GC находит или ему передают?
Очень большая. Когда GC ищет комп обычно не загружен и все равно простаивает. Т.е. в результате влияние GC на быстродействие заметно меньше чем того же сишного хипа. Можешь IT пораспрашивать, он в свое время очень тщательно это тестировал. А у Влада можешь спросить насколько критична скорость выделения/уничтожения объектов в хипе для общего быстродействия. Он тоже пробовал.

ГВ>Про value-типы и структуры я знаю, но мой пример как раз таки предполагал передачу объекта (экземпляра класса).
Если тебе нужно быстродействие при работе с памятью используй структуры.

AVK>>Все это так, но можно привести и обратные примеры.
ГВ>Примеры в студию!
Тут этих примеров было вагон и маленькая тележка.

AVK>>Не вижу чем. Что это за сервер приложений который надо перекомпилировать при изменении бизнес-логики? Нормальный сервер приложений должен на лету подхватывать изменения в бизнес-правилах и не прекращать работу клиентов если это возможно. Почитай в форуме по дотнету, топик "Разработка учетных систем с использованием .NET" — человек задал несколько вопросов как раз в этом плане и привел набор требований к такому серверу. Вот и прикинь какой кровью отольется их реализация на С++.
ГВ>Не надо домысливать. Никто не собирался перекомпилировать сервер на C++ при изменении прикладной логики.
Да ну. Ну тогда расскажи мне как ты собираешься на плюсах без компонентной технологии на лету бизнес-логику менять. Самые общие моменты.

AVK>> Что же касается С++ для веб-приложений — тут то ты надеюсь спорить не будешь?
ГВ>Поспорил бы, особенно с учётом того, что для меня термин "Web-приложение" звучит подобно "VGA-приложению" или "GUI-приложению", но не вижу в этом смысла.
Приложение с веб-интерфейсом. Так понятнее?

AVK>>Ну математика то здесь при чем? Если конечно не назвать computer science математикой.
ГВ>Математика — инструмент, а как называется наука, её использующая, в данный момент не важно.
Ну тогда все точные науки математикой обозвать можно.

AVK>>Систематизацию никто не отрицает. Только не надо называть все информационные науки математикой.
ГВ>OK, не буду обобщать в смысле названия (это была в определённом смысле метафора), хотя инструменты из теории множеств и булевой алгебры используются нередко.
Используются, но чаще всего как вспомогательные.

ГВ>Я тоже оцениваю технологии не по жужжанию и согласен с твоим подходом. Но а) не все и не всегда поступают аналогично и б) не всегда слышны трезвые голоса, поскольку общий гвалт только возрастает.
Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.

ГВ>Я отлично знаю, что в современных приложениях ХП используются до сих пор и очень активно. Но моя оценка подобных реализаций от этого не меняется. Это всего лишь означает широко распространённое уродство, считающееся нормой.
Это лучше чем если бы их не было.

AVK>>>>Которые поставлены.
ГВ>>>Охарактеризуй задачи, если не затруднит.
AVK>>Ты чего — издеваешся? Ты нить разговора не утерял? Как я их могу охарактеризовать?
ГВ>Нить разговора я не утерял

Просто ответ весьма интересный: "- Что делаете?", "- Что скажут!". Я имел ввиду характеристику задач в смысле — системные, прикладные, "GUI" и т.п. Ну да ладно, проехали. На самом деле, мне было интересно, какую классификацию ты сам выберешь.
Ну нет, дело совсем не так было. Ты спросил что такое спец. Я ответил что это человек который способен качественно решать поставленные перед ним задачи. Ты спросил какие. Я естественно ответил что которые поставлены. А что я еще мог тебе ответить?

AVK>>Не так подробно — есть критерий простота модификации, в том числе и глубокой.
ГВ>OK. А как выносится предположение о характере предполагаемой модификации? Модификаии могут быть разными. Здесь обобщения, ИМХО, неуместны.
А так — никто заранее не знает. Есть определенные, полученные эмпирически прикидки.

ГВ>Порядок байт надо специально учитывать только при обработке взаимодействий с внешними средствами (сети, как правило).
А еще с файлами, БД, и т.д.

ГВ>Ну будет у меня одна функция, переупорядочивающая байты. И всё. На остальную структуру программы это не сильно повлияет.
Тока эту функцию в зависимости от платформы вызывать надо.

AVK>>По первости на 3.1, потом на 4.5 и немножко на 5.0.
ГВ>Мда. Именно их я и имел ввиду...

Ну так там на 5.5 вроде все закончилось. Или ты билдер имеешь ввиду?

AVK>>J# не есть язык для основной разработки. Это просто средство для переноса джава-программ.
ГВ>См. начало постинга.

Ты спрашивал — зачем понадобится таскать программы с платформы на платформу.

AVK>>дотнет должен быть бинарно совместим. Так что каши не будет.
ГВ>С чем он должен быть бинарно совместим? ИМХО — только с самим собой.
Этого достаточно.

AVK>>Не считали
ГВ>Попробуйте посчитать. Особенно в соотношении с другими показателями могут получиться интересные цифры.

Не получиться. Я давно уже там не работаю.

ГВ>А... Java. Тогда — количесто классов. Одним словом — количество deployment items.
Много, больше тысячи точно. Точнее не знаю.

AVK>>Тоже как то не интересновался. Несколько мегабайт.
ГВ>Вот как раз этот объём и хорошо бы соотнести с числом экранов.

А ты что рассчитываешь узнать? И о каких экранах речь идет? Там собственно формочек было очень мало — 90% интерфейсов собиралось на лету. Количество документов? С полсотни наверное было. Отчетов под сотню. Справочников тоже наверное с полсотни. Да не помню я уже сколько там чего было. И не один я все это писал.

... Янус версия 1.0 alpha 3

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

AVK>Здравствуйте Геннадий Васильев, Вы писали:

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

AVK>Вот только что роадмап почитал — MS заявляет что в следующем релизе студии он реализует стандарт на 90%. Да, хорош язык коль такой монстр как MS смог реализовать 90% только к 8 версии.

ИМХО — хорош монстр!

А если совсем ИМХХО, то это признак того, что монстру просто это не было нужно. А отнюдь не показатель характеристик языка.

AVK>Давай ты не будешь за меня говорить, ладно? Когда я заинтересовался дотнетом еще никакого маркетинга не было. Была бета которую я скачал и посмотрел. Посмотрел потому что мне было интересно.

Ни секунды в этом не сомневаюсь. Посмотрел, потому что было интересно.

ГВ>> Прежде всего тем, что поверил, что ещё немного и .NET будет повсюду и в подавляющем большинстве.
AVK>Глупости какие. Не поверил я в это. Когда я впервые увидел дотнет еще непонятно было когда он выдет. Просто я заинтересовался и попробовал сделать пару маленьких проектов, мне понравилось. Ты вобще странный человек — когда я тебе говорю что чтобы разобраться с технологией надо что то попытаться на ней сделать. Ты говоришь что это неправильно. И ты же обвиняешь меня в том что я повелся на маркетинг. Что то логика хромает.

Попробую обосновать. Перед тем как выбирать технологию, обычно сначала определяют требования к ней: зачем, что должна делать, какие-то ещё характеристики. Затем берутся приглянувшиеся по каким-то критериям технологические средства и проводится их "пилотирование". Но это — в идеале. Другой вариант (к сожалению, наиболее частый) — когда выбор средства диктуется вкусовыми предпочтениями (попробовал — понравилось). А вкусовые предпочтения — субъективная вещь и часто корректируется усилиями заинтересованных маркетологов. Это же всё на поверхности лежит! Вот скажи, говорит тебе о чём-нибудь название фирмы Persistence?

AVK>
AVK>>>У как все сложно. На самом деле всего этого можно избежать. 1) В шарпе есть еще структуры — они могут и в стеке быть. 2)в GC ничего передавать не нужно — он сам все находит.

ГВ>>1. Структуры — это всё-таки не совсем классы.
AVK>Практически классы. Вся разница в том что они value ну и нет static initializers, всю логику в конструктор надо выносить.

Ну да. "Почти", "практически"... У C++ единая концепция класса, выразимая как в виде структур, так и классами без разделения value-type / class-type. Собственно, struct отличается от class только public-доступом по умолчанию. Сам же знаешь. Или не ощущаешь разницы?

ГВ>> 2. Ну какая разница: сам GC находит или ему передают?
AVK>Очень большая. Когда GC ищет комп обычно не загружен и все равно простаивает. Т.е. в результате влияние GC на быстродействие заметно меньше чем того же сишного хипа. Можешь IT пораспрашивать, он в свое время очень тщательно это тестировал. А у Влада можешь спросить насколько критична скорость выделения/уничтожения объектов в хипе для общего быстродействия. Он тоже пробовал.

Я это и сам хорошо понимаю. Только если сервер работает в режиме 24x7 то...

ГВ>>Про value-типы и структуры я знаю, но мой пример как раз таки предполагал передачу объекта (экземпляра класса).
AVK>Если тебе нужно быстродействие при работе с памятью используй структуры.

Т.е., вопросы, связанные с управлением памятью также перекладываются на проектирование, как и для C++?

AVK>>>Все это так, но можно привести и обратные примеры.
ГВ>>Примеры в студию!
AVK>Тут этих примеров было вагон и маленькая тележка.

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

AVK>>>Не вижу чем. Что это за сервер приложений который надо перекомпилировать при изменении бизнес-логики? Нормальный сервер приложений должен на лету подхватывать изменения в бизнес-правилах и не прекращать работу клиентов если это возможно. Почитай в форуме по дотнету, топик "Разработка учетных систем с использованием .NET" — человек задал несколько вопросов как раз в этом плане и привел набор требований к такому серверу. Вот и прикинь какой кровью отольется их реализация на С++.
ГВ>>Не надо домысливать. Никто не собирался перекомпилировать сервер на C++ при изменении прикладной логики.
AVK>Да ну. Ну тогда расскажи мне как ты собираешься на плюсах без компонентной технологии на лету бизнес-логику менять. Самые общие моменты.

С++ и компонентные технологии — понятия несколько разных категорий, не находишь? Напоминаю, что я говорил, что а) компонентные технологии нужны на своём месте, б) что можно обойтись без COM, в) ради поддержки компонентных технологий не стоит менять C++. Как из этого могло последовать, что я отрицаю модульность (компонентные технологии — просто модное обозначение этой парадигмы) и собираюсь реализовывать СП без неё?

Без той или иной ипостаси модульного deployment "вода не освятится" в любом случае. А самый общий и самый сложный момент организации взаимодействия "бизнес-приложений" — это решение проблемы "отсечения" клиентов (не пользователей, а объектов-клиентов) от тех модулей, которые предполагается выгрузить и обновить. ИМХО, это общий момент. Не находишь?

Ну нельзя же отцепить модуль, если его объекты в настоящий момент используются! Однако это решается разными способами и в том числе, — подходящими идиомами указателей, но только в рамках межмодульных интерфейсов. Остальные проблемы — конвертации БД, освобождение библиотек, компонентов и т.п. — решаются проще. Только при этом внутри модулей (и, кстати, для интерфейсов экспортируемых ими классов) сохраняются все преимущества использования C++, а в особенности — библиотек шаблонов, которые не тянут за собой трёх вагонов других модулей.

Сервер обеспечивает приложения набором необходимых сервисов, в т.ч. — сервисами загрузки/выгрузки модулей и контролем их функционирования. Вот, собственно и всё основное. Зачем же его перекомпилировать-то?

AVK>>> Что же касается С++ для веб-приложений — тут то ты надеюсь спорить не будешь?
ГВ>>Поспорил бы, особенно с учётом того, что для меня термин "Web-приложение" звучит подобно "VGA-приложению" или "GUI-приложению", но не вижу в этом смысла.
AVK>Приложение с веб-интерфейсом. Так понятнее?

Замечательно! Я именно на это определение и надеялся.

Оно намного более корректно, чем "Web-приложение". Есть приложение и есть Web- или Windows- или VGA- или TTY-интерфейсы пользователя к нему. А также — Web (Http), или TCP/IP, или ещё какая-то коммуникационная среда. Таким образом, термин "Web-приложение" означает приложение с Web-интерфейсом пользователя (читай — xxx Markup Language) и поддерживающее http-протокол взаимодействия с пользователем же. Хорошо, без спора обошлись.

Так вот, ИМХО, что Web-интерфейсы, что Windows-UI+что-то-там сеть — всё едино с точки зрения приложения, поскольку прикладная логика от этого не должна изменяться (Если меняется, то это — бардак) А место C++ здесь — очень даже на стороне приложения. Ну не виноват я, что принято реализовывать прикладную логику на интерфейсных и скриптовых языках. Не виноват!

И ничем иным, кроме как "ненавистью" к пользователям (юзерам) я это объяснить не могу.

AVK>>>Ну математика то здесь при чем? Если конечно не назвать computer science математикой.
ГВ>>Математика — инструмент, а как называется наука, её использующая, в данный момент не важно.
AVK>Ну тогда все точные науки математикой обозвать можно.

Математический аппарат используют? Используют. Иначе не были бы точными. К тому же, я уже отказался от термина "математика", как обобщающего определения.

ГВ>>Я тоже оцениваю технологии не по жужжанию и согласен с твоим подходом. Но а) не все и не всегда поступают аналогично и б) не всегда слышны трезвые голоса, поскольку общий гвалт только возрастает.
AVK>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.

Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

ГВ>>Я отлично знаю, что в современных приложениях ХП используются до сих пор и очень активно. Но моя оценка подобных реализаций от этого не меняется. Это всего лишь означает широко распространённое уродство, считающееся нормой.
AVK>Это лучше чем если бы их не было.

Бесспорно, но одно другого всё равно не отменяет.

AVK>>>>>Которые поставлены.
ГВ>>>>Охарактеризуй задачи, если не затруднит.
AVK>>>Ты чего — издеваешся? Ты нить разговора не утерял? Как я их могу охарактеризовать?
ГВ>>Нить разговора я не утерял

Просто ответ весьма интересный: "- Что делаете?", "- Что скажут!". Я имел ввиду характеристику задач в смысле — системные, прикладные, "GUI" и т.п. Ну да ладно, проехали. На самом деле, мне было интересно, какую классификацию ты сам выберешь.
AVK>Ну нет, дело совсем не так было. Ты спросил что такое спец. Я ответил что это человек который способен качественно решать поставленные перед ним задачи. Ты спросил какие. Я естественно ответил что которые поставлены. А что я еще мог тебе ответить?

Пожалуй, что я тут тоже не совсем корректно себя повёл. Пока снимаю вопрос. Обсудим его попозже, если настроение будет.

AVK>>>Не так подробно — есть критерий простота модификации, в том числе и глубокой.
ГВ>>OK. А как выносится предположение о характере предполагаемой модификации? Модификаии могут быть разными. Здесь обобщения, ИМХО, неуместны.
AVK>А так — никто заранее не знает. Есть определенные, полученные эмпирически прикидки.

Так, принимаю к сведению.

ГВ>>Порядок байт надо специально учитывать только при обработке взаимодействий с внешними средствами (сети, как правило).
AVK>А еще с файлами, БД, и т.д.

Суть — внешние средства.

ГВ>>Ну будет у меня одна функция, переупорядочивающая байты. И всё. На остальную структуру программы это не сильно повлияет.
AVK>Тока эту функцию в зависимости от платформы вызывать надо.

Нет, с точки зрения алгоритма эта функция работает всегда, а в зависимости от конкретной платформы — оптимизируется или нет.

AVK>>>По первости на 3.1, потом на 4.5 и немножко на 5.0.
ГВ>>Мда. Именно их я и имел ввиду...

AVK>Ну так там на 5.5 вроде все закончилось. Или ты билдер имеешь ввиду?

Нет-нет, именно Borland C++ 3.1 до 5.5. Ещё бытовало название "Багланд".

AVK>>>дотнет должен быть бинарно совместим. Так что каши не будет.
ГВ>>С чем он должен быть бинарно совместим? ИМХО — только с самим собой.
AVK>Этого достаточно.

Для работы C# — да.

ГВ>>А... Java. Тогда — количесто классов. Одним словом — количество deployment items.
AVK>Много, больше тысячи точно. Точнее не знаю.

Немало...

AVK>А ты что рассчитываешь узнать? И о каких экранах речь идет? Там собственно формочек было очень мало — 90% интерфейсов собиралось на лету.

Вот это уже неплохо.

AVK>Количество документов? С полсотни наверное было. Отчетов под сотню. Справочников тоже наверное с полсотни. Да не помню я уже сколько там чего было. И не один я все это писал.

Для отчётов генератор делали или готовым пользовались, коль не секрет?

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

AVK>>Глупости какие. Не поверил я в это. Когда я впервые увидел дотнет еще непонятно было когда он выдет. Просто я заинтересовался и попробовал сделать пару маленьких проектов, мне понравилось. Ты вобще странный человек — когда я тебе говорю что чтобы разобраться с технологией надо что то попытаться на ней сделать. Ты говоришь что это неправильно. И ты же обвиняешь меня в том что я повелся на маркетинг. Что то логика хромает.

ГВ>Попробую обосновать. Перед тем как выбирать технологию, обычно сначала определяют требования к ней: зачем, что должна делать, какие-то ещё характеристики. Затем берутся приглянувшиеся по каким-то критериям технологические средства и проводится их "пилотирование". Но это — в идеале. Другой вариант (к сожалению, наиболее частый) — когда выбор средства диктуется вкусовыми предпочтениями (попробовал — понравилось). А вкусовые предпочтения — субъективная вещь и часто корректируется усилиями заинтересованных маркетологов. Это же всё на поверхности лежит!

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

ГВ>Вот скажи, говорит тебе о чём-нибудь название фирмы Persistence?
Persistence Software имеешь ввиду? Да, знакомо. А тебе Castor? Из той же оперы.

AVK>>Практически классы. Вся разница в том что они value ну и нет static initializers, всю логику в конструктор надо выносить.
ГВ>Ну да. "Почти", "практически"... У C++ единая концепция класса, выразимая как в виде структур, так и классами без разделения value-type / class-type.
А в шарпе в safe коде от указателей избавились. Отсуда и отличия. Зато у С++ есть примитивы, а есть классы/структуры. А в шарпе и примитивы это тоже структуры.

ГВ> Собственно, struct отличается от class только public-доступом по умолчанию. Сам же знаешь. Или не ощущаешь разницы?
Ну и что? А в шарпе структура и int вобще не отличаются.

ГВ>Я это и сам хорошо понимаю. Только если сервер работает в режиме 24x7 то...
То что? У самого загруженного сервера нагрузка все равно неравномерна.

AVK>>Если тебе нужно быстродействие при работе с памятью используй структуры.
ГВ>Т.е., вопросы, связанные с управлением памятью также перекладываются на проектирование, как и для C++?
Нет, только тогда когда тебе нужно выжать максимум быстродействия.

AVK>>Тут этих примеров было вагон и маленькая тележка.
ГВ>Да, я помню примеры о компонентах, летающих по станциям сети и генерацию прокси-классов. Я думал, ты приведёшь какой-то более частный случай, который не сводится к компонентизации. Ну, не хочешь — не смею настаивать.
Ну в прошлом же сообщении тебе привел вполне конкретный пример — компиляция бизнес логики на лету. Или еще более конкретно — аналог jsp/asp.net.

AVK>>Да ну. Ну тогда расскажи мне как ты собираешься на плюсах без компонентной технологии на лету бизнес-логику менять. Самые общие моменты.

ГВ>Без той или иной ипостаси модульного deployment "вода не освятится" в любом случае. А самый общий и самый сложный момент организации взаимодействия "бизнес-приложений" — это решение проблемы "отсечения" клиентов (не пользователей, а объектов-клиентов) от тех модулей, которые предполагается выгрузить и обновить. ИМХО, это общий момент. Не находишь?

Ну нельзя же отцепить модуль, если его объекты в настоящий момент используются!
Вот видишь, ты даже возможности такой не видишь. Рекомендую для ознакомления ну например Resin. Он то как не странно вполне замечательно на лету меняет энтерпрайз-бины.

ГВ>Однако это решается разными способами и в том числе, — подходящими идиомами указателей, но только в рамках межмодульных интерфейсов.
Это все общие слова. Ты мне объясни как ты собираешься заменять висящие в памяти классы.

ГВ> Остальные проблемы — конвертации БД, освобождение библиотек, компонентов и т.п. — решаются проще. Только при этом внутри модулей (и, кстати, для интерфейсов экспортируемых ими классов) сохраняются все преимущества использования C++, а в особенности — библиотек шаблонов, которые не тянут за собой трёх вагонов других модулей.
Вагон слов и ничего конкретного.

ГВ>Сервер обеспечивает приложения набором необходимых сервисов, в т.ч. — сервисами загрузки/выгрузки модулей и контролем их функционирования. Вот, собственно и всё основное. Зачем же его перекомпилировать-то?
Сервисы ты эти как реализовывать будешь?

или "GUI-приложению", но не вижу в этом смысла.
AVK>>Приложение с веб-интерфейсом. Так понятнее?

ГВ>Замечательно! Я именно на это определение и надеялся.

Оно намного более корректно, чем "Web-приложение". Есть приложение и есть Web- или Windows- или VGA- или TTY-интерфейсы пользователя к нему. А также — Web (Http), или TCP/IP, или ещё какая-то коммуникационная среда. Таким образом, термин "Web-приложение" означает приложение с Web-интерфейсом пользователя (читай — xxx Markup Language) и поддерживающее http-протокол взаимодействия с пользователем же.
И умеющее работать в глобальной сети. Веб-сервисы это тоже веб-приложение.

ГВ>Так вот, ИМХО, что Web-интерфейсы, что Windows-UI+что-то-там сеть — всё едино с точки зрения приложения, поскольку прикладная логика от этого не должна изменяться (Если меняется, то это — бардак)
Ты уверен? Ты хорошо представляешь что такое веб-интерфейс. Я вот представляю — логика совершенно иная.

ГВ> А место C++ здесь — очень даже на стороне приложения. Ну не виноват я, что принято реализовывать прикладную логику на интерфейсных и скриптовых языках. Не виноват!

И ничем иным, кроме как "ненавистью" к пользователям (юзерам) я это объяснить не могу.
Ну да — все вокруг идиоты, повелись на рекламу. Настоящие кульные приложения надо писать на ц плус плус. Ты ради интереса напиши на С++ аналог rsdn.ru, я думаю просветление наступит быстро.

AVK>>Ну тогда все точные науки математикой обозвать можно.
ГВ>Математический аппарат используют? Используют. Иначе не были бы точными. К тому же, я уже отказался от термина "математика", как обобщающего определения.
Кто бы спорил. Я пытаюсь сказать что математика не должна определять все остальное.

AVK>>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.
ГВ>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

Надо не думать, надо найти недельку и попробовать. Такова уж профессия программера, постоянно надо что то изучать. Было бы приятно конечно один раз потратить время на С++ и всю остальную жизнь совершенствовать свое умение, но, увы, не выйдет.

AVK>>А еще с файлами, БД, и т.д.
ГВ>Суть — внешние средства.
Тока эти внешние средства есть во всех приложениях.

AVK>>Тока эту функцию в зависимости от платформы вызывать надо.
ГВ>Нет, с точки зрения алгоритма эта функция работает всегда, а в зависимости от конкретной платформы — оптимизируется или нет.
При чем тут оптимизация? На платформе А порядок следования байтов один, на платформе В другой. Если ты пишешь код для обоих платформ тебе придется учитывать это.

ГВ>Нет-нет, именно Borland C++ 3.1 до 5.5. Ещё бытовало название "Багланд".
Ну так другиъх и не было. А названия к чему только не придумывали.

AVK>>Количество документов? С полсотни наверное было. Отчетов под сотню. Справочников тоже наверное с полсотни. Да не помню я уже сколько там чего было. И не один я все это писал.
ГВ>Для отчётов генератор делали или готовым пользовались, коль не секрет?
Вот как раз я этим и занимался. Перепробовал их штук несколько и не нашел ни одного который бы подошел, самое интересное что если шаблоны отчетов у них и отчуждались то в малопонятном бинарном формате, несовместимом в разных версиях. Пришлось писать свой, который умел кушать xml. Заказчики от возможности править эти xml'ки просто писали кипятком.

... Янус версия 1.0 alpha 3

Извини, предыдущее сообщение глюкодромно отправилось.

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

AVK>>>Глупости какие. Не поверил я в это. Когда я впервые увидел дотнет еще непонятно было когда он выдет. Просто я заинтересовался и попробовал сделать пару маленьких проектов, мне понравилось. Ты вобще странный человек — когда я тебе говорю что чтобы разобраться с технологией надо что то попытаться на ней сделать. Ты говоришь что это неправильно. И ты же обвиняешь меня в том что я повелся на маркетинг. Что то логика хромает.

ГВ>>Попробую обосновать. Перед тем как выбирать технологию, обычно сначала определяют требования к ней: зачем, что должна делать, какие-то ещё характеристики. Затем берутся приглянувшиеся по каким-то критериям технологические средства и проводится их "пилотирование". Но это — в идеале. Другой вариант (к сожалению, наиболее частый) — когда выбор средства диктуется вкусовыми предпочтениями (попробовал — понравилось). А вкусовые предпочтения — субъективная вещь и часто корректируется усилиями заинтересованных маркетологов. Это же всё на поверхности лежит!

AVK>Опять все не так. Когда я еще занимался джавой у меня появилось немножко свободного времени и я решил посмотреть на аналогичную платформу. На тот момент, да и сейчас аналог джавы один — дотнет.

А почему ты занимался джавой? Мне это интересно, поскольку я Java обходил за километр. Да и сейчас обхожу. И в основном — из-за одиночного наследования, с которым практически познакомился (и натрахался по уши) ещё на Turbo-Pascal 5.5.

ГВ>>Вот скажи, говорит тебе о чём-нибудь название фирмы Persistence?
AVK>Persistence Software имеешь ввиду? Да, знакомо. А тебе Castor? Из той же оперы.

Говорит, но я Java всё ещё стороной обхожу по-возможности.

Причина — выше.

AVK>>>Практически классы. Вся разница в том что они value ну и нет static initializers, всю логику в конструктор надо выносить.
ГВ>>Ну да. "Почти", "практически"... У C++ единая концепция класса, выразимая как в виде структур, так и классами без разделения value-type / class-type.
AVK>А в шарпе в safe коде от указателей избавились. Отсуда и отличия. Зато у С++ есть примитивы, а есть классы/структуры. А в шарпе и примитивы это тоже структуры.

Как подкласс value-type-ов. До чего только оптимизация не доводит.

Да, наворочено до небес. Это интересно выглядит с позиций C++ — программирования, где, как я помню, всё-таки стремятся унифицировать концепции, сведя всё к классам. Это, кстати, и в мануалах по C++ было: "в C++ все типы — классы". С этой позиции Java гораздо лучше C# (концептуально), хотя и хуже, чем C++ (как концептуально, так и по быстродействию).

По сути, проблемы, связанные с GC и его влиянием на проектирование никуда не делись. Только теперь придётся думать ещё и о том, где вводить value-, а где class-type.

Обрати внимание, что от структур на C++ очень даже можно унаследоваться, чего нельзя сделать от C#-структур. Они — sealed по определению.

ГВ>> Собственно, struct отличается от class только public-доступом по умолчанию. Сам же знаешь. Или не ощущаешь разницы?
AVK>Ну и что? А в шарпе структура и int вобще не отличаются.

В смысле — как ипостаси value-type? Ну да, согласен. ИМХО, концептуально — кошмар, поскольку вместо разделения "элементарный тип/класс" (C++) вводится дополнительная градация: "элементарный тип/структура/класс". Собственно говоря, именно это я и имел ввиду.

ГВ>>Я это и сам хорошо понимаю. Только если сервер работает в режиме 24x7 то...
AVK>То что? У самого загруженного сервера нагрузка все равно неравномерна.

Да, только ему наверняка потребуется мусор выбрасывать именно в моменты пиковой нагрузки. Это просто из логики функционирования GC следует.

AVK>>>Если тебе нужно быстродействие при работе с памятью используй структуры.
ГВ>>Т.е., вопросы, связанные с управлением памятью также перекладываются на проектирование, как и для C++?
AVK>Нет, только тогда когда тебе нужно выжать максимум быстродействия.

OK, ясно.

AVK>>>Тут этих примеров было вагон и маленькая тележка.
ГВ>>Да, я помню примеры о компонентах, летающих по станциям сети и генерацию прокси-классов. Я думал, ты приведёшь какой-то более частный случай, который не сводится к компонентизации. Ну, не хочешь — не смею настаивать.
AVK>Ну в прошлом же сообщении тебе привел вполне конкретный пример — компиляция бизнес логики на лету. Или еще более конкретно — аналог jsp/asp.net.

Ты имеешь ввиду описанную тобой ERP или что-то ещё? Вроде бы, asp.net мы вообще не упоминали. Или ты его в качестве примера привёл?

[здесь было о замене объектов на лету]
AVK>Вот видишь, ты даже возможности такой не видишь. Рекомендую для ознакомления ну например Resin. Он то как не странно вполне замечательно на лету меняет энтерпрайз-бины.

Посмотрю, спасибо. Чуть позже выскажусь по этому поводу.

ГВ>>Однако это решается разными способами и в том числе, — подходящими идиомами указателей, но только в рамках межмодульных интерфейсов.
AVK>Это все общие слова. Ты мне объясни как ты собираешься заменять висящие в памяти классы.

Ты имеешь ввиду классы или экземпляры объектов? Если классы, то они автоматически удалятся при выгрузке библиотеки, а если объекты, то они будут удалены перед выгрузкой или во время уничтожения статических данных модуля. Это уже детали проектирования в конкретном контексте конкретного App-сервера.

ГВ>> Остальные проблемы — конвертации БД, освобождение библиотек, компонентов и т.п. — решаются проще. Только при этом внутри модулей (и, кстати, для интерфейсов экспортируемых ими классов) сохраняются все преимущества использования C++, а в особенности — библиотек шаблонов, которые не тянут за собой трёх вагонов других модулей.
AVK>Вагон слов и ничего конкретного.

Я тебе описал самые общие моменты, как ты и просил. Конкретизируй вопрос. ИМХО, на общий вопрос — общий ответ.

ГВ>>Сервер обеспечивает приложения набором необходимых сервисов, в т.ч. — сервисами загрузки/выгрузки модулей и контролем их функционирования. Вот, собственно и всё основное. Зачем же его перекомпилировать-то?
AVK>Сервисы ты эти как реализовывать будешь?

Как часть App-сервера и комплект драйверов. Под "сервисами" я имею ввиду сугубо системные аспекты — коммуникации, систему безопасности и т.п.

AVK>или "GUI-приложению", но не вижу в этом смысла.
AVK>>>Приложение с веб-интерфейсом. Так понятнее?
ГВ>>Замечательно! Я именно на это определение и надеялся.

Оно намного более корректно, чем "Web-приложение". Есть приложение и есть Web- или Windows- или VGA- или TTY-интерфейсы пользователя к нему. А также — Web (Http), или TCP/IP, или ещё какая-то коммуникационная среда. Таким образом, термин "Web-приложение" означает приложение с Web-интерфейсом пользователя (читай — xxx Markup Language) и поддерживающее http-протокол взаимодействия с пользователем же.
AVK>И умеющее работать в глобальной сети. Веб-сервисы это тоже веб-приложение.

А к чему фраза: "умеющее работать в глобальной сети"? Какая разница для приложения — глобальная сеть или локальная? Это вообще с точки зрения прикладной логики должно быть глубоко фиолетово, поскольку это — сугубо компьютерная, а не прикладная специфика. Сие есть забота сетевых драйверов и прочих коммуникационных прослоек (в т.ч. — ORB, DCOM и т.п.).

ГВ>>Так вот, ИМХО, что Web-интерфейсы, что Windows-UI+что-то-там сеть — всё едино с точки зрения приложения, поскольку прикладная логика от этого не должна изменяться (Если меняется, то это — бардак)
AVK>Ты уверен? Ты хорошо представляешь что такое веб-интерфейс. Я вот представляю — логика совершенно иная.

Твоя фраза "логика совершенно иная", ИМХО, свидетельствует о том, что ты невнимательно прочитал мою фразу. Я же ясно сказал — "...с точки зрения приложения". Так что, извини, но я считаю твой довод попросту неправомерным.

Кратко обосную свой взгляд.

Логика взаимодействия человека с машиной в человеко-машинной системе не менялась со времён кнопок и лампочек и не поменяется, ИМХО, ещё столько же. Машина (более узко — прикладная логика приложения) даёт пользователю сигналы и предоставляет органы управления, с помощью которых можно ограниченно (fool-protection) изменяють её параметры. Бесспорно, что внутренняя структура и логика интерфейсной системы самой по себе отличается от структуры управляемой через неё системы. Равно как и внутренние логики разных интерфейсных систем тоже отличаются одна от другой. Как, например, отличается организация Web-интерфейса самого по себе от Windows-интерфейса самого по себе. Но прикладная логика не должна быть завязана на эти аспекты! Это противоречит всем принципам "правильного" модульного проектирования, которые сами по себе рационально обоснованы, иначе не были бы общепризнанными. А то, что подход, искажающий подобное деление распространён более чем широко — так это не означает, что он верен. Человек (в данном случае я имею ввиду проектировщика) в каком-либо контексте всегда делает ошибок больше, чем корректных действий, особенно — поначалу. А ошибки (а смешение абстракций в данном случае — ошибка) могут провоцироваться разными факторами — и маркетинговой активностью (которая почти всегда связана с психологическим давлением посредством, в частности, методом спекуляций на теме "старое/новое") — в том числе.

Банальный пример следствий — помещение прикладной логики в обработчик OnClick. Таким образом всегда делается грубейшая ошибка, поскольку изменения в соответствующем элементе интерфейса пользователя повлияют на прикладную логику. Совокупность таких ошибок рождает непереносимую программу и колоссальное её усложнение.

ГВ>> А место C++ здесь — очень даже на стороне приложения. Ну не виноват я, что принято реализовывать прикладную логику на интерфейсных и скриптовых языках. Не виноват!

И ничем иным, кроме как "ненавистью" к пользователям (юзерам) я это объяснить не могу.
AVK>Ну да — все вокруг идиоты, повелись на рекламу. Настоящие кульные приложения надо писать на ц плус плус. Ты ради интереса напиши на С++ аналог rsdn.ru, я думаю просветление наступит быстро.

Эмоции... Кроме того — невыдержанность и хамство, извини за прямоту. Ты обратил внимание, что я слово "ненависть" в кавычки взял? И ещё небольшая подковырка: а чего это RSDN стал так часто глючить?

AVK>>>Ну тогда все точные науки математикой обозвать можно.
ГВ>>Математический аппарат используют? Используют. Иначе не были бы точными. К тому же, я уже отказался от термина "математика", как обобщающего определения.
AVK>Кто бы спорил. Я пытаюсь сказать что математика не должна определять все остальное.

Конечно, не должна определять "всё остальное", но компьютеры-то — строго детерминированные системы. Куда от этого денешься? Так что, где компьютеры — там и математика и использующие её формальные дисциплины (формальная семантика, формальная логика и т.п). И никуда мы от этого не денемся. ИМХО, вместо "математически", мне стоило употребить термин "формально".

AVK>>>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.
ГВ>>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

AVK>Надо не думать, надо найти недельку и попробовать. Такова уж профессия программера, постоянно надо что то изучать. Было бы приятно конечно один раз потратить время на С++ и всю остальную жизнь совершенствовать свое умение, но, увы, не выйдет.

Ну, на сегодняшний день, время потраченное на изучение C++ окупается многократно. Хотя бы потому, что как Java, так и C# — прямые его наследники по многим показателям.

А кроме того — ИМХО, ты спекулируешь выражением "учиться" и "новизна". Я охотно изучу новую концепцию или перечитаю Ульмана, а вот копаться в очередных приблудах и API просто любопытства ради... извините. Тем более, что из моих собеседников, только ты, IT, да Влад активно защищают .NET. Другие мои знакомые писали на нём. И знаешь, — плевались... Вернулись на C++.

AVK>>>А еще с файлами, БД, и т.д.
ГВ>>Суть — внешние средства.
AVK>Тока эти внешние средства есть во всех приложениях.

Да, и что это меняет? Если необходимо обеспечить переносимость информации, то проблема с порядком байтов в int или float — далеко не самая важная. Кроме того, есть ещё горы библиотек для C++.

AVK>>>Тока эту функцию в зависимости от платформы вызывать надо.
ГВ>>Нет, с точки зрения алгоритма эта функция работает всегда, а в зависимости от конкретной платформы — оптимизируется или нет.
AVK>При чем тут оптимизация? На платформе А порядок следования байтов один, на платформе В другой. Если ты пишешь код для обоих платформ тебе придется учитывать это.

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

AVK>>>Количество документов? С полсотни наверное было. Отчетов под сотню. Справочников тоже наверное с полсотни. Да не помню я уже сколько там чего было. И не один я все это писал.
ГВ>>Для отчётов генератор делали или готовым пользовались, коль не секрет?
AVK>Вот как раз я этим и занимался. Перепробовал их штук несколько и не нашел ни одного который бы подошел, самое интересное что если шаблоны отчетов у них и отчуждались то в малопонятном бинарном формате, несовместимом в разных версиях. Пришлось писать свой, который умел кушать xml. Заказчики от возможности править эти xml'ки просто писали кипятком.

С промежуточным форматом хранения в XML -хорошая идея, одобрямс.

ГВ>Тем более, что из моих собеседников, только ты, IT, да Влад активно защищают .NET. Другие мои знакомые писали на нём. И знаешь, — плевались... Вернулись на C++.

А чего зря воздух сотрясать?

Все равно все останутся при своем мнении. А "мои знакомые" — это абсолютно нерепрезентативная выборка.

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

ГВ>>Тем более, что из моих собеседников, только ты, IT, да Влад активно защищают .NET. Другие мои знакомые писали на нём. И знаешь, — плевались... Вернулись на C++.

Не верю. Хотя, в принципе, возможно, если они тоже занимаются программированием только ради концепции.

IT>А чего зря воздух сотрясать?

Все равно все останутся при своем мнении. А "мои знакомые" — это абсолютно нерепрезентативная выборка.

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

AVK>>Опять все не так. Когда я еще занимался джавой у меня появилось немножко свободного времени и я решил посмотреть на аналогичную платформу. На тот момент, да и сейчас аналог джавы один — дотнет.

ГВ>А почему ты занимался джавой?
Как ты интересно разговор в сторону уводишь. В данном случае не я выбирал средство разработки.

ГВ> Мне это интересно, поскольку я Java обходил за километр. Да и сейчас обхожу. И в основном — из-за одиночного наследования, с которым практически познакомился (и натрахался по уши) ещё на Turbo-Pascal 5.5.
Ну во первых TP 5.5 был первым объектным вариантом паскаля, первый рабочий был 7.0. Во вторых то что ты не умеешь проектировать без множественного наследования еще не означает что без него жить нельзя. Я писал и на паскале, и на джаве, теперь вот на дотнете. И как ни странно от отсутствия множественного наследования не страдаю. Шаблоны действительно иногда позволяют повысить эффективность выполнения, но вот множественное наследование бывает полезным в очень небольшом количестве случаев, жа и те по большей части ограничиваются множественным наследованием интерфейсов, которое и в джаве и в дотнете есть.
А вобще забавно — по TP 5.5 судить о джаве и дотнете

ГВ>Говорит, но я Java всё ещё стороной обхожу по-возможности.

Причина — выше.
Глупая причина надо сказать.

ГВ>Как подкласс value-type-ов. До чего только оптимизация не доводит.

Да, наворочено до небес. Это интересно выглядит с позиций C++ — программирования, где, как я помню, всё-таки стремятся унифицировать концепции, сведя всё к классам. Это, кстати, и в мануалах по C++ было: "в C++ все типы — классы".
Ага, int в С++ тоже класс?

ГВ> С этой позиции Java гораздо лучше C# (концептуально), хотя и хуже, чем C++ (как концептуально, так и по быстродействию).
Вот о чем не знаешь не говори. Гораздо хуже. Та же самая песня — примитивные типы сами по себе, классы сами по себе. Можешь поглядеть на EJB — сколько там наворочено из-за того что есть примитивные типы. В джаве есть аналоги примитивных типов но классы, и вот преобразования туда и оттуда это просто так. В С++ тоже самое. А вот дотнет в этом отношении намного лучше — любой тип может быть приведен к object.

ГВ>По сути, проблемы, связанные с GC и его влиянием на проектирование никуда не делись. Только теперь придётся думать ещё и о том, где вводить value-, а где class-type.
Проблем GC решает куда больше.

ГВ>Обрати внимание, что от структур на C++ очень даже можно унаследоваться, чего нельзя сделать от C#-структур.
ГВ> Они — sealed по определению.
Естественно, у них же vtbl нету. Структура она и есть структура. Кусок памяти просто.

AVK>>Ну и что? А в шарпе структура и int вобще не отличаются.

ГВ>В смысле — как ипостаси value-type? Ну да, согласен. ИМХО, концептуально — кошмар, поскольку вместо разделения "элементарный тип/класс" (C++)
Ты сам себе противоречишь — то у тебя главный недостаток шарпа в том что у него типы не унифицированны, то главный недостаток что они унифицированны. Помоему ты уже споришь ради спора, поскольку вместо аргументов в ход пошла софистика.

ГВ>вводится дополнительная градация: "элементарный тип/структура/класс". Собственно говоря, именно это я и имел ввиду.
Во первых не там никакой градации. Любые данные я могу привести к object. А потом — ты скромно умалчиваешь что в С++ есть указатели на экземпляры, а есть экземпляры классов. Те же яйца вид в профиль.

AVK>>То что? У самого загруженного сервера нагрузка все равно неравномерна.
ГВ>Да, только ему наверняка потребуется мусор выбрасывать именно в моменты пиковой нагрузки. Это просто из логики функционирования GC следует.
Ну ты понимаешь что люди тестировали, и даже при стрессовых нагрузках GC оказывался быстрее сишного хипа. Единственный недостаток GC — непрогнозируемость задержек. Поэтому ни джава ни дотнет не могут применяться в рилтайм системах.

AVK>>Ну в прошлом же сообщении тебе привел вполне конкретный пример — компиляция бизнес логики на лету. Или еще более конкретно — аналог jsp/asp.net.
ГВ>Ты имеешь ввиду описанную тобой ERP или что-то ещё?
Это не я описывал.

ГВ> Вроде бы, asp.net мы вообще не упоминали. Или ты его в качестве примера привёл?
В качестве примера.

AVK>>Это все общие слова. Ты мне объясни как ты собираешься заменять висящие в памяти классы.
ГВ>Ты имеешь ввиду классы или экземпляры объектов?
И классы и экземпляры.

ГВ> Если классы, то они автоматически удалятся при выгрузке библиотеки, а если объекты, то они будут удалены перед выгрузкой или во время уничтожения статических данных модуля. Это уже детали проектирования в конкретном контексте конкретного App-сервера.
А ты пробовал? Вот идиоты COM придумали, оказывается сишные классы без него прекрасно на лету подгружаются. В общем то что ты предлагаешь даже не смешно. Подумай хотя бы о том что произойдет если базовый класс в одной dll а потомок в другой.

AVK>>Вагон слов и ничего конкретного.
ГВ>Я тебе описал самые общие моменты, как ты и просил. Конкретизируй вопрос. ИМХО, на общий вопрос — общий ответ.
Куда уж конкретнее — как в сях на лету подгрузить класс.

AVK>>Сервисы ты эти как реализовывать будешь?
ГВ>Как часть App-сервера и комплект драйверов. Под "сервисами" я имею ввиду сугубо системные аспекты — коммуникации, систему безопасности и т.п.
Опять общие слова. Это все можно сказать про любое средство разработки.

AVK>>И умеющее работать в глобальной сети. Веб-сервисы это тоже веб-приложение.
ГВ>А к чему фраза: "умеющее работать в глобальной сети"? Какая разница для приложения — глобальная сеть или локальная?
Вот сразу видно что ты никогда не писал эти самые работающие в глобальной сети. Разница есть — в величине и предсказуемости задержек, вероятности обрыва, толшине канала и т.д. Вот в обратную сторону пожалуйста — из глобальной сети в локальную.

ГВ>Это вообще с точки зрения прикладной логики должно быть глубоко фиолетово, поскольку это — сугубо компьютерная, а не прикладная специфика. Сие есть забота сетевых драйверов и прочих коммуникационных прослоек (в т.ч. — ORB, DCOM и т.п.).
Все это ты красиво говоришь, только при чем тут С++. И что из тобой перечисленного нельзя реализовать на джаве, дотнете?

AVK>>Ты уверен? Ты хорошо представляешь что такое веб-интерфейс. Я вот представляю — логика совершенно иная.
ГВ>Твоя фраза "логика совершенно иная", ИМХО, свидетельствует о том, что ты невнимательно прочитал мою фразу. Я же ясно сказал — "...с точки зрения приложения". Так что, извини, но я считаю твой довод попросту неправомерным.
С точки зрения приложения логика совершенно иная.

ГВ>Кратко обосную свой взгляд.

ГВ> Но прикладная логика не должна быть завязана на эти аспекты! Это противоречит всем принципам "правильного" модульного проектирования, которые сами по себе рационально обоснованы, иначе не были бы общепризнанными.
ВОт ты попробуй воплотить свои красивые и правильные идеи в жизнь, а потом и будешь всем тут рассказывать как что и почему. До сих пор все попытки привести веб-интерфейсы к GUI оканчивались печально. Что то получилось у MS с вебформсами, но это еще далековато до реального написания приложения которое будет переключаться прозрачно с веб-интерфейса на GUI. Пока что все ограничивается общим ядром, а интерфейс пишется под гуй отдельно, под веб отдельно.

ГВ> А то, что подход, искажающий подобное деление распространён более чем широко — так это не означает, что он верен.
Ну да, мы ж умнее, мы пойдем своим путем. А все эти jsp, asp.net фигня полная. Все правильно.

ГВ>Человек (в данном случае я имею ввиду проектировщика) в каком-либо контексте всегда делает ошибок больше, чем корректных действий, особенно — поначалу. А ошибки (а смешение абстракций в данном случае — ошибка) могут провоцироваться разными факторами — и маркетинговой активностью (которая почти всегда связана с психологическим давлением посредством, в частности, методом спекуляций на теме "старое/новое") — в том числе.
Ну да, во всех бедах виноваты маркетологи. Это как в старом анекдоте — если ты такой умный, то почему ж не богатый?

ГВ>Банальный пример следствий — помещение прикладной логики в обработчик OnClick. Таким образом всегда делается грубейшая ошибка, поскольку изменения в соответствующем элементе интерфейса пользователя повлияют на прикладную логику. Совокупность таких ошибок рождает непереносимую программу и колоссальное её усложнение.
А при чем здесь средства разработки. Ты не уходи от темы.

AVK>>Ну да — все вокруг идиоты, повелись на рекламу. Настоящие кульные приложения надо писать на ц плус плус. Ты ради интереса напиши на С++ аналог rsdn.ru, я думаю просветление наступит быстро.
ГВ>Эмоции... Кроме того — невыдержанность и хамство, извини за прямоту.
Это тиы так воспринимаешь. Не стоит. И все же — напиши. Хотя бы начни.

ГВ> Ты обратил внимание, что я слово "ненависть" в кавычки взял? И ещё небольшая подковырка: а чего это RSDN стал так часто глючить?

То что его почти полностью переписали практически с нуля. Можешь у IT спросить сколько у него ушло на это чистого времени. А потом попробуй сделать тоже на С++ за время в два раза большее.

AVK>>Кто бы спорил. Я пытаюсь сказать что математика не должна определять все остальное.

ГВ>Конечно, не должна определять "всё остальное", но компьютеры-то — строго детерминированные системы.
Компьютер это не сферический конь в вакууме. Программы пишуться не ради программ а ради реального мира. И нет там никакой детерминированности. А еще есть такой раздел прикладной науки как надежность вычисления. Так вот, там априори считается что комп подвержен случайным ошибкам.

ГВ> Куда от этого денешься? Так что, где компьютеры — там и математика и использующие её формальные дисциплины (формальная семантика, формальная логика и т.п). И никуда мы от этого не денемся. ИМХО, вместо "математически", мне стоило употребить термин "формально".
Есть такая наука — системотехника. Так вот — во всех учебниках там ясно написано — аналитическая модель сложных систем на данном уровне развития науки невозможна. Получается описать аналитически только очень простые системы. Вот такие вот пирожки.

AVK>>Надо не думать, надо найти недельку и попробовать. Такова уж профессия программера, постоянно надо что то изучать. Было бы приятно конечно один раз потратить время на С++ и всю остальную жизнь совершенствовать свое умение, но, увы, не выйдет.

ГВ>Ну, на сегодняшний день, время потраченное на изучение C++ окупается многократно. Хотя бы потому, что как Java, так и C# — прямые его наследники по многим показателям.
Шарп и джава похожи на С++ в основном внешне. Как ни странно но у дотнета и дельфи больше сходств чем у дотнета и С++.

ГВ>А кроме того — ИМХО, ты спекулируешь выражением "учиться" и "новизна". Я охотно изучу новую концепцию или перечитаю Ульмана, а вот копаться в очередных приблудах и API просто любопытства ради... извините. Тем более, что из моих собеседников, только ты, IT, да Влад активно защищают .NET. Другие мои знакомые писали на нём. И знаешь, — плевались... Вернулись на C++.
Я тебе отвечу твоими же словами — не умеют строить абстракции. Да и потом — непонятно когда они только успели пописать, поплеваться и вернуться обратно. Релиз только в феврале вышел. Просто видимо они писали 2 дня, не разобрались и вернулись на старое. Вон Влад тоже первое время говорил что дотнет это по большей части фигня полная. Однако у него хватило ума не бросать а разобраться.

AVK>>Тока эти внешние средства есть во всех приложениях.
ГВ>Да, и что это меняет? Если необходимо обеспечить переносимость информации, то проблема с порядком байтов в int или float — далеко не самая важная. Кроме того, есть ещё горы библиотек для C++.
Меняет это одно — переносимые программы на С++ писать тяжело.

ГВ>"Оптимизация" в данном случае означет исключение операции перестановки байтов, если это не нужно на конкретной платформе. Согласен, что я опять неудачный термин выбрал. Тем не менее, в процессе работы определить характер платформы и поставить соответствующий флажок, на основании которого выполнять или не выполнять конвертацию, — не составляет никакого особенного труда.
Вот из таких операций и складываются горы. Вон американы на марсе аппарат потеряли из-за того что футы и метры попутали. А уж там наверное софт тестировался дай боже.

AVK>>Вот как раз я этим и занимался. Перепробовал их штук несколько и не нашел ни одного который бы подошел, самое интересное что если шаблоны отчетов у них и отчуждались то в малопонятном бинарном формате, несовместимом в разных версиях. Пришлось писать свой, который умел кушать xml. Заказчики от возможности править эти xml'ки просто писали кипятком.
ГВ>

С промежуточным форматом хранения в XML -хорошая идея, одобрямс.

А каковой она была 4 года назад, когда это все задумывалось! Я ж говорю, заказчики, когда первую рабочую версию репортера увидели прям паром в потолок били

(у них до этого была системка на дельфи 1 писанная еще под вин 3.1 с родным дельфевым quick report по моему).

<<... J 1.0 alpha 4 >>

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

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>> Ты обратил внимание, что я слово "ненависть" в кавычки взял? И ещё небольшая подковырка: а чего это RSDN стал так часто глючить?

Я могу ответить за каждый глюк RSDN'а

AVK>То что его почти полностью переписали практически с нуля. Можешь у IT спросить сколько у него ушло на это чистого времени. А потом попробуй сделать тоже на С++ за время в два раза большее.

Не с нуля конечно. Большинство переносилось из asp+jscript в asp.net. Отсюда и глюки. Сам знаешь, большинство глюков вносится не при разработке, а при доработке. При первоначальной разработке каждый кусочек кода тщательно тестируется, а при доработке/изменении это делать лениво, да и некогда (заметь, новые фичи не глючат

). Потом я поменял некоторые клиентские скрипты, а браузеры любят использовать кое-что из кеша, понятно, что результат может быть печальным. К тому же asp и asp.net хоть и дружно живут, но сессии между собой не разделяют и выличить это можно только полным изничножением asp.

А про C++ в вебе... забудь. У нас искалка написана на C++. Она то конечно искает, но с тем куском, который занимается генерацией html без поллитры разобраться невозможно. Соответственно, доработка искалки будет не скоро и будет это не дороботка, а полная переделка, главной целью которой будет отделение собственно поиска от представления результатов. Кстати, тут возможно найдётся место и для C++, и как раз там где ему самое место. Хранение данных можно сделать на мап-файлах, т.е. это уже тесная работа с WinAPI, а раз мап-файлы, то вся работа с памятью будет накладывается на отображения. Вот где можно будет порезвиться с указателями

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

ГВ>>Вон Влад тоже первое время говорил что дотнет это по большей части фигня полная. Однако у него хватило ума не бросать а разобраться.

Не ну ты напраслину не гони... Я никогда не гворил "что дотнет это по большей части фигня полная". Я говорил, что там проблем куча. Дык это я и сейчас скажу...

В .NET нужно:
1. Добавить шаблоны. Причем так чтобы их именно джит обрабатывал. Примерно как это сделано в Роторе.
2. Добавить подключение реализаций интерфейсов и отдельных методов. Ну это нечто вроде множественного наследования, но более разумено и менее геморойно (в С++ множественое раследование порождает столько же проблем сколько решает).
3. Открыть как можно больше кода. На худой конец поправить Анакрину.

В общем в .NET есть недостатки. Но уже на сегодня по многим статьям голый С++ (анменеджед) проигрывает .NET. Ставлю 10 пива, что если перечисленные мною вещи будут реализованы, а стандарт С++ будет так же ревностно защищаться от изменения, то через несколько лет С++ превратиться в то что представляет на сегодняшний день С, а может быть и асм, т.е. существовать он будет, но большинству программистов на него будет наплевать с большой колокольни.

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

VD>Не ну ты напраслину не гони... Я никогда не гворил "что дотнет это по большей части фигня полная". Я говорил, что там проблем куча. Дык это я и сейчас скажу...
Да ладно уж скромничать, почитай топики где нибудь за март. В прочем бог с ним, пускай не говорил.

VD>В .NET нужно:
VD>1. Добавить шаблоны. Причем так чтобы их именно джит обрабатывал. Примерно как это сделано в Роторе.
Нужно. Никто вроде и не спорит.

VD>2. Добавить подключение реализаций интерфейсов и отдельных методов. Ну это нечто вроде множественного наследования, но более разумено и менее геморойно (в С++ множественое раследование порождает столько же проблем сколько решает).
Да, тут в отличие от мн смысл есть. И вроде бы им там не особо напрягаться придется, ничего сложного нет.

VD>3. Открыть как можно больше кода. На худой конец поправить Анакрину.

VD>Ставлю 10 пива,
10 чего? Кружек, бутылок, литров, баклажек, бочек?

... << J 1.0 alpha 4 >>

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

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

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

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

Пара слов против .Net (соответсвенно за C++):

— Во первых писать что-то на шарпе для людей работающих не под XP/2000 (системные утилитки полезные например) нереально, потому что НИКОГО не заставишь себе на машину поставить CLR ради мелкой программы какой-нибудь — т.е. несмотря на рантаймы Backward compatibility распространяется только на "пузатых" клиентов (которые деньги заплатили и которым продукт навязать можно

)

— Во вторых (и если я ошибаюсь — поправьте) написать на C# что-то вроде Quake и тд и тп просто невозможно — никакой GB это дело, которое в игрущках с памятью творится (очень уж они охочи до последнего байтика, да не про запас а сразу в дело!) не разрулит

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

IP>- Во первых писать что-то на шарпе для людей работающих не под XP/2000 (системные утилитки полезные например) нереально, потому что НИКОГО не заставишь себе на машину поставить CLR ради мелкой программы какой-нибудь
MS заставит, не сомневайся. Просто как и MFC, в следующей версии ОС лотнет-рантайм будет встроенный. Да и не понимаю я в чем проблема рантайм поставить.

IP>- Во вторых (и если я ошибаюсь — поправьте) написать на C# что-то вроде Quake и тд и тп просто невозможно — никакой GB это дело, которое в игрущках с памятью творится (очень уж они охочи до последнего байтика, да не про запас а сразу в дело!) не разрулит
Ну насчет возможности ничего не скажу, по крайней мере пока 3D-библиотеки для дотнета нет. Но память тут точно ни при чем, все там прекрасно разрулиться. И не GB а GC.

... << J 1.0 alpha 4 >>

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

AVK>Здравствуйте Геннадий Васильев, Вы писали:

AVK>>>Опять все не так. Когда я еще занимался джавой у меня появилось немножко свободного времени и я решил посмотреть на аналогичную платформу. На тот момент, да и сейчас аналог джавы один — дотнет.

ГВ>>А почему ты занимался джавой?
AVK>Как ты интересно разговор в сторону уводишь. В данном случае не я выбирал средство разработки.

ГВ>> Мне это интересно, поскольку я Java обходил за километр. Да и сейчас обхожу. И в основном — из-за одиночного наследования, с которым практически познакомился (и натрахался по уши) ещё на Turbo-Pascal 5.5.
AVK>Ну во первых TP 5.5 был первым объектным вариантом паскаля, первый рабочий был 7.0. Во вторых то что ты не умеешь проектировать без множественного наследования еще не означает что без него жить нельзя. Я писал и на паскале, и на джаве, теперь вот на дотнете. И как ни странно от отсутствия множественного наследования не страдаю.

[...]

Как пишет Буч, "Необходимость множественного наследования в OOP остается предметом горячих споров. По нашему опыту, множественное наследование — как парашют: как правило, он не нужен, но, когда вдруг он понадобится, будет жаль, если его не окажется под рукой."

Кстати, его любимый язык С++

Можете убедиться

P.S. Гнилыми помидорами просьба не кидаться, это не апеллирование к авторитету, а просто интересный (возможно устаревший) факт.

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

M>Как пишет Буч, "Необходимость множественного наследования в OOP остается предметом горячих споров. По нашему опыту, множественное наследование — как парашют: как правило, он не нужен, но, когда вдруг он понадобится, будет жаль, если его не окажется под рукой."

Вот только почему то на пассажирских самолетах люди без парашутов летают.

... << J 1.0 alpha 4 >>

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

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

M>>Как пишет Буч, "Необходимость множественного наследования в OOP остается предметом горячих споров. По нашему опыту, множественное наследование — как парашют: как правило, он не нужен, но, когда вдруг он понадобится, будет жаль, если его не окажется под рукой."

AVK>Вот только почему то на пассажирских самолетах люди без парашутов летают.

Добавь еще "... и никто об этом не пожалел"

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

AVK>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>А почему ты занимался джавой?
AVK>Как ты интересно разговор в сторону уводишь. В данном случае не я выбирал средство разработки.

Раз не ты выбирал — вопрос снимается.

ГВ>> Мне это интересно, поскольку я Java обходил за километр. Да и сейчас обхожу. И в основном — из-за одиночного наследования, с которым практически познакомился (и натрахался по уши) ещё на Turbo-Pascal 5.5.
AVK>Ну во первых TP 5.5 был первым объектным вариантом паскаля, первый рабочий был 7.0. Во вторых то что ты не умеешь проектировать без множественного наследования еще не означает что без него жить нельзя. Я писал и на паскале, и на джаве, теперь вот на дотнете. И как ни странно от отсутствия множественного наследования не страдаю. Шаблоны действительно иногда позволяют повысить эффективность выполнения, но вот множественное наследование бывает полезным в очень небольшом количестве случаев, жа и те по большей части ограничиваются множественным наследованием интерфейсов, которое и в джаве и в дотнете есть.
AVK>А вобще забавно — по TP 5.5 судить о джаве и дотнете

Модели наследования очень уж похожи. А насчёт проектирования без множественного наследования — не кипятись, эмулировать такое наследование через агрегацию я умею, хоть и не люблю. Ладно, давай закроем тему про TP.

ГВ>>Говорит, но я Java всё ещё стороной обхожу по-возможности.

Причина — выше.
AVK>Глупая причина надо сказать.

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

ГВ>>Как подкласс value-type-ов. До чего только оптимизация не доводит.

Да, наворочено до небес. Это интересно выглядит с позиций C++ — программирования, где, как я помню, всё-таки стремятся унифицировать концепции, сведя всё к классам. Это, кстати, и в мануалах по C++ было: "в C++ все типы — классы".
AVK>Ага, int в С++ тоже класс?

Нет, конечно, физически int — не тоже самое, что и класс, тут главное — акцент на унифицированное представление в мозгах. Что-то вроде "воспитания" пользователей (программистов).

ГВ>> С этой позиции Java гораздо лучше C# (концептуально), хотя и хуже, чем C++ (как концептуально, так и по быстродействию).
AVK>Вот о чем не знаешь не говори. Гораздо хуже. Та же самая песня — примитивные типы сами по себе, классы сами по себе. Можешь поглядеть на EJB — сколько там наворочено из-за того что есть примитивные типы.

И нет шаблонов...

AVK>В джаве есть аналоги примитивных типов но классы, и вот преобразования туда и оттуда это просто так. В С++ тоже самое. А вот дотнет в этом отношении намного лучше — любой тип может быть приведен к object.

Софистика и демагогия чистой воды. Например, в C++ преобразования "туда и оттуда" совсем не аналогичны Javа, сам это прекрасно знаешь. И чем в данном случае .NET намного лучше? Вообще — как это всё логически связано?

ГВ>>По сути, проблемы, связанные с GC и его влиянием на проектирование никуда не делись. Только теперь придётся думать ещё и о том, где вводить value-, а где class-type.
AVK>Проблем GC решает куда больше.

С твоей точки зрения — "больше решает", с моей — "больше создаёт". Частичное подтверждение моей точки зрения я нашёл в твоих словах ниже о непредсказуемости задержек.

ГВ>>Обрати внимание, что от структур на C++ очень даже можно унаследоваться, чего нельзя сделать от C#-структур.
ГВ>> Они — sealed по определению.
AVK>Естественно, у них же vtbl нету. Структура она и есть структура. Кусок памяти просто.

Обрати внимание не терминологию — она сугубо "сишная". Это просто наблюдение...

AVK>>>Ну и что? А в шарпе структура и int вобще не отличаются.

ГВ>>В смысле — как ипостаси value-type? Ну да, согласен. ИМХО, концептуально — кошмар, поскольку вместо разделения "элементарный тип/класс" (C++)
AVK>Ты сам себе противоречишь — то у тебя главный недостаток шарпа в том что у него типы не унифицированны, то главный недостаток что они унифицированны. Помоему ты уже споришь ради спора, поскольку вместо аргументов в ход пошла софистика.

Ничего подобного. Я говорил о дополнительном критерии отличия, введённом (появившемся) для сложных типов данных. Притом, критерий этот смешивает композиционный аспект и аспект физического представления. Да, их можно в каком-то смысле унифицировать boxing-ом. В рантайме. (Кстати, вовсе не обязательно было разрывать мою фразу пополам, создаётся ощущение, что ты начинаешь опровергать довод, называя его софистикой, не дочитав до конца.)

ГВ>>вводится дополнительная градация: "элементарный тип/структура/класс". Собственно говоря, именно это я и имел ввиду.
AVK>Во первых не там никакой градации. Любые данные я могу привести к object. А потом — ты скромно умалчиваешь что в С++ есть указатели на экземпляры, а есть экземпляры классов. Те же яйца вид в профиль.

В данном случае указатели и ссылки я не рассматривал. Кстати, в C# тоже есть ref (аналог &), params (маршализуемый аналог эклипсиса), out (в C++ предусмотрена защита от модификации параметра, переданного по указателю через модификатор const).

AVK>>>То что? У самого загруженного сервера нагрузка все равно неравномерна.
ГВ>>Да, только ему наверняка потребуется мусор выбрасывать именно в моменты пиковой нагрузки. Это просто из логики функционирования GC следует.
AVK>Ну ты понимаешь что люди тестировали, и даже при стрессовых нагрузках GC оказывался быстрее сишного хипа. Единственный недостаток GC — непрогнозируемость задержек. Поэтому ни джава ни дотнет не могут применяться в рилтайм системах.

Про realtime-системы совершенно согласен. (Стакан в студию!) Я именно непрогнозируемость задержек и имел ввиду. Кстати, я не думаю, что это критично в любом приложении, но нервов может попортить много. Кстати, управление технологическим процессом я бы такой системе не доверил.

AVK>>>Ну в прошлом же сообщении тебе привел вполне конкретный пример — компиляция бизнес логики на лету. Или еще более конкретно — аналог jsp/asp.net.
ГВ>>Ты имеешь ввиду описанную тобой ERP или что-то ещё?
AVK>Это не я описывал.

Здравствуйте!

Перечитай свои же постинги про 90% форм, генерируемых на Java.

ГВ>> Если классы, то они автоматически удалятся при выгрузке библиотеки, а если объекты, то они будут удалены перед выгрузкой или во время уничтожения статических данных модуля. Это уже детали проектирования в конкретном контексте конкретного App-сервера.
AVK>А ты пробовал? Вот идиоты COM придумали, оказывается сишные классы без него прекрасно на лету подгружаются. В общем то что ты предлагаешь даже не смешно. Подумай хотя бы о том что произойдет если базовый класс в одной dll а потомок в другой.

Здесь ограничения в самом деле получаются подобными COM-овским. Однако, я не утверждаю (и не буду утверждать), что каждый класс обязан быть подгружаемым компонентом. Компоненты — это deployment.

AVK>>>Сервисы ты эти как реализовывать будешь?
ГВ>>Как часть App-сервера и комплект драйверов. Под "сервисами" я имею ввиду сугубо системные аспекты — коммуникации, систему безопасности и т.п.
AVK>Опять общие слова. Это все можно сказать про любое средство разработки.

Я говорил не о средстве разработки, а об архитектуре системы, не передёргивай, please.

AVK>>>И умеющее работать в глобальной сети. Веб-сервисы это тоже веб-приложение.
ГВ>>А к чему фраза: "умеющее работать в глобальной сети"? Какая разница для приложения — глобальная сеть или локальная?
AVK>Вот сразу видно что ты никогда не писал эти самые работающие в глобальной сети. Разница есть — в величине и предсказуемости задержек, вероятности обрыва, толшине канала и т.д. Вот в обратную сторону пожалуйста — из глобальной сети в локальную.

То, о чём ты сказал — не самое интересное. Самое интересное, ИМХО, — сохранение состояний интерфейса пользователя между вызовами.

ГВ>>Это вообще с точки зрения прикладной логики должно быть глубоко фиолетово, поскольку это — сугубо компьютерная, а не прикладная специфика. Сие есть забота сетевых драйверов и прочих коммуникационных прослоек (в т.ч. — ORB, DCOM и т.п.).
AVK>Все это ты красиво говоришь, только при чем тут С++. И что из тобой перечисленного нельзя реализовать на джаве, дотнете?

Я же не говорю, что это принципиально невозможно реализовать на Java или .NET! Да хоть на Вижуал Васике и Fortran! Речь-то шла об архитектуре системы и подходе к её построению. ИМХО, очень хреново, если на верхнем уровне проектирования присутствует разделение понятий Web-интерфейс и Windows-интерфейс. Краткое обоснование я уже приводил.

AVK>>>Ты уверен? Ты хорошо представляешь что такое веб-интерфейс. Я вот представляю — логика совершенно иная.
ГВ>>Твоя фраза "логика совершенно иная", ИМХО, свидетельствует о том, что ты невнимательно прочитал мою фразу. Я же ясно сказал — "...с точки зрения приложения". Так что, извини, но я считаю твой довод попросту неправомерным.
AVK>С точки зрения приложения логика совершенно иная.

Приехали.

Перечитать ещё раз моё сообщение — ну никак. И обоснование двумя строками ниже — совсем нет. Нам бы сначала за меч схватиться, а там разберёмся! Так что-ли?

ГВ>>Кратко обосную свой взгляд.

ГВ>> Но прикладная логика не должна быть завязана на эти аспекты! Это противоречит всем принципам "правильного" модульного проектирования, которые сами по себе рационально обоснованы, иначе не были бы общепризнанными.
AVK>ВОт ты попробуй воплотить свои красивые и правильные идеи в жизнь, а потом и будешь всем тут рассказывать как что и почему. До сих пор все попытки привести веб-интерфейсы к GUI оканчивались печально. Что то получилось у MS с вебформсами, но это еще далековато до реального написания приложения которое будет переключаться прозрачно с веб-интерфейса на GUI. Пока что все ограничивается общим ядром, а интерфейс пишется под гуй отдельно, под веб отдельно.

Это можно считать аргументом? Если да, то он неправомерен, поскольку сие — аргумент к коллективу.

Предлагаю постановить, что доводы типа: "а ты попробуй, знаешь как это трудно!" — не котируются, если не снабжены дополнительными разъяснениями о том, что именно считается трудным. Я во всяком случае на подобные выпады больше отвечать не буду. Понимаешь ли, для меня выражение "трудно, но можно" означает, что я так и сделаю, потому что "можно".

ГВ>> А то, что подход, искажающий подобное деление распространён более чем широко — так это не означает, что он верен.
AVK>Ну да, мы ж умнее, мы пойдем своим путем. А все эти jsp, asp.net фигня полная. Все правильно.

В корень зришь!

ASP — это не "полная фигня" ни в коем случае, но уже тепло.

ГВ>>Человек (в данном случае я имею ввиду проектировщика) в каком-либо контексте всегда делает ошибок больше, чем корректных действий, особенно — поначалу. А ошибки (а смешение абстракций в данном случае — ошибка) могут провоцироваться разными факторами — и маркетинговой активностью (которая почти всегда связана с психологическим давлением посредством, в частности, методом спекуляций на теме "старое/новое") — в том числе.
AVK>Ну да, во всех бедах виноваты маркетологи. Это как в старом анекдоте — если ты такой умный, то почему ж не богатый?

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

ГВ>>Банальный пример следствий — помещение прикладной логики в обработчик OnClick. Таким образом всегда делается грубейшая ошибка, поскольку изменения в соответствующем элементе интерфейса пользователя повлияют на прикладную логику. Совокупность таких ошибок рождает непереносимую программу и колоссальное её усложнение.
AVK>А при чем здесь средства разработки. Ты не уходи от темы.

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

А причём тут средства разработки? Так очень даже причём — мы же их выбираем. То есть, если мне, к примеру, прожужжат все уши про новую тулзу ",NODE", которая решит гору проблем программирования и которые я сам, допустим, не представляю как решать — то велика вероятность того, что именно ",NODE" я и выберу и вместо траты времени на совершенствование своего продукта (и себя любимого), я потрачу то же (и даже большее) время на изучение ",NODE" и, к сожалению, не факт, что получу существенно лучший результат. Поэтому, кстати, и стараюсь сначала понять, что именно представляет из себя то или иное средство, а потом уже его использовать.

AVK>>>Ну да — все вокруг идиоты, повелись на рекламу. Настоящие кульные приложения надо писать на ц плус плус. Ты ради интереса напиши на С++ аналог rsdn.ru, я думаю просветление наступит быстро.
ГВ>>Эмоции... Кроме того — невыдержанность и хамство, извини за прямоту.
AVK>Это тиы так воспринимаешь. Не стоит. И все же — напиши. Хотя бы начни.

Хорошо, возможно, для тебя такая форма общения — с постоянным передразниванием и попытками унижения оппонента — норма. Учту. Собственно, уже учёл.

ГВ>> Ты обратил внимание, что я слово "ненависть" в кавычки взял? И ещё небольшая подковырка: а чего это RSDN стал так часто глючить?

AVK>То что его почти полностью переписали практически с нуля. Можешь у IT спросить сколько у него ушло на это чистого времени. А потом попробуй сделать тоже на С++ за время в два раза большее.

IT уже сказал "своё веское".

AVK>>>Кто бы спорил. Я пытаюсь сказать что математика не должна определять все остальное.

ГВ>>Конечно, не должна определять "всё остальное", но компьютеры-то — строго детерминированные системы.
AVK>Компьютер это не сферический конь в вакууме. Программы пишуться не ради программ а ради реального мира. И нет там никакой детерминированности. А еще есть такой раздел прикладной науки как надежность вычисления. Так вот, там априори считается что комп подвержен случайным ошибкам.

К чему ты это? Да, компьютер подвержен случайным ошибкам. Но ошибки, потому-то и считаются ошибками, что есть некая исходная модель "правильного" поведения системы, отклонение от которой и считается ошибкой. Если бы этих моделей не было, то мы бы всё ещё на счётах считали. Так что, случайные ошибки не отменяют общего детерминизма компьютеров.

ГВ>> Куда от этого денешься? Так что, где компьютеры — там и математика и использующие её формальные дисциплины (формальная семантика, формальная логика и т.п). И никуда мы от этого не денемся. ИМХО, вместо "математически", мне стоило употребить термин "формально".
AVK>Есть такая наука — системотехника. Так вот — во всех учебниках там ясно написано — аналитическая модель сложных систем на данном уровне развития науки невозможна. Получается описать аналитически только очень простые системы. Вот такие вот пирожки.

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

ГВ>>А кроме того — ИМХО, ты спекулируешь выражением "учиться" и "новизна". Я охотно изучу новую концепцию или перечитаю Ульмана, а вот копаться в очередных приблудах и API просто любопытства ради... извините. Тем более, что из моих собеседников, только ты, IT, да Влад активно защищают .NET. Другие мои знакомые писали на нём. И знаешь, — плевались... Вернулись на C++.
AVK>Я тебе отвечу твоими же словами — не умеют строить абстракции. Да и потом — непонятно когда они только успели пописать, поплеваться и вернуться обратно. Релиз только в феврале вышел. Просто видимо они писали 2 дня, не разобрались и вернулись на старое. Вон Влад тоже первое время говорил что дотнет это по большей части фигня полная. Однако у него хватило ума не бросать а разобраться.

Возможно, что ты и прав, поскольку они на бете писали в конце прошлого года. Я привёл этот пример только в качестве иллюстрации. Относительно их способности строить абстракции я по определению ничего говорить не буду.
Ладно, снимаю довод, как неправомерный в контексте дискуссии. Хотя я им только эмоции выражал.

AVK>>>Тока эти внешние средства есть во всех приложениях.
ГВ>>Да, и что это меняет? Если необходимо обеспечить переносимость информации, то проблема с порядком байтов в int или float — далеко не самая важная. Кроме того, есть ещё горы библиотек для C++.
AVK>Меняет это одно — переносимые программы на С++ писать тяжело.

Всё зависит от того, как выбраны основные абстракции и как они эволюционируют. Это, ИМХО — ключ ко многим проблемам разработки софта.

ГВ>>"Оптимизация" в данном случае означет исключение операции перестановки байтов, если это не нужно на конкретной платформе. Согласен, что я опять неудачный термин выбрал. Тем не менее, в процессе работы определить характер платформы и поставить соответствующий флажок, на основании которого выполнять или не выполнять конвертацию, — не составляет никакого особенного труда.
AVK>Вот из таких операций и складываются горы. Вон американы на марсе аппарат потеряли из-за того что футы и метры попутали. А уж там наверное софт тестировался дай боже.

По этому поводу хорошо проезжался, кажется, Алан Картер с Progstone (http://progstone.narod.ru — русский вариант сайта, более точно ссылку указать не смогу — то ли где-то в материалах, то ли в рассылках, но суть не в этом). Посмотри там. Конкретно, там была фраза типа такой: "они [представители NASA] сказали, что будут совершенствовать процесс и дальше". Это в ответ на потерю аппарата. Что можно сказать — молодцы!

Наверное, им стоило на Java софт написать — тогда бы он вообще не взлетел

) Или на .NET — чтобы взлетел неизвестно когда. Шутка.

Просто твой довод абсолютно "не в тему".

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

ГВ>Модели наследования очень уж похожи. А насчёт проектирования без множественного наследования — не кипятись, эмулировать такое наследование через агрегацию я умею, хоть и не люблю.
Это еще не известно кто кого эмулирует, агрегация мн или мн агрегацию

ГВ>Не настаиваю на однозначной её оценке всеми, но тем не менее, для меня поддобное ограничение оказалось существенным. А поскольку я был свободен в выборе инструментария, то и отказался от Java.
Пословицу про молоко и воду помнишь?

AVK>>Вот о чем не знаешь не говори. Гораздо хуже. Та же самая песня — примитивные типы сами по себе, классы сами по себе. Можешь поглядеть на EJB — сколько там наворочено из-за того что есть примитивные типы.
ГВ>И нет шаблонов...

Нет. Там шаблоны в том виде в каком они в С++ и не помогут, тут нужен те самый generic types, которые шаблоны, но в рантайме.

AVK>>Проблем GC решает куда больше.
ГВ>С твоей точки зрения — "больше решает", с моей — "больше создаёт". Частичное подтверждение моей точки зрения я нашёл в твоих словах ниже о непредсказуемости задержек.
Тогда рассказывай какая у тебя предметная область.

AVK>>Естественно, у них же vtbl нету. Структура она и есть структура. Кусок памяти просто.
ГВ>Обрати внимание не терминологию — она сугубо "сишная". Это просто наблюдение...
Где ты тут сишную терминологию увидел?

ГВ>В данном случае указатели и ссылки я не рассматривал. Кстати, в C# тоже есть ref (аналог &), params (маршализуемый аналог эклипсиса), out (в C++ предусмотрена защита от модификации параметра, переданного по указателю через модификатор const).

params то тут при чем? Чистейшей воды синтаксическая конструкция.

ГВ>Про realtime-системы совершенно согласен. (Стакан в студию!) Я именно непрогнозируемость задержек и имел ввиду. Кстати, я не думаю, что это критично в любом приложении, но нервов может попортить много.
Не вижу как это может попортить нервы в серверах приложений к примеру. Непредсказуемость это не значит что GC прервет работу программы на десятки секунд.

ГВ> Кстати, управление технологическим процессом я бы такой системе не доверил.
А это смотря какие ТП. Если они некритичны к запаздыванию в единицы секунд то очень интересный вариант платформы.

AVK>>А ты пробовал? Вот идиоты COM придумали, оказывается сишные классы без него прекрасно на лету подгружаются. В общем то что ты предлагаешь даже не смешно. Подумай хотя бы о том что произойдет если базовый класс в одной dll а потомок в другой.

ГВ>Здесь ограничения в самом деле получаются подобными COM-овским. Однако, я не утверждаю (и не буду утверждать), что каждый класс обязан быть подгружаемым компонентом. Компоненты — это deployment.
Для объектов бизнес-логики это обязательное условие.

AVK>>Опять общие слова. Это все можно сказать про любое средство разработки.
ГВ>Я говорил не о средстве разработки, а об архитектуре системы, не передёргивай, please.
А С++ то ту при чем?

ГВ>То, о чём ты сказал — не самое интересное. Самое интересное, ИМХО, — сохранение состояний интерфейса пользователя между вызовами.
Вот поэтому веб интерфейс так сильно отличается от гуя.

ГВ>Я же не говорю, что это принципиально невозможно реализовать на Java или .NET! Да хоть на Вижуал Васике и Fortran! Речь-то шла об архитектуре системы и подходе к её построению. ИМХО, очень хреново, если на верхнем уровне проектирования присутствует разделение понятий Web-интерфейс и Windows-интерфейс. Краткое обоснование я уже приводил.
Хреново, не хреново, но разделение присутствует, иначе либо гуй фиговый, либо веб-интерфейс. Вот только непонятно что ты под верхним уровнем понимаешь. Интерфейсную логику в ялдро системы тащить конечно не надо. А вот презентативная логика получается разной.

ГВ>Это можно считать аргументом? Если да, то он неправомерен, поскольку сие — аргумент к коллективу.
Это ты так считаешь. Все же я не готов поверить что ты вот сядешь и напишешь лучше чем все остальные писали до этого.
Это самые правильные аргументы — факты в голом виде.

ГВ>Предлагаю постановить, что доводы типа: "а ты попробуй, знаешь как это трудно!" — не котируются, если не снабжены дополнительными разъяснениями о том, что именно считается трудным. Я во всяком случае на подобные выпады больше отвечать не буду. Понимаешь ли, для меня выражение "трудно, но можно" означает, что я так и сделаю, потому что "можно".
Просто устал я за тобой замечать незнание что такое дотнет. И если ты такой упорный то бог бы с ним, это твое личное дело. Но ты ведь новичкам советуешь не пользоваться дотнетом, даже не попробовав сам.

AVK>>Ну да, мы ж умнее, мы пойдем своим путем. А все эти jsp, asp.net фигня полная. Все правильно.
ГВ>В корень зришь!

ASP — это не "полная фигня" ни в коем случае, но уже тепло.
А ты его пробовал?

ГВ>Я не ухожу от темы, поскольку от слов "Кратко обосную свой взгляд..." и до этого места шло очень краткое обоснование утверждения о том, что приложение не должно зависеть от конкретных ипостасей коммуникаций и интерфейсов. Возможно, оно в чём-то сумбурное, извини уж за стилистику. Я мог бы уточнить те или иные моменты, если бы ты заинтересовался.
Не, ты сам себе тему для спора что ли придумываешь? Я тебя все время стараюсь перевести на тему конкретных средств разработки, а ты постоянно сваливаешься на общие слова о системах вобще.

ГВ>",NODE", которая решит гору проблем программирования и которые я сам, допустим, не представляю как решать — то велика вероятность того, что именно ",NODE" я и выберу и вместо траты времени на совершенствование своего продукта (и себя любимого), я потрачу то же (и даже большее) время на изучение ",NODE" и, к сожалению, не факт, что получу существенно лучший результат.
Вот видишь — тебе видимо кто то прожужжал уши что дотнет это ерунда и ты теперь в этом уверен, да еще и других агитируешь. В этом и проблема.
Но только не надо на других это переносить. Лично мне плевать на то что про продукт рассказывают его продавцы и производители. И не стоит меня убеждать что я себя не понимаю и на самом то деле разбираться с дотнетом меня заставили злобные маркетологи.

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

AVK>>Это тиы так воспринимаешь. Не стоит. И все же — напиши. Хотя бы начни.
ГВ>Хорошо, возможно, для тебя такая форма общения — с постоянным передразниванием и попытками унижения оппонента — норма. Учту. Собственно, уже учёл.

Я не хочу тебя унижать, даже не пытаюсь. Если чем тебя обидел — извини. Я не вижу ничего обидного в предложении попробовать что то написать.

AVK>>То что его почти полностью переписали практически с нуля. Можешь у IT спросить сколько у него ушло на это чистого времени. А потом попробуй сделать тоже на С++ за время в два раза большее.
ГВ>IT уже сказал "своё веское".

Ну это он скромничает.

AVK>>Компьютер это не сферический конь в вакууме. Программы пишуться не ради программ а ради реального мира. И нет там никакой детерминированности. А еще есть такой раздел прикладной науки как надежность вычисления. Так вот, там априори считается что комп подвержен случайным ошибкам.
ГВ>К чему ты это?
К тому что комп недетерминирован.

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

ГВ>Угу. Только с целью обеспечения "постижимости" в общем и возможности аналитического описания в частности. как раз и говорится, что нужно разбивать сложные системы на простые подсистемы, для которых и строится то или иное формальное описание. И для их взаимодействий — тоже.
вот как тебя не обидеть? — скажем так мягко, ты не прав, не все можно разбить на простейшие подсистемы.
AVK>>Меняет это одно — переносимые программы на С++ писать тяжело.

ГВ>Всё зависит от того, как выбраны основные абстракции и как они эволюционируют. Это, ИМХО — ключ ко многим проблемам разработки софта.
Зависит. Но в итоге на джаве получается проще.

В общем, теперь наверное этот топик никто кроме нас уже не читает. Ты уже обижаться стал. Мне надоело по десятому разу повторять одно и тоже. Ты похоже сам не желаешь чтобы тебя в чем то убедили. Что ж — это твое право. В общем все что я хотел я уже сказал, можешь считать что я в этом споре проиграл. Продолжать его я не буду.
Ну и небольшой совет — если будет время ты все же попробуй реализовать на дотнете какой нибудь небольшой проектик из тех которые ты писал на С++.
И не обижайся, никаких личных к тебе претензий и наездов у меня нет.

<<... J 1.0 alpha 4 >>

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

ГВ>А к чему фраза: "умеющее работать в глобальной сети"? Какая разница для приложения — глобальная сеть или локальная? Это вообще с точки зрения прикладной логики должно быть глубоко фиолетово, поскольку это — сугубо компьютерная, а не прикладная специфика. Сие есть забота сетевых драйверов и прочих коммуникационных прослоек (в т.ч. — ORB, DCOM и т.п.).
ГВ>>>Так вот, ИМХО, что Web-интерфейсы, что Windows-UI+что-то-там сеть — всё едино с точки зрения приложения, поскольку прикладная логика от этого не должна изменяться (Если меняется, то это — бардак)

Вот именно, интерфейс это мелочь, главное прикладная логика, которая не должна сильно меняться от типа приложения (настольное, WEB,..).
А теперь вопрос на засыпку: Допустим ты написал на супер универсальном языке C++, очень универсальные классы с прикладной логикой. Каким образом ты собираешься запихнуть свои труды в процесс WEB-сервера (или другого сервера, или если другой программе захочется подергать за твое хозяйство).
Единственное более менее вменяемое решение для этого — COM,DCOM.
Во что превращается прикладная логика когда кней привинчивают COM,ATL? Это довольно печальное зрелище.
Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

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

AVK>>>>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.
ГВ>>>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

Ой не знаю дождешся ли 6 версии .NET программируя на C++. Я имею ввиду доживет ли C++ до 6 версии .NET ????
В последние годы ява заметно потеснила C++, теперь M.soft его добил. От силы 4-5 лет и все, останутся для C++ драйвера, и программирование контроллеров (повышение производительности ПК только усугубляет положение C++).

Тут спор не в синтаксисе языков а в уровне абстракции.
Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен.

Скоро станет не нужно и то что делалось на C++ в последние 5 лет.Возможности повторного использования кода у такого подхода очень слабые. Может это и интересно писать всякие эффективные хитрые алгоритмы сортировок, склеивания копирования строк, и.т.д., но они уже написаны, зачем каждый раз делать одно и тоже?. По крайней мере этим бубут заниматься очень не многие.

А для более высокого уровня C++ не приспособлен.

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

SS>А для более высокого уровня C++ не приспособлен.

Всё правильно, только боюсь что ГВ этот твой постинг аккуратненько проигнорирует

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

[...]
AVK>Ну и небольшой совет — если будет время ты все же попробуй реализовать на дотнете какой нибудь небольшой проектик из тех которые ты писал на С++.

AVK>И не обижайся, никаких личных к тебе претензий и наездов у меня нет.

У меня тоже. Но всё равно спор, ИМХО, неплохой вышел. Спасибо.

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

SS>Во что превращается прикладная логика когда кней привинчивают COM,ATL? Это довольно печальное зрелище.

В прикладную логику с подключённой "толстой" интерфейсной прослойкой. То есть, в то, во что она и должна превратиться в этом случае.

SS>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
SS>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.

SS>Могут возразить что это все частный случай и компонентные технологии (и подобные) используются очень редко, вот об этом можно поспорить. Мое IMHO, они повсюду и с каждым годом их становится больше.

Концептуально — частный случай, фактически — COM и ORB распространены очень широко. Теперь к ним добавляется .NET. Но это ничего не меняет.

AVK>>>>>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.
ГВ>>>>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

SS>Ой не знаю дождешся ли 6 версии .NET программируя на C++. Я имею ввиду доживет ли C++ до 6 версии .NET ????

Да C++-то доживёт. А вот доживёт ли .NET не мутировав во что-то ещё "очень новое" — абсолютно не уверен.

SS>В последние годы ява заметно потеснила C++, теперь M.soft его добил. От силы 4-5 лет и все, останутся для C++ драйвера, и программирование контроллеров (повышение производительности ПК только усугубляет положение C++).

Твоими бы устами

SS>Тут спор не в синтаксисе языков а в уровне абстракции.

Да, только уровень абстракции — человеческая прерогатива. Язык — это просто инструмент. Более или менее удобный. Который тем или иным образом влияет на пользователя. Об том и все эти споры.

По аналогии с филологической лингвистикой (извини за тавтологию), по отношению к программистской лингвистике можно, ИМХО, постулировать, что язык определяет набор абстракций, которыми человек оперирует при удовлетворении своих интеллектуальных потребностей. Есть только одна закавыка — набор абстракций должен быть инструментом попрождения работающей системы. Вот тебе и связка и переход между "уровнем абстракции человека" и "уровнем абстракции от аппаратуры".

SS>Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен.

SS>Скоро станет не нужно и то что делалось на C++ в последние 5 лет.Возможности повторного использования кода у такого подхода очень слабые. Может это и интересно писать всякие эффективные хитрые алгоритмы сортировок, склеивания копирования строк, и.т.д., но они уже написаны, зачем каждый раз делать одно и тоже?. По крайней мере этим бубут заниматься очень не многие.

Интересно, рефлексия в форумах наверное никогда не прекратится.

Не, ребята, я больше в мыльных операх не участвую.

SS>А для более высокого уровня C++ не приспособлен.

А это очень похоже на формулу аутотренинга. Повторять утром и вечером!

Чтобы не подумалось иначе.

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

AVK>Да ладно уж скромничать, почитай топики где нибудь за март. В прочем бог с ним, пускай не говорил.

Вот сам и читай. Найдешь... кинь ссылочку. А так нечего стрелки переводить.

AVK>Да, тут в отличие от мн смысл есть. И вроде бы им там не особо напрягаться придется, ничего сложного нет.

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

VD>>3. Открыть как можно больше кода. На худой конец поправить Анакрину.

AVK>

VD>>Ставлю 10 пива,
AVK>10 чего? Кружек, бутылок, литров, баклажек, бочек?

Ящиков естественно.

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

IP>- Во первых писать что-то на шарпе для людей работающих не под XP/2000 (системные утилитки полезные например) нереально, потому что НИКОГО не заставишь себе на машину поставить CLR ради мелкой программы какой-нибудь — т.е. несмотря на рантаймы Backward compatibility распространяется только на "пузатых" клиентов (которые деньги заплатили и которым продукт навязать можно

)

Сразу видно человек сидит под линуксом или фришкой и плюет на всех остальных. Нет? И ты тоже из под этой навязчивой винды в Интернет лезешь?

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

ГВ>>А к чему фраза: "умеющее работать в глобальной сети"? Какая разница для приложения — глобальная сеть или локальная? Это вообще с точки зрения прикладной логики должно быть глубоко фиолетово, поскольку это — сугубо компьютерная, а не прикладная специфика. Сие есть забота сетевых драйверов и прочих коммуникационных прослоек (в т.ч. — ORB, DCOM и т.п.).
ГВ>>>>Так вот, ИМХО, что Web-интерфейсы, что Windows-UI+что-то-там сеть — всё едино с точки зрения приложения, поскольку прикладная логика от этого не должна изменяться (Если меняется, то это — бардак)

SS>Вот именно, интерфейс это мелочь, главное прикладная логика, которая не должна сильно меняться от типа приложения (настольное, WEB,..).
SS>А теперь вопрос на засыпку: Допустим ты написал на супер универсальном языке C++, очень универсальные классы с прикладной логикой. Каким образом ты собираешься запихнуть свои труды в процесс WEB-сервера (или другого сервера, или если другой программе захочется подергать за твое хозяйство).
SS>Единственное более менее вменяемое решение для этого — COM,DCOM.
SS>Во что превращается прикладная логика когда кней привинчивают COM,ATL? Это довольно печальное зрелище.
SS>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
SS>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

А в apache дотнетовские классы/сборки/чтоунихтам запихиваются?

SS>Могут возразить что это все частный случай и компонентные технологии (и подобные) используются очень редко, вот об этом можно поспорить. Мое IMHO, они повсюду и с каждым годом их становится больше.

SS>

AVK>>>>>Ну я то тебе как раз попробовать что нибуть написать для дотнета советовал.
ГВ>>>>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

Я не Нострадамус, но ежели 6 версия .Net таки будет, то скорее всего она окажется последней

Так что дожидаться ее не стоит

SS>Ой не знаю дождешся ли 6 версии .NET программируя на C++. Я имею ввиду доживет ли C++ до 6 версии .NET ????
SS>В последние годы ява заметно потеснила C++, теперь M.soft его добил. От силы 4-5 лет и все, останутся для C++ драйвера, и программирование контроллеров (повышение производительности ПК только усугубляет положение C++).

Ну, это уж перебор. Повышение производительности ПК обычно сопровождается повышением аппетитов пользователей. На долю С++ останутся, как минимум: движки баз данных, игрушки, графика — и 2, и 3D, статистика всякая, Data/Text mining, да и тот же пользовательский интерфейс, как это ни странно звучит. Например, чтоб не очень убого расположить подписи на круговой (aka "торт") диаграмме, весьма дофига считать приходится (причем, в доли секунды желательно уложиться). Я уж не говорю про визуализацию графов (да и любых больших объемов данных вообще). Или вот как то пришлось делать — есть набор полей в базе данных, есть набор полей в проекте (до нескольких сотен). Называются они похоже, но не идентично. Их надо сопоставить друг другу. Шоб пользователю ручками все сотни не мапить, желательно похожие (не одинаковые) сопоставить автоматом — причем быстро, юзер долго ждать не любит. Прикинь потребную вычислительную мощь. Жаба/нет тут не катят

Это то, что я за 30 секунд вспомнил, на самом деле применений гораздо больше.

SS>Тут спор не в синтаксисе языков а в уровне абстракции.
SS>Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен.

Вот тут ты ошибаешься. asm, конечно, не особо нужен, но с профайлером посидеть иногда приходится.

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

А у кого они сильнее, чем у C++? Причем повторного использования исходников, а не бинарников — с бинарниками везде дело обстоит довольно кисло.

SS> Может это и интересно писать всякие эффективные хитрые алгоритмы сортировок, склеивания копирования строк, и.т.д., но они уже написаны, зачем каждый раз делать одно и тоже?.

Ты ж говоришь, возможности повторного использования кода слабые — вот и переписываем по-новой

А если все уже написано до нас, найди мне, плиз, реализацию tabu search для point feature labeling problem, на любом языке, можно хоть на шарпе

SS>По крайней мере этим бубут заниматься очень не многие.

Уже сейчас очень многие только тем и занимаются, что 1С конфигурируют. Но я к ним не хочу

SS>А для более высокого уровня C++ не приспособлен.

Ню-ню.

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

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

SS>>Во что превращается прикладная логика когда кней привинчивают COM,ATL? Это довольно печальное зрелище.
ГВ>В прикладную логику с подключённой "толстой" интерфейсной прослойкой. То есть, в то, во что она и должна превратиться в этом случае.

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

ГВ>Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.

Мы расходимся во мнении, что абстракции проще прорабатывать на более высокоуровневых языках.
Либо ты считаешь C# языком с ограниченными возможностями, наподобии VB6. Я другого мнения.

ГВ>>>>>Да вот я и думаю — стоит на него тратить время сейчас или подождать выхода версии 6.0 ?

SS>>Ой не знаю дождешся ли 6 версии .NET программируя на C++. Я имею ввиду доживет ли C++ до 6 версии .NET ????
ГВ>Да C++-то доживёт. А вот доживёт ли .NET не мутировав во что-то ещё "очень новое" — абсолютно не уверен.

Скорей бы придумали, что нибудь еще более крутое чем .NET, из последних сил цеплятся за .NET не буду.

SS>>А для более высокого уровня C++ не приспособлен.
ГВ>А это очень похоже на формулу аутотренинга. Повторять утром и вечером!

Чтобы не подумалось иначе.

Ну ты не путай мое мнение о C++, с мнением Java-программистов о C#/.NET — это совсем из другой области.
Я же не всегда так думал, было время долго фанател от C++, и было там от чего фанатеть. Могу даже сертификаты Microsoft показать по Visual С++.

Хотя в этих экзаменах языка C++ даже и нету

, только технологии Microsoft.
Но все опошлили современные технологии, из-за которых при программировании с их использованием на C++ резко возросло количество нудной нетворческой механической работы. И увеличился разрыв между программированием и проектированием.
В .NET/C# роль тупого кодера, делающего механическую работу выполняет среда, остается только творческая.

Если ты отвергаешь технологии .NET/C#,Java из-за того что пугают мрачные картины будущего, описанные в этом фантастическом расказе в стиле кибер-панк:
http://www.rsdn.ru/forum/Message.aspx?mid=95594&only=1
Где описано как интелектуально и морально разложившиеся программисты, опухшие отупевшие и окосевшие от скуки, создают крутые ERP и прочие системы перетаскивая мышкой на формах разные компонетты с места на место. Раскрашивают их в разные цвета и отвечают на вопросы визардов.

Это напрасно. Более высокоуровневая это наоборот более интелектуальная работа — то что не может сделать компьютер.
VB6 и всякие нынешние Case системы и 4GL языки — это не полноценые универсальные системы, а просто готовые шаблоны узкоспециализированных решений, поддающиеся настройке.
.NET сюда относить не стоит.

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

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

ГВ>Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.

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

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

S>Ну, это уж перебор. Повышение производительности ПК обычно сопровождается повышением аппетитов пользователей. На долю С++ останутся, как минимум: движки баз данных, игрушки, графика — и 2, и 3D, статистика всякая, Data/Text mining, да и тот же пользовательский интерфейс, как это ни странно звучит. Например, чтоб не очень убого расположить подписи на круговой (aka "торт") диаграмме, весьма дофига считать приходится (причем, в доли секунды желательно уложиться). Я уж не говорю про визуализацию графов (да и любых больших объемов данных вообще). Или вот как то пришлось делать — есть набор полей в базе данных, есть набор полей в проекте (до нескольких сотен). Называются они похоже, но не идентично. Их надо сопоставить друг другу. Шоб пользователю ручками все сотни не мапить, желательно похожие (не одинаковые) сопоставить автоматом — причем быстро, юзер долго ждать не любит. Прикинь потребную вычислительную мощь. Жаба/нет тут не катят

Ну, это уж перебор. Повышение производительности ПК обычно сопровождается повышением аппетитов пользователей. На долю С останутся, как минимум: движки баз данных, игрушки, графика — и 1, и 2D, статистика всякая, Data/Text mining, да и тот же пользовательский интерфейс, как это ни странно звучит. Например, чтоб не очень убого расположить подписи на круговой (aka "торт") диаграмме, весьма дофига считать приходится (причем, в доли секунды желательно уложиться). Я уж не говорю про визуализацию графов (да и любых больших объемов данных вообще). Или вот как то пришлось делать — есть набор полей в базе данных, есть набор полей в проекте (до нескольких сотен). Называются они похоже, но не идентично. Их надо сопоставить друг другу. Шоб пользователю ручками все сотни не мапить, желательно похожие (не одинаковые) сопоставить автоматом — причем быстро, юзер долго ждать не любит. Прикинь потребную вычислительную мощь. C++ тут не катит

S>Это то, что я за 30 секунд вспомнил, на самом деле применений гораздо больше.

Это я припоминаю подобные разговоры 10-летней давности

Остальное поскипано.

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

Да нет у дотнета тех недостатков о которых вы говорите, просто нету. Всё это высосано из пальца и базируется на устаревшем представлении о Java тех времён, когда она работала только в режиме интерпретации. CLR ни чуть не медленнее обычного нативного кода, почитайте Шустриков в конце концов. Контроль ресурсов говорите? А разве в серьёзных игрушках используется стандартный C++ хип? Сомневаюсь, наверняка там своя подсистема управления памятью. Что-нибудь подобное придумают и для C#. Т.е всё это приходящее.

Что же касается полей в базе данных... Был проект написанный на C++ и занимающийся обработкой данных. На один двух-гигабайтный файл уходило до 57 часов. Всё это хозяйство было переписано на C#, время сократилось до 40 минут. В чём дело, спросите вы? Правильно, в правильном дизайне и применении вспомогательных технологий, никак не связанных с самим языком.

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

IT>Господа, сколько уже можно вас призывать и уговаривать. Если вы хотите рассуждать о предмете, то необходимо с ним хотя бы ознакомится.

В процессе...

IT>Да нет у дотнета тех недостатков о которых вы говорите, просто нету. Всё это высосано из пальца и базируется на устаревшем представлении о Java тех времён, когда она работала только в режиме интерпретации.

Дак и у С++ нет тех недостатков, о которых вы говорите. О тех, которые у него на самом деле есть и жить мешают, все почему-то молчат.
Да и говорил я вовсе не о недостатках нета, а о том, что быстродействие много где требуется.

IT>CLR ни чуть не медленнее обычного нативного кода, почитайте Шустриков в конце концов.

Дык это смотря как тестировать. Я надеюсь, ты не станешь утверждать, что виртуальные функции вызываются быстрее обычных? Аналогия понятна? Блин, "антишустрика" написать, что ли...

IT>Контроль ресурсов говорите?

А какие ресурсы, кроме памяти, может автоматически контролировать .Net?

IT>А разве в серьёзных игрушках используется стандартный C++ хип?

Если серьезной игрушкой считать Quake II, так там даже и плюсами не пахнет. Голимый "пуре Це"

И при чем тут, собственно, хип? Быстродействие не только от него зависит. C++ кардинально отличается от нетовских языков тем, что в C++ GC или иной способ управления памятью можно реализовать с куда меньшим геморроем, чем в нетовских языках организовать собственное управление памятью. Да и никто не заставляет в C++ всегда пользоваться евойным хипом, при необходимости можно и системные функции подергать. Тормозил у меня, например, std::stringstream — так я написал свой стримбуфер со своим аллокатором, стало просто летать. Причем, что характерно, если мне этот код портировать вдруг понадобится, я просто поменяю пару дефайнов и на отличных от винды платформах будет работать все тот же std::stringstream — медленно, но будет. Пока нативный аллокатор не напишу

В нете такое практически нереализуемо.

IT>Сомневаюсь, наверняка там своя подсистема управления памятью. Что-нибудь подобное придумают и для C#. Т.е всё это приходящее.

Вот именно, приходящее и уходящее. Когда еще придумают то. А работать сейчас надо.

IT>Что же касается полей в базе данных... Был проект написанный на C++ и занимающийся обработкой данных. На один двух-гигабайтный файл уходило до 57 часов. Всё это хозяйство было переписано на C#, время сократилось до 40 минут. В чём дело, спросите вы?

Дело тут может быть только в том, что программист(ы), писавшие эту С++ программу, плохо владели инструментом. Им и правда надо на .Net сваливать.

IT>Правильно, в правильном дизайне и применении вспомогательных технологий, никак не связанных с самим языком.

Во-во, сравнивают плохой сишный код с хорошим нетовским и говорят, что второе — быстрее. Так кто ж спорит, я вполне могу написать программу на С++, которая будет работать медленне бэйсиковского аналога, мною же написанного.

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

IT>>Господа, сколько уже можно вас призывать и уговаривать. Если вы хотите рассуждать о предмете, то необходимо с ним хотя бы ознакомится.

S>В процессе...

Во-во, давай, а то уже чесслово надоело одно и тоже доказывать.

IT>>Да нет у дотнета тех недостатков о которых вы говорите, просто нету. Всё это высосано из пальца и базируется на устаревшем представлении о Java тех времён, когда она работала только в режиме интерпретации.

S>Дак и у С++ нет тех недостатков, о которых вы говорите. О тех, которые у него на самом деле есть и жить мешают, все почему-то молчат.

Разве кто-то говорит о недостатках? Речь идёт об отсутствии достоинств, которые его выделяли 10 лет назад среди других языков и которыми уже сейчас уже никого не удивишь. Хотя впрочем то, что язык тормознулся в своём развитии тоже можно считать недостатком.

IT>>CLR ни чуть не медленнее обычного нативного кода, почитайте Шустриков в конце концов.

S>Дык это смотря как тестировать. Я надеюсь, ты не станешь утверждать, что виртуальные функции вызываются быстрее обычных? Аналогия понятна? Блин, "антишустрика" написать, что ли...

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

IT>>Контроль ресурсов говорите?

S>А какие ресурсы, кроме памяти, может автоматически контролировать .Net?

Только память. А разве я утверждал обратное?

IT>>А разве в серьёзных игрушках используется стандартный C++ хип?

S>Если серьезной игрушкой считать Quake II, так там даже и плюсами не пахнет. Голимый "пуре Це"

И вся графика ручками написана без всяких DirectX. Или я не прав? Может и не прав, но вот в Doom точно без DirectX обошлись. И что, ты станешь сейчас в неё играть когда уже есть Tournament?

S>И при чем тут, собственно, хип? Быстродействие не только от него зависит. C++ кардинально отличается от нетовских языков тем, что в C++ GC или иной способ управления памятью можно реализовать с куда меньшим геморроем, чем в нетовских языках организовать собственное управление памятью. Да и никто не заставляет в C++ всегда пользоваться евойным хипом, при необходимости можно и системные функции подергать. Тормозил у меня, например, std::stringstream — так я написал свой стримбуфер со своим аллокатором, стало просто летать. Причем, что характерно, если мне этот код портировать вдруг понадобится, я просто поменяю пару дефайнов и на отличных от винды платформах будет работать все тот же std::stringstream — медленно, но будет. Пока нативный аллокатор не напишу

S>В нете такое практически нереализуемо.

Ну вот опять

Я надеюсь ты знаешь кое что об интерфейсах. В дотнете я могу написать свой форматер и передавать данные между стандартными объектами по своему доморощенносму протоколу и всё будет летать. А вот на C++ вместе с COM'ом такого не сделаешь.

Давай не будем приводить в качестве аргумента частные решения. Как я уже говорил всё зависит от дизайна и прямости рук. У меня вообще может возникнуть вполне законный вопрос — а нафига тебе понадобился стримбуфер, неужели нельзя было обойтись без него

IT>>Сомневаюсь, наверняка там своя подсистема управления памятью. Что-нибудь подобное придумают и для C#. Т.е всё это приходящее.

S>Вот именно, приходящее и уходящее. Когда еще придумают то. А работать сейчас надо.

Если ты занимаешься игрушками, то используй C++ и "голимый Це", никто тебя в .NET не тянет. Твоё время пока не пришло

IT>>Что же касается полей в базе данных... Был проект написанный на C++ и занимающийся обработкой данных. На один двух-гигабайтный файл уходило до 57 часов. Всё это хозяйство было переписано на C#, время сократилось до 40 минут. В чём дело, спросите вы?

S>Дело тут может быть только в том, что программист(ы), писавшие эту С++ программу, плохо владели инструментом. Им и правда надо на .Net сваливать.

Опять ты не понял. Ни программисты, ни C++, ни C# тут ни при чём. Парсер был перенесён один в один из C++ в C#. Разница была лишь в методе вставки данных в базу данных. Во втором случае использовался BULK INSERT, который сам по себе работает в десятки раз быстрее.

IT>>Правильно, в правильном дизайне и применении вспомогательных технологий, никак не связанных с самим языком.

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

Да ладно

Всё это мы уже слышали про крутых C++ программеров и даже сами так кричали по всем фидошным эхам в своё время. Но я надеюсь ты не думаешь, что если кто-то был хорошим программером только потому что он писал на C++, и вдруг сразу стал плохим так как начал писать на C#

да..............

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

AVK>Ну насчет возможности ничего не скажу, по крайней мере пока 3D-библиотеки для дотнета нет. Но память тут точно ни при чем, все там прекрасно разрулиться. И не GB а GC.

Отстаешь от жизни...

Врапер для OpenGL 1.2 — http://csgl.sourceforge.net/
ExoEngine — a C# 3D engine (тоже обертка над OpenGL) — http://www.codeproject.com/cs/media/exoengine.asp

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

AVK>Вот только почему то на пассажирских самолетах люди без парашутов летают.

Дык просто они юзеры, а значит по определению ламеры... Кто же даст ламеру в руки такой серьезный инструмент.

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

AVK>>В джаве есть аналоги примитивных типов но классы, и вот преобразования туда и оттуда это просто так. В С++ тоже самое. А вот дотнет в этом отношении намного лучше — любой тип может быть приведен к object.

ГВ>Софистика и демагогия чистой воды. Например, в C++ преобразования "туда и оттуда" совсем не аналогичны Javа, сам это прекрасно знаешь. И чем в данном случае .NET намного лучше? Вообще — как это всё логически связано?

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

Вот тебе код на Шарпе:

int i = 123;
object o = i;
double d = (double)o; // Здесь в рантайме будет исключение
Write(d);

А вот аналог на С++:

int i = 123;
void * o = &i;
double & d = *((double*)o);
Write(d); // Здесь в рантайме будет проход по памяти :)

Теперь о том о чем говорил AVK...
Если приметивный тип является объектом, то можно писать код проверяющий тип объекта и делающий те или иные действия в зависимости от результаотв проверки. Код приведенный мною выше как раз демонстрирует такую возможность в C# и отстуствие такой возможности в С++. Идем дальше...
C++:

void Write(...) { }

С#

void Write(ParamArray object[] pa) { } // Точно синтаксиса не помню, но что-то в этом духе

В С++ такая функция невозможно так как нет информации ни о количестве параметров, ни их типах. Отсюда и раждается уродливый printf и его ошибки типа printf("%d", DoubleVar). И что характерно никакие шаблоны не спасут. Хваленая типобезапастность првращается на поверку в полную опастность.

В C# каждый парамет ссылка на базовый класс обжект которая имеет полное самоописание в рантайме. Это позволяет реализовать printf так printf("{0}", DoubleVar). Внутри метода мы будем иметь массив (тоже самоописываемый) с известным количеством элементов содержащий нужные парамтры. Так как параметры типизированы (хотя и в рантайме) отподает нужда указывать тпм черз %х, а параметр можно использовать внутри описания несколько раз printf("{0} ... {0}", DoubleVar) (ноль в данном случае номер параметра).

Теперь о боксинге. Если параметр не является экземпляром класса, то в языках типа С++ и Явы его нужно запоковать в класс-обертку которая будет предоставлять описание вложенного типа. Вот такая запаковка и распаковка называется боксингом и анбоксингом. Она есть и в Яве и в С++ (просто потому, что это делается вручную). Шарп же делает такую запаковку автоматически и программист может рассуждать в терминах чистой абстракции не задумываяс является ли переменная ссылкой на класс, примитивом или структурой.

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

ГВ>С твоей точки зрения — "больше решает", с моей — "больше создаёт". Частичное подтверждение моей точки зрения я нашёл в твоих словах ниже о непредсказуемости задержек.

Вот это уже форменная демогогия. Какое поддтверждение? Вырвал из контекста... и сделал подтверждением.

AVK>>Естественно, у них же vtbl нету. Структура она и есть структура. Кусок памяти просто.

ГВ>Обрати внимание не терминологию — она сугубо "сишная". Это просто наблюдение...

А ты хотел чтобы она была какая? Оба языка произошли от С и структуры взяли от туда же. Причем я бы даже сказал, что С# их взял намного ближе к оригиналу.

ГВ>Про realtime-системы совершенно согласен. (Стакан в студию!) Я именно непрогнозируемость задержек и имел ввиду. Кстати, я не думаю, что это критично в любом приложении, но нервов может попортить много. Кстати, управление технологическим процессом я бы такой системе не доверил.

А ты не задумывался, что в ОС типа NT или Линукса вообще нельзя писать реалтаймные задачи? Ведь они в любой момент могут отнять управления. Да и хипы их написаны так что не могут обеспечить гарантированного времени доступа. Так что луче не рассуждать о том что не трогает. Иначе договоримся что ДОС лучшая ОС, так как в ней можно делать риалтайм-задачи.

AVK>>Подумай хотя бы о том что произойдет если базовый класс в одной dll а потомок в другой.

ГВ>Здесь ограничения в самом деле получаются подобными COM-овским. Однако, я не утверждаю (и не буду утверждать), что каждый класс обязан быть подгружаемым компонентом.

Вот она демогогия в чистом виде.

Я бы на твоем месте все же почитал Бокса. Он очень популярно изложил почему нльзя использовть длл + классы С++ для организации компонентов. Там все просто как неучить уроков... просто нет бинарного стандарта на описание, бинарную форму и экспорт класса. Другими словами это решение будет несовместимо не только с другими языками (что важно для компонентных технологий не завязанных на один язык), но и между компиляторами разных производителей.

ГВ>Компоненты — это deployment.

Ага. Т.е. строительство дома — это deployment.

Они ведь там тоже из компонентов все лабают... Это даже не демогогия, это откровенное незнание предмета обсуждения. Ты уж извени.

AVK>>>>Сервисы ты эти как реализовывать будешь?
ГВ>>>Как часть App-сервера и комплект драйверов. Под "сервисами" я имею ввиду сугубо системные аспекты — коммуникации, систему безопасности и т.п.

Вот и подумай, как ты будешь выкручиваться когда сервис должен подключаться к уже имеющейся системе. И о том как потребитель сервиса должен получать информацию о сервисе и взаимодействовать с сервисом? Вот тут-то компонентные технологии и тот самый COM просто незаменимы. Вот тут-то они и дают огромное упрощение реализации (не смотря на свою сложность). А так как используются сервисы куда чаще чем создатся, то время портаченное на их компонентизацию окупается с лихвой. Ну, а .NET это просто следующий шаг, позволяющий понизить сложность реализации этих компонентных архитектур. Несомненно компоненты нужны не везде, но что плохого если без какого то нибыло оверхэда ты получаешь возможность работать с любым экземпляром объекта как с компонентом?

ГВ>То, о чём ты сказал — не самое интересное. Самое интересное, ИМХО, — сохранение состояний интерфейса пользователя между вызовами.

Да... вот это проблема. Глянь на ASP.NET. Там это все не просто решено... там это еще и визуально решено. Ты, кстати, сейчас сидишь на форуме который это дело пользует постоянно. Вот только не ясно как это к разговору отностися.

ГВ>ИМХО, очень хреново, если на верхнем уровне проектирования присутствует разделение понятий Web-интерфейс и Windows-интерфейс. Краткое обоснование я уже приводил.

А ты сам пробывал делать нечто обеспечивающее и то и другое и еще чтобы без уродства и прочих безобразий? Уверен что нет. Так вот логика делится на логику приложения, логику обработки данных и презентационную логику. Последняя в виду сильно разнящихся подходов получатся совершенно разной для Web- и GUI-интерфейса. По-этому, обычно выделяют слой логики, а интерфейсы делают разные.

AVK>>ВОт ты попробуй воплотить свои красивые и правильные идеи в жизнь, а потом и будешь всем тут рассказывать как что и почему. До сих пор все попытки привести веб-интерфейсы к GUI оканчивались печально. Что то получилось у MS с вебформсами, но это еще далековато до реального написания приложения которое будет переключаться прозрачно с веб-интерфейса на GUI. Пока что все ограничивается общим ядром, а интерфейс пишется под гуй отдельно, под веб отдельно.

ГВ>Это можно считать аргументом? Если да, то он неправомерен, поскольку сие — аргумент к коллективу.

А что ты хоть один (по этому поводу) привел?

Ну смотри мои аргументы (выше).

ГВ>Предлагаю постановить, что доводы типа: "а ты попробуй, знаешь как это трудно!" — не котируются

А я тебе предложил бы пропробывать. Тогда охота спорить с совершенно очевидными вещами у тебя отпадет сама собой.

ГВ>..., если не снабжены дополнительными разъяснениями о том, что именно считается трудным. Я во всяком случае на подобные выпады больше отвечать не буду. Понимаешь ли, для меня выражение "трудно, но можно" означает, что я так и сделаю, потому что "можно".

А что для тебя будет аргументом? Он тебе привел доводы, что как минимум скорости работы разные. Уж можно было домыслить, что в условиях низкой скорости и высокой латентности соеденения нужно делать интерфейсы отличные от применяемых в случаях когда нет задержек.

К тому же при создании Web-варианта ты можешь пользоваться мошными функциями реализованными Web-сервером. А в локальном режиме тебе придется все далать вручную или другими методами. Или ты хочешь делать как в анкдоте про кипячение чайника программистом?

ГВ>В корень зришь!

ASP — это не "полная фигня" ни в коем случае, но уже тепло.

Почитай вот это http://forum.ixbt.com/0026/000058.html. Причем сейчас. Потому как если ты гляншь на это лет через 5-10, то вряд ли поймешь в чем хохма.

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

SS>...

Полностью поддержива все сказанные слова...

SS>Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен.

А вот сдесь хочу поспорить. Задачи оптимизации и сейчас временами выжны. Особенно когда делаешь компоненты которые могут использоватся в суровых условиях. Но как раз .NET и даем пеханизм решения таких проблем. Правда не встроенный asm-блок, но можно написать кусок кода на том самом С++ причем там додут и по памяти пройтись и по химичить в доволь. Ну и в крайнем случае есть MSIL. На нем можно все до байта вылезать. Ну, а Jit даст оптимальный код на платформе конечного потребителя.

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

SS>А для более высокого уровня C++ не приспособлен.

Это точно.

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

ГВ>В прикладную логику с подключённой "толстой" интерфейсной прослойкой. То есть, в то, во что она и должна превратиться в этом случае.

Что ты понимаешь под словом "толстой"?

SS>>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
SS>>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

ГВ>Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.

Софистика чистой воды.

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

ГВ>Концептуально — частный случай, фактически — COM и ORB распространены очень широко. Теперь к ним добавляется .NET. Но это ничего не меняет.

Чего? Твоего отношения сложившегося из-за нежелания разобраться в критикуемых тобой технологиях?

ГВ>Да C++-то доживёт. А вот доживёт ли .NET не мутировав во что-то ещё "очень новое" — абсолютно не уверен.

Доживет. Как C и asm. А .NET конечно мутирует. Или сдохнет. Например, ему точно нужна мутация в области дженерик-программирования.

SS>>Тут спор не в синтаксисе языков а в уровне абстракции.

ГВ>Да, только уровень абстракции — человеческая прерогатива. Язык — это просто инструмент. Более или менее удобный. Который тем или иным образом влияет на пользователя. Об том и все эти споры.

Вот ты и даказал своей реализацией делегатов, что С++ хреновый инструмент для реализации абстракций.

Помнишь свое описание метода? Да и переносимость кода доказал замечательно. Иди скомпилируй свой код где-нибудь под Sun-ом.

Тебе не кажется, что твоя реализация просто монстроидальна и что она явно проигрывает тому что было на дремучем С (как по краткости и элегантности, так и по эффективности)?

ГВ>По аналогии с филологической лингвистикой (извини за тавтологию), по отношению к программистской лингвистике можно, ИМХО, постулировать, что язык определяет набор абстракций, которыми человек оперирует при удовлетворении своих интеллектуальных потребностей. Есть только одна закавыка — набор абстракций должен быть инструментом попрождения работающей системы. Вот тебе и связка и переход между "уровнем абстракции человека" и "уровнем абстракции от аппаратуры".

И вот же умеют люди сказать простую фразу, так что ничерта не понятно.

ГВ>Интересно, рефлексия в форумах наверное никогда не прекратится.

Не, ребята, я больше в мыльных операх не участвую.

Гы-гы.

SS>>А для более высокого уровня C++ не приспособлен.

ГВ>А это очень похоже на формулу аутотренинга. Повторять утром и вечером!

Чтобы не подумалось иначе.

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

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

S>Дак и у С++ нет тех недостатков, о которых вы говорите. О тех, которые у него на самом деле есть и жить мешают, все почему-то молчат.
S>Да и говорил я вовсе не о недостатках нета, а о том, что быстродействие много где требуется.

Ты прикидываешься или действительно не понял, что IT тебе говорил о том, что Шарп не медленнее чем С++?

Шустрики — это вот что:

http://rsdn.ru/article/?devtools/perftest.xml
http://rsdn.ru/article/?devtools/perftest2.xml
http://rsdn.ru/article/?devtools/perftest3.xml

S>Дык это смотря как тестировать. Я надеюсь, ты не станешь утверждать, что виртуальные функции вызываются быстрее обычных? Аналогия понятна? Блин, "антишустрика" написать, что ли...

Давай. Только не прибегай к тестированию интеропа. Ты давй на вычислительных задачах... Очем и говорил. А тестировть будем С# супротив VC6 (все же самы распространненный на сегодня... ведь устраивает же его скорость большиство народу).

S>Если серьезной игрушкой считать Quake II, так там даже и плюсами не пахнет. Голимый "пуре Це"

Ну, а Анрыл на С++ написан. Да он вообще на половину на своем встроеном интерпретаторе написан. И почему там вместо него Шарп нельзя использовать?

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

Вот Мишка.Нэт уже пытался это сделать. Может и ты попробуешь? Если удастся без гемороя я тебе $300 подарю.

S>Причем, что характерно, если мне этот код портировать вдруг понадобится, я просто поменяю пару дефайнов и на отличных от винды платформах будет работать все тот же std::stringstream — медленно, но будет. Пока нативный аллокатор не напишу

S>В нете такое практически нереализуемо.

Т.е. в нете условной компиляции нет? Или там нельзя свои классы писать (или от имеющихся наследоваться)?

S>Дело тут может быть только в том, что программист(ы), писавшие эту С++ программу, плохо владели инструментом. Им и правда надо на .Net сваливать.

А мы в отличии от них круты как вареные яйца и неправильных решений не принимаем

!

IT>>Правильно, в правильном дизайне и применении вспомогательных технологий, никак не связанных с самим языком.

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

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

Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.

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

IT>И вся графика ручками написана без всяких DirectX. Или я не прав? Может и не прав, но вот в Doom точно без DirectX обошлись. И что, ты станешь сейчас в неё играть когда уже есть Tournament?

Уже есть Анрыл 2.

IT>Ну вот опять

Я надеюсь ты знаешь кое что об интерфейсах. В дотнете я могу написать свой форматер и передавать данные между стандартными объектами по своему доморощенносму протоколу и всё будет летать. А вот на C++ вместе с COM'ом такого не сделаешь.

Сделаешь. Но пока будешь делать летать это будет.

IT>Да ладно

Всё это мы уже слышали про крутых C++ программеров и даже сами так кричали по всем фидошным эхам в своё время. Но я надеюсь ты не думаешь, что если кто-то был хорошим программером только потому что он писал на C++, и вдруг сразу стал плохим так как начал писать на C#

К разговору на таком уровне Петька был не готов (с)

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

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

S>>Дак и у С++ нет тех недостатков, о которых вы говорите. О тех, которые у него на самом деле есть и жить мешают, все почему-то молчат.
S>>Да и говорил я вовсе не о недостатках нета, а о том, что быстродействие много где требуется.

VD>Ты прикидываешься или действительно не понял, что IT тебе говорил о том, что Шарп не медленнее чем С++?

Это IT и ты не поняли, что я говорил не про C#, а отвечал вот на это:
"Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен."

VD>Шустрики — это вот что:

VD>http://rsdn.ru/article/?devtools/perftest.xml
VD>http://rsdn.ru/article/?devtools/perftest2.xml
VD>http://rsdn.ru/article/?devtools/perftest3.xml

Да знаю я, где твои шустрики лежат.

S>>Дык это смотря как тестировать. Я надеюсь, ты не станешь утверждать, что виртуальные функции вызываются быстрее обычных? Аналогия понятна? Блин, "антишустрика" написать, что ли...

VD>Давай. Только не прибегай к тестированию интеропа. Ты давй на вычислительных задачах... Очем и говорил. А тестировть будем С# супротив VC6 (все же самы распространненный на сегодня... ведь устраивает же его скорость большиство народу).

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

S>>Если серьезной игрушкой считать Quake II, так там даже и плюсами не пахнет. Голимый "пуре Це"

VD>Ну, а Анрыл на С++ написан. Да он вообще на половину на своем встроеном интерпретаторе написан. И почему там вместо него Шарп нельзя использовать?

Я анриловских исходников не видел и про него ничего сказать не могу.

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

VD>

VD>Вот Мишка.Нэт уже пытался это сделать. Может и ты попробуешь? Если удастся без гемороя я тебе $300 подарю.

Маловато будет

Mishka<T> изначально поставил неправильную цель — обеспечить запрет создания некоторых классов не GC-методами. Вот оттуда и геморрой.

S>>Причем, что характерно, если мне этот код портировать вдруг понадобится, я просто поменяю пару дефайнов и на отличных от винды платформах будет работать все тот же std::stringstream — медленно, но будет. Пока нативный аллокатор не напишу

S>>В нете такое практически нереализуемо.

VD>Т.е. в нете условной компиляции нет? Или там нельзя свои классы писать (или от имеющихся наследоваться)?

Аллокатор быстрый, не гарбадж-коллекнутый там не слишком легко сделать

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

Там примитивный код, в жизни такой редко нужен.

VD>Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.

Без шаблонов неизбежны либо повторы кода, либо падение быстродействия (если избегать повторов через делегаты).

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

IT>>>А разве в серьёзных игрушках используется стандартный C++ хип?

S>>Если серьезной игрушкой считать Quake II, так там даже и плюсами не пахнет. Голимый "пуре Це"

IT>И вся графика ручками написана без всяких DirectX. Или я не прав? Может и не прав, но вот в Doom точно без DirectX обошлись. И что, ты станешь сейчас в неё играть когда уже есть Tournament?

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

S>>И при чем тут, собственно, хип? Быстродействие не только от него зависит. C++ кардинально отличается от нетовских языков тем, что в C++ GC или иной способ управления памятью можно реализовать с куда меньшим геморроем, чем в нетовских языках организовать собственное управление памятью. Да и никто не заставляет в C++ всегда пользоваться евойным хипом, при необходимости можно и системные функции подергать. Тормозил у меня, например, std::stringstream — так я написал свой стримбуфер со своим аллокатором, стало просто летать. Причем, что характерно, если мне этот код портировать вдруг понадобится, я просто поменяю пару дефайнов и на отличных от винды платформах будет работать все тот же std::stringstream — медленно, но будет. Пока нативный аллокатор не напишу

S>>В нете такое практически нереализуемо.

IT>Ну вот опять

Я надеюсь ты знаешь кое что об интерфейсах. В дотнете я могу написать свой форматер и передавать данные между стандартными объектами по своему доморощенносму протоколу и всё будет летать. А вот на C++ вместе с COM'ом такого не сделаешь.

Я не совсем понял, о чем ты. Какой форматтер, зачем? Я вообще про выделение памяти и гибкость шаблонов в С++ говорил.

IT>Давай не будем приводить в качестве аргумента частные решения.

А без них одно пустозвонство получается. Про молоко и воду, недетерминированные компьютеры и т.д.

IT>Как я уже говорил всё зависит от дизайна и прямости рук. У меня вообще может возникнуть вполне законный вопрос — а нафига тебе понадобился стримбуфер, неужели нельзя было обойтись без него

А удобно. Объект сериализуется в стандартный стрим — хоть в файл пишется, хоть по сети передается, хоть через COM в виде BSTR, хоть через IStream — код один и тот же, только стримы разные. Или вообще в виде base64 в HTML страницу.

IT>>>Сомневаюсь, наверняка там своя подсистема управления памятью. Что-нибудь подобное придумают и для C#. Т.е всё это приходящее.

S>>Вот именно, приходящее и уходящее. Когда еще придумают то. А работать сейчас надо.

IT>Если ты занимаешься игрушками, то используй C++ и "голимый Це", никто тебя в .NET не тянет. Твоё время пока не пришло

Не, я датамайнингом занимаюсь. И вижу — таки не пришло еще время на шарп пересаживаться.

IT>>>Что же касается полей в базе данных... Был проект написанный на C++ и занимающийся обработкой данных. На один двух-гигабайтный файл уходило до 57 часов. Всё это хозяйство было переписано на C#, время сократилось до 40 минут. В чём дело, спросите вы?

S>>Дело тут может быть только в том, что программист(ы), писавшие эту С++ программу, плохо владели инструментом. Им и правда надо на .Net сваливать.

IT>Опять ты не понял. Ни программисты, ни C++, ни C# тут ни при чём. Парсер был перенесён один в один из C++ в C#.

Ну вот — язык, оказывается, не причем. Тогда к чему было об этом говорить?

IT>Разница была лишь в методе вставки данных в базу данных. Во втором случае использовался BULK INSERT, который сам по себе работает в десятки раз быстрее.

А что мешало его использовать его в программе на С++?

IT>>>Правильно, в правильном дизайне и применении вспомогательных технологий, никак не связанных с самим языком.

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

IT>Да ладно

Всё это мы уже слышали про крутых C++ программеров и даже сами так кричали по всем фидошным эхам в своё время. Но я надеюсь ты не думаешь, что если кто-то был хорошим программером только потому что он писал на C++, и вдруг сразу стал плохим так как начал писать на C#

Нет, конечно.

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

IT>>Ну вот опять

Я надеюсь ты знаешь кое что об интерфейсах. В дотнете я могу написать свой форматер и передавать данные между стандартными объектами по своему доморощенносму протоколу и всё будет летать. А вот на C++ вместе с COM'ом такого не сделаешь.

S>Я не совсем понял, о чем ты. Какой форматтер, зачем? Я вообще про выделение памяти и гибкость шаблонов в С++ говорил.

А я не понял причём тут твой стримбуфер.

IT>>Давай не будем приводить в качестве аргумента частные решения.

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

А с ними только кульные частности, которые всё равно никто проверить не может.

S>Не, я датамайнингом занимаюсь. И вижу — таки не пришло еще время на шарп пересаживаться.

А что это такое, может там шарпу самое место?

IT>>Опять ты не понял. Ни программисты, ни C++, ни C# тут ни при чём. Парсер был перенесён один в один из C++ в C#.

S>Ну вот — язык, оказывается, не причем. Тогда к чему было об этом говорить?

Как раз потому что язык тут не при чём. Твои слова?:

S>Прикинь потребную вычислительную мощь. Жаба/нет тут не катят

Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.

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

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

IT>>>Ну вот опять

Я надеюсь ты знаешь кое что об интерфейсах. В дотнете я могу написать свой форматер и передавать данные между стандартными объектами по своему доморощенносму протоколу и всё будет летать. А вот на C++ вместе с COM'ом такого не сделаешь.

S>>Я не совсем понял, о чем ты. Какой форматтер, зачем? Я вообще про выделение памяти и гибкость шаблонов в С++ говорил.

IT>А я не понял причём тут твой стримбуфер.

Еще раз повторяю — я не понял, о чем ты говоришь, а вовсе не спрашиваю, при чем тут форматтер.

IT>>>Давай не будем приводить в качестве аргумента частные решения.

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

IT>А с ними только кульные частности, которые всё равно никто проверить не может.

Ну давай тогда опять про сферического коня в вакууме... Работа, она из частностей складывается. А насчет проверить — если что-то вызывает сомнения, готов выслать компилябельный кусочек кода. Другое дело — если никто не желает ни верить на слово, ни проверять

S>>Не, я датамайнингом занимаюсь. И вижу — таки не пришло еще время на шарп пересаживаться.

IT>А что это такое, может там шарпу самое место?

Ну, сходи на www.kdnuggets.com, посмотри, почитай.

IT>>>Опять ты не понял. Ни программисты, ни C++, ни C# тут ни при чём. Парсер был перенесён один в один из C++ в C#.

S>>Ну вот — язык, оказывается, не причем. Тогда к чему было об этом говорить?

IT>Как раз потому что язык тут не при чём. Твои слова?:

Ты вроде взялся языки сравнивать?

S>>Прикинь потребную вычислительную мощь. Жаба/нет тут не катят

IT>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.

Насчет того, что .NET ни чуть не медленнее чем C++ код — все зависит от задачи.
Например, есть примерно такой сишный код:

struct A
{
   A(int a, int b) : _a(a), _b(b) {}
   int _a;
   int _b;
   static bool less_by_a(const A &x, const A &y) const
   { return x._a < y._a; }
   bool less_by_b(const A &x, const A &y) const
   { return x._b < y._b; }

....//Куча всяких полезностей, которые на сравнение не влияют
};

struct B : public A
{
   B(int a, int b, int c, int d) : A(a, b), _c(c), _d(d) {}
   int _c;
   int _d;
   bool less_by_d(const B &x, const B &y) const
   { return x._d < y._d; }
....//Куча других полезностей, которые на сравнение тоже не влияют

};

void foo()
{
    std::vector<A> as;
    size_t i;
    const size_t vs = 100000;
    as.reserve(vs);
    for (i = 0; i < vs; ++i)
   .    as.push_back(A(rand(), rand()));
    std::vector<B> bs;
    bs.reserve(vs);
    for (i = 0; i < vs; ++i)
   .    bs.push_back(B(rand(), rand(), rand(), rand()));

   std::sort(as.begin(), as.end(), &A::less_by_a);
   std::sort(as.begin(), as.end(), &A::less_by_b);
   std::sort(bs.begin(), bs.end(), &B::less_by_d);
}

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

Насчет того, что GC работает быстрее чем сишный хип — ты уверен, что это справедливо для любого сишного рантайма и самописных хипов? На любых задачах? Речь вроде не шла о конкретном компиляторе.
И с каких это пор DCOM является единственным средством IPC/RPC/других коммуникаций?

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

IT>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.
Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого. Плюс у ремоутинга гибкость и удобство использования в разы больше.

<<... J 1.0 alpha 4 >>

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

IT>>А с ними только кульные частности, которые всё равно никто проверить не может.

S>Ну давай тогда опять про сферического коня в вакууме... Работа, она из частностей складывается. А насчет проверить — если что-то вызывает сомнения, готов выслать компилябельный кусочек кода. Другое дело — если никто не желает ни верить на слово, ни проверять

Ладно, завязываем с этим, всё равно кроме пререканий ничего не будет.

S>>>Не, я датамайнингом занимаюсь. И вижу — таки не пришло еще время на шарп пересаживаться.

IT>>А что это такое, может там шарпу самое место?

S>Ну, сходи на www.kdnuggets.com, посмотри, почитай.

Что-то я там не нашёл внятного определения

IT>>Как раз потому что язык тут не при чём. Твои слова?:

S>Ты вроде взялся языки сравнивать?

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

S>>>Прикинь потребную вычислительную мощь. Жаба/нет тут не катят

S>Насчет того, что .NET ни чуть не медленнее чем C++ код — все зависит от задачи.
S>Например, есть примерно такой сишный код:

[skip]

S>Вот мне почему то кажется, что на аналоги на нетовских языках будет выполнять foo гораздо медленней. Будет немного свободного времени, обязательно проверю

Проверь. А я хочу проверить так же работу БД провайдеров из C# и C++. Тоже будет интересно. Ты кажется базами занимаешься. Вот и узнаем сколько ты выиграешь на сортировке (если выиграешь) и сколько проиграешь на доступе к базе.

S>Насчет того, что GC работает быстрее чем сишный хип — ты уверен, что это справедливо для любого сишного рантайма и самописных хипов? На любых задачах? Речь вроде не шла о конкретном компиляторе.

Я сравниваю с тем, чем я пользуюсь каждый день и сменить это на что-то другое мне никто не позволит. Виндовый хип, кстати, тоже медленнее работает. Насчёт самописных хипов я ничего не говорил, можно написать такой (и уже написаны), что ему будут никакие GC ни по чём. Только вопрос, чем ты за это платить будешь? Всей памятью твоей машины? А если это сервер и у меня на нём таких задач не одна крутится?

S>И с каких это пор DCOM является единственным средством IPC/RPC/других коммуникаций?

Я явой не пользуюсь, корба как-то тоже на винде не прижилась, а низкоуровневые вещи типа сокетов я не использую по причине — шоли мне больше нечем заняться. Остаётся DCOM, вполне нормальная штука, меня устраивала.

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

S>Это IT и ты не поняли, что я говорил не про C#, а отвечал вот на это:
S>"Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен."

Вообще-то это был не вопрос, а ответ. Подколка, тык сызыть.

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

Ну, это ты зря. Шаблоны в шарпе все равно в ближайшее время появятся. Ты же про вычисления говоришь? Или я тебя не правильно понял?

S>Я анриловских исходников не видел и про него ничего сказать не могу.

Ну, я куски видел. А на интерперетаторе можешь и сам пописать. Открой их редактор, там он почти везде есть.

VD>>Вот Мишка.Нэт уже пытался это сделать. Может и ты попробуешь? Если удастся без гемороя я тебе $300 подарю.

S>Маловато будет

Ладно 350.99

S>Mishka<T> изначально поставил неправильную цель — обеспечить запрет создания некоторых классов не GC-методами. Вот оттуда и геморрой.

Он такой цели не ставил. Ты его статью читал? У него как раз попытка реализации GC средствами C++. Кстит, на VC6 он тоже забил (шаблон слабые...).

VD>>Т.е. в нете условной компиляции нет? Или там нельзя свои классы писать (или от имеющихся наследоваться)?

S>Аллокатор быстрый, не гарбадж-коллекнутый там не слишком легко сделать

Про value-типы слышал? Вот они как раз для оптимизации добавленны. К тому же ты не правильно себе понимаель .NET и возможности MSIL. На том же C# в ансэйф-режиме ты можешь занимать память где угодно и делать с ней что угодно. В том же шустрике есть пример быстрой сортировки на базе указателей.

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

S>Там примитивный код, в жизни такой редко нужен.

В жизни код еще приметивней. Просто его много. Не думаю, что ты каждый день пишишь крутые алгоритмы. По крайней мнер 99 их процентов уже давно написаны.

VD>>Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.

S>Без шаблонов неизбежны либо повторы кода, либо падение быстродействия (если избегать повторов через делегаты).

Тут ты прав. Но, во-первых, не настолько уж он замедляется, и, во-вторых, судя по всему такое положение вещей скоро изменится. Слышал, что для Ротора (CLI) шаблоны уже сделаны и доступны для скачивания?

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

IT>>Как я уже говорил всё зависит от дизайна и прямости рук. У меня вообще может возникнуть вполне законный вопрос — а нафига тебе понадобился стримбуфер, неужели нельзя было обойтись без него

S>А удобно. Объект сериализуется в стандартный стрим — хоть в файл пишется, хоть по сети передается, хоть через COM в виде BSTR, хоть через IStream — код один и тот же, только стримы разные. Или вообще в виде base64 в HTML страницу.

А ты думаешь в нете что-то по другому? Там все тоже самое, тольк проще на порядок возможностей больше (тот-же ремоутинг).

S>Не, я датамайнингом занимаюсь. И вижу — таки не пришло еще время на шарп пересаживаться.

И в чем рельная загвоздка? А с временем оно так... не время... не времяя.. рано еще... ра. Ой поздно!

S>Ну вот — язык, оказывается, не причем. Тогда к чему было об этом говорить?

В том, что при стольк малой разнице в производительности нет смысла говорить о том, что .NET небя сдерживает в этом аспекте. Все равно скорость определит качество твоего кода. А на том же Шарпе под нет намног проще писать качественный код, чем на С++ и врукопашную (естественно если задача не по указателям шарить).

IT>>Разница была лишь в методе вставки данных в базу данных. Во втором случае использовался BULK INSERT, который сам по себе работает в десятки раз быстрее.

S>А что мешало его использовать его в программе на С++?

А ты найди нужый кусок без профайлера, или там где он не пременим.

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

S>Насчет того, что GC работает быстрее чем сишный хип — ты уверен, что это справедливо для любого сишного рантайма и самописных хипов? На любых задачах? Речь вроде не шла о конкретном компиляторе.

Вот смотри! Ты сказал ключевые слова "любого сишного рантайма". Т.е. ты и сам понимаешь, что многие рантаймы могут оказаться менее эффективным.

А пример твой и проверить то тяжело, так как ты рандом используешь. а рандом в .NET и STL разный (я уже не говрю о разных реализациях STL).

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

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

IT>>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.
AVK>Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого. Плюс у ремоутинга гибкость и удобство использования в разы больше.

Первым, кстати, был .NET.

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

IT>>>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.

AVK>>Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого. Плюс у ремоутинга гибкость и удобство использования в разы больше.

VD>Первым, кстати, был .NET.

Откуда такие сведения, Ты проверял уже? Дай посмотреть результаты.

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

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

IT>>>>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.

AVK>>>Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого. Плюс у ремоутинга гибкость и удобство использования в разы больше.

VD>>Первым, кстати, был .NET.

IT>Откуда такие сведения, Ты проверял уже? Дай посмотреть результаты.

Я имею в виду, что AVK сказал "то сравнение будет не в пользу первого", а первым у него был .NET.

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

VD>>>Первым, кстати, был .NET. ;)

IT>>Откуда такие сведения, Ты проверял уже? Дай посмотреть результаты.

VD>Я имею в виду, что AVK сказал "то сравнение будет не в пользу первого", а первым у него был .NET. :)

Ы, ты всё прикалываешься. Мне бы сейчас где-нибудь надыбать нормальное честное сравнение DCOM и Remoting для применения этого хозяйства в борьбе с остатками неверующих, точнее не хотящих и цепляющихся за последнее :)

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

VD>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>В прикладную логику с подключённой "толстой" интерфейсной прослойкой. То есть, в то, во что она и должна превратиться в этом случае.

VD>Что ты понимаешь под словом "толстой"?

Я понимаю под эти словом объём кода, который будет заниматься трансляцией COM-овских соглашений и типов данных в данные и соглашения, принятые при разработке прикладной логики.

SS>>>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
SS>>>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

ГВ>>Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.

VD>Софистика чистой воды.

Почему? Помнишь шуточное правило "всякую программу можно сократить на одну команду"?

Чем больше программа, тем больше вероятность появления в ней "типовых" кусков, с которыми можно бороться либо никак (copy/paste), либо "рыбами" (copy/paste из общего источника), либо выделением их в функции/классы/модули — т.е., запоздалым выделением абстракций, либо — превентивным анализом и структурированием абстракций. Последний вариант — ИМХО, самый разумный как раз в контексте большой программы (ну, или такой программы, от которой ожидается, что она станет большой). C++ как раз и адекватен, поскольку у него, в частности, развиты механизмы комбинирования абстракций и средства оптимизации (inline).

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

Ну, только не передёргивай, я говорил о том, что а) COM — не единственный в своём роде способ реализации компонентного подхода к deployment; б) соглашения COM устанавливают очень неприятные и глупые ограничения для программистов на C++; в) что нет необходимости каждый класс программы делать компонентом в смысле компонентов/объектов COM/CORBA; г) что нет нужды ради "компонентизации" корёжить хороший язык C++.

Теперь о том, о чём "речь не о том"

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

В твоих словах сквозит попытка смешать понятия "COM" (или "CLR"?) и "компонентные технологии вообще". Поправь меня, если я ошибаюсь. Если же нет, тогда скажу, что хотя в каком-то контексте такое смешение и возможно (особенно — в контексте маркетингового оболванивания), но не в даннном споре (я не позволю

).

Это — неправомерное смешение понятий. Конкретно, смешивается концепция ("компоненты") и конкретная спецификация (COM).

И ещё. Объясни, плиз., что именно я с трудом могу объяснить?

ГВ>>Концептуально — частный случай, фактически — COM и ORB распространены очень широко. Теперь к ним добавляется .NET. Но это ничего не меняет.

VD>Чего? Твоего отношения сложившегося из-за нежелания разобраться в критикуемых тобой технологиях?

Нет, не только моего мнения. Это не меняет того, что COM/ORB/.NET/<вписать> являются частными случаями реализации компонентного (модульного с описанными выше расширениями) подхода.

ГВ>>Да C++-то доживёт. А вот доживёт ли .NET не мутировав во что-то ещё "очень новое" — абсолютно не уверен.

VD>Доживет. Как C и asm. А .NET конечно мутирует. Или сдохнет. Например, ему точно нужна мутация в области дженерик-программирования.

Ну вот, мутирует, там и посмотрим

Только, ИМХО, он ещё и в плане рантайма мутировать будет. То-то веселуха начнётся с бинарной совместимостью.

Впрочем, последнее — злостный стёб. Ничего архисложного в JIT-компиляции старого кода в новый нет.

SS>>>Тут спор не в синтаксисе языков а в уровне абстракции.

ГВ>>Да, только уровень абстракции — человеческая прерогатива. Язык — это просто инструмент. Более или менее удобный. Который тем или иным образом влияет на пользователя. Об том и все эти споры.

VD>Вот ты и даказал своей реализацией делегатов, что С++ хреновый инструмент для реализации абстракций.

Помнишь свое описание метода? Да и переносимость кода доказал замечательно. Иди скомпилируй свой код где-нибудь под Sun-ом.

Интересно ты выводы делаешь

Ты мне говорил, что аналога делегатов C# на C++ сделать нельзя, я предметно доказал обратное. ИМХО, доказав гибкость C++ как инструментального средства. Реализацию можно сделать и по-другому, вопросов нет. Можешь сам этим заняться, если интересно.

Мне лично — уже нет, по причинам, изложенным чуть ниже. Кстати, об "описании метода". Я думаю, что если бы ты почитал реальное описание того, как работает CLR — то выводов класса "ужас", "монстр" и т.п. сделал бы ещё больше.

У меня тут появилась замечательная мысль, которая ускользала на протяжении всех этих баталий. А на хрена в C++ вообще делегаты с евентами нужны? Всё, что можно сделать делегатами/евентами зашибись как решается интерфейсом с единственным методом, принимающим объект-сообщение нужного типа плюс множественным наследованием объекта-приёмника от нужного набора таких интерфейсов (можно — с частичной реализацией оных). От ипостаси "евентов" как от варианта диспетчера сообщений никуда не денешься, но зачем тянуть за собой процедурно-ориентированный интерфейс? Это же совсем не объектный стиль в принципе!

То есть, оцени прикол: я что-то доказываю тебе, ты — мне, тогда как сам по себе объект обсуждения выбран некорректно!

Если слегка перефразировать твоё высказывание, то это не "C++ — хреновый инструмент", абстракция хреновая.

Так что, признаюсь, что кое в чём я сам повёлся на удочку.

И, кстати, теперь я чуть больше, чем раньше согласен с теми высказываниями, которые сопоставляют C# и "чистый" C. Он-таки на самом деле близок к C!

VD>Тебе не кажется, что твоя реализация просто монстроидальна и что она явно проигрывает тому что было на дремучем С (как по краткости и элегантности, так и по эффективности)?

Нет проблем — можно поманипулировать с регистрами, можно и от типобезопасности избавиться. Только я этого делать не буду. Если считать void* верхом достижения программистской мысли, то это не есть правильное считание.

ГВ>>По аналогии с филологической лингвистикой (извини за тавтологию), по отношению к программистской лингвистике можно, ИМХО, постулировать, что язык определяет набор абстракций, которыми человек оперирует при удовлетворении своих интеллектуальных потребностей. Есть только одна закавыка — набор абстракций должен быть инструментом попрождения работающей системы. Вот тебе и связка и переход между "уровнем абстракции человека" и "уровнем абстракции от аппаратуры".

VD>И вот же умеют люди сказать простую фразу, так что ничерта не понятно.

Ну, перечитай ещё раз.

А если без стёба, то сформулируй вопрос — отвечу.

ГВ>>Интересно, рефлексия в форумах наверное никогда не прекратится.

Не, ребята, я больше в мыльных операх не участвую.

VD>Гы-гы.
Banzai!

SS>>>А для более высокого уровня C++ не приспособлен.

ГВ>>А это очень похоже на формулу аутотренинга. Повторять утром и вечером!

Чтобы не подумалось иначе.

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

Да, я понимаю, что здесь мне не тут.

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

IT>>>>>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.
1 — DCOM, 2 -Remoting
Так что гонишь ты все.

VD>Я имею в виду, что AVK сказал "то сравнение будет не в пользу первого", а первым у него был .NET.

<<... J 1.0 alpha 4 >>

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

S>>Это IT и ты не поняли, что я говорил не про C#, а отвечал вот на это:
S>>"Я тоже с ностальгией вспоминаю времена, когда сидя в DOC на Borland C++ 2.0, поковыряв программу в TurboProfiler, можно было сделать умное выражение лица, написать asm{..}, поднапрячь интелект, решив сложную комбинаторную задачу, по хитрому соптимизировать какую нибудь сортировку,распихать по регистрам, ... и с чувством глубокого удовлетворения наблюдать как прога стала "летать". Теперь такой уровень ни кому не нужен."

VD>Вообще-то это был не вопрос, а ответ. Подколка, тык сызыть.

Я типа повелся

Ну не согласен я с тем, что быстродействие сейчас лишним стало.

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

VD>Ну, это ты зря. Шаблоны в шарпе все равно в ближайшее время появятся. Ты же про вычисления говоришь? Или я тебя не правильно понял?

Вот когда появятся, тогда и можно будет их обсудить.

VD>>>Вот Мишка.Нэт уже пытался это сделать. Может и ты попробуешь? Если удастся без гемороя я тебе $300 подарю.

S>>Маловато будет

VD>Ладно 350.99

Тебя готовый (из gcc выдеру) не устроит?

S>>Mishka<T> изначально поставил неправильную цель — обеспечить запрет создания некоторых классов не GC-методами. Вот оттуда и геморрой.

VD>Он такой цели не ставил. Ты его статью читал? У него как раз попытка реализации GC средствами C++. Кстит, на VC6 он тоже забил (шаблон слабые...).

Он перед статьей в форуме трепался на эту тему. И цель такая ставилась. Когда с ней облом вышел, видать и GC писать расхотелось

S>>Аллокатор быстрый, не гарбадж-коллекнутый там не слишком легко сделать

VD>Про value-типы слышал? Вот они как раз для оптимизации добавленны. К тому же ты не правильно себе понимаель .NET и возможности MSIL. На том же C# в ансэйф-режиме ты можешь занимать память где угодно и делать с ней что угодно. В том же шустрике есть пример быстрой сортировки на базе указателей.

Ну а переходы safe-unsafe, надо полагать, бесплатные? А что касаемо value-типов, так классы ими вроде быть не могут? А от структур наследовать нельзя. Вот и выходит геморроя поболее, чем в С++.

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

S>>Там примитивный код, в жизни такой редко нужен.

VD>В жизни код еще приметивней. Просто его много. Не думаю, что ты каждый день пишишь крутые алгоритмы. По крайней мнер 99 их процентов уже давно написаны.

Я не про крутые алгоритмы. Я про иерархии классов, с экземплярами которых приходится работать. Короче, value-типы обычно не катят. И, кстати, 90% из тех 99 алгоритмов, что уже написаны, нахаляву никто не раздает.

VD>>>Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.

Мне — сложнее. Появятся шаблоны, посмотрим.

S>>Без шаблонов неизбежны либо повторы кода, либо падение быстродействия (если избегать повторов через делегаты).

VD>Тут ты прав. Но, во-первых, не настолько уж он замедляется, и, во-вторых, судя по всему такое положение вещей скоро изменится. Слышал, что для Ротора (CLI) шаблоны уже сделаны и доступны для скачивания?

Их кто-то умеет компилировать? Или самому язык писать придется?

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

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

S>>Насчет того, что GC работает быстрее чем сишный хип — ты уверен, что это справедливо для любого сишного рантайма и самописных хипов? На любых задачах? Речь вроде не шла о конкретном компиляторе.

VD>Вот смотри! Ты сказал ключевые слова "любого сишного рантайма". Т.е. ты и сам понимаешь, что многие рантаймы могут оказаться менее эффективным.

Так само собой. Реализаций C++ куча (в отличие от NET), некоторые из них вполне могут быть левой ногой писаны.

VD>А пример твой и проверить то тяжело, так как ты рандом используешь. а рандом в .NET и STL разный (я уже не говрю о разных реализациях STL).

Ну выкинь этот rand нафиг, числа заранее подготовь. Главное, чтоб наследование было и массивы переменного размера, а сами объекты достаточно мелкие.

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

IT>Ы, ты всё прикалываешься. Мне бы сейчас где-нибудь надыбать нормальное честное сравнение DCOM и Remoting для применения этого хозяйства в борьбе с остатками неверующих, точнее не хотящих и цепляющихся за последнее

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

Так вот, а для DCOM есть COM+. Скоро выйдет 1.5-шка под Windows.NET Srv. Там туева хуча полезных вещей. Делать тоже самое под дотнэт прсто самоубийство. Так что я бы еще рассмотрел дотнэт-фрэймворк в качестве клиента и сервер для COM+. Ну и естественно сравнил бы это дело с ремоутенгом и вэб-сервисами. Причем сравнил бы как функционально, так и по скоростным характеристикам.

Кстати, нам сейчас нужны статьи. А из этого может получиться хорошая статья. Может займешся, а я AVK и другие тебе поможем (как советом, так и делом).

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

VD>Боюсь у твоих аппонентов есть серьезный козырь. Под дотнэт нет ни одного сервера приложений. Ну, разве что IIS. Но сам пониаешь он применим только для вэба.

Это я в курсе

VD>Так вот, а для DCOM есть COM+. Скоро выйдет 1.5-шка под Windows.NET Srv. Там туева хуча полезных вещей. Делать тоже самое под дотнэт прсто самоубийство. Так что я бы еще рассмотрел дотнэт-фрэймворк в качестве клиента и сервер для COM+. Ну и естественно сравнил бы это дело с ремоутенгом и вэб-сервисами. Причем сравнил бы как функционально, так и по скоростным характеристикам.

Тем не менее насчёт удобства это как посмотреть. Комплюсовые компоненты нужно будет ещё деплоить, да и отлаживать их сложнее, к тому же чтобы передать, допустим массив байт, нужно постараться.

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

Останется только админа попинать, чтобы он порт открыл такой какой ему админу больше нравится.

VD>Кстати, нам сейчас нужны статьи. А из этого может получиться хорошая статья. Может займешся, а я AVK и другие тебе поможем (как советом, так и делом).

С удовольсьвием, только видимо во второй номер не поспею, видишь сайт глюкает, поиск отвалился...

ЗЫ. Хлопчик этот которому нужно pdf на сайт передать COM'а в глаза не видел. Я ему как-то пытался азы растолковать, только время потерял. Веб-сервисы он взял за пару дней, а ремотиг может ещё за три. Вот такие пироги. А апликейшин сервер... да пока он как-то и на фиг не нужен, пишем свои сервисы и в них всё что надо хостим. Хотя я конечно от него бы не отказался.

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

IT>С удовольсьвием, только видимо во второй номер не поспею, видишь сайт глюкает, поиск отвалился...

Давай. Ремоутинг вариант я напишу. Только для начала нужно определиться что и как тестировать будем.

IT>ЗЫ. Хлопчик этот которому нужно pdf на сайт передать COM'а в глаза не видел. Я ему как-то пытался азы растолковать, только время потерял. Веб-сервисы он взял за пару дней, а ремотиг может ещё за три.
Не, ремоутинг все же заметно посложнее сервисов. Хотя конечно если не заморачиваться то можно и за 3 дня. А копать там глубоко можно. Я до сих пор некоторых вещей не понимаю, хотя с ремоутингом довольно много ковыряюсь. С веб сервисами намного проще, хотя и возможности не те совсем.

IT> Вот такие пироги. А апликейшин сервер... да пока он как-то и на фиг не нужен, пишем свои сервисы и в них всё что надо хостим. Хотя я конечно от него бы не отказался.
Я думаю родные апп-сервера должны появиться. Тот же Борланд наверняка не упустит возможность, тем более что политика MS в этом плане какая то невнятная.

<<... J 1.0 alpha 5 >>

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

IT>>С удовольсьвием, только видимо во второй номер не поспею, видишь сайт глюкает, поиск отвалился...

AVK>Давай. Ремоутинг вариант я напишу. Только для начала нужно определиться что и как тестировать будем.

А сколько у нас времени есть?

AVK>Не, ремоутинг все же заметно посложнее сервисов. Хотя конечно если не заморачиваться то можно и за 3 дня. А копать там глубоко можно. Я до сих пор некоторых вещей не понимаю, хотя с ремоутингом довольно много ковыряюсь. С веб сервисами намного проще, хотя и возможности не те совсем.

Сложнее и копать там много, но начать применять хоть как-то довольно легко.

AVK>Я думаю родные апп-сервера должны появиться. Тот же Борланд наверняка не упустит возможность, тем более что политика MS в этом плане какая то невнятная.

То-то и оно. Причём никакой информации от MS

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

IT>Сложнее и копать там много, но начать применять хоть как-то довольно легко.
Вот только эти заморочки с метаданными удаленных объектов. Никакой внятной политики. Они сами в документации нигде на эту тему не высказались. В сервисах wsdl есть, а тут ничего подобного.

AVK>>Я думаю родные апп-сервера должны появиться. Тот же Борланд наверняка не упустит возможность, тем более что политика MS в этом плане какая то невнятная.

IT>То-то и оно. Причём никакой информации от MS

Это ответы Девида Чаппела с www.gotdotnet.ru

==============================================
Вопрос: Как Вы считаете, как долго COM/COM+ будет использоваться для построения бизнес-приложений?

Ответ: COM и COM+ — это не одно и тоже, так что ответ зависит от того, что Вы имеете в виду. Службы COM+ доступны в .NET Framework под названием "Enterprise Services", так что они без сомнения будут использоваться. Стандартный COM, в то же время, не используется для новых .NET Framework приложений. Как только Framework станет выбором по умолчанию для разработки Windows приложений, роль COM и LOB приложений будет существенно снижена.
==============================================

Вот так — ничего в общем то и не сказал.

<<... J 1.0 alpha 5 >>

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

ГВ>Я понимаю под эти словом объём кода, который будет заниматься трансляцией COM-овских соглашений и типов данных в данные и соглашения, принятые при разработке прикладной логики.

Т.е. ты утверждаешь, что объем кода самого большого броузера меньше чем самого маленького ком-клиента?

Или считаешь что на вызов ком-объекта нужны какие-то немереные затраты? Или считаешь что в какой-либо технологии эти затраты меньше? И почему ты счтаешь, что комовские типы нельзя использовать без трансляции для описания прикладной логики? В конце концов VB6 весь постоен на комовских типах, но тем неменее как нельзя лучше подходит для описания той самой прикладной логики.

SS>>>>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
SS>>>>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

ГВ>>>Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.

VD>>Софистика чистой воды.

ГВ>Почему?

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

ГВ>...запоздалым выделением абстракций, либо — превентивным анализом и структурированием абстракций. Последний вариант — ИМХО, самый разумный как раз в контексте большой программы (ну, или такой программы, от которой ожидается, что она станет большой).

Понимаю... нефть ищите... (с). Вот только один вопрос! К чему ты все это говоришь? Тебе был задан конкретный вопрос: "...реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET". Ты же ответил на другой. И сейчас пытаешся доказать свою правоту.

Пойми, никто с тобой не будет спорить о том, что крамотная декомпозиция это одна из важных составляющих успеха в программировании. Но это здесь было вообще не причем. На Шарпе и Яве абстракции делаются ни чуть не хуже чем на С++. Конечно отсутствие шаблонов в некоторых случаях приводит к менее эффективному коду и к лишним рантайм-проверкам (отсуствие которых может привести к некорректному поведению), но в других областях Шарп и Ява делают С++ как катенка.

Вот тебе пример... Реализуй на С++ контейнер содержащий заранее не известные типы. И ты увидишь всю слабость обычного С++. Он ведь умее или контролировать типы только на стадии компиляции. Тебе ридется городить море кода производящего боксинг простых типов и структур в конструкции типа VARIANT (хронящии некое описание хранимого типа и ссылку на экземпляр). Или привести все к указателю на void переложив заботу о типах с компилятора на конечного программисто (того что будет использовать твой контейнер). Многие перепрограммировшие на С++ скажут, что в этом нет ничего страшного. Подумаешь нужно подумать... А я скажу, что это то место где идеологически зараждаются ошибки. Причем ошибки трудноуловимые.

В Шарпе это решается за счет 100%-ой типизации ссылок и автоматического боксинга. В этом языке ты можешь привести любую переменную к ссылке на абстрактный объект, а потом привести указатель обратно. Причем при обратном преобразовании будет произведен контроль приведения типов и ты получишь нечто похожее на проверку типов в С++, но не на стадии компиляции, а на стадии выполнения.

Безусловно такая проверка медленнее чем ее аналог сделанный в период компиляции и наличие шаблонов резко упросило бы дело. Но все в компайл-тайме не проверишь. А С++ практически лишен рантайм проверок (только динамик_каст, но он очень ограничен). Кстати, в MC++ динамик_каст резко расширил свои возможности. Это заслуга рантайма .NET.

ГВ>C++ как раз и адекватен, поскольку у него, в частности, развиты механизмы комбинирования абстракций и средства оптимизации (inline).

То что эти заявления безосновательны тебе уже говорили. Но ты никого не слышиш.

1. inline — это наследие уродливого прошлого. Инлайнинг функций — это самое мошьное средство оптимизации, но им должен управлять не человек, а компилятор. Легко доказывается простыми тестами с автоинлайнингом и хорошими скоростными показателями .NET и Явы.

Комбирирование абстракций в Шарпе не просто развито. Она перешло на качественно новый уровень. Там разговор идет в терминах коллекций, объектов и ссылок между ними, а не на уровне байтов и битов к которому тяготеет С++. Да реализация местами является не столь эффективной по сравнению с тем что можно достичь на С++ с использованием шаблонов. Но качественная реализация на С++ это нетривиальная работа. Сделать ее может не каждый, да и самые крутые программисты из-за больших объемов работы плюют на оптимальность алгоритмов и вибырают более "легкие" решения. А они в разы проигрываю тем универсальным решениям применяемых в Яве и Шарпе.

В конце концов есть только три алгоритма хранения множества: массив, связанный список и хэш-таблица. Остальные (и даже дерево) являются разнаыидностями и реализуются на этих базовых приметивах. В Шарпе и Яве программист с первых шагов приучается их использовать. А в С++ уровень разработки, за частую не дает программисту подняться над мелочами и осознать, что вот здесь нужно использовать хэшь-таблицу, а вот здесь связанный список, а здесь динамический массив. В большинстве реализаций STL хэшь-таблица вообще отсуствует, а писать свою многие просто не могут или нехотят. Отдельная проблема хэш-функции. В той же Яве и .NET любой объект имеет дефолтную реализацию хэшь функции которую можно легко заменить на собственную.

ГВ>Ну, только не передёргивай, я говорил о том, что а) COM — не единственный в своём роде способ реализации компонентного подхода к deployment;

Тебе уже сказали, что компоненты к деплойменту отностся так же как классы или методы. И сказали, что на С++ нет ни одного промышленного аналога COM (имеющего те же возможности).

ГВ>б) соглашения COM устанавливают очень неприятные и глупые ограничения для программистов на C++;

А кто виноват? В С++ нет ни одной потуги к той самой компонентности. Вот и приходится создавать упрощенную модель. Так чтобы она подходила ко всем компиляторам и всем языкам.

ГВ>в) что нет необходимости каждый класс программы делать компонентом в смысле компонентов/объектов COM/CORBA; г) что нет нужды ради "компонентизации" корёжить хороший язык C++.

Хреновый язык. Тебе уже не раз показывали вещи которые нельзя сделать на С++Ю, которые приводят на нем к повышенной опастности или неадекватным задаче размерам кода. Ты же долдонишь одно и тоже не приводия аргументов. Вернее приводя, но против своих же выводов.

Я тебя уже спрашивал: "Что плохого если без сущесвенного оверхеда ты получишь возможность работать с любым объектом как с компонентом?". В ответ "нет необходимости каждый класс"... Несерьезно.

ГВ>Теперь о том, о чём "речь не о том"

. Речь как раз о привлекательности C++ потому что а) язык позволяет очень глубоко структурировать программу

Согласен! Но 90% других языков позволяет структурировать программу как минимум не хуже чем С++. А то же Шарп иногда и лучше. И внось в ответ безпочвенные заявления являющиеся слествием того, что ты влюблен в С++ и не хочешь смотреть вокруг.

ГВ>..., что в контексте неоспоримого довода о важности декомпозиции и проектировании выглядит очень привлекательным;

И опять же тебе уже на слабо говорят, что большинство выбравших Яву и Шарп выберают эти языки/платформы в виду того, что проектирование на них в разы проще чем на С++. И опять в ответ расказ о правильности проектирования перед кодированием...

ГВ> б) этого никогда не позволят "компонентные технологии"

Т.е. они не позволят проектировать и структурировать програмы.

ГВ>, базирующиеся на унификации языковой модели; в) он очень привлекателен как средство "работающей" реализации сложных идей.

Да на нем и простые идеи иногда сложно реализовать. А сложные идеи можно и на асм-е реализовывать. Так что это просто демогогия. Безосновательные выводы и итверждения апелирующие к чувствам и эмоциям.

ГВ>В твоих словах сквозит попытка смешать понятия "COM" (или "CLR"?) и "компонентные технологии вообще".

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

ГВ>Поправь меня, если я ошибаюсь.

Поправил.

ГВ> Если же нет, тогда скажу, что хотя в каком-то контексте такое смешение и возможно (особенно — в контексте маркетингового оболванивания)

Во. Сново демогогия! Так кто из нас занимается оболваниваением?

ГВ>, но не в даннном споре (я не позволю

).

Это — неправомерное смешение понятий. Конкретно, смешивается концепция ("компоненты") и конкретная спецификация (COM).

Ты хоть сам то понял, что сказал?

ГВ>И ещё. Объясни, плиз., что именно я с трудом могу объяснить?

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

VD>>Чего? Твоего отношения сложившегося из-за нежелания разобраться в критикуемых тобой технологиях?

ГВ>Нет, не только моего мнения. Это не меняет того, что COM/ORB/.NET/<вписать> являются частными случаями реализации компонентного (модульного с описанными выше расширениями) подхода.

А что кто-то утверждал обратное? Я только утверждаю, что С++ не содержит ни грамма возможностей облегчающий работу в рантайме и тем самым разработку компонентных технологий. И я так же утверждаю, что подход избранный в .NET (забота о рантайме и учитывание этого фактора при проектировании и рантайма, и зыков) является верным и дает свои плоды.

VD>>Доживет. Как C и asm. А .NET конечно мутирует. Или сдохнет. Например, ему точно нужна мутация в области дженерик-программирования.

ГВ>Ну вот, мутирует, там и посмотрим

Только, ИМХО, он ещё и в плане рантайма мутировать будет. То-то веселуха начнётся с бинарной совместимостью.

Опять же, не нужна она там. Там промежуточный язык есть и система контроля версий. Просто на одной машине будут жить две разные версии рантайма. И старые программы будут работать со старым, а новые...

ГВ>Впрочем, последнее — злостный стёб. Ничего архисложного в JIT-компиляции старого кода в новый нет.

Да и не нужно это делать.

VD>>Вот ты и даказал своей реализацией делегатов, что С++ хреновый инструмент для реализации абстракций.

Помнишь свое описание метода? Да и переносимость кода доказал замечательно. Иди скомпилируй свой код где-нибудь под Sun-ом.

ГВ>Интересно ты выводы делаешь

Да когда вижу можре нечитаемого кода который не может скомпилировать 80% компиляторов, то как-то выводы направшиваются сами собой. Мой код почему-то и на Интеле и на борланде компилируется, хотя в принципе это и не ружно.

ГВ> Ты мне говорил, что аналога делегатов C# на C++ сделать нельзя, я предметно доказал обратное.

Вот жаль, толко аналога не вышло и код твой комплируется только на Интеле.

ГВ>ИМХО, доказав гибкость C++ как инструментального средства.

Уродство это, а не доказательство. Ты сделал самы приметивный вариант использовв конструкции которые еще не появились в половине компиляторов и все равно создал море кода, да еще вынуждающего делать декларации методов размером со страницу.

Нам такой хоккей не нужен.

А ведь твои делегаты грохнутся даже при вызове между потоками, а чтобы сделать вызов между процессами тебе нужно будет создать подобие собственного кода, а это уже такая гора кода что в нем можно захлебнуться. Но нужно это в большинстве современных программ, и совершенно непонятно, почему нельзя расширить возможности сзяка, ну хотя бы чтобы такие возможности можно было делать меньшей кровью. Я тебе уже сто раз коворил, что в С — это делалось двумя строчками кода и было 100% типобезопастно. В С++ такое нагромождение является следствие неправильного дизайна языка, а вернее ошибкой в проектировании. Нужо было вместо уродских указателей на методы класса, противоречащих кононам ООП сделаь сдвоеный указатель указывающий на объект и на метод, ну и естественно сделать их как и в С независимыми от конкретного класса... совпадает сигнатура — значит можно вызвать. Ты же нечинаешь разводить демогогию о стройности языка. Чем решение изложенное мной менее стройно чем придуманное Страуструпом? Да в амбициях последнего и не желании признавать свои ошибки!

ГВ> Реализацию можно сделать и по-другому, вопросов нет. Можешь сам этим заняться, если интересно.

Ухе не интересно. Для мнея С++ — это низкоуровневый язык предназраченый для всякого рода хаков и совместимости с кодом времет эры С/С++.

ГВ>Мне лично — уже нет, по причинам, изложенным чуть ниже. Кстати, об "описании метода". Я думаю, что если бы ты почитал реальное описание того, как работает CLR — то выводов класса "ужас", "монстр" и т.п. сделал бы ещё больше.

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

ГВ>У меня тут появилась замечательная мысль, которая ускользала на протяжении всех этих баталий. А на хрена в C++ вообще делегаты с евентами нужны? Всё, что можно сделать делегатами/евентами зашибись как решается интерфейсом с единственным методом

Вот и подумай сколько тебе нужно будет прадить липовых наследований из-за пустекового дела решаемого в С одной строкой кода.

Достаточно просто сравнить количество кода...

ГВ>..., принимающим объект-сообщение нужного типа плюс множественным наследованием объекта-приёмника от нужного набора таких интерфейсов (можно — с частичной реализацией оных). От ипостаси "евентов" как от варианта диспетчера сообщений никуда не денешься, но зачем тянуть за собой процедурно-ориентированный интерфейс?

Он более чем ОО-ый.

ГВ> Это же совсем не объектный стиль в принципе!

Это удобный, краткий и эффективный метод. И не менее ОО, чем наследование.

ГВ>То есть, оцени прикол: я что-то доказываю тебе, ты — мне, тогда как сам по себе объект обсуждения выбран некорректно!

Можешь посмотреть на Яву. Она решает проблему событий (неизбежную в современном мире) очень похожим образом. Но для простоты они ввели вложенные классы имеющие ссылку на родителя. Получатеся проще чем на С++ но все рвано криво и громоздко. Когда сравнивешь код Явы и .NET, то сразу тановится все ясно.

На С++ я лично для себя нашел еще более банальное и довольно эффективное решение:

template<class T>
struct Base
{
protected:
   void Fire()
   {
      T * pT = (T*)this;
      pT->Event1();
   }
};

struct MyClass : Base<MyClass>
{
public:
  void Event1()
  { ... }
};

Решение более удобное чем интерфейсы, но имеющее недостоток. Нелья динамически подключиться к событиям дугого объекта. Ну, а с интерфесами, можно и так, но неудобно. Что мелало сдалать нормальные указатели на ОО-функции?

ГВ>И, кстати, теперь я чуть больше, чем раньше согласен с теми высказываниями, которые сопоставляют C# и "чистый" C. Он-таки на самом деле близок к C!

Вот ты ёрничаешь, я на практике ощутил насколько подход старого С проще и удобнее. В новой реинкорнации он позволяет прозрачно вызыватать удаленные методы и круппировать вызовы в одном контейнере (делегате). Вывод — это проще, удобнее, эффективнее и любые слова не поменяют этого расклада. Про использование иттерфейсов я тебе говорил с самого начала, и в самом начале объяснил почему это неудобно.

VD>>Тебе не кажется, что твоя реализация просто монстроидальна и что она явно проигрывает тому что было на дремучем С (как по краткости и элегантности, так и по эффективности)?

ГВ>Нет проблем — можно поманипулировать с регистрами, можно и от типобезопасности избавиться. Только я этого делать не буду. Если считать void* верхом достижения программистской мысли, то это не есть правильное считание.

Ну, и кто из нас передергивает? Думаю ты прекрасно меня понял.

ГВ>Ну, перечитай ещё раз.

А если без стёба, то сформулируй вопрос — отвечу.

Уже устал. Ты все равно отвечаешь на другие вопросы... которые я не задовал.

ГВ>>>Интересно, рефлексия в форумах наверное никогда не прекратится.

Не, ребята, я больше в мыльных операх не участвую.

VD>>Гы-гы.
ГВ>Banzai!

Ну, в общем действительно я тоже подустал.

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

VD>>Я имею в виду, что AVK сказал "то сравнение будет не в пользу первого", а первым у него был .NET.

Цитирую:

IT>>Так вот я и хочу тебе сказать, что .NET ни чуть не медленнее чем C++ код, GC работает быстрее чем сишный хип, осталось только сравнить DCOM и Remoting.
AVK>Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого. Плюс у ремоутинга гибкость и удобство использования в разы больше.

Здесть это легкто читаеться как:

Я думаю что если использовать TcpChannel и BinaryFormatter то сравнение будет не в пользу первого (.NET — он же первый встречается). Плюс у ремоутинга гибкость и удобство использования в разы больше.

Когда много сущьностей лучше выделять нужную отдельно.

PS

Но это я так... прикалывался.

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

S>Ну не согласен я с тем, что быстродействие сейчас лишним стало.

Дык и я нет. Но до маньячества то доводить зачем? Там не если и есть просад производительности, то совершенно линейный (на проценты, а не в разы). Да и связан он в основном с тремя вещеми:

1. Отсуствие дженерик-программирвания. Уже сейчас частично решается на МС++. В Версии 2 скорее всего шаблоны введут в язык и CLR.

2. Интероп со старым кодом. Если задача связана с частым дерганьем интеропа, то есть только одно решение МС++. Но во многих случаях можно вообще обойтись без обращения к анменэджет коду, ну или сократить эти обращения до не критичного минимума.

3.Не полный набор оптимзаций. Это вообще временное явление. При должном упорстве можно добиться большей оптимизации за счет использования информации о конкретной системе.

S>Вот когда появятся, тогда и можно будет их обсудить.

Ротор видел? К нему уже патч есть. Три мега и шаблоны в твоем распоряжении.

S>Тебя готовый (из gcc выдеру) не устроит?

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

VD>>Он такой цели не ставил. Ты его статью читал? У него как раз попытка реализации GC средствами C++. Кстит, на VC6 он тоже забил (шаблон слабые...).

S>Он перед статьей в форуме трепался на эту тему. И цель такая ставилась. Когда с ней облом вышел, видать и GC писать расхотелось

Ну, прочти статью... там все предельно ясно... пока дело до кода не доходит.

S>>>Аллокатор быстрый, не гарбадж-коллекнутый там не слишком легко сделать

VD>>Про value-типы слышал? Вот они как раз для оптимизации добавленны. К тому же ты не правильно себе понимаель .NET и возможности MSIL. На том же C# в ансэйф-режиме ты можешь занимать память где угодно и делать с ней что угодно. В том же шустрике есть пример быстрой сортировки на базе указателей.

S>Ну а переходы safe-unsafe, надо полагать, бесплатные?

Приводят к копированию пиннутых данных. Но сам переход ничего не стоит. В МС++ все можно обойтись без пинов и скорость такая же как при работе на обычном VC. Я сам проверял... писал отрисовку контрола на С++.

S>А что касаемо value-типов, так классы ими вроде быть не могут? А от структур наследовать нельзя. Вот и выходит геморроя поболее, чем в С++.

Зато их можно вкладывать друг в друга.

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

Дык а скорость то кода как от этого зависит? Ну, вон терерь весь сайт на C# и что? Этот проект маленький что ли? И все работает.

S>Короче, value-типы обычно не катят. И, кстати, 90% из тех 99 алгоритмов, что уже написаны, нахаляву никто не раздает.

Да в общем они почти все в стандарных библиотеках .NET и Явы.

VD>>>>Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.

S>Мне — сложнее. Появятся шаблоны, посмотрим.

Можешь уже попробыать на Роторе.

S>Их кто-то умеет компилировать? Или самому язык писать придется?

Умеет компилировать C#-компилятор из CLI и Jit-омпилятор от туда же.

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

S>Ну выкинь этот rand нафиг, числа заранее подготовь. Главное, чтоб наследование было и массивы переменного размера, а сами объекты достаточно мелкие.

Сейчас нет времени, но позже обязательно попробую. Пример я твой уже отложил.

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

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

Останется только админа попинать, чтобы он порт открыл такой какой ему админу больше нравится.

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

IT>С удовольсьвием, только видимо во второй номер не поспею, видишь сайт глюкает, поиск отвалился...

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

IT>ЗЫ. Хлопчик этот которому нужно pdf на сайт передать COM'а в глаза не видел. Я ему как-то пытался азы растолковать, только время потерял. Веб-сервисы он взял за пару дней, а ремотиг может ещё за три. Вот такие пироги. А апликейшин сервер... да пока он как-то и на фиг не нужен, пишем свои сервисы и в них всё что надо хостим. Хотя я конечно от него бы не отказался.

Ну, вот когда начнешь ядро с ком-а снимать, вот тогда раскажишь...

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

IT>А сколько у нас времени есть?

Ну, 2-е недели точно. Нам нужно еще Клиент-Сервер сдать.

IT>Сложнее и копать там много, но начать применять хоть как-то довольно легко.

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

IT>То-то и оно. Причём никакой информации от MS

К сожалению информация есть. И она говрит перебьетес COM+-ом 1.5.

Первой нетовской ласточкой будет следующий релиз SQL Server-а. В него вместо Явы запихнут .Net. На нем и увидем как это будет выглядеть. Может другого сервера приложений и не понадобится.

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

AVK>Вот так — ничего в общем то и не сказал.

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

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

IT>>А сколько у нас времени есть?

VD>Ну, 2-е недели точно. Нам нужно еще Клиент-Сервер сдать.

Тогда ок.

IT>>Сложнее и копать там много, но начать применять хоть как-то довольно легко.

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

Ну ты сравнил. За три дня начала применения COM ты откомпилируешь разве что пару примеров, да позапускаешь визард. Потом ещё неделю будешь репу чесать и решать надо оно тебе или не надо. Я же говорю о том что человек (правда уже хорошо знакомый с .NET) просто разобрал пару примеров и начал писать вполне рабочие задачи, не задумываясь о том что такое QueryInterface, AddRef, Release и какие его ждут глюки в будущем при неправильном применении этой святой троицы.

IT>>То-то и оно. Причём никакой информации от MS

VD>К сожалению информация есть. И она говрит перебьетес COM+-ом 1.5.

Тогда потестируем ещё и .NET внутри COM+. А шо делать?

VD>Первой нетовской ласточкой будет следующий релиз SQL Server-а. В него вместо Явы запихнут .Net. На нем и увидем как это будет выглядеть. Может другого сервера приложений и не понадобится.

А разве в него Ява уже запихана? Или ты про Оракл?
Не думаю что это будет хороший сервер приложений, он заточен совсем под другое. К тому же как раз этому зверю я бы меньше всего доверил хостить объекты, данные важнее. При всей надёжности CLR мне бы не хотелось их терять из-за какого-нибудь нерадивого компонента. А для SP и UDF это как раз самое оно.

Я думаю так. Если MS не сделает нормальный сервер приложений в ближайшем будущем, то его сделает кто-то другой, благо исходные коды ремотинга есть. В данном случае ситуация кардинально отличается от случая с COM+. Возможно, что это будет и какой-нибудь открытый проект

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

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

Да, скорее всего так и будет. Причем проект такой будет не один. Если для COM+ это сложно, мало информации, да и часть сервером MS поставляет бесплатно то для ремоутинга он оставил сладкий кусочек пирога, я не верю что никто не соблазниться.

... << J 1.0 alpha 5 >>

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

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

S>>Ну не согласен я с тем, что быстродействие сейчас лишним стало.

VD>Дык и я нет. Но до маньячества то доводить зачем? Там не если и есть просад производительности, то совершенно линейный (на проценты, а не в разы).

Вот насчет процентов я пока не уверен. Кое-где, скорее всего, в разы.

VD>Да и связан он в основном с тремя вещеми:

VD>1. Отсуствие дженерик-программирвания. Уже сейчас частично решается на МС++. В Версии 2 скорее всего шаблоны введут в язык и CLR.

Вот только глядя на то, как MS за уже четыре года не удосожилось к VC нормальную поддержку шаблонов прикрутить, я не очень верю, что в CLR будут приличные шаблоны. Скорее всего, опять говнище редкостное сваяют.

VD>2. Интероп со старым кодом. Если задача связана с частым дерганьем интеропа, то есть только одно решение МС++. Но во многих случаях можно вообще обойтись без обращения к анменэджет коду, ну или сократить эти обращения до не критичного минимума.

Это фигня, критичным быть не должно. Никто не собирается из нового кода isalpha дергать.

VD>3.Не полный набор оптимзаций. Это вообще временное явление. При должном упорстве можно добиться большей оптимизации за счет использования информации о конкретной системе.

Оптимизация — это вообще мелочи. А вот запрет наследования для value-типов — это уже серьезно.

S>>Вот когда появятся, тогда и можно будет их обсудить.

VD>Ротор видел? К нему уже патч есть. Три мега и шаблоны в твоем распоряжении.

И чем они компиляются, если не секрет?

S>>Тебя готовый (из gcc выдеру) не устроит?

VD>Если он встроин в компилятор, то нет. А если как классы/шаблон совместимые с другими компилятрами и если все будет так же удобно и шустро как на менеджет языках, то может и устроит.

Он встороен в компилятор, поскольку этим компялятором "для себя" используется. Впрочем, гугель говорит, что этот же самый GC и отдельно доступен — даже выдирать ничего не надо : http://www.hpl.hp.com/personal/Hans_Boehm/gc

VD>>>Он такой цели не ставил. Ты его статью читал? У него как раз попытка реализации GC средствами C++. Кстит, на VC6 он тоже забил (шаблон слабые...).

S>>Он перед статьей в форуме трепался на эту тему. И цель такая ставилась. Когда с ней облом вышел, видать и GC писать расхотелось

VD>Ну, прочти статью... там все предельно ясно... пока дело до кода не доходит.

Да читал я эту статью, успокойся. Даже критику писал

S>>>>Аллокатор быстрый, не гарбадж-коллекнутый там не слишком легко сделать

VD>>>Про value-типы слышал? Вот они как раз для оптимизации добавленны. К тому же ты не правильно себе понимаель .NET и возможности MSIL. На том же C# в ансэйф-режиме ты можешь занимать память где угодно и делать с ней что угодно. В том же шустрике есть пример быстрой сортировки на базе указателей.

S>>Ну а переходы safe-unsafe, надо полагать, бесплатные?

VD>Приводят к копированию пиннутых данных. Но сам переход ничего не стоит. В МС++ все можно обойтись без пинов и скорость такая же как при работе на обычном VC. Я сам проверял... писал отрисовку контрола на С++.

Мы ж про кастом мемори аллокаторы говорим, так? И какой мне прок память в ансэйфе выделять, если при переходе в сэйф она копироваться будет?

S>>А что касаемо value-типов, так классы ими вроде быть не могут? А от структур наследовать нельзя. Вот и выходит геморроя поболее, чем в С++.

VD>Зато их можно вкладывать друг в друга.

Тоже выход, но уж больно убого.

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

VD>Дык а скорость то кода как от этого зависит? Ну, вон терерь весь сайт на C# и что? Этот проект маленький что ли? И все работает.

Форумы тормозят изрядно.

S>>Короче, value-типы обычно не катят. И, кстати, 90% из тех 99 алгоритмов, что уже написаны, нахаляву никто не раздает.

VD>Да в общем они почти все в стандарных библиотеках .NET и Явы.

Блин, ну ткни меня носом в исходники реализации алгоритма SMACOF... Или хоть что-нибудь готовое для multi dimensional scaling.
Я нигде не нашел, хотя он, безусловно, написан. Вот и придется самому писать, похоже.

VD>>>>>Ну, тогда задумайся хоть над тем, что на Шарпе просто проще писать "хороший" код.

S>>Мне — сложнее. Появятся шаблоны, посмотрим.

VD>Можешь уже попробыать на Роторе.

Забыл написать — возможность размещать полноценные объекты на стеке тоже хочу, и чтоб деструкторы для них были и сами вызывались.

S>>Их кто-то умеет компилировать? Или самому язык писать придется?

VD>Умеет компилировать C#-компилятор из CLI и Jit-омпилятор от туда же.

Ок, посмотрим че они там сваяли.

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

AVK>Да, скорее всего так и будет. Причем проект такой будет не один. Если для COM+ это сложно, мало информации, да и часть сервером MS поставляет бесплатно то для ремоутинга он оставил сладкий кусочек пирога, я не верю что никто не соблазниться.

Дык, давай доделывай быстрее Янус, я пока баги на сайте почищу и будем соблазняться

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

IT>Дык, давай доделывай быстрее Янус, я пока баги на сайте почищу и будем соблазняться

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

<<... J 1.0 alpha 5 >>

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

IT>Ну ты сравнил. За три дня начала применения COM ты откомпилируешь разве что пару примеров, да позапускаешь визард. Потом ещё неделю будешь репу чесать и решать надо оно тебе или не надо. Я же говорю о том что человек (правда уже хорошо знакомый с .NET) просто разобрал пару примеров и начал писать вполне рабочие задачи, не задумываясь о том что такое QueryInterface, AddRef, Release и какие его ждут глюки в будущем при неправильном применении этой святой троицы.

А ты возьми VB6 и все резко упростится. Ну и для смеха на МС++ примерчик с ремоутингом наклепай.

IT>А разве в него Ява уже запихана? Или ты про Оракл?

Был тут как-то пресрелиз от MS... что мол встроили Яву... и ее можно использовать как язык для триггеров.

IT>Не думаю что это будет хороший сервер приложений, он заточен совсем под другое.

Интересно подочто?

IT> К тому же как раз этому зверю я бы меньше всего доверил хостить объекты, данные важнее. При всей надёжности CLR мне бы не хотелось их терять из-за какого-нибудь нерадивого компонента. А для SP и UDF это как раз самое оно.

Ну и Ява и .Нет в сэйф-рижиме для данных безопастны. Так что это суеверие.

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

Ему придется конкурировать с тем же COM+. И боюсь что конкуренцию он проигает. Ну, как Mono по сравнению с CLI.

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

S>Вот насчет процентов я пока не уверен. Кое-где, скорее всего, в разы.

А ты не свмневайся, а проверяй.

S>Вот только глядя на то, как MS за уже четыре года не удосожилось к VC нормальную поддержку шаблонов прикрутить, я не очень верю, что в CLR будут приличные шаблоны. Скорее всего, опять говнище редкостное сваяют.

Меня утраивают шаблоны даже от древнего VC6. Остальное это для любитилей нечитаемых награмождений. Ну, а на счет .NET-а... дык скачай себе CLI и апдэйт и погляди. Наворотов там нет, но все просто красиво и эффективно.

VD>>2. Интероп со старым кодом. Если задача связана с частым дерганьем интеропа, то есть только одно решение МС++. Но во многих случаях можно вообще обойтись без обращения к анменэджет коду, ну или сократить эти обращения до не критичного минимума.

S>Это фигня, критичным быть не должно. Никто не собирается из нового кода isalpha дергать.

Ну-ну.

VD>>3.Не полный набор оптимзаций. Это вообще временное явление. При должном упорстве можно добиться большей оптимизации за счет использования информации о конкретной системе.

S>Оптимизация — это вообще мелочи. А вот запрет наследования для value-типов — это уже серьезно.

И как "запрет наследования для value-типов" может повлиять на производительность? А оптимизации конечно мелоч. Но без того же автоинлайнинга прогаммы в несколько раз медленне получаются.

VD>>Ротор видел? К нему уже патч есть. Три мега и шаблоны в твоем распоряжении.

S>И чем они компиляются, если не секрет?

Что компилируют? CLI с добавленными шаблонами? Дык или VC7 или gcc (за второе не отвечу, а семеркой сам компилировал).

А может ты на счет компиляции кода с шаблонами для CLI? Тогда тем самым пропатчены CLI компилятором C#-а.

S>Он встороен в компилятор

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

S>, поскольку этим компялятором "для себя" используется. Впрочем, гугель говорит, что этот же самый GC и отдельно доступен — даже выдирать ничего не надо : http://www.hpl.hp.com/personal/Hans_Boehm/gc

Ты бы хоть глянул чего суешь.

Там С++-ом и не пахнет. Все на голом С. Замечательное поддтверждение моих слов, что С++ для этой работы не гадится. Все статические проверки типов идут под нож. Ну и нужно еще глянуть удобство использования этого дела и производительность. На первый взгляд ужасная гора низкоуровнего кода и нечитабельный пример для С++.

S>Мы ж про кастом мемори аллокаторы говорим, так? И какой мне прок память в ансэйфе выделять, если при переходе в сэйф она копироваться будет?

Мы вообще-то говорили о твоем заявлении что мол переход сэйв-ансейв дико дорог. Я тебе объяснил, что это не так, да и делать это не нужно обычно.

S>Тоже выход, но уж больно убого.

В общем даже приучает к грамтной структуризации. Все же в Шарпе нужно помнить, что структура нужна только там где она даст выигрышь в скорости. Твой пример я бы писал без структур. Сортировать быстрее указатели.

S>Форумы тормозят изрядно.

И что я не замечаею? Может у тебя с Инетом проблемы?

VD>>Да в общем они почти все в стандарных библиотеках .NET и Явы.

S>Блин, ну ткни меня носом в исходники реализации алгоритма SMACOF... Или хоть что-нибудь готовое для multi dimensional scaling.

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

S>Я нигде не нашел, хотя он, безусловно, написан. Вот и придется самому писать, похоже.

Забавнее, то что в 80% реализации STL нет таких простых вщей как хэш-таблины.

S>Забыл написать — возможность размещать полноценные объекты на стеке тоже хочу, и чтоб деструкторы для них были и сами вызывались.

Да пофигу где размещаются объекты. Главное чтобы создавались быстро. А деструкторы для стековых обхектов... я бы тоже не отказался. Но тут приходится выбирать. Дикая сложность С++-ного кода все равно перевешивает все недостатки Шарпа. С++ является прекрасным языком подержки, но как основной на сегодня оне уже не катит. Его нужно серьезно лечить. Причем куда серьезнее, чем Шарп. Проблемы шарпа можно перечесть на пальцах, а вот плюсы переходят в нишу С и асм-а.

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

IT>>Ну ты сравнил. За три дня начала применения COM ты откомпилируешь разве что пару примеров, да позапускаешь визард. Потом ещё неделю будешь репу чесать и решать надо оно тебе или не надо. Я же говорю о том что человек (правда уже хорошо знакомый с .NET) просто разобрал пару примеров и начал писать вполне рабочие задачи, не задумываясь о том что такое QueryInterface, AddRef, Release и какие его ждут глюки в будущем при неправильном применении этой святой троицы.

VD>А ты возьми VB6 и все резко упростится. Ну и для смеха на МС++ примерчик с ремоутингом наклепай.

Не, на MC++ мне статью наваять хватило по самое нихачу. Я в те времена ещё тоже C# за язык не считал, правда уже начинал сомневаться.

Насчёт VB, хлопчик этот о котором я говорил как раз большой специалист по нему был. Сейчас вот любит C#, задачку эту он действительно лихо так забацал, и теперь любители C++ ходят репу чешут и пальцы уже так сильно у них не загибаются. Последний аргумент у них остался — типа мол DCOM это reliable. Я им растолковываю что мол, пацаны, you just confuse some terminology, it's not reliable, it's archaic

IT>>А разве в него Ява уже запихана? Или ты про Оракл?

VD>Был тут как-то пресрелиз от MS... что мол встроили Яву... и ее можно использовать как язык для триггеров.

Не знаю такого. Про Оракл слышал, про MS SQL нет.

IT>>Не думаю что это будет хороший сервер приложений, он заточен совсем под другое.

VD>Интересно подочто?

Под обработку данных. Ты сам знаешь, что всё что он умеет делать на 5 с плюсом — это молотить SQL запросы. Курсоры у него уже получаются с трудом на троечку, а UDF можно использовать если только в ней не делать ничего сложнее 2*2. И в том что он умеет делать хорошо ему лучше не мешать. Кто знает как он себя поведёт если ты начнёшь у него из нутри туда сюда файлы разные открывать, многозадачность свою лепить... У него даже доспут к дискам сделан своим особым образом и по чёрному завязан на NT. Нет уж, мне данные важнее.

VD>Ну и Ява и .Нет в сэйф-рижиме для данных безопастны. Так что это суеверие.

Не спорю, даже согласен на 99.9%. Но одна десятая всё же остаётся

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

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

VD>Ему придется конкурировать с тем же COM+. И боюсь что конкуренцию он проигает. Ну, как Mono по сравнению с CLI.

Так дело не в том кто выиграет, а самом процессе

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

VD>Ему придется конкурировать с тем же COM+. И боюсь что конкуренцию он проигает. Ну, как Mono по сравнению с CLI.

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

<<... J 1.0 alpha 5 >>

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

Извини, что долго молчал.

VD>Здравствуйте Геннадий Васильев, Вы писали:

AVK>>>В джаве есть аналоги примитивных типов но классы, и вот преобразования туда и оттуда это просто так. В С++ тоже самое. А вот дотнет в этом отношении намного лучше — любой тип может быть приведен к object.
ГВ>>Софистика и демагогия чистой воды. Например, в C++ преобразования "туда и оттуда" совсем не аналогичны Javа, сам это прекрасно знаешь. И чем в данном случае .NET намного лучше? Вообще — как это всё логически связано?
VD>Ну, ты бы хоть показал в чем тут демогоия/софистика? А то внешне выглядит как раз что это от тебя исходят рассуждения основанные на неверных предпосылках.

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

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

"В джаве есть аналоги... преобразования ...просто так". Не сомневаюсь ни капли. Object-to-object. А вот в C++ всё обстоит немного "не так". Преобразование простой тип — сложный тип является частным случаем любого преобразования типов и может включать в себя как генерацию нового экземпляра сложного типа, так и наоборот — проебразование сложного типа к простому, элементарному. Однако, далее неясно, на основании чего делается вывод о преимуществах дотнет в этом отношении. Любой тип в дотнет может быть приведён к object. OK. согласен. Но почему это лучше модели преобразований в C++? Дотнет по определению — система с одиночным наследованием, т.е., — все типы производны от System.Object. А чем же это лучше? Вот это как раз и есть очень спорный момент, который подаётся как бесспорный. Ничего неясно, но высказывание производит впечатление логически связного за счёт сравнительных наречий. А на мой взгляд — больше похоже на танка (стихи такие японские

). Потому я и назвал это софистикой и демагогией.

Я сам нередко грешу недоговорённостями, просто нередко получаются очень длинными.

Хочется сократить.

VD>Вот тебе код на Шарпе:

Я пронумеровал здесь отдельные моменты

VD>

VD>int i = 123;
VD>object o = i;
VD>double d = (double)o; // Здесь в рантайме будет исключение (1)
VD>Write(d);
VD>

VD>А вот аналог на С++:
VD>

VD>int i = 123;
VD>void * o = &i;
VD>double & d = *((double*)o); (2)
VD>Write(d); // Здесь в рантайме будет проход по памяти :)
VD>

Здесь (2) ты приводишь пример очевидно паршивого стиля программирования, от которого советовали шарахаться ещё на C. Иными словами, доказываешь только то, что с "кривыми руками" (это ни в коем случае не наезд на твою квалификацию, а комментарий к примеру) на C++ можно наделать чёрт-те чего. Ну да, можно, хотя этот же механизм очень неплохо работает в ситуациях, когда он прикрывается сильно типизованной надстройкой. У Элджера, кстати, были примеры таких реализаций.

Что же касается примера на C#, то он тоже не играет на руку популярности C#. В точке (1) вылетит исключение, но только в рантайме, поскольку компилятор a'priori не сможет делать предположений о типе данных. Поиск ошибок, возникающих только в рантайме — сам знаешь насколько нетривиальное занятие. ИМХО, наиболее надёжный способ борьбы с ним — статическая типизация. Ото всех ошибок не спасёт, конечно, но... Вот и C++, если ему не заткнуть рот явно (как это сделано в твоём примере), будет горланить как минимум предупреждения при некоторых опасных преобразованиях. Притом произойдёт это на этапе трансляции, а не в рантайме. Следовательно — хоть частично, но тестирование упростится, чего не происходит в случае C#.

То есть, фактически, свои примером ты сказал следующее — на C++ можно сделать глупость, а на C# — тоже можно сделать глупость. На C# она может быть будет обнаружена в run-time (если тестирование пройдёт эту ветку).

VD>Теперь о том о чем говорил AVK...
VD>Если приметивный тип является объектом, то можно писать код проверяющий тип объекта и делающий те или иные действия в зависимости от результаотв проверки. Код приведенный мною выше как раз демонстрирует такую возможность в C# и отстуствие такой возможности в С++. Идем дальше...

Проблема в том, что таких проверок для надёжности придётся делать много (посмотри, например, реализации метода IDispatch::Invoke). А постоянные проверки типа объекта попросту сведут на нет сильные стороны .NET (извини за каламбур

) в части производительности. По этому я очень скептически отношусь к победным реляциям о том, что C# вот-вот догонит C++ по скорости. Он никогда его не догонит при существующей языковой модели. Здесь можно привести контрдовод о том, что C# предоставляет механизмы типизации и это правда, но при этом у него нет очень большого куска того что есть в C++ по части композиций. Ну, я уже много разорялся на эту тему, так что не буду повторяться.

К чему я клоню? Вы тут носитесь (у меня просто другого термина нет) с расписыванием преимуществ рантайм-определения типа, но забываете, ИМХО, о главном. Об истории.

Не правда ли, забавный довод? О том, что на самом деле такой подход отлично реализовывался на чистом C. Ну что стоит сделать у структуры поле "int type;" и гонять в рантайме анализ этого поля? Да того и стоит, что в итоге падает производительность. Именно за счёт строгой типизации C++ и выигрывал какие-то сравнения с C, хотя, в принципе, должен быть более медленным (виртуальные функции, конструкторы/деструкторы...). Просто вычислительный процесс направляется сразу в нужное русло, не отвлекаясь на распознавание типов. Естественно, что для этого требуется несколько иная подготовка разработчиков, чем для реализации наивного if(ptr -> type == my_type) {...}. Собственно, как я понимаю, отсюда-то и пошли разговоры о "трудности ОО-программирования" и всякая подобная дребедень.

В итоге получается, что C# ближе к процедурному языку программирования, чем к объектному. Так какой же этого выигрыш (в контексте больших систем)? ИМХО — никакой.

VD>C++:
VD>

VD>void Write(...) { }
VD>

VD>С#
VD>

VD>void Write(ParamArray object[] pa) { } // Точно синтаксиса не помню, но что-то в этом духе
VD>

Ну да, аналог эклипсиса.

VD>В С++ такая функция невозможно так как нет информации ни о количестве параметров, ни их типах. Отсюда и раждается уродливый printf и его ошибки типа printf("%d", DoubleVar). И что характерно никакие шаблоны не спасут. Хваленая типобезапастность првращается на поверку в полную опастность.

Ты снова совершаешь ошибку, смешивая понятия.

Нет, даже две ошибки — смешиваешь понятия и неправомерно обобщаешь. C++ и предлагаемая им концепция програмирования, и "генетически порочная" по сравнению с ним библиотека, перетянутая из C совместимости ради — совсем не одно и тоже. Кстати, эклипсис тоже не стоит часто использовать в программах на C++. Если говорить применительно к твоему примеру, то для языка C функция printf — это очень простой и прямолинейный способ решения задачи форматирования элементарных данных. Но на C++ возможна гора и других способов, притом достаточно несложно реализуемых и типобезопасных. iostream и перекрытые операторы "<<" и ">>" — один из возможных выходов, не более того, не надо привязываться к ним, как к абсолюту. (Иллюстрации ради скажу тебе, что я и сам неоднократно писал библиотеки форматирования.) Соответственно, на C++ функцию форматирования аналогичную показанной тобою написать можно, и даже сделать её типобезопасной — тоже можно. Если возникнет необходимость поступать именно так.

Кстати, задумайся о том, сколько тебе придётся лопатить и где, если потребуется изменить способ форматирования данных? А если их будет два, три, десять? Хороший пример — форматирование даты.

Ну, ещё прикинь о композиционных сложностях, возникающих при использовании printf, да и вообще — любой функции с переменным числом аргументов. Замечу "на полях", что нет никакой проблемы в том, чтобы передать в функцию переменное число аргументов через const std::vector<object*>& или const std::vector<IUnknownPtr>&. Только зачем это?

Собственно, из первого ошибочного довода плавно вытекла ошибка в рассуждении: шаблоны здесь действительно не спасут, поскольку они только не используются для работы с функцией printf (за исключением каких-то частных случаев), но и вообще противоречат способам решения, предусматривающим слабую типизацию. Так что это — попытка обобщить проблему библиотеки (и самого языка) C на язык C++. Улавиливаешь? Приводимые тобой примеры — примеры "нерекомендуемого" подхода, т.е., такого, который можно использовать только семь раз отмеряв.

VD>В C# каждый парамет ссылка на базовый класс обжект которая имеет полное самоописание в рантайме. Это позволяет реализовать printf так printf("{0}", DoubleVar). Внутри метода мы будем иметь массив (тоже самоописываемый) с известным количеством элементов содержащий нужные парамтры. Так как параметры типизированы (хотя и в рантайме) отподает нужда указывать тпм черз %х, а параметр можно использовать внутри описания несколько раз printf("{0} ... {0}", DoubleVar) (ноль в данном случае номер параметра).

Да, да, да!

Ты продолжаешь доказывать тезис, альтернатив которому не приемлешь.

Тезис о необходимости производства всех типов от Object, кстати (и это самая главная моя претензия) — не приводишь никакого рационального его обоснования. Это, кстати, называеся фанатизмом. А там где фанатизм — там... И снова, это не наезд на тебя, а логический вывод. Оснований для него уже более чем достаточно. В предыдущих рассуждениях ты пытался доказать преимущества C# над C++ апеллируя к C. Иначе как фанатизмом подобное искажение восприятия, ИМХО, вызвано быть не может.

VD>Теперь о боксинге. Если параметр не является экземпляром класса, то в языках типа С++ и Явы его нужно запоковать в класс-обертку которая будет предоставлять описание вложенного типа. Вот такая запаковка и распаковка называется боксингом и анбоксингом. Она есть и в Яве и в С++ (просто потому, что это делается вручную). Шарп же делает такую запаковку автоматически и программист может рассуждать в терминах чистой абстракции не задумываяс является ли переменная ссылкой на класс, примитивом или структурой.

Да...

Это уже самозамкнутые доводы пошли.

Если параметр не является экземпляром класса, то по крайней мере в C++ это означает, что он и должен быть таким. Зачем его превращать в класс? Если же он должен быть экземпляром класса, то нет никакой проблемы в том, чтобы создать этот экземпляр из любого элементарного типа (если, конечно, сам класс предусматривает такую операцию). Твой довод строится, ИМХО, на уверенности в том, что все или почти все элементы программы должны быть физически подобны классам, к тому же — самоописываемым. Только здесь всегда возникает вопрос: зачем? Там где самоописания — там же и огромный оверхед на их обработку.

Складывается впечатление, что ты чистым искусством занимаешься!

Я-то довольно быстро начал всё сводить к надёжности и построению систем (получив свою порцию обвинений в обобщениях), и всё о быстродействии, да о надёжности впариваю — как о рациональных характеристиках ПО. Просто я не ожидал, что приётся объяснять такие простые вещи, вот и начал дискуссию (она у нас уже не только по этой ветке идёт

) с вопросов о языковой модели, поскольку а) полагал, что важность характеристик надёжности и быстродействия — не последняя и б) C++, ИМХО, предоставляет очень развитый и гармоничный набор способов управления абстракциями как инструментов для достижения тех самых производительности и надёжности. Поскольку человеку по отношению к сложным системам, ИМХО, всегда проще манипулировать абстракциями, а не конкретикой, то C++ как раз очень удачен в этом смысле, как инструмент.

VD>Так что это твои предпосылки неверны, а стало быть именно ты занимаешся софистикой.

Сильно сказано.

Особенно, если учесть, что в твоих доводах логические ошибки в исходных посылках, ИМХО, просто одна на одной.

ГВ>>С твоей точки зрения — "больше решает", с моей — "больше создаёт". Частичное подтверждение моей точки зрения я нашёл в твоих словах ниже о непредсказуемости задержек.

VD>Вот это уже форменная демогогия. Какое поддтверждение? Вырвал из контекста... и сделал подтверждением.

Отнюдь. Высказывание AndrewVK содержало вполне оформленный и законченный тезис о непредсказуемости задержек GC, с которым я и согласился, основываясь, кстати, далеко не только на его словах.

AVK>>>Естественно, у них же vtbl нету. Структура она и есть структура. Кусок памяти просто.
ГВ>>Обрати внимание не терминологию — она сугубо "сишная". Это просто наблюдение...
VD>А ты хотел чтобы она была какая? Оба языка произошли от С и структуры взяли от туда же. Причем я бы даже сказал, что С# их взял намного ближе к оригиналу.

Я специально намекнул, а ты не понял.

C++ отошёл от C с прагматическими целями (модульность, кстати, одна из них), сознательно сохранив совместимость с последним. Тогда как C# в каком-то смысле решительно двинулся назад, "к предкам"

У него тоже прагматичные цели — обеспечить прибыли Microsoft. Не самые плохие в этом мире цели, надо сказать, и вполне достойные уважения, но зачем же позволять себя оболванивать? Я не против MS самой по себе, нехай только делает нормальные языки и компиляторы.

ГВ>>Про realtime-системы совершенно согласен. (Стакан в студию!) Я именно непрогнозируемость задержек и имел ввиду. Кстати, я не думаю, что это критично в любом приложении, но нервов может попортить много. Кстати, управление технологическим процессом я бы такой системе не доверил.

VD>А ты не задумывался, что в ОС типа NT или Линукса вообще нельзя писать реалтаймные задачи? Ведь они в любой момент могут отнять управления. Да и хипы их написаны так что не могут обеспечить гарантированного времени доступа. Так что луче не рассуждать о том что не трогает. Иначе договоримся что ДОС лучшая ОС, так как в ней можно делать риалтайм-задачи.

Рискую нарваться на насмешки, но не так давно проскакивало, что DOS-таки действительно пользуется любовью реалтаймщиков именно в силу того, что она позволяет полностью контролировать компьютер. А на NT некоторые реалтаймные задачи делать можно, хотя и очень осторожно. В идеале, конечно, ИМХО, DOS — не самый худший выбор.

AVK>>>Подумай хотя бы о том что произойдет если базовый класс в одной dll а потомок в другой.
ГВ>>Здесь ограничения в самом деле получаются подобными COM-овским. Однако, я не утверждаю (и не буду утверждать), что каждый класс обязан быть подгружаемым компонентом.
VD>Вот она демогогия в чистом виде.

Я бы на твоем месте все же почитал Бокса. Он очень популярно изложил почему нльзя использовть длл + классы С++ для организации компонентов. Там все просто как неучить уроков... просто нет бинарного стандарта на описание, бинарную форму и экспорт класса. Другими словами это решение будет несовместимо не только с другими языками (что важно для компонентных технологий не завязанных на один язык), но и между компиляторами разных производителей.
ГВ>>Компоненты — это deployment.
VD>Ага. Т.е. строительство дома — это deployment.

Они ведь там тоже из компонентов все лабают... Это даже не демогогия, это откровенное незнание предмета обсуждения. Ты уж извени.

Извинияю. Но аналогия неверная, так что — аргумент и обвинение отклоняю. Строительство дома из компонентов — строительство по фиксированному проекту, обеспечивающее повторяемость вополщения одного проекта. По одному проекту могут быть построены сотни домов, а разработка софта — это как раз разработка того самого проекта. Или ты предлагаешь каждую копию как дом строить?

Так что, извини...

AVK>>>>>Сервисы ты эти как реализовывать будешь?
ГВ>>>>Как часть App-сервера и комплект драйверов. Под "сервисами" я имею ввиду сугубо системные аспекты — коммуникации, систему безопасности и т.п.
VD>Вот и подумай, как ты будешь выкручиваться когда сервис должен подключаться к уже имеющейся системе. И о том как потребитель сервиса должен получать информацию о сервисе и взаимодействовать с сервисом? Вот тут-то компонентные технологии и тот самый COM просто незаменимы. Вот тут-то они и дают огромное упрощение реализации (не смотря на свою сложность). А так как используются сервисы куда чаще чем создатся, то время портаченное на их компонентизацию окупается с лихвой. Ну, а .NET это просто следующий шаг, позволяющий понизить сложность реализации этих компонентных архитектур. Несомненно компоненты нужны не везде, но что плохого если без какого то нибыло оверхэда ты получаешь возможность работать с любым экземпляром объекта как с компонентом?

Про оверхеды я уже писал выше. Так что, насчёт "без какого бы то ни было" — не верю абсолютно. Относительно снижения сложности реализации... да, согласен, но ценой отсутствия выбора для тех, кто плотно западает на .NET. ИМХО — высокая цена. Очень высокая.

ГВ>>То, о чём ты сказал — не самое интересное. Самое интересное, ИМХО, — сохранение состояний интерфейса пользователя между вызовами.
VD>Да... вот это проблема. Глянь на ASP.NET. Там это все не просто решено... там это еще и визуально решено. Ты, кстати, сейчас сидишь на форуме который это дело пользует постоянно. Вот только не ясно как это к разговору отностися.

Я только охарактеризовал её интересность, а не сложность/невозможность решения. К дальнейшему разговору это относится очень даже косвенно.

ГВ>>ИМХО, очень хреново, если на верхнем уровне проектирования присутствует разделение понятий Web-интерфейс и Windows-интерфейс. Краткое обоснование я уже приводил.
VD>А ты сам пробывал делать нечто обеспечивающее и то и другое и еще чтобы без уродства и прочих безобразий? Уверен что нет. Так вот логика делится на логику приложения, логику обработки данных и презентационную логику. Последняя в виду сильно разнящихся подходов получатся совершенно разной для Web- и GUI-интерфейса. По-этому, обычно выделяют слой логики, а интерфейсы делают разные.

Отлично.

Интерфейсы делают разные, но прикладную-то логику оставляют одной и той же! Дальше, к сожалению, приходится цитировать полностью:

AVK>>>ВОт ты попробуй воплотить свои красивые и правильные идеи в жизнь, а потом и будешь всем тут рассказывать как что и почему. До сих пор все попытки привести веб-интерфейсы к GUI оканчивались печально. Что то получилось у MS с вебформсами, но это еще далековато до реального написания приложения которое будет переключаться прозрачно с веб-интерфейса на GUI. Пока что все ограничивается общим ядром, а интерфейс пишется под гуй отдельно, под веб отдельно.
ГВ>>Это можно считать аргументом? Если да, то он неправомерен, поскольку сие — аргумент к коллективу.
VD>А что ты хоть один (по этому поводу) привел?

Ну смотри мои аргументы (выше).

Аргумент простой — так сделать можно.

Прикол в том, что ты и сам привёл доказательство этого (косвенно)

Цитирую: "...логику приложения... и презентационную логику." То есть — презентационная логика сама по себе — отдельный слой. Логично предположить, что она может проецироваться на Web-specific или Windows-specific. Взаимодействие презентационной логики и логики приложения по идее (sic!) не должно носить отметки той или иной XXX-specific, на которую спроецирована презентационная логика. Ну, например, на уровне приложения не должен фигурировать Window-HANDLE. Я не совсем точно сформулировал фразу о некорректности разделения понятий "на самом верхнем уровне", поскольку в контексте разговора этого не требовалось, однако поясню её ещё раз. Я имел ввиду, что неверно привязываться к структуре презентационной логики как к чему-то, определяющему реализацию прикладной логики. То есть, в принципе, прикладная логика — отдельно, презентационная логика — отдельно. Это вполне решабельно, если ввести дополнительный слой абстракций между прикладным "ядром" и библиотеками, реализующими интерфейс пользователя.

ГВ>>Предлагаю постановить, что доводы типа: "а ты попробуй, знаешь как это трудно!" — не котируются

VD>А я тебе предложил бы пропробывать. Тогда охота спорить с совершенно очевидными вещами у тебя отпадет сама собой.

На слабо взять хочешь? Понимаешь ли, не факт, что я сделаю те выводы, которых ты ожидаешь. Поэтому, давай всё-таки, будем пользоваться логикой. Факты — упрямая вещь, но их легко подтасовать.

ГВ>>..., если не снабжены дополнительными разъяснениями о том, что именно считается трудным. Я во всяком случае на подобные выпады больше отвечать не буду. Понимаешь ли, для меня выражение "трудно, но можно" означает, что я так и сделаю, потому что "можно".

VD>А что для тебя будет аргументом? Он тебе привел доводы, что как минимум скорости работы разные. Уж можно было домыслить, что в условиях низкой скорости и высокой латентности соеденения нужно делать интерфейсы отличные от применяемых в случаях когда нет задержек.

VD>К тому же при создании Web-варианта ты можешь пользоваться мошными функциями реализованными Web-сервером. А в локальном режиме тебе придется все далать вручную или другими методами. Или ты хочешь делать как в анкдоте про кипячение чайника программистом?

Нет, я хочу делать ещё сложнее и проще одновременно.

Проще — потому что надоели бесконечные сравнения фичечек того или иного Web-сервера, среды разработки и т.п., сложнее — потому что "в начале" при таком подходе работы больше, чем обычно. Зато потом — меньше. Проверял, знаю.

ГВ>>В корень зришь!

ASP — это не "полная фигня" ни в коем случае, но уже тепло.

VD>Почитай вот это http://forum.ixbt.com/0026/000058.html. Причем сейчас. Потому как если ты гляншь на это лет через 5-10, то вряд ли поймешь в чем хохма.

Посмотрел. Народ спорит как всегда о C/C++ и Асме. Очень похоже на нас. Забавна только аналогия — C и Асм защищаешь как раз ты и другие защитники C#.

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

VD>Здравствуйте Геннадий Васильев, Вы писали:

ГВ>>Я понимаю под эти словом объём кода, который будет заниматься трансляцией COM-овских соглашений и типов данных в данные и соглашения, принятые при разработке прикладной логики.

Отвечу на все вопросы по отдельности.

VD>Т.е. ты утверждаешь, что объем кода самого большого броузера меньше чем самого маленького ком-клиента?

Вот софистика так софистика!

Обоснуй, правомерность подобной постановки вопроса?

VD> Или считаешь что на вызов ком-объекта нужны какие-то немереные затраты?

Нет, не считаю. И эти затраты действительно невелики. Особенно при использовании шаблонов.

VD>Или считаешь что в какой-либо технологии эти затраты меньше?

Затраты на что? На вызов COM-объекта? Риторика, риторика, риторика...

VD>И почему ты счтаешь, что комовские типы нельзя использовать без трансляции для описания прикладной логики?

Можно, но не стоит этого делать

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

VD>В конце концов VB6 весь постоен на комовских типах, но тем неменее как нельзя лучше подходит для описания той самой прикладной логики.

Снова обобщения, притом абсолютно неправомерные. "как нельзя лучше" — одно из них. Я тоже могу сказать "в противовес", что нибудь типа "VB-отстой и маздай", но это как-то совсем глупо.

Так что, давай ты всё-таки обоснуешь, хоть в общих терминах, почему он "как нельзя лучше подходит".

SS>>>>>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
SS>>>>>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

ГВ>>>>Это от объёма задачи зависит. Чем она больше — тем важнее унификация внутренней структуры и глубина проработки абстракций. Тем адекватнее там C++.

VD>>>Софистика чистой воды.

ГВ>>Почему?

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

Постараюсь

откатиться назад. Дело в том, что вопрос сам по себе подразумевал достаточно узкое видение контекста решения задачи, и, следовательно — ответ должен был быть таким же узким, почти однозначным. Но сам-то по себе контекст намного шире, чем простое впихивание приклада в процесс веб-сервера. Поэтому я и сказал, что "чем шире задача, тем адекватнее там C++". Почему C++ адекватен для больших задач объяснять надо?

ГВ>>...запоздалым выделением абстракций, либо — превентивным анализом и структурированием абстракций. Последний вариант — ИМХО, самый разумный как раз в контексте большой программы (ну, или такой программы, от которой ожидается, что она станет большой).

VD>Понимаю... нефть ищите... (с). Вот только один вопрос! К чему ты все это говоришь? Тебе был задан конкретный вопрос: "...реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET". Ты же ответил на другой. И сейчас пытаешся доказать свою правоту.

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

Сначала был тезис об очень универсальных классах:

SS>А теперь вопрос на засыпку: Допустим ты написал на супер универсальном языке C++, очень универсальные классы с прикладной логикой.

А дальше — посылка, которая должна была быть выводом.

SS>Каким образом ты собираешься запихнуть свои труды в процесс WEB-сервера

Спрашивается, зачем совать мои труды в процесс Web-сервера?

Ан вот и ответ (bold — мой):

SS> (или другого сервера, или если другой программе захочется подергать за твое хозяйство)

Так вот, дорогие мои, кроме как через Web-сервер можно придумать ещё ящик способов, которыми другая программа захочет подёргать мою программу. Сети существуют примерно столько же, сколько и сами компьютеры. Способы взаимодействия между программами отюдь не ограничиваются только COM/DCOM и Web-серверами, но дальше, наконец, появляется и исходная посылка, ради доказательства которой сказано всё предыдущее:

SS>Единственное более менее вменяемое решение для этого — COM,DCOM.

YESSS!!! IIS, конечно, это единственный в мире сервер.

Спору нет. Windows — единственная ОС на все времена.

Чуешь, сколько неявных условий накладывается на исходную "универсальность"? Это как раз тот самый случай, когда любое разъяснение конкретики только отдаляет от сути дискуссии. Поэтому я и ушёл от прямого ответа на последовавший вопрос:

SS>Во что превращается прикладная логика когда кней привинчивают COM,ATL? Это довольно печальное зрелище.

И уж тем более постарался избежать размазывания отвечая на очевидно неправомерно поставленный вопрос:

SS>Вот мне бы это и хотелось услышать от противников .NET,С#,Java примерно такую фразу:
SS>"реализовывать такие задачи на C++,COM,DCOM,ATL гораздо быстрее, приятнее, эффективнее чем на C#/.NET"

Дальнейшая рефлексия (коей и был почти весь постинг) уже на самом деле не нуждалась в оппонировании:

SS>Могут возразить что это все частный случай и компонентные технологии (и подобные) используются очень редко, вот об этом можно поспорить. Мое IMHO, они повсюду и с каждым годом их становится больше.

Ну и так далее, и тому подобное...

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

VD>Пойми, никто с тобой не будет спорить о том, что крамотная декомпозиция это одна из важных составляющих успеха в программировании. Но это здесь было вообще не причем. На Шарпе и Яве абстракции делаются ни чуть не хуже чем на С++. Конечно отсутствие шаблонов в некоторых случаях приводит к менее эффективному коду и к лишним рантайм-проверкам (отсуствие которых может привести к некорректному поведению), но в других областях Шарп и Ява делают С++ как катенка.

Друже, исходно контекст заведомо заужен, понимаешь?

VD>Вот тебе пример... Реализуй на С++ контейнер содержащий заранее не известные типы. И ты увидишь всю слабость обычного С++. Он ведь умее или контролировать типы только на стадии компиляции. Тебе ридется городить море кода производящего боксинг простых типов и структур в конструкции типа VARIANT (хронящии некое описание хранимого типа и ссылку на экземпляр). Или привести все к указателю на void переложив заботу о типах с компилятора на конечного программисто (того что будет использовать твой контейнер). Многие перепрограммировшие на С++ скажут, что в этом нет ничего страшного. Подумаешь нужно подумать... А я скажу, что это то место где идеологически зараждаются ошибки. Причем ошибки трудноуловимые.

Меня так и тянет скзать что-то вроде "так давайте же перестанем думать! мысли — источник трудноуловимых и трудноустранимых ошибок!".

Шутка. Ты поступил сейчас точно также, как и silver_s, задав вопрос, который подразумевал единственный ответ. Есть вопросы, на которые нельзя отвечать ни "да", ни "нет". Это такая манипулятивная штука. Типа — "Вы любите Basic?". Сказать — "Да" будет ложью и сказать "Нет" — тоже, но из этого задающие вопрос сделают заранее заданный и вполне определённый вывод. По такому принципу часто строится реклама. Улавливаешь? Надеюсь, что да, поэтому возвратимся к "нашим баранам". На твой вопрос самый правильный ответ — вопросом. А зачем нужен контейнер, содержащий неизвестно что? Это же чистая абстракция! Как он может существовать? Раз есть контейнер, значит есть и то, что он хранит, а значит и соответствующие методы, т.е., — есть тип элемента, помещённого в контейнер. Кроме того, есть пользователи объектов определённых типов, помещаемых в этот контейнер. Ну что, попробуешь развернуть дальше?

VD>В Шарпе это решается за счет 100%-ой типизации ссылок и автоматического боксинга. В этом языке ты можешь привести любую переменную к ссылке на абстрактный объект, а потом привести указатель обратно. Причем при обратном преобразовании будет произведен контроль приведения типов и ты получишь нечто похожее на проверку типов в С++, но не на стадии компиляции, а на стадии выполнения.

Всё это верно, но есть ещё и обязательные накладные расходы, связанные с перебором мусора в контейнере, то есть тех элементов, которые после проверки типа будут проигнорированы. Кроме того — расходы на приведение типов.

VD>Безусловно такая проверка медленнее чем ее аналог сделанный в период компиляции и наличие шаблонов резко упросило бы дело. Но все в компайл-тайме не проверишь. А С++ практически лишен рантайм проверок (только динамик_каст, но он очень ограничен). Кстати, в MC++ динамик_каст резко расширил свои возможности. Это заслуга рантайма .NET.

dynamic_cast в принципе противоречит статической типизации, как и rtti, но сами по себе подобные задачи — не "есть хорошо" (ИМХО).

ГВ>>C++ как раз и адекватен, поскольку у него, в частности, развиты механизмы комбинирования абстракций и средства оптимизации (inline).
VD>То что эти заявления безосновательны тебе уже говорили. Но ты никого не слышиш.

Слышу. Но мне доказывали это, приводя неправомерные доводы типа "ни у кого ничего не вышло". Такие доводы просто незачем слушать.

Как раз-таки, обоснованных доводов практически не приводилось. В том-то и беда. AndrewVK вообще прекратил дискуссию (кстати, у осталось хорошее мнение о нём, как о собеседнике), частично мотивировав тем, что я "не хочу, чтобы меня убедили". Убедить меня можно и вопреки моему желанию, но правомерными доводами, а не взываниями. Если бы я хотел, чтобы меня убедили, я не затеял бы спора.

VD>1. inline — это наследие уродливого прошлого. Инлайнинг функций — это самое мошьное средство оптимизации, но им должен управлять не человек, а компилятор. Легко доказывается простыми тестами с автоинлайнингом и хорошими скоростными показателями .NET и Явы.

Не спорю, что неплохо было бы иметь автоматический инлайнинг.

VD>Комбирирование абстракций в Шарпе не просто развито. Она перешло на качественно новый уровень. Там разговор идет в терминах коллекций, объектов и ссылок между ними, а не на уровне байтов и битов к которому тяготеет С++. Да реализация местами является не столь эффективной по сравнению с тем что можно достичь на С++ с использованием шаблонов. Но качественная реализация на С++ это нетривиальная работа. Сделать ее может не каждый, да и самые крутые программисты из-за больших объемов работы плюют на оптимальность алгоритмов и вибырают более "легкие" решения. А они в разы проигрываю тем универсальным решениям применяемых в Яве и Шарпе.

Вот, опять: "может сделать не каждый" и т.п. (Я, кстати, тоже многого не могу или не пробовал.) Казалось бы, естественный вывод для homo sapiens: "не знаешь как — научись" подменяется выводом "не знаю и знать не хочу". Мило.

VD>В конце концов есть только три алгоритма хранения множества: массив, связанный список и хэш-таблица. Остальные (и даже дерево) являются разнаыидностями и реализуются на этих базовых приметивах. В Шарпе и Яве программист с первых шагов приучается их использовать. А в С++ уровень разработки, за частую не дает программисту подняться над мелочами и осознать, что вот здесь нужно использовать хэшь-таблицу, а вот здесь связанный список, а здесь динамический массив. В большинстве реализаций STL хэшь-таблица вообще отсуствует, а писать свою многие просто не могут или нехотят. Отдельная проблема хэш-функции. В той же Яве и .NET любой объект имеет дефолтную реализацию хэшь функции которую можно легко заменить на собственную.

Хеш-функция сильно зависит от того пространства, к которому она применяется и должна формироваться с учётом множества ключей, которые могут попасть под её контроль. Пример — есть такая СУБД/ОС Unidata. Доступ к записям БД — как к кэлементам хеш-таблицы. Так вот, там предлагается порядка 20 (!) типов хеш-функций для разных типов ключей и диапазонов их значений

ГВ>>Ну, только не передёргивай, я говорил о том, что а) COM — не единственный в своём роде способ реализации компонентного подхода к deployment;

VD>Тебе уже сказали, что компоненты к деплойменту отностся так же как классы или методы. И сказали, что на С++ нет ни одного промышленного аналога COM (имеющего те же возможности).

(Vlad, ну ёлки-палки! Да службы COM на C/C++ написаны! И на нём ещё много чего написано. Ну ёлки зелёные!)

Так что, сказать-то сказали, но доказательств толком не привели. Коллеги, если вы берётесь утверждать какие-то вещи, то доказывайте, что они правомерны и указывайте — в каком контексте они правомерны. Можно с цифрами в руках. Это техника, а не религия в конце-концов!

ГВ>>б) соглашения COM устанавливают очень неприятные и глупые ограничения для программистов на C++;

VD>А кто виноват? В С++ нет ни одной потуги к той самой компонентности. Вот и приходится создавать упрощенную модель. Так чтобы она подходила ко всем компиляторам и всем языкам.

Sic! Ко всем языкам. Давай отупим все языки до уровня, удобного при реализации поддержки коммуникаций? Относительно компиляторов вопрос отдельный, хотя и не неважный.

VD>
ГВ>>в) что нет необходимости каждый класс программы делать компонентом в смысле компонентов/объектов COM/CORBA; г) что нет нужды ради "компонентизации" корёжить хороший язык C++.

VD>Хреновый язык. Тебе уже не раз показывали вещи которые нельзя сделать на С++Ю, которые приводят на нем к повышенной опастности или неадекватным задаче размерам кода. Ты же долдонишь одно и тоже не приводия аргументов. Вернее приводя, но против своих же выводов.

Нет. На C++ можно делать всё, а вот вещи, которые приводили вы в качестве доказательства вызвают вопросы относительно посылок, которые привели к их возникновению. Грубо говоря, ваши доводы напоминают примерно такой: у меня есть две Java-программы, на чём я сделаю связь этих двух Java-программ? Таки на Java! Вывод: Java — лучшее средство. Я тоже грешу порой такими ошибками (пересчитай, сколько посылок я снял в ходе дискуссии), но на них должны указывать оппоненты, притом указывать правомерно.

VD>Я тебя уже спрашивал: "Что плохого если без сущесвенного оверхеда ты получишь возможность работать с любым объектом как с компонентом?". В ответ "нет необходимости каждый класс"... Несерьезно.

Именно что серьёзно в контексте посылок о том, что компоненты — это цельные модули (а отсюда и пошёл мой тезис о компонентах, как способе deployment), а не инструментарий, используемый для внутреннего структурирования программы.

ГВ>>Теперь о том, о чём "речь не о том"

. Речь как раз о привлекательности C++ потому что а) язык позволяет очень глубоко структурировать программу

VD>Согласен! Но 90% других языков позволяет структурировать программу как минимум не хуже чем С++. А то же Шарп иногда и лучше. И внось в ответ безпочвенные заявления являющиеся слествием того, что ты влюблен в С++ и не хочешь смотреть вокруг.

Да и хочу и смотрю, но пока ничего реально лучше нет.

VD>
ГВ>>..., что в контексте неоспоримого довода о важности декомпозиции и проектировании выглядит очень привлекательным;

VD>И опять же тебе уже на слабо говорят, что большинство выбравших Яву и Шарп выберают эти языки/платформы в виду того, что проектирование на них в разы проще чем на С++. И опять в ответ расказ о правильности проектирования перед кодированием...

Да, проектирование проще, поскольку ограничен выбор средств реализации. Кстати, пролью тебе бальзам на душу — C# меня тоже заинтересовал, но только своими атрибутами.

VD>
ГВ>> б) этого никогда не позволят "компонентные технологии"
VD>Т.е. они не позволят проектировать и структурировать програмы.

Глубоко структурировать, заметь! Т.е., на мой взгляд, неверно каждый чих представлять отчуждаемым компонентом.

ГВ>>, базирующиеся на унификации языковой модели; в) он очень привлекателен как средство "работающей" реализации сложных идей.

VD>Да на нем и простые идеи иногда сложно реализовать. А сложные идеи можно и на асм-е реализовывать. Так что это просто демогогия. Безосновательные выводы и итверждения апелирующие к чувствам и эмоциям.

Довод в) действительно неудачно сформулирован. Согласен. Временно снимаю. (До переформулировки

)

ГВ>>В твоих словах сквозит попытка смешать понятия "COM" (или "CLR"?) и "компонентные технологии вообще".
VD>В моих словах свквозит утверждение, что COM и CLR являются реализациями компонентных технологий доведенных до приемлего качества и способных применяться в промышленном производстве ПО.
ГВ>>Поправь меня, если я ошибаюсь.
VD>Поправил.

Спасибо. Однако, давай заметим вот что: что COM, что CLR — суть принадлежность одной компании — MS (стандартизацию в ECMA учитывать, как мне кажется — глупо, посмотри по этому поводу мой постинг в разделе "Прочее"). То есть, если я реализую реально переносимое приложение, например, для SCO/Solaris/Windows, то они мне не увы, но не помощники. То есть, помощники "наполовину". С учётом того, что для MS всегда будут альтернативы (всё-таки, Oracle и IBM играют "против", а это не хрен собачий) моя большая разработка попадёт в зависимость от маркетинга одной фирмы. Мне смогут сказать, что "бери Java и не жужжи", но это снова прикол — неизвестно, как Java-приложения будут работать на Windows/.NET, так что выбор остаётся — C++ или... или C.

Кроме того, я не верю в реальную переносимость CLR-приложений в перспективе. Реальная переносимость это такая, которая обеспечивает перенос с небольшими потерями. MS просто нет не слишком выгодно обеспечивать себя конкурентами. Она же платформу продаёт, а не бесплатные виртуальные машины.

ГВ>> Если же нет, тогда скажу, что хотя в каком-то контексте такое смешение и возможно (особенно — в контексте маркетингового оболванивания)
VD>Во. Сново демогогия! Так кто из нас занимается оболваниваением?

Я ошибся в предположении относительно твоих слов, так что, этот довод снимается, а обвинение в демагогии, следовательно, становится беспочвенным.

ГВ>>, но не в даннном споре (я не позволю

).

Это — неправомерное смешение понятий. Конкретно, смешивается концепция ("компоненты") и конкретная спецификация (COM).
VD>Ты хоть сам то понял, что сказал?

Понял. Я в данном случае ошибся. Ты имел ввиду, что невозможно сделать программу (с учётом упомянутых условий) без использования компонентных технологий, доведённых до промышленного использования. Да, есть такая буква в этом слове.

ГВ>>И ещё. Объясни, плиз., что именно я с трудом могу объяснить?
VD>Похоже что ты и сам не можешь объяснить, то что пытаешься. Получается размыто и не убедительно... Как же я это могу объяснить, если я утверждаю обратное?

Ты просто мастер на афоризмы.

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

VD>>>Чего? Твоего отношения сложившегося из-за нежелания разобраться в критикуемых тобой технологиях?
ГВ>>Нет, не только моего мнения. Это не меняет того, что COM/ORB/.NET/<вписать> являются частными случаями реализации компонентного (модульного с описанными выше расширениями) подхода.
VD>А что кто-то утверждал обратное? Я только утверждаю, что С++ не содержит ни грамма возможностей облегчающий работу в рантайме и тем самым разработку компонентных технологий. И я так же утверждаю, что подход избранный в .NET (забота о рантайме и учитывание этого фактора при проектировании и рантайма, и зыков) является верным и дает свои плоды.

Я согласен со всеми твоими посылками самими по себе, но в контексте "противостояния C++ <-> C#"

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

VD>>>Доживет. Как C и asm. А .NET конечно мутирует. Или сдохнет. Например, ему точно нужна мутация в области дженерик-программирования.

ГВ>>Ну вот, мутирует, там и посмотрим

Только, ИМХО, он ещё и в плане рантайма мутировать будет. То-то веселуха начнётся с бинарной совместимостью.

VD>Опять же, не нужна она там. Там промежуточный язык есть и система контроля версий. Просто на одной машине будут жить две разные версии рантайма. И старые программы будут работать со старым, а новые...

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

VD>>>Вот ты и даказал своей реализацией делегатов, что С++ хреновый инструмент для реализации абстракций.

Помнишь свое описание метода? Да и переносимость кода доказал замечательно. Иди скомпилируй свой код где-нибудь под Sun-ом.
ГВ>>Интересно ты выводы делаешь

VD>Да когда вижу можре нечитаемого кода который не может скомпилировать 80% компиляторов, то как-то выводы направшиваются сами собой. Мой код почему-то и на Интеле и на борланде компилируется, хотя в принципе это и не ружно.

Вам "шашечки" (читабельность и удовлетворяющий недоделанные на 30-40% компиляторы код) или "ехать" (соответствующая возможность)?

ГВ>> Ты мне говорил, что аналога делегатов C# на C++ сделать нельзя, я предметно доказал обратное.
VD>Вот жаль, толко аналога не вышло и код твой комплируется только на Интеле.

Я доказывал принцип и прямо говорил, что код является иллюстративным. Надо что-то добавить — нет проблем, можно добавить для получения почти полного аналога.

ГВ>>ИМХО, доказав гибкость C++ как инструментального средства.
VD>Уродство это, а не доказательство. Ты сделал самы приметивный вариант использовв конструкции которые еще не появились в половине компиляторов и все равно создал море кода, да еще вынуждающего делать декларации методов размером со страницу.

Нам такой хоккей не нужен.

А ведь твои делегаты грохнутся даже при вызове между потоками,

Доказательства!

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

VD> а чтобы сделать вызов между процессами тебе нужно будет создать подобие собственного кода, а это уже такая гора кода что в нем можно захлебнуться.

А вот это — интересный вопрос. Надо подумать.

VD>Но нужно это в большинстве современных программ, и совершенно непонятно, почему нельзя расширить возможности сзяка, ну хотя бы чтобы такие возможности можно было делать меньшей кровью. Я тебе уже сто раз коворил, что в С — это делалось двумя строчками кода и было 100% типобезопастно.

Что-о-о-о??? Указатель на функцию в C относительно типобезопасен, это да, но то, что в C одновременно с этим решается проблема потокобезопасности и передачи вызова между процессами — это уже новость!

VD>В С++ такое нагромождение является следствие неправильного дизайна языка, а вернее ошибкой в проектировании. Нужо было вместо уродских указателей на методы класса, противоречащих кононам ООП сделаь сдвоеный указатель указывающий на объект и на метод, ну и естественно сделать их как и в С независимыми от конкретного класса... совпадает сигнатура — значит можно вызвать. Ты же нечинаешь разводить демогогию о стройности языка. Чем решение изложенное мной менее стройно чем придуманное Страуструпом? Да в амбициях последнего и не желании признавать свои ошибки!

Не согласен, разумеется. И кажется, наконец-то, понял, почему. Унификация указателя на метод класса с указателем на функцию предлагаемыми тобой методами — это же не что иное, как RTTI! Потому-то, вероятно, от него и отказались, как от фундаментального элемента.

ГВ>> Реализацию можно сделать и по-другому, вопросов нет. Можешь сам этим заняться, если интересно.

VD>Ухе не интересно. Для мнея С++ — это низкоуровневый язык предназраченый для всякого рода хаков и совместимости с кодом времет эры С/С++.

Ну что же, твоё дело.

ГВ>>Мне лично — уже нет, по причинам, изложенным чуть ниже. Кстати, об "описании метода". Я думаю, что если бы ты почитал реальное описание того, как работает CLR — то выводов класса "ужас", "монстр" и т.п. сделал бы ещё больше.

VD>Я как бы его рассмотрел очень внимательно и под отладчиком, и под анакриной, и представлении Рихтера... И вижу скорость работы этого дела... Очень даже приемлимую для современного железа.

Ну и как, читабельно?

Шутка, не обижайся.

ГВ>>У меня тут появилась замечательная мысль, которая ускользала на протяжении всех этих баталий. А на хрена в C++ вообще делегаты с евентами нужны? Всё, что можно сделать делегатами/евентами зашибись как решается интерфейсом с единственным методом
VD>Вот и подумай сколько тебе нужно будет прадить липовых наследований из-за пустекового дела решаемого в С одной строкой кода.

Достаточно просто сравнить количество кода...

Здесь придётся всё в комплексе рассматривать. Я уже записал себе этот момент как тему для более детального изложения своих и чужих мыслей.

ГВ>>..., принимающим объект-сообщение нужного типа плюс множественным наследованием объекта-приёмника от нужного набора таких интерфейсов (можно — с частичной реализацией оных). От ипостаси "евентов" как от варианта диспетчера сообщений никуда не денешься, но зачем тянуть за собой процедурно-ориентированный интерфейс?
VD>Он более чем ОО-ый.

Как это? А наследование от делегатов где? ИМХО — прямой эквивалент указателя на функцию/процедуру.

ГВ>> Это же совсем не объектный стиль в принципе!
VD>Это удобный, краткий и эффективный метод. И не менее ОО, чем наследование.

Упс!

См. выше.

ГВ>>То есть, оцени прикол: я что-то доказываю тебе, ты — мне, тогда как сам по себе объект обсуждения выбран некорректно!

VD>Можешь посмотреть на Яву. Она решает проблему событий (неизбежную в современном мире) очень похожим образом. Но для простоты они ввели вложенные классы имеющие ссылку на родителя. Получатеся проще чем на С++ но все рвано криво и громоздко. Когда сравнивешь код Явы и .NET, то сразу тановится все ясно.

VD>
VD>На С++ я лично для себя нашел еще более банальное и довольно эффективное решение:
VD>

VD>template<class T>
VD>struct Base
VD>{
VD>protected:
VD>   void Fire()
VD>   {
VD>      T * pT = (T*)this;
VD>      pT->Event1();
VD>   }
VD>};

VD>struct MyClass : Base<MyClass>
VD>{
VD>public:
VD>  void Event1()
VD>  { ... }
VD>};
VD>

VD>Решение более удобное чем интерфейсы, но имеющее недостоток. Нелья динамически подключиться к событиям дугого объекта.

Ну добавь к базовому классу методы Attach/Detach в public и контейнер указателей в private. И подключайся сколько хочешь. Только я, честно говоря, не понял, почему Base::Fire сделан как protected.

VD>Ну, а с интерфесами, можно и так, но неудобно. Что мелало сдалать нормальные указатели на ОО-функции?

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

ГВ>>И, кстати, теперь я чуть больше, чем раньше согласен с теми высказываниями, которые сопоставляют C# и "чистый" C. Он-таки на самом деле близок к C!
VD>Вот ты ёрничаешь, я на практике ощутил насколько подход старого С проще и удобнее. В новой реинкорнации он позволяет прозрачно вызыватать удаленные методы и круппировать вызовы в одном контейнере (делегате). Вывод — это проще, удобнее, эффективнее и любые слова не поменяют этого расклада. Про использование иттерфейсов я тебе говорил с самого начала, и в самом начале объяснил почему это неудобно.

О подходе "старого C" можешь почитать просто горы материалов в сети, противопоставлявших объектную и процедурную парадигмы. Это тоже holy war.

VD>>>Тебе не кажется, что твоя реализация просто монстроидальна и что она явно проигрывает тому что было на дремучем С (как по краткости и элегантности, так и по эффективности)?
ГВ>>Нет проблем — можно поманипулировать с регистрами, можно и от типобезопасности избавиться. Только я этого делать не буду. Если считать void* верхом достижения программистской мысли, то это не есть правильное считание.

VD>Ну, и кто из нас передергивает? Думаю ты прекрасно меня понял.

Объясню своё высказывание. Во-первых, я согласен, что предоженная мной реализация — не самый лучший способ решения, хотя бы потому, что сделана без учёта каких-либо внешних требований, кроме обеспечения синтаксического подобия C# и демонстрации воможности унификации указателя на функцию с указателем на метод экземпляра средствами C++. Само собой, что в той или иной практической задаче появятся содержательные соображения, которые могут привести к необходимости изменения этой реализации.

Мои слова о void* — суть контраргумент на твой, где ты говоришь о том, что "всё это" можно сделать гораздо проще на C, в котором, как мне показалось, ты апеллируешь к тому, что можно пожертвовать типобезопасностью ради простоты реализации и, возможно, повышения скорости работы. Если я не прав в своём предположении — поправь, если прав, то я не считаю такой подход приемлемым, потому и злостно простебался по этому поводу.

ГВ>>Ну, перечитай ещё раз.

А если без стёба, то сформулируй вопрос — отвечу.
VD>Уже устал. Ты все равно отвечаешь на другие вопросы... которые я не задовал.

В том-то и беда, что не задавал. Похоже, что даже сам себе...

ГВ>>>>Интересно, рефлексия в форумах наверное никогда не прекратится.

Не, ребята, я больше в мыльных операх не участвую.

VD>>>Гы-гы.
ГВ>>Banzai!

VD>

Ну, в общем действительно я тоже подустал.

Banzai!

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

ГВ>Собственно, из первого ошибочного довода плавно вытекла ошибка в рассуждении: шаблоны здесь действительно не спасут, поскольку они только не используются для работы с функцией printf (за исключением каких-то частных случаев), но и вообще противоречат способам решения, предусматривающим слабую типизацию. Так что это — попытка обобщить проблему библиотеки (и самого языка) C на язык C++. Улавиливаешь? Приводимые тобой примеры — примеры "нерекомендуемого" подхода, т.е., такого, который можно использовать только семь раз отмеряв.

Не удержался. Точно также ты пытаешься перенести подход с С++ на С#.
А по поводу изменения форматирования — рекомендую поинтересоваться как это делается в дотнете.

ГВ>Да...

Это уже самозамкнутые доводы пошли.

Если параметр не является экземпляром класса, то по крайней мере в C++ это означает, что он и должен быть таким. Зачем его превращать в класс? Если же он должен быть экземпляром класса, то нет никакой проблемы в том, чтобы создать этот экземпляр из любого элементарного типа (если, конечно, сам класс предусматривает такую операцию).

Не надо, пробовали. Можешь посмотреть исходники реализации любого EJB сервера.
Я так реагирую потому что сам не одну собаку на этом съел, до сих пор шерстью отплевываюсь. Без поддержки со стороны языка неоднородность простых типов и классов порождает гору бестолкового кода. Спорить на эту тему я не буду, просто привел факт из своего опыта. А верить или не верить тебе решать.

ГВ>Отнюдь. Высказывание AndrewVK содержало вполне оформленный и законченный тезис о непредсказуемости задержек GC, с которым я и согласился, основываясь, кстати, далеко не только на его словах.
Я привел гору доводов за и один против. Ты те что за проигнорировал а вот за это упоминание уцепился. Это говорит о том что для тебя главное не истина а победа в споре. Поэтому я и прекратил полемику на эту тему.

VD>>А я тебе предложил бы пропробывать. Тогда охота спорить с совершенно очевидными вещами у тебя отпадет сама собой.

ГВ>На слабо взять хочешь? Понимаешь ли, не факт, что я сделаю те выводы, которых ты ожидаешь. Поэтому, давай всё-таки, будем пользоваться логикой. Факты — упрямая вещь, но их легко подтасовать.

Опять же, не требующий ответа факт из реальной жизни. Я много знаю народу который что то делал на С++ под WEB. И 100% из них, кто попробовал использовать для того же самого веб-ориентированные технологии говорили что для веба на С++ писать нельзя.

<<... J 1.0 alpha 5 >>

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

IT>Насчёт VB, хлопчик этот о котором я говорил как раз большой специалист по нему был. Сейчас вот любит C#...

Ну, дык с тобой свяжешся... и не такое полюбишь.

IT>Не знаю такого. Про Оракл слышал, про MS SQL нет.

Ну, приципить Яву дело не сложное. У нас в этом номере Клиент-Сервера будет статья про JNI. Дык там пять строчке и прокрамма на С++ уже использует Яву как скриптовый язык.

IT>Под обработку данных. Ты сам знаешь, что всё что он умеет делать на 5 с плюсом — это молотить SQL запросы. Курсоры у него уже получаются с трудом на троечку, а UDF можно использовать если только в ней не делать ничего сложнее 2*2. И в том что он умеет делать хорошо ему лучше не мешать. Кто знает как он себя поведёт если ты начнёшь у него из нутри туда сюда файлы разные открывать, многозадачность свою лепить... У него даже доспут к дискам сделан своим особым образом и по чёрному завязан на NT. Нет уж, мне данные важнее.

Ну, батенька, то у вас жажда нового, то вы в консерватора превращаетесь. Трезво нужно мвслить.

С Юдр все ясно... ты нактнулся на какую-то хрень. Я юдт-хи использовал. Глюки есть но жить можно. В нектоторых случаях они просто незаменимы. Я лично их вместо вьюх использовал. Ооочень удобно.

IT>Не спорю, даже согласен на 99.9%. Но одна десятая всё же остаётся

И что же эта десятая у нетбя не всплывает при рассуждениях COM+ vs. Недоделанный ремоутинг на Шарпе?

IT>Влад, ты пойми, если контора потеряет данные хотя бы за несколько часов, то это будет полный писец.

И что если она потеряет их в виду глючности сервера преложений будет легче нежели если она потеряет их из-за вылета SQL Servr-а? В общем по твоей логики нужно становиться ретроградом и давить все новое.

Если встроют нормально Нэт в сиквел, то все будет тип-топ. И работать это будет куда надежнее чем самопальный сервер приложений. К тому же еще и скороть... ведь межпроцессной комуникации не будет...

VD>>Ему придется конкурировать с тем же COM+. И боюсь что конкуренцию он проигает. Ну, как Mono по сравнению с CLI.

IT>Так дело не в том кто выиграет, а самом процессе

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

Реальнее всео вариант такой: попытки создать сервер приложений под .NET не выдержат конкуренции у COM+-а на базе .NET-компонентов.

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

VD>>Ему придется конкурировать с тем же COM+. И боюсь что конкуренцию он проигает. Ну, как Mono по сравнению с CLI.

AVK>У дотнетных серверов будет фора — на интеропе все же довольно много теряется. Плюс не используются многие чисто дотнетные фишки.

Да блин. Ты уже забыл что софт можно писать и без нэта.

Да и интероп по сравнению с маршалингом по сети — это фигня.

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

S>>Вот насчет процентов я пока не уверен. Кое-где, скорее всего, в разы.

VD>А ты не свмневайся, а проверяй.

Проверю, когда руки дойдут

S>>Вот только глядя на то, как MS за уже четыре года не удосожилось к VC нормальную поддержку шаблонов прикрутить, я не очень верю, что в CLR будут приличные шаблоны. Скорее всего, опять говнище редкостное сваяют.

VD>Меня утраивают шаблоны даже от древнего VC6. Остальное это для любитилей нечитаемых награмождений.

Остальное — для любителей качественного кода

VD>Ну, а на счет .NET-а... дык скачай себе CLI и апдэйт и погляди. Наворотов там нет, но все просто красиво и эффективно.

VD>>>2. Интероп со старым кодом. Если задача связана с частым дерганьем интеропа, то есть только одно решение МС++. Но во многих случаях можно вообще обойтись без обращения к анменэджет коду, ну или сократить эти обращения до не критичного минимума.

S>>Это фигня, критичным быть не должно. Никто не собирается из нового кода isalpha дергать.

VD>Ну-ну.

VD>>>3.Не полный набор оптимзаций. Это вообще временное явление. При должном упорстве можно добиться большей оптимизации за счет использования информации о конкретной системе.

S>>Оптимизация — это вообще мелочи. А вот запрет наследования для value-типов — это уже серьезно.

VD>И как "запрет наследования для value-типов" может повлиять на производительность?

Дык кто мне говорил "Про value-типы слышал? Вот они как раз для оптимизации добавленны" Вот только раз они наследования не поддерживают, толку от них не так много, как хотелось бы.

VD>А оптимизации конечно мелоч. Но без того же автоинлайнинга прогаммы в несколько раз медленне получаются.

А че, в C# есть такое понятие, как inline?

S>>Он встороен в компилятор

VD>Тогда не устроит. Это как раз то очем я говорю, т.е. единственный способ обеспечивающий приемлемый результат. Но именно против него и стоит на сметь Страуструп.

Я не про это — он не в том смысле встроен, просто используется в коде компилятора.

S>>, поскольку этим компялятором "для себя" используется. Впрочем, гугель говорит, что этот же самый GC и отдельно доступен — даже выдирать ничего не надо : http://www.hpl.hp.com/personal/Hans_Boehm/gc

VD>Ты бы хоть глянул чего суешь.

Там С++-ом и не пахнет. Все на голом С.

Какая разница, на чем библиотека написана? Да хоть на ассемблере, лишь бы работало. Или ты считаешь, что для C# GC написан на C#?

VD>Замечательное поддтверждение моих слов, что С++ для этой работы не гадится. Все статические проверки типов идут под нож.

Какие такие статические проверки типов? operator new function возвращает void *, как и положено.

VD>Ну и нужно еще глянуть удобство использования этого дела и производительность. На первый взгляд ужасная гора низкоуровнего кода и нечитабельный пример для С++.

Дык откуда уверенность, что GC внутри должен быть высокоуровневым? BTW, нетовский GC по тому же алгоритму работает и внутри, IMHO, похоже должен быть устроен. И что, он от этого хуже?

S>>Мы ж про кастом мемори аллокаторы говорим, так? И какой мне прок память в ансэйфе выделять, если при переходе в сэйф она копироваться будет?

VD>Мы вообще-то говорили о твоем заявлении что мол переход сэйв-ансейв дико дорог. Я тебе объяснил, что это не так, да и делать это не нужно обычно.

Я говорил про конкретный случай.

S>>Тоже выход, но уж больно убого.

VD>В общем даже приучает к грамтной структуризации. Все же в Шарпе нужно помнить, что структура нужна только там где она даст выигрышь в скорости. Твой пример я бы писал без структур. Сортировать быстрее указатели.

S>>Форумы тормозят изрядно.

VD>И что я не замечаею? Может у тебя с Инетом проблемы?

Да нет, ADSL как никак. Вот только время от времени (когда кто-нибудь поиск починить пытается, я полагаю) все жутко тормозит.

VD>>>Да в общем они почти все в стандарных библиотеках .NET и Явы.

S>>Блин, ну ткни меня носом в исходники реализации алгоритма SMACOF... Или хоть что-нибудь готовое для multi dimensional scaling.

VD>Видимо это или не алгоритмы в чистом понимании этого слова... покрайнй мере я о таких не слышал.

Верю, что не слыхал. Но это не опровергает того факта, что нахаляву реализации алгоритмов сложнее сортировки никто не раздает.

VD>Базовые же алгоритмы есть все до одного, а найти какую-то спецефичную приблуду можно везде.

Под базовыми алгоритмами, ты надо полагать, понимаешь те, что чуть сложнее foreach?

VD>Забавнее, то что в 80% реализации STL нет таких простых вщей как хэш-таблины.

И вправду, забавно.

S>>Забыл написать — возможность размещать полноценные объекты на стеке тоже хочу, и чтоб деструкторы для них были и сами вызывались.

VD>Да пофигу где размещаются объекты. Главное чтобы создавались быстро.

Пофигу. На самом деле мне нужны не обязательно стековые, а "автоматические" (в терминологии С++) объекты, которые уничтожались бы сразу после выхода из области видимости. И чтоб деструкторы у них вызывались немедленно. Иначе какой к черту качественный код, если мне руками файлы и прочее закрывать придется — обязательно ведь забуду.

VD>А деструкторы для стековых обхектов... я бы тоже не отказался. Но тут приходится выбирать. Дикая сложность С++-ного кода все равно перевешивает все недостатки Шарпа. С++ является прекрасным языком подержки, но как основной на сегодня оне уже не катит. Его нужно серьезно лечить. Причем куда серьезнее, чем Шарп. Проблемы шарпа можно перечесть на пальцах, а вот плюсы переходят в нишу С и асм-а.

Да, VB с сишным синтаксисом — страшная сила.

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

VD>Ну, приципить Яву дело не сложное. У нас в этом номере Клиент-Сервера будет статья про JNI. Дык там пять строчке и прокрамма на С++ уже использует Яву как скриптовый язык.

Пришли мне почитать. И RSDN #1 заодно

VD>Ну, батенька, то у вас жажда нового, то вы в консерватора превращаетесь. Трезво нужно мвслить.

С Юдр все ясно... ты нактнулся на какую-то хрень. Я юдт-хи использовал. Глюки есть но жить можно. В нектоторых случаях они просто незаменимы. Я лично их вместо вьюх использовал. Ооочень удобно.

Они плохо оптимизируются, нужно либо хинты использовать, либо ещё что-то.

IT>>Не спорю, даже согласен на 99.9%. Но одна десятая всё же остаётся

VD>И что же эта десятая у нетбя не всплывает при рассуждениях COM+ vs. Недоделанный ремоутинг на Шарпе?

Намёк не понял

IT>>Влад, ты пойми, если контора потеряет данные хотя бы за несколько часов, то это будет полный писец.

VD>И что если она потеряет их в виду глючности сервера преложений будет легче нежели если она потеряет их из-за вылета SQL Servr-а? В общем по твоей логики нужно становиться ретроградом и давить все новое.

Давай разбираться. Допустим у тебя глюкнул компонент внутри процесса SQL сервера, ну там писанул не туда, буфера там какие потёр, завалил процесс в то время когда он только половину на диск записал и т.д. Ты можешь потерять не последние данные, которые как бы откатились транзакцией, а всю базу. Просто весь файл. И будешь ты потом бэкапы восстанавливать и перенабивать данные за прошедший период с момента последнего бэкапа. SQL сервер, конечно штука надёжная, но шансы его завалить изнутри есть.

Теперь если у тебя глюкнул апп. сервер. Ну откатится назад одна транзакция, ну зайдёт админ в консоль и прибъёт все дедлоки, ну будет задержка в режиме системы, ну поматеряться юзеры немного, ну и что. Все данные целы.

Да и какой там SQL сервер хостер? Что такое масштабируемость ты знаешь, как ты её к нему прикрутишь? Или ты хочешь ставить сиквел сервер с пустой базой, натолкать в него SP и вызывать их, типа мы тут бизнес-логику имплементируем

VD>Если встроют нормально Нэт в сиквел, то все будет тип-топ. И работать это будет куда надежнее чем самопальный сервер приложений. К тому же еще и скороть... ведь межпроцессной комуникации не будет...

Ага, ничего не будет и масштабируемости тоже. То что ты предлагаешь называется 2.5 уровневой архитектурой. Разница только в том что вместо убогого T-SQL ты будешь писать на C#.

VD>Вот я и говрю, что ко врмени когда этот процес до беты дорастет MS глядишь или от Нэт откажится, или сама сервер приложений напишет.

Реальнее всео вариант такой: попытки создать сервер приложений под .NET не выдержат конкуренции у COM+-а на базе .NET-компонентов.

Я думаю, что просто в COM+ добавять нативный для .NET доступ к объектам и этого будет вполне достаточно, по крайней мере, как я понимаю, для тебя

Я бы поучаствовал в каком-нибудь открытом проекте типа сервера приложений для .NET. Задача очень даже интересная. Для начала можно было бы хотя бы просто определиться с требованиями и путями решения, а дальше видно будет.

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

VD>Да блин. Ты уже забыл что софт можно писать и без нэта.

Да нет, не забыл. Но на дотнете или джаве это делать приятнее.

VD>Да и интероп по сравнению с маршалингом по сети — это фигня.

К несчастью интероп будет не только при маршаллинге но и при работе самого компонента с серверными службами. А это уже серьезно.

<<... J 1.0 alpha 5 >>

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

IT>Пришли мне почитать. И RSDN #1 заодно

В следующий раз пришлю.

IT>Они плохо оптимизируются, нужно либо хинты использовать, либо ещё что-то.

Нормально. Они просто как вьющи оптимизируются. Нужно толко соблюдать такие условия: возвращать не курсор, а запрос и не делать никаких лишних действий внутрии. Получается нечто вроде вьюх, но с более удобным синтаксисом. А шинты на запросах б большим БД все равно периодически применять прихдится. Особенно с индексирванными вьюхами. Там у MS SQL крышу клинит капитально.

VD>>И что же эта десятая у нетбя не всплывает при рассуждениях COM+ vs. Недоделанный ремоутинг на Шарпе?

IT>Намёк не понял

Предвзят ты малость. Тестировать лучше отчуждаясь от предмета тестирования. В любом случае как бы не закончились тесты в ремоутинге отсуствует: защита, контроль закрузки и ее распределение на другие серверы, статистика, тарнзакции, обеспечение устойчивой работы в условиях глюков приложения, администрирование. Это и есть составляющие сервера приложений. Безспорно все это можно сделать, но труд это огромный.

IT>Давай разбираться. Допустим у тебя глюкнул компонент внутри процесса SQL сервера, ну там писанул не туда

Это физически невозможно. Это означает, что ты гузил ансэй код. Ты и сейчас можеш хкстендед-хранимую прцедуру на С забацать и что сервер будет виноват? А хранимые процедуры на транзакте ты клепаешь пачками и о надежности незадумываешься. С явой и нетом все тоже самое. Там будет в основном сэйф-код, а над ансэйвом ты сто раз задумаешся (как над экстендед процедурой).

IT>, буфера там какие потёр, завалил процесс в то время когда он только половину на диск записал и т.д.

На это есть журналы тарнзаккций. По барабану где откатывается транзакция. Технически там единый набор действий.

IT> Ты можешь потерять не последние данные, которые как бы откатились транзакцией, а всю базу.

Извени это уже чистая фантазия.

IT> Просто весь файл. И будешь ты потом бэкапы восстанавливать и перенабивать данные за прошедший период с момента последнего бэкапа. SQL сервер, конечно штука надёжная, но шансы его завалить изнутри есть.

Его так же можно завалить и снаружи процесса. Там применяются алгоритмы которым падение нестрашно. Страшен только проход по памяти. Именно его отсуствие и карантируют безопастные режимы явы и нета.

Дальнейшие размышления основаны не неверном предположении.

IT>Да и какой там SQL сервер хостер? Что такое масштабируемость ты знаешь, как ты её к нему прикрутишь? Или ты хочешь ставить сиквел сервер с пустой базой, натолкать в него SP и вызывать их, типа мы тут бизнес-логику имплементируем

В основном на них все масштабирование и держится. SQL-сервер сабмое слабое звено. Основной способ мсштабирования реплекация несколькоих серверов. Если нэт позволит делать гладкую репликацию (да еще и асинхронную), то масштабируемость будет очень высокой.

IT>Ага, ничего не будет и масштабируемости тоже. То что ты предлагаешь называется 2.5 уровневой архитектурой. Разница только в том что вместо убогого T-SQL ты будешь писать на C#.

Да я ничего не прдлагаю. Это MS делает. И смысл в этом есть. К тому же называется это двухуровневой архитектурой (возможно массово-параллельной), и при ее применеии нет запрета на третий уровень. Оракловцы (многие) до сих пор так работают. И причиной тому более качественный язык. Который можно назвать языком программирования в отличии от транзакта. Который больше является расширением SQL, чем процедурным языком. Шарп позволил бы контролировать на сервере более сложную логику. Для многих систем этого было бы достаточно. В общем плохого в этом ничего нет. В конце концов хоть опыта наберутся.

IT>Я думаю, что просто в COM+ добавять нативный для .NET доступ к объектам и этого будет вполне достаточно, по крайней мере, как я понимаю, для тебя

Не понял? Доступ к COM+ из нэт и сейчас прозрачный как слеза, и на оборот тоже. Ты о чем?

IT>Я бы поучаствовал в каком-нибудь открытом проекте типа сервера приложений для .NET. Задача очень даже интересная. Для начала можно было бы хотя бы просто определиться с требованиями и путями решения, а дальше видно будет.

Это очень большой проект. Если не делать его с бухты-барахты, то он займет человеко-десятилетия. Проще тогда взять за основу корбу и реализовать их идеи на нэте.

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

AVK>К несчастью интероп будет не только при маршаллинге но и при работе самого компонента с серверными службами. А это уже серьезно.

И все же по сравнению с маршалингом по сети — это мелочь. Но в любом случае нужно мерить.

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

IT>>Пришли мне почитать. И RSDN #1 заодно

VD>В следующий раз пришлю.

А первый номер ты мне послал или опять забыл

VD>Нормально. Они просто как вьющи оптимизируются. Нужно толко соблюдать такие условия: возвращать не курсор, а запрос и не делать никаких лишних действий внутрии. Получается нечто вроде вьюх, но с более удобным синтаксисом. А шинты на запросах б большим БД все равно периодически применять прихдится. Особенно с индексирванными вьюхами. Там у MS SQL крышу клинит капитально.

Я возвращаю таблицу, маленькую такую, всего на 30 записей и при этом SQL полностью перестраивает план запроса в худшую сторону.

VD>Предвзят ты малость. Тестировать лучше отчуждаясь от предмета тестирования.

Конечно предвзят. Вот уже два часа не могу заставить COM+ поднять .NET'вский объект на удалённом сервере. Будешь тут...

VD>В любом случае как бы не закончились тесты в ремоутинге отсуствует: защита, контроль закрузки и ее распределение на другие серверы, статистика, тарнзакции, обеспечение устойчивой работы в условиях глюков приложения, администрирование. Это и есть составляющие сервера приложений. Безспорно все это можно сделать, но труд это огромный.

Ты так говоришь, как будто ты уже сдался и придумываешь разные excuses

защита — есть в IIS,
контроль закрузки и ее распределение на другие серверы — есть, можно лоадбалансер прицепить и будет ещё лучше чем на COM+.,
статистика — какую тебе надо? или ты о тех крутящихся шариках, которые рисует COM+'овая консоль? нормальную статистику в COM+ тоже ещё надо постараться получить,
транзакции — нету, но в том же COM+ они сделаны на DTS и местами MS рекомендует пользоваться им на прямую, что мешает сделать для этого маленький рапер.
обеспечение устойчивой работы в условиях глюков приложения — ну это ты загнул, ты мне тут ниже распинаешься как круто надёжен сэйф код в SQL сервере, и вдруг он стал не надёжен. А эксепшинами ремотинг может кидаться не хуже чем COM+ возвращать HRESULT
администрирование — нету, жалко конечно.

И вообще, если ты уже знаешь, что ремотинг так плох, то зачем вообще о нём говорить и тем более тестировать?

IT>>Давай разбираться. Допустим у тебя глюкнул компонент внутри процесса SQL сервера, ну там писанул не туда

VD>Это физически невозможно.

А в апп.сервере всё возможно.

VD>Это означает, что ты гузил ансэй код. Ты и сейчас можеш хкстендед-хранимую прцедуру на С забацать и что сервер будет виноват? А хранимые процедуры на транзакте ты клепаешь пачками и о надежности незадумываешься. С явой и нетом все тоже самое. Там будет в основном сэйф-код, а над ансэйвом ты сто раз задумаешся (как над экстендед процедурой).

T-SQL наверняка интерпретируется, а нетовский код выполняется как нативный, чувствуешь разницу?

IT>> Ты можешь потерять не последние данные, которые как бы откатились транзакцией, а всю базу.

VD>Извени это уже чистая фантазия.

Ну напиши SP на C и постреляй по левым адресам внутри SQL сервера, посмотришь выживет он бедолага или нет.

VD>Его так же можно завалить и снаружи процесса. Там применяются алгоритмы которым падение нестрашно. Страшен только проход по памяти. Именно его отсуствие и карантируют безопастные режимы явы и нета.

За память я и говорю. Я же не спорю, что сэйф код не надёжен, я тебе говорю, что мне данные важнее

VD>Дальнейшие размышления основаны не неверном предположении.

Сам такой

VD>В основном на них все масштабирование и держится. SQL-сервер сабмое слабое звено. Основной способ мсштабирования реплекация несколькоих серверов. Если нэт позволит делать гладкую репликацию (да еще и асинхронную), то масштабируемость будет очень высокой.

Как тебе нет сделает репликацию данных, я что-то не пойму. Здесь проблема кроется глубже, не думаю, что её можно решить нетами или явами. Вот если бы SQL сервер умел делать виртуальную распределённую базу на нескольких серверах и давал мне возможность решать какая таблица на каком сервере будт храниться, вот это было бы уже что-то. А у репликаций применение ограниченное и без поллитры там никак.

IT>>Ага, ничего не будет и масштабируемости тоже. То что ты предлагаешь называется 2.5 уровневой архитектурой. Разница только в том что вместо убогого T-SQL ты будешь писать на C#.

VD>Да я ничего не прдлагаю. Это MS делает. И смысл в этом есть. К тому же называется это двухуровневой архитектурой (возможно массово-параллельной), и при ее применеии нет запрета на третий уровень.

Двух уровневой, если мне не изменяет мой склероз, вроде называется архитектура где вся логика находится на клиенте, но используется общая серверная БД. Уровни выше появляются когда логика начинает убираться с клиента. Вот перенос в её на сервер БД и есть 2.5, ещё не три, но уже и не два

VD>Оракловцы (многие) до сих пор так работают.

И иногда вообще удивляются зачем нужна многозвенка и вообще весь этот штат C++ и ява программеров

VD>И причиной тому более качественный язык. Который можно назвать языком программирования в отличии от транзакта. Который больше является расширением SQL, чем процедурным языком. Шарп позволил бы контролировать на сервере более сложную логику. Для многих систем этого было бы достаточно. В общем плохого в этом ничего нет. В конце концов хоть опыта наберутся.

Да ради бога. Будет возможность писать SP на шарпе, я буду это делать. Но делать из SQL сервера сервер приложений — это уже слишком. Тем более что в нём точно не будет многих вещей, которые ты перечислил как достоинства COM+.

IT>>Я думаю, что просто в COM+ добавять нативный для .NET доступ к объектам и этого будет вполне достаточно, по крайней мере, как я понимаю, для тебя

VD>Не понял? Доступ к COM+ из нэт и сейчас прозрачный как слеза, и на оборот тоже. Ты о чем?

Ну да, то-то я парюсь сегодня целый день. Да и на DCOM'е он сделан, интероп там всякий, хотя похоже что он не сильно всё замедляет, если вообще замедляет. Я говорю о прямом ремотинге, о channel.

IT>>Я бы поучаствовал в каком-нибудь открытом проекте типа сервера приложений для .NET. Задача очень даже интересная. Для начала можно было бы хотя бы просто определиться с требованиями и путями решения, а дальше видно будет.

VD>Это очень большой проект. Если не делать его с бухты-барахты, то он займет человеко-десятилетия. Проще тогда взять за основу корбу и реализовать их идеи на нэте.

Бессысленно мерять человеко-годы не имея элементарных требований к задаче. К тому же структура .NET весьма и весьма отличается от COM и в CLR уже много чего реализовано. Ты меряешь всё мерками COM+, а ты выйди из его тени и прикинь что тебе реально нужно в этой жизни от апп.сервера.

Защиту можно сделать только в момент соединения, нафиг оно надо каждый пакет проверять, лоадбалансинг при stateless модели делается и без всякой поддержки со стороны софта, а при stateful и софтом не получится, статистику можно навернуть, тарнзакции — разбираемся с DTS и поехали, устойчивая работа есть у самого CLR по определению, администрирование можно навернуть. Где нужно применяем перехват вызовов, благо в .NET это вполне реализуемо и даже не одним способом.

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

А самое главное — не результат, а участие

Просто я не знаю лучшей задачи, чтобы как следует покопаться внутри у .NET. Можно конечно свой Анакрино написать, но это пошло

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

VD>И все же по сравнению с маршалингом по сети — это мелочь. Но в любом случае нужно мерить.

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

... << J 1.0 alpha 5 >>

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

VD>>Это очень большой проект. Если не делать его с бухты-барахты, то он займет человеко-десятилетия. Проще тогда взять за основу корбу и реализовать их идеи на нэте.

IT>Бессысленно мерять человеко-годы не имея элементарных требований к задаче. К тому же структура .NET весьма и весьма отличается от COM и в CLR уже много чего реализовано. Ты меряешь всё мерками COM+, а ты выйди из его тени и прикинь что тебе реально нужно в этой жизни от апп.сервера.

Могу в качестве примера привести JBoss. Ничего такого уж неподъемного, а там много лишнего. Или Resin. Уж извините, но если там бинарником всего мегабайта полтора то это никак не тянет на человекодесятилетия.

IT>тарнзакции — разбираемся с DTS и поехали,
DTC наверное. Кстати он стандартизован, так что тут скорее всего проблем не будет.

IT> устойчивая работа есть у самого CLR по определению, администрирование можно навернуть.
Точно, придумать что нибудь вроде джавовского JMX.

... << J 1.0 alpha 5 >>

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

IT>А первый номер ты мне послал или опять забыл

Послал. Но по началу как пологается забыл.

VD>>Нормально. Они просто как вьющи оптимизируются. Нужно толко соблюдать такие условия: возвращать не курсор, а запрос и не делать никаких лишних действий внутрии. Получается нечто вроде вьюх, но с более удобным синтаксисом. А шинты на запросах б большим БД все равно периодически применять прихдится. Особенно с индексирванными вьюхами. Там у MS SQL крышу клинит капитально.

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

VD>>Предвзят ты малость. Тестировать лучше отчуждаясь от предмета тестирования.

IT>Конечно предвзят. Вот уже два часа не могу заставить COM+ поднять .NET'вский объект на удалённом сервере. Будешь тут...

А нет на удаленной машине поставил? Учти эти козлы там кучу тлб-х зацепляют, так что по официальной версии без рантайма на клиентах никак. Вот такоу плюсик в копилочку.

IT>Ты так говоришь, как будто ты уже сдался и придумываешь разные excuses

В общем ты почти прав. Во времена до MTS-а мы подобное пытались родить. Коркас даже получился...

IT>защита — есть в IIS,

IIS — это вэб-сервер, а не сервер приложений. Он, кстати, в основном пользуется услугами того же COM+-а.

IT>контроль закрузки и ее распределение на другие серверы — есть, можно лоадбалансер прицепить и будет ещё лучше чем на COM+.,

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

IT>статистика — какую тебе надо? или ты о тех крутящихся шариках, которые рисует COM+'овая консоль? нормальную статистику в COM+ тоже ещё надо постараться получить,

Ее явно больше чем в ремоутинге. А главное что есть способ ее получения. Есть такая фича — перехват (интерцептинг). В ремоутинге я пока подобного не увидел.

IT>

транзакции — нету, но в том же COM+ они сделаны на DTS и местами MS рекомендует пользоваться им на прямую, что мешает сделать для этого маленький рапер.

Ключевое слово — сделаны. В COM+ 1.5 они довели работу с транзакциями до совершенства. Короче реализовали все что описнао в стандартах Корбы.

Работа это нехилая. Сделать ее для нет будет не просто. А ведь нужно чтобы еще и производительнось при этом не рухнула.

IT>

обеспечение устойчивой работы в условиях глюков приложения — ну это ты загнул, ты мне тут ниже распинаешься как круто надёжен сэйф код в SQL сервере, и вдруг он стал не надёжен. А эксепшинами ремотинг может кидаться не хуже чем COM+ возвращать HRESULT

Проблема в том что обеспечение целостности данных и работоспособности приложений — это разные проблемы.

В COM+ 1.5 есть такие фичи как перезапуск процессов сервера приложений при разных условиях. От потерь памяти GC не спасает. Забудет, программист освободить ссылочку на объект и через 100 часов работы система исчерпает ресурс свопа. С данными ничего не случится но приложение "ляжет".

IT>администрирование — нету, жалко конечно.

Во-во.

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

IT>И вообще, если ты уже знаешь, что ремотинг так плох, то зачем вообще о нём говорить и тем более тестировать?

Ремоутинг не плох. Ремоутинг это интерфейс. Ну, как DCOM. Только в нем многого нет. Той же защиты, к примеру.

Главное что пока нет сервера приложений и если в MS решат, что COM+ будет достаточно, то для нэт врятли вообще появится серьезн сервер приложений (А остальные Борланды с IBM-ами в лучшим виде будут делать серверы на/под Ява).

IT>А в апп.сервере всё возможно.

Мы говорим о прикладном коде и устойчивости сервера. Все на свете возможно, но в данном случае вероятность того что глючным окажется код от MS куда выше того что ты в сэйф-режиме рапортишь память.

IT>T-SQL наверняка интерпретируется, а нетовский код выполняется как нативный, чувствуешь разницу?

Нет. Перед компиляцией он проверяется на наличие запрещенных инструкций и приемов. Верифицируется значичь. Это дает ту же степень надежности/безопастности.

IT>...и постреляй по левым адресам внутри SQL сервера

Это невозможно. Сэйф режим просто неимеет подобных инструкций. Блыин кого я лечу?

IT>За память я и говорю. Я же не спорю, что сэйф код не надёжен, я тебе говорю, что мне данные важнее

Ну попробуй без интеропа в сэйф-режиме пройтись по памяти. Как удастся поговорим дальше.

IT>Как тебе нет сделает репликацию данных, я что-то не пойму.

Репликацию пусть делает SQL Server, а нет даст возможнось превратить его в сервер приложений.

IT>Вот если бы SQL сервер умел делать виртуальную распределённую базу на нескольких серверах и давал мне возможность решать какая таблица на каком сервере будт храниться, вот это было бы уже что-то. А у репликаций применение ограниченное и без поллитры там никак.

Это уже давно возможно. Ты можешь обращаться к другим серверам из одного запроса. Проблема в том, что это медленно и ненадежно.

Применяют другой подход. Сервера реплпцируются и ты можешь рабоать с любым сервером как с соновным. Внесенные тобой изменения синхронно или асинхронно рассылаются по другим серверам... Таким образом пользователей можно распределять между раноценными копиями базы на назных серверах.

IT>Двух уровневой, если мне не изменяет мой склероз, вроде называется архитектура где вся логика находится на клиенте

Тебя обманули.

Уже сто лет триггеры используют для обработки бизнес-логики.

IT>, но используется общая серверная БД. Уровни выше появляются когда логика начинает убираться с клиента. Вот перенос в её на сервер БД и есть 2.5, ещё не три, но уже и не два

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

Я вот толко понять не могу в чем она различается. Для мнея логика данных — это правила реляционной модели которые и кодирования то на сегодня не требуют.

VD>>Оракловцы (многие) до сих пор так работают.

IT>И иногда вообще удивляются зачем нужна многозвенка и вообще весь этот штат C++ и ява программеров

Ну и в чем они не правы если из задача решается и их это удовлетворяет? Лично мне больше не нарвится их язык. Шарп куда удобнее.

IT>Да ради бога. Будет возможность писать SP на шарпе, я буду это делать. Но делать из SQL сервера сервер приложений — это уже слишком. Тем более что в нём точно не будет многих вещей, которые ты перечислил как достоинства COM+.

А как только ты начнешь это делать, ты поймешь что разнцы то (если нет распределенной системы) нет. Просто обращение к БД в триггерах куда эффективнее.

IT>>>Я думаю, что просто в COM+ добавять нативный для .NET доступ к объектам и этого будет вполне достаточно, по крайней мере, как я понимаю, для тебя

VD>>Не понял? Доступ к COM+ из нэт и сейчас прозрачный как слеза, и на оборот тоже. Ты о чем?

IT>Ну да, то-то я парюсь сегодня целый день. Да и на DCOM'е он сделан, интероп там всякий, ... Я говорю о прямом ремотинге, о channel.

Ну тоды это будет уже не COM+, .NET+. И автоматом решится вопрос о сервере приложений.

IT>хотя похоже что он не сильно всё замедляет, если вообще замедляет.

Вот это собственно и нужно померять. Ести тормаза минимальны, то о чем тогда вообще речь. Сам по себе COM+ оптимальный сервер приложений. Что плохого в том, что он кроме .NET объектов еще будет и COM+-овские способен подымть? И в том что криент может быть и на анменеджет-средствах разработки создан? Ну AVK малость поплюется (пользуясь случаем хочу передать пример), а потом поймет что разницы нет и тоже будет пользоваться.

IT>Бессысленно мерять человеко-годы не имея элементарных требований к задаче. К тому же структура .NET весьма и весьма отличается от COM и в CLR уже много чего реализовано. Ты меряешь всё мерками COM+, а ты выйди из его тени и прикинь что тебе реально нужно в этой жизни от апп.сервера.

Я как-бы еще Яву видел... Про Корбу все время статьи почитываю... Там люди сложа руки не сидят. Ты думаешь почему в последнее время так участились случаи когда программист говорит "хочу на нэт!", а ему отвечают "нехрена лабай на Яве"? Там все сто раз продумано. Да и в COM+-се все продумано. А нэт ли это, ява ли, или DCOM ни суть важно. Требования к серверу приложений общие. В конце концов сервер приложений просто предоставляет сервисы через специфицированный интерфейс, а сервисы отражают потребность прикладных программистов.

IT>Защиту можно сделать только в момент соединения

IT. Давай или ты поглуже разберешься в пробеме или не будешь так легкомысленно говорить о столь серьзеных вещах. Ты видел сколько страниц занимает моя стать о защите в ком-е? А я веть там только поверхностно коснулся ее общих вопросов и описал кое-какие интерфейсы. На практике реализовывать защиту очень и очень сложно. Темболее что она должна быть прозначно интегрирована и ее работа не заканчивается на этапе соеденения. Там все куда сложнее.

IT>, нафиг оно надо каждый пакет проверять

Это не нашего ума дело. Тебе (в некоторой конкретной задаче) не надо. А дургим надо. Возможно задачу моно серьезно упростить используя разные готовые вещи типа SSL-я, но опять таки этим должны заниматься специалисты, а не мы с тобой.

IT>, лоадбалансинг при stateless модели делается и без всякой поддержки со стороны софта

Опять зе ключевое слово делается. Это работа. Причем требующая универсального решения, т.е. это задача сервера приложений.

IT>, а при stateful и софтом не получится

Это чушь. Еще как получится. Просто это сложно. Здесь теже методы что и при репликации.

Кстит, под stateful в корбе понимается объект имещий не просто состояние, а сохраняющий свое состояние между сессиями.

IT>, статистику можно навернуть

Можно. Не желаешь заняться?

IT>, тарнзакции — разбираемся с DTS и поехали...

Гы-гы. Похоже на остаток своей жизни занятие уже нашлось.

IT>Работы конечно много, но можно начать постепенно и главное определиться с требованиями.

Вот тут-то видимо программисты из MS почесали репу и пошли мерять скорость работы .NET-объектов через COM+.

Может и мы сначала это сделаем?

IT>А самое главное — не результат, а участие

Просто я не знаю лучшей задачи, чтобы как следует покопаться внутри у .NET. Можно конечно свой Анакрино написать, но это пошло

Ну не знаю.

Что там пошлого? А детать это вдимо нужно. Анакрино действительно безбожно глючит и не очень качественно вскрывает логику. Я бы с удовольствием его улучшил.

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

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

Это все слова не имеющие под собой никакой почвы... Нужно мерить.

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

AVK>Могу в качестве примера привести JBoss. Ничего такого уж неподъемного, а там много лишнего. Или Resin. Уж извините, но если там бинарником всего мегабайта полтора то это никак не тянет на человекодесятилетия.

Дык видимо он и не тянет на серьезный сервер пиложений.

AVK>DTC наверное. Кстати он стандартизован, так что тут скорее всего проблем не будет.

Ага. Почти. Ну, по крайней мере, до тех пор пока не начнешь реальную работу.

Да и еще раз повторюсь — это работа для разработчиков сервера приложений, а не для прикладника.

IT>> устойчивая работа есть у самого CLR по определению, администрирование можно навернуть.
AVK>Точно, придумать что нибудь вроде джавовского JMX.

Мужики, а мне еще в NT-ях много чего не нарвится... может подстугаем?

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

VD>Дык видимо он и не тянет на серьезный сервер пиложений.

Тянет, не сомневайся.Транзакции есть, load balancing есть, авторизация есть. Что еще?

VD>Ага. Почти. Ну, по крайней мере, до тех пор пока не начнешь реальную работу.

Да и еще раз повторюсь — это работа для разработчиков сервера приложений, а не для прикладника.

А кто то говорил что это работа прикладника?

<<... J 1.0 alpha 5 >>

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

VD>>Дык видимо он и не тянет на серьезный сервер пиложений.

AVK>Тянет, не сомневайся.Транзакции есть, load balancing есть, авторизация есть.

Значит все же модуль у него не маленький. Да и видимо денег стоит и не маленьких.

AVK> Что еще?

То что в ремоутинге этого всего нет.

VD>>Ага. Почти. Ну, по крайней мере, до тех пор пока не начнешь реальную работу.

Да и еще раз повторюсь — это работа для разработчиков сервера приложений, а не для прикладника.

AVK>А кто то говорил что это работа прикладника?

Тогда что споришь с тем что ремоутинг пока не является заменой сервера приложений?

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

VD>Значит все же модуль у него не маленький.
Ну проверь сам
http://www.caucho.com/download/resin-ee-2.1.4.zip
4.9М. При этом в архив входит документация, примеры, куски J2EE, собственный xml парсер и xslt трансформер, ну и еще кое какая чепуха.

VD>Да и видимо денег стоит и не маленьких.
Для некоммерческих проектов бесплатен. Для коммерческих без техсаппорта $1000 per server. Это дорого? Не думаю.

AVK>> Что еще?

VD>То что в ремоутинге этого всего нет.

Так и в джаве тоже нету. И xml-парсера до недавнего времени не было.

AVK>>А кто то говорил что это работа прикладника?

VD>Тогда что споришь с тем что ремоутинг пока не является заменой сервера приложений?

Э, что то я не въехал. Ремоутинг не является заменой сервера приложений, но он может помочь создать сервер приложений имеющий на платформе .NET определенные преимущества перед COM+. Другого я не утверждал.

<<... J 1.0 alpha 5 >>

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

AVK>http://www.caucho.com/download/resin-ee-2.1.4.zip
AVK>4.9М. При этом в архив входит документация, примеры, куски J2EE, собственный xml парсер и xslt трансформер, ну и еще кое какая чепуха.

Пять мег — это не для моего Инета.

Но уже видно что люди не меньше года трахались.

AVK>Для некоммерческих проектов бесплатен. Для коммерческих без техсаппорта $1000 per server. Это дорого? Не думаю.

А сколько там у нас винды с ремоутингом то стоят?

Да и чтерт его знает на сколько качественный этот сервер...

AVK>Так и в джаве тоже нету. И xml-парсера до недавнего времени не было.

Ну, будем надеяться что или серверы приложений появятся или COM+ будет не хуже с нэтом интегрироваться и тормозов не давать.

AVK>Э, что то я не въехал. Ремоутинг не является заменой сервера приложений, но он может помочь создать сервер приложений имеющий на платформе .NET определенные преимущества перед COM+. Другого я не утверждал.

Ты влез в наш с IT спор о применимости ремоутинга для создания многоуровневых приложений (полнофункциональных). Так вот я утверждал, что пока ремоутинг не пременим для этого, так как нет сервера приложений, а IT напротив говорил что фигня все это.

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

VD>Ты влез в наш с IT спор о применимости ремоутинга для создания многоуровневых приложений (полнофункциональных). Так вот я утверждал, что пока ремоутинг не пременим для этого, так как нет сервера приложений, а IT напротив говорил что фигня все это.

Не надо, я не говорил что это фигня. Я говорил что было бы круто попробовать написать свой. Я даже не говорил давай напишем, а именно давай попробуем просто ради получения эспириенса.

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

IT>Не надо, я не говорил что это фигня. Я говорил что было бы круто попробовать написать свой. Я даже не говорил давай напишем, а именно давай попробуем просто ради получения эспириенса.

Честно говоря я бы предпочел чтобы это сделал ктонибудь другой. Например, MS.

Уж слишком много мелочей и слишком высока отвественность.

Но в любом случае сначала нужно убедиться что это в принципе нужно. Что там твои тесты .NET-объектов через COM+? Насколько это медленнее нежели COM-овские объекты через тот же COM+ и как это все в сравнении с ремоутингом?

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

VD>Но в любом случае сначала нужно убедиться что это в принципе нужно. Что там твои тесты .NET-объектов через COM+? Насколько это медленнее нежели COM-овские объекты через тот же COM+ и как это все в сравнении с ремоутингом?

Мои тесты просты и красноречивы — пока я не могу поднять .NET объект в COM+ на сервере, пишет — 0x8007007e The specified module could not be found. На локальной машине всё Ok. Не понимаю в чём дело. Если у тебя получалось кинь мне пример простого сервера и простого клиента. С обычными объектами всё Ok.

ЗЫ. Ты в своей статье сервер тестировал?

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

IT>Мои тесты просты и красноречивы — пока я не могу поднять .NET объект в COM+ на сервере, пишет — 0x8007007e The specified module could not be found. На локальной машине всё Ok. Не понимаю в чём дело. Если у тебя получалось кинь мне пример простого сервера и простого клиента. С обычными объектами всё Ok.

Я еще .NET-объекты через COM+ не подымал.

IT>ЗЫ. Ты в своей статье сервер тестировал?

В какой? Корба вс. Ком? Там все в серверном резиме работало.

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

IT>>ЗЫ. Ты в своей статье сервер тестировал?

VD>В какой? Корба вс. Ком? Там все в серверном резиме работало.

Я про это — http://www.rsdn.ru/?article/default.asp?dotnet/complusnet.xml

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

IT>Я про это — http://www.rsdn.ru/?article/default.asp?dotnet/complusnet.xml

А. Когда-то я ее смотрел... но давно дело было.

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

IT>Я про это — http://www.rsdn.ru/?article/default.asp?dotnet/complusnet.xml

Это статья дотнэт.сайтовцев в принципе можно к ним обратиться если что...

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

[skip]

VD>Вот ты и даказал своей реализацией делегатов, что С++ хреновый инструмент для реализации абстракций.

Помнишь свое описание метода? Да и переносимость кода доказал замечательно. Иди скомпилируй свой код где-нибудь под Sun-ом.

Помнится, грозился я реализовать делегатов на VC++ 6.0. Посмотри, если интересно, в "Исходниках".

Описалово будет чуть позже — уж не обессудь.

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

VD>>Вот ты и даказал своей реализацией делегатов, что С++ хреновый инструмент для реализации абстракций.

Помнишь свое описание метода? Да и переносимость кода доказал замечательно. Иди скомпилируй свой код где-нибудь под Sun-ом.

ГВ>Помнится, грозился я реализовать делегатов на VC++ 6.0. Посмотри, если интересно, в "Исходниках".

Описалово будет чуть позже — уж не обессудь.

Шаргин уже реализовал их довольно прилично. В RSDN Magazine #1 будет статья об этом. Но две основные претензии:
1. Невороятно большой объем кода.
2. Невозможность вызова из других процессов.

...остаются.

PS

В общем С++ один хрен нужно менять. Иначе он будет косить под динозавров.

... << RSDN@Home 1.0 alpha VladD2.1.0.alpha 12.1.0.1028.36665 >>

	От:	SergeMS
	Дата:	20.08.02 10:09
	Оценка:	12 (2)

	От:	Mishka.NET
	Дата:	20.08.02 10:23
	Оценка:	36 (4) -1

	От:	Sergey
	Дата:	20.08.02 11:13
	Оценка:	23 (3)

От:	Anatolix	https://www.linkedin.com/in/anatolix/
Дата:	20.08.02 11:29
Оценка:

	От:	Igor Trofimov
	Дата:	20.08.02 11:33
	Оценка:	9 (2)

От:	Aquary	https://wmspanel.com/
Дата:	21.08.02 00:11
Оценка:

От:	VladD2	www.nemerle.org
Дата:	21.08.02 00:47
Оценка:

От:	econt	http://cprime.110mb.com
Дата:	21.08.02 06:31
Оценка:	45 (6)

	От:	Максимов Андрей
	Дата:	21.08.02 09:26
	Оценка:	39 (6) -1

От:	Vi2	http://www.adem.ru
Дата:	22.08.02 04:17
Оценка:	15 (2)

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	22.08.02 23:32
Оценка:

От:	m.a.g.	http://dottedmag.net/
Дата:	25.08.02 06:03
Оценка:	61 (7)

От:	epflorov	www.epflorov.hotbox.ru
Дата:	26.08.02 19:26
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	30.08.02 11:44
Оценка:

От:	Batiskaf	http://www.mult.ru/
Дата:	04.09.02 16:38
Оценка:	80 (10)

От:	Yampolski_Nikita	http://nikitay.pisem.net
Дата:	10.09.02 16:14
Оценка:

От:	IT	linq2db.com
Дата:	13.09.02 01:11
Оценка:	7 (1)