» Вопросы по Embarcadero RAD Studio XE5-XE8,10.x(Seattle, Berl

Еще один вопросик:
как из модуля C++ Builder зареференсить(то есть объявить) переменную из Delphi RTL?
Конкретно: SysInit.HInstance?

sergionn

Цитата:

Господа, может у кого-нибудь есть возможность
залить сырцы отдельно (ибо мой ssd забит под завязку),
дабы посмотреть, как наши fmx девелоперы продвинулись,
заранее благодарен

Папка source XE8 под катом #

Цитата:

Папка source XE8 под катом

спасибо большущее!

Цитата:

Папка source XE8 под катом

Они там, кажется, какую-то новую архитектуру приложения внедряют. Может MVP.

Цитата:

Папка source XE8 под катом

Цитата:

There are really a lot of changes to FireMonkey, RTL, VCL, Generics and so on

Сравнил юнит System.Generics.Collections из ХЕ7 и ХЕ8 ... мама мия, доно педро, пресвятая дева мария! Они перелопатили TList<T>, TQueue<T>, TStack<T>. Изменения, нежно говоря, радикальные.

Боже мой. Вы только посмотрите на эти хаки, когда из структуры-хелпера вычисляется внешний указатель массива в классе:
Код:
function TListHelper.GetFItems: PPointer;
begin
Result := PPointer(PByte(@Self) + SizeOf(Self));
end;

И нафига эта магия?

Цитата:

Надо срочно выпить чаю ...

Тут надо покрепче что-то пить. Эти хаки называются - "наши компиляторщики не умеют оптимизацию. Совсем."

можно впердолить XE7 бета компилятор(dcc32220->dcc32210, DLL), ну и либы -- будет компилить, и даже отладка работает.

Добавлено:

Цитата:

Эти хаки называются - "наши компиляторщики не умеют оптимизацию. Совсем

а причем здесь оптимизация?

Цитата:

а причем здесь оптимизация?

Притом, что вся эта низкоуровневая возня в памяти должна бы компилятором делаться. Он должен уметь понять всё по размеру и свойствам типа и сгенерировать оптимальный код. А так, такое ощущение что читаю код plain C.

Цитата:

Притом, что вся эта низкоуровневая возня в памяти должна бы компилятором делаться. Он должен уметь понять всё по размеру и свойствам типа и сгенерировать оптимальный код. А так, такое ощущение что читаю код plain C.

там не в оптимизации дело, думается.
Eternal_Shield толком ничего не сказал, как у него водится.
TListHelper это хак чтобы не раздувать размер исполняемого файла, работая с обобщенными методами.
Они выводят из-под обобщения всю реализацию, которую можно вывести, работая с указателями и RTTI -- разумно. Я сам такое делал.

Конечно, грязновато.. Но виновата тут скорее не оптимизация компилятора, а утиная модель и реализация обобщенных методов в Delphi (тоже компилятор, но другая его сторона). Там даже type inference толком не работает.

Абракадабре срочно нужен "Compiler Guy", и лучше парочку.

Цитата:

Result := PPointer(PByte(@Self) + SizeOf(Self));

Мдя, возвращаются времена Delphi2. Не говоря уже о целесообразности хелпера для собственного класса скрытого под толстым слоем других - своих же классов. А что такого нужного в хелпере чего нельзя перенести в базовый TList?

Добавлено:
Вообще я понимаю ценность хелперов в том случае когда Вы не желаете менять чужой код (например TApplication), но хотите привязать свой метод, который по справедливости и удобству написания должен принадлежать этому классу. Но выносить костыли в другой класс(хелпер) на основании, что это костыли, а я используя это юнит и всё равно компилирую в свой код эти костыли и ни как не смогу их обойти смысла нет. TList<T> генерик это не классический TList, код которого божественный и окончательно совершенный. TList<T> надо было до совершенства доводить, а не хелперы ваять, мне кажется. Я бы не против если меня переубедят, увидеть + одну ещё причину (вторую) применения хелперов было бы достаточно интересно.

AlekXL

Цитата:

Eternal_Shield толком ничего не сказал, как у него водится.

Не в этом дело, как там у меня было бы. Дело в том, что ихний подход нарушает целостность в принципе и тут даже говорить не о чем ... Это простое незнание фундаментальных принципов программирования, имхо. Именно это меня и насторожило. Да и всех других, по идее, должно ...

Если так сильно хочется со структурой-хелпером, то передайте указатель на массив в структуру в конструкторе класса, например, через метод SetArrayRef или аналогичный. Всё! Никаких математик во время исполнения и -1 вызов метода.

xpin2013

Цитата:

Я бы не против если меня переубедят, увидеть + одну ещё причину (вторую) применения хелперов было бы достаточно интересно.

Например, у вас есть TMyList<T> с N нетипизированными методами и два наследника: TMyList<Integer> и TMyList<string>. Для каждого наследника будет создана полная копия родителя. В итоге, у вас N нетипизированных методов присутсвуют в обоих новых типах. Вот вам и эксцесс. Выделите эти N методов в другое место и конечные классы "похудеют".

Собственно, что ем-ро и сделала, но блин, что, наследником никак нельзя? Взяли бы создали какой-нить абстрактный TListBaseClass вместо этой хитрожопой структуры и унаследовали бы от него TList<T>. Всё! Все рады и прыгают от счастья, а все остальные сложной математиком всеми усилиями замедляют свои приложения. Но не судьба вестимо....

---

И давайте уже уберём XE5, XE6, XE7 из шапки и названия обоих тем. Оставим только Embarcadero RAD Studio ...

Eternal_Shield

Цитата:

Выделите эти N методов в другое место и конечные классы "похудеют".

Попытался. Что-то я не понимаю. Может хелпер у Вас это не "class helper", а нечто другое? Пытаюсь воспроизвести, но параметр-тип не компилится у меня с хелпером.
Поправьте, если не сложно, а то я запутался.
[more]
Код: [no]type
TMyList<T> = class
public
FData: T;
constructor Create(AData: T);
function Get: T;
end;
TMyListHelper<T> = class helper for TMyList<T>
public
function Get2: T;
end;
TMyListI = class(TMyList<Integer>)
public
end;
TMyListS = class(TMyList<String>)
public
end;

procedure TForm1.Button1Click(Sender: TObject);
var
li: TMyListI;
ls: TMyListS;
begin
li := TMyListI.Create(2);
ls := TMyListS.Create('zz');
ShowMessage(li.Get.ToString);
ShowMessage(ls.Get);
ShowMessage(ls.Get2);
end;

{ TMyList<T> }

constructor TMyList<T>.Create(AData: T);
begin
FData := T;
end;

function TMyList<T>.Get: T;
begin
Result := T;
end;

{ TMyListHelper<T> }

function TMyListHelper<T>.Get2: T;
begin
Result := T;
end;

end.[/no]

AlekXL

Цитата:

Абракадабре срочно нужен "Compiler Guy", и лучше парочку.

А нечего было Barry обижать.
Вернее игнорировать.

xpin2013

Цитата:

Попытался. Что-то я не понимаю.

Class helper'ы не работают для генериков. Если вы зацепились за слово хелпер, то применитольно к структуре имел я ввиду не прямо хелпер class/record helper for, а в смысле тип-сателит, т.е. просто отдельный тип в котором реализованы общие методы.

Что касается вашего примера, то моя идея примерно такая была:
Имеем:

Код:
TMyList<T> = class
...
protected
procedure A;
procedure B;
procedure C;
public
procedure Add(const Value: T);
end;

TMyListString = class (TMyList<String>);
TMyListInteger = class (TMyList<Integer>);
TMyListPointer = class (TMyList<Pointer>);

Eternal_Shield

Цитата:

А да, ещё не забывайте, что одно и тоже объявление

Это касается всех объявлений, а не генериков в частности. Я делаю так:

Код: [no]unit unit1;
uses DBGridEh...
type
TDBGridEh = class(DBGridEh.TDBGridEh)
protected
procedure InplaceEditWndProc(Control: TWinControl; var Message: TMessage); override;
end;
TfmTable = class(TForm)
DBGridEh1: TDBGridEh;[/no]

Абракадабра купила Касталию
http://www.embarcadero.com/ru/press-releases/embarcadero-acquires-castalia-and-usertility-from-twodesk-software

бл, лучше бы купили того, кто им поможет компилер для x86 Android сделать ((((((((

Цитата:

Абракадабра купила Касталию

Вот говорят, что абракадабра обанкротится. Есть ведь деньги, чтобы покупать другие конторы. Значит покупают delphi и builder.

Цитата:

бл, лучше бы купили того, кто им поможет компилер для x86 Android сделать ((((((((

И отладку в придачу.

Цитата:

Вот говорят, что абракадабра обанкротится.

да, я высказывал такие предположения,
но потом стало понятно, что "плывет" (пока) она за счет 2-х факторов:
подписка + агрессивный (с элементами "развода"), маркетинг

Цитата:

Есть ведь деньги, чтобы покупать другие конторы. Значит покупают delphi и builder.

не думаю, что там были серьезные деньги были потрачены...

Цитата:

да, я высказывал такие предположения,
но потом стало понятно, что "плывет" (пока) она за счет 2-х факторов:
подписка + агрессивный (с элементами "развода"), маркетинг

Emb делает ставку на большие компании. Те которые знают, что хотят и под это тратят деньги. Значит есть выгоды от использования Delphi и билдера. Не работает тут агрессивный маркетинг. А подписка у них, как и у любой большой компании. Например, AutoDesk.

Цитата:

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

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

Цитата:

Не работает тут агрессивный маркетинг.

работает , посмотри на их форум и комьюнити - там куча нубов или вернувшихся на/обновившие Дельфи с ранних версий, купившиеся на возможность "кроссплатформенной разработки",
in desperation от толком неработающей системы

Цитата:

А подписка у них, как и у любой большой компании

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

sergionn
SuPriTo

Ребята, а как же Embarcadero до покупки Delphi жила?

Я ее раньше знал как производителя инструментария для работы с БД.
У меня в заначке ее
Embarcadero Change Manager v1.4.0
Embarcadero Rapid SQL v5.7.1
Embarcadero SQL Tuner v1.0.1
с 2001 года.

А еще здесь узнал что она(Embarcadero) ErWin купила - в июле 2014 года.


Цитата:

Значит есть выгоды от использования Delphi и билдера

Есть такое.

У Delphi сильные позиции в ISV, InHouseDeveleopment.
Европа, Латинская Америка, Азия.
Кроме Индии, в которой оутсорса на NET, Java до фига.

В Америке до расцвета MS тоже знали и любили языки Pascal - семейства.
В частности Apple.

Добавлено:
SuPriTo

Цитата:

лучше бы купили того, кто им поможет компилер для x86 Android сделать

Купили же он Delphi for PHP
http://www.qadram.com/vcl4php
http://joseleon.es/?page_id=39

Пусть купят RemObjects!

Добавлено:
Хотя нет... они же с RemObjects разругались потому что Embarcadero теперь "Going to native".

Цитата:

бл, лучше бы купили того, кто им поможет компилер для x86 Android сделать ((((((((

Сейчас переписываю мобильное приложение с Delphi на JAVA.

Ничего не получится у Embarcadero с мобильными платформами с таким подходом. Визуальная часть должна быть нативная, иначе имеет то что имеем

Alexey_Gawrilow

Цитата:

Ребята, а как же Embarcadero до покупки Delphi жила?

Раньше они самостоятельной конторой были, а теперь увы.


Цитата:

У Delphi сильные позиции в ISV, InHouseDeveleopment.

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


Цитата:

В Америке до расцвета MS тоже знали и любили языки Pascal - семейства.
В частности Apple.

Когда это было, в 79-м году, кажется?

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

Цитата:

Хотя нет... они же с RemObjects разругались потому что Embarcadero теперь "Going to native".

Хотя жаль это. Я на Delphi Prism писал. Мне больше понравилось, чем на C#.

Цитата:

Визуальная часть должна быть нативная, иначе имеет то что имеем

А в Xamarin как у них?
В целом я так понимаю, что в делфи можно делать нативные компаненты для android, избегая fm.

NickNNN

Цитата:

Сейчас переписываю мобильное приложение с Delphi на JAVA.

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

Добавлено:
SuPriTo

Цитата:

Хотя жаль это. Я на Delphi Prism писал. Мне больше понравилось, чем на C#.

Так в чем же дело? Delphi Prism назывался ремобжектовый кислород. RemObjects Oxygen - стоит дешевле чем дельфя, поддерживает нативную разработку под три платформы (.NET, WinRT, Cocoa (iOS, OS X), Java (JVM, Android Dalvik)).

Цитата:

Так в чем же дело?

Дело в том, что в основном пишу под Windows. Delphi Prism был неким компромисом для перехода на net. В net мне не нравится сборка мусора. Поэтому я его использую в исключительных случаях, например, когда есть готовые библиотеки.
Все остальное пишу на Delphi, то что требует вычислений на си++.

Цитата:

В целом я так понимаю, что в делфи можно делать нативные компаненты для android, избегая fm.

Я бы пошел именно этим путем


Цитата:

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

Если бегло - удалось сделать нормальный интерфейс без танцев с бубнами + скорость работы раз в 10 по сравнению с Делфи (графическая часть приложения так точно).

SuPriTo

Цитата:

Delphi Prism был неким компромисом для перехода на net. В net мне не нравится сборка мусора

В таком случае я не понимаю твоего сожаления.

NickNNN

Цитата:

Если бегло

А результат, по окончании, выкладывать будешь?

Цитата:

В таком случае я не понимаю твоего сожаления.

Если бы выбирать си# или Delphi Prism я бы выбрал Delphi Prism, но ее перестали поддерживать.