Если __ramfunc, то как раз все данные должны быть только в оперативке...
Например бутлоадер, который пишет во flash, не должен затрагивать данных из того-же flash.
Поэтому проще было убрать в приведённом примере слово static и слово const вовсе - результат был бы такой же, а буков меньше.

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

а он и есть приятнут за уши. Привидите плиз пример когда volatile const необходим и заоодно выдержку из стандарта где поведение этой конструкции описывается. Реально раздражают такие собеседователи с дебильными "что значит const char * const blavbla". Еще бы про auto спрашивали, который не впился ни в одно место эмеддерам ни в эпоху С, ни в эпоху С++ 14 когда он стал значить совершенно иное

Упс. Не заметил, что в примере локальные статики без const. Действительно hello будет в RAM, что действительно логично для __ramfunc.

В таких система обычно весь flash без разбора копируется в ОЗУ задолго да cstartup.

Прошу заменять все Ваши сентенции "никому не нужен ..." на "мне не нужен".
Спасибо.

хорошо, мне не нужен auto в С. Вам нужен?

Не знаю, что он нынче делает в C, а в плюсах новый auto использую очень часто и нахожу очень удобным.

Да, я про С имел в виду более. В С++ и const собственно гораздо важнее и нужнее. Просто само использование плюсов в эмбеддед ранее было сильно ограничено так сказать, свободно с STL стало писать можно относительно недавно, когда ОЗУ достаточно (256 К и более)

Поведение volatile описано, поведение const тоже. Дерзайте, соединяйте вместе.

Участок одного из заголовочных файлов к STM32. Определение для __I и для __IO найдете сами. Хотя естественно можно с const не заморачиваться, также, как и с осмысленными именами функций, например.

Можно развить ваш вопрос: "приведите пример, когда const необходим и без него никак"?





А какие вопросы вы считаете не притянутыми за уши для программиста встроенных систем с опытом хотя бы более 5 лет?

Мне всегда интересно понять, как человек думает. Даже если умный человек столкнулся первый раз с такой конструкцией (а это вполне возможно), он задумается, постарается понять, о чем речь. Неумный начнет доказывать, разбрасывая слюни в разные стороны, что оно не надо, вы все тут идиоты, так никто не программирует! Но этот человек пришел к нам, решать наши задачи за деньги. Сейчас задача понять, что значит volatile const, вот и все.

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




В C++ крайне нужная весчЬ.

Хотя в C++ я не использую это слово по старой привычке, и опираясь на логику некоторых местных товарищей, могу утверждать, что оно не нужно :-)

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

Ну указатель то как раз ясно, а вот с остальным так себе...

Для затравки кусок кода:
Брэйкпоинт установленный на nop сработает? Сработает. Значит массив это указатель? А указатель это массив?

На много интереснее попросить привести примеры где именно массив поведет себя иначе чем указатель и наоборот.

Кто ответит? )

Не сработает.

Сработает!
Только вот за конструкции видаif ((i == pi) == ptri) лучше отрубать голову голову сразу. Такой код гораздо хуже случая, когда программер не разбирается в const volatile
Гм, а как эта строка вообще работает то ?
http://www.includehelp.com/c/how-expressio...rogramming.aspx


Гыыы int arr[2] = { 0, 1 }; Ай маладца, а если nt arr[2] = { 0, 2 }; ?
Не, реально 10 лет без права переписки за такие хаки
The result of (a== is 1 (i.e. true). И еще - по стандарту true совсем не обязан быть 1

Строка сравнивает числовое значение true , обычно 1, со значением из массива по первому индексу... глубокомысленно

Я думаю стоит сконцентрироваться на работе с массивом и индексами, сравнением массива с указателями.

Ответа на вполне конкретный вопрос пока не поступило.

sizeof ( ptr ) != sizeof ( arr )

https://ideone.com/SLqzMw

Ну имя массива это не lvalue , нельзя записать "имя_массива++" например. А указатель - lvalue


prog.c:8:4: error: assignment to expression with array type
a = b;
VS дает на такое именно " error C2106: '=' : left operand must be l-value"


Так а кусок кода что Вы привели - какой смысл имеет и какое отношение к этому? Он попросту ошибочен

Мне и правда нужно было упоминать что строка девять и строка восемь это тот случай когда "массив поведет себя иначе чем указатель"?

Я отвечу. Ознакомьтесь.

Очень нужная весчЬ - использовать я ее конечно не буду

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


К имени массива привязан не только адрес, но и размер. Как уже писали выше размеры массива и указателя не равны.


Еще пример когда в качестве параметра передается ссылка на массив, в этом случае указатель в качестве параметра не пройдет.

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

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

Во флэш он не живет, а существует хранится.

+++! А какой у них при этом умный вид! Как правило это всякие КТН, с напускным видом умудренного опытом жирного кота. Если посмотреть потом их код - как правило это академическая муть с неочевидной перегрузкой операторов, неуклюжей попыткой засунуть ООП там, где оно вообще не надо итп. Реально полезного - ноль, собственно поэтому и ищут людей ))
Правда это не случай Сигмы - тут обратное , код похож на тот, что напишет бывший ассемблирщик, которому дали С. Причем с ошибкой (или это тест на внимание такой? )

Скомпилится?
ptr это массив поинтеров?
Поинтер на массив?
Ваш варинт ответа

это вот что https://www.youtube.com/watch?v=cdX8r3ZSzN4
А так то - указатель на массив, только вот по-моему редко кто такими конструкциями пользуется.

для эстетов
Он в любом случае пожизненно хранится (занимает память) во флеш... до вызова функции он храниться (занимает память) во флеш, во время вызова хранится (занимает память) и в ОЗУ и во флеш.

delete

Указатель на массив.

Теперь моя очередь =)

А вот это я расшифровать пока не могу

Озвучу мысли, но я не уверен что это правильно
func это массив указателей на функцию без параметров, которая возвращает указатель на фукнцию без параметров, которая возвращает char

Ну, я Вас понимаю =)
Подобные "сюрпризы" ни раз приходилось наблюдать в индусских говнопрограммах драйверах для процессоров различных платформ.
Пример надуманный, и у вышеупомянутых коллек по ремеслу индусских товарищей было что-то чуть-чуть попроще, но лишь чуть-чуть
P.S. func - это функция, не принимающая аргументов и возвращающая указатель на массив указателей на функции, которые возвращают char и не принимают параметров.

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

Этой строке лет 20 уже - как гласит легенда - "первоапрельская шутка для UNIX-программистов" раньше была...
Это покажет уровень понимания (!) языка в принципе. Я знаю, что знание языка отнюдь не всегда самое важное, однако эмбеддерам мое мнение нахрен никому не нужно считаю нужно уметь "думать" на языке, на котором пишешь.

Ну блин, я к Вам в кино в следущий раз подсяду и буду шептать "а убийца то - дворник. " Только я тоже пока не могу корректно компилящийся код под такую конструкцию написать, даже после такого ответа. Возникает идея - давать на собеседовании такие вот вопросы, и, если решил - не брать ни в коем случае, а то весь код в таком ключе и будет написан. Шарады и ребусы это конечно круто, но не в рабочем коде. А вообще это все ерунда я считаю. Пусть не знает вообще ни одного языка, но нарисует мне удобные интерфейсы - это супер. Я вот уже месяц торможу над проектом, при этом основной инструмент - планшет с пером, рисую взаимосвязи и интерфейсы, вот там реально мало чую у меня опыта. А эти шарады нафик не сдались
"понимания (!) языка в принципе." - ничего кроме знания формальных правил это не покажет. Давайте ужо кодера от программиста отличать что-ли
Задумался "нужно уметь "думать" на языке" - а чтобы думать всегда надо думать словами ? Двуязычные тут есть? На каком языке думаете обычно? Я про реальные языки, типа русского там или украинского, английского.

Вам лично могу придумать полдесятка витиеватых примеров для решения

Согласен, запутанные конструкции реально использовать трудно. Но менее сложные, такие как массивы указателей на функции, использовать приходилось, да и решение выглядело вполне изящно.

Многие "фишки" C++ как раз раскрываются вот такими интересными конструкциями... Тот же механизм виртуальных функций...

А, точно. Немного запутался

Вот после такой хрени таки да, auto как глоток воздуха становится. Ловлю себя на мысли, что то , чем не пользуешься - забывается мгновенно. Я синтаксис того что Вы написали однозначно не прочел бы ни с первого ни второго раза. В реальной работе крайне редко использую даже простой указатель на функцию. Если нужен - снова гуглю - где там скобочки и звездочки правильно расставить надо. Честно говоря такая моя "безграмотность" - не мешает. Проектирование программы, повторюсь, считаю куда более сложной задачей, чем собственно претворение готового проекта в код
"использовать приходилось, да и решение выглядело вполне изящно" - да, согласен. Но я такие конструкции с гуглом пишу а не по памяти, обычно их пару раз в моих небольших проектах то и нужно всего использовать.

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

"кому-то еще и поддерживать." и 99 % это вы сами и будете, чертыхаясь и пытаясь понять свой же код. Я - за хорошие названия переменных и методов, вот тут тоже думать много надо над именем, (хотя собственно эти имена и отражают стадию проектирования). И если они хорошие - методы не нуждаются в комментариях (самодокометированный код_) за редким исключением. Еще думать как лучше вернуть несколько значений, раньше я передавал указатели, которые метод заполнял. Сейчас чаще завожу структуру отдельную и возращаю ее. Если структура выглядит как смесь совершенно несвязанных вещей - значит и метод у меня неправильный задуман, и его надо разбивать на несколько мелких более. В общем чем больше пишу, тем более простой код стараюсь делать, избегаю сложных конструкций в одну строку (зачем ? хвастать что можешь так ? перед самим собой что-ли?). Не стеснятся goto в меру . Лучше написать "туповатый" код но понятный даже новичку в С, чем вычурную констркцию if( (i == pi) == ptri ) и не заметить что первая ее часть возращает bool который ты ошибочно сравниваешь с int и это работает.. если int равен 1 и только.. как-то так.. а уж какие горы в ++ можно навернуть то это жуть. Страуструп признавался, что знает С++ где-то на 80..90 из 100. Куда уж смертным то

Мудреные конструкции наподобие вышеприведенных разбираются в учебнике K&R "Язык C", там и метод описан. В жизни мне использовать нет необходимости.

func - не функция, а указатель на функцию.

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

"поплачИтесь" ,- непременно


Совсем ничего не соображаю, а почему такая запись возможно тогда?

Вы не правы.


Потому что func - это то, что я писал выше. А вот f - это указатель на массив указателей на функции. Записи логически и синтаксически корректны.

Ваше замечание притянуто за уши. Поскольку Я применяю это слово редко (или не применяю вовсе), могу делать в нем столько ошибок, сколько захочу. Я же не яйцеголовый КТН в самом деле! И если меня кто-то на собеседовании поправит, обязательно настучу по голове, как было предложено выше.

жаль что совершенно нечитаемы (мне). Всегда удивляют (приятно) люди (на Хабре например) которые это щелкают как орехи. Не понимаю, как при обычном программировании можно получить опыт чтения такого.

char (*(*func(void))[3])(void);

да, не указатель (проглядел скобки справа), но это и не функция. Строго говоря, func - есть имя функции, которое семантически является её адресом, т.е. технически это указатель. Всё выражение да, не указатель, но, строго, и не функция.

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

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

Технически любое имя функции - это есть указатель. Даже

Согласно Вашей логике, f1 - не функция? Стандартописатели из комитета ANSI C ошиблись с терминологией?
Все выражение, все-таки - функция... Вернее, ее прототип.

Технически, синтаксически, логически, семантически (что там еще?) - это именно функция. Я могу ее вызвать, потому что это функция. Я не могу присвоить func ничего, потму что это не указатель, а идентификатор, связанный с выделенным участком кода.

Вот небольшой пример



Важное замечание №1: если все-таки придется использовать какую-то гибкую схему вызовов - лучше, как и было озвучено Quasar, через typedef.
Важное замечание №2: не пишите так никогда (как в примере выше у меня). Это всего лишь пример, но никак не побуждение к действиям. Если и хочется сделать что-то гибко и структурно - лучше тщательно продумать концепцию кода и оформить с typedef-ами (иначе Вас потом будут проклинать ).