А почему так инициализация Опции

[DASM]

CODE

struct lala
{
char *p;
}
....
lala la = {"the"};
*(la.p) = '1'; // access violation

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

[aaarrr]

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

[ViKo]

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

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

[aaarrr]

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

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

char *p = "abc";
defines p with type ‘‘pointer to char’’ and initializes it to point to an object with type ‘‘array of char’’
with length 4 whose elements are initialized with a character string literal. If an attempt is made to use p to
modify the contents of the array, the behavior is undefined.

[DASM]

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

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

[XVR]

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

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

[jcxz]

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

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

В примере:

Код

  static void Func(char *s) { s[1] = 0; }
  static char const t1[] = "test";
  static char const *t2 = "test";
  Func("test");
  Func(t1);
  Func(t2);

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

[XVR]

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

В примере:

Код

  static void Func(char *s) { s[1] = 0; }
  Func("test");

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

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

Код

int searchDB (int v)
{
//..............
}
.... main...
searchDB('1234');

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

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

[Forger]

Единственный её минус

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

[XVR]

В данном случае это - не единственный минус.
В этом достаточно убедится, попытавшись дать не sizeof(int), а меньше символов, например 2 или 3.

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



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

[Forger]

А в чём проблема?

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

[XVR]

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

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

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

Нули или "мусор" из стека? "Стандарт" описывает эти нюансы?

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

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

[Forger]

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

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

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

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

Может вы спутали литеральные константы и строки?

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

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