Проблемы с созданием типа данных
 

Пишу словарь itap на мобильник, но есть проблема - массивы из строк жрут много хипа. Поэтому решил создать сой тип - массив из 30 символов. Т.к. строка занимает 256 это должно увеличить количество записей почти в 10 раз. Вот код:
type
ch=array[1..30] of char;
var
sl: array[1..1000] of ch;

При компиляции вылетает ошибка:
Fatal error: Internal error #024

каким способом можно её устранить?

Re: Проблемы с созданием типа данных
 

Как я понял, ошибка не в коде, а в самом MP. Как вариант - слишком объёмный тип - попробуй сделать массив поменьше.

Re: Проблемы с созданием типа данных
 

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

Re: Проблемы с созданием типа данных
 

Пробовал меньше массив 30 символов и 90 слов та же ошибка. Хранятся они как раз в ресурсе а при запуске загружаются в массив. Если при нажатии первой буквы загружать соответствующие словари из ресурса - это займет много времени, а зачем тогда iTap если Таром можно набрать быстрее.

Видимо прийдётся загружать по несколько слов в одну строку массива(пока не закончаться символы в строке).

Re: Проблемы с созданием типа данных
 

Двухмерный массив объявлять не пробовал?
Var s: array[1..1000, 1..30] of char;
Всё пашет.

Re: Проблемы с созданием типа данных
 

работает. но всеравно берет много хипа(на моем теле 30х3000 уже зависает как и при таком же массиве из строк) вобщем буду искать другие способы

Re: Проблемы с созданием типа данных
 

Лучше все слова хранить не в массиве, а в файле ресурсов (причем лучше этих файлов сделать побольше, например, для каждой первой буквы слова - отдельный файл, чтобы у каждого был маленький размер - быстрее грузиться будет). Слова хранить и обрабатывать не в UTF-8 формате, а например в Win-1251 так они меньше места занимают, а перекодировать в UTF непосредственно перед самым выводом на экран. Я так делал и в DreamExpert и в E666 и в ExtInfo. Короче, лучше метода я пока не придумал. Ещё как вариант - скинуть всё в один большой файл и загружать кадрами из него, но тут уж функции ReadLine и ReadByte не спасут, придется подключать библиотеку работы с файлами.

Re: Проблемы с созданием типа данных
 

А Char и есть строка из 1 буквы. Она может занимать 1 байт, а может и 2. Это ещё без учета всяких там байтов, указывающих на конец строки, типа 0x00.

Re: Проблемы с созданием типа данных
 

2 odd: Обьясни почему тип Char может занимать 2 байта?

Если это действиетльно Паскаль, то никаких 0x00 символов в конце строки встречаться не может. Это же не Си.
String в Паскале организован двумя типами:
- 1 байт(длинна строки): LENGTH
- 1-256 байт(собственно строка): DATA
А вот когда используется массив...ммм... сложно сказать сколько используется байт для DATA секции. ИМХО, раз тип изначально придуман как динамический массив, значит используется столько, сколько надо. А с другой стороны фрагментация памяти после использования такого типа просто ужасная будет! А как посмотреть сколько памяти потребляет мидлет не знаю.

Когда я скопировал к себе:
У меня все заработало, тока как юзать эту конструкцию не пойму???

Re: Проблемы с созданием типа данных
 

Char в юникоде ето 2 байта

sl[23][23] из логики имхо :)

Re: Проблемы с созданием типа данных
 

Это точно... толькочто посчитал сколько символов в строке 'Любая кнопка - выключение'
Общая длинна 25 символов, а занимает 46 байт. Это видимо из-за юникод8 и символов типа пробела и тире.

Re: Проблемы с созданием типа данных
 

В файле в кодировке юникод 1 символ занимает 2 байта, а в памяти помоему только 1 байт, а если и 2, то всеравно нужно читать его не как два байта, а как значение типа char.

Вообще в паскале делается так:
Но у меня при компиляции MP просто вылетает.

Re: Проблемы с созданием типа данных
 

ViNT
блин ... масив масивов ето не масив в два измерения !
bla[1][1] и (bla[1])[1] тоже самое по идее, если лексемы нормально разбираются

Re: Проблемы с созданием типа данных
 

Уверен?

По моему,
и
и
это одно и то же, и доступ к элементам производится так:
Во всяком случае, так в нормальном паскале(я проверял в Delphi)

Re: Проблемы с созданием типа данных
 

Как показали дампы памяти, строки хранятся в формате UTF-8 т.е. к примеру, английская буква "a" имеет код 61 (1 байт), а русская буква "a" имеет код D0 B0 (2 байта). Перед каждой строкой пишется её длина (4 байта). Байтов-указателей на конец строки нет.