Столкнулся с тем что GCC упорно не хочет выполнять следующее, вроде с синтаксисом нет никакого криминала комерческие компиляторы отрабатывают без проблем (Borlad c++ и пр.) не выдавая никаких ошибок и предупреждений

unsigned long int a[] = {1, 2, 3, 4, 5};
unsigned long int b[5];

void* ptr = a;

b[0] = *((unsigned long int*)ptr)++;
b[1] = *((unsigned long long int*)ptr)++;

В обоих случаях отказывается делать инкремент указателя выдавая ошибку хотя здесь явно указатель приводится к указателю на заданный тип, пробовал указатель описать как указатель на тип char или int ситуация не меняется. С точки зрения синтаксиса вроде всё правильно .. пытался искать в стандарте Ansi C но нашел ничего .. Мож у кого есть какие мысли .. не исключаю что может и я что то делаю не коррекктно.. Конечно эту ситуацию можно обойти... Спасибо.

Видимо имеется ввиду это:
warning: use of cast expressions as lvalues is deprecated
Означает, что операция преобразования типов не возвращает ссылку на объект, а следовательно не будет выполнятся его модификация.

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

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

попробуйте так :

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

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


Про "и пр." это Вы для красного словца вверули.

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

По поводу криминала - приведу выдержку из закона в подтверждение того, что выше уже было сказано:
Причём это из стандарта С аж 89 года, в 99 это было подтверждено.
А раз кастированное выражение не lvalue - значит ему нельзя присвоить значение и ++ не проходит.

А обойти можно так:

При этом, правда, организуется доступ к объекту одного типа через приведение указателя на него к указателю на другой тип, что не всегда безопасно.
Будет предупреждение:

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

то есть если нужно инкрементировать указатель, приведенный к другому типу :


а если содержимое этого указателя, то нужно добавить внешние скобки :


в обоих случаях нет никаких предупреждений.

А это абсолютно другой код. Согласно приоритетов ++ выполнится раньше приведения типа указателя.
А вот инкремент указателя на void - это, кажется, "неопределённое поведение".

Что-то типа, что c операциями с указателеми на void придется обломиться.

Имя компилятора в студию



Без "кажется" - компилятор который молча инкрементирует указатель на неизвестный объект не может быть признан компилятором

А если не молча, если про это в документации написано...


Анатолий.

Мрак. Хоть ключик под warning имеет место быть.

Ну, несколько я понимаю, "неопределённое поведение" означает, что компилятор может (имеет право) что-то сделать так или сяк, а молча ли он это сделает - зависит от включенного уровня предупреждений.
Учитывая

Сейчас проверил gcc в данном месте независимо от размера объекта, к указателю на который делается приведение, увеличивает ptr на 1 (его право в случае UB), если есть ключ --pedantic, то выдаёт Просто -Wall -Wextra для этого мало (для предупреждения на i = i++ их достаточно).

Хм, я был уверен, что -Wall -Wextra включают все предпреждения...
Надо ещё раз перед сном перечитать документацию :-)

Я пробовал в Borland C++ Builder6, там всё проходит.. Конечно эту ситуацию можно обойти очень легко.. .Просто я вроде явно привожу указатель ок определённому типу информирую компилятор о том на объект какого типа он ссылается причём приведение типа срабатывает а вот инкремент нет.. причем дело тут не в void* можно указатель описать и как char* результат будет тот же. Не исключаю что косяк в моей голове.. Просто иногда очень удобено описать указатель на массив как void* и по ходу дела приводить и его к разным типам разыменовывая содержимое буферного массива чтобы не создавать кучу разных указателей на разные типы данных.. Опять же не утверждаю и не настаиваю что я прав я вполне могу ошибаться. . Спасибо.

Ну и разве это нормально?

Это плохо . Действия с серьезными последствиями производятся и при этом даже warning на эти действия надо с дополнительными усилиями извлекать.
Попробовал

два моих самых используемых компилятора (IAR и Watcom ) выдали однозначную ошибку. Меня это очень порадовало - сам я такое не напишу - рука не поднимется, а вот чужого кода (очень разного качества )достаточно много быват просматривать/править/использовать приходится и лишние проблемы совсем никчему.

можно так :

или так :

Да конечно так можно.. Я понимаю.. До меня дошло что к моменту взятия постинкремента тип к которому было приведение уже теряется и поэтому операция постинкремента уже не корректна. Интересно то что в 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).

А если так:

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

Вы уже несколько раз это повторили. А нельзя ли привести пример того, как такое делается на языках высокого уровня? Скажем, вы принимаете сериализованный список переменных разного типа. То есть, принятый вами буфер выглядит следующим образом:
[число_переменных_в_пакете][номер_переменной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();
}

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

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

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



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

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

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

Здесь создается новая переменная и pDst в нее копируется. Лучше инкрементировать саму pDst, ради этого стоит сделать ее char* и каждый раз при обращении писать преобразование типа. А если компилятор (вопреки стандарту) позволяет инкремент void* то можно оставить ее и void*

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

size потерялся где-то. Вероятно нужен еще sizeof(T)

Если уж нас заботит экономия кода, то с шаблошами лучше не связываться...

Да это всё понятно:-) Я ждал какого-то мегаоткровения, а тут... :-) Так и не понял, где здесь обещанные преимущества языка высокого уровня, по сравнению, скажем, с вариантом от Редчука. Контроль типов - на программисте как был, так и остался, арифметика с указателями - как была, так и осталась. Зато столько пафоса...

Ваш, Сергей, вариант с шаблонами по крайней мере переносит часть контроля типов на компилятор.

Если нас заботит экономия кода, то любой иснтрумент надо применять аккуртано. Многие монстроидальные результаты нынешнего софтостроения связаны не с примененеим С++ вообще или шаболнов в частности, а с бездумным "оттянул-уронил".
Я бы, может, и не влез, если бы не эта последняя фраза, которую я процитировал первой.

Никто ничего нового не создаёт.
К моменту использования нового указателя старый уже никому не нужен. Как следствие, его можно "выбросить", а регистры использовать по новой. Чудесным образом, в них уже есть нужное значение и ничего никуда копировать вообще не нужно (ну, за исключением копирования указателя из регистров передачи параметра в указательный регистр, у MSP430 и ARM не было бы и этого).
"Найдите десять отличий"

Я нашёл только одно - в порядке копирования аргументов на новые места (впрочем, size можно было и не копировать, но это не имеет отношения к преобразованибю типов и "созданиб нового указателя").

Вернёмся. Для более правдоподобного сравнивания я в каждом варианте прочту каждый вид переменной по нескольку раз.
Чистый С, "без никаких латинских примесей"





Гадкие, противные, местожрущие шаблоны.



Итого вариант с шаблонами версии "если хочеться экономить код" дал выигрыш в 3 слова программной памяти (лишний rjmp в функции read C-шного варианта не считаем) . Или, на этом участке, около 5%.
Обратите внимание - "проигрыш" шаблонов в сгенерированных при специализации шаблона функциях (9 слов), а выигрыш - при каждом применении шаблонного чтения (1 слово, тут 12 применений, 3 слова выигрыша). И чем больше будет чтений, тем больше будет выигрыш.
"догнать" на С можно, заведя самостоятельно функции и производя "закат солнца вручную".
Перегнать не выйдет.

Эту проверку можно сделать перед вызовом функции, когда принимается решение - в какую переменную читать. Ведь проверка все равно нужна, а код цикла do {} while(--size) будет короче чем while(size--) {} и в байтах кода и в тактах.
Да, конечно. надо было еще добавить uint8_t size = sizeof(T);
Ну а про шаблоны ReAl все изложил с фактами наперевес. Добавлю лишь, что можно добиться на выходе точно такого же кода, как и в С-варианте, если сделать шаблонную функцию inline. А преимущество будет в том, что не ошибешься, указав имя одной переменной а sizeof другой. Пусть рутину выполняет компилятор.

unsigned long int a[] = {1, 2, 3, 4, 5};
unsigned long int b[5];

unsigned long * ptr = a;

b[0] = (*ptr)++; // или же м.б. b[0] = *ptr++; или b[0] = *(ptr++); Что Вы хотите - Вам виднее.
b[1] = *ptr++;
PS. Все современные языки борются с указателями неявного типа. Это источник глюков.




И я о том же.


Наверное, для науки надо (как делать не надо).

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

а при чем тут макрос? Ничего общего с шаблоном у него нет.

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

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

Он не догадывается, он знает. Он, знаете ли, отслеживает использование каждой переменной и при необходимости использует регистры, которые занимала одна переменная, для другой.
Да, на сложных функциях очень много вариантов размещения и оптимизатор не всегда выберет идеальный, но на сложных функциях и человек не всегда всё сообразит.

А я разве сказал, что у него есть что-то общее с шаблоном?
С ним чисто С-шный текст быстрее пишется и меньше шансов ошибиться, подсунув не тот sizeof. Вот и всё.


Зависит от построения программы, конечно, но если Вам более правдоподобными кажутся программы, в которых из потока вынимается в одном единственном месте по одной единственной переменной каждого типа, то да, в Вашем случае шаблоны проиграют. В случае данной платформы - по два слова программной памяти на каждом типе. Это, безусловно, катастрофическая величина, позволяющая говорить "если важен размер, с шаблонами лучше не связываться".
Уже при трёх чтениях переменной каждого типа шаблонный вариант не проигрывает.
На вполне вероятных количествах чтений 4 и больше - выигрывает. Выигрывает не столько, чтобы плясать от радости, но я только хотел показать, что "слухи о безусловной вредности шаблонов для комплекции программы несколько преувеличены", при количествах чтений от 1 до 5 на тип - 50/50. И даже в случае проигрыша - он чепуховый.

С третьей стороны, если размер так важен, что нужно столь "тщательное измерение результатов", то либо всю программу надо писать на ассемблере, либо это то, что на фотофорумах называют техноонанизмом.

Вы опредедлитесь. А то писать вручную приведение к char* в каждом вызове, писать вручную размеры переменных (ведь макросы тут ни при чём) с шансом где-то ошибиться - это не страшно, подумаешь, время программиста, главное - инструмент старый и отработанный.
Я, кстати, и не тратил бы время на эти измерения, если бы не Ваше столь же голословное, сколь и громкое утверждение.