0) в обозримом будущем я планирую написать статью на эту тему.
1) обсуждения этого топика могут помочь мне осветить отдельные темы лучше, чемя бы сделал это по умолчанию.
2) надо всё-таки собрать что-то под WinCe 4.x для понту дела, а также под ps2/psp и ткнуть носом виндузятника Квакса :-)))
имхо, особо надо осветить стандарт, т.е. нестандарт в msvc :) на самом деле, все остальное почти не стоит обсуждения, имхо
т.е. максимально большое кол-во не соответствующих стандарту кусков кода, иллюстрирующих разные ситуации, при которых msvc компилирует код, а gcc - нет.
Zeux
имелось ввиду именно кросс-компилирование(x86->arm, x86->ppc, x86_64Linux->x86FreeBSD) между системами, а не разница в интропретации кода.
>>имхо, особо надо осветить стандарт, т.е. нестандарт в msvc :) на самом деле, все остальное почти не стоит обсуждения, имхо
тогда уже сразу и с pgc и icc и bcc в купе. и оформить в виде таблицы. приму к сведению :-).
>>т.е. максимально большое кол-во не соответствующих стандарту кусков кода, иллюстрирующих разные ситуации, при которых msvc компилирует код, а gcc - нет.
могу конечно ошибаться, но мне кажеться, что наиболее частой ошибкой являеться использование ms-specific функций в библиотеках(itoa, например).
зачем в unixdev освещать msvc? он разве под *nix работает?
Кстати, совместимость кода между платформами и компиляторами очень интересная тема. Мне сейчас приходится писать максимально кросс-платформенный код и это не так просто. Если с Win/Lin всё более или менее понятно (стандарт помогает), то допустим с кодом для Symbian и WinCE не всё просто. Так что если будет некий список того что делать можно, а чего нельзя, то будет очень полезно.
это с опытом приходит
таких "непортабельных" вещей не так уж и много.
между линухом и виндами (x86) можно вобще код написать идентичный, и он будет после перекомпиляции работать
или написать на питоне или жабе -- и будет без перекомпиляции работать
а вот если другая архитектура - нужно уже учитывать little/big endianess, размеры инта и лонга
тут тож можно вывернуться через ifdefs
а на некоторых платформах даж такой роскоши, как чтение файла, просто нет.
приходится заморачиваться с разными проприетарными ресурсными системами
а это - изменение кода под конкретную систему.
и как ни старайся писать портируемый код -- рано или поздно песец таки может наступить, если целевая платформа изначально не рассматривалась как таковая.
особенно прикольно получается, что заложился на супер-крутую портабельную библиотеку, а на целевой платформе она не пашет.
если либа opensource - фиг с ним, правишь ее (не забывая об [L]GPL) и юзаешь (если конечно это не 70-90% от всех исходников игры)
а вот если это проприетарная, или основная библиотека проекта -- может очень плохо стать.
как пример можно привести directx
если от него как следует не абстрагироваться -- переделать под другие api может быть нелегко
в эту сторону и надо смотреть в первую очередь.
и програмить, програмить, програмить................
waker
>>little/big endianess,
опыт PPC/x86 показывает(а сколько ещё покажет на thisGen(чуть не написал - nextGen)консолях) - это не такая уж и большая заморочка, если всё корректно писать с начала.
azazello
да я и не считаю это большой заморочкой...
правда, у меня опыт sparc/x86, а не ppc/x86
кто нить пробовал кросскомпилить под xmingw openal+ogg+vorbis?
программа вылетает если звук использовать
openal,ogg,vorbis брал с devpaks
я пробовал. но все компилил сам.
все работает под wine.
waker
я вот только не понял как собирать openal через xmingw,
вот эту мататень выдает, где брать хрен знает
./OpenAL32/Include/eax.h:12:20: dsound.h: No such file or directory
это получается что openal нужны еще либы directx?
_ace_
угу :)
waker
где их взять ? -)
_ace_
что то у меня рвотный рефлекс начинается от слов directx -)
_ace_
>> где их взять ? -)
в dx sdk.
или давай мыло, я сброшу скомпиленные либы..
Тема в архиве.