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

[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]

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

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

[ViKo]

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

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

[DASM]

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

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

[jcxz]

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

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

[Forger]

CODE

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

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

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

[XVR]

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

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

[esaulenka]

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

Потому что это си.
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 аналогичный трюк работает без предупреждения.

[Forger]

В main.c аналогичный трюк работает без предупреждения.

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

[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).

[DASM]

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

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

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

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

[Forger]

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

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

[DASM]

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

Код

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

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

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

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

[Forger]

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

Код

int searchDB (int v)
....
searchDB('1234');

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

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

Код

Он ругается на куда более безопасные вещи

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

[DASM]

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

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

[Forger]

Стоп стоп. Почему Вы считаете это говнокодом и как бы Вы сделали, не городя монстра?

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

По сути из имени получается бесплатно подобие хэша.

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

[DASM]

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

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

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

[Forger]

Просто дали проект, сижу разбираюсь.

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

Но у меня обычно больший overhead, не люблю оптимизировать

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

[jcxz]

Иначе варианты начинают хотеть strcmp, или, страшно сказать std::map . А тут бесплатно

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

Код

  #define M(x0,x1,x2,x3) ((uint)(u8)(x0) | (uint)(u8)(x1) << 8 | (uint)(u8)(x2) << 16 | (uint)(u8)(x3) << 24)
  searchDB(M('1','2','3','4'))

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

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

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

[DASM]

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

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

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

[Arlleex]

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

Код

  #define M(x0,x1,x2,x3) ((uint)(u8)(x0) | (uint)(u8)(x1) << 8 | (uint)(u8)(x2) << 16 | (uint)(u8)(x3) << 24)
  searchDB(M('1','2','3','4'))

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

[Forger]

Не, сочувствовать не надо. Я во всех чужих программах ищу и нахожу что то новое.

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

Операционку он ucos юзал, не в восторге, но работает. Я хотел бы scmRTOS, но это потом.

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

Кстати крутая программистка .... поэтому с ней расстались.

Логично

[DASM]

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

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

[Forger]

проблема в собеседованиях. Давно были?

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

насчет двух минут смены горячитесь

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

, у многих еще и менджер памяти свой

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

[DASM]

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

[Forger]

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

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

[DASM]

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

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

[Forger]

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

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

[DASM]

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

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

[Forger]

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

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

Впрочем это ни о чем, как и весь топик.

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

[DASM]

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

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

[jcxz]

Операционку он ucos юзал, не в восторге, но работает. Я хотел бы scmRTOS, но это потом. Кстати крутая программистка, которая тоже сидела над этим проектом за нее.

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

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

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

[Forger]

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

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

[DASM]

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

[Arlleex]

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

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

И будем переписывать, например, freeRTOS по-русски. Вот я уже придумал название: "бесплОС" или "бесплатОС"

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

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

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

[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?

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

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

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

[DASM]

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

[Forger]

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

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

[DASM]

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

[Forger]

Вот "например, '12345678' для 4-байтового int) " просто не скомпилируется, я о том

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

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

[DASM]

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

[Forger]

то ++ с последними нововведениями скатился в откровенное черти что.

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

[DASM]

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

да нечитаемо все стало, и реально слишком сложно для изучения. К тому же сегодня словил странный глюк в МS на range based loop, как дома проверю - напишу.

[Forger]

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

Странно ... По мне как раз все наоборот - более свежие стандарты плюсов позволяют наоборот - сделать код проще, меньше текста, лучше читаемость и лучше оптимизация компилятора.
Может M$ идет каким-то своим путем? ..

[XVR]

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

Старшая. Сначала литеральная константа преобразуется в int (с учетом BE/LE), затем этот int будет усечён (если понадобится) по обычному правилу приведения типов.

Стандарт на этот счет весьма неопределен - implementation dependent

[DASM]

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

вот что тут https://msdn.microsoft.com/ru-ru/library/zzw4bwhd.aspx Микрософт имел в виду в

Код

vector <int> v5(5);
    for (auto i : v5) {
        v5[i] = i;
    }

и пишут, что v5 = 0 1 2 3 4 . А он нулевой будет в итоге, i это значения ветора по копии, а никак не индекс

[Forger]

По логике i тут должен быть int, для этого тут поставлен auto.
Такая конструкция должна правильно работать уже с C++11. Или я что-то не понимаю?

[DASM]

По логике i тут должен быть int, для этого тут поставлен auto.
Такая конструкция должна правильно работать уже с C++11. Или я что-то не понимаю?

v5[i] = i; - это фигня полная. Выражение for (auto i : v5) пробежит по всему вектору, присваивая i последовательные значения из этого вектора. Это не индекс. Так как вектор создан нулевым, то это будет так :
v5[0] = 0;
v5[0] = 0;
v5[0] = 0;
v5[0] = 0;
v5[0] = 0;
5 раз
Если сделать

Код

    vector <int> v5(5, 10);
    for (auto i : v5) {
        v5[i] = i;
    }

то будет access violation
ибо это v5[10] = 10; 5 раз подряд

[Arlleex]

то будет access violation

Именно из-за вот таких приколов и сложностей в понимании лично я не взлюбил C++. Хотя и достаточно вумных книжек прочитал по нему... Со временем понял, что выражение "Веревка достаточной длины, чтобы выстрелить себе в ногу(с)" имеет смысл. Был у нас один сотрудник, который всегда писал программы с применением, возможно, всех фишек C++. В итоге я ничего не понял из листинга (совсем!) даже относительно несложного проекта, а при попытке объяснить код сам программист пришел в замешательство со словами "ну, так делают другие программисты и оно так проще для понимания и удобнее". Жесть. И вот лично я люблю Си, чистый Си. И, возможно, не прочь выучить C++ нормально - но куда угнаться-то? Постоянно что-то новое. Считаю, что язык должен быть строгим в своем синтаксисе и однозначно трактуемым. Бомбануло у меня, помню, тогда, когда нашел штук пять разных способов инициализации членов класса при объявлении объекта... Брр, даже не стану вспоминать. Можете ругать

[Forger]

Это не индекс.

По-ходу i - это в данном случае итератор ...

Попытался эти примеры прокомпилить в старом добром keil (компилятор v6).
Примеры собирает, но отлаживать их вообще неудобно: вроде i по окну watch - int, а нифига - это действительно итератор. Пример и правда не работает, как ожидается ((



Честно говоря, не использовал так активно штатные шаблоны (в частности std::vector). До умного for() так и не добрался.
Выяснил, что они могут неявно использовать кучу.
А кучу не использую, в известных целях (речь про обычные МК).

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

Мне лично из C++11 (для меня нового) пришлись по душе жесткие ограничения при неявном приведении типов - нужно ставить явный static_cast или переписывать код.
Также пригодилась инициализация полей классов прямо в описании класса (например, какие-нить константы), т. е. максимально возможный уход от #define.
const_expr - вообще чудесная штука. Также считаю полезными final и override.... Это пока то, что вспомнил с ходу.

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

[DASM]

i это не итератор, это локальная переменная типа элемента вектора. Сравните

Код

    struct fio
    {
        string f;
        string i;
    };
    vector <fio> names {{ "ivan", "ivanov" }, {"petr", "petrov"}};
    for (auto &r : names)    
        r.i = "sidorov";
    for (auto r : names)
        cout << r.f << " " <<  r.i << endl;

[Herz]

Господа, пора бы остановиться, а? Очень не хочется превращения темы в очередной холивар.
Понятно, что у любых языков, стандартов и компиляторов полно недостатков. Тем более понятно, что умельцы всегда могут наворотить чудес в коде...
Обсуждать всякие причуды, валя всё в кучу, смысла нет, ИМХО.

Можете ругать

Нет, давайте не будем. У всех свои предпочтения, но провоцировать свару не надо. Это предупреждение.

[Forger]

i это не итератор, это локальная переменная типа элемента вектора.

В моем компиляторе - это не просто int. Я это проверил: попытка присвоить содержимое этого i кому-нить еще (я пробовал простой массив int a[5]; ), приводит к копирования некого адреса где-то в ОЗУ, но вовсе не содержимого. Это видно в окне watch.
Да и ходьба по шагам, где происходит обращение к i, кидает во внутренний некий файл iterator, где все это происходит.
Короче, for() в этом компиляторе тут ни разу не for() как это в привычном C или старом C++03, а разворачивается в конструкцию по-сложнее: https://en.cppreference.com/w/cpp/language/range-for (см. раздел Explanation)
По крайней мере, если речь идет про vector или что-то подобное.

[DASM]

Это int. Дома посмотрю, почему у Вас сомнения

[DASM]

Проверил, это точно int , собственно и сомнений не было. Итераторы конечно используются для такого for, но тип i - это int

Код

    vector <int> iv (5, 1);
    for (auto i : iv)
    {
        int tmp;
        decltype (i) intger = 0;
        tmp = intger;
        intger = tmp;        
    }

Эскизы прикрепленных изображений

 

[Forger]

Проверил, это точно int , собственно и сомнений не было. Итераторы конечно используются для такого for, но тип i - это int

Попробуйте это i присваивать внутри цикла например в какой нить примитивный массив из int, но для индексации внутри массива НЕ используйте саму i.
Что будет в массиве при выходе из цикла?

[DASM]

Попробуйте это i присваивать внутри цикла например в какой нить примитивный массив из int, но для индексации внутри массива НЕ используйте саму i.
Что будет в массиве при выходе из цикла?

Код

    vector <int> iv (5, 1);
    int trace[5];
    int ix = 0;
    for (auto i : iv)
    {
        trace[ix++] = i;
    }

trace стал 1,1,1,1,1 что абсолютно верно

[Forger]

Заглумил я тут всех
Короче, увеличил кучу, все стало работать правильно! Дело было в том, что куча у меня не используется и на нее выделяется от силы 16 байт. Тут этого было мало.

Ради финальной проверки, инициализирую iv так:

Код

vector <int> iv = {1, 2, 3, 4, 5};
int trace[5];
int ix = 0;
for (auto i : iv)
{
    trace[ix++] = i;
}

И результат соответствующий: trace: 1, 2, 3, 4, 5.

Получается, что все верно: при каждой итерации for (auto i : iv) вызывается оператор копирования из вектора iv, а результат кладется в i, которая все верно - обычная int (проверил через sizeof)
Имхо, это несколько непривычно для восприятия цикла for, ведь "i" тут - вовсе не индекс для перебора внутри вектора, а лишь копия одного из его элементов,
или по-другому - результат, возвращаемый внутренним итератором (в данном цикле создается неявно).

Фактический такой пример будет работать правильно, если iv заранее правильно заполнить:

Код

vector <int> iv = {0, 1, 2, 3, 4};
int trace[5];

for (auto i : iv)
{
    trace[i] = iv[i];
}

Тогда trace: 0, 1, 2, 3, 4




Кстати, с полностью включенной оптимизацией это все выходит довольно компактно и работает шустро (судя по данным из окна disasm)!

зы. Удивило, что даже статическое (или в стеке) создание "банального" vector все равно требует наличия кучи
Это как-то странно. Надо бы разобраться....

[DASM]

"несколько непривычно для восприятия цикла for," зато удобно, например скалярное умножение вектора на 2 :

Код

for (auto& i : iv)
  i *= 2;

хотя в принципе можно и через разыменование итератора.. в общем как сделано так сделано
"если iv заранее правильно заполнить:" мне непонятно как в микрософт попал пример с такой жуткой ошибкой
" vector все равно требует наличия кучи " вектор же динамический, может увеличиваться и уменшаться на ходу. Как это статически или на стеке сделать то?

[Forger]

мне непонятно как в микрософт попал пример с такой жуткой ошибкой

Значит, ошибок там может быть еще больше ...

" vector все равно требует наличия кучи " вектор же динамический, может увеличиваться и уменшаться на ходу. Как это статически или на стеке сделать то?

Это логично при изменении размера вектора (добавляем/удаляем), но ведь не для создания же ... Это-то меня и удивляет

[DASM]

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

[Forger]

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

Я про то, где хранится описательная часть вектора. Т.е. некая структура, хранящая, скажем, двусвязный список и другую служебную инфу по вектору.
Короче, логика работы понятна: вектор состоит из двух "кусков": описательная часть вектора, лежит там, где создаем (стек, статика или даже куча).
А сами данные - всегда в куче.
По логике, получается, если вектор пустой, то и нет обращения к куче.
Но даже статическое создание вектора с известным числом элементов все равно использует кучу... Разобрался ))

Гы, лезем в дебри std, а это уже откровенный офф

[esaulenka]

Я дико извиняюсь, но почему обсуждение стандартной библиотеки языка си++ (наиболее базовых вещей из неё) - "откровенный офф" ?

"Откровенный офф" - это пара страниц обсуждения дурацкой опечатки у майкрософта.

А STL прямо вот очень рекомендую посмотреть. Умные люди понаделали велосипедов почти на все случаи жизни.

PS для статического создания массивов есть std::array, ему куча не нужна (но при этом у него нет push()/pop())
PPS в кишках std::vector НЕТУ двусвязного списка (и вообще списка нет). Это один сплошной массив. И да, этот массив создеётся в куче.

[Forger]

Я дико извиняюсь, но почему обсуждение стандартной библиотеки языка си++ (наиболее базовых вещей из неё) - "откровенный офф" ?

Эта тема вообще ни разу не про C++ и уж тем более про STL
Но тенденция "скатиться к этому" есть почему-то у каждой темы в этом разделе ...

"Откровенный офф" - это пара страниц обсуждения дурацкой опечатки у майкрософта.

Это не офф, это - пустой треп

А STL прямо вот очень рекомендую посмотреть. Умные люди понаделали велосипедов почти на все случаи жизни.

К сожалению, STL довольно толстая библиотека и, если и стоит ее использовать в конкретнтных встраиваемых приложениях, то как можно активнее.
Поэтому пока что у меня лично нет возможности совать ее во все проекты без исключения.
Другая причина - активное использование кучи.
Причем, опасения вызывает даже не сам факт использования кучи (если "правильно ее готовить", то ничего страшного в ней нет),
а то, что STL использует кучу неявно. Можно сказать, непредсказуемо. Поэтому без перегруженных new/delete уж никак не обойтись.
А еще хлеще, что наверняка придется перегружать еще и локальные new/delete ("локальные", это значит - предназначенные для конкретных классов, точный термин не помню).
Например, вместо фрагментируемой кучи использовать более безопасные "пулы" для конкретно взятых классов.
С этой точки зрения Ваша фраза "понаделали велосипедов" может звучать уже иначе

PS для статического создания массивов есть std::array, ему куча не нужна (но при этом у него нет push()/pop())

Это все понятно ))) Книжки читать умеем )
Но речь зашла именно про vector и почему у меня он так работал. Но к счастью разобрался. Короче, проехали

PPS в кишках std::vector НЕТУ двусвязного списка (и вообще списка нет). Это один сплошной массив. И да, этот массив создеётся в куче.

Некая "описательная" часть этого массива все равно требует места для хранения, а точнее хранится именно там в какой области объявили этот vector.
Например, для случая: std::vector <int> v = {0, 1, 2, 3, 4};
sizeof(v) = 12 байт (arm compiler v6)

А уже сами данные вектора хранятся в куче.
Именно это момент вызвал проблемы в моем случае.
Кстати, размер выделенных в куче данных может оказаться даже больше, чем было "запрошено". Таков функционал этого vector - выделяет с неким запасом.

Напомню причину: у меня в текущих и старых проектах куча имеет минимально возможный размер (вроде 8 байт) и в принципе не используется, т.к. не особо-то и нужна.
По-хорошему мне стоит "перегрузить" штатные malloc и free (их используют new/delete) на некие "заглушки-ловушки"...

[XVR]

Другая причина - активное использование кучи.
Причем, опасения вызывает даже не сам факт использования кучи (если "правильно ее готовить", то ничего страшного в ней нет),
а то, что STL использует кучу неявно. Можно сказать, непредсказуемо. Поэтому без перегруженных new/delete уж никак не обойтись.
А еще хлеще, что наверняка придется перегружать еще и локальные new/delete ("локальные", это значит - предназначенные для конкретных классов, точный термин не помню).

Не надо. У всех контейнеров в STL есть шаблонный параметр - аллокатор (и он практически никогда не передаётся, а используется аллокатор по умолчанию - через new/delete и кучу)
Делаете свой аллокатор (с любым местом расположения объектов и алгоритмом алокации) у вуаля - всё управление кучей в ваших руках

[Forger]

Не надо. У всех контейнеров в STL есть шаблонный параметр - аллокатор

Тем проще ))
Тем не менее, проблем с неявным обращением к куче, т.е. вызовом этого самого аллокатора, увы, все равно не избежать
Фактически, при активном использовании STL, имхо, всегда нужно держать "руку на пульсе": строчить свои аллокаторы на каждый вид объектов...
Повторюсь, что речь в данном случае про встраиваемые системы на обычным МК.
Пока что очкую применять STL в аппаратно-критичных приложениях, а других у меня и нету ))

[Kabdim]

Не стоит забывать что stl который с компилятором не прибит гвоздями. В геймдеве схожие с эмбедедом проблемы и написаны адаптированные под такие проблемы библиотеки. EASTL например, который выглядит намного разумней того что предлагает стандарт и производители компиляторов.

[Forger]

EASTL

EASTL как вариант, конечно, хорошо. К тому же он полный опенсорс с необходимыми бенчмарками и соотв. тестами, но есть одно важное НО:
применение STL, судя по всему, требует соотв. экспиренса в наших программных делах. И, судя по всему, весьма немалого!
Тут многие местные "программеры" от банальных плюсов шарахаются, как от вампиры от чеснока, а что уж говорить про STL....
Признаюсь, и я не исключение: например, категорически не применяю heap

А у ж в этом разделе "В помощь начинающему > Программирование" весь этот STL - это как показать самолет изолированному племени аборигенов
Имхо, "демонстрация" STL в реальных проектах зачастую может выглядеть как банальное хвастовство перед коллегами по проекту, а вовсе не по необходимости
Провожу аналогию с "голым" С и плюсами - дай плюсы, например, упоротому фанату-указателей-где-надо-и-не-надо, так он и код на плюсах умудрится сделать опасным и напрочь нечитаемым и вообще не поддающимся сопровождению
Поэтому я, уверен, что при должном и разумном применении этот самый STL даже в "стоковом" виде имеет место быть, как раз именно по необходимости.

[Herz]

применение STL, судя по всему, требует соотв. экспиренса в наших программных делах.

А простого опыта будет недостаточно? Может, в этом собака порылась? Люди опасаются, что с "экспириенсом" у них проблемы, а оно и... "не так страшен черт", если разобраться...

[Forger]

А простого опыта будет не достаточно?

Увы, этого не достаточно ((
Нужно читать очень много чужого кода, очень много.

Люди опасаются, что с "экспириенсом" у них проблемы, а оно и... "не так страшен черт", если разобраться...

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

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

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

[Herz]

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

[Forger]

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

Уже давно английский стал неким не побоюсь этого слова всепланетарным языком, особенно в программировании.
В целом с Вами согласен, но с одной поправкой - вместо слова, например, экспириенс стоит использовать иноземное написание: experience.
А иногда, просто лень искать правильное написание того или иного слова в оригинале

[Herz]

Вот именно.

[Forger]

чем буржуазный "экспириенс" ценнее отечественного опыта

Слово experience в данном смысле более точно отражает смысл опыта программиста как такового, чем слово "опыт". Более обще, что-ли.
experience <-> опыт в программировании - это примерно то же самое (в моем понимании), как, например, volvo <-> ВАЗ.
Ничего против ВАЗа как такого я не имею, но, думаю, мысль моя понятна