RadStudio XE4. Дожили...

← →
DVM © (2013-05-07 15:56) [80]

> Дмитрий С © (07.05.13 15:14) [79]

> Он с трудом до уровня delphi 5 дотягивает.

Смотря в чем. Дженерики там есть, юникод есть, компилит под все платформы даже с GUI. Многие другие вещи которые появились не так давно тоже поддерживает, например inline и т.д. Но во многом сильно отличается от Delphi.

← →
Дмитрий С © (2013-05-07 16:36) [81]

С этим согласен, но среда разработки (лазарус) слабая.
Многие модули очень слабые, например http server.
Много внезапных багов. Например, TStringList.Write в середину стрима обрежет его.

← →
Дмитрий С © (2013-05-07 17:14) [82]

А еще такой вопрос о будущих объектах:
В таком коде:
var I: TSomeObject; begin I := TSomeObject.Create; I.SomeMethod(); // <-- Строка 5 ... // Тут код, который не использует, либо переопределяет I. end;
Неужели компилятор не сможет догадаться, что после строки 5 можно уже освободить объект?

← →
Rouse_ © (2013-05-07 20:00) [83]

> Неужели компилятор не сможет догадаться, что после строки
> 5 можно уже освободить объект?

Если используется подсчет ссылок, то ему и не нужно ни о чем догадываться. На декременте рефов вызовется деструктор и всего делов. Один в один с интерфейсами-ж будет.

← →
Дмитрий С © (2013-05-08 19:40) [84]

> Rouse_ © (07.05.13 20:00) [83]

Теоретически экономнее к памяти.

← →
Rouse_ © (2013-05-08 22:58) [85]

> Дмитрий С © (08.05.13 19:40) [84]
> Теоретически экономнее к памяти.

Врятли, ибо это приведет не к экономии, а к ее фрагментации, что на порядок хуже.

← →
Eraser © (2013-05-09 01:18) [86]

> Rouse_ © (07.05.13 20:00) [83]

> Один в один с интерфейсами-ж будет.

кстати да, в принципе, ARC они могли повсеместно внедрить еще в далеком 1999.

← →
TUser © (2013-05-09 01:29) [87]

Дмитрий С © (07.05.13 04:59) [74]

Я вот думаю, новый проект никакой на Delphi не начну. Python или Java, скорее всего. И FAR )) для отладки - какой-нибудь эклипс. Потому что миллион леммингов не ошибается, имхо. И этот миллион леммингов создал больше, чем все замечательные программисты на Delphi, хоть он и крут.

Это действительно крутая штука, этот Delphi, но, увы, мертвая из-за многочисленных ошибок менеджмента.

← →
Плохиш © (2013-05-09 22:44) [88]

> Неужели компилятор не сможет догадаться, что после строки
> 5 можно уже освободить объект?

Какое отношение имеет компилятор к сборщику мусора?
Ознакомились бы сначала с предметом, который берëтесь обсуждать.

← →
NoUser © (2013-05-10 00:27) [89]

Хм, посмотрел свежий Lazarus/fpc2.6.2 - очень позитивные впечатления(!), если что (with c pointer"ом забанят) - буду съезжать :)

> DVM © (07.05.13 15:56) [80]
> Но во многом сильно отличается от Delphi.

Сильно отличаются IDE ? , или и синтаксис - с {$mode delphi} дженерики, вроде, один в один.

> TUser © (09.05.13 01:29) [87]
> Я вот думаю, новый проект никакой на Delphi не начну. Python
> или Java, скорее всего

Вы это серьезно?

← →
Дмитрий С © (2013-05-10 02:07) [90]

> Какое отношение имеет компилятор к сборщику мусора?
> Ознакомились бы сначала с предметом, который берëтесь обсуждать.

1. В Delphi нет сборщика мусора, "Ознакомились бы сначала с предметом, который берëтесь обсуждать".
2. Именно компилятор решает когда нужно освобождать переменную, требующую освобождения. Сейчас это делается при выходе из процедуры или функции.

← →
Дмитрий С © (2013-05-10 02:22) [91]

Точнее, конечно, не освобождать, а финализировать.

← →
Германн © (2013-05-10 03:01) [92]

> Дмитрий С © (10.05.13 02:07) [90]
>
>
> > Какое отношение имеет компилятор к сборщику мусора?
> > Ознакомились бы сначала с предметом, который берëтесь
> обсуждать.
>
> 1. В Delphi нет сборщика мусора, "Ознакомились бы сначала
> с предметом, который берëтесь обсуждать".
> 2. Именно компилятор решает когда нужно освобождать переменную,
> требующую освобождения. Сейчас это делается при выходе
> из процедуры или функции.
>

???

Бред. Сборщик мусора работает в ран-тайм, когда компилятор давно уже спит мёртвым сном. Компилятор физически не может определить, когда "нужно освобождать переменную"! Ибо он не может сам найти все ссылки на неё, которые будут созданы в рантайм.
Но вроде в XE4 и далее сборщик мусора будет реализован.

← →
Игорь Шевченко © (2013-05-10 09:59) [93]

> Неужели компилятор не сможет догадаться, что после строки
> 5 можно уже освободить объект?

Не дай бог, если компилятор начнет догадываться о намерениях всех быдлокодеров

← →
Дмитрий С © (2013-05-10 12:50) [94]

> Не дай бог, если компилятор начнет догадываться о намерениях
> всех быдлокодеров

Он же выполняет оптимизацию. И ничего! Никто не умер еще.

> Бред. Сборщик мусора работает в ран-тайм, когда компилятор
> давно уже спит мёртвым сном. Компилятор физически не может
> определить, когда "нужно освобождать переменную"! Ибо он
> не может сам найти все ссылки на неё, которые будут созданы
> в рантайм.

А никто и не спорит, компилятор ничего не ищет. Но именно компилятор решает где будет находится I._Release, FinalizeRecord или типа того, в зависимости от типа, это и есть финализация. Именно он может решить выполнить финализацию в конце процедуры или сразу после последнего использования переменной в процедуре.
Про сборщик мусора в delphi это уже другой разговор. Мне не понятно зачем он нужен delphi в прямом его смысле.

← →
NoUser © (2013-05-10 13:51) [95]

А у кого-то есть логичное обоснование того, почему динамические переменные класса автоматически финализируются еще до деструктора класса?

TTest = class class var sa: array of String; class constructor Init; class destructor Done; end; class constructor TTest.Init; begin SetLength(sa,1); sa[0]:="Test" ; end; class destructor TTest.Done; begin Finalize(sa[0]); // AV - sa уже растаял. Finalize(sa); end;

← →
Kilkennycat © (2013-05-10 16:07) [96]

> NoUser © (10.05.13 13:51) [95]

оптимизатор не увидел использование

← →
Kilkennycat © (2013-05-10 16:12) [97]

и вообще, разве можно так уничтожать элемент массива? мне почему-то кажется, что это приведет к разрушению массива.

← →
DVM © (2013-05-10 17:27) [98]

Нет в Delphi сборщика мусора (такого как в .Net например) и не будет в ближайшем времени. Подсчет ссылок и автоматическое разрушение объектов при достижении счетчиком нужного значения - это далеко не сборщик мусора.

Разумеется оптимизатор может обнаруживать места, где переменная указывающая на объект еще не вышла из области видимости, но далее уже очевидно не будет использована, но это потребует вероятно нескольких проходов и снизит скорость компиляции.

← →
Kilkennycat © (2013-05-10 17:38) [99]

> потребует вероятно нескольких проходов и снизит скорость
> компиляции.

большинство компиляторов для мк содержат такую возможность настройки: изменение числа проходов ради скорости компиляции или качества оптимизации.

← →
DVM © (2013-05-10 17:43) [100]

> NoUser © (10.05.13 00:27) [89]

>
> Сильно отличаются IDE ? , или и синтаксис - с {$mode delphi}
> дженерики, вроде, один в один.
>

Дженерики сильно отличаются, например они не наследуются. Да и сами библиотеки дженериков совсем разные. Нету многих стандартных классов и типов, TEncoding например, и добавить их туда весьма сложно. Indy работает через пень колоду.

← →
DVM © (2013-05-10 17:52) [101]

> Kilkennycat © (10.05.13 17:38) [99]

> большинство компиляторов для мк

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

← →
Kilkennycat © (2013-05-10 18:12) [102]

> мк - это микроконтроллеры что ли?

ага

← →
NoUser © (2013-05-10 23:56) [103]

> DVM © (10.05.13 17:43) [100]
Ясно, спасибо.
Ну я стандартными либами особо не пользуюсь, да и сеть своя.
Посмотрел, что интересовало, - собралось, запустилось - доволен.
А вот раньше смотрел, до XE2, с прицелом на х64, - не особо.
Да, и к Unicode GUI уже привык.

> Kilkennycat © (10.05.13 16:07) [96]
> оптимизатор не увидел использование

Да нет, такое поведение и в справке описано, но вот почему так, ведь не очень то логично?

Порадовался за class constructor/destructor, вот думаю, initialization/finalization можно и убрать, -
а там такую свинку подложили, пришлось выкрутится через указатель на динамическую переменную и вспомнить про New/Dispose

Кстати, как там в XE4, initialization/finalization и New/Dispose также deprecated или еще живы?

> и вообще, разве можно так уничтожать элемент массива? мне
> почему-то кажется, что это приведет к разрушению массива.

А как можно, вроде нормальная практика?

← →
Kilkennycat © (2013-05-11 00:03) [104]

>
> А как можно, вроде нормальная практика?

нормальная практика, как мне казалось, финализировать объект, содержащийся в элементе массива.

← →
Дмитрий С © (2013-05-11 01:16) [105]

> А как можно, вроде нормальная практика?

Вручную элементы массива нельзя финализировать в общем случае. Они финализируются сами при финализации или при обрезе массива.

← →
NoUser © (2013-05-11 16:02) [106]

> нормальная практика, как мне казалось, финализировать объект,
> содержащийся в элементе массива.

Ну вот, в элементе массива, в данном случаи - sa[0], и содержится объект, в данном случаи - String.

> Дмитрий С © (11.05.13 01:16) [105]
> Вручную элементы массива нельзя финализировать в общем случае.
> Они финализируются сами при финализации или при обрезе
> массива.

В общем случае, содержимое элементов динамического массива нужно финализировать вручную.
В случаи со следующими типами содержимого массива
tkLString tkWString tkUString tkVariant tkArray tkRecord tkInterface tkDynArray
финализация будет выполнена под капотом.

В приведенном примере ручная финализация избыточна (сплю я так спокойнее) , но не нельзяшная.

----------------------------
Перефразирую свой вопрос:

Какова причина/необходимость автоматически выполняемой финализации классовых переменных до вызова классового деструктора, если такой имеется ?

TTest = class class var Sa: array of String; class constructor Init; class destructor Done; end; class constructor TTest.Init; begin SetLength(Sa,123); end; class destructor TTest.Done; begin if ( Length(Sa) = 0 ) then ??? end;

← →
Дмитрий С © (2013-05-11 19:13) [107]

> В приведенном примере ручная финализация избыточна (сплю
> я так спокойнее) , но не нельзяшная.

Нельзяшная, т.к. в итоге ты получишь двойную финализацию, а это AV.

← →
NoUser © (2013-05-11 23:11) [108]

> Нельзяшная, т.к. в итоге ты получишь двойную финализацию,
> а это AV.

Ага.
function AvTest:String; var i : Integer; id: TGUID; s : String; begin CreateGUID(id); s:=GUIDToString(id); try for i := 1 to 100500 do Finalize(s); s := "Хух, пронесло!" except s := "Ай, ну больно же, больше так не буду."; end; Result:=s; end;

← →
jack128_ (2013-05-11 23:43) [109]

> Нельзяшная, т.к. в итоге ты получишь двойную финализацию,
> а это AV.

двойная файнализация - это никогда не AV.

А в BC++ x64 уже строки иммутабельны? Он же на LLVM вроде как...

Кстати, на XE4 что 32 что 64 бит прекрасно собирается
program ConsoleTest; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; var s: AnsiString; begin try SetLength(s, 4); s[2] := "Я"; Writeln(s); Readln; except on E: Exception do Writeln(E.ClassName, ": ", E.Message); end; end.

Да, кстати, буква "Я" там - второй символ.

> Cobalt © (13.05.13 11:22) [111]
> Кстати, на XE4 что 32 что 64 бит прекрасно собирается

Так оно и должно. А вот если так:
{$ZEROBASEDSTRINGS ON}

Я проверял на Win-платформе.
Если понадобится писать под IOS или MAC, то полюбому придется много чего переписывать (ассемблерные вставки, защита эл. ключом, обращение к портам, работу с сокетами)

← →
jack128_ (2013-05-13 15:37) [116]

> А в BC++ x64 уже строки иммутабельны? Он же на LLVM вроде
> как...

маловероятно. По стандарту С++ - std::basic_string - мутабельная. Про иммутабельность строк - это заморочки эмбаркадеро, а не LLVM

> [116] jack128_ (13.05.13 15:37)
> мутабельная ... иммутабельность

Чем дальше в лес, тем страшнее слова.

Интересно откуда взялся такой синтаксис:
TComponent = class(TPersistent, IInterface, IInterfaceComponentReference) private [Weak] FOwner: TComponent; FName: TComponentName; FTag: NativeInt;

Логичнее же для паскаля было бы:
TComponent = class(TPersistent, IInterface, IInterfaceComponentReference) private FOwner: TComponent; weak; FName: TComponentName; FTag: NativeInt;

Внутри квадратных скобок атрибута может быть много чего другого, что нельзя написать так как во втором варианте, неоднозначной образуется. Она даже в твоем случае есть, если полей за weak больше нет, то непонятно это метод или атрибут.

Как это непонятно? Ни на что как на атрибут это не похоже. Никого же не смущают, например, virtual для методов.

RadStudio XE4. Дожили... Найти похожие ветки