Место общения программистов, форум разработчиков БД на Clarion
https://forum.clarionlife.net/
Код: Выделить всё
megaconfig[1] = 1
megaconfig[2] = 0
! save field megaconfig
...
!read field megaconfig
message(megaconfig[1])
message(megaconfig[2])
RaFaeL писал(а):Со строкой-то понятно, а дальше? Получим что-то типа '100010001000100100101'. Как из этого сделать long? Через band? Это как раз из серии не очень красивых решений. Может как-то через OVER получится красивее?
Мне не для памяти, а для ускорения чтения-записи настроек в файл/базу. Чтение 1 ячейки будет явно быстрее чтение 32 ячеек. Быстрее читаются настройки -> быстрее запускается программа -> более радостные пользователи
https://ru.wikipedia.org/wiki/%D0%9A%D0 ... 0%B3%D0%B0Это верное заявление только в теории. На самом деле чтение памяти с дисков происходит блоками. В MS SQL, например, одновременно считывается 8K данных. И если ваша выборка из 32 байт будет считана за одно чтение головки диска, то остальным можно пренебречь, и делать так, как удобно программисту.
хз..., может пора посмотреть на "это" под другим углом и менять методу?RaFaeL писал(а):Да понятно, что string(32) от long по быстродействию вряд ли будет заметно отличаться. Просто мне кажется, как это это неаккуратно - хранить число (а битовая последовательность суть число) в строке. Вон, виндовый калькулятор и то влёт переводит из двоичной в десятичную, а кларион не может чтоль?
Что касается быстродействия вообще. Вот такой пример - приложение хранит ini в каталоге с базой, база на сервере. При работе имеем N putini в сетевой файл. На каждый putini файл меняется отдельно. На каждую запись в файл антивирус сканирует файл. Чтобы антивирусу (локальному) проверить файл, он его в фоне по сети себе перекачивает. В итоге на простейшее закрытие формы имеем "тормоза". Не, понятно что можно настроить файлы и каталоги как исключения, но вот по умолчанию оно работает именно так. И что получается - "у нас ваша программа тормозит", и ведь реально тормозит, если файл под сотню килобайт (а в большом проекте и окон и настроек много). И казалось бы такая фигня как замена N настроек на N/32 настроек может эту проблему вообще снять или сделать не значимой. А так то да, байты в гигабайтах
Код: Выделить всё
PROGRAM
Flags ITEMIZE(1)
eq:Val1 EQUATE ! 1
eq:Val2 EQUATE ! 2
eq:Val3 EQUATE ! 3
eq:Val4 EQUATE ! 4
eq:Last EQUATE(32)
END
FlagsMgr CLASS, TYPE
v LONG, PRIVATE !value, 32 bits
Value PROCEDURE(LONG pValue)
Value PROCEDURE(), LONG
SetBit PROCEDURE(BYTE bitnumber)
ClearBit PROCEDURE(BYTE bitnumber)
GetBit PROCEDURE(BYTE bitnumber), BYTE
ToString PROCEDURE(), STRING
END
MAP
END
fmgr FlagsMgr
CODE
fmgr.Value(170)
MESSAGE(fmgr.ToString())
fmgr.SetBit(eq:Val3)
MESSAGE(fmgr.ToString())
fmgr.ClearBit(eq:Val2)
MESSAGE(fmgr.ToString())
MESSAGE('4th bit = '& fmgr.GetBit(eq:Val4))
FlagsMgr.Value PROCEDURE(LONG pValue)
CODE
SELF.v = pValue
FlagsMgr.Value PROCEDURE()
CODE
RETURN SELF.v
FlagsMgr.SetBit PROCEDURE(BYTE bitnumber)
bits LONG, AUTO
CODE
bits = BSHIFT(1, bitnumber - 1)
SELF.v = BOR(SELF.v, bits)
FlagsMgr.ClearBit PROCEDURE(BYTE bitnumber)
bits LONG, AUTO
CODE
bits = BSHIFT(1, bitnumber - 1)
bits = -(bits + 1) !bitwise NOT
SELF.v = BAND(SELF.v, bits)
FlagsMgr.GetBit PROCEDURE(BYTE bitnumber)
bits LONG, AUTO
CODE
bits = BSHIFT(1, bitnumber - 1)
RETURN CHOOSE(BAND(SELF.v, bits) <> 0)
FlagsMgr.ToString PROCEDURE()
bits LONG, AUTO
bitnumber BYTE, AUTO
sbits STRING(32)
CODE
LOOP bitnumber = 1 TO 32
bits = BSHIFT(1, bitnumber - 1)
sbits[32 - bitnumber + 1] = CHOOSE(BAND(SELF.v, bits) <> 0, '1', '0')
END
RETURN sbits