Так и делаю, если посмотреть. В порядке расположения точек
Вопрос о конструкциях типа 2+%1(%2^2+%3(10+%2*3))
Начни об этом думать, и не понятно когда закончишь (имеется в виду "честная" работа)

------------ Дoбавленo в 18.30:
Мне казалось, что тема " Эволюция современных языков программирования" предполагает обсуждение именно FrontEnd-а
Чего, собственно, обсуждать BackEnd-то...
Что его надо делать на высоком качестве, обсуждать, как минимум - не умно.
Есть одна закономерность: изменения в FrontEnd-а могут потребовать делать BackEnd заново. Это тоже вроде не оспаривалось
И ВСЕ.

------------ Дoбавленo в 18.52:
btw: В своей последней схеме я сделал две ошибки (включил красный цвет - и сразу увидел). Перезалил

Никакого прироста в скорости у меня не произошло, кроме как потери в цветовой гамме.
p.s градацию уменьшил до 64 в прошлом примере было 128

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

Попробую прояснить отличия

С передачей целочисленных данных (хэндл объекта) в потоках нет никаких проблем вообще. Никаких изменений в среде для этого не требуется

Без св-ва типа "класс элемента" объектоуказание бессмысленно. А это св-во - вовсе уже не data_object. Класс элемента - это константа времени компиляции, и ни к какому конкретному объекту отношения не имеет.

Св-во же типа data_object, наоборот - не может поменять класс, но может выбрать конкретный объект заранее предписанного класса. Грубо говоря - ничего общего

Соответственно, без поддержки со стороны среды изменения внешнего вида элемента в зависимости от св-ва - это лишь чит, понимание которого доступно лишь тому, кто сам изменил CodeGen под этот чит. А вот data_object не требует никакого изменения внешнего вида элемента.

Dilma писал(а):

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

Начнем с того, что если мы будем создавать контейнеры для функционирования как ЭЛЕМЕНТЫ, то механизм сокрытия точек (а я убежден - не только точек) будет просто необходим.
Да, пока это однократное использование, как сегодня - в этом смысла нет. Не нужна точка - не рисуй ее.
И что получается. Сделали элемент а-ля TControl, и что теперь - каждый Pointer-элемент теперь на пол экрана разворачивать ???
Да нет вовсе, "открываем" только парочку нужных, и ими пользуемся. В этом месте.
А в другом - совсем другими.
И, между прочим, это не только сервиз пользователя, это определяет и функционирование для правых/верхних точек. Возникающие события у нутре элемента (например в ответ на вызов метода) поступают на Pointer-элемент только если они на нем "открыты". А если нет - на элемент-оригинал.
((btw: я не нашел аналогии для этой фишки в классических ЯВУ))

Ну и вот, разные Pointer-элементы могут выглядеть совершенно по-разному, хоть и указуют на один оригинал
И это даже и хорошо (если вспомнить про TControl).
В такой ситуации (а она именно такая), дополнительные точки типа #hselect, или верхний #handle - никакого дискомфорта вызывать не должны

Кстати говоря, никто не обращал внимание на хитромудрость исполнения элемента LPT ???
А вот присмотритесь
Дело в том, что он выполнен именно как Pointer-элемент, указующий не некий невидимый один (если порт один) элемент-оригинал
Берусь утверждать, что это вовсе не потому, что я вырос и воспитывался в Голландии, а потому-что без этого работать - крайне затруднительно

Для чистоты эксперимента пришлось делать полный аналог схемы. При этом код = 43 строки, скорость с первым вариантом увеличилась в 5 раз. Dilma, 1 : 1

VB6: Если описать несколько объектных переменных с обработкой событий (with events), и присвоить им один и тот же объект, то будут вызваться все обработчики события.
.Net: Если добавить несколько обработчиков событий, при возникновении события будут вызваны все делегаты (хотя порядок вызова не определён).

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



да это уже больше похоже на правду. Только у меня не в 5 раз быстрее а в 2

[b]Dilma[/b], выкинул из кода
заменил на


получил прирост ещё процентов на 15. Так что бадаться мне только с Fasm вероятно...

andrestudio, вы автор компилятора чтоли, чтобы бодаться с кем-то? Программа из-под PB на данном этапе работает быстрее только по двум причинам:
1) сборка в Delphi работает с классовыми переменными, в то время как PB все свои переменные размещает в общей памяти с прямой адресацией.
2) все версии Delphi генерируют код для совместимости работы с сопроцессором на машинах 8086, вставляя инструкцию wait после каждой выгрузки результата в оперативную память

если поправить п1 и перенести объявление переменных в глобальную секцию, то скорость обоих аглоритмов уже сравняется

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

andrestudio, не надо путать понятие "язык" и понятие "компилятор". Это во-первых. Во-вторых, скептиков следует поискать в другом месте - тут таких насколько мне известно не водилось. Ну в третьих, не нужно пытаться доказать то, что за вас уже давным давно сделано - .NET платформа в стандартной поставке состоит из трех языков VB,Managed C++,C#, каждый из которых транслируется в один и тот же MSIL и уже потом исполняется. Т.е. в данном случае сравнивать все три языка вообще бессмысленно.

Ну и по теме немного: Basic(как инструмент) действительно подходит только для интерпретации и не потому, что с него нельзя сделать компилятор, а потому что в нем нет конструкций и механизмов, без которых не может обойтись ни один современный ЯВУ. В случае с .NET язык Basic был просто расширен до того уровня, который позволил подогнать его под нужную идеалогию. Кроме того это было тем более просто сделать, что в .NET как и в Basic отсутствуют инструменты непосредственной работы с памятью.

Интересная статья про ассемблеры: http://www.opticode.ru/art/art1.html

нужно быть очень смелым, чтобы утверждать, что ASM понятнее и на нем проще писать, чем на ЯВУ.

Видимо пишет бывалый ассемблерист, другие статьи на этом сайте, в том же ключе.
Но вопросы затрагиваемые в статье, также интерисовали и меня... если ассемблер это самое быстрое и компактное, что может быть, то почему всё на нем не пишется или нету скажем Visual Assembler-a? (т.е. он есть, но это не то что VisualStudio). Почему код компиляторов не столь эффективен по сравнению с кодом ассемблера? Почему не эффективно используются или совсем не используются инструкции (MMX, 3DNOW и т.д.) современных процессоров в копиляторах?

Кроме всего прочего надо углубится в API по самое нихочу, и так для всех осей , и где гарантия что в следущей оси будет та или иная функция. Соотношение времени на изучение всего этого непропорционально тому что будет написано (каких либо качественных приложений с GUI это вряд ли), хотя для написания драйверов знания ассемблера актуально. Pirr, почти во всех современных языках есть возможность ассемблерных вставок, так что критические по скорости участки можно всегда сделать.