| |||||||||||||
Well, it's nice to ignore facts...Well, it's nice to ignore facts...Posted Aug 21, 2011 15:26 UTC (Sun) by endecotp (guest, #36428)In reply to: Well, it's nice to ignore facts... by alankila Parent article: HP dropping webOS devices
> sometimes a new texture must be uploaded to the GPU, and it must
> be done from the rendering thread, because [on Android] it has the > only OpenGL context!
My understanding is that in principle you can have multiple OpenGL contexts on Android, but in practice (according to gurus on the Android forums) this is likely to be unreliable in practice due to implementation bugs. Since there are many different OpenGL implementations on Android - one per GPU vendor - you would need to do a lot of testing before trying to use this.
(This was one of several bad things that I discovered about Android when I experimented with it last year; another was that the debugger didn't work with multi-threaded programs. I was actually quite shocked by how poor at lot of it was once I poked below the surface. I believe some things have got better in the meantime.)
> On iOS there's also a slight pause in the animation during the
On iOS, you can definitely have multiple OpenGL contexts, one per thread, both in theory and in practice.
> objC was new to me, and xcode 4 is fairly buggy and crashes quite
Right, I agree. So does Apple, and they now have GC on Mac OS and "automatic reference counting" on iOS.
However, my suggestion would be to use C++ with smart pointers. This has the advantage of working on every platform that you might ever want to use - even WebOS! - but not Windows Mobile.
(Log in to post comments)
Well, it's nice to ignore facts... Posted Aug 21, 2011 16:16 UTC (Sun) by alankila (subscriber, #47141) [Link]
Thanks for swinging the cluebat. You seem to be right on the possibility for multiple GL contexts on iOS. They also say that android 3.0 and onwards should properly support this feature.
Well, it's nice to ignore facts... Posted Aug 22, 2011 1:52 UTC (Mon) by cmccabe (guest, #60281) [Link]
> (This was one of several bad things that I discovered about Android when I
> experimented with it last year; another was that the debugger didn't work > with multi-threaded programs. I was actually quite shocked by how poor at > lot of it was once I poked below the surface. I believe some things have > got better in the meantime.)
Multi-threaded debugging has always worked fine for pure Java code on Android. Debugging multi-threaded native code (aka NDK code, aka C/C++ code), is broken on Android 2.2 but it works on Android 2.3 and above.
> However, my suggestion would be to use C++ with smart pointers. This has
Um, it depends on what "every platform you might ever want to use" is. Neither C nor C++ are supported at all on Blackberry or Windows Phone 7.
Android supports C and C++ through the NDK. However, the older NDK kits do not support C++ exceptions. There are reports that some people have gotten exceptions to work with the older NDK by including glibc and libstdc++ in their application, but that increases the application size by many megabytes.
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.
There is this thing called Objective C++ that you can use on iOS if you want. However, that is not necessarily a good idea. Basically, Apple views Objective C as replacement for C++, and only supports Objective C++ for compatibility reasons.
Well, it's nice to ignore facts... Posted Aug 22, 2011 16:25 UTC (Mon) by endecotp (guest, #36428) [Link]
> Debugging multi-threaded native code (aka NDK code, aka C/C++
> code), is broken on Android 2.2 but it works on Android 2.3 and > above.
Right. I own 4 Android devices, and currently only one of them has >=2.3 available; that's my Galaxy Tab, and Samsung released the update just a few weeks ago. So on my other 3 devices I can still only do "printf-style" debugging. My Motorola Defy has only just got an update to 2.2!
It's actually even worse than that; on the 2.2 Galaxy Tab some vital symlink or somesuch was missing, which made even single-threaded native debugging impossible.
> the older NDK kits do not support C++ exceptions.
Right, that's one of the other surprising "bad things" that I was referring to. I was able to work around it by installing a hacked version of the tools from crystax.net.
> There is this thing called Objective C++ that you can use on
I'm very familiar with it :-)
> However, that is not necessarily a good idea. Basically, Apple views
"Citation Required".
Well, it's nice to ignore facts... Posted Aug 23, 2011 10:44 UTC (Tue) by jwakely (subscriber, #60262) [Link] 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)
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."
|
|||||||||||||