вы в этой ветке столько всего нагородили. что неудивительно. Байтовый массив на любой платформе читается одинаково. Исходите из того, что это - непреложная аксиома. Если у вас не так - ищите ошибки в СВОЕМ коде, а не в "несовместимости" компиляторов.
Это сленг для указания начала. Условно и не обязательно. Потому как начало не всегда то место которое надо. Вот блин доматались... можно подумать что в слове "хрен", я не только ударение ставлю не верно, но допускаю ещё 5 ошибок!
Всё, что касается стандарта языка, всё везде одинаково. Я работаю с компиляторами AVRGCC, IAR MSP430, TI MSP430, ARMGCC. Проблем с указателями не испытывал нигде. Т.е. тупо беру готовые куски кода и вставляю их. Проблемы только с атрибутами - у каждого компилятора они свои...
чей та? хочешь сказать, что вот тут _addr не может быть больше 255? Код (C++): uint8_t buff[ARRAY_SIZE]; uint8_t *abuff = buff + _addr; и. следовательно, массивы байтов больше 256 элементов невозможны в принципе? На самом деле _addr может быть любым целочисленным типом, к размерности данных массива это не имеет отношения.
Поправил в сообщении #23 Но конструкция Код (C++): 1 uint8_t buff[10]; 2 uint8_t * b1 = &buff[0]; 3 uint8_t * b2 = &buff; 4 uint8_t * b3 = buff; Не компилируется GCC, выдает ошибку в строке 3:
когда пишешь buff + _addr это получается само. то что смещение _в байтах_ будет зависеть от типа buff - это вроде как очевидно... Хотя на эту тему новички тоже очень часто ошибаются
потому что в этой строке Код (C++): uint8_t * b2 = &buff; переменная b2 имеет тип uint8_t** . а не uint8_t* и это тоже обьясняет, почему у Игоря не работает
Но в старом Си (не С++) работает: Код (C++): C:\C600\WORK\test>type test_c.c void main() { char buff[10]; printf("\n\r b1=%lp b2=%lp b3=%lp\n\r",(void far *) (&buff[0]),(void far *) &buff, (void far *) buff ); } C:\C600\WORK\test>cl /AS test_c.c Microsoft (R) C Optimizing Compiler Version 6.00 Copyright (c) Microsoft Corp 1984-1990. All rights reserved. test_c.c Microsoft (R) Segmented-Executable Linker Version 5.10 Copyright (C) Microsoft Corp 1984-1990. All rights reserved. Object Modules [.OBJ]: test_c.obj /farcall Run File [test_c.exe]: "test_c.exe" /noi List File [NUL.MAP]: NUL Libraries [.LIB]: Definitions File [NUL.DEF]: ; C:\C600\WORK\test>test_c b1=0EF5:0D74 b2=0EF5:0D74 b3=0EF5:0D74
Да верно! Это я дурак!!! За то и прошу прощения!!! Вот только старый CArm(uVision3) компилятор этого не тянет почему-то. Да шут с ним я его много лет как не юзаю, хоть и стоит(для просмотра старой работы). Код (C++): #include <stdio.h> #include <stdint.h> uint8_t buf[32]; int main(void) { int64_t par; (*(uint64_t*)(buf)) = 1234; par = (*(uint64_t*)(buf)); printf("test: %lli\n", par); return 0; } Сейчас проверил как в GCC(Debian 10), как в Keil uVision4/5, не буду VisualStudio запускать Одним словом спасибо что открыли глаза(Надесь это так) ВЕМ РЕСПЕКТ!!!!!
Это не указатель на указатель. Это просто адрес первого элемента массива, это не переменная. Просто часть компиляторов подставляют сам адрес, потому, что нет адреса адреса
С VisualStudio(2005 новые не ставлю давно) пример так же сработал, но правда C++. Хотя никак не могу привыкнуть, что конкретно адрес не надо указывать. Не привык. Неужели все компиляторы стали телепатами?! Я лично их привык носом тыкать дабы не было недоразумений... особенно в Кейл когда узкий функционал надо тащить в код на ассемблере. Знаете бывает и такое, когда надо передать адрес как параметр. В голове не укладывается... не привычно. И Все равно РЕСПЕКТ!!! Потому как писанины меньше. Главное потом не пролететь если надо будет "тыкать носом", а то привыкну к простому.
А тем что: Код (C++): uint8_t *b = buff +3; Выполняется медленнее, а потому и лучше... но смотрится просто Блеск. 1 - загружаем адрес в регистр 2 - загружаем смещение в регистр 3 - складываем адрес со смещением и получаем адрес со смещением образно два лишних обращения к памяти а тут: Код (C++): uint8_t *b = &buff[3]; сразу получаем адрес со смещением в регистр. Выполняется быстрее, а потому и хуже... и выглядит как Быдлокодинг
5 баллов Я лично пользуюсь последним вариантом. Но не могу взять в толк, почему это оно же и читается легче. В программировании как в самолётах: чем проще прочитать, тем меньше шанс сделать ошибку.