Строки и массивы

profiT

mrack писал(а):

как удобнее реализовывать для работы массивы даных будь то строковые или числовые исчисляемые мегабайтами ну для начала хотябы одним мегабайтом.

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

Могу предложить посмотреть в сторону моей "кошки" для испытаний: ~profit/prog/sort/sort.f. Программа читает файл in.txt из той же папки, записывает все слова в массив (массив состоит из двойных ячеек addr u), затем сортирует это дело (пирамидальной сортировкой, ~mlg/SrcLib/hsort.f, также есть аналог с быстрой сортировкой: ~pinka/samples/2003/common/qsort.f), и делает двоичный поиск слова в отсортированном массиве (~profit/lib/binary-search.f).

Другое дело что...

mrack писал(а):

...у меня нужда в строке размером в мегабайт искать словосочетания.

Ну так и надо заводить строку размером пусть хоть в сто мегабайт. Какая разница?.. А чтобы искать, обычный SEARCH должен тут помочь.

mrack писал(а):

...а потом еще и сортировать их, внутри того же массива.

Ну, пока что "бриллианты почти совсем не видны". В смысле, что ещё за массив, только про строку же было сказано?

PS. Хм, "Кошка" глючит, похоже... Причём грабли старые.

mrack_

спасибо взгляну обязательно
"массив" "строка" прошу прощения за расплывчатую терминологию,
просто я использовал "строку" (единая непрерывная область памяти) для хранения последовательности строк разделенной 0x0A0D
а проблема моя как мне кажется в том что вместо областей памяти создаваемых по ALLOT правильно использовать ALLOCATE.
проверю позже экспериментами

chess

mrack_ писал(а):

а проблема моя как мне кажется в том что вместо областей памяти создаваемых по ALLOT правильно использовать ALLOCATE

Точно, надо заменить ALLOT

Код:

: ALLOT ALLOCATE THROW ;

mrack_

хмм
а я чайник мне можно

Код:

SPF\src\compiler\spf_compile0.f  
: ALLOT ( n -- ) \ 94
  DP +!
;
SPF\src\win\spf_win_memory.f 
: ALLOCATE ( u -- a-addr ior ) \ 94 MEMORY
  CELL+ 9 ( HEAP_ZERO_MEMORY) THREAD-HEAP @ HeapAlloc
  DUP IF R@ OVER ! CELL+ 0 ELSE -300 THEN
;

плюс насколько я помню где то картинка пролетала области памяти выделяются разные по ALLOT и ALLOCATE,
и возможно фишка в способе применения или еще в чем (в моем недопонимании чеголибо как вариант) но используемые выделения по ALLOT увеличивают размер екзе файла

chess

chess писал(а):

Точно, надо заменить ALLOT
Код:
: ALLOT ALLOCATE THROW ;

Написал неправильно
Надо было:

Код:

: ALLOC \ U --> A-BEG
ALLOCATE THROW ;

Применение

Код:

VARIABLE MASSIV   \  или USER MASSIV 
1000000 ALLOC MASSIV !  \ в MASSIV занесли начальный адрес массива (A-BEG) в 1000000 байт

Создание больших массивов в кодофайле нежелательно (например CREATE 1000000 ALLOT), так как кодофайл уйдет в екзешник и он станет раздутым, а кроме того можно напороться на несвободную память, факт наличия которой ALLOT не определяет.

mrack_

спасибо chess

ld

А вот допустим если надобно реализовать арифметику больших чисел, ( целые, >0) т.к. 64 бит мне уже мало

, чем лучше воспользоваться для хранения чисел, массивами или строками, если важна скорость вычислений?
P.S. Ещё по теме, что быстрее должно работать, MOVE или CMOVE?

chess

ld писал(а):

А вот допустим если надобно реализовать арифметику больших чисел, ( целые, >0) т.к. 64 бит мне уже мало , чем лучше воспользоваться для хранения чисел, массивами или строками, если важна скорость вычислений?
P.S. Ещё по теме, что быстрее должно работать, MOVE или CMOVE?

1. Лучше воспользоваться массивами.
2. Быстрее CMOVE.

ld

2chess: спасибо

Строки и массивы

Кто сейчас на конференции