Lepsik
не думаю что лично моя. Потому что CGI на С++ довольно распространенное явление.


Не могу согласится что CGI на C++ - распространенное явление. Графики, на
которые вы ссылаетесь отражают общий сектор разработки C++, а не C++CGI.


Половина кода у меня только и занимается манипуляциями с XML
Что именно вас интересует - я пользуюсь DOM для этого. Чем вам поможет вырванный кусок кода понять что это возможно.


Дело в том что один из моих проектов "Электронный Документоооборот Предприятия" (ЭДП)
базируется на XML технологиях, и мне хотелось бы поделится с вами идеями и решениями
а также узнать ваши решения. С целью обмена опытом.


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


Рациональное зерно в этом есть. Я бы выразился немного иначе.

Вы попробуйте разработать сложную cистему но с простым интерфейсом(ами). Чтобы человек с улицы этот
интерфейс понял. Тогда я перед вами сниму шляпу!


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


Язык С/C++ создавался с учетов особенностей той архитектуры которая
главенствовала на момент его создания. Она предполагает существование
четкого разделения кода и данных. Из этого вытекают масса технических
мелочей, которые и делают сегодняшний образ "мастодонта C".
Даже делая скидку на полиморфизм и прочие "фенечки" современных языков,
никак не могу считать его настолько гибким, насколько "трубят"
об этом Страуструп и им подобные. Не могу, коллега! Хоть убейте!

Может ли C++ изменять свой код в режиме runtime ?
Может ли он рассматривать код как данные, а данные как код?

Очень хорошую реплику сказал Lelikk. Я позволю себе его
процитировать. И хотя я забегаю вперед (об этом хотелось подискутировать позже)
но все таки...

Lelikk
...Опять же вотчина других языков гораздо лучше приспособленных под это.
Более того, на С++ НЕ ВОЗМОЖНО даже сымитировать код, написанный на OCaml.


Есть повод почесать репу.

Lepsik
Извините, если я пользуюсь библитекой для работы с регулярными выражениями, то мне
что надо переходить для этого перл ? Я это достаточно эфективно могу делать и на С++.
По поводу работы с базами данных - база Беркли не использует SQL-подобного языка, но
это не мешает решать на ней серьезные задачи. Кстати extended procerures - как правило
из делают на С++ и Oracle стала использовать Java, а Micorosft подвязал .NET -
говорит о недостаточности и неэффективности процедурных языков для ряда задач.


RegExp-ы - это отдельная технология, которая ни к Perl ни к С++ отношения не имеет

Насчет Беркли .. извините не сталкивался. Однако меня интригует ваше заявление
о том, что данная СУБД не использует SQL. Что-же она использует взамен?


К сожалению прошло больше 12 лет и у меня ничего не осталось на руках.
Основано это было на "нагруженных сетях Петри". Был написан препроцессор
для С, позволяющий использовать его на многопроцессорых машинах.
А софт сей позволял моделировать как многпроцессорные системы,
так и моделировать софт для них. К сожалению с распадом Союза
потребность в этом исчезла. Потому как финансировать некому было.


Жаль. Очень жаль. Ну тогда, если вам не трудно будет вспомнить,
я хотел-бы задать три вопроса:

1. Что из себя представляет "препроцессор для С" ?
2. Под какую аппаратную конфигурацию создавался проект ?
3. Как были реализованы "обьекты многозадачности" (критические секции и.т.п) ?


...при таком подходе вообще вопрос топика поставлен некорретно.


Совершенно верно.


Я имел ввиду на самом деле программисту платят и он работает на том что ему говорят.
Данным майнстримом является сейчас С#. Они работают на нем не отого что он
эффективнее, а на том что им скажут. Но часто эти прихоть менеджера, а не
целесообразность.


ИМХО вы зря на него обижаетесь. Это не прихоть а его видение проблемы. А если
вы побудете годик-другой менеджером - тоже станете мыслить другими категориями.
На передний план встанут вопросы вопросы сопровождения кода. Ну а наши с вами
дискуссии в "кулуарах" отойдут на задний план.


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


Между тем Java, тихо и надежно продолжает работать на вашем мобильном телефоне и в кредитной карте.


нет проблем. Win32 работает в режиме эмулции.
А AMD64 работает вполне хорошо. Скажем я на своей машине проблем не нашел.
Или вы имели ввиду портирование ?


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

Разумеется я имел в виду портирование, коллега. Новая линейка процессоров от Intel
будет обратно несовместима с набором команд x86.


...хранимые процедуры - небольшая ниша, для расширения процедурного SQL


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


...большая часть продаваемого на С++...


Смотрите динамику спроса и предложения на .Net решения, коллега!


PL/1 тоже написали не дилетанты. И где он ?


У меня нет комментариев. К сожалению я не знаком с PL/1.


темплейты, которые впрочем появятся в 2.0, но почему-то
неглупые люди о них забыли в первой версии. И наличие препроцессора,
который такие делает дистанцию между С++ и C#


Я очень хорошо понимаю создателей С#. Они не хотели
делать слепок с C++. Равно как и не хотели повторять Java. Новая
идея, чтобы завладеть массами должна выглядеть новой.

Впопыхах забыли про шаблоны? Ну что-ж. Это вопрос решаемый. Тем более
что это языковая а не платформенная проблема.

Итак коллеги, я высказал своe мнение.

С уважением
Mayton