Чего тут думают керниганы и примкнувшие, не понимаю. Ну вроде же initialyzer list, почему он не создает временный rw объект и не присваивает ему указатель, а вместо этого прямо в лоб на константный инициализатор ссыль кидает. Где в стандартах этого так называемого языка программирования глянуть?

Потому что "the" по стандарту константа.

А указатель на нее?

Указатель модифицировать можно, а вот содержимое инициализатора - нет:

То есть char a[8] = {1,2}; a[0] = '8' это можно, а первое нельзя?
.

Точно. По указателю на константу ничего не записать.

А почему никто не сказал, что не надо char * присваивать auto const char *? И все прокатило без явных приведений типа? Почему вообще такой синтаксис умудряется быть спокойно скомпилированным и при этом гарантированно все обрушить?

Согласен. Тоже считаю такое недопустимым поведением компилятора. Какой компилятор кста?

А чего другого вы ожидали?
Грубо влезли в область хранения указателя "p" - вместо адреса реального объекта накидали туда всякого "мусора".
И после этого пытаетесь пользоваться этим "указателем" ...

К слову. Более современные компиляторы уже ругаются на такие дикости lala la = {"the"}: warning: ISO C++11 does not allow conversion from string literal to 'char *' [-Wwritable-strings]

Потому что С позволяет программисту сделать всё, что он хочет - отстрелить обе ноги и повесится. С++ в этом отношении более строгий, он это не проглотит.

Потому что это си.
https://stackoverflow.com/questions/2245664...rals-in-c-and-c

Нет, вру. "struct lala ... lala la" - это не си. Это кривой вопрос, т.к. правильный вопрос должен указывать и название компилятора тоже.

Вот, например, компилятор gcc
char * test = "TEST";
../Common/main.cpp:41:16: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
В main.c аналогичный трюк работает без предупреждения.

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

Да ладно? Про какой компилятор речь? IAR вполне себе тоже "проглатывает" (((

В примере:

негодование компилятора (IAR_7.80) вызывают только последние 2 строчки, но к сожалению никак не Func("test");
Хотя хоть убей - не пойму в чём принципиальная разница между Func("test"); и static char const t1[] = "test"; Func(t1); ?
Language: C++; Dialect: Extended Embedded C++ (default).

Gcc дал warning - deprecated (странный варнинг для такого). M$ проглотил даже без warning


M$ даже не дал warning в С++ 11 режиме

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

Еще интересный вопрос возник. Как вам такая штука

Тут gcc дает warning что то там multibyte, точно не помню. Просто интересное применение, раньше как-то не встречал такую идею.


По умолчанию? Он ругается на куда более безопасные вещи. Ну ладно, с этим вопросом разобрались вроде

На известном ресурсе полно подобного "кода". Смысл его тут цитировать?

M$ - уже давно не образец для подражания.

Стоп стоп. Почему Вы считаете это говнокодом и как бы Вы сделали, не городя монстра? По сути из имени получается бесплатно подобие хэша. Иначе варианты начинают хотеть strcmp, или, страшно сказать std::map . А тут бесплатно

Разве не очевидно? Функция ожидает int, а получает то, что дадут.
В подобных ситуациях делают ряд функций, каждая из которых работает со своим типом данных.
Либо передается в одну функцию ссылка на определенную структура, где заранее расписаны "детали" поиска и что искать.
Существуют и другие способы, но там уже используются чисто плюсы и их "фишки".

Неявно, неочевидно. Со временем развития проекта из-за этого могут возникнуть проблемы, которые найти будет довольно сложно.
Компилятор заругается, если будет не 4 цифры, а больше или int на неком железе окажется равным не 4 байтам. Но ведь это лишь предупреждение... Не дай бог это попадет в библиотеку, где линкер при сборке этого просто не увидит!
А если дать всего 3 цифры, то что получит на входе функция? Лотерею из мусора в стеке?...

Думаю Вы правы. Просто дали проект, сижу разбираюсь. Многие вещи интересные. Причем 90% кода по всем правилам, что наводит на мысли об опыте автора. А раз применяет такие трюки - может в этом есть смысл? Я то сам пишу удивительно пресный код, таких открытий он не сулит. Но у меня обычно больший overhead, не люблю оптимизировать

Сочувствую Доделывать начатое за другими - мало кому по кайфу ...

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

Нормально делается и без strcmp:

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


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

Не, сочувствовать не надо. Я во всех чужих программах ищу и нахожу что то новое. Может через месяц я начну переделывать ее, но уже имея в багаже чужие трюки и подходы. Есть плохие места, есть интересные. Знания лишние не бывают.
Операционку он ucos юзал, не в восторге, но работает. Я хотел бы scmRTOS, но это потом. Кстати крутая программистка, которая тоже сидела над этим проектом за нее. Но увы, у девушек редко хорошо с железом,, поэтому с ней расстались. Хотя в плане академического программирования - все красиво и хорошо.

Зачем приводить к u8, а потом к uint?

Ну, если цель в этом, то другое дело


А не все ли равно? Особенно, если камень выбран с достаточным запасом.
К примеру, мои проекты уже давно лишены привязки к конкретной RTOS, менять ось - дело двух минут, хотя такой задачи изначально не ставилось.
Просто, свой код читать всегда проще и чем его больше в соотношении с чужим кодом, тем проще сопровождать такой проект. Имхо!

Логично

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

Всегда спрашиваю просто: наличие законченных проектов и куски кода оттуда для примера. Хотя бы это.
Остальные качества выясняются на испыт. сроке ))


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


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

Ни разу не видел еще готовый проект с кучей доступных билдов под разные ядра. Даже hello world не видел

Я тоже. А зачем это вообще делать?

А как понять "из списка доступных билдов нужно лишь выбрать нужный под нужную ОСь и пересобрать проект"? Под ядро я имел в виду ось, ибо эмбеддерские это все же больше ядра просто, иногда с плюшками, не суть

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

Я вообще о том, что перенести проект из freeRtos под, например, scmRtos это отнюдь не две минуты. Впрочем это ни о чем, как и весь топик. Хотя полезное есть и в нем (топике)

Да, если он изначально был написан конкретно под freeRTOS.
Я же немного про другое ))


В этом смысле он почти ничем не отличается от большинства топиков в этом разделе :D

Ну кто же виноват, что stackoverflow нужный ответ за минуту находится. Просто иногда не находится ничего, потому что не ищешь, а не ищешь потому что даже не знаешь, что такое бывает ))

Сурово у вас.... За операционку уже сажают! как в 37-ом


Это аналог: (uint)((x) & 255) но выглядит проще.

Раз пошла такая пьянка...
Вот мы тут хихикаем, а отечественные законотворцы начитаются этого и введут запрет на использование иностранных операционок в рамках импортозамещения ...
И будем переписывать, например, freeRTOS по-русски. Вот я уже придумал название: "бесплОС" или "бесплатОС"

БолгенОС уже была..

Так и подумалось вначале.


А мы не смеемся. Вот только есть один момент. Законопроекта как такового пока что нет, а вот пути развития уже поставлены - собственно, действительно была поставлена задача разработки отечественного ПО, и начали все с ОСРВ... Пока в рамках международного форума по информационным системам на службе ОПК РФ.
Как назвать? ПонОС - "ПОНятная Операционная Система"


Тссс, вдруг он сейчас зарегистрируется и будет кричать "не БолгенОС а Болдженос"?

Это специальный случай - для него в стандарте сделали хак (иначе не назовёшь), иначе бы разломались практически все С программы (а С++ декларировался как совместимый с С, ха ха).



Нормальная multi byte символьная константа. Описана в стандарте. Единственный её минус (который практически не даёт её применять) - стандарт не описывает endianess этой самой константы, т.е. неизвестно, с какого конца целого числа будут выкладываться символы
Если вам всё равно как именно она формируется, то использовать можно.

В данном случае это - не единственный минус.
В этом достаточно убедится, попытавшись дать не sizeof(int), а меньше символов, например 2 или 3.
Компилятор предупредит соотв. warning, но проект все равно успешно соберется.
Не трудно догадаться, что предсказать результат работы такой функции в этом случае уже никто не сумеет ...

А в чём проблема? Вариант с одним символом у вас вопросов не вызывает, с 4мя тоже (положим что int - 32 бита). Чем вам 2 или 3 символа не нравятся?
Это же не строка, а символьный литерал.



'ABC' будет 0x414243 или 0x434241 (как карта ляжет). Других вариантов нет.

Что будет в этой переменной int v, которую ожидает функция, если ей дать не '1234', а например '1', '12', '123' ?
Нули или "мусор" из стека? "Стандарт" описывает эти нюансы?

Т.е. вы утверждаете, что запись int v='1'; неправильна? Это что то новое, до сих пор миллионы програмистов ничего неорпеделённого в такой записи не видели.

По вашему вопросу - в v будет 0x31, 0x3132, 0x313233 или 0x31, 0x3231, 0x333231 соотвественно для BE/LE машин.

Никакого мусора 'из стека'. И да, стандарт эти 'нюансы' описывает.

Может вы спутали литеральные константы и строки? Речь шла о '1234' а не о "1234" (второе вообще даст ошибку)

Не утверждаю, а лишь спрашиваю


Ясно, значит, недостающие байты во многобайтовой переменной будут заполнены нулями.
А BE/LE влияет на положение этих неявных нулей в переменной?
С какой стороны будет "обрезана" слишком длинная литеральная константа (например, '12345678' для 4-байтового int) с учетом BE/LE?

Не спутал, мне известна разница.

Честно говоря, никогда не использовал подобные неявные инициализации - многобайтовые литеральные константы.
И, судя по всему, правильно делал

"С какой стороны будет "обрезана" слишком длинная литеральная константа" - ни с какой, даст ошибку компиляции

В том-то и дело, что с литеральной константой компилятор дает лишь предупреждение (об этом выше уже шла речь).
Это как в int попытаться засунуть слишком длинный hex: int v = 0x123456780912345; - ошибки не будет, но будет соотв. предупреждение
В случае с hex все вполне однозначно - компилятор разместит его именно так, как нужно и читать его будет тоже так, как нужно (в зависимости от BE/LE).
С многобайтными литералами получается, что не все так однозначно и это зависит от BE/LE, о чем уже поделился XVR.

С литеральными все понятно и вопроса не было бы. Я про мультибайтную, сорри, попутал. Просто вообще ранее с таким не сталкивался
Блин, Вы меня запутали. Вот "например, '12345678' для 4-байтового int) " просто не скомпилируется, я о том

В том-то и дело, что все компилируется, но с warning
Без warning будет, если число символов строго совпадает с sizeof() соотв. переменной, куда присваиваем.

У меня лично вопрос остался один: какая часть этой слишком длинной литеральной строки будет обрезана в зависимости от BE/LE - правая или левая?

Ну Майкрософт ошибку дает, видимо кто на что горазд. Я С изучал раз 5, как и ++, после чего забывал все без практики. И каждый раз мир открытий чудных. Причем если С еще придраться не особо, то ++ с последними нововведениями скатился в откровенное черти что.

Раз пошла такая пьянка, то договаривайте ))