On Thu, Jan 8, 2009 at 10:17 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Thu, Jan 8, 2009 at 10:10 AM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Thu, Jan 8, 2009 at 9:21 AM, Doug Gregor <doug.gregor@gmail.com> wrote:
On Wed, Jan 7, 2009 at 5:33 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
Emil Dotchevski wrote:
Does boost::function not support -fno-rtti by design (linux/gcc 4.1.3)?
target, target_type, and contains require typeid. I suppose that in principle these could be disabled.
Yes, it's possible, and I'd certainly accept a patch that did so.
Someone correct me if I'm doing it wrong, but for example the RTTI-less and typeid-less configurations of Boost Exception, the library I'm maintaining, are tested only by me on my own computer, and I'm only testing them with MSVC and a single version of linux/gcc. Shouldn't the automatic trunk/release tests handle these, as well as other supported configurations?
I guess what I'm saying is, I can make a patch to make boost::function work without RTTI, but I'm certainly not up to running those tests too. :)
I'm sure you can teach bjam to build a test using the appropriate extra flags for each compiler, but I don't recall how to do so. Then we could put that test in with the rest of Boost.Function's tests.
Yes that's how I do it :) but I do not want to be running -fno-rtti tests for boost::function on a regular basis. Also consider that disabling RTTI comes in two flavors, since on MSVC static typeid is available even when RTTI is disabled. This ought to be part of all Boost testing, provided that the Boost community cares about -fno-rtti (I can say this the other way around too, if we're not testing the no-RTTI configuration of Boost, then we don't care about that configuration.) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode