На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
! Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
Страницы: (245) « Первая ... 236 237 [238] 239 240 ...  244 245  ( Перейти к последнему сообщению )  
> Есть ли будущее у DELPHI?
    Цитата leo @
    В си конструкция for отличается от общего вида do\while лишь синтаксисом

    Это не значит, что Сишные компиляторы не умеют оптимизировать for.

    Цитата leo @
    Аглицкая вики в отношении Loop variable scope and semantics не делит языки и компиляторы на "нормальные" и не очень, а лишь подчеркивает, что реализации\правила м.б. different, в т.ч. и c "becomes undefined", и объясняет преимущества таких ограничений в плане оптимизации выполнения цикла.

    Еще раз: в нормальных языках программист может выбирать, каким будет for. В Делфи этого выбора нет.
      leo, что мрешает компилятору самому распознать случай, подходящий для этого вида оптимизаций?
        Цитата korvin @
        Это не значит, что Сишные компиляторы не умеют оптимизировать for.

        Дело не в том, кто что умеет, а в том, что в дельфи цикл for имеет ряд принципиальных ограничений по сравнению с циклами общего вида.

        Цитата korvin @
        Еще раз: в нормальных языках программист может выбирать, каким будет for. В Делфи этого выбора нет.

        Его и не может быть, т.к. в паскале нет ограничения видимости переменных на уровне блока - только на уровне процедуры\функции. Поэтому вместо "выбора", м.б. только исключения из правил, к которым и относится счетчик цикла for.

        Цитата D_KEY @
        что мрешает компилятору самому распознать случай, подходящий для этого вида оптимизаций?

        Эти оптимизации и ограничения тянутся с "незапамятных времен". Поэтому и "поблажки" вводятся, но "с другой стороны". Я же приводил пример, что в случае использования значения счетчика после цикла, компилер "по традиции" выдает варнинг, но все же сохраняет верное значение счетчика в ущерб изначально заложенной оптимизации.

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

        Добавлено
        Цитата korvin @
        Цитата D_KEY @
        korvin, не твой случай?

        Да, видимо мой.

        Нет, не твой. В том случае создается и хранится ссылка на объект, у которого RefCount=0. А ты хранишь ссылки на интерфейсы, у которых в момент присваивания становится RefCount=1. При передаче ссылки в Build(..) в качестве параметра (без модификатора const или var), должен происходить инкремент счетчика ссылок до RefCount=2, а при нормальном выходе из процедуры соотв-но декремент до RefCount=1. Если у тебя где-то проскакивает лишний декремент, то либо процедура Build написана криво, либо ты тут "примерно" вообще не тот код приводишь (несуществующий тип InterfacedObject без префикса T, вызовы несуществующих методов IWriter.Free, ненужные для интерфейсов override - "а какой компилятор смог это переварить?" спрашивает недоумевающий Shaggy)
        Сообщение отредактировано: leo -
          Цитата Qraizer @
          Ты не прав. Это бред. Создавать объект со счётчиком равным 0? Не, Дельфи не убивали, он убился сам свои весом.

          Бред - это пытаться как мартышка примерять очки, не зная что это, и как их использовать.
          Счетчик ссылок нужен для автоудаления объекта, реализующего интерфейс, когда удаляется\релизится последняя ссылка на этот интерфейс. Это ваш "горячо любимый" контракт поведения майкрософтовского IUnknown, реализованный в TInterfacedObject. Вот и подумай(те) будет ли работать эта контрактная фича, если объект, не имея ни одной ссылки, будет иметь счетчик не равный 0? Вот уж бред, так бред
          PS: Нужно быть разборчивее в половых связях и думать, от кого хочешь поиметь наследника :D
            leo, подсчет ссылок есть и в других языках/библиотеках/инструментах. Но таких косяков там почему-то нет.
              Цитата leo @
              Счетчик ссылок нужен для автоудаления объекта, реализующего интерфейс, когда удаляется\релизится последняя ссылка на этот интерфейс. Это ваш "горячо любимый" контракт поведения майкрософтовского IUnknown, реализованный в TInterfacedObject. Вот и подумай(те) будет ли работать эта контрактная фича, если объект, не имея ни одной ссылки, будет иметь счетчик не равный 0? Вот уж бред, так бред

              Вот и расскажи, почему у созданного объекта счетчик ссылок равен нулю? Т.е. объект как бы существует, как бы ссылка на него есть, но количество этих ссылок почему-то нулевое.
                Цитата korvin @
                Вот и расскажи, почему у созданного объекта счетчик ссылок равен нулю? Т.е. объект как бы существует, как бы ссылка на него есть, но количество этих ссылок почему-то нулевое.

                подсчёт количества этих ссылок не ведётся.
                  Цитата Shaggy @
                  Цитата korvin @
                  Вот и расскажи, почему у созданного объекта счетчик ссылок равен нулю? Т.е. объект как бы существует, как бы ссылка на него есть, но количество этих ссылок почему-то нулевое.

                  подсчёт количества этих ссылок не ведётся.

                  Почему?

                  Добавлено
                  В смысле не очень понятно, как тогда всем этим пользоваться и не спотыкаться.

                  Добавлено
                  Вот в C++ для shared_ptr(который реализует подсчет ссылок) есть специальный механизм невладеющего указателя - weak_ptr. Т.е. объект может быть удален, но в этом случае weak_ptr вернет nullptr при попытки завладеть объектом и все можно сделать безопасно. Да, конечно, никто не мешает руками использовать скрытый под капотом сырой указатель, но это нужно делать явно...
                    Цитата D_KEY @
                    Почему?

                    ExpandedWrap disabled
                      void sample(){
                      int *x = new int(42);}

                    утечка будет? почему?
                      Цитата Shaggy @
                      Цитата D_KEY @
                      Почему?

                      ExpandedWrap disabled
                        void sample(){
                        int *x = new int(42);}

                      утечка будет? почему?

                      Потому, что ручное управление памятью. А мы про подсчет ссылок(т.е. полуавтоматическое управление памятью).
                      Тут не будет
                      ExpandedWrap disabled
                        void sample() {
                            auto x = make_shared<int>(42);
                        }
                        Цитата D_KEY @
                        Потому, что ручное управление памятью. А мы про подсчет ссылок(т.е. полуавтоматическое управление памятью).
                        Тут не будет

                        спасибо кэп!

                        хочешь ручное, используй объектные ссылки(счётчик использоваться не будет)
                        хочешь автоматическое, используй интерфейсные ссылки

                        у korvin, если убрать очевидные ляпы(leo их описал), всё заработает

                        поведение, которое он описывает, будет при
                        ExpandedWrap disabled
                              FTxtWriter: TWriter;
                              FXmlWriter: TWriter;

                        т.е. он смешивает оба подхода(что само по себе не проблема, проблема в том, что он не понимает того что делает)
                        Сообщение отредактировано: Shaggy -
                          Цитата Shaggy @
                          хочешь автоматическое, используй интерфейсные ссылки

                          Это понятно. Но это идиотизм какой-то. Мы же имеем обычные объекты, почему поведение, связанное с управлением памятью, зависит от того, к какому уровню иерархии статически относится используемая мною ссылка? А если мне нужен именно объект моего класса держать, а не интерфейс? Я определил дополнительные операции какие-то, что мне нужны, но при этом хочу передавать свой объект туда, где ожидают интерфейс. Как мне действовать?

                          ExpandedWrap disabled
                            struct IA {
                                virtual void foo() = 0;
                            };
                             
                             
                            void f(std::shared_ptr<IA> a)
                            {
                                a->foo();
                                // ...
                            }
                             
                            struct B : IA {
                                void foo() override
                                {
                                    //...
                                }
                                void bar()
                                {
                                    // ...
                                }
                            };
                             
                            void g(std::shared_ptr<B> b)
                            {
                                b->bar();
                                f(b);
                            }
                             
                            int main()
                            {
                                g(std::make_shared<B>());
                            }
                          Сообщение отредактировано: D_KEY -
                            Цитата D_KEY @
                            Как мне действовать?

                            реализовать AddRef и Release так:
                            ExpandedWrap disabled
                              function ....AddRef:Integer;
                              begin
                                Result:=MAXINT;
                              end;
                              Цитата Shaggy @
                              Цитата D_KEY @
                              Как мне действовать?

                              реализовать AddRef и Release так:
                              ExpandedWrap disabled
                                function ....AddRef:Integer;
                                begin
                                  Result:=MAXINT;
                                end;

                              Эм. А разве я тогда получу корректный подсчет ссылок?
                                leo, для чего нужен подсчёт ссылок, я как бы знаю.
                                Цитата leo @
                                Вот и подумай(те) будет ли работать эта контрактная фича, если объект, не имея ни одной ссылки, будет иметь счетчик не равный 0?
                                И как бы знаю, что конструируемый объект имеет ссылку, поэтому его счётчик нулевым не может быть по определению.
                                Сообщение отредактировано: Qraizer -
                                1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
                                0 пользователей:
                                Страницы: (245) « Первая ... 236 237 [238] 239 240 ...  244 245


                                Рейтинг@Mail.ru
                                [ Script execution time: 0,1943 ]   [ 14 queries used ]   [ Generated: 18.07.25, 17:07 GMT ]