>> >> >> А че будет, ежли и правда ключ чему-то приравнять? :-)))
>> >> AM> не понял, ключ приравнять то конЭчно нельзя а вот группу можно
>> >> AM> получилось то что ты и хотел, те групповое присвоение полей в СО> ключе, это
>> >> AM> имелось ввиду ?
>> >> Дык группы присваивать я уже умею ;). А то было б непосредственно ключ
>> >> 🙂
>> VVS> Вот более непонятно отсутствие ошибки при использовании
>> VVS> ключей не от тех файлов в файловых операциях.
>> VVS> Типа SET(File1:Key,File2:Key) и т.п.

СО> есть подозрение что File1:Key,File2:Key — это просто порядковый номер ключа
СО> SET(1,1) — Может работать…. Грубо и наверно не так.
СО> Хотя есть подозрение что в результате вынимается номер ключа….

Немножко не так.

На самом деле все достаточно просто: в данной форме оператора SET() второй параметр используется ТОЛЬКО для определения самой операции — «выставить указатель в ключе по полям данного ключа». А само значение этого второго параметра драйвером не используется. Поэтому в качестве второго параметра может стоять ЛЮБОЙ ключ. Все данные о рабочем файле и ключевым полям берутся из ключа, заданного в качестве первого параметра.

Другое дело, что выглядит это малость странновато и должно бы пресекаться на этапе компиляции. Хотя думаю, что знаю, почему компилятор не делает подобной проверки — в качестве параметров оператора SET() могут быть использованы рефералы на ключи. А их принадлежность какому-либо файлу можно определить ТОЛЬКО во время выполнения.

Кстати! В рамках данной темы поднимался вопрос о сравнении скорости работы цикла чтения записей прямо из файла или посредством View. Как показывает опыт (и не только мой), чтение через View практически НИКОГДА не бывает медленнее прямого чтения из файла. Но, во многих случаях, чтение через View быстрее прямого чтения из файла. Иногда — на порядок!

Основные преимущества по скорости у View в следующих случаях:

• использование фильтрации записей. Особенно, когда фильтр не имеет прямой поддержки со стороны ключей.
• использование порядка сортировки, отличного от имеющихся ключей.
• работа с SQL-таблицами.

Небольшое дополнение к первому пункту: при использовании фильтра, который не «ложиться» ни на один из имеющихся ключей, разница в скорости выборки будет тем больше, чем меньше кол-во записей, удовлетворяющих всем условиям выборки.

PS> Здравствуйте, люди!
PS> Хочу выбрать из большого файла записи со значением полей: code_doc=8 и
PS> gBegDate<=data_last и data_last<=gEndDate. Чтобы не просматривать весь файл,
PS> я решил создать ключ из code_doc и data_last, потом установить режим прохода
PS> по файлу по этому ключу и прыгнуть на первую запись, у которой нужный
PS> code_doc (8). Как это сделать? Насколько я понял, с помощью оператора SET().

PS>   Строчка из описания файла:
PS> code_date_key KEY(MOV:code_doc,MOV:data_last),DUP,NOCASE,OPT

PS>   Кусочек программы:
PS>   OPEN(moving)
PS>   MOV:code_date_key=8
PS>   SET(MOV:code_date_key, < ? > )
PS>   LOOP UNTIL EOF(moving) OR (MOV:code_date_key<>8)
PS>      NEXT(moving)
PS>      ….
PS>   END
PS>   Что здесь неправильно и что должно стоять в качестве второго параметра
PS> SET? Надо ли присваивать что-то MOV:data_last ? Ну тогда уж минимальное
PS> возможное значение, т.к. меня интересуют все даты с этим code_doc. А какое
PS> оно?

Практически на все вопросы данного письма коллеги уже дали ответы. Но, кажется, остался один вопрос без ответа — см. последний абзац. Для присвоения какой-либо переменной наименьшего, возможного для данного типа, значения достаточно Читать далее →

PS>   С неиспользуемыми кусками кода все понятно — это свойство компилятора, а
PS> не линковщика. С lib-модулями — тоже. Например, в Borland C++ lib-файлы
PS> (библиотеки) собираются из obj-файлов с помощью специальной программы.
PS>   А вот с obj-файлами — непонятно. Копирую их другого своего письма:
PS>   Может ли obj-файл, созданный компилятором при
PS> компилировании одной программы, использоваться в другой? Если не может —
PS> тогда понятно (он — «собственность» этого проекта). Если может — что
PS> наиболее вероятно (компилятор пишет что-то вроде «Создан qwe.obj (qwe.clw
PS> был изменен)») — то что, собственно говоря, помещать в этот obj-файл —
PS> процедуры, используемые в одном проекте, или процедуры, используемые в
PS> другом проекте? А если я создам один exe-файл, потом — другой, а потом
PS> вернусь к первому, что делать компилятору с obj-файлами? Как он узнает, что
PS> они были созданы для другого проекта?
PS>   А откуда Вы знаете про SmartLink? Наверное, там это объясняется.

Честно говоря, я этим делом специально не занимался. Но по опыту использования SOURСE — библиотек типа тех, что мы обсуждали по данной теме, могу сказать, что проблем никогда не было. Т.е., когда я собираю приложение, никогда не задумываюсь, а как у меня там с obj-модулями общих библиотек?

Стало интересно — посмотрел. Оказывается — все несколько не так Читать далее →

NT> Можно собрать ToDo-заглушки для библиотек B или условно omit-ить вызовы.

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

Вообщем, я уже решил эту проблему — в самом INC-файле основной библиотеки, используя COMPILE(), объявляю адресные метки всех «плавающих» переменных/процедур из подчиненных библиотек. А в главной библиотеке есть только список их адресов. При сборке библиотеки он пустой. Теперь, при сборке приложения, надо только с помощью Define-меток указать, какие переменные/процедуры будут использоваться в данном приложении и с помощью процедуры регистрации из главной библиотеки заполнить список адресов. Все это делает шаблон. Таким образом, получили эмуляцию динамического определения нужных адресов в статическом режиме! И линкер не ругается, и все работает.

В принципе, все это необходимо для новой библиотеки DynaFile. В этой библиотеке мне необходимо знать точки входа в файловые драйверы. В DLL-режиме их определить элементарно. А в статике их можно определить только если нужные LIB-библиотеки уже подключены к проекту. А так как эти точки входа определяются по символьным меткам драйверов, то эти самые символьные метки надо объявить в библиотеке. А если метка объявлена, но драйвер не подключен, то получаем отлуп от линкера. Вот и получается, что все драйверы подключать к проекту — нонсенс, а знать их адреса в библиотеке надо! И никакие условия компиляции уже не помогут, так как библиотека уже собрана.

>> А вот в данном случае — в библиотеке (А) обьявлено несколько
>> переменных или процедур, которые находятся в нескольких разных
>> библиотеках. При определенных условиях, в приложении некоторые
>> из этих переменных или процедур будут не нужны. Не хотелось-бы и
>> «цеплять» лишние библиотеки, которые не будут использованы.
>> Можно, конечно, для разных таких случаев собрать разные
>> варианты библиотеки (А). Но таких вариантом может быть масса.
>> Да и не красиво это как-то!

MAP
  ClarionDrv,NAME('CLARION')
  TopSpeedDrv,NAME('TOPSPEED')
END

Code
ClaDrvAddr# = Address(ClarionDrv)
TpsDrvAddr# = Address(TopSpeedDrv)

Compile project in Local mode. If drivers CLARION and TOPSPEED linked to project — all Ok.

If driver CLARION or TOPSPEED not linked to project — failed proccess of link. Ok. It is possible to make so, that the process of assembly of the project has not discontinued, and instead of addresses to receive 0?