указатель на тип void, попытки создать общую функцию Опции

[andrvisht]

Всех с наступившим!!!
Решил написать функцию вывода строки в массив да так чтобы можно было эту строку брать как из SRAM так и из FLASH а поскольку указатели на FLASH и SRAM это разные вещи, то и типы указателей должны быть разные.
решил сделать тип void чтобы тип можно было задать при вызове функции с приведением типа.

вот код функции

Код

void LCDString(unsigned char StrNum, unsigned char StrPos, void *pStr)
{
  unsigned char i, c;
  i = StrPos;
  c = *((char*)pStr++);
  while ((i < SYM_STR-2) && (c != 0x00))
  {
    LCDStr[StrNum][i] = c;
    c = *((char*)pStr++);
    i++;
  }
}

прблема в том что компилятор не может сделать ++ для указателя типа void.
если создать отдельную переменную типа char *pS; то все нормально.

т.о. вопрос ? как сделать ++ указателю типа void без отдельной переменной, если возможно.

И еще вопрос. Если нужен передавать параметр типа bool
то можно как-то использовать
#if
#endif
т.е. напрмер

Код

strcpy(char *pStr, bool S_F)
{
#if S_F // если передан указатель на FLASH
flashcpy()
#else
Sramcpy()
#endif
}

или может так :

Код

strcpy(char *pStr)
{
#ifdef S_F
flashcpy()
#else
Sramcpy()
#endif
}
а вызов функции делать так

#define S_F
strcpy(*pStr)
#undef S_F

Есть еще вариант передавать два указателя, для Flash и SRAM и ненужный передавать 0
Или может еще каким образом поступают при такой задаче, просьба поделиться опытом ...

[andrvisht]

to Old1:
Спасибо, просмотрел Ваши функции, узнал для себя что unsigned char можно писать как строку символов без обьявления массива
кстати Вы в def.h делаете так:

Код

#ifdef __FUNK1__
void Write_massiv_1(void *P_STRING, unsigned char *P_MASSIV, unsigned char STRING_TYPE);
#else
extern void Write_massiv_1(void *P_STRING, unsigned char *P_MASSIV, unsigned char STRING_TYPE);
#endif//__FUNK1__

в книге по С сказано:

Если спецификатор класса памяти не указан, то подразумевается класс памяти extern.

т.о. можно сократить запись, чего нельзя сказать о переменных...

А вот если в функции с __generic переставить местами аргументы то результаты будут чуть лучьше.
366 цикл. и 405 цикл. соответственно.
Для void такое мероприятие в некоторых случаях даже ухудшает дело.

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

И еще такой вопрос:
У IAR по умолчанию функция main возвращает значение int = 0;
понятно что такого быть не должно, и она может быть void.
но ведь для чего-то IAR так делает, а иногда (причину пока не выяснил) IAR дает сообщение на main что возвращаемый тип должен быть int. ???
to ObitJr
абсолютно согласен, в книге по С такой пример есть. А в IAR нет, вот только после данной ветки мне теперь кажется что IAR прав (по крайней с этим приходиться мириться)
Вопрос об указатели на FLASH хоть и верен, но в данном варианте не имеет значения, т.к. ошибка инкремента приведенного указателя не зависит от типа приведения и возникает на стадии компиляции самой функции.

[ObitJr]

Ищем книгу "The New C Standard - An economic and Cultural Commentary" (только не говорите чтоб я ее куда-нибуть запостил - ее можно найти в сети). В книге есть ссылки на стандарты и коментарии к ним.
Смотрим для начала пункт '6.2.5 Types' - в конце этого пункта написано практически тоже что я и говорил про то, что есть ситуации в которых невозможно определить какой применять доступ к некоторым облястям памяти. (Там же есть и пару строк про IAR, только применительно к PIC контроллерам)
Смотрим пункты '6.3.2.2 Void', '6.3.2.3 Pointers' (внимательно читаем весь пункт) и понимаем что из себя представляет этот тип. Там же написано о том, что стандарт не может гарантировать наличия функциональности о которой я говорил по приведенным причинам.

[_artem_]

esli vse taki xotite manipulirovat void v funkcii to mozete sdelat assemblernuju vstavku dlja inkrementa void'a v zavisimosti ot tipa .

Ищем книгу "The New C Standard - An economic and Cultural Commentary" (только не говорите чтоб я ее куда-нибуть запостил - ее можно найти в сети). В книге есть ссылки на стандарты и коментарии к ним.

A kniga vrode by est v emule (imya poxozee )) ):
ed2k://|file|The%20New%20C%20Standard%20A%20Commentory.pdf|7964335|359B84821628646E0157EE8877E09211|/

[andrvisht]

esli vse taki xotite manipulirovat void v funkcii to mozete sdelat assemblernuju vstavku dlja inkrementa void'a v zavisimosti ot tipa .

Спасибо, я уже все сделал через __generic , и привел результаты выше.
раньше на ASM писал, потом на AlgBulder, но возвращаться к ним не хочу думаю и не придеться

Сообщение отредактировал &-rey - Jan 11 2006, 16:38

[Old1]

To &-rey.

А вот если в функции с __generic переставить местами аргументы то результаты будут чуть лучьше.
366 цикл. и 405 цикл. соответственно.

Да, действительно... спасибо.

конечно оптимизировать можно до бесконечности ...

Еще одно замечание на эту тему, если в моем примере в модуле Funk1 в определении функции использовать квалификатор __x_z, то результаты тоже улучшаются , но к сожалению строка из flash (при таком построении функции) все равно читается медленнее чем с __generic...

И еще такой вопрос:
У IAR по умолчанию функция main возвращает значение int = 0;
понятно что такого быть не должно, и она может быть void.
но ведь для чего-то IAR так делает, а иногда (причину пока не выяснил) IAR дает сообщение на main что возвращаемый тип должен быть int. ???

Здесь уже задавался подобный вопрос, вот ссылка на тему: http://electronix.ru/forum/index.php?showt...st=0?entry50424 (что-то уменя ввод гиперссылки не работает).

[andrvisht]

to Old1:
Спасибо за ссылку, мои подозрения оправдались
Тему по __z_x скачал. Займусь на выходных.

[Old1]

...если в моем примере в модуле Funk1 в определении функции использовать квалификатор __x_z, то результаты тоже улучшаются ...

Упс... В данном случае __x_z не дает , увы, никакого эффекта (работал поздно ночью, видимо улучшенный результат приглючился )...