Вопросы по Delphi (36 стр)

g-cont
> Посмотрел я тут синтаксис XAML, он же WPF. Ну вот почему dfm годится для
> редактирования в блокноте, а эти языки с тэгами как будто нарочно делают, чтобы
> затруднить редактирование вне нативной IDE.
Ну так ты возьми блокнот поддерживающий xml. Вообще их редактриовать вне иде не имеет смысла особо. Да и у WPF побольше возможностей, чем у дельфи.

skalogryz
> запрещать его присваивание?
Добавить мув семантику как в плюсах или передачу овнершипа как в расте?

MrShoor
> Добавить мув семантику как в плюсах или передачу овнершипа как в расте?
Понятно.
Перенимать новые подходы, вопрос только в том какие именно.

skalogryz
> Понятно.
> Перенимать новые подходы, вопрос только в том какие именно.
Ну самый простой:

var
obj1: TMyObject local;
obj2: TMyObject local;
obj3: TMyObject;
begin
  obj1 := TMyObject.Create;
  obj2 := obj1; //здесь происходит перемещение указателя в obj2
                //obj1 при этом становится равен nil
  obj3 := obj2; //а здесь obj2 по прежнему указывает на объект
                //и obj3 тоже указывает на этот же объект  
end; //здесь obj2 будет освобожден

это слишком опасно, как и поинтеры на строки. (и по-этому их никто не использует)

потому что obj3 присвоится в тихушку; (без предупреждений компилятора).
и куда потом obj3 уйдёт, или obj3 сам будет освобождён - неизвестно и компилятор за этим не проследит.

оке... а в Расте точно так же можно на грабли наступить?

skalogryz
> и куда потом obj3 уйдёт, или obj3 сам будет освобождён - неизвестно и
> компилятор за этим не проследит.
obj2/obj3 хоть так хоть так - надо будет освобождать. И когда ты освободишь один из указателей - второй автоматически начинает указывать в чужую память. Даже без всяких local.
Или по твоему работа с просто указателями - безопасна, а вот с local становится опаснее?

> оке... а в Расте точно так же можно на грабли наступить?
Нельзя наступить если не используешь unsafe

MrShoor
> Нельзя наступить если не используешь unsafe

"Нельзя наступить" это победа пропагандонов раста.
Пишешь виртуальную машину с аналогом malloc и free, вызываешь malloc, забываешь free.
Нужно отдать должное - реклама поставлена на уровне.
Аналогично врут про C#/java и прочие.

Отдельная претензия к любителям использовать RAII для управления памятью: постоянно позорным образом умалчивают что освобождать каждую маленькую фигню менее эффективно чем использовать арену и грохать все сразу.

CD
> Пишешь виртуальную машину с аналогом malloc и free, вызываешь malloc, забываешь free
Звучит, как в анекдоте - "а вы на шкаф залезьте"

Aslan

Есть такая шутка:
https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

А как известно в любой шутке есть только доля шутки.

CD
Ну незнаю, писали бы тогда сразу на Лиспе xD

CD
> Пишешь виртуальную машину с аналогом malloc и free, вызываешь malloc, забываешь
> free.
Я же специально написал: "если не используешь unsafe". И ты даже это предложение и процитировал. Твои malloc и free - это unsafe код. Для unsafe пишется safe обертка, где в конструкторе вызывается malloc, в деструкторе free. Всё, пользуешься только safe оберткой, и ничего не течет.

> Отдельная претензия к любителям использовать RAII для управления памятью:
> постоянно позорным образом умалчивают что освобождать каждую маленькую фигню
> менее эффективно чем использовать арену и грохать все сразу.
Ну а это вообще глупость. Если ты насоздавал мелких объектов, то уже нет никакой разницы как ты их грохать будешь, сразу на месте или потом. Тебе всё равно либо придется их грохать по одному, либо грохать всё приложение, и ОС за тебя погрохает ресурсы, который ты выделял себе.

MrShoor
> Или по твоему работа с просто указателями - безопасна, а вот с local становится опаснее?
вопрос в ответственности.
за освобождение managed типов отвечает компилятор.

и чтобы managed тип, навредить управлению этими типами, то нужно сделать какую-нить явную дичь с приведением типов.
Во всех остальных случаях компилятор вполне себе разруливает операции с типами.

объявляю переменную как local, ты по сути говоришь компилятору - теперь это managed. Но при этом повредить код очень легко.

там даже статистический анализатор не разберёт.

MrShoor
> И когда ты освободишь один из указателей - второй автоматически начинает
> указывать в чужую память. Даже без всяких local.
именно так. Но т.к. компилятор этими переменными не управляет ответственность полностью на мне.
а так я могу начать причиать: "да почему компилятор такой тупой, если я у него переменную забрал"

skalogryz
> вопрос в ответственности.
> за освобождение managed типов отвечает компилятор.
Ну в данном случае local будет как std::unique_ptr в плюсах, а не local - как сырой указатель в тех же плюсах.

> и чтобы managed тип, навредить управлению этими типами, то нужно сделать
> какую-нить явную дичь с приведением типов.
На интерфейсах вполне себе делаются циклические ссылки.

> Но при этом повредить код очень легко.
Почему легко то? Не присваивай её в обычный указатель и всё. Зато никакого оверхеда на счетчик ссылок.

> Но т.к. компилятор этими переменными не управляет ответственность полностью на
> мне.
Ну да:

var
obj1: TMyObject local;
obj2: TMyObject;
begin
  obj1 := TMyObject.Create;
  obj2 := obj1; //все, ответственность полностью на тебе
                //в obj2 может оказаться мусор, когда obj1 выйдет из области видимости
end;

MrShoor
> Не присваивай её в обычный указатель и всё
а если я её в функцию передам?

skalogryz
> а если я её в функцию передам?
кого? local?
если функция:

procedure Foo(obj: TMyObject local);
begin
end;//тут obj будет освобожден, если он не nil

То вот:

var
obj1: TMyObject local;
obj2: TMyObject;
begin
  obj1 := TMyObject.Create;
  Foo(obj1); //в функцию уходит указатель, а в obj1 остается nil             
end;

Ну то есть я предлагаю для local сделать поведение как в Rust