На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Модераторы: Qraizer, Hsilgos
Страницы: (77) « Первая ... 73 74 [75] 76 77   ( Перейти к последнему сообщению )  
> Текущий Стандарт С++ и перспективы его развития
    Интересно, по стандарту чему должно быть равно i в этом примере:
    ExpandedWrap disabled
      int i = 1;
      i = i++;
      По стандарту это ill-formed и UB. Ибо двойная модификация одной переменной в рамках одного же выражения.
        Цитата prografix @
        Интересно, по стандарту чему должно быть равно i в этом примере:

        https://en.cppreference.com/w/cpp/language/eval_order

        Добавлено
        Цитата Flex Ferrum @
        По стандарту это ill-formed и UB.

        Так по старому же вроде стандарту UB, в новом точки следования убрали ведь? Или вернее заменили на что то другое.
          Почему бы не ввести (нововведение) такую возможность: a.1 - взятие первого бита, и т.д.? Результат - bool. ASM-овские операции bt* есть, так что можно было бы и "p.3 = 1;" писать. :scratch:
            Тогда уж взятие элементов tuple, как в rust.
              Цитата Славян @
              Почему бы не ввести (нововведение) такую возможность: a.1 - взятие первого бита, и т.д.?
              Потому что большие/маленькие индейцы?
                Подобные расширения есть у некоторых компиляторов для микроконтроллеров. Даже тип bit встречал. Но чтобы заСтандартизировать такое... маловостребовано это. Настолько низкий уровень нынче редкость.
                  Ясно. Спасибо. :thanks:
                  Раньше, помнится, встречалось такое:
                  ExpandedWrap disabled
                    a++;
                    ...
                    a++;
                  Т.е. выгоднее было сделать дважды добавление единицы, чем один раз a += 2; А теперь (когда и 64 бита обрабатывается за такт, и один бит) ни компиляторы, ни программисты не задумываются о таких оптимизациях. Печалька. :'(
                    Сейчас соревноваться с компиляторами в оптимизации неблагодарное дело. Из мейнстримных, ясное дело, о специализированных разговор особый. К примеру
                    ExpandedWrap disabled
                      int x, y, *array, i;
                       
                      /* ... */
                      x += array[i++];
                      y += array[i++];
                    компилятор запросто может превратить в
                    ExpandedWrap disabled
                      MOV edx, array
                      MOV eax, i
                      ADD x, [edx+eax*4]
                      LEA eax, [eax+2*4]
                      ADD y, [edx+eax*4-4]
                    если посчитает нужным. А почему он так посчитал, а фикъегознает. Бывает, достаточно сменить тип процессора на Atom, и уже код иначе оптимизируется. Тут нужно очень уж хорошо знать целевой процессор, тогда как обычно нам это наоборот, не хочется, а хочется, чтобы было примерно одинаково хорошо на любом.
                      Цитата Славян @
                      Почему бы не ввести (нововведение) такую возможность: a.1 - взятие первого бита, и т.д.?

                      А если надо группу бит? Тогда уж лучше класс STL, который будет принимать на вход любой целочисленный тип, и методом at(begin, end) выдавать нужное значение, в том же целочисленном формате
                        Цитата B.V. @
                        А если надо группу бит?
                        Группа бит (меньшая 8 и большая, чем 1) не является базовой в x86/AMD64-архитектуре. А вот отдельный бит вполне можно считать хранящимся в каком-либо флаге регистра флагов. Так что такой низкоуровневый вариант выглядит вполне логично.
                        Замутки с классами и т.п. - уровень выше, а интересовала именно низкоуровневая возможность.
                          Так-то в Плюсах уже давно есть std::bitset<> и std::vector<bool>. Для эстетов недавно сделали std::span<>; для бит, правда, вряд ли не подойдёт, даже если компилятор поддерживает bit.
                          Просто обычно незачем. Не, ну если реально нужны контейнер или масштабные битовые операции... так-то проще наоператить прямо по самому int-у старыми добрыми |, & или ^, местами с ~. Честно говоря, никогда не сетовал по поводу отсутствия прямых битовых обращений.
                            Цитата Qraizer @
                            Честно говоря, никогда не сетовал по поводу отсутствия прямых битовых обращений.
                            Да я тоже, конечно; просто думается, что "школьники", увидевшие "a |= 64" будут понимать, что это несколько искусственное число, служащее лишь для установки такого-то бита. Посему, имей мы инструкцию "a.7 = 1", объяснения были бы естественнее.
                              А почему именно a.7 = 1? Как насчёт
                              ExpandedWrap disabled
                                for (int i=0; i<CHAR_BIT; ++i)
                                  a.i = b.(CHAR_BIT-1 - i);
                              Может быть стоит тогда подумать об
                              ExpandedWrap disabled
                                bit *ptr = &a.3
                              Слишком много вопросов без хороших ответов.
                                Цитата Славян @
                                просто думается, что "школьники", увидевшие "a |= 64" будут понимать, что это несколько искусственное число
                                Таким школьникам бью по рукам линейкой и заставляю сто раз писать на доске a |= 1 << 6. После этого у школьников появляется свободное время, которое они раньше тратили на не всегда правильные вычисления в уме ответа на вопрос "а какой же именно бит мы тут ставим?".
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (77) « Первая ... 73 74 [75] 76 77 


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,1022 ]   [ 17 queries used ]   [ Generated: 28.03.24, 23:44 GMT ]