| |||||||||||||
Well, it's nice to ignore facts...Well, it's nice to ignore facts...Posted Aug 23, 2011 10:44 UTC (Tue) by jwakely (subscriber, #60262)In reply to: Well, it's nice to ignore facts... by cmccabe Parent article: HP dropping webOS devices
Without exceptions, you cannot use std::tr1::shared_ptr, which is more or less the standard smart pointer in the C++ world these days. Most of the stuff in the STL uses exception too, which is inconvenient to say the least.Both boost::shared_ptr and GCC's tr1::shared_ptr can be used without exceptions. Failed memory allocations will abort. The only other throwing operation is converting a weak_ptr to a shared_ptr, which can be replaced by calling weak_ptr::lock() which is non-throwing. GCC's C++ standard library can be used with -fno-exceptions and I'd be very surprised if other implementations don't have something equivalent. In normal use there are few places where the C++ Standard Library throw exceptions, and they can often be avoided by checking preconditions first (e.g. don't call std::vector::at() without checking the index isn't out of range first)
(Log in to post comments)
Well, it's nice to ignore facts... Posted Aug 23, 2011 19:24 UTC (Tue) by cmccabe (guest, #60281) [Link]
> Both boost::shared_ptr and GCC's tr1::shared_ptr can be used without
> exceptions. Failed memory allocations will abort. The only other throwing > operation is converting a weak_ptr to a shared_ptr, which can be replaced > by calling weak_ptr::lock() which is non-throwing.
That is technically true, but a little bit misleading.
Code using tr1::shared_ptr will not compile without support for RTTI. Now, you could enable RTTI without enabling exceptions, but nobody actually does, because RTTI requires exceptions in order to function in any reasonably sane way. Otherwise, the entire program aborts when a dynamic_cast to a reference type fails. And I don't think even the most die-hard C++ advocate could put a positive spin on that.
Realizing this, Google compiled their old libc without support for exceptions or RTTI. So you will not be able to use shared_ptr with the old NDK, only with the new one-- sorry.
There is talk of removing the dependency on RTTI from tr1::shared_ptr. But of course that will take years to be agreed on by everyone and rolled out, assuming that it goes forward.
Well, it's nice to ignore facts... Posted Aug 23, 2011 20:09 UTC (Tue) by cmccabe (guest, #60281) [Link]
> Realizing this, Google compiled their old libc without support
> for exceptions or RTTI. So you will not be able to use shared_ptr > with the old NDK, only with the new one-- sorry.
er, I meant libstdc++
Well, it's nice to ignore facts... Posted Aug 24, 2011 3:00 UTC (Wed) by njs (guest, #40338) [Link]
Man, if only there were a full-featured free-software C/C++ standard library that they could have used to avoid this whole mess.
Well, it's nice to ignore facts... Posted Aug 24, 2011 21:53 UTC (Wed) by jwakely (subscriber, #60262) [Link]
Well, it's nice to ignore facts... Posted Aug 24, 2011 22:12 UTC (Wed) by jwakely (subscriber, #60262) [Link] There is talk of removing the dependency on RTTI from tr1::shared_ptr. But of course that will take years to be agreed on by everyone and rolled out, assuming that it goes forward.What talk exactly? You know TR1 is finished, right? It is what it is, there will be no more changes to the document. But if you want changes to libstdc++'s implementation of tr1::shared_ptr, just ask me, if it's reasonable I'll consider it. But please stop making misleading comments about C++ that ignore facts. As the bug I linked to shows, it didn't take years to agree on, it took 8 days.
Well, it's nice to ignore facts... Posted Aug 24, 2011 22:38 UTC (Wed) by jwakely (subscriber, #60262) [Link]
And if you're *only* talking about the Android NDK version of libstdc++, I don't see why it should take years to backport a simple fix from upstream.
Well, it's nice to ignore facts... Posted Sep 4, 2011 20:45 UTC (Sun) by cmccabe (guest, #60281) [Link]
Hi jwakely,
I did not mean to imply that the libstdc++ maintainers were slow. However, rollout of new libstdc++ versions can be quite delayed, as you know. Using shared_ptr without exceptions on older Android versions just isn't going to compile, and it would be misleading to suggest otherwise. That was what I was trying to avoid.
Just out of curiousity, are the -fno-rtti and -fno-exceptions modes part of any standard, or just something that GCC and a few other compilers implement?
P.S. as a former C++ user, thanks for all your work on libstdc++
Well, it's nice to ignore facts... Posted Sep 4, 2011 21:08 UTC (Sun) by jwakely (subscriber, #60262) [Link]
Sorry for misunderstanding then. The C++ standard includes RTTI and exceptions as part of the language. They're not optional, so disabling them takes you into non-standard territory (but still reasonably portable, as -fno-rtti or -fno-exceptions and their equivalents are quite common non-standard features.)
There is (or was) an "Embedded C++" dialect which omits RTTI and exceptions, among other features, but it's not a standard and as Stroustrup has said "To the best of my knowledge EC++ is dead (2004), and if it isn't it ought to be."
|
|||||||||||||