» Вопросы по Embarcadero RAD Studio XE4

Eternal_Shield
а что именно за баг со стримингом?

Цитата:

Ты бредишь, не было такого или давай пруф.

Найди с чего начался спор. Хотя надо было это сделать до того, как в него влезать.


Цитата:

И каким образом библиотека должна выбирать верную локаль, соответствующую языку текста, из их великого множества?

А как она это делает при работе с COM (MS XML, ADO, Excel, Word) ?
А как она это делает при WideString := AnsiString ?
Значит - может.


Цитата:

Окей, что у них есть? (как раз к вопросу выше)

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


Цитата:

Ты же всё понял

Пока я понял, что ты не можешь отделить Windows от VCL и путаешь одно с другим.
А чтобы эта путаница была менее заметна - даёшь намеренно общие ни к чему не относящиеся фразы типа кнопка-вообще лежит-вообще на панели-вообще.


Цитата:

Вообще то там одно следует из другого.

Тезис 1-й: знать особенности windows не надо, VCL от нас их спрячет, все странности поведения - нужно воспринимать как "данность" VCL
Тезис 2-й: если VCL ведёт себя странно, то она не виновата, потому что "данность" VCL вдруг не данность - а проекция особенностей Windows и это дурак программист, не зная Windows начал использовать VCL.

И по твоему второй тезис вытекает из первого? он ему противоречит вообще-то.


Цитата:

Сам то понял, что написал?

Да.
А тебе какое слово не понятно?
"Объект", "владелец", "освобождать" или "VCL" ?

Добавлено:

Цитата:

С if-in создал багрепорт

ссылку зажал?
и что там вообще происходит (нет у меня xe4) ?

1. Мне кажется у record'ов вообще не должно быть private-полей.

2. Далее, дженерик-методы хранятся в DCU в виде недокомпилированного кода, так же как и инлайн-функции.
Дженерик-инлайн функция... По идее должна храниться так же, то не удивлюсь если Delphi попытается сделать какой-то недокомпилированный-в-квадрате код Впрочем, это детали реализации, программист имеет право о том не знать. Так что...

2. Ты пытаешься из Inline-функции получить доступ к private-полю, которое для inline-функции недоступно. Это не должно компилироваться вообще. И дело тут вовсе не в if-in

Arioch1

Цитата:

1. Мне кажется у record'ов вообще не должно быть private-полей.

приватные поля + публичные свойства, почему бы и нет? иногда очень удобно

Цитата:

Ты пытаешься из Inline-функции получить доступ к private-полю, которое для inline-функции недоступно. Это не должно компилироваться вообще.

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

A_V

Цитата:

а что именно за баг со стримингом?

TWriter.WriteCollection корректно ([more]Сигнатура - данные - терминатор[/more]) сохраняет коллекцию в поток, а вот TReader.ReadCollection начинает неверно ([more]Данные - терминатор, забывая про сигнатуру[/more]) считывать коллекцию из потока. Разумеется сразу exception. В гуях всё видно, а сервисы молча валятся ... ищи потом проблему ...

Arioch1

Цитата:

ссылку зажал?

118446


Цитата:

1. Мне кажется у record'ов вообще не должно быть private-полей.

Зря так кажется.


Цитата:

2. Ты пытаешься из Inline-функции получить доступ к private-полю, которое для inline-функции недоступно. Это не должно компилироваться вообще. И дело тут вовсе не в if-in

Инлайнинг тут нипричём. Видимость переменных никогда не была предлогом для инлайна в рамках одной сущности. Убери инлайн - проблема останется. Дело тут в генериках разумеется, а нерабочий if-in - это уже следствие.

Цитата:

для инлайна в рамках одной сущности.

с какого перепугу публичная функция вдруг стала "в рамках одной сущности" ?

Arioch1
во-первых, в зависимости от того, откуда вызывается метод, изнутри или снаружи, компилятор может его или заинлайнить или нет, во-вторых и приватные методы могут вызываться снаружи, в-третьих вобще-то возможно инлайнить в обоих случаях, хотя может дельфя этого и не умеет. в-четвертых - в оф. доке
http://docwiki.embarcadero.com/RADStudio/XE4/en/Calling_Procedures_and_Functions#Using_the_inline_Directive
ничего такого про приватные поля нет.

__http://qc.embarcadero.com/wc/qcmain.aspx?d=118446

IMHO убери inline если он тут не при чём
И вместо TestSetType = set of 0..255; поставь для соотвествия TestSetType = set of UInt8;

Вообще примеры надо минимизировать: убирать ненужное и писать что не работает.

http://pastebin.com/paaexX61

Добавлено:

Цитата:

компилятор может его или заинлайнить или нет

Только если при {$Inline Auto} ?
Обычно же невозможность заинлайнить функцию - ошибка компиляции.

Кроме того все дженерик-функции по определению сначала инлайнятся, и только потом уже компилируются с конкретными типами.



Добавлено:
Кстати о XE4....

QC 118446 воспроизхводится на LLVM-компиляторе или нет ?

Arioch1

Цитата:

Только если при {$Inline Auto}

нет, auto тут не причем, при auto просто не инлайнятся методы длинее 32 байт.
я про то, что один и тот же метод, в зависимости от вариантов его вызова, будет то заинлайнен в код, то вызван как call.

Цитата:

Обычно же невозможность заинлайнить функцию - ошибка компиляции

в Delphi - нет

Цитата:

роме того все дженерик-функции по определению сначала инлайнятся, и только потом уже компилируются с конкретными типами.

ээ.. не уловил смысла, что-ты понимаешь тогда под 'инлайнятся'?

Цитата:

в Delphi - нет

...а я ее видел.

именно что inline невозможен, скомпилировать нельзя.


Цитата:

что-ты понимаешь тогда под 'инлайнятся'?

хранятся в таком же полу-скомпилированном виде, как инлайн-функции в DCU.
и докомпилируются по месту вызова функции тем же кодом, который докомпилирует методы при указании параметра класса.

точно формат знают только разработчики DCC32

Arioch1

Цитата:

с какого перепугу публичная функция вдруг стала "в рамках одной сущности" ?

В данном конкретном примере, сущность - это record. В рамках этой сущности для метода видны все поля и пофиг на видимость.


Цитата:

...а я ее видел.

Скажем так: инлайн может вызвать побочные эффекты у ем-рошного компиля, которые не позволят скомпилироваться. Ошибка а-ля URW**** или С*****. Это проблема ровности компиля, а не инлайнинга. Методы, которые невозможно заинлайнить никогда будут являться стоперами компилации.


Цитата:

И вместо TestSetType = set of 0..255; поставь для соотвествия TestSetType = set of UInt8;

Тут вопрос ридабилити. Сталкивался с тем, что некоторые человеки-ппцшники считают, это 1 байтовое множество, а не множество с 256ю элементами, размер которого 32 байта

Arioch1

Цитата:

...а я ее видел.

именно что inline невозможен, скомпилировать нельзя.

ок. для документированных случаев (по моей ссылке выше), в местах где инлайн вообще нельзя применять, код вероятно и не скомпилится. но в остальных случаях, когда у компилятора, по одному ему ведомым причинам, 'не получилось', код соберется.
хотя-бы потому, что инлайн не означает, что все вызовы обязательно заинлайнятся, что-то получится, что-то нет, останется как call.. и при сборке отдельной dcu, этого вообще знать нельзя.


Цитата:

хранятся в таком же полу-скомпилированном виде, как инлайн-функции в DCU.

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

Цитата:

для метода видны все поля

Интересно как с этим в C++

В рамках той же логики функция должна читать глобальные переменные в секции Implementation,- видит же их! - а вот хрен вам...


Цитата:

Методы, которые невозможно заинлайнить никогда будут являться стоперами компилации.

Не-а, это была именно остановка компиляции, а не внутренняя ошибка.

{$inline on} обязывает заинлайнить все функции, и если этого не получится - то соотв. ошибка.
А что до "is hint"... ну в справке Дельфи много чуши. До XE3 например (пока я не пристал к Крису с вопросами) там писали что string в новой Delphi **опционально** юникодный.


Цитата:

Тут вопрос ридабилити.

Для багтеста не первый вопрос


Цитата:

некоторые человеки-ппцшники

Ну если у людей в школе не было комбинаторики - то их трудно лечить. Но даже тут можно было бы type xxx = 0..255; var yyy: set of xxx; var I: xxx;

Добавлено:

Цитата:

что инлайнится компилятором уже бинарный код, и нужды хранить что-то промежуточное нет.

и как же он "инлайнится" в место вызова ? де-компиляцией ? тогда бы и ассемблерные функции можно было инлайнить.


Цитата:

инлайн не означает, что все вызовы обязательно заинлайнятся

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

Например я не заметил там запрета на инлайнинг вложенных функций.

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


Цитата:

так что приведи пруф

Тяжело. Кажется всплывало на StackOVerflow при обсуждении какого-то бага на пересечении как раз инлайнов с дженериками. И там была инсайдерская (т.е. неофициальная) инфа, что дженерики сделаны на базе инлайн-механизма.

Собственно, если они уже скомпилированны окончательно, то почему из них нельзя получить доступ в implementation-only переменным, например ?


Цитата:

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

И тут встает интересный вопрос...

Package1(dcp, bpl) - объявляет TBase<T>;
Package2(dcp, bpl) - объявляет TypeX = TBase<integer>;
Package3(dcp, bpl) - объявляет TypeY = TBase<integer>;
EXE - использует оба package2 и package3 (BPL)

Получается, что у нас в программе две реализации одного и того же класса...

Добавлено:

Цитата:

в полученных dcu, код в инлайн функциях был честно собран

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

Или ещё как угодно, внутренности dcc32 нам не ведомы...

Добавлено:

Цитата:

во-вторых и приватные методы могут вызываться снаружи

что вы имели в виду, кстати ? "дружественность" всего модуля ? ну... с точки зрения Дельфи тот же модуль - это не "снаружи", да и можно на strict private заменить без потери общности

Arioch1
Arioch1

Цитата:

Цитата:
так что приведи пруф

Цитата:

Тяжело

ну, на самом деле просто )
проверил, собрал минимальную dcu с одной процедурой, без лишних uses, с inline и без.
с inline размер ощутимо увеличивается, при том что сам код процедуры одинаков, если смотреть через dcu32int.
это конечно не мат. док-во, но мне достаточно )


Цитата:

вполне возможно что инлайн функции двуличны - хранятся и в окончательном виде, и в виде AST

таки да, тут ты прав видимо


Цитата:

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

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

Цитата:

а по месту уже решают вызывать или инлайнить.

.. и может получится, что ничего не проинлайнется, вот и игнор инлайна..
так что все верно в справке на эту тему.


Цитата:

Получается, что у нас в программе две реализации одного и того же класса...

ага, так и получается.. а dcu еще веселее, каждая из проекта все заюзанные дженерик классы в себя включает


Цитата:

Цитата:
во-вторых и приватные методы могут вызываться снаружи

Цитата:

что вы имели в виду, кстати ? "дружественность" всего модуля?

ага.
это комментарий на

Цитата:

с какого перепугу публичная функция вдруг стала "в рамках одной сущности" ?

я про то, что к приватным/протектедам все то-же самое относится, они "в рамках тех же сущностей", т.е для работы инлайна без разницы.

Цитата:

с точки зрения Дельфи тот же модуль - это не "снаружи"

модуль - это на уровне сорцов/dcu, в бинарнике уже нет разницы.

Цитата:

А как она это делает при WideString := AnsiString ?

Глянул. Текст конвертируют WideCharToMultiByte / MultiByteToWideChar, первым параметром которых является кодовая страница системной локали по умолчанию (он же язык ввода по умолчанию). Никакого магического анализа текста не осуществляется.. И да, всё строго по документации.

Теперь касаемо компонентов ввода и буфера обмена. TClipboard (глянул и как оказалось) вообще не применяется в компонентах ввода, все операции с буфером обмена полностью отдаются на откуп системе, даже в тех местах где реализованы методы копирования в буфер обмена - посылается самому себе WM_COPY. Ну и как ты думаешь, что всё это означает? А означает это то, что вся эта чехарда с переключением раскладок лежит не на Delphi, а на самой Винде и более того, это даже документировано, что также опровергает твоё нелепое утверждение о криво реализованной VCL и соблюдении каких то "стандартов".

Цитата:

An application sends the WM_COPY message to an edit control or combo box to copy the current selection to the clipboard in CF_TEXT format.

Standard Clipboard Formats

Цитата:

When you close the clipboard, if it contains CF_TEXT data but no CF_LOCALE data, the system automatically sets the CF_LOCALE format to the current input language.

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

интересно, а в XE4 функция UpperCase все ещё не юникодная?
В XE3 все ёще нет

X11
она юникодная.. но работает только с a..z )
с учетом локали - UpperCase([chr], loUserLocale), она же AnsiUpperCase

X11
Backward-compatibility.

У неё кажется ещё со времен Turbo Pascal заявлена работа исключительно с латиницеЙ, и нкоторые проги на это завязаны

Добавлено:

Цитата:

А означает это то, что вся эта чехарда с переключением раскладок лежит не на Delphi, а на самой Винде

В вашем с AlexXL тезисе о "гениальной" VCL "не нуждающейся в книжках" это не имеет значения.
Это просто одна из тех вещей, которые Delphi должна была икапсулировать скрыть от программиста, как и другие геморрои Windows


Цитата:

просто нет другого способ правильно определить локаль соответствующую языку текста.

Cистеме нет, а программе - есть. Если Delphi решила, на примере WideString, с какой именно кодировкой она собирается трактовать AnsiString, значит и с clipboard она должна себя вести так же.

Цитата:

В вашем с AlexXL тезисе о "гениальной" VCL "не нуждающейся в книжках" это не имеет значения.
Это просто одна из тех вещей, которые Delphi должна была икапсулировать скрыть от программиста, как и другие геморрои Windows

"скрыть" - означает "поломать", т.к. повторю ещё раз:

Цитата:

языковых раскладок может быть установлено более одной и даже двух, просто нет другого способ правильно определить локаль соответствующую языку текста

Цитата:

Cистеме нет, а программе - есть. Если Delphi решила, на примере WideString, с какой именно кодировкой она собирается трактовать AnsiString

А как она, Delphi, может сама решить под какой кодовой таблицей трактовать набор байтов?
Ответ: самой - никак. Поэтому либо программа автоматом берёт системную локаль по умолчанию, либо пользователь сам в настройках программы указывает верную кодовою страницу для текста.

Добавлено:

Цитата:

значит и с clipboard она должна себя вести так же.

Не должна, т.к. это будет неправильно.

Добавлено:

Цитата:

интересно, а в XE4 функция UpperCase все ещё не юникодная?

Для работы с юникодом применяет новый rtl, а старое для совместимости.

Цитата:

она юникодная.. но работает только с a..z )
с учетом локали - UpperCase([chr], loUserLocale), она же AnsiUpperCase

в том-то и дело, что работает с "но" и с "учетом" )))

Добавлено:

Цитата:

Цитата:
интересно, а в XE4 функция UpperCase все ещё не юникодная?

Для работы с юникодом применяет новый rtl, а старое для совместимости.

т.е. есть что-то новое вместо UpperCase?

Цитата:

вместо UpperCase?

Был AnsiUpperCase - ещё в Delphi 5 1999-года насколько помню.


Цитата:

Delphi, может сама решить под какой кодовой таблицей трактовать набор байтов?

А как она УЖЕ РЕШАЕТ это со всеми AnsiString - и переменными и свойствами всех этих компонентов ?
Вот и ПРОДОЛЖАТЬ решать так же в случае копирования в буфер.


Цитата:

т.к. это будет неправильно.

Почему ? Вот я - блондинка. Села за дельфи, бросила на форму TEdit.


Код: procedure TForm1.FormShow(const Sender: TObject);
begin
Edit1.Text := 'Мама Мыла Раму';
Edit1.SelectAll;
Edit1.CopyToClipboard;
end;

Ребята, у меня такой вопрос. Скачал RAD Studio XE4 upd1, установил, пролечил как сказано здесь ( http://forum.ru-board.com/topic.cgi?forum=35&topic=52173&start=0&limit=1&m=3#1). Запускаю - непонятная мне ошибка (скрин - http://img7.tempfile.ru/12243/19a62b0904/b5cb76b105030127965e6426.jpg). Один момент, раньше, на этапе патча (rtm) меня смутило слово "ERROR" ( http://img10.tempfile.ru/12243/19dab5a814/7ec6d185d9c7f3d3fcbcd773.jpg )
Что же делать, ума не дам...Умные люди, подскажите, пожалуйста, мб кто-то сталкивался?

А не может проблема решиться, если кто-нибудь мне отправит свой рабочий файл RADStudioRepository, в котором у меня какая-то ошибка?

P.S. Изначально вопрос задавал сюда - http://forum.ru-board.com/topic.cgi?forum=35&topic=52173&start=240#18 , посоветовали переустановить, предварительно полностью удалив, - не помогло.

SemonXXX
Вот там и продолжайте обсуждение, в этом разделе такие вопросы запрещены.

Цитата:

А как она УЖЕ РЕШАЕТ это со всеми AnsiString - и переменными и свойствами всех этих компонентов ?

Выше писал, системная локаль по умолчанию.


Цитата:

Вот и ПРОДОЛЖАТЬ решать так же в случае копирования в буфер.

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


Цитата:

Ивот вы уверяете, что если Delphi/VCL скопирует текст как полагается, без разрушений, с признаком руского языка - то это по вашему неправильно. А вот если Delphi/VCL все разрушит и скопирует кракозябры - то это правильно и хорошо.

Delphi поступает так, как задизайнено и задокументировано в Винде, а твои предложения - это феерический бред.

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

Добавлено:
SemonXXX
Отписался по твоей проблеме:
http://forum.ru-board.com/topic.cgi?forum=35&topic=52173&start=260#5

Добавлено:

Цитата:

т.е. есть что-то новое вместо UpperCase?

Подробнее:
http://edn.embarcadero.com/ru/article/38446
http://edn.embarcadero.com/ru/article/38582
http://edn.embarcadero.com/ru/article/38703

Цитата:

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

1) У текста нет раскладок, это не клавиатура.

2) Откуда в неюникодной VCL разные "раскладки" ? Если в AnsiString свойстве TEdit.Text несколько разных "раскладок", то он уже испорчен.

----


Цитата:

системная локаль по умолчанию.

как же можно? ведь это же


Цитата:

поломает текст в случае нескольких языковых раскладок.

???

----


Цитата:

Delphi поступает так, как задизайнено и задокументировано в Винде

То есть вы так и не погуглили ни про ReCreateWnd, ни про OwnerDraw, ни про другие случаи, когда Delphi кладет большой и толстый на то,
Цитата:

как задизайнено и задокументировано в Винде

? Попробуйте, вдруг интереcное что узнаете.

Кроме того, что там делает и как делает винда - не важно. Это всё в принципе не оправдание для VCL.
Те кто хочет писать "как в винде" - пишут нa MFC или OWL или сразу на API.
VCL - для тех кто хочет писать "как удобно", в не "как можно вместить WinWord в 2 мегабайта памяти на 16-битном процессоре"

---------------


Цитата:

Код: procedure TForm1.FormShow(const Sender: TObject);
begin
   Edit1.Text := 'Мама Мыла Раму';
   Edit1.SelectAll;
   Edit1.CopyToClipboard;
end;

Этот простой код должен просто работать.

ego666
Arioch1

Так и не понял - чего вы зацепились то! Выскажу имхо.

VCL - довольно удобная, функциональная обертка над WinAPI. Голое WinAPI безусловно не так удобно в п
ользовании, и для своего времени VCL стало хорошим компромисом между абстракцией фреймворка и платформой. Более того, часть функций платформы поддержано языком и фреймворком: сообщения, OLE, OLE-типы, ...

Но как и у любой сложной вещи, у VCL были свои недостатки и косяки в поддержке платформы - глупо отрицать что все идеально. Ничего идеального не бывает, VCL не исключение. Но да, VCL удобна и функциональна, и функциональнее многих! Как и Delphi RTL. Не будем спорить, круче ли .NET, но их хотя бы можно сопоставлять.

К слову, FMX менее удачная абстракция имхо, именно за счет меньшей опоры на поддерживаемые платформы.

Можно ли развивать VCL? Думаю, безусловно да. И зря ЭМРО сделало ставку на FMX, забросив развитие VCL. Но это мое имхо, и чистая теория - в жизни мы имеем то, что имеем: развитие FMX и более медленное развитие VCL. Также считаю зря, что VCL не рефакторят, избавляясь от косяков реализации или архитектуры (часть вы упомянули). Да, сломать старый код - плохо. Но можно было бы придумать варианты! Типа, замена юнитов на "новые версии" или еще какой механизм.. Миграционные ассистенты, в конце концов! Появился бы смысл тянуть код на новые версии среды

> чего вы зацепились то!

А это просто.

AlexXL сказал, что если для бибдиотеки пишут книгу - это плохая библиотека. Для хорошей библиотеки - книги не нужны.

Я возразил ему, что по его логике, тогда и VCL - плохая библиотека, потому что дял ее исползования (за пределами Hello World) нужна документация.

Он, кажется, замолчал. Зато вдруг проснулся ego666, влез в чужой спор на стороне Алекса, и до сих пор доказывает, что VCL не нуждается в докусментации, просто нужно досконально знать MSDN. В обещм, забавная позиция, с ним весело.



Добавлено:

Цитата:

Да, сломать старый код - плохо. Но можно было бы придумать варианты!

Да даже не придумывать, а подсмотреть в LCL, все равно они уже испачкались, делая XE2 на основе Лазаря

Цитата:

И зря ЭМРО сделало ставку на FMX, забросив развитие VCL.

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

Arioch1

Ну что вы как скучающие в поисках троллинга)) Понятно же, что любые категоричные позиции при внимательном рассмотрении - неадекватны! В жизни вообще редко есть чего-то черно-белое. Спорить можно обо всем, но практического смысла занимать крайние позиции нету, имхо

Про книги - это ж понятно, что погорячились с категоричностью! Но если переформулировать - то врядли кто то будет спорить: если для пользования библиотекой без книги никак, то это не очень годная библиотека. Лучше пользовать более понятную библиотеку (если она есть - для некоторых ситуаций без вариантов, типа SDK). Но вреда от книги не усматриваю никакого, и книги пишут не только для библиотек, которые никак нельзя освоить иначе. И вообще - книг писано по любому поводу куча! И по стоящему поводу, и по не очень стоящему!)

Ну и VCL! Да, можно и без книг чего-то писать. но что-то без книг писать сложно (например, интеллектуально емкие штуки, но не из-за VCL, а по своей природе). Да, иногда нужно в MSDN лезть. Да, не всегда что-то очевидно, но часто все довольно прозрачно. Хз. По разному бывает на практике! )) Жизнь - штука сложная и многогранная!

Добавлено:
Frodo_Torbins


Цитата:

Они считают, что вся платформа Win32 мертва

В целом, доля PC среди компьютерных устройств снижается, да. Текущая big thing - это mobile. В векторе маркетинга ЭМРО правы.

Но в тактике действий?! Я считаю, они допускают ошибку. Если у них было удачное решение для одной платформы, нафига они поддержку других платформ сделали вообще с другой идеологией, архитектурой?! И опять наступают на грабли отсутствия рефакторинга для доведения фреймворка.

Если FMX была нужна для других платформ, нафига нужно FMX решение для Win? Там уже есть VCL. Что касается OSX и iOS - почему бы не сделать так, как сделано в iCL? А лучше - с совместимость с VCL (хотя бы идеологической). Надо векторные контролы со стилями - сделайте их "в уголке" для нуждающихся!

Тесты же показывают, что iCL работает куда ни шло прилично, а FMX вообще отвратно. Ну и интересно, как оно на android будет. Волнуюсь за диспетчер памяти, который будет прибивать NDK-приложения "на раз". Все-таки для Android - NDK это экзотика!

Цитата:

Про книги - это ж понятно, что погорячились с категоричностью!

Это вам понятно. А вот некто бросился эту позицию защищать с пеной у рта.

Другой вариант - "чукча - не читатель": некто бросился рвать на груди рубаху, даже не прочитав о чём идёт спор и против чего он возражает (а значит и за что вписывается). Но мы же не будем НАСТОЛЬКО плохо думать о программисте, правда? :-D



Цитата:

если для пользования библиотекой без книги никак

Этот тезис "за всё хорошее против всего плохого".

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

А вот где именно на этой шкале вы поместите "пользование" - это вкусовщина и случайность, тут просто не о чем говорить.

Добавлено:

Цитата:

нафига нужно FMX решение для Win?

Скорее всего купились на обещания Майкрософта и лезли в Метро, чтобы один exe и на десктопе и на планшете.

Добавлено:

Цитата:

Волнуюсь за диспетчер памяти

ДУмаете, с ним что-то плохое случится ? :-D

Arioch1

Цитата:

ДУмаете, с ним что-то плохое случится ? :-D

Ога! Не зобанят ли аппликуху в системе? )))