The Boost issue (again)

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.

The Boost issue (again)

Postby sinbad » Wed Mar 25, 2009 3:44 pm

I think it's fair to say we all love Boost (right?). So far, however, since I don't like adding new dependencies unless I can help it, I've resisted making Boost a requirement and tried to find other ways to do it. It's why we have our own SharedPtr for example.

I keep coming across cases where I'd really like to use Boost, the latest being in the paging system. I'd really like to re-use & improve the property system I created for wxOgreMVC, and threading is pretty important such that it doesn't make a lot of sense without it, and boost::bind for type-specific events would be much more elegant than different listener structures). I can probably do it another way, but it won't be as nice.

What's the current opinion of others on this? I know I'm the one who has pushed for keeping it out of the core unless we really needed it, but I'm starting to think now might be the time. CMake makes it easier to pull in the components we need on all platforms easily, so that helps. And I've just eliminated another dependency (ODE, since ReferenceApplication is now gone) so it wouldn't be a net increase in dependencies ;)

Thoughts? I hesitate to change the previous stance just because I want to use Boost more widely now, but maybe others feel now is a good time anyway.
User avatar
sinbad
OGRE Founder (Retired)
OGRE Founder (Retired)
 
Posts: 25870
Kudos: 63
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: The Boost issue (again)

Postby mirlix » Wed Mar 25, 2009 4:12 pm

I use boost in every personal project, so for me this wouldnt change anything.

I would say boost offers enough good libraries to justify it as a new dependencies.

One problem I see is that for console developers it might be tricky to get boost compiled for their target system. I dont know how good the template support of current console compilers is, some comment from someone who works with console would be nice.
mirlix
Goblin
 
Posts: 225
Kudos: 5
Joined: 01 May 2006
Location: Germany

Re: The Boost issue (again)

Postby cdleonard » Wed Mar 25, 2009 4:16 pm

AFAIK both boost::bind and boost::shared_ptr went into tr1. Perhaps ogre could restrict itself to TR1 and avoid all of boost. It's a smaller well-tested subset. Ogre would have to choose a subset of boost anyway; since boost is very very large.

TR1 implementations are also available from third parties. Such alternatives might easily provide a faster thread-safe shared_ptr; so they're worth supporting.
User avatar
cdleonard
Goblin
 
Posts: 266
Kudos: 0
Joined: 31 May 2007

Re: The Boost issue (again)

Postby Kencho » Wed Mar 25, 2009 4:36 pm

My opinion is that Boost would be a nice addition to the dependencies list. It's been widely tested, has very interesting features, and it's not uncommon to be using Boost and Ogre at the same time. This would mean easier-to-understand code for many newcomers, as well as better maintainability, so I say go for it. Haven't looked into TR1 yet, but might be worth considering as an alternative to certain Boost modules as well.
Image
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
 
Posts: 4534
Kudos: 1
Joined: 19 Sep 2003
Location: Burgos, Spain

Re: The Boost issue (again)

Postby Klaim » Wed Mar 25, 2009 4:44 pm

Personally I install a full boost version on each of my C++ developpement environnements, including at work and at home.

I use the installer if already provided for the version I need but if not provided I build from sources (because I use libs that need build). The installer makes life easy and should be used by all people who want to start using boost.

The problem I might see is in cases where Boost is not available, like at work where for instance I work mainly on NDS projects. For some good and bad reasons (compiler limitations and non-proven theories about boost space usage) I cannot use boost on this platform so any boost-dependant lib is forbiden too.
But as Ogre is not possible to run on NDS anyway, that's not a real problem in the end.

The problem might occur if the Ogre user cannot use boost for corporate or pltatform specific reasons. I think there is no platform that Ogre can manage and not boost, rest the corporate reasons.

Anyway I'm sure boost would greatly help.
User avatar
Klaim
Old One
 
Posts: 2324
Kudos: 48
Joined: 11 Sep 2005
Location: Lille, France

Re: The Boost issue (again)

Postby tuan kuranes » Wed Mar 25, 2009 5:14 pm

Boost in.

Afaict, people building their own Ogre dependencies are very few anyway.

And that would also add a real possibility of ogre OGRE_THREAD_SUPPORT enabled by default, which should really be done. (even more with paging standing near.)
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
 
Posts: 3064
Kudos: 4
Joined: 24 Sep 2003
Location: Haute Garonne, France

Re: The Boost issue (again)

Postby sinbad » Wed Mar 25, 2009 5:18 pm

cdleonard wrote:AFAIK both boost::bind and boost::shared_ptr went into tr1. Perhaps ogre could restrict itself to TR1 and avoid all of boost. It's a smaller well-tested subset. Ogre would have to choose a subset of boost anyway; since boost is very very large.


As it happens it's only TR1 bits that I'm interested in initially, except for threads, which we already optionally include. However, I'm not sure of the stability of compiler implementations right now, so I'd probably refer to reference the Boost versions direct initially, until TR1 support in compilers is a bit more of a known quantity. It's a fairly easy change to switch to TR1 headers/namespaces once this is better understood.
User avatar
sinbad
OGRE Founder (Retired)
OGRE Founder (Retired)
 
Posts: 25870
Kudos: 63
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: The Boost issue (again)

Postby Kojack » Wed Mar 25, 2009 5:27 pm

waiting for jacmoe to suggest Poco instead...
:)

It's always possible (well, ease can vary but it's possible) to just extract the bits of boost that are needed. There's a ton of stuff in there that probably won't help ogre.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
 
Posts: 6252
Kudos: 389
Joined: 25 Jan 2004
Location: Brisbane, Australia

Re: The Boost issue (again)

Postby cdleonard » Wed Mar 25, 2009 5:35 pm

sinbad wrote:As it happens it's only TR1 bits that I'm interested in initially, except for threads, which we already optionally include. However, I'm not sure of the stability of compiler implementations right now, so I'd probably refer to reference the Boost versions direct initially, until TR1 support in compilers is a bit more of a known quantity. It's a fairly easy change to switch to TR1 headers/namespaces once this is better understood.


This can be offered as an preprocessor option (OGRE_TR1_IMPLEMENTATION). By default it can be false and will use boost::tr1. It's far too early to *require* the platform to implement std::tr1.

Also: It would be nasty to require a separate installation of boost on windows. The subset of boost that ogre uses (including boost::thread) should be bundled. This would be similar to what happens today with nedmalloc.
User avatar
cdleonard
Goblin
 
Posts: 266
Kudos: 0
Joined: 31 May 2007

Re: The Boost issue (again)

Postby CABAListic » Wed Mar 25, 2009 5:36 pm

Personally, I'm all for pulling Boost in. I have it installed anyway and usually use it for any C++ project I do, because otherwise I'd often have to replicate well proven code in Boost, anyway. And since Ogre already has to do that (SmartPtrs, Any etc.) I really think it would be a wise move.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 2902
Kudos: 58
Joined: 18 Jan 2007

Re: The Boost issue (again)

Postby sinbad » Wed Mar 25, 2009 5:58 pm

cdleonard wrote:
sinbad wrote:As it happens it's only TR1 bits that I'm interested in initially, except for threads, which we already optionally include. However, I'm not sure of the stability of compiler implementations right now, so I'd probably refer to reference the Boost versions direct initially, until TR1 support in compilers is a bit more of a known quantity. It's a fairly easy change to switch to TR1 headers/namespaces once this is better understood.


This can be offered as an preprocessor option (OGRE_TR1_IMPLEMENTATION). By default it can be false and will use boost::tr1. It's far too early to *require* the platform to implement std::tr1.


That's not what I meant - if you refer to the TR1 headers then Boost will automatically provide them (it has wrappers), but if the compiler itself has support for them, it will use those instead. I'm personally a little skeptical that compiler implementations will be any good the first time round, based on prior experience. I'd rather refer to the boost versions explicitly for now, since we will at least know their behaviour. Later on they can be changed to TR1 standard and Boost will still make up for compilers that don't have TR1 support.

Also: It would be nasty to require a separate installation of boost on windows. The subset of boost that ogre uses (including boost::thread) should be bundled. This would be similar to what happens today with nedmalloc.


Well, that's entirely the point here - I wouldn't even ask if I was going to embed Boost in Ogre. I'm not going to do that - nedmalloc is suitably small, rarely updated, self-contained and less usual that embedding made sense. Boost isn't like this - it's bigger, and people probably have versions of it already - if we included a version we'd be in danger of clashing with theirs or needing to update it far too often. At best, we'll provide the subsets of Boost we use in the dependencies, but even that I think isn't very practical because of the versions so many people will already be using in their own apps. Honestly, based on what I'm hearing what self-respecting C++ developer doesn't already have Boost on their machine anyway?
User avatar
sinbad
OGRE Founder (Retired)
OGRE Founder (Retired)
 
Posts: 25870
Kudos: 63
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: The Boost issue (again)

Postby xadhoom » Wed Mar 25, 2009 6:01 pm

We use boost in our projects, too. Especially because we use the threaded version of Ogre. I like Boost for all the stable and maybe performant functionality it gives.
BUT, because its not yet mentioned, trying to find programming errors which are reported with some cryptic two page long template error messages are a real pain in the ass. I wouldn´t be suprised if the help forum would get some extra topics if the first people get errors with SharedPtr or boost::bind listeners.

jacmoe mentioned POCO as a lightweight alternative to boost, but I don´t know if the reduced (?) functionality would outweigh the new dependency...

xad
User avatar
xadhoom
Minaton
 
Posts: 973
Kudos: 2
Joined: 28 Dec 2007
Location: Germany

Re: The Boost issue (again)

Postby ajs15822 » Wed Mar 25, 2009 6:33 pm

I wouldn't be against Ogre3D requiring a Boost dependency-- I, like many others, already have it installed due to other libraries' requirements.
User avatar
ajs15822
OGRE Expert User
OGRE Expert User
 
Posts: 568
Kudos: 2
Joined: 02 Jan 2006
Location: Texas

Re: The Boost issue (again)

Postby cdleonard » Wed Mar 25, 2009 7:33 pm

Where I work we use native Ogre; managed C++ and C# but not boost (it's a microsoft shop). The .net framework already provides so much stuff that boost is not worth the additional complexity. I actually have boost in a corner but only for the occasional glance at the source code.

Ogre doesn't currently require separate installation for dependencies (freeimage etc) and this is a good thing. Adding a subset of boost to the Dependencies pack sounds great. Version conflicts with already-installed versions of boost shouldn't be that bad as long as Ogre sticks to the most stable parts of boost; which it should do anyway.
User avatar
cdleonard
Goblin
 
Posts: 266
Kudos: 0
Joined: 31 May 2007

Re: The Boost issue (again)

Postby sinbad » Wed Mar 25, 2009 7:36 pm

Version conflicts with already-installed versions of boost shouldn't be that bad as long as Ogre sticks to the most stable parts of boost; which it should do anyway.


I think that's only really likely to be the opinion of a current non-Boost user. Anyone already using Boost will not want 2 versions of it in parallel on their machine, it is just asking for obscure problems - even the most stable parts of Boost get bugfixes from time to time, it's inevitable. The furthest I would go is offering an optional pre-built version of Boost to place in the dependencies - existing Boost users would not want to use this option, and the strong impression I'm getting is that this will be the majority.

I'm experimentally adapting and improving my (pretty sweet I think) property system from wxOgreMVC as a possible core feature, for use in describing variants in the paging system but it could also replace StringInterface eventually as a more robust option. It relies on boost::bind and boost::function (which are header-only). I'd also quite like to use my boost::signal wrappers from that project too, although that's less important - but it's much easier to add type-specific events that way.
User avatar
sinbad
OGRE Founder (Retired)
OGRE Founder (Retired)
 
Posts: 25870
Kudos: 63
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: The Boost issue (again)

Postby Praetor » Wed Mar 25, 2009 9:07 pm

I was a long-time boost user, and I'm not necessarily opposed to boost dependencies. I would certainly always choose to avoid extra dependencies if possible. We've gone back and forth on this issue quite a bit. I think I've assumed for a long time now that a boost dependency was inevitable, it just a matter of time. Perhaps the time is now.

@sinbad since I have not had a chance to look at wxOgreMVC at all, I am not familiar with the property system at all. Are you referring to a good method for storing variants, kind of like a beefed up Any? If so, I might be able to send you something I've had for a while to look at.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 3335
Kudos: 3
Joined: 21 Jun 2005
Location: Rochester, New York, US

Re: The Boost issue (again)

Postby KungFooMasta » Wed Mar 25, 2009 9:14 pm

Don't you think asking this question in the Development Forums would give biased results regarding the fact that everybody has Boost installed on their machine? :wink:

I think having Boost in the dependencies would follow what was done for all other dependencies. If advanced users already have Boost on their machine, and/or want a more recent version of Boost compiled with Ogre, they could compile it themself, right? In my team we ran into problems because not everybody was using the same version of Boost, and in particular one teammate kept getting an error using Boost Threads, that was fixed in later versions. If you supply this in the same way you supply the dependencies, everybody is on the same level.
Creator of QuickGUI!
User avatar
KungFooMasta
OGRE Contributor
OGRE Contributor
 
Posts: 2083
Kudos: 16
Joined: 03 Mar 2005
Location: WA, USA

Re: The Boost issue (again)

Postby reptor » Wed Mar 25, 2009 9:25 pm

I use boost in my hobby projects and it's great. To me it is OK either way. But I am not a professional programmer and I think my opinion should have less weight than that of the professionals because I am not doing a business out of this.

So for example, what do the console game developers say about this? Is boost used in console game projects?
reptor
Ogre Magi
 
Posts: 1120
Kudos: 4
Joined: 15 Nov 2006
Location: Finland

Re: The Boost issue (again)

Postby Noman » Wed Mar 25, 2009 9:51 pm

Theoretically speaking, if Ogre's core was to use header-only boost libraries only, I think it is (license-wise) legal to include boost headers under a modified name.
If the use of boost is internal only (meaning, no boost classes/templates that need use get exposed to the user), it could be easier (for the beginner/intermediate user) to work that way (We'll have OgreSignal.h or similar etc, which will contain the namespace-modified code).
This makes maintainance a bit more annoying, but does not require the user to use a specific version of boost. What if a user's environment has a legacy version of boost and they don't intend to upgrade, but Ogre requires a certain version? Etc.

However, I still think that its a better idea to just have boost as a dependency. Easier to keep build systems synchronized with CMake, easier to add more boost references to the project, easier to keep up to date...
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 714
Kudos: 2
Joined: 31 Jan 2005
Location: Israel

Re: The Boost issue (again)

Postby Assaf Raman » Wed Mar 25, 2009 10:13 pm

I checked if boost is available for my current OGRE mobile OS port.
symbian - Seems that symbian has a boost port.
android - I found this on how to use opengl es and c++ with android. Seems that anything that compiles for linux will not be hard to port and use.
iPhone - Seems that boost can compile with STLport and seems that you can compile STLport for iPhone - so I hope it won't be that hard.
Windows CE - seems to be supported.
BREW - other big port problems before boost.
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
 
Posts: 3087
Kudos: 77
Joined: 11 Apr 2006
Location: TLV, Israel

Re: The Boost issue (again)

Postby xavier » Wed Mar 25, 2009 10:35 pm

sinbad wrote:so it wouldn't be a net increase in dependencies ;)


Perhaps not in number, but the size differential is a non-starter for me.

IMO Ogre is starting to become too big and rely a bit too much on external software. It's Sinbad's baby, of course, and he is free to do with it what he likes, but to me, Ogre is becoming bloated already, without the additional (arguably huge) dependencies being discussed here. Compile/link times certainly will skyrocket with the increased number of templates involved (and expanding their use throughout the codebase isn't going to help solve that).

Count me a strong "no" vote.
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
User avatar
xavier
OGRE Moderator
OGRE Moderator
 
Posts: 9481
Kudos: 22
Joined: 18 Feb 2005
Location: Dublin, CA, US

Re: The Boost issue (again)

Postby sinbad » Wed Mar 25, 2009 10:50 pm

xavier wrote:
sinbad wrote:so it wouldn't be a net increase in dependencies ;)


Perhaps not in number, but the size differential is a non-starter for me.

IMO Ogre is starting to become too big and rely a bit too much on external software. It's Sinbad's baby, of course, and he is free to do with it what he likes, but to me, Ogre is becoming bloated already, without the additional (arguably huge) dependencies being discussed here. Compile/link times certainly will skyrocket with the increased number of templates involved (and expanding their use throughout the codebase isn't going to help solve that).

Count me a strong "no" vote.


I respect your opinion here, but I do wonder where this concept of 'huge' comes from when discussing Boost - I think it is a perception that doesn't actually match up with reality. What we're actually talking about in practice is about a pretty small number of header files. Boost as a whole is huge for sure, but no-one uses all of it - not even close. The bits I'm most interested in here are those bits that have been included in TR1 in fact. I've been using these components of Boost in other projects and client projects for years and haven't seen any compile times 'skyrocket' - maybe I'm not using them enough ;) They're just very useful.

The way to 'fudge' this is to do what we've been doing, which is to make our own versions of things Boost already provides. That works, but then later on we get all kinds of issues about things that have been fixed / improved in Boost since we made our version, and it all seems a bit unnecessary. I'd say that referring to Boost / TR1 reduces bloat, since it removes custom code copies that really have no business being duplicated.

The reason I don't want to just copy a subset of it out even though we'll only be using a small section is that I know lots of people use Boost already, so forcing the use of our own packaged version of it will just cause more hassle. Someone else has suggested renaming the classes or namespace, which I suppose is possible, but then you're back to unnecessary code duplication again.
User avatar
sinbad
OGRE Founder (Retired)
OGRE Founder (Retired)
 
Posts: 25870
Kudos: 63
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: The Boost issue (again)

Postby sinbad » Wed Mar 25, 2009 10:56 pm

Praetor wrote:@sinbad since I have not had a chance to look at wxOgreMVC at all, I am not familiar with the property system at all. Are you referring to a good method for storing variants, kind of like a beefed up Any? If so, I might be able to send you something I've had for a while to look at.


It uses Any, but wraps it in a bunch of self-describing properties and routes the whole thing through boost::function / boost::bind so you get reliable, class-hierarchy friendly, typesafe property access direct to member functions.
User avatar
sinbad
OGRE Founder (Retired)
OGRE Founder (Retired)
 
Posts: 25870
Kudos: 63
Joined: 06 Oct 2002
Location: Guernsey, Channel Islands

Re: The Boost issue (again)

Postby Wolfmanfx » Wed Mar 25, 2009 11:01 pm

Why not using openMP instead of boost thread (openMP is a standard not add dep only a compiler switch)
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
 
Posts: 1426
Kudos: 98
Joined: 03 Feb 2006
Location: Austria - Leoben

Re: The Boost issue (again)

Postby xavier » Wed Mar 25, 2009 11:05 pm

sinbad wrote:I respect your opinion here, but I do wonder where this concept of 'huge' comes from when discussing Boost


It comes from past experience downloading, compiling, using and linking against the thing, none of which are in the least bit fun.

It's truly enormous. If you somehow can limit yourself to things that are truly header-only, it's less onerous, but eventually you really want to use something that requires a lib build, and then the interdependencies start mounting (they do even if you are just "header only", because Boost code is incestuous).

I'm not a fan, if you couldn't tell. ;)

There are other decisions made recently regarding the project that have made Ogre less attractive to me personally, but none of those are germane to this topic, other than to say that this (Boost) is not a decision I could support.
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
User avatar
xavier
OGRE Moderator
OGRE Moderator
 
Posts: 9481
Kudos: 22
Joined: 18 Feb 2005
Location: Dublin, CA, US

Next

Return to Developer talk

Who is online

Users browsing this forum: No registered users and 3 guests