А с указателями сколько отожрет по твоему? 
Выделить память , считать туда из EEPROM и занести указатель в массив.
Выделенная память не должна освобождаться.
не про сколько отожрет речь не идет , понятно , что это одно и тоже посути , но потом указзатели надо получать отдельно а так они есть .ю… ну покрайне мере я так рассуждал
я вот сейчас и пытаюсь сделать через
*s = (char*)malloc(strlen(fd) + 1);
Опасная игра при таком уровне подготовки.
Я присоединяюсь к совету сделать массив [30][20] и указателями показать на адреса двадцатисимвольных блоков.
Сортировать строки расположенные в еепром не получится. Ни через указатели, ни считывая по одной. Такова данность AVR архитектуры. Придётся все строки перегнать в память.
рано или поздно придется… А в чем опасность ? чтобы стек не залез на мои данные я вроде как выяснил делать … очистит выделеную память с помощью free вроде знаю как, учесть чтоб небыло фрагментации , тоже вроде понимаю… С чем я еще могу столкнуться…
Если честно я уже решил , что попробую и так и так… если знаний хватит… все равно надо понимать как можно поразному делать а потом смотреть что конкретно рентабельней в данной ситуации для меня …
я понимаю это, поэтому и сортирую не в еепром … в еепром они просто хранятся…
есть 2 варианта можно при добавлении новой строки считать отсортировать и записать сортированный список… второй при работе со списком считывать в память сортировать и работать с ним… во второй варианте жаль памяти , в первом кроме скорости вроде как ничего не мешает … Про циклы перезаписи … добавление строк в моем варианте очень редкое … поэтому этими уиклами можно пренебреч… скорость конечно большой минус но в данном случае придется выбирать скорость или экономия памяти … думаю что со скоростью возможно можно смериться
Ну отчего ж. Сортировать надо не строки, а индексы в EEPROM. Но, как мне кажецца, для ТС это тёмный лес и немцы в доме. А вот потом, можно пересохранить строки в EEPROM согласно индексам. Двух строк в ОЗУ для сортировки хватить. Написать?
1 лайк
Ну отчегож . была и эта мысль , для этого в конце каждой строки записан порядковый номер … ну правда он еще и для доступа … но сути не меняет , можно конечно и осортировать сами индексы , но тогда придется менять перекрестные ссылки в нескольких таблицах… можно ввести конечно еще один индекс… можно и не в строку… как говориться вариантов много…
но зачем усложнять если для меня приемлемы и первые два варианта
Чуть чуть я Вас опередил
Извини, но вот этого не понял. Изначально говорилось о данных в еепром, потом это оказались строки. Что бы сравнить две строки их надо считать в память. А дальше ещё 30 строк. Как с ними быть?
Дак я ж написал, пузырьком. Если сортировать индексы, не обязательно ВСЕ строки из ЕПРОМ читать, достаточно ДВЕ, которые сравниваются в данный момент. Заводишь массив адресов на строки, читаешь две, и тасуешь их, в зав-ти от сравнения.
не, ну если Вы считаете, что прибавлять в одном месте 20, а в другом ещё единицу - нестрашно, значит - нестрашно. Люди же все разные, кто-то менее смелый, кто-то - более.
Ну, а если всё правильно, так что здесь делает эта тема? Зачем Вы её создали? Чтобы поспорить с Дедом?
Ну я собирался использовать qsort без пузырька … если память позволит . считать 30 строк отсортировать и вперед…
Это где такое? Что-то не вижу (пропустил?)…
не совсем понял о чем Вы…
ff.toCharArray(mem, 18);
f3.toCharArray(mem, 18);
mem[19] = 4;
EEPROM.put(80, mem);
если по это , то сперва индекса небыло и строк были 18 байтов, потом добавил индекс , но так как индекс записывается отдельно , небыло смысла изменять на
ff.toCharArray(mem, 20);
f3.toCharArray(mem, 20);
mem[19] = 4;
EEPROM.put(80, mem);
mem то все равно 20 байтов… по сути и первая строка не нужна
или Вы о чем
Виноват, это я с прямым углом перепутал.
Т.е. доставать строки придется не по одному разу а максимум (n*log(n)) . Минус время плюс память. Если памяти мало вариант.