1) Dilma, вопрос "качества" кода от версии компилятора зависит конечно. Но и от библиотек не меньше
У тебя есть возможность валожить енто (без исходников биллиотек, хотя бы)
Ибо рытье по никсоидным шанхаям больше напоминает не закачку, а изучение того, как они все там делают.
Накачаешь сотню метров, и через пару месяцев поймешь, что хватило бы и 10...
Да и времени жалко
2) Если он действительно Inline - вроде вообще никаких вопросов нет. Только это не просто св-во кем-то поставленное, это еще и отсутствие линков на него.
А вообще-то и посложнее - одна реализация из полного набора линков вместе с оригиналом.
Это - одна реализация
code_1651.txt
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
|
|||
карма: 9 |
| ||
файлы: 1 | code_1651.txt [1.6KB] [589] |
Ответов: 2125
Рейтинг: 159
|
|||
Вот, кстати, вопрос про Inline: как предполагается события-то в Inline вызывать в новом типе кодогенерации?
|
|||
карма: 1 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Galkov, уменьшу немного пакет gcc - выложу тогда.
tsdima писал(а): как предполагается события-то в Inline вызывать в новом типе кодогенерации?Хороший вопрос... Видимо самое разумное инлайн делать всегда ввиде ф-ции. Иначе я не представляю ни то, как события вызвать, ни то, как получить данные из потока или с точек data. |
|||
карма: 27 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Dilma писал(а): Видимо самое разумное инлайн делать всегда ввиде ф-цииDilma, а вот прочитай, чего ты написал Это вы про ЭЛЕМЕНТ Inline [size=-2]------ Добавлено в 11:08 Тогда надо сделать "имена" недопустимые в целевом языке. И парсить их к скрипте |
|||
карма: 9 |
|
Ответов: 2125
Рейтинг: 159
|
|||
Galkov писал(а): Это вы про ЭЛЕМЕНТ Inline Смотри-ка - угадал Вы тут просто про Inline писали, а я ещё и про элемент такой вспомнил Я думаю, разумнее предусмотреть в Inline какие-нибудь кракозяблы, которые будут преобразовываться CodeGen-ом в вызов функции, ну и функцию тоже генерить, при наличии таких кракозябл, как для event, так и для data. [size=-2]------ Добавлено в 11:18 Опоздал :? |
|||
карма: 1 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
так это несовсем честный инлайн будет. Да и не думаю, что это удобно - невозможно будет код отлаживать где-то еще. Кроме того не понятно пока, что с типами делать. CG про типы внутри Inline совершенно ничего не знает и знать не может. Inline в свою очередь совершенно ничего не знает о том, что ему придет из вне. И никак они об этом друг другу сказать не могут, поскольку являются жителями разных миров. Отсюда вывод: либо CG все и вся преобразует в один тип, заранее понятный для Inline(скажем TData), либо сам Inline пишется из расчета на прием от CG любых типов(перегруженные MakeData).
|
|||
карма: 27 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Про GCC еще: компиляция через gcc.exe или g++.exe тормозит безбожно. Видимо имеет смысл разобраться с опциями по умолчанию и компилировать напрямую через cc1plus.exe
|
|||
карма: 27 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Про GCC еще:
Качество - не лучше FPC. И в остальном - шибко на него похоже Как мало верится, что 3.4, это революция по сравнению 3.2, на котором я пробовал |
|||
карма: 9 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Установка ловушки исключений, это примерно такое (из Дельфей пример):
Поиск дизасмом конструкции mov fs:[*],* - безуспешна |
|||
карма: 9 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Ну ладно, вернемся к нашим баранам
Имеется в виду - кодогенерация. Состряпал невеликий примерчик для размышления: а имеем ли мы право "откладывать" вычисления данных потока до того момента, пока эти данные понадобятся В Дельфи-1 схема такая:
Вроде все очевидно и понятно, а работает неправильно |
|||
карма: 9 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
Galkov, да пример очень хороший Но без некоторой хитрости тут всетаки не обошлось В частности нарушено основное правило построения элемента пакета FTCG, при котором использование левой точки do и нижней точки Result должно всенепременно приводить к заведению внутреннего буфера хранения результата(без специального указания в справке на компонент об отступлении от этого правила). Об этой особенности в хелпе написано кстате.
|
|||
карма: 27 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Ну это правило - просто следствие того, что не все может сегодня CG
Мне так представляется. Что бы проводить некоторые телодвижения, надо как минимум знать, что это кому-нибудь нужно. А мы не знаем. Поэтому (если желаем оптимальности кода) отдаем дальше, тому кто знает. Так ведь по цепочке можно с десяток буферов завести, и заниматься перекачиванием одного и того же... Как распознать-то ситуацию: это переменная хранящая результат, или еще невычисленное выражение И то и другое, вроде Code, и все... Тем более, что и язык обычно не очень хочет давать гарантии, что первый аргумент чего-то будет вычислен раньше второго (или наоборот) |
|||
карма: 9 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
не сказал бы, что это следствие ограничей CG... Уже ддостаточно давно нижние точки типа Result в элементах хранят результат вызова do точки. Иное поведение всегда реализовывалось через, например, reCalk и т.п. Скорее даже приведенный код это пример некорректно выполненой оптимизации, а не ограничений CG...
|
|||
карма: 27 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Смысл не в нижних точках вовсе.
Она как раз "посчиталась" когда нужно. Это данные потока "не посчитались" Нижняя точка как раз соответствует на 100% Дельфи-1. И вполне имеет право такой быть И даже можно один элемент разделить на два с тем же смыслом...
А в том смысл, что мы не имеем право "откладывать" вычисление данных потока. При том объеме информации, которая сегодня у элемента имеется. Даже в том случае, если нижняя точка типа Result не используется Это касается элементов StrCat, Math... Ровно также как и DataToFile. Давай же правильные выводы делать из происходящего Утверждение по силе ровно такое же, как и то, что нельзя вызывать события элемента до вызова метода. Об одном и том же речь фактически... И во что тогда превратится длинная матформула или не менее длинная конкатенация строк... Что-то не увидел я пока в кодах этих элементов воплощения некого правила, которое заставляет сохранять данные чтения в DataToFile, перед парсингом потока. |
|||
карма: 9 |
|
Администрация
Ответов: 15295
Рейтинг: 1519
|
|||
ну да тут есть некоторая необходимость в знание технологии. Для разработчика пакета одним из решений может быть принудительное сохранение результатов работы метода в промежуточной переменной. Причем всегда и не зависимо ни от чего. Видимо так и стоит делать для любого пакета с защитой от дурака. Разрешить как-то иначе эту ситуацию - пока не преставляю, поскольку в общем случае даже знание об использование данных кинутых в поток ничем тут не помогут.
Galkov писал(а): А в том, что мы не имеем право "откладывать" вычисление данных потока.очень даже имеем. По крайней мере до тех пора, пока не выясним об элементах какого уровня идет речь. И для какого пользователя делается пакет, содержащий эти элементы. Напомню, что паралельно с этими рассуждениями идет активное тестирование пакета WEB на базе переделки сайта HiAsm. А это использование больше половины функционала с обширным количеством топологий схемы. |
|||
карма: 27 |
|