На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (11) « Первая ... 8 9 [10] 11  все  ( Перейти к последнему сообщению )  
> Баллада о ссылках в С++
    Цитата Flex Ferrum @
    Я считаю, что в C++ есть тип int (относится к категории фундаментальных), и что есть декларации, тип которых может быть "ссылка на тип int".

    Тогда почему я могу специалищировать шаблон класса, например, типом int&, если это не тип? Почему я могу указать int& везде(ну почти, есть исключения), где требуется указать тип?

    Цитата
    Это знаешь, как у Хайдеггера (в переводе) термин "бытие" может использоваться в пяти разных смыслах. :D

    С Хайдеггером у меня не задалось...

    Это сообщение было перенесено сюда или объединено из темы "D vs C++"
      Цитата D_KEY @
      const int является типом, да.

      Является типом декларации. Говорить при этом, что const является типом - нельзя. Есть декларация, есть некий тип1 (из категории fundamental или compound), и есть некий тип2, который тип1 с навешанными на него дополнительными характеристиками (константность, волатильность, ссылочность, и прочее). Тип1 - это из системы типов, а тип2 - это тип конкретной декларации. Ссылки не входят в множество того, что является типом1. Но они могут быть навешаны на него и произвести тип2.

      Это сообщение было перенесено сюда или объединено из темы "D vs C++"
        Цитата Flex Ferrum @
        D_KEY, ты ответь. const в С++ - это тип или нет? А volatile? А массив? А функция?

        const int - тип. Так же как int[100500]. И int&, про который я и спрашиваю, зачем он существует как тип.

        Это сообщение было перенесено сюда или объединено из темы "D vs C++"
          Цитата D_KEY @
          Тогда почему я могу специалищировать шаблон класса, например, типом int&

          Ты можешь его и сигнатурой функции специализировать. :)

          Это сообщение было перенесено сюда или объединено из темы "D vs C++"
            Цитата Flex Ferrum @
            Я продемонстрировал, как компилятор может оптимизировать ссылки и не оптимизировать указатели в схожих ситуациях. Я не знаю, что ты там увидел, но показывал я именно это. И ассемблерный код это подтверждает.
            Может тебе напомнить, забывчивый ты наш? :D Смотри:
            Цитата Flex Ferrum @
            Цитата Qraizer @
            Учёт этой штуки по факту заставляет компилятор запрещать многие оптимизации.

            Что и было мною продемонстрировано на примерах.
            И тобой было продемонстрировано именно то что имел в виду Qraizer? Как ссылка запретила компилятору многие оптимизации? Ты всего лишь продемонстрировал, как volatile запрещает компилятору оптимизировать доступ к переменной. Правда непонятно зачем, потому что для этого volatile и было придумано.
            Цитата Flex Ferrum @
            Да нет. Я явно сказал компилятору, что можно, а что нельзя, причём корректными средствами. А не с помощью злобных кастов от одного к другому.
            Ну и я сделал, тоже корректными средствами, без злобных кастов, ссылка перестала оптимизироваться.
            Цитата Flex Ferrum @
            Батенька, тут показано именно то, о чём я говорил. :) Ссылка на временный объект (внезапно) начинает "держать" этот объект. :) Компилятор так решил. :) Вот тут, внезапно, ссылка превращается... Превращается ссылка... Во временный объект:
            Компилятор особо ничего не решал, у него не было выбора. Да и ссылка, которая превратилась во временный объект, совсем не соптимизировалась, а реализация в коде полностью совпадает с указателем. Бу-га-га-га.
            Цитата Flex Ferrum @
            С чего бы это? Ведь ссылка - это не более, чем сахарный константный указатель? :)
            Я имел ввиду реализацию. Компилятор внутри реализует ссылку как указатель, который может соптимизироваться, а может и нет. Что тебе было продемонстрировано в примере. В очень многих случаях указатель может полностью заменить ссылку. Только при удержании временных объектов ссылка ведет себя по иному. Ну и я уже соглашался с тобой, что концептуально ссылка - это псевдоним.
            Цитата Flex Ferrum @
            Бинарную десериализацию никогда не писал? :) Там такие штуки ловятся "на раз", если не знать, где грабли зарыты.
            Писал много раз. Крайний раз MessagePack. Никаких проблем не было.
            Ну и, все-таки, хотелось бы маленький, но конкретный пример. Типа вот тут проблема с pointer aliasing из-за указателя. Меняем его на ссылку и вуаля, проблема ушла. Для простоты, разрешается даже говнокод с мутными кастами.
            Цитата Flex Ferrum @
            Ты, похоже, неправильно прочитал собою же процитированное из стандрата. Ты же сам привёл пример (https://ideone.com/CkeMhZ ), где константная ссылка прекрасно "держит" временный объект, возвращённый функцией.
            Я все прочитал правильно. Речь шла не о просто временных объектах, а о ссылках на временные объекты возвращаемые из функции. Или ты издеваешься, или какое-то недопонимание между тобой и мной.

            Это сообщение было перенесено сюда или объединено из темы "D vs C++"
            Сообщение отредактировано: applegame -
              Цитата Flex Ferrum @
              Цитата D_KEY @
              const int является типом, да.

              Является типом декларации. Говорить при этом, что const является типом - нельзя. Есть декларация, есть некий тип1 (из категории fundamental или compound), и есть некий тип2, который тип1 с навешанными на него дополнительными характеристиками (константность, волатильность, ссылочность, и прочее). Тип1 - это из системы типов, а тип2 - это тип конкретной декларации. Ссылки не входят в множество того, что является типом1. Но они могут быть навешаны на него и произвести тип2.

              Откуда ты это взял? Найди пруф на это.
              Цитата
              3.9 Types
              1 [Note: 3.9 and the subclauses thereof impose requirements on implementations regarding the representation of types. There are two kinds of types: fundamental types and compound types. Types describe objects (1.8), references (8.3.2), or functions (8.3.5). end note]


              Цитата
              3.9.2 Compound types
              1 Compound types can be constructed in the following ways:
              (1.1) arrays of objects of a given type, 8.3.4;
              (1.2) functions, which have parameters of given types and return void or references or objects of a given type, 8.3.5;
              (1.3) pointers to void or objects or functions (including static members of classes) of a given type, 8.3.1;
              (1.4) references to objects or functions of a given type, 8.3.2. There are two types of references:
              (1.4.1) lvalue reference
              (1.4.2) rvalue reference
              ...


              Добавлено
              А если все, как ты говоришь, тогда C++ - ещё более лютое говно, чем я думал :(

              Это сообщение было перенесено сюда или объединено из темы "D vs C++"
              Сообщение отредактировано: D_KEY -
                Договоритесь, что под "тип ссылка" имеется в виду "ссылочный тип", то бишь композитный тип, в котором ссылка скомбинирована с фундаментальным или композитным типом. А то слово "ссылка" может быть воспринята как псевдоним, а не тип.

                Это сообщение было перенесено сюда или объединено из темы "D vs C++"
                Сообщение отредактировано: applegame -
                  Цитата applegame @
                  Все равно твоя аргументация сводится к отсылкам к собственным постам (в том числе в весьма отдаленном прошлом), к фейспалмами и советам пойти куда-нибудь далеко учить матчасть. Такую "аргументацию" оставь при себе.
                  Возвращаю: когда оппонент выцепляет непринципиальную пару слов в двухабзацном посте и на протяжении трёх ответов игнорирует эти оставшиеся два абзаца, полностью зациклившись на непринципиальных двух словах, он, мягко говоря, демонстрирует свою полную некомпетентность в вопросе, о котором спорит. Был бы на твоём месте троль, реакция была бы другой, ну а иначе... ты ожидал чего-то, кроме фэйсплма?

                  Добавлено
                  Цитата applegame @
                  Qraizer, говорил, о том, что, в отличие от указателей, ссылки помогают избежать опасных агрессивных оптимизаций.
                  ЧЁ??Эм... но коментс, коллега.

                  Добавлено
                  P.S. Надеюсь, ты обиделся именно на посыл в 8 класс. Это уже вообще ни в какие ворота.

                  Добавлено
                  Цитата Flex Ferrum @
                  Поясни примером кода, что ты имеешь в виду.
                  Зачем? Ты это уже прекрасно продемонстрировал и без всяких полей. Агрессивная оптимизация к ссылкам применима легче, чем к указателям. Я упомянул поля в классах, потому что их инициализация выполняется всегда (в случае указателей необязательно) в конструкторах, а используются они в подавляющем большинстве случаев в остальных методах, и это сильно разные точки в общем потоке исполнения программы, и они не расположены в пределах некоего одного блока функции/метода. В случае ссылок компилятор – для уже сконструированного экземпляра – всегда уверен в их значениях и никогда не может быть уверен в значениях указателей.

                  Это сообщение было перенесено сюда или объединено из темы "D vs C++"
                  Сообщение отредактировано: Qraizer -
                    Цитата Qraizer @
                    ЧЁ??Эм... но коментс, коллега.
                    Я тогда хз, как понимать вот эту твою. фразу, коллега:
                    Цитата Qraizer @
                    Если интересно и ещё не в курсе, почитай в гугле на тему "pointer aliasing". Учёт этой штуки по факту заставляет компилятор запрещать многие оптимизации. Которые доступны при замене указателей на ссылки,
                    Я это понял так, что по твоему ссылки позволяют применять оптимизации, которые с указателями могут вызвать проблемы с pointer aliasing. Что не так?
                    Цитата Qraizer @
                    P.S. Надеюсь, ты обиделся именно на посыл в 8 класс. Это уже вообще ни в какие ворота.
                    Какой злой. Но я на тебя не обижаюсь. :)
                    Цитата Qraizer @
                    Зачем? Ты это уже прекрасно продемонстрировал и без всяких полей. Агрессивная оптимизация к ссылкам применима легче, чем к указателям.
                    В равных условиях не легче. Флекс явно запретил оптимизацию для указателя и заявил: "вот смотрите компилятор не смог оптимизировать указатель!". Ваша наглость не знает границ, господа. На всякий случай еще раз код:
                    ExpandedWrap disabled
                      #include <cstdio>
                       
                      void Refs1()
                      {
                          volatile int a = 10;
                          volatile int& b = a;
                          volatile int* volatile c = &b; // волатильный указатель - явный запрет оптимизации
                          
                          std::printf("%d", a);
                          std::printf("%d", b);
                          std::printf("%d", *c);
                          std::printf("%p", c);
                      }
                    Пикантности добавляет тот факт, что волатильный указатель сам по себе - достаточно бесполезная штука и в реальной жизни вряд ли встречается.
                    Цитата Qraizer @
                    Я упомянул поля в классах, потому что их инициализация выполняется всегда (в случае указателей необязательно) в конструкторах
                    Ну вот давай без эмоций и посыланий в 8-й класс. Может я и правда чего-то не знаю в плюсах. Но константный указатель тоже нужно обязательно инициализировать в конструкторе. Иначе как объяснить, что этот код не компилируется:
                    https://glot.io/snippets/erji17fi8u
                    ExpandedWrap disabled
                      class Foo {
                          int* const c;
                      };
                       
                      int main() {
                          Foo foo;
                      }

                    Цитата Qraizer @
                    В случае ссылок компилятор – для уже сконструированного экземпляра – всегда уверен в их значениях и никогда не может быть уверен в значениях указателей.
                    Но ведь в случае константных указателей компилятор тоже будет уверен. Не так ли? Без фейспалмов, скажи, так это или не так? Смотри вышеприведенный код.

                    Добавлено
                    То о чем говорил D_LEY:
                    Цитата Stroustrup. Why does C++ have both pointers and references?
                    C++ inherited pointers from C, so I couldn't remove them without causing serious compatibility problems. References are useful for several things, but the direct reason I introduced them in C++ was to support operator overloading.


                    Это сообщение было перенесено сюда или объединено из темы "D vs C++"
                    Сообщение отредактировано: applegame -
                      Знаете, что показала тема?
                      Что даже одни из самых адекватных и имеющих хороший профессиональный уровень форумчан не в состоянии вести нормальную дискуссию с аргументацией, признанием ошибок и без перехода на личности.

                      Это сообщение было перенесено сюда или объединено из темы "D vs C++"
                        На самом деле в C++ существует несколько разновидностей ссылок, требующих разного подхода к их реализации
                        Навскидку
                        Ссылки первой разновидности ссылаются на объекты, к которым и без них можно обратиться. Их ещё называют псевдонимами. Обычно компилятор не выделяет для таких ссылок память, а напрямую обращается к объекту ссылки. Впрочем, при оптимизации компилятор может захешировать такую ссылку, как впрочем может захешировать любой другой часто используемый адрес.
                        Ссылки второй разновидности, ссылающиеся на некоторый объект, доступный только в момент инициализации ссылки (например, конструируемый или получаемый из какой-нибудь функции). Такие ссылки сходны с обычным константным указателем, с автоматическим разыменованием, и возможным вызовом деструктора в конце области видимости.
                        Ссылки, передающие значения в функцию, возвращающие их из функции. Могут иметь lvalue или rvalue-семантику. Нужны для того, чтобы без нужды не копировать сложные объекты, для реализации полиморфизма. Пожалуй, обладают самым сложным поведением из всех.
                        Ссылки, являющиеся частью составных объектов. Эти похожи на вторую разновидность.

                        Это сообщение было перенесено сюда или объединено из темы "D vs C++"
                          Тут по тырнетам ходит цитата Страуструпа:
                          Цитата
                          Очевидной реализацией ссылки является (константный) указатель, при каждом использовании которого происходит разыменование. В некоторых случаях компилятор может оптимизировать ссылку таким образом, что во время исполнения вообще не будет существовать объекта, представляющего ссылку.


                          Это сообщение было перенесено сюда или объединено из темы "D vs C++"
                            Цитата applegame @
                            И тобой было продемонстрировано именно то что имел в виду Qraizer? Как ссылка запретила компилятору многие оптимизации? Ты всего лишь продемонстрировал, как volatile запрещает компилятору оптимизировать доступ к переменной. Правда непонятно зачем, потому что для этого volatile и было придумано.

                            Давай я напомню тебе, что именно написал Qraizer:
                            Цитата Qraizer @
                            В общем случае не может. Даже больше: может в ограниченном количестве случаев. Всё потому, что указатель доступен программисту как есть, поэтому компилятор не может гарантировать, кто где-то, в невидимом ему контексте, этот указатель программером не поменяется, даже если всё время жизни объекта-указателя у него перед глазами. ... Учёт этой штуки по факту заставляет компилятор запрещать многие оптимизации. Которые доступны при замене указателей на ссылки, т.к. единственное место, где ссылка может поменять своё значение – это точка её инициализации.

                            То есть, суммируя, ссылки позволяют компилятору более агрессивно оптимизировать опираясь на их свойства. И константные указатели (о которых ты говоришь) тут не могут являться адекватной заменой, но об этом чуть позже. Поэтому да, мой код показал именно то, о чём говорит Qraizer. Стоило мне сделать "уточнение" для компилятора, что значение указателя может поменяться за пределами области видимости - и усё, ему пришлось отложить свой оптимизатор в сторону. В отношении указателей. А вот написать эквивалентный код со ссылкой уже не выйдет. Именно по причине того, что сделать ссылку волатильной (то есть изменяемой за пределами контекста видимости и использования) - нельзя при всём желании.

                            Цитата applegame @
                            Ну и я сделал, тоже корректными средствами, без злобных кастов, ссылка перестала оптимизироваться.

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

                            Цитата applegame @
                            Компилятор внутри реализует ссылку как указатель, который может соптимизироваться, а может и нет.

                            Большая ошибка так считать. Мы с тобой уже в этой дискуссии набрали разных примеров того, как поступает компилятор со ссылками на разных уровнях оптимизации. Реализация "как указатель" - лишь одна из возможных, но не единственная. И не может быть единственная. Да и, с другой стороны, какая разница, что там думает себе компилятор в каждом конкретном случае? Речь по большей части о видимой (и стандартизованной) семантики этой сущности, а интерпретация конкретным компилятором - это детали реализации, тем более, что:
                            Цитата 8.3.2 References (dcl.ref)
                            4 It is unspecified whether or not a reference requires storage


                            Цитата applegame @
                            Ну и, все-таки, хотелось бы маленький, но конкретный пример. Типа вот тут проблема с pointer aliasing из-за указателя. Меняем его на ссылку и вуаля, проблема ушла.

                            Зачем тебе такой пример? Указатель не всегда можно заменить на ссылку и наоборот. Это разные сущности с разным поведением.

                            Цитата applegame @
                            Я все прочитал правильно. Речь шла не о просто временных объектах, а о ссылках на временные объекты возвращаемые из функции. Или ты издеваешься, или какое-то недопонимание между тобой и мной.

                            А, всё. Понял. :) Я слишком привык к опциям -Wall и -Werror, поэтому получаю ошибку компиляции там, где может быть dangling reference: https://wandbox.org/permlink/DfU2EEnvEbQYqm6U Ну да. Согласно стандарту такая программа не является ill-formed. Что несколько странно. :D

                            Цитата applegame @
                            Пикантности добавляет тот факт, что волатильный указатель сам по себе - достаточно бесполезная штука и в реальной жизни вряд ли встречается.

                            Угу. А потом на сцену выходит многопоточность и прочие забавные вещи. Впрочем, ты прав. Вместо волатильных указателей лучше использовать атомик-указатели. Ну, как минимум. :D

                            Цитата applegame @
                            Но ведь в случае константных указателей компилятор тоже будет уверен. Не так ли?

                            Не так. Константность указателя говорит лишь о том, что его значение не поменяется в области видимости константности. Но константность в рамках конкретного скоупа ничего не говорит о том, что указатель на самом деле не будет менять своё значение даже в рамках этого скоупа. Про ссылки такие допущения делать можно. Вот пример:

                            ExpandedWrap disabled
                              class RotationLog
                              {
                              public:
                                 //...
                                 void Trace(const std::string& message) const
                                 {
                                    (*m_os) << message << std::endl; // Тут указатель на m_os - константный.
                                 }
                                
                                 void Rotate()
                                 {
                                    // ...
                                    if (RotationCriteriaMet())
                                       m_curStream.reset(new std::ofstream(GetNewFileName()); // тут m_os - не константный
                                    // ...
                                 }
                              private:
                                 std::unique_ptr<std::ofstream> m_curStream;
                              };

                            Теперь представим себе, что Rotate крутится в отдельном потоке, а Trace - вызывается из множества других. Какие предположения может делать компилятор об неизменности константного указателя в методе Trace? Ровным счётом никаких кроме тех, что Trace значение указателя не изменит. Исправление этого кода - простое. Добавить мьютекс, указатель делать шареным и под мьютексом снимать его копию в методе Trace, а в Rotate под ним же ресеттить. К слову, поменять здесь указатель на ссылку - нельзя.

                            Добавлено
                            Цитата D_KEY @
                            Откуда ты это взял? Найди пруф на это.

                            Да, тут ты прав. А я - нет. :) Получается, что мой "тип1" - это фундаментальные типы и структуры, а "тип2" - это составные типы без структур. :)

                            Это сообщение было перенесено сюда или объединено из темы "D vs C++"
                            Сообщение отредактировано: Flex Ferrum -
                              Цитата Flex Ferrum @
                              авай я напомню тебе, что именно написал Qraizer:
                              Окай. Хорошо, согласен, я не совсем верно интерпретировал слова Qraizer'a. И прошу у него прощения за непреднамеренное искажение смысла.
                              Цитата Flex Ferrum @
                              Стоило мне сделать "уточнение" для компилятора, что значение указателя может поменяться за пределами области видимости - и усё, ему пришлось отложить свой оптимизатор в сторону. В отношении указателей. А вот написать эквивалентный код со ссылкой уже не выйдет. Именно по причине того, что сделать ссылку волатильной (то есть изменяемой за пределами контекста видимости и использования) - нельзя при всём желании.
                              А ты посмотри с другой стороны: волатильный указатель в принципе нельзя заменить ссылкой. Иначе его волатильность получается бессмысленой. То есть в данном случае заставить компилятор применить оптимизацию путем замены волатильного указателя ссылкой не получится, просто потому что такую замену сделать невозможно. Если же его волатильность липовая, до достаточно просто её убрать и оптимизация будет такая же как и с ссылкой. Ссылка в данном случае либо невозможна либо бесполезна.
                              Цитата Flex Ferrum @
                              Большая ошибка так считать. Мы с тобой уже в этой дискуссии набрали разных примеров того, как поступает компилятор со ссылками на разных уровнях оптимизации
                              Да, и выяснили, что в основном компилятор поступает с сылками также как и с указателями, за некоторыми исключениями вроде волатильности и изменения времени жизни объектов на которые эта ссылка указывает.
                              Цитата Flex Ferrum @
                              Да и, с другой стороны, какая разница, что там думает себе компилятор в каждом конкретном случае? Речь по большей части о видимой (и стандартизованной) семантики этой сущности, а интерпретация конкретным компилятором - это детали реализации, тем более, что:
                              С этим согласен.
                              Цитата Flex Ferrum @
                              Не так. Константность указателя говорит лишь о том, что его значение не поменяется в области видимости константности. Но константность в рамках конкретного скоупа ничего не говорит о том, что указатель на самом деле не будет менять своё значение даже в рамках этого скоупа. Про ссылки такие допущения делать можно.
                              Стоп, стоп, стоп. Мы говорим о константных указателях - членах класса. В их константности компилятор может быть уверен всегда. Нет? Кстати в D эта проблема решается дополнительным модификатором immutable. Этот модификатор гарантирует компилятору, что переменная не будет меняться нигде и никогда (в том числе и других потоках) пока не выйдет из всех областей видимости.
                              Цитата Flex Ferrum @
                              К слову, поменять здесь указатель на ссылку - нельзя.
                              В этом-то и прикол. Если указатель должен меняться, то его априори нельзя заменить на ссылку. А если же не должен, то можно, но никакого профита с точки зрения оптимизации это не даст. Опять мы приходим к тому, что замена указателя на ссылку не поможет компилятору применить оптимизации.

                              Это сообщение было перенесено сюда или объединено из темы "D vs C++"
                              Сообщение отредактировано: applegame -
                                Цитата applegame @
                                А ты посмотри с другой стороны: волатильный указатель в принципе нельзя заменить ссылкой. Иначе его волатильность получается бессмысленой. То есть в данном случае заставить компилятор применить оптимизацию путем замены волатильного указателя ссылкой не получится, просто потому что такую замену сделать невозможно. Если же его волатильность липовая, до достаточно просто её убрать и оптимизация будет такая же как и с ссылкой. Ссылка в данном случае либо невозможна либо бесполезна.

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

                                Цитата applegame @
                                Да, и выяснили, что в основном компилятор поступает с сылками также как и с указателями, за некоторыми исключениями вроде волатильности и изменения времени жизни объектов на которые эта ссылка указывает.

                                Только это не исключения. А если добавить в рассматриваемый контекст ещё и правые ссылки, то совсем не исключения. Механизм правых ссылок на указателях вообще реализовать нельзя. Как и некоторые свойства левых ссылок. Что ещё раз говорит, что это не эквивалентные сущности.

                                Цитата applegame @
                                Мы говорим о константных указателях - членах класса. В их константности компилятор может быть уверен всегда. Нет?

                                Строго говоря - нет. Потому что есть const_cast, который к ссылкам (при всём желании) не применим. А за счёт неопределённости (в стандарте) на счёт того, занимают ссылки какое-то место или нет, ты даже с помощью грязных хаков сможешь поменять значения только тех ссылок, в которых ты точно уверен, что это засахаренные указатели.

                                Цитата applegame @
                                Опять мы приходим к тому, что замена указателя на ссылку не поможет компилятору применить оптимизации.

                                В такой формулировке - да. Только вот начальный тезис был чуть другой: ссылки позволяют компилятору более агрессивно оптимизировать за счёт прибитой гвоздями иммутабельности и некоторых других свойств, которых у указателей нет. Только из этого тезиса не следует, что одно можно заменить другим. :)

                                Сообщения были разделены в тему "Баллада о ссылках в С++"

                                Это сообщение было перенесено сюда или объединено из темы "D vs C++"
                                Сообщение отредактировано: Flex Ferrum -
                                0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (11) « Первая ... 8 9 [10] 11  все


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,0783 ]   [ 16 queries used ]   [ Generated: 28.03.24, 12:13 GMT ]