
![]() |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[216.73.216.30] |
![]() |
|
Страницы: (245) « Первая ... 236 237 [238] 239 240 ... 244 245 ( Перейти к последнему сообщению ) |
![]() |
Сообщ.
#3556
,
|
|
Это не значит, что Сишные компиляторы не умеют оптимизировать for. Цитата leo @ Аглицкая вики в отношении Loop variable scope and semantics не делит языки и компиляторы на "нормальные" и не очень, а лишь подчеркивает, что реализации\правила м.б. different, в т.ч. и c "becomes undefined", и объясняет преимущества таких ограничений в плане оптимизации выполнения цикла. Еще раз: в нормальных языках программист может выбирать, каким будет for. В Делфи этого выбора нет. |
Сообщ.
#3557
,
|
|
|
leo, что мрешает компилятору самому распознать случай, подходящий для этого вида оптимизаций?
|
Сообщ.
#3558
,
|
|
|
Цитата korvin @ Это не значит, что Сишные компиляторы не умеют оптимизировать for. Дело не в том, кто что умеет, а в том, что в дельфи цикл for имеет ряд принципиальных ограничений по сравнению с циклами общего вида. Цитата korvin @ Еще раз: в нормальных языках программист может выбирать, каким будет for. В Делфи этого выбора нет. Его и не может быть, т.к. в паскале нет ограничения видимости переменных на уровне блока - только на уровне процедуры\функции. Поэтому вместо "выбора", м.б. только исключения из правил, к которым и относится счетчик цикла for. Цитата D_KEY @ что мрешает компилятору самому распознать случай, подходящий для этого вида оптимизаций? Эти оптимизации и ограничения тянутся с "незапамятных времен". Поэтому и "поблажки" вводятся, но "с другой стороны". Я же приводил пример, что в случае использования значения счетчика после цикла, компилер "по традиции" выдает варнинг, но все же сохраняет верное значение счетчика в ущерб изначально заложенной оптимизации. PS: Все это действительно из области холивара, поскольку дельфистов ничуть не напрягает написать лишнюю строчку кода для сохранения значения счетчика при досрочном выходе из цикла. А для сишников, привыкших с незапамятных времен экономить на всем вплоть до бестолковых сокращений и обозначений, - это конечно, смерти подобно Добавлено Нет, не твой. В том случае создается и хранится ссылка на объект, у которого RefCount=0. А ты хранишь ссылки на интерфейсы, у которых в момент присваивания становится RefCount=1. При передаче ссылки в Build(..) в качестве параметра (без модификатора const или var), должен происходить инкремент счетчика ссылок до RefCount=2, а при нормальном выходе из процедуры соотв-но декремент до RefCount=1. Если у тебя где-то проскакивает лишний декремент, то либо процедура Build написана криво, либо ты тут "примерно" вообще не тот код приводишь (несуществующий тип InterfacedObject без префикса T, вызовы несуществующих методов IWriter.Free, ненужные для интерфейсов override - "а какой компилятор смог это переварить?" спрашивает недоумевающий Shaggy) |
Сообщ.
#3559
,
|
|
|
Цитата Qraizer @ Ты не прав. Это бред. Создавать объект со счётчиком равным 0? Не, Дельфи не убивали, он убился сам свои весом. Бред - это пытаться как мартышка примерять очки, не зная что это, и как их использовать. Счетчик ссылок нужен для автоудаления объекта, реализующего интерфейс, когда удаляется\релизится последняя ссылка на этот интерфейс. Это ваш "горячо любимый" контракт поведения майкрософтовского IUnknown, реализованный в TInterfacedObject. Вот и подумай(те) будет ли работать эта контрактная фича, если объект, не имея ни одной ссылки, будет иметь счетчик не равный 0? Вот уж бред, так бред PS: Нужно быть разборчивее в половых связях и думать, от кого хочешь поиметь наследника ![]() |
Сообщ.
#3560
,
|
|
|
leo, подсчет ссылок есть и в других языках/библиотеках/инструментах. Но таких косяков там почему-то нет.
|
![]() |
Сообщ.
#3561
,
|
|
Цитата leo @ Счетчик ссылок нужен для автоудаления объекта, реализующего интерфейс, когда удаляется\релизится последняя ссылка на этот интерфейс. Это ваш "горячо любимый" контракт поведения майкрософтовского IUnknown, реализованный в TInterfacedObject. Вот и подумай(те) будет ли работать эта контрактная фича, если объект, не имея ни одной ссылки, будет иметь счетчик не равный 0? Вот уж бред, так бред Вот и расскажи, почему у созданного объекта счетчик ссылок равен нулю? Т.е. объект как бы существует, как бы ссылка на него есть, но количество этих ссылок почему-то нулевое. |
![]() |
Сообщ.
#3562
,
|
|
Цитата korvin @ Вот и расскажи, почему у созданного объекта счетчик ссылок равен нулю? Т.е. объект как бы существует, как бы ссылка на него есть, но количество этих ссылок почему-то нулевое. подсчёт количества этих ссылок не ведётся. |
Сообщ.
#3563
,
|
|
|
Цитата Shaggy @ Цитата korvin @ Вот и расскажи, почему у созданного объекта счетчик ссылок равен нулю? Т.е. объект как бы существует, как бы ссылка на него есть, но количество этих ссылок почему-то нулевое. подсчёт количества этих ссылок не ведётся. Почему? Добавлено В смысле не очень понятно, как тогда всем этим пользоваться и не спотыкаться. Добавлено Вот в C++ для shared_ptr(который реализует подсчет ссылок) есть специальный механизм невладеющего указателя - weak_ptr. Т.е. объект может быть удален, но в этом случае weak_ptr вернет nullptr при попытки завладеть объектом и все можно сделать безопасно. Да, конечно, никто не мешает руками использовать скрытый под капотом сырой указатель, но это нужно делать явно... |
![]() |
Сообщ.
#3564
,
|
|
Цитата D_KEY @ Почему? ![]() ![]() void sample(){ int *x = new int(42);} утечка будет? почему? |
Сообщ.
#3565
,
|
|
|
Цитата Shaggy @ Цитата D_KEY @ Почему? ![]() ![]() void sample(){ int *x = new int(42);} утечка будет? почему? Потому, что ручное управление памятью. А мы про подсчет ссылок(т.е. полуавтоматическое управление памятью). Тут не будет ![]() ![]() void sample() { auto x = make_shared<int>(42); } |
![]() |
Сообщ.
#3566
,
|
|
Цитата D_KEY @ Потому, что ручное управление памятью. А мы про подсчет ссылок(т.е. полуавтоматическое управление памятью). Тут не будет спасибо кэп! хочешь ручное, используй объектные ссылки(счётчик использоваться не будет) хочешь автоматическое, используй интерфейсные ссылки у korvin, если убрать очевидные ляпы(leo их описал), всё заработает поведение, которое он описывает, будет при ![]() ![]() FTxtWriter: TWriter; FXmlWriter: TWriter; т.е. он смешивает оба подхода(что само по себе не проблема, проблема в том, что он не понимает того что делает) |
Сообщ.
#3567
,
|
|
|
Цитата Shaggy @ хочешь автоматическое, используй интерфейсные ссылки Это понятно. Но это идиотизм какой-то. Мы же имеем обычные объекты, почему поведение, связанное с управлением памятью, зависит от того, к какому уровню иерархии статически относится используемая мною ссылка? А если мне нужен именно объект моего класса держать, а не интерфейс? Я определил дополнительные операции какие-то, что мне нужны, но при этом хочу передавать свой объект туда, где ожидают интерфейс. Как мне действовать? ![]() ![]() 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>()); } |
![]() |
Сообщ.
#3568
,
|
|
Цитата D_KEY @ Как мне действовать? реализовать AddRef и Release так: ![]() ![]() function ....AddRef:Integer; begin Result:=MAXINT; end; |
Сообщ.
#3569
,
|
|
|
Цитата Shaggy @ Цитата D_KEY @ Как мне действовать? реализовать AddRef и Release так: ![]() ![]() function ....AddRef:Integer; begin Result:=MAXINT; end; Эм. А разве я тогда получу корректный подсчет ссылок? |
![]() |
Сообщ.
#3570
,
|
|
leo, для чего нужен подсчёт ссылок, я как бы знаю.
Цитата leo @ И как бы знаю, что конструируемый объект имеет ссылку, поэтому его счётчик нулевым не может быть по определению. Вот и подумай(те) будет ли работать эта контрактная фича, если объект, не имея ни одной ссылки, будет иметь счетчик не равный 0? |