IBAH (10.05.2022 21:48, просмотров: 4812)-
- Функция f(unsigned char *) имеет полное право эту самую строку
изменять. А const unsigned char str[], очевидным образом, не
допускает возможности изменения. - LightElf(11.05.2022 21:15)
- Угу, книга С++ за 21 день за авторством Либерти, день девятый - symbions(11.05.2022 23:25)
- Я этого вашего Либерти не читал, но C++ осуждаю! :-) - LightElf(11.05.2022 23:30)
- Угу, книга С++ за 21 день за авторством Либерти, день девятый - symbions(11.05.2022 23:25)
- Почему-то думал, что это влияние гарвардской архитектуры. Ну т.е.
"unsigned char const *" и "unsigned char *" могут адресовать
объекты из физически разных областей. Как в таком случае прототипу
функции указать нужную область памяти кроме как явно? - Argon(11.05.2022 07:34)
- Я тоже так думал... Тяжелое наследие восьмибинтого детства. - IBAH(11.05.2022 14:25)
- Ну и позанудничаю. Всем знакомый Cortex-M3 вполне себе Гарвард. Ну
а Cortex-M0 фон Нейман. И там, и там однородное адресное
пространство. Короче, не путайте тёплое с мягким. - SciFi(11.05.2022 08:31)
- Ну это частный случай. "Гарварды" в общем случае не обязаны иметь
однородное адресное пространство и одну адресную шину (см. PIC). - Argon(11.05.2022 09:22)
- "гарвард" - это наличие разных шин для кода и для данных. И
только-то. А насколько адресное пространство выглядит единым - это
уже фича. - POV(11.05.2022 10:18)
- Как насчёт i8051, есть ли у него отдельные шины для внешней памяти
программ и данных? - ЫЫyкпy(11.05.2022 12:52)
- Вполне допускаю, что среди множества совместимых с 8051 процов есть
и такие, в которых одна общая шина (то есть фон Нейман), но
адресные пространства разделены, потому что это 8051, и надо
сохранять совместимость с тулзами. - SciFi(11.05.2022 13:11)
- Это извращение имеет своё название, "модифицированная гарвардская архитектура". - ЫЫyкпy(11.05.2022 13:47)
- Три адресные шины - код, внешняя память, внутренняя память. - POV(11.05.2022 13:00)
- А для внутренней? Да и для внешней есть сигнал отвечающий за разделение циклов. - =AlexD=(11.05.2022 12:56)
- Вполне допускаю, что среди множества совместимых с 8051 процов есть
и такие, в которых одна общая шина (то есть фон Нейман), но
адресные пространства разделены, потому что это 8051, и надо
сохранять совместимость с тулзами. - SciFi(11.05.2022 13:11)
- Как насчёт i8051, есть ли у него отдельные шины для внешней памяти
программ и данных? - ЫЫyкпy(11.05.2022 12:52)
- "гарвард" - это наличие разных шин для кода и для данных. И
только-то. А насколько адресное пространство выглядит единым - это
уже фича. - POV(11.05.2022 10:18)
- Ну это частный случай. "Гарварды" в общем случае не обязаны иметь
однородное адресное пространство и одну адресную шину (см. PIC). - Argon(11.05.2022 09:22)
- Кейл51 каким-то образом принимает в функции указатели на все виды
памяти.. код, внутренняя рам, внешняя рама.. видимо за счет
дублирования функций скрыто от программера. Так тчо гарвардская
архитектура не при чем. - POV(11.05.2022 08:06)
- "Образ"- это 24-битный указатель, если не указано иное (спецификатор xdata/pdata/idata). - Costic(11.05.2022 14:28)
- Более того, для раздельных адресных пространств (8051, avr и т.п.) соответствующие компиляторы вынуждены вводить нестандартные ключевые слова (xdata, flash и т.д.) В голом Си ничего этого нет. - SciFi(11.05.2022 08:17)
- Это "защита от дурака". С точки зрения ЦП (асемблера) - это всё тот же адрес в памяти, как и void *. Единственный момент - const объекты обычно размещаются во флеш в микроконтроллерах. Можно ещё вспомнить функции с переменным числом аргументов - тоже простор для полёта фантазии. - Costic(10.05.2022 23:03)
- По семантике понятно: если функция принимает "type*", она имеет право менять объект по указателю, а передаваемый указатель "type const*" подразумевает, что менять объект нельзя. Кстати, когда наоборот, передавать можно, и компилятор ругаться не станет. - SciFi(10.05.2022 22:04)
- Почему же нельзя. В принтф, например, не const передается хоть и с
руганью. Просто флажки по варнингам какие-то мешаются. - POV(10.05.2022 21:49)
- У меня ИАР пишет Error[Pe167]: argument of type "unsigned char
const *" is incompatible with parameter of type "unsigned char *".
Вообще в принципе не понятно, почему эти типы не преобразовываются
по умолчанию? Почему указатель на неизменяемые данные не может быть
просто указателем? - IBAH(10.05.2022 21:56)
- Потому что "просто указатель" - это указатель на изменяемые данные. aoreh(303 знак., 11.05.2022 12:16)
- GCC передавай на здоровье, у иара какой-то видимо, свой заскок. - PeterD(11.05.2022 07:57)
- Думаю, он компилирует в режиме C++. Там добавляются плюсовые
заморочки. - SciFi(11.05.2022 08:01)
- Из всего ++ только опция "C++ inline semantics". ядро Кортех. Объяснение вполне логично IBAH(2 знак., 11.05.2022 20:21, ссылка, ссылка)
- Да какие заморочки объявлена строка как константа, ну передал ее
адрес в ОЗУ какие проблемы. Возможно "машина" просто гарвардской
архитектуры, компилятору важно различать указатели на разные
области памяти, так как памяти раздельные в такой архетектуре, с
гарвардскими только на AVR-ках работал давненько, там помню что
как-то огородами к флешь подбирался. - PeterD(11.05.2022 08:44)
- И как в С++, с учетом декорирования (манглинга), вы планируете слинковать ф-ии с разными типами аргументамов (а конст и не конст - это разные типы)? aoreh(89 знак., 11.05.2022 12:18)
- Нет. Вот вам для примера одно и то же в режиме С и С++: SciFi(2 знак., 11.05.2022 08:49, ссылка, ссылка)
- Думаю, он компилирует в режиме C++. Там добавляются плюсовые
заморочки. - SciFi(11.05.2022 08:01)
- Ну вот такое оно )) POV(1 знак., 10.05.2022 21:56, ссылка)
- У меня ИАР пишет Error[Pe167]: argument of type "unsigned char
const *" is incompatible with parameter of type "unsigned char *".
Вообще в принципе не понятно, почему эти типы не преобразовываются
по умолчанию? Почему указатель на неизменяемые данные не может быть
просто указателем? - IBAH(10.05.2022 21:56)
- Функция f(unsigned char *) имеет полное право эту самую строку
изменять. А const unsigned char str[], очевидным образом, не
допускает возможности изменения. - LightElf(11.05.2022 21:15)