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

ЗХ>>Итак, поразмыслим немножко о "происхождении одного языка от других". Что, вообще, можно подразумевать, говоря "язык Б произошел от языка А"?
ЗХ>>1. Синтаксис Б расширяет синтаксис А
ЗХ>>По этому признаку, большинство современных мейнстрим-языков "произошли" от C.
ЗХ>>Такое "происхождение", чаще всего, можно однозначно доказать.
ЗХ>>Ценность такой концепции "происхождения" близка к 0.

E>Вот мне так не кажется.

E>Как показывают жаркие споры о "синтаксическом оверхеде" и о том, "что Java -- это испорченный С-ным синтаксисом Oberon" (сюда же можно отнести и то, что большая часть критики Oberon-а сводится к тому, что КЛЮЧЕВЫЕ СЛОВА нужно ЗАПИСЫВАТЬ в верхнем РЕГИСТРЕ ), вопрос первичности синтаксиса очень важен.

E>Возьмем два языка, близких по возможностям, но совершенно разных по синтаксису: Паскаль и C. По мне, синтаксическая разница между ними состоит не в том, что присваивание в Паскале -- это ":=", а в C -- "=". И не в том, что составной оператор в Паскале ограничивается begin/end, а в C через {}. Самая большая разница в Паскале -- это разбиение программы на секции: секция объявления типов, секция объявления констант, секция объявления переменных. Или еще одно: считать ли присваивание выражением (имеющим значение, как в C) или же оператором (более точно -- statement, не имеющим значения), а дальше -- возможность/невозможность использования присваивания в логических выражениях (злополучный if(a=b)). Из-за этих синтаксических различий структура программы на Паскале отличается от структуры программы на C. А вот это уже намного существеннее. Это уже отражает мировозрение авторов языка.

Согласен. Однако, imho, разница синтаксиса Паскаля и C в том, что Паскаль — ориентирован на быстрое обучение начинающих и с этой позиции begin лучше {, секции лучше чем их отсутствие, = — это привычный значок "равно", а не "присвоить" и т.п. В то время как C ориентирован на ускорение разработки профессионалом. C предполагает, что человек давно знаком в чем разница между if (a > b) и if (a >> b) , и заботится о том, что бы человек мог побыстрее изложить технические детали и приступить думанию над задачей. В этом смыле та же java произошла от C, как язык для профессиональной разработки. Но наличие типа boolean, и не пригодность int в логических выражениях указывает на то, что альтернативная идея тоже была принята в расчет.
Правда с позиции предложенной классификации, это рассуждение больше относится к духу языка, чем непосредственно к синтаксису.

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

Нехочу снова зариваться в терминологические споры.

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

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

E>Так что в сад, батенька, с подобным сарказмом, в сад.

Предпочитаю в лес. Но это даже не сарказм.

В общем, все просто. На уровне идеологии ООП сообщением называется передача некой информации. При этом механизм передачи не важен. В конкретных же реализация в основном эта бастракция реализуется через вызов метода, так как это значительно фээектинвее (для современных процессоров) нежели возня с очередями сообщений. Ради эксперемента можешь сравнить скорость вызова SendMessage в Windows и самый хреновый вид вызова метода (интерфейсы, делегаты и т.п.). Увидишь, что разница 2-3 порядка.

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

E>Имхо, существует большая разница между намерениями и возможностями. Может быть авторы Java и понимали преимущества шаблонов/generic-ов в 1996. Но вот реализовать их смогли только в 2003-2004. А между выходом Java 1.0 и Java 1.5 ведь еще были 1.1, 1.2, 1.3, 1.4. Но выпустили они generic-и только когда силенок хватило.

E>В Java вообще много такого, что на водит на мысль о "включили, потому что смогли сделать". А что не включили, то от лукавого Множественное наследование, например, нормальное (ведь в managed среде от множественного наследования совсем не много бед) или перегрузка операторов.

Ага. Ну, да... в Сане ламеры седят. Вот только эти ребята как-то умудрились свои ОС написать и компилятр С++ к ним.

В общем, повтояюсь в последний раз. Дело было не в силах или возможности. Дело было в иделогических противоречиях.

E>Ну тебе виднее. Мы же с тобой над общими проектами уже давно работаем, постоянно кодом обмениваемся

Мы еще про буст с АСЕ или уже о свом, о девичьем?

E>Случай, ты серьезно думаешь, что ООП -- это наше все? Что ООП -- вершина эволюции и дальше идти уже не куда?
E>Ах забыл, вершина -- это КОП.

Это к делу не относится. Главное, что C# и Ява проектировались не как надстройка над С, а как ООЯ (т.е. без всяких компромисов).

E>SObjectizer (Собжектайзер), пожалуйста, если не сложно

Как угодно. Но он к ЯП и компиляторам все же отношения не имеет. Это фрэймворк.

E>Вот именно, что ООП никак не ограничивают способ обмена сообщениями в ООЯ.

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

E> Но только все ООЯ делают это синхронно в виде вызова метода. Т.е. получается, "раз ООП тебя не ограничивает, то уж мы тебя точно органичим"

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

E>Зачмырить -- это перехватить?

Зачмырить — это значит оговорить, представить в негативном свете.

E>Да я имел в виду именно это.

Похоже на то.

E>Влад, есть два приниципиально разных способа взаимодействия параллельных процессов:
E>-- отсылка сообщений. Отославший сообщение процесс не знает о результатах обработки сообщения.

Еще раз. Бывают разные системы посылки сообщеий. Например, SendMessage и PostMessage. И бывают разные цели ассинхронности. Одно дело когда речь идето о комуникациях, другое когда о распараллеливании вычислений.

E>Да?
E>Может это все за счет разработки enterprise систем?

Дык они это 80% софта.

E> А то у меня из .Net-овских приложений только Janus и стоит. А Java-овских давно уже не было.

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

E>Пусть так, но даже в таких условиях C++ позволяет мне писать меньше кода и работает все быстро.

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

E>А ты еще говоришь, что C++ не для ламеров.

Ладно. Уломал речистый.

E>>>Принципиальная: рефлексия для любого типа или рефлексия только для того, что я явно заказал.

VD>>Может пусть компиляторы и рантаймы думают об эффективности? Зачем мне еще одна головная боль?

E>Блин, да я тебе об этом и говорю. В C++ эта головная боль у меня. А в Java -- у компилятора.

Ну, и пусть заботися. Уж что, что, а от рефлексии ресурсы особо не жрет. Да и нужна она в первую очередь ЖЦ.

E>...Третий модуль, который должен использовать классы из двух предыдущих модулей, знает названия классов PriorityQueue и Diagram, но не знает их интерфейсов. Как он будет с ними работать в .Net-е?

Блин, ну, ты что не веришь, что дотнет поддреживает КОП? Или не понимашь принципов этой парадигмы? Да создать два типа из другой сборки это вообще детство. Дотнет (и Ява, кстати, тоже) могут и без имени компонент создать. На том и основанны дизайнеры форм и компонентов. Для использования типа нужно всего лишь сделать ссылку на модуль где тип объявлен. После этого можно использовать тип в коде и поьзоваться всеми благами цевилизации (комплит вордом, навигацией...). Если же нужно в рантайме, то есть такие фичи как Activator.CreateInstance() и рефлексия. И есть даже фрэймворки рантайм-кодогенирации. В общем, все средства. Чтобы написать все это на С++ нужно положить не один десяток человеколет. Примерно такие же возможности, но более скудные можно найти в Дельфи и даже Обероне. А в С++ о модулях вообще речи не идет.

E>Влад, ты занимаешься КОП и тебе кажется, что все, что идет во благо КОП -- это прорывы, и КОП -- это следующая парадигма после ООП.

Мне не кажется. Я вообще-то объяснял почему твоя гипотиза (о происхождении C# и о том почему в нем нет, небыло и никогда не будет шаблонов) ошибочна. Мои пристрастия тут совсем не причем. Важны только цели создателей языка. Хотя если спросить меня лично, то я отвечю, что язык не поддерживающий КОП — это маральный урод которому не место в 21 веке.

E>Я занимаюсь разработкой многпоточных и многопроцессовых систем.

Замечательно. Правда этим занимаются почти все кто делает финансовые приложения. Ну, да ладно.

E>Для меня многопоточнось и асинхронность важны, но асинхронные делегаты, имхо, в этой области совсем не прорыв.

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

E>Ну и? Ты же смотришь на C++ через призму своих догм. Почему мне от такого подхода отказываться.

Я смотрю на С++ как на ООЯ. И сравниваю его с другими ООЯ.

E>У Ruby есть community. Имхо, вполне разумно, что все разработки этого community находятся в одном хорошо известном месте.

Просто как в песне Цоя "Все говорят что мы в месте, но не многие знают в каком."

Здравствуйте, Павел Кузнецов, Вы писали:

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

Э... ненадо подменять задачи. Если мы программирвем на ООЯ, то все делается в терминах объектов и именно это делает побайтное копирование объектов бредовой идеей. Если же для нас объекты это прикладная фигня записанная в памяти, а мы просто управляем блоками памяти (причем сами, и только мы), то проблем нет. Память для нас будет выглядить как плоский массив тех самых бай и функции копирования для него у нас уже есть (Array.CopyTo). Так что ардестная арифметика нам для этого особо ненужна. Другое дело эффективность.

ПК>Это и определяется тем, какого типа ограничения накладываются на аргументы шаблонов/generics: структурные или "подтиповые". С чем ты споришь-то?..

По-моему, споришь ты.

ПК>Проблемы Си++ здесь совершенно ни при чем.

Очень даже причем. Есть решения которые не трбуют утиности.

ПК> Это просто-напросто возможность, которая либо есть, либо нет. Если ее нет, то часть техник становится недоступной.

Не беда. Есть другие. Причем так же недоступные в разных С++. Вопрос можно сформулировать проще. Есть ли задачи которые невозможно спроектировать и реализовать с применением некоторого подхода. В данном случае таких задачь нет. Так же важно насколько просто решаются задачи. Так вот задачи явно решаются намного проще чем на С++ даже с применением того, чего в нем пока нет и неизвестно появится ли и когда появится.

ПК> Если она есть, то появляется дополнительный уровень сложности, с ней ассоциированный. В C# такой возможности в непосредственном виде нет (можно получить некоторое подобие через reflection).

В С++ процентов 50 возможностей шарпа и дотнете нет. Но ты почему-то до сих пор на нем программируешь.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>В C# наоборот. И за это его создателей нужно хорошенько пропесочить.

Я бы скорее пропесочил Явшиков.

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

E>Т.е. получается, что в скором времени стоит ожидать выхода C# 3.0. И что скомпилированные им программы будут работать на втором .Net. И когда Mono полностью реализует поддержку 2.0, то скомпилированный MS компилятором C# 3.0 программы будут работать там, где есть Mono?

E>Если так, то круто!

Ждать нужно только поддержки в Моно нового обобщенного мсила из .Net 2.0 (точнее нового стандарта CLI который уже вроде как принят ECMA). Компилятор C# 3.0 уже есть и интегрируется со студией. Вспе приведенные примеры я компилировал на нем. Компилятор порождает сборку в которой МСИЛ. Далее остается запустить ее под Моно и вуаля!

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

VD>В общем, все просто. На уровне идеологии ООП сообщением называется передача некой информации. При этом механизм передачи не важен.
Тут, Влад, дело не в механизме. Дело — в семантике.
Вызов метода можно представить в виде композиции из двух действий :

1. Отправить сообщение
2. Дождаться ответа

Если сообщение не предполагает ответа (void метод), все равно очень важен тот факт, что к моменту возврата все побочные эффекты уже произошли. Т.е.

1. Отправить сообщение
2. Дождаться окончания обработки сообщения

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

list.Add("Hello!");

а, значит,

list.Contains("Hello!");

вернет true. Потому, что мы неявно дождались окончания добавления хелло в список. И это очень удобно. Если бы у нас все вызовы были по умолчанию асинхронными, то пришлось бы постоянно втыкать ожидания, потому как 99% кода имеют синхронную природу.
И совершенно случайно оказалось, что стековая архитектура прекрасно описывает вот эту семантику вызовов с ожиданиями. И, стало быть, дает еще и сверхэффективность обмена сообщениями. В принципе, я не уверен, что так будет всегда.
Мы подходим к очередному кризису производительности однопроцессорных машин. А, значит, начнется рост потребности в распараллеливании алгоритмов. Есть риск, что будет придумано изящное решение этой задачи (ООП, vtbl, конвенция fastcall и т.п. тоже не сразу появились). И тогда разработчикам аппаратуры может захотеться сделать аппаратные реализации.
Ну вот пример: вроде как регистровой архитектуре стек нафиг не нужен. Мы всегда можем заменить команду push парой команд mov и inc. Тем не менее, есть встроенная поддержка. А кто в таком случае мешает сделать что-то аналогичное с очередями? Будут регистры QS и QH/QT, аппаратная синхронизация постановки/разгребания очереди, аппаратная поддержка кольцевого буфера с динамическим расширением, аппаратные сигналы "в очереди данные"...
И окажется, что SendMessage стоит всего раза в два-три дороже, чем банальный call, зато дает возможность повышать параллельность.

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

VD>Ждать нужно только поддержки в Моно нового обобщенного мсила из .Net 2.0 (точнее нового стандарта CLI который уже вроде как принят ECMA). Компилятор C# 3.0 уже есть и интегрируется со студией. Вспе приведенные примеры я компилировал на нем. Компилятор порождает сборку в которой МСИЛ. Далее остается запустить ее под Моно и вуаля!

Действительно, круто.
C# становится все привлекательнее и привлекательнее

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

D>Я в свое время имел дело с "автоматическими" системами построения доказательств....

а может можно придумать высокоуровневый язык для описания доказательств теорем и вообще любых математических утверждений?
просто языки в программах типа Coq и Hol по своему "уровню" больше напоминают ассемблер. программисты(в отличии от математиков) очень хорошо думали и придумали удобные языки Программирования высокого уровня. может и для proof-assistance можно сделать высокоуровневые языки?

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

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

D>>Я в свое время имел дело с "автоматическими" системами построения доказательств....

1>а может можно придумать высокоуровневый язык для описания доказательств теорем и вообще любых математических утверждений?
И назовем его SML!!!! (или кто-то уже делал такой?)

С уважением, Gleb.

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


D>>>Я в свое время имел дело с "автоматическими" системами построения доказательств....

1>>а может можно придумать высокоуровневый язык для описания доказательств теорем и вообще любых математических утверждений?
GZ>И назовем его SML!!!! (или кто-то уже делал такой?)

что же тогда делать?

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

1>>а может можно придумать высокоуровневый язык для описания доказательств теорем и вообще любых математических утверждений?
GZ>И назовем его SML!!!! (или кто-то уже делал такой?)

SML — не для "описания доказательств теорем", а для "программироваия систем доказательств".

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

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

1>>>а может можно придумать высокоуровневый язык для описания доказательств теорем и вообще любых математических утверждений?
GZ>>И назовем его SML!!!! (или кто-то уже делал такой?)

Т>SML — не для "описания доказательств теорем", а для "программироваия систем доказательств".
Собственно HOL и Coq , ровно также как и LCF (ради которого был создан ML) ---- написаны на ML.
не думаю что это будет верх эволюции.

Я, честно говоря, не очень понимаю, зачем языку нужно содержать в себе что-то совсем уж новаторское. Мне Java нравится не своими "новаторскими" идеями, а тем, что у нее простой синтаксис и боле-менее нормальная документация. Еще мне кажется интересным язык D ( http://digitalmars.com/d/ ). А скриптовые языки мне нравятся как раз тем, что они предоставляют "вообще-все-что-вам-может-понадобиться-когда-либо".

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

E>Я поразмышлял еще о коде в стиле select...from...orderby. Мне кажется, что у компилятора здесь появляются возможности для неслабой оптимизации выполнения. Например, неявно для программиста компилятор и run-time может распараллелить некоторые операции по доступным в системе процессорам. Скажем where x < 7 для вектора может паралелльно вычислятся по разным диапазонам вектора. Аналогично и сортировкой/группировкой.

В данном конкретном случае это не задача компилятора, а задача библиотеки для конкретных типов. Потому что за этим select совсем не обязательно стоит IL-код.

E>Смотря в каком варианте. В варианте с select понятнее, хотя я так и не понял, откуда берется объект z с методами Key и Group.

Extension метод GroupBy для IEnumerable возвращает коллекцию экземпляров такого класса:

public sealed class Grouping<K, T>
{
      // Methods
      public Grouping();
      public Grouping(K key, IEnumerable<T> group);

      // Properties
      public IEnumerable<T> Group { get; set; }
      public K Key { get; set; }
}

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

E>Имхо, существует большая разница между намерениями и возможностями. Может быть авторы Java и понимали преимущества шаблонов/generic-ов в 1996. Но вот реализовать их смогли только в 2003-2004. А между выходом Java 1.0 и Java 1.5 ведь еще были 1.1, 1.2, 1.3, 1.4. Но выпустили они generic-и только когда силенок хватило.

Прототип дженериков в Java (с примерной реализацией) появился очень давно, года 3 назад оно точно уже было. Но были очень большие проблемы совместить дженерики и КОП.

VD>> Ассинхронность ортогональное понятие к ООП. За исключением Эрлэнг, и с наряжкой дотнетных, я низнаю ни одного ЯП который поддерживал бы поддерживал посылку ассинхронных сообщений.

E>Вот именно, что ООП никак не ограничивают способ обмена сообщениями в ООЯ. Но только все ООЯ делают это синхронно в виде вызова метода.

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

VD>>Ага. Только псылка сообщений тут на фиг не упала. В том же дотнете есть такое понятие как RealProxy. С ее помощью можно подменить ссылку на реальный объект, на ссылку на прокси и перенаправлять вызовы куда хочешь. С помощью RealProxy сделаны такие вещи как Ремоутинг (межмашинное, межпроцессное и межпоточное взаимодействие).

E>Влад, есть два приниципиально разных способа взаимодействия параллельных процессов:
E>-- отсылка сообщений. Отославший сообщение процесс не знает о результатах обработки сообщения. Может даже не знать, дошло ли сообщение до получателя. Ответ так же приходит в виде сообщения. Это полностью асинхронный механизм взаимодействия;

Такое в ремоутинге в частности (и в механике TP/RP в целом) возможно.

E>Оба эти подхода имеют свои сильные и слабые стороны. Но самое главное, что они практически не совместимы друг с другом. Если система строится на основе обмена ссообщениями, то попытки выразить это через якобы синхронные операции только замутняют суть происходящего. В этом случае гораздо понятнее написать send(<что-то там>), чем делать вызовы BeginInvoke, EndInvoke. Имхо.

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

VD>>А кто будет в ней отладкой заниматься? И почему этот орел не может взять отладочную версию?

E>А я разве говорил об отладке? Я говорил о замене кода в работающей системе.
E>Иногда нужно новую функциональность добавить, или ошибку на лету исправить, или наоборот, часть старой функциональности изъять. Возможность сделать это без останова всей системы -- это очень интересно.

Ты вобще когда нибудь с ASP.NET или JSP сталкивался? Там эта возможность сто лет как реализована.

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

E>>Вот именно, что ООП никак не ограничивают способ обмена сообщениями в ООЯ. Но только все ООЯ делают это синхронно в виде вызова метода.

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

Ну дык почему же не сделать такую же возможность для обычных вызовов в рамках одного многопоточного процесса?

Я ведь здесь не оригинален, Саттер в своей презентации подобные вещи для C++ описывает: concurrent c++

Автор: alexeiz
Дата: 05.10.05

.

E>>Оба эти подхода имеют свои сильные и слабые стороны. Но самое главное, что они практически не совместимы друг с другом. Если система строится на основе обмена ссообщениями, то попытки выразить это через якобы синхронные операции только замутняют суть происходящего. В этом случае гораздо понятнее написать send(<что-то там>), чем делать вызовы BeginInvoke, EndInvoke. Имхо.

AVK>Ты противоречишь сам себе. Приведи гипотетический пример, как должны выглядеть эти самые асинхронные посылки сообщений.

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

class Editor {
    void do_background_save()
        {
            m_writter.store( m_document );
        }
        
    void do_background_print()
        {
            m_printer.print( m_document );
        }

public :
    // Callback для получения результата сохранения.
    async background_save_done( const Save_Result & r )
        { ... }
        
    // Callback для получения результата печати.
    async background_print_done( const Print_Result & r )
        { ... }
    ...
    };
    
class Writter {
public :
    async store( const Document & doc )
        {
            ...
            doc.editor().background_save_done( result );
        }
    ...
    };
    
class Printer {
public :
    async print( const Document & doc )
        {
            ...
            doc.editor().background_print_done( result );
        }
    ...
    };

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

AVK>Ты вобще когда нибудь с ASP.NET или JSP сталкивался? Там эта возможность сто лет как реализована.

C JSP сталкивался года четыре назад, некоторые application-сервера такую возможность поддерживали. Но хотелось бы отметить два момента:
-- во-первых, это не C++. А меня интересует такая возможность именно для C++. Поэтому и приходится смотреть в сторону других языков;
-- во-вторых, не все задачи можно сделать на JSP. И если такой задачей приходится заниматься, то придется самому повторять то, что JSP было сделано. А хотелось бы иметь это в готовом виде. Как, скажем, в Ruby.

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

E>>Я поразмышлял еще о коде в стиле select...from...orderby. Мне кажется, что у компилятора здесь появляются возможности для неслабой оптимизации выполнения. Например, неявно для программиста компилятор и run-time может распараллелить некоторые операции по доступным в системе процессорам. Скажем where x < 7 для вектора может паралелльно вычислятся по разным диапазонам вектора. Аналогично и сортировкой/группировкой.

AVK>В данном конкретном случае это не задача компилятора, а задача библиотеки для конкретных типов. Потому что за этим select совсем не обязательно стоит IL-код.

Жаль. Тогда это всего лишь синтаксический сахар.

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

E>Ну дык почему же не сделать такую же возможность для обычных вызовов в рамках одного многопоточного процесса?

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

AVK>>Ты противоречишь сам себе. Приведи гипотетический пример, как должны выглядеть эти самые асинхронные посылки сообщений.

E>Например, есть редактор,

Да, любишь ты простыни кода. Вот как то же самое выглядит в ремоутинге:

class Editor
{
  private void DoBackgroundSave()
  {
    m_writter.Store(m_Document, BackgroundSaveDone);
  }
        
  private void DoBackgroundPrint()
  {
    m_printer.Print(m_Document, BackgroundPrintDone);
  }

  // Callback для получения результата сохранения.
    public void BackgroundSaveDone(SaveResult r)
  { ... }

  // Callback для получения результата печати.
  public void BackgroundPrintDone(PrintResult r)
  { ... }
    
  ...
}

class Writter
{
    [OneWay]
  public void Store(Document doc, StoreCallback callback)
  {
    ...
    callback(result);
  }
  ...
}

class Printer
{
    [OneWay]
  public void Print(Document doc, PrintCallback callback)
  {
    ...
    callback(result);
  }
  ...
}

AVK>>Ты вобще когда нибудь с ASP.NET или JSP сталкивался? Там эта возможность сто лет как реализована.

E>C JSP сталкивался года четыре назад, некоторые application-сервера такую возможность поддерживали. Но хотелось бы отметить два момента:
E>-- во-первых, это не C++.

Т.е. изменение кода на лету будет прорывом, только если будет реализовано в С++?

E>-- во-вторых, не все задачи можно сделать на JSP.

А почему обязательно JSP. Я тебе просто привел пример того, что подобное, при наличии на то необходимости, на управляемых средах делается. Ну а то что С++ такого не умеет это личные проблемы С++, к проблемам индустрии в целом имеющие весьма отдаленное отношение.

E> И если такой задачей приходится заниматься, то придется самому повторять то, что JSP было сделано.

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