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.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: The Boost issue (again)

Post by CABAListic »

Beg to differ, it's GPL with the runtime exception which is, from my understanding, pretty much the same as Ogre offers now, just with a slightly different name.

[Edit]You edited quicker than I could post :) [/Edit]
a4z
Halfling
Posts: 64
Joined: Thu Nov 08, 2007 11:16 am

Re: The Boost issue (again)

Post by a4z »

sinbad wrote:The interesting thing to me about POCO is that its threading support seems to be far better than Boost's. It exposes thread priorities (a major missing element of boost::thread), thread pools, and has really nice 'waiting for result' wrappers and other higher-level concepts. For example, see ActiveMethod - a simple way of making an implementation run in parallel, using a thread from a thread pool if you want, with a return type which automatically manages the parallelised result. Compared to what boost::thread offers, that's awesome - it would significantly simplify threaded work compared to what you'd have to write with Boost.

Since I've shelved the general dependence on Boost for now, I'm going to give POCO a run through for the threading support soon, because it looks much more usable and powerful than Boost. Sure, it may have a smaller community, but if it works, I'm open to it.
I think compairing boost and poco does not work caus in my oppionion it is so that if I would like to code something like poco I maybe would use boost as a base lib, or integrate some boost parts 1:1
In fact, poco has some boost code integrated, eg Any, and other parts seem to be heavily insired by boost parts
also the meta programming approach from boost is different from poco

does not mean that I do not like poco, I find this is a realy cool project providing great funktionality
but if I have to decide if I would use poco or boost I would not compair funktionality
I would think about (maybe existing) overhaed through allready abstracted basefunktionality and than decide if I care about this or if I want to code this functionality myself so that I can control how much abstraction I want to have in my project
User avatar
Chris Jones
Lich
Posts: 1742
Joined: Tue Apr 05, 2005 1:11 pm
Location: Gosport, South England
x 1

Re: The Boost issue (again)

Post by Chris Jones »

Yea, i've always been a bit confused by TBB's commercial licence but the way i interpret it is that you get paid support from Intel with it. We use TBB in OGE but mainly for their parallel containers and user mode mutex/locks. We've also made wrappers for the threading related classes so the use of TBB can be removed from OGE, for choice and that TBB doesn't compile using Mingw on windows IIRC (unless its been fixed now).
User avatar
steven
Gnoll
Posts: 657
Joined: Mon Feb 28, 2005 1:53 pm
Location: Australia - Canberra (ex - Switzerland - Geneva)
Contact:

Re: The Boost issue (again)

Post by steven »

About TBB & mingw, Intel and a contributor are working on it. See the latest patch.

AFAIK Intel wants incorporate the mingw patch even if they don't officially support mignw.
but.... the contributor didn't follow the contribution procedures so the patch was not applied :evil:

IMO if someone wants to use TBB for cross-platform he should be careful in using head as Intel might brake the mingw support (until the next patch).
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: The Boost issue (again)

Post by sinbad »

I'm still favouring POCO on face value based on what I'm seeing. It has MinGW support, has build settings for other environments like the iPhone and even crazy tiny ones like the Digi Connect ME. The license is also simpler for users - they would have to be told to distribute the TBB source with their binaries too if we used that (GPL conditions still apply to the original code).

Sticking with Boost for threading is also an option, but if I can avoid writing my own wrappers, I would like to.
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Re: The Boost issue (again)

Post by xavier »

sinbad wrote:
Sticking with Boost for threading is also an option, but if I can avoid writing my own wrappers, I would like to.
One of the benefits of writing your own wrappers is that you have complete control over the implementation. If Boost or POCO do something a bit differently than you like or need, then you often enter the twilight world of licensing issues -- with your own implementation, you don't.

Threading, to be honest, is not that difficult to abstract -- all of the different platforms use basically the same interface (pthread or pthread-like) and while the synch primitives may all have slightly different APIs or syntaxes, they all basically do the same thing, the same way.
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: The Boost issue (again)

Post by sinbad »

xavier wrote:One of the benefits of writing your own wrappers is that you have complete control over the implementation. If Boost or POCO do something a bit differently than you like or need, then you often enter the twilight world of licensing issues -- with your own implementation, you don't.

Threading, to be honest, is not that difficult to abstract -- all of the different platforms use basically the same interface (pthread or pthread-like) and while the synch primitives may all have slightly different APIs or syntaxes, they all basically do the same thing, the same way.
These 2 statements are at odds with each other ;)

The very reason I don't want to write my own threading wrappers is that these issues are pretty well understood already, and there isn't really very much you'd want to tweak / change. However, it's one of those areas that's a bitch if you screw it up, even marginally, therefore it seems crazy to write your own, untested version of something that's already been extensively hammered on, and doesn't have much scope for personal tweaking anyway. I think often the 'I can't trust it unless I wrote it myself' issue is programmer paranoia and not in the slightest bit justified in cases like this.

Boost and POCO's license are both very permissive, hence in the very rare case where you do want to change something, it's really not an issue. TBB is another case entirely.
hellcatv
Gremlin
Posts: 163
Joined: Thu Dec 14, 2006 2:11 am

Re: The Boost issue (again)

Post by hellcatv »

My personal feeling on this is:
poco is not going to be included in the C++ standard, std::tr1 and eventually boost::threads will be--- adding that additional subset of boost will not pull in an extra dependency for long, whereas pulling in poco will add it forever.

I strongly advocate including the boost/tr1/*.hpp headers is ideal because on most modern compilers they don't pull in *any* boost and just include the tr1 equivalents, but on old compilers they require the poor user to pull in boost headers--which is fine because that user didn't have any choice.

I like the dependency on boost threads because that will eventually go into C++0x, but for now pulling in all those boost headers in each ogre header does slow down any sort of builds by a bunch. Ideally one could restructure ogre to depend on boost for threads in the dll, but hide that dependency from the headers using some wrapper classes: right now ogre with threads (which is, for modern streaming games, the right way to do things) pulls in a lot of unnecessary headers and slows down build times...

But that wrapping is tough, so it's fine to keep things as they are.
Please do not bake in the boost headers directly into ogre since other libs may depend on certain boost versions and untangling them can be difficult and including 2 boost versions can cause strange crashing behavior (i've seen it from building ogre with thread=2 with boost 1.35 and the rest of my lib with boost 1.37).

To summarize: since I view ogre with threads as the typical usage pattern for newly built games, I view including boost as a dependency as a negligible cost since it is already there. Since all TR1 is definitely making it into C++ and already has working implementations in the top C++ compilers, requiring the 1 or 2 boost headers which in turn include the compiler-specific TR1 seems perfectly ok.
Including a default version of boost with ogre's vc8/9 dependency/ folder sounds perfectly reasonable since users will then be able to choose their own after that.
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Re: The Boost issue (again)

Post by xavier »

You are ignoring one major fact -- threads are not header-only.
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
Shareth
Gnoblar
Posts: 13
Joined: Tue Aug 21, 2007 7:29 am

Re: The Boost issue (again)

Post by Shareth »

I personally see picking up any library except boost to be a pain in both short and long term. As I said before I think there are much more boost users than users of any other library (simply by the fact that boost is much more widespread) which means using anything except boost will force those users to have 2 dependencies doing same thing. In long term considering boost is moving into standard C++, it will slowly fade away as a dependency, but other libraries won't.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: The Boost issue (again)

Post by jacmoe »

Boost is IMO a bunch of advanced C++ developers researching.
They make some cool stuff, but I really don't like the feel of it. It's too elitist.
And I find that there's a lot of inconsistencies across libraries.
It's great that some of their stuff is going to go into the new C++, but that's not a reason to use Boost.
And POCO is not going to go away anytime soon either.
It's a collection of libraries, just like Boost, but much more coherent, and smaller.
The design principles, the code and the feel of POCO is IMO a strong reason to use it - just like the design and feel of Ogre is a reason to use Ogre. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: The Boost issue (again)

Post by sinbad »

Heh, we seem to have a nice even spread between people who love Boost, hate Boost, and who hate all external dependencies. What chance do I have to please? ;)

My experience in projects generally tells me never to plan based on what might happen tomorrow, but go with what works best today unless somehow that totally screws you longer term. TR1 has been in development for a zillion years, and I don't expect boost::threads to be core for a while either - so basically to me Boost is still an external dependency and has no special treatment, particularly with regards to threads. This doesn't have a long-term impact because essentially any of these wrappers provide the same kind of functionality to a greater or lesser degree (as xavier mentioned, threads are well understood) so trying to pre-empt the future versus judging on current merits is a bad call - a bird in the hand is worth several million in the bush, so to speak.

As such I'm going to give POCO a go to see what it's like compared to boost::thread and not pre-judge. I may even allow the use of either, we'll see.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: The Boost issue (again)

Post by Kojack »

TR1 is only a draft doc of possible features for a future C++ standard. There is no guarantee that any part of it will definitely appear in the next standard.
To quote TR1 itself:
This technical report is non-normative. Some of the library components in this technical report may be considered for
standardization in a future version of C++, but they are not currently part of any C++ standard. Some of the components
in this technical report may never be standardized, and others may be standardized in a substantially changed form.
(In fact not once in the entire 198 page TR1 document are Boost or threads mentioned)
Heh, we seem to have a nice even spread between people who love Boost, hate Boost, and who hate all external dependencies. What chance do I have to please?
See what happens when you give advance warning of something? :)
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: The Boost issue (again)

Post by Klaim »

You could see the problem like this too : boost is big and meant to be an environement library (like the stl, always available in your c++ projects- or should be), and POCO is tiny and then can easily be embedded in the project source code/repository.

Now, I'm a boost user but POCO (and other libs like TBB) seems interesting too. Whatever the library addition as far as it's one of them I don't really care in the end. It just have to work fine (with Ogre).
hellcatv
Gremlin
Posts: 163
Joined: Thu Dec 14, 2006 2:11 am

Re: The Boost issue (again)

Post by hellcatv »

Whether or not boost is ever accepted to the standard we already have top C++ compilers supporting TR1 (visual studio, gcc, etc)--do you think they're going to remove that support if the committees suddenly pooh-pooh the draft? I think people would lose a lot of faith in the C++ standards committee.

The argument about threads not being header-only is true-- I could imagine depending on a better thread library like pthreads (there is a native windows build for that)
Pthreads has a big argument going for it that it's supported on every major OS, it has very lite header files---and all the unices have pthreads preinstalled.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: The Boost issue (again)

Post by sinbad »

Klaim wrote:You could see the problem like this too : boost is big and meant to be an environement library (like the stl, always available in your c++ projects- or should be), and POCO is tiny and then can easily be embedded in the project source code/repository.
I think that's a good way to sum it up.
hellcatv wrote:Pthreads has a big argument going for it that it's supported on every major OS, it has very lite header files---and all the unices have pthreads preinstalled.
Pthreads also needs more manual wrapping to make it nice to use in C++ - in terms of more useful constructs rather than low-level C methods, and things like binding of thread functions to C++ structures etc. But yes, it's a consideration.
User avatar
Invader Zim
Halfling
Posts: 55
Joined: Fri Mar 25, 2005 11:42 am
Location: Oslo, Norway
Contact:

Re: The Boost issue (again)

Post by Invader Zim »

There's one thing I don't like: Boost included everywhere. Ogre currently uses boost for OGRE_AUTO_MUTEX, and the boost-includes trickle into every single header, because it's done in OgrePrerequisites.h. Even if I just include OgreString.h or OgreVector.h, I inherit the boost include, and the extended compile time incurred by it. Is it possible to clean that up somewhat? Because the number of headers that actually use the mutexes are less than 10 percent of all headers.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: The Boost issue (again)

Post by sinbad »

A fair point, this was mostly for our convenience. Will think about this when I revisit this area.
User avatar
pianoman
Halfling
Posts: 47
Joined: Sun Feb 08, 2009 10:52 pm

Re: The Boost issue (again)

Post by pianoman »

I've really REALLY been trying to link with boost::thread the last several days with MinGW (within Eclipse) and have had nothing but trouble (my post: http://www.ogre3d.org/forums/viewtopic.php?f=10&t=49744 ). So I'm quite ready to look into POCO!
[POCO] has MinGW support
-- sinbad

Are there MinGW binaries? I didn't see any MinGW instructions in POCO's readme. I only saw VC mentioned . . .

When it comes to Windows, most libraries care nothing about MinGW :cry: waa, waa :( .
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: The Boost issue (again)

Post by jacmoe »

What's your problem, really?
You do realise that you can get Visual C++ 2008 Express for free? :)
POCO features a makefile - try that. Or it's CMake script.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: The Boost issue (again)

Post by jacmoe »

pianoman wrote:I've really REALLY been trying to link with boost::thread the last several days with MinGW (within Eclipse) and have had nothing but trouble (my post: http://www.ogre3d.org/forums/viewtopic.php?f=10&t=49744 ).
I decided to search for the solution, and it seems like the first Google hit is going to save your *** :
http://www.cleardefinition.com/page/Bui ... for_MinGW/
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
pianoman
Halfling
Posts: 47
Joined: Sun Feb 08, 2009 10:52 pm

Re: The Boost issue (again)

Post by pianoman »

Thanks for the info, jacmoe.

The reason I'm not using VC Express is because, while it's free, the license disallows use for commercial software, and i'm hoping to publish the game that i'm working on. (Then if I have enough money some day to keep up with msvc versions, i can fork some out for it :) )

I'll definitely give that mingw/boost link a try! Apparently you're a better googler than i -- i've been googling everything everywhere and didn't get anything like that. haha oh well.
User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
x 7
Contact:

Re: The Boost issue (again)

Post by haffax »

pianoman wrote:The reason I'm not using VC Express is because, while it's free, the license disallows use for commercial software, and i'm hoping to publish the game that i'm working on.
That's not true. There is no restriction to VC Express that forbids commercial use.
See item 7: http://www.microsoft.com/express/suppor ... fault.aspx
team-pantheon programmer
creators of Rastullahs Lockenpracht
User avatar
pianoman
Halfling
Posts: 47
Joined: Sun Feb 08, 2009 10:52 pm

Re: The Boost issue (again)

Post by pianoman »

What? WHAT?? W H A A A A T ?!?!?! :shock: You mean... i've been using MinGW/Eclipse this whole time when I could have been using......

I'm going to go read the license agreement again RIGHT NOW...

If you're right, then I'll kick myself until the neighbors call the police.
User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
x 7
Contact:

Re: The Boost issue (again)

Post by haffax »

I edited my post in between. See the link there to the official FAQ.
team-pantheon programmer
creators of Rastullahs Lockenpracht
Post Reply