Да конечно так можно.. Я понимаю.. До меня дошло что к моменту взятия постинкремента тип к которому было приведение уже теряется и поэтому операция постинкремента уже не корректна. Интересно то что в Borlande приведение типа видимо сохраняется и далее постинкремент работает правильно в соответствии с приведённым типом.. Не буду спорить правильно ли это или нет но влюбом случае такой приём надо избегать.. я не собираюсь использовать это в коде проекта... Просто столкнулся с разным поведением компиляторов при разборе синтаксиса пусть даже и не корректного..В любом случае благодарю за обсуждение. Спасибо.

А почему бы не сделать сразу этот указатель на unsigned long - и не придется ничего преобразовывать?

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

Да Вы в общем то правы. Да я пишу на С но всегда копаюсь в скомпилированом коде ассемблера. Как ни крути ну сильна привычка и любовь к железу.. пока не могу оторваться ибо до этого много работал на ассемблере. С приобретением опыта программирования на С думаю это пройдет но пока стараюсь и учусь. Спасибо.

Безусловно, в скомпилированном коде копаться нужно - все-таки не всегда код генерится достаточно эффективный, и когда компилятор создает что-то неудачное, программу надо менять. Но не таким варварским образом.

поскольку только осваиваюсь в сях, а ситуация интересная, посоветовался с опытным человеком

И действительно
b[0] = *(*(unsigned long int **)&ptr)++;
не вызвал ошибки и , судя по листингу, правильно инкрементировал ptr.
Правда пока не понял в чем разница

Это то же, что предлагал ReAl немного выше. Разница в том, что в этом случае временный объект - указатель на наш указатель, и модифицируется не он (не временный объект), а то, на что он указывает (о как мощно задвинул:-) )
В принципе это тоже не комильфо, но работает.

Что значит "по старому стандарту"?
По K&R первого издания, являвшимся "стандартом де-факто", но не "де-юре"?
Я же привёл выше цитату из стандарта 1989 года про то, что cast не есть lvalue.

Другое дело, что многие компиляторы до конца 90-ых (а борлданд - так похоже и до середины 2010-ых :-) ) так и не удосужились привести себя в соответствие стандарту 1989 года, как и сейчас не все и не всё делают согласно стандарту 1999 года...

Это то де по сути, но прозрачнее записано.
То, что написал я - можно подрихтовать, вставив вместо sizeof свой макрос, который как-то корректирует размер - например, в зависимости от параметра, задающего выравнивание.
У того же борланда, насколько я помню, так сделан макрос (а не __builtin) VA_ARG (stdarg.h).

А если так:

Так можно. Только зачем? Языки высокого уровня придумываются для того, чтобы избегать низкоуровневых работ, а также для обнаружения большинства ошибок на этапе компиляции. А чего мы добиваемся подобной конструкцией?

Сообщение отредактировал 777777 - May 6 2008, 16:54

Вы уже несколько раз это повторили. А нельзя ли привести пример того, как такое делается на языках высокого уровня? Скажем, вы принимаете сериализованный список переменных разного типа. То есть, принятый вами буфер выглядит следующим образом:
[число_переменных_в_пакете][номер_переменной1][переменная1][номер_переменной2][п
еременная2]...[номер_переменнойN][переменнаяN].
В зависимости от номера переменной её тип может быть int, char, double, long int.
Научите, как это делается на языках высокого уровня?

Очень просто. (Правда, номер переменной здесь не нужен - обычно порядок определяет назначение переменной). Можно написать функцию read(void* buf, uint8_t size) которая "принимает" (неважно откуда) данные размера size. Тогда мы пишем:

int var1;
char var2;
double var3;
long var4;
read(&var1, sizeof(var1));
read(&var2, sizeof(var2));
read(&var3, sizeof(var3));
read(&var4, sizeof(var4));

или еще проще:

struct VAR {
int var1;
char var2;
double var3;
long var4;
} var;
read(&var, sizeof(var));

Только здесь надо позаботиться чтобы переменные в стуктуре были выровнены побайтно. А самой функции read нет необходимости знать о типах - она читает только заданное количество байт.

Содержимое функции read зависит от того, откуда ей принимать данные, в любом случае ей придется инкрементировать указатель *buf. Если компилятор допускает ++ для типа void* и увеличивает его именно на 1, то такой код годится, если нет (как того требует стандарт) - то прототип функции должен быть read(char* buf, uint8_t size), но тогда при обращении к ней нужно приводить тип буфера к char*

Номер переменной здесь нужен потому, что в пакете могут быть произвольные переменные. Например, передаются только изменившиеся параметры - это сильно экономит трафик. Но не суть.



Собственно весь вопрос и заключался в том, как должна быть написана эта функция. Вы функцию не привели, и идеи ваши никуда не ушли в сторону от банальной арифметики с указателями.



Не вижу здесь никакого особого "высокоуровневого" подхода.

Вы тоже не объяснили откуда плучаются данные.

void read(char* p, uint8_t n)
{
while(n--)
*p++ = getchar();
}

Каков вопрос, таков ответ

А вообще, вопрос надо задавать более широко: что требуется в конечном итоге? Тогда, возможно, отпадет даже сама необходимость решать этот частный вопрос.

Сообщение отредактировал 777777 - May 7 2008, 05:02

А какая разница?



Спасибо, теперь я наконец-таки узнал, как надо писать на языке высокого уровня

Можно я чуток поправлю?
Любой указатель приводится к void* автоматически. В исходном коде компилятор не дал бы read(&var3, sizeof(var3)); только read((char *)&var3, sizeof(var3)):

Еще можно предположить, что размер переменной не может быть равным нулю. Тогда:Ну и отсюда всего один шаг до С++:
Или, если экономим код, то