Еще один аргумент.

При разработке при помощи гпре программы, подключающейся к нескольким базам, гпре не позволяет использовать вызовы UDF и хранимых процедур. Выход - обращения к разным базам разносить в разные файлы, что неявно следует из документации по InterBase "Embedded SQLGuide", "один database handle можно использовать только внутри одного файла исходников". Следовательно, если разместить обращения к разным базам в разные файлы исходников (и далее в разные объектные файлы), то в пределах каждого файла исходников работа идет в однобазовом режиме, что позволяет использовать UDF, хранимые процедуры и т.д. Так оно и получается. Проблема только в том, что некоторые внешние переменные, добавляемые gpre, добавляются в оба обработанных файла и в некоторых случаях это может привести к неоднозначности и проблемам трудноуправляемых глобальных переменных.

Реализация gpre для паскаля позволила бы не допускать в принципе такой проблемы благодаря наличию в паскале целостной концепции единицы трансляции - модуля. Достаточно дополнительные переменные, вставляемые гпре, не выносить за пределы видимости implementation.

to Л.Ге

Уточните, пожалуйста, вопрос.

Да-да!! Конечно!!!! ... Но кто ЭТО может???

to funcenstain

>Кстати, чем вас так расстроил grpe-c?
Да, ничем. Сейчас большую часть работы я выполняю на нем. Некоторые вещи делаются бысрее, чем на дельфи. А к си я уже привык.

>Я такие вещи при работе с grpe устранял на С при помощи макросов.
Поделитесь, пожалуйста, опытом (примером).

>Только, если честно, как вы хотите это прикрутить (в смысле, без существенной модификации архитектуры приложений, критических к операциям доступа (Kylix,Perl) с IB) к уже работающему ПО ?

В завсисмости от того, какое это ПО. Если честно, то, что хорошо работает, пусть работает себе на здоровье, а новые вещи лучше использовать в новых проектах задачах.

С уважением,

To №9.
>interbase. Это будет быстрее интерпретируемого perl и проще, чем  >gpre+gcc, размер (от 50k) будет меньше, чем у сделанного в kylix >модуля для apache
      Верно, быстрее Perl, но нельзя сравнивать grpe+gcc с интерпретатором. У него же совершенно другие задачи. (Вспомним аббревиатуру ?)

Да, для таких небольших узкофункциональных программ Ваша идея, пожалуй, подойдет. Кстати, чем вас так расстроил grpe-c? (в смысле работа со строками и т.д.). Поработав на IB  под RedHat я пришел к выводу, что это очень мощное вспомогательное средство. Одна из главных вещей, которая мне понравилась - полная поддержка С. А ошибки  - это скорее непривычка к С-й организации работы с char*. Я такие вещи при работе с grpe устранял на С при помощи макросов.
Очень сильное подспорье.
  Только, если честно, как вы хотите это прикрутить (в смысле, без существенной модификации архитектуры приложений, критических к операциям доступа (Kylix,Perl) с IB) к уже работающему ПО ?

to maxtor

>Почему тогда борланды не сделали такой препроцессор?

Видимо, из маркетинговых соображений. Сначала им надо было позиционировать на рынке BDE, потом IBX, dbexpress.

Почему тогда борланды не сделали такой препроцессор?

to funcenstatin

>Но зачем тогда grpe ? fibplus в одиночку неплохо cправится.
Верно. Fibplus противопоставлялся против решения gpre-bcc-dll-delphi.
А в теме речь идет о то, что даст решение gpre-pascal. При этом fibplus не используется. Это не означает полного отказа от fibplus, просто у программистов будет больше возможности выбора: для приложений с изменяющимися в runtime запросами лучше использовать fibplus (размер бинарника от 500k), а для консольных программ, приложений с большим объемом обработки данных или жесткими требованиями к размеру использовать gpre-pascal (размер бинарника от 50k ) или использовать их совместно, например, для простых запросов о версии базы, дате и времени сервера, системных данных и др. подойдет gpre-pascal (чтобы не плодить во множестве компоненты на форме), а для интерактивной работы с данными будет лучше fibplus.  Отдельный препроцессорный модуль на pascal+EXEC SQL можно добавить в дельфи-проект на уровне исходников и произвести обычную компиляцию.

>Как я понял, Вы хотите заточить свое приложение только под Win32.
В случае предлагаемого Вами решения gpre-bcc-dll-delphi так и будет.
А связка gpre-pascal может компилироваться и использоваться также и в linux и freebsd, для которых также есть порт freepascal, например, для создания межбазовых серверных приложений или эффективно работающих cgi, общающихся с interbase. Это будет быстрее интерпретируемого perl и проще, чем  gpre+gcc, размер (от 50k) будет меньше, чем у сделанного в kylix модуля для apache.

Поработав с gpre-c (без плюсов) можно познать удобство этого механизма, не зря gpre используют при сборке самого interbase. Все НЕУДОБСТВА от си (вылетает при неправильной работе со строками и т.д.). Основная цель разработки gpre-pascal - это привнести удобства gpre в pascal, тем более код генератора кода pascal (масло маслянное) для платформ apollo, vms существует, надо только его оживить для win32/linux/freebsd.

С уважением,

To №7
Так, видимо вы неправильно меня поняли.  Кромсать-не кромсать, я предложил делать ДЛЛ _сразу_ на BCC55. Естественно, что дробить на "fined-grained" objects(units ;) свое приложение никто не будет. Как я понял, Вы хотите заточить свое приложение только под Win32 (используя fibplus). Но зачем тогда grpe ? fibplus в одиночку неплохо справится. Если уж совсем припрет (говорят, лень прогресс двигает), то можно написать небольшой синтаксический анализатор и определить грамматику для _внутреннего_ использования среди группы девелоперов, после чего результат обработки подавать за выход grpe (обеспечив соотв. формат). Но вообще, в таком исполнении (на Вин32) по-моему, использовать grpe нецелесообразно. Если только у Вас сложная задача, и требуется создание динамических запросов от GUI (если не обойтись никак stored procs) пользователя, то ... может быть, но все равно не лучший выход.

to fruncenstein

>Не проще (не говорю эффективнее) реализовать на С++ (bcc5.5 etc.) >модуль, который как *.obj потом прилинковать к приложению на Дельфи?

все gpre-шное для win32 мы сейчас делаем только на bcc55. Были попытки и подлинковать к Дельфи-приложению, но при этом пришлось носить за собой все используемые функции из gds32.lib, import32.lib, cw32mt.lib, так как *.lib файлы дельфи не видит, а расчленять их на отделные *.obj файлы (число которых растет каскадно) - малопроизводительное занятие. Для дельфи проще все сделать на fibplus, а bcc - шные вещи вынести в командно-строчные бинарники.

>А потом превратить его в DLL( на Win32)
После подлинковки незачем кромсать дельфи-приложение на dll без особой причины. Другое дело - собрать dll в bcc55 и вызывать его функции. Но опять же, слишком малая производительность разработки (по сравнению с fibplus и др.). Наличие gpre для pascal позволило бы приблизиться к уровню производительности разработки gpre-c с прямым включением полученных модулей (в исходниках) к дельфи-проекту.

>С подвязкой сокетов под мультиплатформенность, правда, сложней.
В gpre нет необходимости работать непосредственно с сокетами, так как сетевое общение производится штатными средствами gds32.dll/libgds32.so.