На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Модераторы: Qraizer, Hsilgos
Страницы: (77) « Первая ... 5 6 [7] 8 9 ...  76 77  ( Перейти к последнему сообщению )  
> Текущий Стандарт С++ и перспективы его развития
    Цитата Qraizer @
    Впрочем, переприсваивание параметров циклов в теле этих же циклов тоже как-то не совсем структурно, но это уже если придираться.

    Совершенно согласен. . :)
      Переприсваивание параметров вдобавок запутывает код почище тех же goto
        Времени дописать обещанный(и уже как полтора месяца валяющийся почти законченным) обзор TR2 совсем нет.
        Также совсем нет времени просмотреть 4 пакета документов, вышедших с момента моего обзора, и написать что интересного там добавили.
        Но вот, наткнулся на краткий отчёт Саттера об одной из последних встреч. Помимо того о чём я уже писал выше там есть это:


        Language Support for Transporting Exceptions between Threads.
        Языковая поддержка обмена исключениями между потоками исполнения.

        (n2179)

        Очень радует, что поддержка многопоточности в С++09 будет не просто "пустым звуком" на бумаге, а вполне реальной возможностью языка без необходимости через строчку использовать грязные хаки и особенности платформы для реализации чего-либо более реального, чем абстрактный hello world в два потока.

        Суть нововведения в следующем: есть некий std::exception_ptr, который имеет семантику shared_ptr(т.е. разделяет владение - это в proposal явно не указано, но, насколько можно сделать вывод из описания copy_exception - это так).
        Вы можете:
        1. Получить указатель на текущее исключение - current_exception( )
        2. Перебросить исключение на которое имеется такой указатель - rethrow_exception( exception_ptr p )
        3. Получить указатель на копию исключения - copy_exception( E e ).

        Зачем нужна последняя ф-ция я не особо догоняю(только если отдать другому потоку копию, а не оригинал, только зачем? :huh:). В proposal написано, что она нужна из соображений эффективности 0_о.
          Подскажите пожалуйста( может где я не так мыслю ? :-), собираются ли убрать или убрали уже предупреждение о том что строки вида :
          ExpandedWrap disabled
            int x;
            x|=-1;


          или

          ExpandedWrap disabled
            int x;
            x &= 0;


          выдают компилятором предупреждение ? // possible "ранняя операция перед присваиванием"...
          Так просто финальный код короче, а смысл очевидный - зануление и постановка всех бит в 1.
            Ну, финальный код короче - ещё не факт, что быстрее. ИМХО, компилятору виднее, как это сделать эффективнее. Или ты думаешь, что он настолько тупой, что при случае сам до такой оптимизации не додумается? Додумывается, сам иногда видел, а где не видел, значит оптимизатор не посчитал нужным. Вывод: варнингу быть, ибо по-любому имеет место юзанье переменной до инициализации. Не надо привыкать к хакам, может аукнуться.
              1.Да, я думаю, что он столь тупой.
              2.Это не оптимизатор считает что-то нужным, а люди думают, сколько они сил готовы потратить, чтобы усилить оптимизатор. И часто махают рукой.
              3.Использования переменной нету, ибо тут она вчистую превращается в ноль или полностью забивается единицами.
              Но, в целом, жаль, что Warning'у быть... :-(
                Цитата Славян @
                Использования переменной нету

                А здесь тоже нету?
                ExpandedWrap disabled
                  int x = ...;
                  int y = x - x;
                  Да, и здесь компилятор (оптимизатор?) должен обнулить и всё. И чихать он должен хотеть на вычитание. Или я чего-то не понимаю? Ж:-)
                    Я попробую привести пример, который, возможно, прояснит ситуацию.
                    ExpandedWrap disabled
                      struct A
                      {
                          A(int value)
                              : value(value)
                          { }
                       
                      protected:
                          A operator -(const A &rhs)
                          { return A(value - rhs.value); }
                       
                      private:
                          int value;
                      };
                       
                      int main()
                      {
                          A x = 100;
                          A y = x - x; // error
                      }

                    Здесь, несмотря на то, что происходит очевидное зануление, компилятор выдаст не просто предупреждение, а ошибку компиляции. Просто потому, что по Стандарту такой код корректной реализацией компилировать не должен(ill-formed code).

                    Так вот, есть в Стандарте такое понятие как UB(undefined behavior). Это тоже ошибка, но корректная реализация имеет право скомпилировать код(и, как правило, скомпилирует). UB относится к тем случаям, которые далеко не всегда можно детектировать, так что реализация в праве вообще молчать как партизан на такую строку. Но, хорошая реализация в детектируемых случаях старается предупредить программиста, что он пользуется очень опасной конструкцией. Собственно говоря, об этом Вас компилятор и предупреждает. Он не говорит, что это работать будет как-то не так. Он говорит, что такой код по Стандарту имеет право вывести на экран "i'm is a result of code, written by foolish programmer". Если вы можете позволить себе пользоваться такими конструкциями, то можете успешно посмотреть на это предупреждение сквозь пальцы, а то и вообще выключить предупреждения в принципе(зачем они вам - вы же намного умнее компилятора с оптимизатором, правда, с такими амбициями, рекомендую посмотреть в сторону языка ассемблера).
                      Ну для int может и не актуально, но вот если бы там был double, то x - x уже нельзя заменить на 0.
                        Спасибо.
                        Да я давно туда смотрю и хожу, но С не бросишь полностью. Просто тут пример с классами, это принципиально громаднее выглядит, чем int y=x-x; И конечно хочется, чтобы на просто выглядящие вещи оптимизатор бы обращал побольше внимания, а не заваливал предупреждениями по делу и без оного.
                        Ладно, буду сожалеть про себя далее... :-( :-)

                        Добавлено
                        И чем double хуже? Там ноль тоже нормальный, не надо ля!
                          Цитата Славян @
                          Там ноль тоже нормальный, не надо ля!

                          Там результат вычисления неточный. А, если оперировать с нечислами, представленными double'ом, то вообще ни о каком нуле речи быть не может :).
                            Я знаю. Просто за много лет у меня не было ни одной программы где я бы пользовался нечислами в double. А все неточности расчётов с числами тут оптимизатор должен забыть и написать обнуление.
                              Если x - конечное число, то получим вполне точный ноль. Тут все ок.
                              Но, если не инициализировать x, то там может оказатся значение +inf, -inf или даже NaN. Вот тут-то вычитание и вернет нам далеко не ноль.

                              Добавлено
                              Эх, опять я торможу с ответами :)
                                Цитата Славян @
                                Просто за много лет у меня не было ни одной программы где я бы пользовался нечислами в double

                                Вы не поверите - они, порой, сами по себе появляются :).

                                Цитата Славян @
                                А все неточности расчётов с числами тут оптимизатор должен забыть и написать обнуление.

                                Молодой человек, мы разговариваем о С++ или о каком-то, вымышленном Вами языке?(вопрос не риторический)
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (77) « Первая ... 5 6 [7] 8 9 ...  76 77


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0442 ]   [ 16 queries used ]   [ Generated: 27.04.24, 02:08 GMT ]