Массив логических значений в число

RaFaeL

Допустим, есть 32 настройки вида "флажок" (0/1). Все их можно хранить в переменной вида DIM(32). И одновременно это же можно хранить в одной лишь переменной вида LONG. Какое будет самое красивое решение конвертации туда-сюда? Что-то у меня в голове только не очень красивые решения получаются (может потому что понедельник)

Ал · Сообщение Ал » 28 Декабрь 2015, 14:20

string(32)?
flag[...

При объемах памяти в гигабайтах, немного смешно уже побитно хранить ключики.

Ну а вообще, как удобней так и храни.

RaFaeL

Со строкой-то понятно, а дальше? Получим что-то типа '100010001000100100101'. Как из этого сделать long? Через band? Это как раз из серии не очень красивых решений. Может как-то через OVER получится красивее?

Мне не для памяти, а для ускорения чтения-записи настроек в файл/базу. Чтение 1 ячейки будет явно быстрее чтение 32 ячеек. Быстрее читаются настройки -> быстрее запускается программа -> более радостные пользователи

Код: Выделить всё

megaconfig[1] = 1
megaconfig[2] = 0
! save field megaconfig
... 
!read field megaconfig
message(megaconfig[1])
message(megaconfig[2])

и т.д.

Ал · Сообщение Ал » 28 Декабрь 2015, 17:11

RaFaeL писал(а):Со строкой-то понятно, а дальше? Получим что-то типа '100010001000100100101'. Как из этого сделать long? Через band? Это как раз из серии не очень красивых решений. Может как-то через OVER получится красивее?

Мне не для памяти, а для ускорения чтения-записи настроек в файл/базу. Чтение 1 ячейки будет явно быстрее чтение 32 ячеек. Быстрее читаются настройки -> быстрее запускается программа -> более радостные пользователи

https://ru.wikipedia.org/wiki/%D0%9A%D0 ... 0%B3%D0%B0
:=:

kreator

Есть функция BXOR, если что, для побитовых операций. Вот только неудобно это всё. Особенно, если речь идёт о SQL. Oracle вообще, по-моему, хранит числа в огромных ячейках.

Shur

RaFaeL писал(а): Чтение 1 ячейки будет явно быстрее чтение 32 ячеек

Это верное заявление только в теории. На самом деле чтение памяти с дисков происходит блоками. В MS SQL, например, одновременно считывается 8K данных. И если ваша выборка из 32 байт будет считана за одно чтение головки диска, то остальным можно пренебречь, и делать так, как удобно программисту.

RaFaeL

Да понятно, что string(32) от long по быстродействию вряд ли будет заметно отличаться. Просто мне кажется, как это это неаккуратно - хранить число (а битовая последовательность суть число) в строке. Вон, виндовый калькулятор и то влёт переводит из двоичной в десятичную, а кларион не может чтоль?

Что касается быстродействия вообще. Вот такой пример - приложение хранит ini в каталоге с базой, база на сервере. При работе имеем N putini в сетевой файл. На каждый putini файл меняется отдельно. На каждую запись в файл антивирус сканирует файл. Чтобы антивирусу (локальному) проверить файл, он его в фоне по сети себе перекачивает. В итоге на простейшее закрытие формы имеем "тормоза". Не, понятно что можно настроить файлы и каталоги как исключения, но вот по умолчанию оно работает именно так. И что получается - "у нас ваша программа тормозит", и ведь реально тормозит, если файл под сотню килобайт (а в большом проекте и окон и настроек много). И казалось бы такая фигня как замена N настроек на N/32 настроек может эту проблему вообще снять или сделать не значимой. А так то да, байты в гигабайтах

Ал · Сообщение Ал » 28 Декабрь 2015, 18:40

RaFaeL писал(а):Да понятно, что string(32) от long по быстродействию вряд ли будет заметно отличаться. Просто мне кажется, как это это неаккуратно - хранить число (а битовая последовательность суть число) в строке. Вон, виндовый калькулятор и то влёт переводит из двоичной в десятичную, а кларион не может чтоль?

Что касается быстродействия вообще. Вот такой пример - приложение хранит ini в каталоге с базой, база на сервере. При работе имеем N putini в сетевой файл. На каждый putini файл меняется отдельно. На каждую запись в файл антивирус сканирует файл. Чтобы антивирусу (локальному) проверить файл, он его в фоне по сети себе перекачивает. В итоге на простейшее закрытие формы имеем "тормоза". Не, понятно что можно настроить файлы и каталоги как исключения, но вот по умолчанию оно работает именно так. И что получается - "у нас ваша программа тормозит", и ведь реально тормозит, если файл под сотню килобайт (а в большом проекте и окон и настроек много). И казалось бы такая фигня как замена N настроек на N/32 настроек может эту проблему вообще снять или сделать не значимой. А так то да, байты в гигабайтах

хз..., может пора посмотреть на "это" под другим углом и менять методу?

RaFaeL

Дед Пахом писал(а): если не больше 32-х значений, то bflags byte,dim(32) lflags long, over(bflags)

long это же 4 байта? А не 32

RaFaeL

Ал писал(а): хз..., может пора посмотреть на "это" под другим углом и менять методу?

INIClass разве что переписать под работу с БД. Кстати, никто не делал?

RaFaeL писал(а): long это же 4 байта? А не 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

Yufil

Эээ...

evaluate('0' & str & ''b') не преобразует ?