Кросс-платформенная разработка - Delphi 2011: Как к сделанному связанная с Windows межплатформенная библиотека?
Я записал почти точно тот же класс:
template <class C>
class _StringBuffer
{
typename std::basic_string<C> &m_str;
typename std::vector<C> m_buffer;
public:
_StringBuffer(std::basic_string<C> &str, size_t nSize)
: m_str(str), m_buffer(nSize + 1) { get()[nSize] = (C)0; }
~_StringBuffer()
{ commit(); }
C *get()
{ return &(m_buffer[0]); }
operator C *()
{ return get(); }
void commit()
{
if (m_buffer.size() != 0)
{
size_t l = std::char_traits<C>::length(get());
m_str.assign(get(), l);
m_buffer.resize(0);
}
}
void abort()
{ m_buffer.resize(0); }
};
template <class C>
inline _StringBuffer<C> StringBuffer(typename std::basic_string<C> &str, size_t nSize)
{ return _StringBuffer<C>(str, nSize); }
До стандарта каждый компилятор сделал это по-другому. Я полагаю, что старый Аннотируемый Справочник для C++ определил, что временные файлы должны вымыться в конце объема, таким образом, некоторые компиляторы сделали это. Уже в 2003 я нашел, что поведение все еще существовало по умолчанию на компиляторе C++ Forte Sun, таким образом, StringBuffer не работал. Но я был бы удивлен, был ли какой-либо текущий компилятор все еще поврежденным.
11 ответов
Перспектива разработчика визуальных компонентов:
Добавьте уровни функциональности к вашему коду, чтобы иметь возможность добавлять другую платформу без изменения «ядра» компонента. Надеемся, что в компиляторе будет переключатель платформы. (Желательно более одного, работающих вместе друг с другом, например, Windows / ARM, Windows / 386, OSX / Cacao / 386, Linux / Gnome / 386).
Структура макета может выглядеть примерно так.
- ComponentJ.pas
- Linux \ ComponentJ.pas
- Linux \ Gnome \ ComponentJ.pas
- Linux \ KDE \ ComponentJ.pas
- OSX \ ComponentJ.pas
- 386 \ ComponentJ.pas
- ARM \ ComponentJ.pas
Как разработчик приложения:
Я начну с перемещения всех вызовов WIN API в моем коде в группу библиотек в каталоге Windows, чтобы иметь возможность использовать IFDEF в библиотеке level и перевести его на другую платформу, которую я хотел бы поддержать, как только компилятор станет доступен, но только когда я их встречу.) Это также добавит возможность упрощения добавления адаптеров для новых платформ. В любом случае хорошей практикой является удаление возможных зависимостей в центральное место.
IMHO вы не можете создать xplatform Delphi и обеспечить плавный переход для текущих приложений VCL. Это не сработает. VCL был (к счастью, потому что он позволял создавать отличные приложения) был разработан с учетом Windows, и попытка создать совместимую библиотеку, работающую на другой платформе, просто означала бы более длительные циклы разработки и множество компромиссов. Результатом будет библиотека, которую никто бы не хотел использовать. Посмотрите, что случилось с VCL.NET: это был неправильный выбор. И он работал на той же ОС!
Мы знаем, что для таргетинга на платформу, отличную от Windows, с родными приложениями требуется собственная библиотека графического интерфейса. Мы не заботимся о создании GUI с нуля, для нашего приложения это правильный путь, мы не делаем Другие приложения могут пережить перенос графического интерфейса пользователя, но в конечном итоге вы не получите настоящего инструмента xplatform - вы получите инструмент, который может компилироваться для других платформ, но привносит парадигмы одной платформы в другие - и это также не будет приветствоваться " "родные" разработчики на других платформах. Если вы разработчик Linux или Mac, зачем вам учиться работать с библиотекой, которая наследует Windows на вашей платформе? Вы бы сочли это занозой в заднице. Если Embarcadero хочет продавать XDelphi за пределами базы реальных разработчиков, он должен предложить гораздо больше, чем новый CLX.
Я воспользуюсь некоторым древним опытом создания кросс-компилируемой базы кода между Windows и DOS (Delphi 1 / Turbo Pascal 7). Основное правило заключалось в том, чтобы разделить код на несколько блоков. Попробуйте писать код БЕЗ окон, сообщений или каких-либо визуальных компонентов. Если вы обнаружите, что вам нужно позвонить в один из них, поместите этот вызов в другой модуль и напишите прокси (абстрактный класс, от которого вы спускаетесь, работает хорошо) для отправки вызовов. Когда выпускается кросс-совместимая версия, все, что вам нужно сделать, это закодировать другую сторону прокси для новой цели.
Если вы разрабатываете систему на основе форм, попробуйте придерживаться как можно большего количества стандартные компоненты по возможности. НИКОГДА не применяйте какие-либо «бизнес-правила» непосредственно на мероприятии,
Опыт показал, что лучший способ получить приложение Delphi, совместимое с будущими версиями, - это придерживаться чистых компонентов Delphi и ничего не использовать сторонних разработчиков. Такое приложение наверняка будет отстой, но мне так кажется. Я использую множество сторонних компонентов, и приложения отличные и успешные. Но шансы на то, что они перейдут в это будущее, тоже не уверены, и это может вызвать проблемы с такими изменениями, но я бы предпочел иметь отличное приложение сейчас и иметь проблему, чем иметь плохое приложение сейчас и не беспокоиться об этом. .
Ну, помимо всего сказанного - спасибо всем - я действительно думаю, что нам нужны дополнительные вещи:
- нам нужен инструментарий для выполнения необходимых преобразований
- нам нужен инструментарий, чтобы помочь нам в программировании против (некоторой формы) шаблона MVC
Просто выберите последнюю версию 4.6 QT и добавьте хорошую интеграцию между Паскалем и библиотекой QT. Они делали это раньше (во времена Kylix). QT в наши дни настолько мощный.
Я считаю, что QT даже лучше, чем VCL, и как минимум в 10 раз чаще обновляется и исправляется.
Итак, план прост:
- создать кроссплатформенный компилятор Pascal
- сделайте кроссплатформенный RTL
- поместите QT на первое место
, и вы получите первоклассные приложения с исходным кодом на всех платформах.
Не следует делать слишком много компромиссов, чтобы сделать VCL совместимым с Linux и Mac. Windows - это корень VCL. Я предпочитаю новую и очень чистую среду графического интерфейса, хотя и без какой-либо обратной совместимости. Делать VCL толще и толще - не лучшая идея!
Я бы пошел за нестатическими методами, которые более ориентированы на объект (да, используя слишком много статического метода разбивает преимущество объектов, таких как полиморфизм, наследование ...), даже если ваш точка неизменный. И на самом деле, это будет соответствовать способам, подобным классам BigDecimal или Biginteger . Кроме того, статические методы делают классы сложнее для тестирования , поэтому я предпочитаю избегать их, если это возможно, особенно когда это имеет смысл.
- Сделать компиляторы C / C ++ / Delphi, которые нацеливаются на osx / Linux
- , создают компилятор C / C ++, который может быть увеличен
- Написать новый фонд VCL-презентации (VGSCENE / WPF ALIKE) Это не должно быть обратно совместимым! Delphi IDE должен быть Записанные с такими VCL-PF
- библиотекой компонентов должны оставаться как есть (но с улучшенным связыванием данных)
- только предоставить VCL 64-битное для Win64
Это проблема?
- сделать кроссплатформенный компилятор Паскаля
- сделать кроссплатформенный RTL
- поместите QT поверх
Посмотрите на freepascal и lazarus
Мое мнение:
- Сделать кроссплатформенный компилятор (OS x/Linux/ embedded solutions?/ symbian?). Возможно, добавить возможность компилировать/конвертировать код pascal в переносимый код c/c++ для последующей сборки на встраиваемых платформах.
- RTL должен быть разделен на кроссплатформенный слой и родной слой (как для JCL).
- Добавить новые основные компоненты для кросс-платформенной совместимости и родные компоненты для каждой поддерживаемой платформы (например, QT)
- Добавить утилиты перевода для создания/конвертирования между компонентами платформы, например: для конвертации чистой формы windows в форму mac os x cocoa.
- Вся иерархия компонентов для windows должна быть обновлена только для поддержки x64 с максимальной обратной совместимостью. Все кроссплатформенные компоненты должны быть в параллельной иерархии.
- Следующая версия кроссплатформенного решения может быть рефакторинговой и может включать утилиту миграции/конвертации. Из-за минимальной кодовой базы кроссплатформенных решений, иерархия и классы для кроссплатформы могут быть сильно изменены от версии к версии для достижения наилучшей архитектуры.
извините за мой английский - не родной язык (русский - да)!
Я не понимаю. Для меня все .NET выглядит одинаково, если мы не пользуемся услугами третьих лиц. Delphi, использующий стандартные элементы управления, уже полностью функционален, но ваше приложение будет выглядеть как тысячи других.
Я думаю, что Embar следует использовать для КПК, IPhone, Andriod, поскольку настольные компьютеры Windows уже занимают около 98% рынка.
Mac стоит дорого, а Linux стоит совсем бесплатно. Нет смысла переходить на Mac и Linux. Не стоит вложений.