Boost support for consoles? (X360, PS3)
I am currently developping software for Windows. I'd like to use boost as I have used it before and liked it. However, in the near future, I expect to also develop for the Xbox 360 and the PlayStation 3 consoles. Currently I make different projects when doing non portable Windows stuff. However, if boost can be used on the X360 and PS3, it could be really usefull as I could do, I suppose, pretty portable code between the 3 platforms with minimum changes. So my question is: Is Boost working on Xbox 360 and PlayStation3? Thanks! JFC
JF Charron a écrit :
So my question is: Is Boost working on Xbox 360 and PlayStation3? Speaking from experience, for the PS3 under the Fedora linux, Boost is working fine as it detects a PowerPC architecture using gcc under linux. Programming the Cell PPE with Boost is doable and works great. On the contrary, programming the SPE don't work that much but it's mainly because any code linked against libstd break the 256Kb barrier of the SPE scratchpad. If you use no STL class in your code and don't include iostream, it'll be fine.
-- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France
* Joel FALCOU
So my question is: Is Boost working on Xbox 360 and PlayStation3? Speaking from experience, for the PS3 under the Fedora linux, Boost is working fine as it detects a PowerPC architecture using gcc under linux.
..apart from the fact that if you have rtti off (which is not so uncommon as other people think), you have to modify boost's sources. VERY ANNOYING. ..and while it seems that xbox360's sdk is almost the same that of win32, it is not in fact and you'll encounter that each time you'll try to use something that works well on other platforms. ..and operating system of ps3 (cellos) is anything but standard linux and you'll face the same problem. it seems like posix, it feels like posix but it is not. *sigh*. personally i'd be _VERY_ happy if whole boost framework is usable on consoles, but i think this is a bigger job, not a minor change that affects lots of libraries. certainly somebody should do it! ;) concerning SPU and stl/boost: remember that 256K is very small place to live and normal user probably wants to use spurs which eats first 13K of the memory. that leaves us.. ummm very little of memory for code and data. bigger the code, smaller the data. it's like good ol' days :) wish you a nice day, mojmir
Mojmir Svoboda a écrit :
..apart from the fact that if you have rtti off (which is not so uncommon as other people think), you have to modify boost's sources. VERY ANNOYING.
For which boost components ? I'm using stuff like math special_functions without any problems.
concerning SPU and stl/boost: remember that 256K is very small place to live and normal user probably wants to use spurs which eats first 13K of the memory. that leaves us.. ummm very little of memory for code and data. bigger the code, smaller the data. it's like good ol' days :)
Using STL in SPE code doens't even link at soem times when using ppu-embed as it detects that the whole executable will not fit in the LS memory space.
* Joel Falcou
Mojmir Svoboda a écrit :
..apart from the fact that if you have rtti off (which is not so uncommon as other people think), you have to modify boost's sources. VERY ANNOYING.
For which boost components ? I'm using stuff like math special_functions without any problems.
almost every component, since it is present in the low level components like shared_ptr, function, lexical_cast, any, program_options and therefore dragged into graph, serialization, asio, ... try it for yourself giving gcc compiler -fno-rtti. m.
Mojmir Svoboda a écrit :
almost every component, since it is present in the low level components like shared_ptr, function, lexical_cast, any, program_options and therefore dragged into graph, serialization, asio, ... try it for yourself giving gcc compiler -fno-rtti.
Ok I was lucky then. I just added some boost include to something that was compiling with -fno-rtti and it dies in some gruesome way.
Hello, Don't know about the 2 consoles mentioned in the title but for PSP you can take a look at my project on boost4psp.sourceforge.net (didn't have the time recently to work more on it unfortunately). Bruno
afternoon,
* Bruno Lalande
Don't know about the 2 consoles mentioned in the title but for PSP you can take a look at my project on boost4psp.sourceforge.net (didn't have the time recently to work more on it unfortunately).
i did not found the documentation, can you point out what you had to change during porting, please? note that i know nothing about psp. i'm quite limited by the use of -fno-rtti and boostpsp fails there too, for example using boost::shared_ptr<int> s(new int(5)); does not compile. someday i'll look whether all these rtti are really necessary and try to replace them somehow.. i'm wondering - what do you plan to do with boostpsp? will it potentially merge to mainline? best regards, mojmir
2008/7/1 Mojmir Svoboda
i did not found the documentation, can you point out what you had to change during porting, please? note that i know nothing about psp.
i'm quite limited by the use of -fno-rtti and boostpsp fails there too, for example using boost::shared_ptr<int> s(new int(5)); does not compile.
I don't know if it's documented anywhere, or how it's meant to be used, but if you're using 1.35, try defining BOOST_NO_TYPEID. http://svn.boost.org/trac/boost/ticket/1108 http://svn.boost.org/trac/boost/browser/trunk/boost/detail/sp_typeinfo.hpp Unfortunately, it doesn't seem to work in the release branch. I'll take that up in the developer list. Daniel
good morning Daniel,
* Daniel James
I don't know if it's documented anywhere, or how it's meant to be used, but if you're using 1.35, try defining BOOST_NO_TYPEID.
ah okay, i did not found this, seems good enough for me. i'll try to compile rest of boost later
http://svn.boost.org/trac/boost/ticket/1108 http://svn.boost.org/trac/boost/browser/trunk/boost/detail/sp_typeinfo.hpp
Unfortunately, it doesn't seem to work in the release branch. I'll take that up in the developer list.
hmm, it seems to be working for me.. i have 1.35 many thanks for pointing that out! best regards, mojmir
i did not found the documentation,
It's a wiki, the address I indicated should lead you directly to it.
can you point out what you had to change during porting, please? note that i know nothing about psp.
It's not really a porting but just a toolset that allows to compile Boost libraries with the PSP SDK, for those libraries that are actually compilable without any change. Porting Boost would involve rewriting some parts of it, like Threads and Filesystem.
i'm quite limited by the use of -fno-rtti and boostpsp fails there too, for example using boost::shared_ptr<int> s(new int(5)); does not compile.
I don't quite understand, this line compiles perfectly using boost4psp. Let me precise that boost4psp uses the unofficial SDK based on gcc. Don't know anything about the official one, but with this one there's no limitation about RTTI as far as I know.
i'm wondering - what do you plan to do with boostpsp? will it potentially merge to mainline?
No, it's a personal project. Originally I needed it to port a little 3D engine that uses Boost.Signals from PC to PSP. Regards Bruno
participants (6)
-
Bruno Lalande -
Daniel James -
JF Charron -
Joel Falcou -
Joel FALCOU
-
Mojmir Svoboda