Rambler's Top100
"Knowledge itself is power"
F.Bacon
Поиск | Карта сайта | Помощь | О проекте | ТТХ  
 Базарная площадь
  
О разделе

Основная страница

Группы обсуждений


Тематический каталог обсуждений

Архив

 
 К н и г и
 
Книжная полка
 
 
Библиотека
 
  
  
 


Поиск
 
Поиск по КС
Поиск в статьях
Яndex© + Google©
Поиск книг

 
  
Тематический каталог
Все манускрипты

 
  
Карта VCL
ОШИБКИ
Сообщения системы

 
Форумы
 
Круглый стол
Новые вопросы

 
  
Базарная площадь
Городская площадь

 
   
С Л С

 
Летопись
 
Королевские Хроники
Рыцарский Зал
Глас народа!

 
  
ТТХ
Конкурсы
Королевская клюква

 
Разделы
 
Hello, World!
Лицей

Квинтана

 
  
Сокровищница
Подземелье Магов
Подводные камни
Свитки

 
  
Школа ОБЕРОНА

 
  
Арсенальная башня
Фолианты
Полигон

 
  
Книга Песка
Дальние земли

 
  
АРХИВЫ

 
 

Сейчас на сайте присутствуют:
 
  
 
Во Флориде и в Королевстве сейчас  03:28[Войти] | [Зарегистрироваться]
Обсуждение темы:
Разработка препроцессора gpre для delphi\freepascal.

Здравствуйте, уважаемые жители Королевства.

Многие находят удобным препроцессор gpre от interbase (для тех, кто с ним не встречался: gpre преобразует помесь sql и некоторого языка x в чистый код на языке х с вызовами функций IB API). Его использование достаточно хорошо описано в ftp://ftp.ibphoenix.com/downloads/60EmbedSQL.zip с подробными примерами в каталоге /examples/ дистрибутива interbase.

Теоретически это самый производительный доступ к данным ib, кроме того, размер программ получается очень маленьким при большой свободе действий. Но реализации interbase для платформ, нам доступных (win32,linux,freeBSD) предусматривают gpre только для c\cpp.

Линковать на уровне объектных файлов или привязывать через .dll\.so - слишком трудоемкая и многодельная работа с возможными многочисленными летательными исходами.

В исходниках interbase/gpre имеется флаг PASCAL для платформ APOLLO, VMS. Там же есть и реализации для ada, fortran, cobol и др. языков на недоступных (нам) платформах. Эксперименты с .epas и анализ исходников показали, что для win32 работает парсер паскаля и не работает генератор кода паскаля (формируется код си).

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

1.Оправдана ли разработка препроцессора gpre для delphi\freepascal.

2.Оправдана ли разработка движка бд для delphi на основе указанного препроцессора для задач с интенсивным обменом данных в дополнение к существующим движкам.

С уважением,,

 Кубанычбек Тажмамат уулу

Количество сообщений на странице

Порядок сортировки сообщений
Новое сообщение вверху списка (сетевая хронология)
Первое сообщение вверху списка (обычная хронология)

Перейти на конкретную страницу по номеру


Всего в теме 16 сообщений

Добавить свое сообщение

Отслеживать это обсуждение


Смотрите также обсуждения:
Free Pascal, Oberon, BlackBox
  • Мысли об Обероне
  • Component Pascal и среда разработки BlackBox
  • FreePascal: реальная альтернатива или OpenSource — блажь?

  • 16—7 | ...>>>
    Всего сообщений в теме: 16; страниц: 2; текущая страница: 1


    № 16   24-01-2002 16:09 Ответить на это сообщение Ответить на это сообщение с цитированием
    Еще один аргумент.

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

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


    № 15   14-01-2002 20:59 Ответить на это сообщение Ответить на это сообщение с цитированием
    to Л.Ге

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


    № 14   14-01-2002 12:23 Ответить на это сообщение Ответить на это сообщение с цитированием
    Да-да!! Конечно!!!! ... Но кто ЭТО может???


    № 13   07-01-2002 06:18 Ответить на это сообщение Ответить на это сообщение с цитированием
    to funcenstain

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

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

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

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

    С уважением,


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

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


    № 11   06-01-2002 17:10 Ответить на это сообщение Ответить на это сообщение с цитированием
    to maxtor

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

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


    № 10   06-01-2002 17:07 Ответить на это сообщение Ответить на это сообщение с цитированием
    Почему тогда борланды не сделали такой препроцессор?


    № 9   06-01-2002 17:06 Ответить на это сообщение Ответить на это сообщение с цитированием
    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.

    С уважением,


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


    № 7   05-01-2002 18:33 Ответить на это сообщение Ответить на это сообщение с цитированием
    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.


    16—7 | ...>>>
    Всего сообщений в теме: 16; страниц: 2; текущая страница: 1


    Добавить свое сообщение

    Отслеживать это обсуждение

    Дополнительная навигация:
    Количество сообщений на странице

    Порядок сортировки сообщений
    Новое сообщение вверху списка (сетевая хронология)
    Первое сообщение вверху списка (обычная хронология)

    Перейти на конкретную страницу по номеру
      
    Время на сайте: GMT минус 5 часов

    Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter.
    Функция может не работать в некоторых версиях броузеров.

    Web hosting for this web site provided by DotNetPark (ASP.NET, SharePoint, MS SQL hosting)  
    Software for IIS, Hyper-V, MS SQL. Tools for Windows server administrators. Server migration utilities  

     
    © При использовании любых материалов «Королевства Delphi» необходимо указывать источник информации. Перепечатка авторских статей возможна только при согласии всех авторов и администрации сайта.
    Все используемые на сайте торговые марки являются собственностью их производителей.

    Яндекс цитирования