I think AssImp is a really great program! One thing that seems to bother alot of people though (including me) is the boost requirement (or, sort-of requirement). As far as I can see, the only boost stuff that is actually used is the boost:mutex class (except for the classes that have already been re-implemented in the boost workaround part of assimp).
Now, I've recently implemented a portable threading library for C++, closely modeled after the C++0x standard (mainly because I didn't want to use Boost in another project of mine). The library is called TinyThread++, and I think that AssImp can be made completely independent of Boost if you replace the boost::mutex calls with tthread::mutex calls.
I did a quick search/replace and build, and it seems to work all right.
Anyone interested?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using boost seemed strightforward for us at the beginning, but we've underestimated the number of people using it. Luckily, no much boost is used in Assimp, and right now I'm working on annihilating even more ;-)
boost threads stuff is *currently* not really important, after all these mutexes are just used to protect the C-API, which wouldn't even be necessary, a simple API redesign (unfortunately a breaking one so it can't be done) would suffice as well. However, I intend to add threading support to Assimp some day to speed up the post processing pipeline, so more thread stuff will be required! As fas as I can tell, TinyThread would meed the requirements perfectly.
>> AssImp can be made completely independent of Boost if you replace the boost::mutex
calls with tthread::mutex calls.
I'd agree to try that out in the main development line, but I'd like to put it back a few weeks. We've decided to enter feature freeze these days, so I'd currently avoid introducing such a general change. I hope that's fine for you :-)
Bye and thanks!
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just released TinyThread++ v1.0, so it's officialy non-beta (yay!). If you like, I could try to make a patch that replaces Boost with TinyThread++?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't want to decide this on my own, but personally I'd keep it as it is. Reasons for this are:
a) Various other modules of boost are also used in Assimp, it's not just boost::thread.
b) boost::thread is only used to make the PlainC-API thread-safe, which is rarely necessary and can also be switched off easily by a compiler switch.
So I don't see a need for adding an external dependency just to replace part of another dependency.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do agree Ulf. Boost offers a eal stable solution for our requirements. So if you think TinyThread is a better solution for us: can you prepare a small proof of concept with the advantages for us? Maybe we will not change our lib to TinyThread, but other guys see, how easy it is to use your library.
And maybe you have some stuff finished like a job-control which can be useful.
Kimmi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see your point. However, as I pointed out in the first post, I think that having a dependency on Boost in a library (usually) is a bad thing. For instance, for most of the work I do, a Boost dependency is not an option, meaning that I can not use a library that requires Boost.
Also, last time I checked, the only thing that is actually used from Boost is boost::mutex. That seems to me like using a bulldozer to fill up a flower pot…
The thing is that unlike Boost, TinyThread is, well, tiny… ;) …meaning that it would be included in assimp (just two source files), it wouldn't be an external dependency.
Anyway, I'll give it a try.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Apart from boost::threads, there are also format, tuple, foreach, scoped_ptr, shared_ptr and static_assert in use - plus maybe some more I haven't thougth of.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought that the Boost workaround takes care of those (?). Or are they dummy implementations (wouldn't that brake the functionality of assimp?). My point: Boost workaround + TinyThread++ = fully fledged replacement for Boost (right?).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well… in theory, yes :-) But if those replacements had the stability, compatibility and sophistication of their boost counterparts, they would be boost! Boost isn't regarded as one of the C++ must-haves just by accident. A lot of thought went into the boost modules, most of it from much smarter people than me or you. And to me it seems that most of the boost hostility out there is just fear of the weird template mojo going on under the hood. Most people don't have real implementation issues with boost, they just fear the unknown. The boost replacement headers are there just to lower the trust barrier for new users - in my opinion no sane coder would want to work without boost. You may have your qualms with one or the other module, but rejecting all of it? No way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, just to be clear. Technically, I don't think Boost is bad in any way - it's quality, value and comprehensiveness is indeed great. My reluctance to using Boost in certain situations have more to do with administration, and my particular use cases.
One of the main issues I have with Boost is that (as stated in its documentation) you really should lock your development/project to a specific version of Boost (because there is no guarantee of compatibility between versions). In its purest/worst case form, the consequence is that I need to have different Boost installations for different development projects. Also, it means that if I use Boost in an open source project of mine, I force users of that code to use the same version of Boost that I used during development. In practice, things are probably not that bad, but the whole philosophy of Boost is that development of the library is encouraged (it's more of a development ground than a standard).
Another issue is that it's not always easy to use Boost on certain platforms (e.g. if my code needs to work on multiple mobile devices, such as Android, iOS and Symbian). It's usually possible, but not always worth the effort. Especially if the only thing that drives me to use Boost is that I'd like to use a 3rd party library that happens to use a subset of its features…
…and that's why I think that an open source library should not have a dependency on Boost, or any other complex framework for that matter, unless the target is tightly associated with that framework (e.g. a library 100% targeted at KDE applications can obviously have dependencies on Qt, etc).
Just my opinion…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From my point of view we have two different point of views regarding Boost. Schrompf is a fan of boost because it offers a lot of great and useful functionality, which makes his developer life much easier. On the other side we have developers, who just wants an easy to build / use middleware-lib. And yes, sometimes it can be tricky to build Boost on a special platform ( I made my own experiences regarding this ).
The Boost version can be still the developer-version for the power-users, who still wants the featureset offered by boost. And I do agree: we should not cut this completly off. We can get a lot of useful ideas from boost.
But a lot of users of Assimp had already issues with the Boost-dependency. I do not thing educate them is the right solution. And I do not thing educate the Boost-fans is the right was as well. Offering two configurations for two different groups of developers is from my point of view one way to solve this conflict.
So we could offer a NoBoost-configuration with the tinythread-library for instance, if its works fine. If we are using stuff from boost we have to guarantee, that the noboost-build still works. Of course this is just a compromiss but we should try to find a way for all sides. I am not very happy with one discussion regardingBoost per week ;-).
But this is only my opinion.
Kimmi
P.S.: Sorry form my late response, I was rare on time over the weekend.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to add that automatic threading support for Assimp is planned (i.e. parallelize length postprocessing steps automatically). This will increase the gap between the NOBOOST (which has almost no limitations atm) and the regular build, so it would indeed be useful to give non-boost users the option to use another library, TinyThread++ being a good candidate.
The first step would therefore be to integrate TinyThread into the current build system as *optional* feature and to update the few lines of locking stuff in the implementation of the C interface (which is, btw, basically a design flaw since the C++ interface does not need it at all).
I see that TinyThread++ is modelled in the spirit of C++0x - it would be great if it had a boost-based backend as well. This would allow us to code all thread-specific stuff using its API, even if boost is the underlying backend (to clarify why this possibility must be kept, an excerptfrom your docs: 'The Win32 variant uses the native Win32 API for implementing the thread classes, while for other systems, the POSIX threads API (pthread) is used.' - Win32 API *is* a dependency which you can't rely upon. It is possible to use threads via Boost and have no Win SDK installed).
Bye, Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
kimmi, I see your point, though I probably wouldn't agree if I was the project owner (maintaining two parallel configurations that need to work exactly the same way seems overly complex from a configuration management perspective), but luckily it's not my problem ;-)
Anyway, I made a simple patch. Unfortunately it does not, as Alex suggested, support both Boost and TinyThread++. I thought about the two solutions: Boost-look-alike wrapper for TinyThread++ & #ifdef:ed code. I tried the latter, but it became quite cluttered, so I settled for the easier-to-read plain TinyThread++ code.
Please deal with the patch as you wish. It should be quite easy to put boost::mutex back in via ifdef:s (i think there's about a dozen places in the code, in just a couple of cpp files).
Btw: Alex, TinyThread++ uses the Win32 API directly in the .h file. It would be possible to put it in the cpp file via simple wrappers, but I try to keep the library Tiny (also, you are pretty much required to compile the cpp file anyway - there's no DLL version or anything)… Do you have any good use case/example for a Win32 compiler environment where you do not have access to the Win32 API headers (i.e. windows.h)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Marcus,
if you are using the right interface this is not such a big deal. And we will see which way is the favored one for our "customers". But currently one core-member is a little bit "unlucky" about removing Boost, so we should discuss this isuue and how we can solve this conflict. And that's the reason why I am offering a way between these positions :-). We will see …
Anyway: many thanks for your help and the patch. I am currently rare on time and can test it at the beginning of next week. But I will test it!
Kimmi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using BOOST in middleware is a showstopper for many. Although BOOST is a nice library, often companies don't allow to use it. Aside from that, it is a 70Mb download…
Please keep and improve the NOBOOST option.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We do, don't worry :-) For example, my last commit introduced a new boost library which I recently fell in love with (boost.lexical_cast), but I also added a crude noboost workaround right away.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi!
I think AssImp is a really great program! One thing that seems to bother alot of people though (including me) is the boost requirement (or, sort-of requirement). As far as I can see, the only boost stuff that is actually used is the boost:mutex class (except for the classes that have already been re-implemented in the boost workaround part of assimp).
Now, I've recently implemented a portable threading library for C++, closely modeled after the C++0x standard (mainly because I didn't want to use Boost in another project of mine). The library is called TinyThread++, and I think that AssImp can be made completely independent of Boost if you replace the boost::mutex calls with tthread::mutex calls.
I did a quick search/replace and build, and it seems to work all right.
Anyone interested?
Yes, that sounds interesting indeed!
Using boost seemed strightforward for us at the beginning, but we've underestimated the number of people using it. Luckily, no much boost is used in Assimp, and right now I'm working on annihilating even more ;-)
boost threads stuff is *currently* not really important, after all these mutexes are just used to protect the C-API, which wouldn't even be necessary, a simple API redesign (unfortunately a breaking one so it can't be done) would suffice as well. However, I intend to add threading support to Assimp some day to speed up the post processing pipeline, so more thread stuff will be required! As fas as I can tell, TinyThread would meed the requirements perfectly.
>> AssImp can be made completely independent of Boost if you replace the boost::mutex
calls with tthread::mutex calls.
I'd agree to try that out in the main development line, but I'd like to put it back a few weeks. We've decided to enter feature freeze these days, so I'd currently avoid introducing such a general change. I hope that's fine for you :-)
Bye and thanks!
Alex
See https://sourceforge.net/tracker/?func=detail&aid=2980270&group_id=226462&atid=1067635
I've always gone glib for this sort of stuff.
…getting back to this slightly dated post. :)
I've just released TinyThread++ v1.0, so it's officialy non-beta (yay!). If you like, I could try to make a patch that replaces Boost with TinyThread++?
I don't want to decide this on my own, but personally I'd keep it as it is. Reasons for this are:
a) Various other modules of boost are also used in Assimp, it's not just boost::thread.
b) boost::thread is only used to make the PlainC-API thread-safe, which is rarely necessary and can also be switched off easily by a compiler switch.
So I don't see a need for adding an external dependency just to replace part of another dependency.
I do agree Ulf. Boost offers a eal stable solution for our requirements. So if you think TinyThread is a better solution for us: can you prepare a small proof of concept with the advantages for us? Maybe we will not change our lib to TinyThread, but other guys see, how easy it is to use your library.
And maybe you have some stuff finished like a job-control which can be useful.
Kimmi
Ulf, Kimmi,
I see your point. However, as I pointed out in the first post, I think that having a dependency on Boost in a library (usually) is a bad thing. For instance, for most of the work I do, a Boost dependency is not an option, meaning that I can not use a library that requires Boost.
Also, last time I checked, the only thing that is actually used from Boost is boost::mutex. That seems to me like using a bulldozer to fill up a flower pot…
The thing is that unlike Boost, TinyThread is, well, tiny… ;) …meaning that it would be included in assimp (just two source files), it wouldn't be an external dependency.
Anyway, I'll give it a try.
I made a patch and uploaded it: https://sourceforge.net/tracker/?func=detail&aid=3083306&group_id=226462&atid=1067634
It should do the trick (have only tried the CMake build).
Apart from boost::threads, there are also format, tuple, foreach, scoped_ptr, shared_ptr and static_assert in use - plus maybe some more I haven't thougth of.
I thought that the Boost workaround takes care of those (?). Or are they dummy implementations (wouldn't that brake the functionality of assimp?). My point: Boost workaround + TinyThread++ = fully fledged replacement for Boost (right?).
Well… in theory, yes :-) But if those replacements had the stability, compatibility and sophistication of their boost counterparts, they would be boost! Boost isn't regarded as one of the C++ must-haves just by accident. A lot of thought went into the boost modules, most of it from much smarter people than me or you. And to me it seems that most of the boost hostility out there is just fear of the weird template mojo going on under the hood. Most people don't have real implementation issues with boost, they just fear the unknown. The boost replacement headers are there just to lower the trust barrier for new users - in my opinion no sane coder would want to work without boost. You may have your qualms with one or the other module, but rejecting all of it? No way.
Ok, just to be clear. Technically, I don't think Boost is bad in any way - it's quality, value and comprehensiveness is indeed great. My reluctance to using Boost in certain situations have more to do with administration, and my particular use cases.
One of the main issues I have with Boost is that (as stated in its documentation) you really should lock your development/project to a specific version of Boost (because there is no guarantee of compatibility between versions). In its purest/worst case form, the consequence is that I need to have different Boost installations for different development projects. Also, it means that if I use Boost in an open source project of mine, I force users of that code to use the same version of Boost that I used during development. In practice, things are probably not that bad, but the whole philosophy of Boost is that development of the library is encouraged (it's more of a development ground than a standard).
Another issue is that it's not always easy to use Boost on certain platforms (e.g. if my code needs to work on multiple mobile devices, such as Android, iOS and Symbian). It's usually possible, but not always worth the effort. Especially if the only thing that drives me to use Boost is that I'd like to use a 3rd party library that happens to use a subset of its features…
…and that's why I think that an open source library should not have a dependency on Boost, or any other complex framework for that matter, unless the target is tightly associated with that framework (e.g. a library 100% targeted at KDE applications can obviously have dependencies on Qt, etc).
Just my opinion…
From my point of view we have two different point of views regarding Boost. Schrompf is a fan of boost because it offers a lot of great and useful functionality, which makes his developer life much easier. On the other side we have developers, who just wants an easy to build / use middleware-lib. And yes, sometimes it can be tricky to build Boost on a special platform ( I made my own experiences regarding this ).
The Boost version can be still the developer-version for the power-users, who still wants the featureset offered by boost. And I do agree: we should not cut this completly off. We can get a lot of useful ideas from boost.
But a lot of users of Assimp had already issues with the Boost-dependency. I do not thing educate them is the right solution. And I do not thing educate the Boost-fans is the right was as well. Offering two configurations for two different groups of developers is from my point of view one way to solve this conflict.
So we could offer a NoBoost-configuration with the tinythread-library for instance, if its works fine. If we are using stuff from boost we have to guarantee, that the noboost-build still works. Of course this is just a compromiss but we should try to find a way for all sides. I am not very happy with one discussion regardingBoost per week ;-).
But this is only my opinion.
Kimmi
P.S.: Sorry form my late response, I was rare on time over the weekend.
I'd like to add that automatic threading support for Assimp is planned (i.e. parallelize length postprocessing steps automatically). This will increase the gap between the NOBOOST (which has almost no limitations atm) and the regular build, so it would indeed be useful to give non-boost users the option to use another library, TinyThread++ being a good candidate.
The first step would therefore be to integrate TinyThread into the current build system as *optional* feature and to update the few lines of locking stuff in the implementation of the C interface (which is, btw, basically a design flaw since the C++ interface does not need it at all).
I see that TinyThread++ is modelled in the spirit of C++0x - it would be great if it had a boost-based backend as well. This would allow us to code all thread-specific stuff using its API, even if boost is the underlying backend (to clarify why this possibility must be kept, an excerptfrom your docs: 'The Win32 variant uses the native Win32 API for implementing the thread classes, while for other systems, the POSIX threads API (pthread) is used.' - Win32 API *is* a dependency which you can't rely upon. It is possible to use threads via Boost and have no Win SDK installed).
Bye, Alex
kimmi, I see your point, though I probably wouldn't agree if I was the project owner (maintaining two parallel configurations that need to work exactly the same way seems overly complex from a configuration management perspective), but luckily it's not my problem ;-)
Anyway, I made a simple patch. Unfortunately it does not, as Alex suggested, support both Boost and TinyThread++. I thought about the two solutions: Boost-look-alike wrapper for TinyThread++ & #ifdef:ed code. I tried the latter, but it became quite cluttered, so I settled for the easier-to-read plain TinyThread++ code.
Please deal with the patch as you wish. It should be quite easy to put boost::mutex back in via ifdef:s (i think there's about a dozen places in the code, in just a couple of cpp files).
Btw: Alex, TinyThread++ uses the Win32 API directly in the .h file. It would be possible to put it in the cpp file via simple wrappers, but I try to keep the library Tiny (also, you are pretty much required to compile the cpp file anyway - there's no DLL version or anything)… Do you have any good use case/example for a Win32 compiler environment where you do not have access to the Win32 API headers (i.e. windows.h)?
Hi Marcus,
if you are using the right interface this is not such a big deal. And we will see which way is the favored one for our "customers". But currently one core-member is a little bit "unlucky" about removing Boost, so we should discuss this isuue and how we can solve this conflict. And that's the reason why I am offering a way between these positions :-). We will see …
Anyway: many thanks for your help and the patch. I am currently rare on time and can test it at the beginning of next week. But I will test it!
Kimmi
Using BOOST in middleware is a showstopper for many. Although BOOST is a nice library, often companies don't allow to use it. Aside from that, it is a 70Mb download…
Please keep and improve the NOBOOST option.
We do, don't worry :-) For example, my last commit introduced a new boost library which I recently fell in love with (boost.lexical_cast), but I also added a crude noboost workaround right away.