Ви використовуєте застарілий браузер. Цей та інші сайти можуть відображатися в ньому некоректно. Необхідно оновити браузер або спробувати використовувати https://www.google.com/chrome/
Нет. 20 М это .Net столько весит. Для запуска Delphi приложений он не нужен. Тут нормальный нативный кроссплатформенный код, без всяких фреймворков и dll-****'ов и прочих непотребств.
Перевел свой проект на delphi xe2
Появились глюки но я думаю они исправимы)
Главная трабла осталась преждней. - не могу найти нормальную компоненту для z modem через com порт. Async глючит и вылетает под win7, компонента от tms вообще не живет.
да, почитал как он поддерживается, по сути трансляция идет на уровне исходного кода в obj-c, который потом надо все равно собирать под xCode. т.е. готовых приложений делфи не собирает, печально.
Пока через костыли.
В следующей версии обущают выпилить FPC и сделать нативную поддержку.
Лично меня больше не устраивают другие вещи в XE2
Запилили "стили" VCL, при этом выпилили возможность менять цвет контролов при включенном стиле. Бесит.
Сегодня установил. Что могу сказать - душа ликовала, правда одно но для меня стиль программирования придется менять, но для сишников ничего нового (имею ввиду чистый не борландский)
Насчет FireMonkey без понятия, юзать или нет. Под маки все равно собирается через костыли и на MacStore наверняка не попадет
Обязательно! Насчет Мака не в курсе, но думаю в ближайшем будущем испытать на Андройде. Плюс - компоненты. Минус - размер исполняемого файла под винду.
наверное приложение с пустым окном весит мегабайт так двадцать теперь?
Это просто смешно при нынешней копеечной стоимости дискового пространства и памяти. Посмотрите на размеры дистрибутивов современного ПО. Уже давно никто не оптимизирует по размеру и не ъхочет на это тратить программистские ресурсы которые подороже железа.
Дело здесь не в оптимизации, а из-за сложности проекта. Сейчас простейший Image View'er обязан редактировать image, не говоря уже о модулях статистики и т.п. Вот отсюда и большой объем дистрибутива.
Уже давно никто не оптимизирует по размеру и не ъхочет на это тратить программистские ресурсы которые подороже железа
Это больно. Объем возникает при включении различных .res, но некоторые из них возможно не нужны данному модулю и будет есть память. Как Вы говорите "память копеечная", а как вы смотрите на обработку данных, их занесение в память, прикрепление к ним меток, выгрузку их при закрытии данного модуля. Это все мелочи если вы пишете прогу для настольной машины домашнего использования (хотя я и с этим не согласен). Но если данная прога используется в корпоративных целях. То возникают вопросы связанные с нагрузкой системы. Простыми словами зачем постоянно переставлять табурет при жарке яичницы.
Я еще не дисасемблировал данные проги, но мне кажется, что это связанно с тем, что в данный проект включается не только новые модули, а так же и старые. То есть при запуске программы происходит пробежка по старым, а затем загружаются новые.
Это мое имхо, но я думаю оптимизировать необходимо все что пишешь. Вот пример:
Код:
{Получаем А (выделяем немного ОЗУ, определяем в ней адресс, пишем по данному адрессу значение А)}
a=DataSet.FieldByName('A').AsFloat;
//То же самое для В
b=DataSet.FieldByName('B').AsFloat;
{Определяем адрес А и В считываем из них значения, выполняем действие, и mov в с}
c=a+b;
{В адрес ячейки записываем данные результата, при этом выполняя опять же ряд не нужных действий}
StringGrid.Cells[x,y].Text=c;
Если это нормально, я сочувствую. Лучше это делать так:
Бред
Оптимизатор работает неплохо
Кроме того, разница в скорости примерно равна нулю
Если программисту первый вариант удобнее - вперед
Сочувствую вашим прогерам, если у вас есть команда
Объем возникает при включении различных .res, но некоторые из них возможно не нужны данному модулю и будет есть память. Как Вы говорите "память копеечная", а как вы смотрите на обработку данных, их занесение в память, прикрепление к ним меток, выгрузку их при закрытии данного модуля.
Если модуль не используется он в память не груззится
Тем более никто не мешает разделить проект на библиотеки (dpk файлы)
Я еще не дисасемблировал данные проги, но мне кажется, что это связанно с тем, что в данный проект включается не только новые модули, а так же и старые.
В том то и дело что не нашёл, будем искать дальше...
Сам инсталлятор с торрента скачал.
Впринципе не критично могу и под 2010 сидеть, просто не хочется потом через месяц снова устанавливать 2010 и обнаружить что чего-то где-то не хватает и переписывать потом всё...
Заинтересовала поддержка 64битных приложений, ну мак само собой... Кстати пробовал (давно) запускать делфи программульки в Linux ASP и Ubuntu (не CLX а обычные для винды, он-то как раз и не работал), всё работало кроме шрифтов, их надо было интегрировать или в файл-ресурсов скинуть, не отображаются. Делфа то-ли 7 то-ли BDS 2006 была. Что это было? Эмулятор какой-нить попался хороший? В разных линуксях? С++ майкрософтовский так не может, пробовал тоже. Хотя может уже и может, но навряд, там наоборот всё большая и большая "интеграция" с виндой и всякими там .NET идёт.
