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

Цитата:

т.е. получается что они все-таки пилят android версию на основе ndk, как и намекал бровин в вебинаре.

А на чём ещё они должны были пилить, если трубят на каждом углу, что их инструменты генерят код для процессора, а не ВМ?

Цитата:

а как быть с кодегеном для x86 андорида, ведь он 32-битный, а у emb вроде как какие то проблемы с llvm на 32 битах, какие мнения господа?

Где можно прочитать про эти проблемы?

Цитата:

Просто реально, это Эмбе нужно доказывать, что они зачем-то нужны LLVM'у, а не наоборот.

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

Кстати, о финалайзерах... и некоторых идиотских оптимизациях....

Как вы думаете, какой великий смысл
1) финализировать строковые **константы**
2) не инициализировать модули, входящие в BPL, которые используются основным EXE

надо будет завтра на XE4u1 проверрить, а пока насладитесь эффектами Xe2u1hf5

http://rghost.ru/47754697

Добавлено:

Цитата:

они все-таки пилят android версию на основе ndk

кто-то когда-то сомневался? у них были другие варанты? в приемлемый timeframe "пофиксить 10% багой ху4 на айфоне, потом за два месяца написать и зарелизить андроид" ?

и ты ещё забыл Android/MIPS

Добавлено:

Цитата:

положил бы на доказывание кому-то, что ты не верблюд

вот они обоюдно и положили. Вопрос зачем вообще было публиковать остается открытым (впрочем и на вопрос тоже всем положить).

а да, кстати, а лицензия-то на эти патчи какая?

HeMet, Arioch1
трубят, не трубят, сомневался-не сомневался, не в этом суть, все были домыслы, умозаключения, сейчас есть почти оф.подтверждение, И вопрос в ДРУГОМ:
у емб нет llvm кодегена для x86, а для x64 есть, и вот в чем вопрос:
Мне важно ПРЕДПОЛОЖИТЬ: их решение для андроида будет компилить в нативный x86 для intel atom или нет?

Цитата:

у емб нет llvm кодегена для x86, а для x86 НЕТ, вот в чем вопрос:

Не понял...

Цитата:

Вопрос зачем вообще было публиковать остается открытым (впрочем и на вопрос тоже всем положить).

От них не убудется.

Цитата:

Не понял...

поправил....

А интерес мой связан в связи с этой штуковинной:
_http://hi-tech.mail.ru/review/misc/Lenovo_K900-rev.html
и особенно ее ценой, - похоже, что intel взялся за ум, и демонстрирует реальное стремление,
к завоеванию мобильного рынка, снижением цены на чипы, разработкой РЕАЛЬНо конкруентноспособных процев:
_http://www.3dnews.ru/news/653162, и ведь у Интел мощности то поболее будут, нежели у многих контрактных производителей arm чипов........
В отличии от ms, которые нюх потеряли конкретно, и пуляют свои ресурсы в совершенно левом направлении,
и даже не планируют снижение цены на свою операционку в долгосрочной перспективе, а не одноразовых акций.....

до сих пор от них не убывалось только пользоваться чужиМ, а не открывать своё. Непонятно...

Проверил на Xe4u1 - вроде в win32 больше константы не убивают.
todo: win64....



Добавлено:

Цитата:

И еще вопрос -- если record , содержащая , скажем, динамический массив, размещается в стеке, то должно ли зануляться ее содержимое? Потому как под XE3 64-bit не зануляется..

сделай test case - код, что ты ожидаешь и что наблюдаешь


Добавлено:

Цитата:

у емб нет llvm кодегена для x86, а для x64 есть

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

по той же причине я не думаю, что в FPC кто-то всерьёх будем заниматься переходом на LLVM. Ибо свой кодеген у них и так етсь и сейчас когда в Delphi туман и брожение им только не хватало себе то же самое устроить, чтобы с Паскаля все окончательно разбежались

Вот пример: http://free-pascal-general.1045716.n5.nabble.com/Using-LLVM-with-FPC-td3199368.html
"Ну кто-то занмиался, но мы подумали что у нас есть лучше дела ,чем догонять веечно изменяющийся LLVM"

Вот еще пример: http://code.google.com/p/llvm-pascal/

Вот ещё суровый сургутский парень решил вызывать компиляторы llvm из Дельфи: https://github.com/runaum

Было бы это кому-то надо - давно бы дописали.

Arioch1
опять куча домыслов, буквоедство, чтение текста под левым углом, видимо чтобы выглядеть умным, но ни капли сути........

Arioch1

Цитата:

по той же причине я не думаю, что в FPC кто-то всерьёх будем заниматься переходом на LLVM.

это верно. Причины же : никто это не оплатит.


Цитата:

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

странно, если бы он был, "Кодеген для LLVM". LLVM и есть кодеген.

sergionn

Цитата:

у емб нет llvm кодегена для x86, а для x64 есть

странные умозаключения. Я думаю, когда эмба пилила x64 C++ они взяли не только LLVM, они взяли CLANG целиком, и его кастомизировали. Судя командной строке. Да и язык C++11 многократно сложнее парсить, чем Delphi.

Что важнее, у эмбы уже есть генератор Паскаль->LLVM мета-код. Немного напильника, и LLVM заработает везде.

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

AlekXL

Цитата:

странно, если бы он был, "Кодеген для LLVM"

В принципе почему бы нет. Это довольно странно так называть, то вообще-то смотря что мы рассматриваем.
Это как вход и выход - выход одного может быть входом следующего звена.
т.е. в рамках Эмбы вход вполне может быть паскалем, а выход - пакетами промежуточного когда LLVM.
Вот оно и будет тем самым кодегеном, если мы переделываем DCC32 и рассматривает LLVM, как условный виртуальный процессор - тогда мы будем переделывать именно codegen.

А вот когда в одной фразе дновременно эмб, llvm и x86 - здесь уже смешались в кучу кони, люди.

AlekXL, Arioch1
да причем тут умозкалючения, и белиберда причем тут clang вообще, да запилили они c++ на clang,
да есть у них (и не только у них) pascal->llvm ir, ведь компилируют же армовский релиз на нем!
Возможно я неправильно выразился, периначу:
Сейчас emb имеет конечно решение по генерации финального arm кода из паскаля, на основе llvm, НО не имеет такового для x86-32, а имеет только для С++ x86-64 через clang. Вопрос:
Поскольку emb делает свое решение не через dalvic-vm, а нативно через ndk, где генерируется непосредственно машинный нативный arm код,
как вы думаете, к моменту выхода Андроида, будет ли у emb решение по
ГЕНЕРАЦИИ нативного кода для Intel Atom x86 для андроида? Т.к. сейчас его нет, видимо потому, что ответил allen bauer на мой вопрос про сроки llvm под win:

LLVM is our current go-to solution for the ARM target. It's not without
its own brand of complications, mostly centered around proper debug
information. LLVM generates DWARF debug information, however there is
no standard DWARF mechanism to represent many Delphi specific
items/types. Mainly things like properties, events, variants, strings,
etc... don't have analogs in DWARF. Likewise, building a full-fidelity
debugging solution is a lot of painstaking effort. DWARF allows for
vendor-specific extensions, however that doesn't mean that existing
tooling knows or understands those extensions. All that work has to be
"invented" and produced. It's not as simple as it may seem at first
blush. Sure, we were able to produce ARM code from Delphi in relatively
short order, however the downstream effort is still a large endeavor...
RTL, frameworks, debugging, linking...

Цитата:

Немного напильника, и LLVM заработает везде.

Немного напильника - это поддержка ABI на платформе (а в Линуксе сборка одних исходников с разными версиями и настройками GCC приведет к разному ABI), поддержка ADP для отладки, поддержка RTL и FMX с учётом всего этого. Плюс три семейства процессоров с множеством вариаций в основно из них. Плюс гораздо больше видеокарт, чем на Wintel. В общем - пилить им до второго пришествия хватит.

Добавлено:
Кстати, никтo не пробовал Triple City на андроид смартофнах где памяти не так чтобы очень много? Например Sony WT19i. Игрушка (примитивная в общем, как раз для FMX) периодически выжирала всю память и зависала на пару минут. И хороо если отвисала.

Так что что бы там маркетологи не праздновали, у меня осталось сильное впечатление, что NDKшные программы в Андроиде будут как DOSовские в винде. Да, жить будут, но чтобы они жили хорошо и дружелюбно к остальной системе и нативным (для ОС) программам - нужно будет сиииильно постараться. Поживём - увидим, конечно. Вдруг XE5 будет гениальной системой...

Цитата:

Плюс три семейства процессоров с множеством вариаций в основно из них.

я так понял что это проблемы llvm..........

Цитата:

Плюс гораздо больше видеокарт, чем на Wintel.

а вот это уже другая история - тут они точно нифига до ума не доведут, придется все свои дополнения делать, а учитывая что весь почти код работы с 3d контекстом спрятан в fmx под implementation - то это почти mission impossible...........

Цитата:

ак вы думаете, к моменту выхода Андроида, будет ли у emb решение по ГЕНЕРАЦИИ нативного кода для Intel Atom x86 для андроида?

Думаю, что нет. По двум причинам.

1) если бы они могли - они бы сделали это не на LLVM, а на старом компиляторе, как для настольно-ноутбучной MacOS 10
2) если бы они могли - им бы начальство сказало "вы хренью не занимайтесь! сколько процентов андроидного рынка у MIPS+Intel вместе? и чтобы получить этот процент вы собираетесь потратить еще год ???" и на этом весь этото проект был бы сразу же убит.

Почему они даже для iOS Simulator не сделали LLVM-компилятор?
А ведь там это было бы и проще и полезнее! но - не сделали.

Точно так же если им вдруг моча ударит делать x86/Android, то и делать его надо будет на манер уже отработанного x86/iOS

Цитата:

Точно так же если им вдруг моча ударит делать x86/Android, то и делать его надо будет на манер уже отработанного x86/iOS

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

Цитата:

я так понял что это проблемы llvm

кодогенерация - да.

А вот создание бинарной отладочной информации, приспособление к незнамо скольким вариациям версий и настроек GC++ (а ядро линукса наскольоко знаю пока clang'ом не собирают) наконец просто сборка и запаковка в apk нескольких разных бинарников под почти одинаковые платформы...

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

Но - за исключением Кайликса - они пока не разу не выходили на базар.

Основа - жесткий wintel. Да, новый инструкции, новые интерфейсы - но при жестко заданной и требуемой основе. Ну и результат - появление x64 (ассемблер до сих пор не исправили, надеюсь хоть двойной вызов искючений убрали) и SSE хрен знает когда. А также постоянное отставание от "последних писков моды" Microsoft UI
Далее - Java Builder. Жестко заданный и контролируемый sun'ом рантайм.
Delphi for .Net - жестко заданный .Net 1.x. Перезда на 2.0 не пережила.
Delphi for MacOS - жестко и однообразно контролируемая среда, ещё меньше разнообразия, чем у Wintel. И постоянные жалобы на отставание от X-Code

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

В общем, за пределами десятка моделей телефонов из белого списка (и максимум трёх версий прошивок для каждого) - будут самые разнообразные глюки который ВСЕ будут убиваться в QC c "can't reproduce"


Добавлено:

Цитата:

для отладочной версии, ... релизной версии

Нет, не так. Повторяю. Раздел идет не по "отладочная/релизная" а по "arm/x86"
Теоретически я допускаю Android x86 на базе dcc32, но практически я тут самый чёрный пессимист.

Они с 2009 года не могут сделать в Дельфи рабочих дженериков!
Они с 2011 года не могут сделать работающий Win64 ассемблер

А сейчас им надо вхреначить в старый компилятор все изменения языка, которые они ввели в xe4: строки, Free мутирующий во FreeAndNil и хрен знает, что ещё.

И это будут делать люди, которые в релиз выпускают код (как в документации, так и в RTL) ни разу никем не запускавшийся! За полгода вместо обычного года на разработку новой версии! При полном отсутствии регрессионных тестов (в дженериках XE4 появляются баги, которых не было в XE3)

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

Цитата:

В общем, за пределами десятка моделей телефонов из белого списка (и максимум трёх версий прошивок для каждого) - будут самые разнообразные глюки который ВСЕ будут убиваться в QC c "can't reproduce"

боюсь ты погорячилcя, будет работать в пределах ЛИЧНЫХ телефонов и планшетов 3-х разработчиков, ведь на ноутах с гибридным видео fmx до сих пор, спустя 3-релиза глючит.....

К тому же, разработчики андроида изначально не рекомендуют использовать ndk без особых на то оснований, только если это нельзя сделать на sdk,
эх...........

вот мой тебе совет. Найди слабенький андроидный телефон - типа wt19i или слабее.

найди десяток разных верси triple city от 1.00 и до какая там последняя

и поиграйся.

Одна игра - не статистика, конечно. Но если я и раньше не очень понимал как будут драться заресурсы (ту же оперативку) дальвик и линукс, то на****сь с зависаниями и вылетами примитивной (как нароочно под FMX) игры (а переключиться в другую программу нельзя - NDK-жных чужеродов Андроид отстреливает не задумываясь и им почти всгда приходится перезапускаться с нуля. Но.... зависшая игрушка себя сохранить не може и будет отстрелена без сохранения состояния)... Вот тут тот случай, что прелести NDK лучше один раз увидеть самому...

Уж лучше бы они в win8 лезли imho...

Кстати та самая игрушка была на google Play (когда он отличался от маркета) в виде флэш-апплета (и другие игрушки тоже) - работала как часы!

Arioch1


Цитата:

Немного напильника - это поддержка ABI на платформе (а в Линуксе сборка одних исходников с разными версиями и настройками GCC приведет к разному ABI), поддержка ADP для отладки, поддержка RTL и FMX с учётом всего этого

это не преувеличение , часом? Конечно, линукс можно собрать множеством способов, но, право же, не думаю, что существует какая-та серьезная бинарная несовместимость. Поддержат RHEL/CentOs, Debian/Ubuntu - и достаточно.


Цитата:

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

это проблема драйверов , а не FMX. Должна там быть совместимость, иначе не было бы под эти платформы игрушек.


Цитата:

Так что что бы там маркетологи не праздновали, у меня осталось сильное впечатление, что NDKшные программы в Андроиде будут как DOSовские в винде. Да, жить будут, но чтобы они жили хорошо и дружелюбно к остальной системе и нативным (для ОС) программам - нужно будет сиииильно постараться

Это что, далвик считать нативом?! Мы такое не покупаем..


Цитата:

а учитывая что весь почти код работы с 3d контекстом спрятан в fmx под implementation - то это почти mission impossible...........

Если пишешь игру, пиши на крестах. FMX - бизнес платформа, там редко когда нужен реальный 3D.


Цитата:

им бы начальство сказало "вы хренью не занимайтесь! сколько процентов андроидного рынка у MIPS+Intel вместе? и чтобы получить этот процент вы собираетесь потратить еще год ???" и на этом весь этото проект был бы сразу же убит.

И правильно. Нефиг денюжки на ерунду тратить. Под Intel есть гораздо более совершенная ОС. С кучей программ, и без далвика.


Цитата:

Почему они даже для iOS Simulator не сделали LLVM-компилятор?
А ведь там это было бы и проще и полезнее! но - не сделали.

потому что не нужно. Симулятор все равно слишком сильно отличается от устройства. Так что полная аутентичность не нужна.


Цитата:

Точно так же если им вдруг моча ударит делать x86/Android, то и делать его надо будет на манер уже отработанного x86/iOS

вопрос , если , а главное когда ударит.. Перетаскивать Wintel компилятор под ЛЛВМ -- задача важная, хоть и не первоочередная. Стало быть, когда перетащат, то все, старый Intel компилятор пойдет в утиль везде, на всех платформах.


Цитата:

А вот создание бинарной отладочной информации, приспособление к незнамо скольким вариациям версий и настроек GC++ (а ядро линукса наскольоко знаю пока clang'ом не собирают) наконец просто сборка и запаковка в apk нескольких разных бинарников под почти одинаковые платформы...

все это преувеличение. Разве линукс лежащую под андроид собирают c существенно разными настройками? Не думаю. Никому этот гемор с бинарной совместимостью не нужен.


Цитата:

Но - за исключением Кайликса - они пока не разу не выходили на базар

А древние киликс приложения, говорят, по-прежнему работают на новых системах... Так какого ты пугаешь нас всякой бинарной несовместимостью?

Цитата:

Вдруг XE5 будет гениальной системой...

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


Цитата:

А вот создание бинарной отладочной информации, приспособление к незнамо скольким вариациям версий и настроек GC++

а как отладочная инфа соотносится с вариациями GCC? Думаю, никак. С ядром? Полагаю, никак. Отладочная инфа просто помогает интерпретировать дизассемблированный код, его контекст... И большая(системная) часть работы уже сделана за них.


Цитата:

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

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

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

А, как мы знаем, Дельфи будет по сути игнорировать андроид в телефоне, общаясь напрямую с Линуксом. Совместимость будет, конечно, хуже, чем у так называемых "нативных"приложений, но не очень намного

sergionn

Цитата:

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

с точки зрения менеджера. Не дай Бог, такое будет. Релизы тоже надо отлаживать.


Цитата:

Вот тут тот случай, что прелести NDK лучше один раз увидеть самому...

да, надо посмотреть. Наверное, они сделают java обертку, белую и пушистую, пристрелить которую монитору системы будет не комильфо.. А она возми, да и загрузи нативный контрол, FMX. Мальчик Адрюша в растерянности:"ни богу свечка, ни черту кочерга".


Цитата:

Уж лучше бы они в win8 лезли imho...

там их никто же ждет(M$). И никому эта вынь не нужна.

Цитата:

Поддержат RHEL/CentOs,  Debian/Ubuntu - и достаточно.

я в данном случае говорю про Android NDK, а как его какие ромоделы собирают я хз
и даже официалы вполне могут для моделей разного года менять ключи, ifdef'ы и т.д.


Цитата:

там их никто же ждет(M$). И никому эта вынь не нужна.

А гугл ну пряяям заждался!

Доля 4% и растёт. И ближе к естественному рынку Дельфи. И меньше программ. А вот на гугломаркете придётся оооочень сильно потолкаться локтями. И помогать нам в этом будет Дельфи "не упала и ладно".


Цитата:

пристрелить которую монитору системы будет не комильфо

Как раз в 4.3 ввели ещё одну меру борьбы против таких молодых да наглых...


Цитата:

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

Угу, дизассемблированный код... инфа должна определить как в любом месте кода получить доступ к тем или иным локальным переменным или вызвать ту или иную функцию. И все вариации ABI (конвенция вызовов, выравнивание данных) напрямую на том отражаются. При том, что многие фишки Delphi просто не могут быть описаны в "стандартной" информации и требуют расширений.


Цитата:

А древние киликс приложения, говорят, по-прежнему работают на новых системах...

Угу, в виртуальных машинах. Я как раз слышал, что там настолько жёсткие зависимости на старые версии системных библиотек, что на новых оно летает только с бубнами и на одном крыле.
Т.е. в сисадмина, который допиливает линукс, чтобы старая программа продолжала работать, я верю. А в домохозяйку, которая ткнув в кнопку на маркете получает инструкции "получите root, скачайте отсюда системнфый библиотеки, скомпилируйте стакими-то ключами..." - нет.

Впрочем даже если бы Кайликс был лучшей средой 20 века, все равно - это *единственный* их опыт такого рода и он давно в прошлом.


Цитата:

Это одна из фундаментальных задач ОС -- обеспечивать абстракцию интерфейсов оборудования.    

Она и обеспечивает - пишите как положено, и Дальвик все запустит. А требовать от Жальвика абстрагирование выходящего на уровень Линукс NDK - это как требовать Дельфи, чтобы она обеспечивала контроль типов у raw pointers.


Цитата:

Разве линукс лежащую под андроид собирают c существенно разными настройками?

Хрен его знают. Чистопородный линуксы стараются разделить ядро и userland. Каждое собирается со своими настройками, но в большинстве сручаев независимо друг от друга. И потому можно (в принципе) запускать одну и ту же систему на разных ядрах и наоборот.
Насколько NDK привязан именно к ядру сказать не могу. Но то, что мне пока не попадалось сборки драйвера "под официальное ядро" - это факт. Либо люди ухитряются собрать всё ядро сами, либо "берите что дают". В общем, зоопарк андроидов огромен и EMBT хочет выйти за предеы java-песочниццы в реальный и разнообразный мир "bare metal". Не знаю точно что у них получится ,но по крайней мере QC Can't reproduce они могут на отделную кнопку выносить для удобства.


Цитата:

Симулятор все равно слишком сильно отличается от устройства.

и потому сделаем яму ещё ширше! правильный подход, чё!
Только что же вас тогда огорчает идея Сергиона о разных компиляторах под Андроид?


Цитата:

Это что, далвик считать нативом?

Для железа - нет. Для ОСи - да.


Цитата:

Под Intel есть гораздо более совершенная ОС

QNX ??? *_*


Добавлено:

Цитата:

Цитата: И еще вопрос -- если record , содержащая , скажем, динамический массив, размещается в стеке, то должно ли зануляться ее содержимое? Потому как под XE3 64-bit не зануляется..  

сделай test case - код, что ты ожидаешь и что наблюдаешь

AlekXL ? о чем речь-т ошла, сделай демку plz

Цитата:

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

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


Цитата:

А гугл ну пряяям заждался!

Ну M$ явно хочет контролировать платформу жестко.. А гугл просто продает рекламу..
Да и что гугл, когда окончательные решения принимает самсунг. Но религиозная вера Google в java и впрямь напрягает.


Цитата:

А вот на гугломаркете придётся оооочень сильно потолкаться локтями. И помогать нам в этом будет Дельфи "не упала и ладно".

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

Цитата:

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

А я --не очень. Любое сложное приложение, а тем более ядро системы мало собрать. Надо собрать -- правильно. Иначе будут глюки в различных местах.
Даже программер не справится с незнакомыми исходниками.
И я не думаю, что кастомизаторы андроида делают breaking changes в ядре или стандартных либах.


Цитата:

Цитата:
Под Intel есть гораздо более совершенная ОС
QNX ??? *_*

Нет, Windows. Там по крайней мере ни о каких ABI не нужно беспокоится.


Цитата:

AlekXL ? о чем речь-т ошла, сделай демку plz

В DeHL dunit тестах есть такой неявный assumption, неверный. Но весь код хотя и "примерно" готов для 64-bit, но реально не работает. Я допиливал.
Так что в XE или раньше может и зануляется.
А вот в XE3 64-bit зануляется только managed член. Хотя в прологе есть
XOR RAX, RAX
STOSQ
STOSQ
то есть похоже на зануление структуры, но как-то не попадает. Может, попробую воспроизвести на более простом примере.

Arioch1

Цитата:

Я как раз слышал, что там настолько жёсткие зависимости на старые версии системных библиотек, что на новых оно летает только с бубнами и на одном крыле.

Разве это не забота пакетных менеджеров вытягивать зависимоси для софта, а старая или новая не важно - лишь бы в репозитарии была.

AlekXL

Цитата:

А вот в XE3 64-bit зануляется только managed член

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

Цитата:

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

угу, похоже. Ну тащемта все верно. Ибо нефиг.

Стоны о несовместимости ABI разных андроидов сильно преувеличены. Я недавно забавы ради запустил на андроидовском ядре окружение Lubuntu. Причем ничего не перекомпилировал, просто скачал готовые пакеты из репозиториев. Единственная проблема была в том, что Xorg не мог нормально подружится с глючным драйвером фреймбуфера в ядре (планшет дешевый китай).

Свежий Слегка обновленный роадмап: http://edn.embarcadero.com/article/42544
Как то непонятно на счет поддержки Андроида в Делфи и Студии. Судя по слайдам либо Студия изначально зарелизится без андроида, либо релиз Делфи будет на пару месяцев раньше, чем у Студии.

я дико извиняюсь за свою безграмотность,но

предположим , я в начале юнита стоит директива
{$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

мне необходимо, чтобы у класса, объявленного ниже, лишь отдельные члены были видны в е-ртти. Отдельные, а не , скажем все публичные. Ну и сам класс, конечно.. Можно ли это сделать. Скажет, какой-нибуть атрибут поставить, или что..

AlekXL
не, такого атрибута нет, по области видимости тока

Цитата:

Разве это не забота пакетных менеджеров вытягивать зависимоси для софта

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

PS: подайте плюсик, люди добрые...
http://blogs.embarcadero.com/vsevolodleonov/2013/08/07/secr201/

Цитата:

PS: подайте плюсик, люди добрые...  

уже подали пару-тройку...........

Arioch1

Цитата:

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

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


Цитата:

подайте плюсик, люди добрые...

Там уже три плюса мои

А это нормально, что выдает такую ошибку:

Код:
program Project28;

{$APPTYPE CONSOLE}

{$R *.res}

uses
System.SysUtils;
type
IMyIface=interface
['{E1BC77E0-B0E5-4502-8EFD-9C79BAC83648}']
end;
TMyImp=class(TInterfacedObject,IMyIface);


TPlainUtils=record
class function SafeNullIface<T:IInterface>(var iface: T): Boolean; static; inline;
end;


{ TPlainUtils }

class function TPlainUtils.SafeNullIface<T>(var iface: T): Boolean;
begin
try
PUnknown(@iface)^:=nil;
result:=True;
except
result:=false;
end;

end;


var iface:IMyIface;
begin
try
try
iface:=TMyImp.Create();


finally TPlainUtils.SafeNullIface(iface);
//[dcc32 Error] Project28.dpr(42): E2033 Types of actual and formal var parameters must be identical

end;
except
on E: Exception do
Writeln(E.ClassName, ': ', E.Message);
end;
end.