Особенности разработки многоплатформенных приложений на С++

[Big Cheese]

Такая возникла проблема: пишу, точнее - переписываю некую систему, которая в идеале должна бегать на разных платформах, в частности, на Win32, Solaris, Linux, + желательно на остальных больших UNIX (AIX, HP). Язык - С++. Основная платформа разработки - win32, с ней проблем вроде нет. Основные platform-abstraction библиотеки, типа threads /syncronization, sockets, XML, strings etc. уже написаны / найдены / куплены. Однако очевидно, что существует много issues типа low endian / big endian, memory alignment requirements и т.п., незнание которых может сильно выйти боком. В связи с чем вопрос: не поделятся ли уважаемые приветовцы, где/что можно посмотреть / почитать по этой теме? Заранее благодарен.

[Boriskin]

Если вкратце - то вы попали. Очень гемморойное дело портить чтолибо C++-ное с винды куда то еще, и особенно, не дай бог, какой-нить advanced UI. Думаю, придется вам конкретно занятся пользованием #ifdef етс.

[Sheriff]

В связи с чем вопрос: не поделятся ли уважаемые приветовцы, где/что можно посмотреть / почитать по этой теме? Заранее благодарен.

Начните отсюда:

http://www.unixporting.com/portability.html

Также можете погуглить на тему "Writing portable code" и пробежаться по ссылкам.

А насчет portable libraries посмотрите эти места:

1) http://apr.apache.org/
2) http://sourceforge.net/projects/ptypes/

[Big Cheese]

Если вкратце - то вы попали. Очень гемморойное дело портить чтолибо C++-ное с винды куда то еще, и особенно, не дай бог, какой-нить advanced UI. Думаю, придется вам конкретно занятся пользованием #ifdef етс.

Ага, я уже понял, что будет весело. К счастью, приложение это серверное, так что GUI отсутствует как класс. GUI у нас другой тим ваяет на Java, как это сейчас модно. Вообще у меня не портинг win32->unix как таковой, скорее некий редизайн системы с заменой нескольких layers типа data storage / query processing / transaction processing (на основе Berkeley DB), с сопутствующей перетряской core. Плюс расширение списка поддерживаемых платформ (сейчас только win32 и худо-бедно SunOS)

[Big Cheese]

В связи с чем вопрос: не поделятся ли уважаемые приветовцы, где/что можно посмотреть / почитать по этой теме? Заранее благодарен.

Начните отсюда:

Спасибо, пойду смотреть.

[Michael Popov]

ТОднако очевидно, что существует много issues типа low endian / big endian, memory alignment requirements и т.п., незнание которых может сильно выйти боком.

1) low endian / big endian в рамках одной платформы роли особой не играет. При перегонки данных по сети на другие (неизвестные) платформы ntohl/htonl и др. решают проблемы

2) memory alignment requirements - опять же, в рамках стандартных С++ подходов волновать не должно. new за тебя решает эту проблему. Приколы возникают при сериализации. Например,

Code: Select all

   char buf[5];
   char* p = buf;
   ...
   char c = *p;
   p++;
   int i = *((int*)p);

На Intel платформе сработает (кажется), на RISC платформах упадет с грохотом. Пользуйся memcpy и все будет тип-топ.

3) и т.п. - спрашивай по мере возникновения проблем. А мы тут навалимся с лопатами и вилами ...

[шпиён]

Такая возникла проблема: пишу, точнее - переписываю некую систему, которая в идеале должна бегать на разных платформах, в частности, на Win32, Solaris, Linux, + желательно на остальных больших UNIX (AIX, HP). Язык - С++. Основная платформа разработки - win32, с ней проблем вроде нет. Основные platform-abstraction библиотеки, типа threads /syncronization, sockets, XML, strings etc. уже написаны / найдены / куплены. Однако очевидно, что существует много issues типа low endian / big endian, memory alignment requirements и т.п., незнание которых может сильно выйти боком. В связи с чем вопрос: не поделятся ли уважаемые приветовцы, где/что можно посмотреть / почитать по этой теме? Заранее благодарен.

Не так страшен черт, как его малюют. Несколько простых рекомендаций вам помогут:
1) Самое главное - прячьте абсолютно всю среду в свои обертки. Не только API - все, вплоть до clib. Да, в старом добром clib у одних int, у других long а у третьих size_t, а у четвертых и вовсе функции нет. Тем более прячьте 3rd party libs. Снаружи можно оставить только наиболее часто используемые темплэйты из STL - string, vector, set, map, <algorithm> - они б/м совместимы и работают. Таким образом получается 2 слоя - системный, полный #ifdef и т.п., и прикладной, в котором никаких API и т.п. - только Ваши собственные интерфейсы.
2) Эвалюируйте каждую 3rd party lib перед использованием. Тестов нет - на свалку. Сначала - собрать на всех платформах, прогнать все тесты - потом допускать до использования. Если собралось/заработало слишком большой кровью на имеющихся платформах - подумать, стоит ли включать в свой код - платформы-то меняются. И не забывать про обертку, которая не в коем случае не далжна быть lib-specific, а должна быть problem-specific.
3) На винде лучше использовать VC7.1 (а не 6.0) - потом проще переносить будет. Можно подумать об использовании STLport и на винде тоже - в тех же целях.

[flip_flop]

Не так страшен черт, как его малюют.

Это точно.

Несколько простых рекомендаций вам помогут:
1) Самое главное - прячьте абсолютно всю среду в свои обертки. Не только API - все, вплоть до clib.

Yap!

3) На винде лучше использовать VC7.1 (а не 6.0) - потом проще переносить будет. Можно подумать об использовании STLport и на винде тоже - в тех же целях.

А почему не gcc on cygwin (configure, makefile etc. - вроде бы на Unix вопросы портирования давно проработаны)?