Вверх ↑
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
#181: 2007-07-09 10:40:58 ЛС | профиль | цитата
1) Dilma, вопрос "качества" кода от версии компилятора зависит конечно. Но и от библиотек не меньше
У тебя есть возможность валожить енто (без исходников биллиотек, хотя бы)
Ибо рытье по никсоидным шанхаям больше напоминает не закачку, а изучение того, как они все там делают.
Накачаешь сотню метров, и через пару месяцев поймешь, что хватило бы и 10...
Да и времени жалко

2) Если он действительно Inline - вроде вообще никаких вопросов нет. Только это не просто св-во кем-то поставленное, это еще и отсутствие линков на него.
А вообще-то и посложнее - одна реализация из полного набора линков вместе с оригиналом.
Это - одна реализация
code_1651.txt
карма: 9

0
файлы: 1code_1651.txt [1.6KB] [539]
Ответов: 2125
Рейтинг: 159
#182: 2007-07-09 10:48:44 ЛС | профиль | цитата
Вот, кстати, вопрос про Inline: как предполагается события-то в Inline вызывать в новом типе кодогенерации?
карма: 1

0
Администрация
Ответов: 15294
Рейтинг: 1518
#183: 2007-07-09 10:55:35 ЛС | профиль | цитата
Galkov, уменьшу немного пакет gcc - выложу тогда.

tsdima писал(а):
как предполагается события-то в Inline вызывать в новом типе кодогенерации?

Хороший вопрос... Видимо самое разумное инлайн делать всегда ввиде ф-ции. Иначе я не представляю ни то, как события вызвать, ни то, как получить данные из потока или с точек data.
карма: 26
0
Ответов: 9906
Рейтинг: 351
#184: 2007-07-09 11:08:58 ЛС | профиль | цитата
Dilma писал(а):
Видимо самое разумное инлайн делать всегда ввиде ф-ции

Dilma, а вот прочитай, чего ты написал

Это вы про ЭЛЕМЕНТ Inline

[size=-2]------ Добавлено в 11:08
Тогда надо сделать "имена" недопустимые в целевом языке. И парсить их к скрипте
карма: 9

0
Ответов: 2125
Рейтинг: 159
#185: 2007-07-09 11:18:12 ЛС | профиль | цитата
Galkov писал(а):
Это вы про ЭЛЕМЕНТ Inline

Смотри-ка - угадал Вы тут просто про Inline писали, а я ещё и про элемент такой вспомнил

Я думаю, разумнее предусмотреть в Inline какие-нибудь кракозяблы, которые будут преобразовываться CodeGen-ом в вызов функции, ну и функцию тоже генерить, при наличии таких кракозябл, как для event, так и для data.

[size=-2]------ Добавлено в 11:18
Опоздал :?
карма: 1

0
Администрация
Ответов: 15294
Рейтинг: 1518
#186: 2007-07-09 11:48:35 ЛС | профиль | цитата
так это несовсем честный инлайн будет. Да и не думаю, что это удобно - невозможно будет код отлаживать где-то еще. Кроме того не понятно пока, что с типами делать. CG про типы внутри Inline совершенно ничего не знает и знать не может. Inline в свою очередь совершенно ничего не знает о том, что ему придет из вне. И никак они об этом друг другу сказать не могут, поскольку являются жителями разных миров. Отсюда вывод: либо CG все и вся преобразует в один тип, заранее понятный для Inline(скажем TData), либо сам Inline пишется из расчета на прием от CG любых типов(перегруженные MakeData).
карма: 26
0
Администрация
Ответов: 15294
Рейтинг: 1518
#187: 2007-07-09 22:28:14 ЛС | профиль | цитата
Про GCC еще: компиляция через gcc.exe или g++.exe тормозит безбожно. Видимо имеет смысл разобраться с опциями по умолчанию и компилировать напрямую через cc1plus.exe
карма: 26
0
Ответов: 9906
Рейтинг: 351
#188: 2007-07-10 11:22:53 ЛС | профиль | цитата
Про GCC еще:
  • В выходной файл включается абсолютно все, что в исходнике...
  • Особо тонкое понимания inline обнаруживается...
  • И он еще при этом использует msvcrt.dll
    Качество - не лучше FPC. И в остальном - шибко на него похоже

    Как мало верится, что 3.4, это революция по сравнению 3.2, на котором я пробовал
  • карма: 9

    0
    Ответов: 9906
    Рейтинг: 351
    #189: 2007-07-10 20:32:31 ЛС | профиль | цитата
  • к тому же он еще и работает неправильно Он не ставит деструкторы классов в finaly-блоки, после запуска конструктора.
    Установка ловушки исключений, это примерно такое (из Дельфей пример):
    .004017E7: 33D2                         xor         edx,edx
    .004017E9: 55                           push        ebp
    .004017EA: 689A184000 push 00040189A
    .004017EF: 64FF32 push d,fs:[edx]
    .004017F2: 648922 mov fs:[edx],esp
    Видно, что ему пофиг (лохи ) и в ASM-кодах (ключик -S)
    Поиск дизасмом конструкции mov fs:[*],* - безуспешна
  • карма: 9

    0
    Ответов: 9906
    Рейтинг: 351
    #190: 2007-07-11 11:32:39 ЛС | профиль | цитата
    Ну ладно, вернемся к нашим баранам
    Имеется в виду - кодогенерация.
    Состряпал невеликий примерчик для размышления: а имеем ли мы право "откладывать" вычисления данных потока до того момента, пока эти данные понадобятся
    В Дельфи-1 схема такая:
    Add(FileStream,6049437,287,84)
    {
    FileName="111.txt"
    }
    Add(DataToFile,15064033,287,133)
    {
    Type=7
    link(onGet,15814735:doStrCat,[])
    link(Stream,6049437:Stream,[])
    }
    Add(Button,13260222,154,84)
    {
    Left=140
    Top=90
    link(onClick,7313187:doEvent1,[])
    }
    Add(Hub,7313187,210,84)
    {
    OutCount=3
    link(onEvent1,6049437:doOpen,[])
    link(onEvent2,15064033:doGet,[(254,97)(254,146)])
    link(onEvent3,6049437:doClose,[(264,104)(264,97)])
    }
    Add(StrCat,15814735,343,133)
    {
    link(onStrCat,6420786:doMessage,[])
    link(Str1,15064033:Data,[(349,121)(332,121)(332,178)(293,178)])
    }
    Add(Message,6420786,399,133)
    {
    }
    Для Дельфи-2 сделал такие коды методов
    func doOpen(_data)
      if(not isset(_St))
    var(_St)
    lang(St:PStream)
    lng.decl_priv_var(St, 'PStream')
    end
    println(St, ' := NewReadFileStream(',FileName, ');')
    end

    func doClose(_data)
    println(St, '.free;')
    // TODO
    end

    func Stream()
    return(St)
    end
    func doGet(_data)
      event(onGet, Stream + '.ReadStr')
    end

    func Data()
    return(Stream + '.ReadStr')
    end

    Вроде все очевидно и понятно, а работает неправильно
    карма: 9

    0
    Администрация
    Ответов: 15294
    Рейтинг: 1518
    #191: 2007-07-11 11:53:09 ЛС | профиль | цитата
    Galkov, да пример очень хороший Но без некоторой хитрости тут всетаки не обошлось В частности нарушено основное правило построения элемента пакета FTCG, при котором использование левой точки do и нижней точки Result должно всенепременно приводить к заведению внутреннего буфера хранения результата(без специального указания в справке на компонент об отступлении от этого правила). Об этой особенности в хелпе написано кстате.
    карма: 26
    0
    Ответов: 9906
    Рейтинг: 351
    #192: 2007-07-11 12:05:47 ЛС | профиль | цитата
    Ну это правило - просто следствие того, что не все может сегодня CG
    Мне так представляется.
    Что бы проводить некоторые телодвижения, надо как минимум знать, что это кому-нибудь нужно.
    А мы не знаем.
    Поэтому (если желаем оптимальности кода) отдаем дальше, тому кто знает.

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

    Тем более, что и язык обычно не очень хочет давать гарантии, что первый аргумент чего-то будет вычислен раньше второго (или наоборот)
    карма: 9

    0
    Администрация
    Ответов: 15294
    Рейтинг: 1518
    #193: 2007-07-11 13:30:18 ЛС | профиль | цитата
    не сказал бы, что это следствие ограничей CG... Уже ддостаточно давно нижние точки типа Result в элементах хранят результат вызова do точки. Иное поведение всегда реализовывалось через, например, reCalk и т.п. Скорее даже приведенный код это пример некорректно выполненой оптимизации, а не ограничений CG...
    карма: 26
    0
    Ответов: 9906
    Рейтинг: 351
    #194: 2007-07-11 14:06:49 ЛС | профиль | цитата
    Смысл не в нижних точках вовсе.
    Она как раз "посчиталась" когда нужно.
    Это данные потока "не посчитались"
    Нижняя точка как раз соответствует на 100% Дельфи-1.
    И вполне имеет право такой быть
    И даже можно один элемент разделить на два с тем же смыслом...
    Add(FileStream,6049437,287,42)
    {
    FileName="111.txt"
    }
    Add(DataToFile,15064033,287,133)
    {
    Type=7
    link(onGet,15814735:doStrCat,[(335,139)(335,167)])
    link(Stream,6392024:Var2,[])
    }
    Add(StrCat,15814735,350,161)
    {
    link(Str1,2710534:Data,[])
    }
    Add(DataToFile,2710534,350,112)
    {
    Type=7
    link(Stream,6392024:Var3,[(356,100)])
    }
    Add(GetDataEx,6392024,280,91)
    {
    link(Data,6049437:Stream,[])
    }
    Чтобы прекратить разговоры о нарушении правил
    А в том смысл, что мы не имеем право "откладывать" вычисление данных потока.
    При том объеме информации, которая сегодня у элемента имеется.
    Даже в том случае, если нижняя точка типа Result не используется
    Это касается элементов StrCat, Math...
    Ровно также как и DataToFile.
    Давай же правильные выводы делать из происходящего


    Утверждение по силе ровно такое же, как и то, что нельзя вызывать события элемента до вызова метода. Об одном и том же речь фактически...

    И во что тогда превратится длинная матформула или не менее длинная конкатенация строк...
    Что-то не увидел я пока в кодах этих элементов воплощения некого правила, которое заставляет сохранять данные чтения в DataToFile, перед парсингом потока.
    карма: 9

    0
    Администрация
    Ответов: 15294
    Рейтинг: 1518
    #195: 2007-07-11 14:22:15 ЛС | профиль | цитата
    ну да тут есть некоторая необходимость в знание технологии. Для разработчика пакета одним из решений может быть принудительное сохранение результатов работы метода в промежуточной переменной. Причем всегда и не зависимо ни от чего. Видимо так и стоит делать для любого пакета с защитой от дурака. Разрешить как-то иначе эту ситуацию - пока не преставляю, поскольку в общем случае даже знание об использование данных кинутых в поток ничем тут не помогут.

    Galkov писал(а):
    А в том, что мы не имеем право "откладывать" вычисление данных потока.

    очень даже имеем. По крайней мере до тех пора, пока не выясним об элементах какого уровня идет речь. И для какого пользователя делается пакет, содержащий эти элементы. Напомню, что паралельно с этими рассуждениями идет активное тестирование пакета WEB на базе переделки сайта HiAsm. А это использование больше половины функционала с обширным количеством топологий схемы.
    карма: 26
    0
    Сообщение
    ...
    Прикрепленные файлы
    (файлы не залиты)