Объясните пожалуйста дельфисту, что такое шаблоны в Си?

← →
oxffff © (2007-11-05 23:30) [120]

> Юрий Зотов © (05.11.07 22:43) [119]
> > Сусл © (05.11.07 21:39) [112]
>
> Дима, я не то что за месяц, я и за 3 месяца вряд ли это
> напишу. И никто не говорил, что это простая задача. Но решаемая.
>

Есть готовые реализации парсера Delphi. Причем с исходниками.

DGrok?

← →
oxffff © (2007-11-05 23:32) [121]

> Mystic © (05.11.07 21:33) [110]
> > Которые могут быть размещены в регистре при размере value
>
> > type в int.
>
> Может быть и могут, я не видел.
>
> В .NET нет понятия регистров. Но есть понятие evaluation
> stack, который естественно при компиляции в native код транслируется
> на набор регистров и слоты стека потока.
>
> Это понятно. Я говорю о том, как JIT в реализации .NET на
> платформе x86 использует регистры.
>
> Что касаемо передачи stdcall, то все передается через стек.
>
> Это справедливо для 32-х битной среде. В 64-х битной среде
> STDCALL == FASTCALL.

Я тогда не понял. В чем притензия к JIT Compiler"у?
Насколько я понял stdcall использовалось для вызова Native кода.

← →
Сусл © (2007-11-05 23:37) [122]

> Юрий Зотов © (05.11.07 22:43) [119]

Юра, скоро мы все войдем в век шаблнов в Дельфи. Вот тогда и поговорим :р

← →
oxffff © (2007-11-05 23:38) [123]

> Сусл © (05.11.07 23:37) [122]

Дмитрий, согласись это же не плохо?

← →
Сусл © (2007-11-05 23:42) [124]

> oxffff © (05.11.07 23:38) [123]
> > Сусл © (05.11.07 23:37) [122]
> Дмитрий, согласись это же не плохо?

Сергей, знаешь какой бардак начнется?
:)

← →
oxffff © (2007-11-05 23:49) [125]

> Сусл © (05.11.07 23:42) [124]

Тогда добавят специально раздел "Шаблоны".
:)

Меня больше другое волнует.
Сообщество Delphi программистов, всегда ставили стороникам С++ в укор их наличие.
Сейчас для нас это вопрос времени.
Хотя я не знаю и думаю, на что будут похоже compile time их реализация в win32 на template или generics.

Что нам говорить теперь им.

:)

P.S. Зато искренне и откровенно. IMHO

:)

← →
Черный Шаман (2007-11-06 00:07) [126]

> Alkid © (05.11.07 22:24) [118]
>
>
> > Там есть ClassName и Published свойства которые можно
> достать
> > в рантайм. Все отлично и без шаблонов можно сделать с
> использованием
> > особенностей RTTI, причем все отлично читается и понимается
> > потом.
>
> Тем, что
> 1. Этот контейнер не ловит во время компиляции попыток положить
> в него объект не того класса. Он их ловит только во время
> исполнения.

А чем плохо? Лично у меня в одном из проектов все данные по по конкретному элементу брались из xml и на лету создавались динамические объекты с перегрузкой методов выполнения по их символьным значениям(с наследованием и прочим). Этакая объектная база данных вышла для проектирования визуального интерфейса.

Это удобнее тем, что программу можно создавать на основе общего ядра, надстроечных xml файлов и скриптов(где все ресурсоемкие функции вынесены в ядро системы).

На современных системах(Celeron2000+, 256Мб+) тормозов не видно, а гибкость и простота налицо.

Кроме того S.T.A.L.K.E.R. полностью написан на XML + общее ядро.

← →
Alkid © (2007-11-06 10:33) [127]

> А чем плохо? Лично у меня в одном из проектов все данные
> по по конкретному элементу брались из xml и на лету создавались
> динамические объекты с перегрузкой методов выполнения по
> их символьным значениям(с наследованием и прочим). Этакая
> объектная база данных вышла для проектирования визуального
> интерфейса.
> Это удобнее тем, что программу можно создавать на основе
> общего ядра, надстроечных xml файлов и скриптов(где все
> ресурсоемкие функции вынесены в ядро системы).

Наличие типизированного контейнера их шаблона такую возможность ничуть не приуменьшает :) То же самое прекрасно делается и на шаблонах, только при этом у тебя меньше накладных расходов во время выполнения и принципиально ликвидируется вероятность запихивания в контейнер "левого" объекта.

В твоей же схеме либо проверять всё в run-time при помощи RTTI, либо вся система становится уязвима для неправильно написанных XML-скриптов с конфигурацией. А что бы этого не было, придётся делать свою систему проверки валидности этих скриптов.

← →
Юрий Зотов © (2007-11-06 10:41) [128]

> Сусл © (05.11.07 23:42) [124]

А что в этом плохого? Чем больше возможностей мне дает язык при сохранении своей строгой типизированности, ясного, легко читаемого синтаксиса и прочих Паскалевских традиций - тем для меня лучше.

А как мне этими возможностями воспользоваться и не допустить бардака - ну это уж разберемся, не впервой.

← →
Mystic © (2007-11-06 12:59) [129]

> Да я и не спорю, просто тогда это и получаются те самые
> "шаблоны в Дельфи", о ненужности которых постоянно твердят
> некоторые участники форума.

Сделать это несложно, но это никто не сделал. Значит не очень то и хотелось :)

Если говорить о шаблонах, то мне больше нравится их реализация в Ada. Вещь иногда приятная, но не жизненно необходимая. В большинстве случаев мне хватало обычного класса TList. Тот факт, что не было проверки типов времени компиляции меня не очень то и сдерживал: из своей практики я не помню, ни одной серьезной проблемы, которая бы возникла в результате этого.

Одно из различий Delphi и C++ состоит в том, что Delphi имело определенный вектор развития, основанный в первую очередь на практических потребностях. Когда становился вопрос шаблоны vs поддержку COM, расширение возможностей компонент и т. д., то шаблоны были в проигрыше. Потому как вещь приятная, но не настолько необходимая. Текущие средства покрывают 95% всех задач, а в случае 5% нетрудно сделать Copy + Paste и т. д.

Фичи в C++ добавлялись комитетом. Насколько я понимаю этот процесс, шел он примерно так: возникал вопрос: "а не добавить ли нам такую-то возможность?" Потом шло обсуждение. Принималась резолюция: "Да, это круто". Добавляли в стандарт. Потом она реализовывалась в компиляторах. Потом иногда находились грабли, приходилось делать заплатки (так появился, например, explicit). Как сейчас помню, когда читал первое издание Страуструпа (зеленое такое), увлекся обработкой исключительных ситуаций (как это здорово!). Поставил новый Borland C++ 3.1, а он этих слов и не понимает :( Но выбор компиляторов C++ тогда был: Semantec, Watcom, ... BTW, Потом я узнал, что исключительные ситуации давно уже были реализованы в Ada :)

Вообще, например, по ознакомительным статьям мне более импонирует язык D, потому как C++ очень уж завязан на недостатки C. Ну и Ada :)

← →
Mystic © (2007-11-06 13:17) [130]

> Я тогда не понял. В чем притензия к JIT Compiler"у?
> Насколько я понял stdcall использовалось для вызова Native
> кода.

Нет, не native кода, я обычного кода

Претензия в том, что
1. По стандарту вызова метода, параметры передаются в регистрах.
2. JIT компилятор упорно размещает переменные типа class в стеке (может это надо для сборки мусора или еще чего, не знаю).
Поэтому, при вызове метода происходило следующее
1. Аргументы копировались в регистры
2. Вызов функции
3. Инициализация cтека внутри функции
4. Копирование аргументов из регистров в стек
5. Выполнение кода функции
Согласись, это неэффективно?

Тем более на каждый вызов функции :) Ну и по тому коду, что я видел, .NET Framework абсолютно не понимал, зачем нужны регистры процессора, большая часть их которых просто не использовалась, разве что для передачи параметров :)

> Меня больше другое волнует.
> Сообщество Delphi программистов, всегда ставили стороникам
> С++ в укор их [шаблонов] наличие.

Для меня не наличие шаблонов, а их реализация :) Сейчас то сообщения об ошибках более-менее грамотные стали. А так как по мне, компилятор слишком много работы делает, которую тяжело проконтроллировать, сам что-то там себе выводит, хотя мне несложно было бы и подсказать. Да и спокойнее :)

← →
Mystic © (2007-11-06 14:30) [131]

Кстати, еще одна попытка сравнить C++ и C# по скорости:
http://rsdn.ru/forum/Message.aspx?mid=2720100&only=1
Код C++ быстрее в 10 раз :)

← →
oxffff © (2007-11-06 14:49) [132]

> Mystic © (06.11.07 13:17) [130]

Method calls
Instructions emitted by the CIL code generator contain sufficient information for different implementations of the CLI to use different native calling conventions.

Получается, что способ приема/передачи параметров оставлен на усмотрение JIT.
И детерминированно мы можем (точнее должны) указать способ вызова
только для вызова native кода.

Что касаемо конкретного случая.
То я не склонен думать, что это неэффективно.
И вот почему

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

:)

← →
oxffff © (2007-11-06 15:00) [133]

> 2. JIT компилятор упорно размещает переменные типа class
> в стеке (может это надо для сборки мусора или еще чего,
> не знаю).

А как вы к managed объекту обратитись без ссылки на него. :)
Если есть переменная типа O - объектная ссылка в терминах VES.
То она является корнем, которая анализируется при последующем анализе при сборке мусора.
Но сам объект размещен в управляемой куче.

← →
oxffff © (2007-11-06 15:08) [134]

> Тем более на каждый вызов функции :) Ну и по тому коду,
> что я видел, .NET Framework абсолютно не понимал, зачем
> нужны регистры процессора, большая часть их которых просто
> не использовалась, разве что для передачи параметров :)

Я безусловно допускаю и такой вариант.
А нельзя ли этот код IL код и соответствующий x86 код посмотреть?
И какая версия JIT?

← →
Mystic © (2007-11-06 15:20) [135]

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

Хорошо, давая я просто приведу пример, а ты объяснишь, почему код, который сгенерировал JIT компилятор, эффективен?

enum Field { A1, B1, C1, D1, E1, F1, G1, H1, A2, B2, C2, D2, E2, F2, G2, H2, A3, B3, C3, D3, E3, F3, G3, H3, A4, B4, C4, D4, E4, F4, G4, H4, A5, B5, C5, D5, E5, F5, G5, H5, A6, B6, C6, D6, E6, F6, G6, H6, A7, B7, C7, D7, E7, F7, G7, H7, A8, B8, C8, D8, E8, F8, G8, H8 } public static System.UInt64 MakeBitboard(Field A) { return (System.UInt64)1 << (System.Byte)A; }

Получаем следующий нативный код:

; public static System.UInt64 MakeBitboard(Field A) ; { 00000000 mov dword ptr [rsp+8],ecx 00000004 sub rsp,28h 00000008 nop 00000009 mov rax,64280013128h 00000013 mov eax,dword ptr [rax] 00000015 test eax,eax 00000017 je 000000000000001E 00000019 call FFFFFFFFFF78DD50 ; return (System.UInt64)1 << (System.Byte)A; 0000001e movzx ecx,byte ptr [rsp+30h] 00000023 and ecx,3Fh 00000026 mov eax,1 0000002b shl rax,cl 0000002e jmp 0000000000000030 00000030 add rsp,28h 00000034 rep ret ; }

Итак, параметр передается в ecx. Далее я так восстановил смысл проивходящего:
Строка 0000 запихивает его в стек
Строка 0004 делает стековый фрейм функции (-28h)
Строка 0008 это пресловутый nop, чтобы пользователь покупал новый процессор
Строки 0009-0019 см. строку 0008. Расшифровать не удалось
Строка 001e копируем параметр из стека в регистр ecx (+8р -28р = 30р)
Строка 0023 контрольное изнасилование в голову
Строка 0026 это наша единица (а почему не rax)?
Строка 002b сдвиг!
Строка 002e чтобы не тормозило
Строка 0030 восстанавливаем стек
Строка 0034 покидаем функцию

Ну ладно, не знает JIT что есть специальная ассемблерная команда, которая позволяет установить любой бит по индексу. Но чем этот вариант производительнее простого:

mov rax, 1 shl rax, cl ret

?

← →
Mystic © (2007-11-06 15:24) [136]

Еще примеры на пятой странице:
http://delphimaster.net/view/15-1193871434/

← →
homm © (2007-11-06 15:27) [137]

> [135] Mystic © (06.11.07 15:20)
> Строка 0008 это пресловутый nop, чтобы пользователь покупал
> новый процессор

+1 :)

← →
homm © (2007-11-06 15:32) [138]

Сори за оффтоп, но стало интересно, в х86 регистры rXX — это раширенные регистры eXX, или же осабнячком? т.е. младшее двойное слово rax, например, является eax ?

← →
Mystic © (2007-11-06 15:34) [139]

Да, rax это 64-битный регистр, младшее двойное слово это eax. Есть еще дополнительные 64-битные регистры r8, r9, r10, r11, r12, r13, r14, r15

← →
homm © (2007-11-06 15:44) [140]

> Есть еще дополнительные 64-битные регистры r8, r9, r10,
> r11, r12, r13, r14, r15

Я только недавно оправился от шока, что у меня есть 8 128-и битных регистров xmm ,и вот опять новый шок %)

← →
Mystic © (2007-11-06 15:52) [141]

Расслабся, они не используются ;)
Хотя когда знакомый перешел в 32-битного Gentoo на 64-битный, то на глазок разница по скорости была примерно в полтора-два раза :) Но там можно все перекомпилировать, а под Windows большинство программа все равно *32. Хотя рыбка и заппа молотят варианты пошустрее :)

← →
oxffff © (2007-11-06 15:58) [142]

> Хорошо, давая я просто приведу пример, а ты объяснишь, почему
> код, который сгенерировал JIT компилятор, эффективен?

Здесь я могу только констатировать обратное.
Хотя release версия дает чуть лучший код, но это совершенно не меняет суть.
Над JIT (x86) еще нужно работать.

← →
Alkid © (2007-11-06 16:17) [143]

> Сделать это несложно, но это никто не сделал. Значит не
> очень то и хотелось :)

Ну "никто не сделал" - это Вы погорячились :) Тут летали ссылки на разного рода реализации шаблонов в Дельфи, от наколеночных, до более серьёзных.

> Фичи в C++ добавлялись комитетом. Насколько я понимаю этот
> процесс, шел он примерно так: возникал вопрос: "а не добавить
> ли нам такую-то возможность?" Потом шло обсуждение. Принималась
> резолюция: "Да, это круто". Добавляли в стандарт. Потом
> она реализовывалась в компиляторах. Потом иногда находились
> грабли, приходилось делать заплатки (так появился, например,
> explicit). Как сейчас помню, когда читал первое издание
> Страуструпа (зеленое такое), увлекся обработкой исключительных
> ситуаций (как это здорово!). Поставил новый Borland C++
> 3.1, а он этих слов и не понимает :( Но выбор компиляторов
> C++ тогда был: Semantec, Watcom, ... BTW, Потом я узнал,
> что исключительные ситуации давно уже были реализованы
> в Ada :)

Ну, на самом деле не всё так однозначно. Предшественник С++ - C with classes возник из весьма практической задачи, которую Страуструп решал в своё время. И С++ вначале тоже делался без этой бюрократической волокиты.
Так что С++ тоже имел свой вектор в развитии.

Другое дело, что язык, развиваемый разношёрстным комитетом всегда будет развиваться медленнее, чем проприетарный язык, развиваемый какой-нибудь энергичной корпорацией или даже Open-Source сообществом. Это мы сейчас можем наблюдать на примере будущего стандарта С++0х, принятие которого анонсировано аж на 2009-ый год (а, значит, реальная поддержка в инструментальных средствах появится не раньше 2010-2011-годов).

Хотя списывать С++ со счетов ещё рано, уже можно сказать, что звёздный час С++ прошёл. С другой стороны, он пока остаётся единственным игроком на поле кроссплатформенных ОО-языков для системного программирования.

Лично "для себя" (т.е. для программирования "для души") я пока выбрал С# 2.0 и хочу пощупать С# 3.0

> Вообще, например, по ознакомительным статьям мне более импонирует
> язык D, потому как C++ очень уж завязан на недостатки C.
> Ну и Ada :)

ИМХО, D ещё сыроват. :)

← →
oxffff © (2007-11-06 16:44) [144]

to Mystic ©
Хотя чисто технически задача решается.
Поскольку используется peephole.
Тогда добавить peephole шаблон + увеличить глубину peephole.

← →
Mystic © (2007-11-06 16:54) [145]

И что это за зверь peephole?

← →
oldman © (2007-11-06 16:57) [146]

> Объясните пожалуйста дельфисту, что такое шаблоны в Си?

> И что надо отвечать на нападки агрессивных сишников?

На нападки отвечать надо.
Но знать, что такое шаблоны, не надо.
Что, кирпичи отменили? Или ПМы? Или АКМы?

ЗЫ: А по поводу шаблонов - литературу почитать лень?

← →
oxffff © (2007-11-06 17:08) [147]

> Mystic © (06.11.07 16:54) [145]
> И что это за зверь peephole?

http://en.wikipedia.org/wiki/Peephole_optimization

← →
Mystic © (2007-11-06 17:14) [148]

Ну... с учетом того, что CLI instruction set по сути сокращенная форма исходников, то улучшить оптимизацию JIT можно. Но пока... маємо те що маємо.

>на примере будущего стандарта С++0х, принятие которого анонсировано аж на 2009-ый год >(а, значит, реальная поддержка в инструментальных средствах появится не раньше >2010-2011-годов).
многие его нововведения уже реализованы в современных компиляторах.

> многие его нововведения уже реализованы в современных компиляторах.

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

> Верю. И что? :)

А то, что думать как будто все ждут нового стандарта, и начнут его реализацию только после после утверждения - не правильно. Нет, работа уже идет, а следовательно дает возможность разработчикам компиляторов, основываясь на открытых спецификациях(пусть и пока черновых), обкатать новые возможно и попробовать их в деле. Чтобы не получилось как с экспортом шаблонов например. Поэтому процесс внедрения будет вполне безболезненный и достаточно быстрый.

> Поэтому процесс внедрения будет вполне безболезненный и
> достаточно быстрый.

Не, ну я только за, если оно действительно все так хорошо.
Кстати, они там reflection так и не включили в стандарт?

← →
Фрейм (2007-11-07 01:43) [153]

> Alkid © (01.11.07 14:18) [31]
>
>
> > Я знал, что мне опять расскажут байку про контейнеры.
>
> Я примерно 5 лет программировал на дельфи на прошлой работе.
> За это время я бессчётное количество раз реализовывал разного
> рода контейнеры, пока не открыл способ, описанный в [29].
> На этом я потерял столько времени и наделал столько ошибок,
> переписывая в n+1-ый раз методы GetCount, GetItem, Add,
> Remove и Clear, что могу тебе авторитетно заявить - про
> контейнеры, это не байки, а суровая правда жизни.

Можно с этого места по подробнее? Что именно приходилось переписывать?
Может вы просто чего-то не знали о Дельфи? Использование фреймов, например?

> [153] Фрейм (07.11.07 01:43)
> Может вы просто чего-то не знали о Дельфи? Использование
> фреймов, например?

О, да, как же, как же, вот фреймы тут как-раз, как-раз уместно упомянуть. Вы бы еще про Тулбар сказали, тоже ведь «контейнер».

← →
Фрейм (2007-11-07 04:07) [155]

Удалено модератором
Примечание: Ты еще совочком швырнись, да.

Читал ветку. Много думал. Понял, что я тварь дражжащая и пошел вешаться: я любил бейсик...

Код, приведенный в ссылке [130] ужасен. Причем как С#, так и C++. Я уж не говорю, что на моем ноуте в release версии C# обставил C++. Даже, пардон, не в 10 раз.

> Я уж не говорю, что на моем ноуте в release версии C# обставил
> C++.

Ты что-то напутал. Возможно ты хотел сказать в debug версии.

> Можно с этого места по подробнее? Что именно приходилось
> переписывать?
> Может вы просто чего-то не знали о Дельфи? Использование
> фреймов, например?

Не, ну я конечно каких-то тонкостей Дельфи и VCL не знаю, но не надо меня полным ослом считать :) Фреймы я знаю и активно их использовал.
Вот только не прикину, как фреймы относятся к теме данного топика.
Можешь поясните?

> Код, приведенный в ссылке [130] ужасен. Причем как С#, так
> и C++. Я уж не говорю, что на моем ноуте в release версии
> C# обставил C++. Даже, пардон, не в 10 раз.

Что конкретно там тестировалось? Код из [130]?
А методику можешь рассказать?
Просто разные исследования авторитетно заявляют разные вещи, от превосходства кода С# над С++ на порядок по скорости выполнения до наоборот.

Объясните пожалуйста дельфисту, что такое шаблоны в Си? Найти похожие ветки