--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en.
On Nov 9, 2:26 am, Anton Persson <don.juan...@gmail.com> wrote:Any code across which an exception can be thrown must be able to clean
> How would c++ exception support slow down C applications?
up after itself. If a bit of C code is bracketed by C++ code that
throws and catches, and the C code calls malloc()/free() for a
temporary allocation, a memory leak is possible. You have to write
everything with either the understanding that exceptions can't cross
over you, or understanding that they can happen and you may have to
handle cleanup by other means.
The exception-enabled code generated for ARM by gcc was unacceptable
when we first started on Android, so we built the system without it,
and I don't think anybody has really missed it.
OTOH, I don't think
anybody has evaluated the size and performance costs in a while. If
you wanted to make a case for exceptions, hard numbers on core/
external libraries would be a good place to start.
--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To post to this group, send email to andro...@googlegroups.com.
for our project I've written few simple classes to derive from
and supporting stuff.
I published this as unwind.cpp & unwind.h in the group files.
Tested under MS VS 2005 & NDK 1.6.
This is single thread version, you may enhance it yourself via ex:TLS
or pthreads keys.
There are some restrictions, derived classes may not be allocated via
NEW operator or created as a class-member, only stack variable.
But this is enough for mutex handling, ref-countering, auto-ptrs etc.
Use as :
----------------------
TRY_BLOCK {
}
CATCH_BLOCK_FIN
{
std::cerr << exc;
}
FIN_BLOCK;
Regards,
Boris
I've built my own version of android ndk which support full C++
standard library (including STL), exceptions and RTTI. I did it using
official ndk build scripts and sources, just little patched them.
Actually I was wonder how easy it was. I've used exceptions in massive
piece of code which I have now ported to android (libstdc++ linked
statically) and seems all works fine.
Only linux and darwin variants ready for now -
http://www.crystax.net/data/android-ndk-1.6_r1-linux-x86-crystax.tar.bz2,
http://www.crystax.net/data/android-ndk-1.6_r1-darwin-x86-crystax.tar.bz2.
Diff I've created to build customized ndk -
http://www.crystax.net/data/android-ndk-1.6_r1-crystax.diff.
Hope it would help to you guys :)
This is obviously a big deal for C++ developers, especially adding
support for exceptions which is otherwise pretty tricky to work-
around.
I haven't tried this yet, but by the look of the diff it doesn't look
like a big change.
Question to NDK maintainers: would it be possible to support this
build in the next release?
Presumably it would be possible to make a single ndk build that does
exactly what the current ndk build does at the moment (i.e. no
overhead for supporting exceptions as previously mentioned), and only
adds full C++ support when enabled via compiler flags? (maybe that is
what Dmitry's build already does?).
Hywel.
On Jan 29, 1:03 am, Dmitry Moskalchuk <crys...@gmail.com> wrote:
> Hi all,
>
> I've built my own version of android ndk which support full C++
> standard library (including STL), exceptions and RTTI. I did it using
> official ndk build scripts and sources, just little patched them.
> Actually I was wonder how easy it was. I've used exceptions in massive
> piece of code which I have now ported to android (libstdc++ linked
> statically) and seems all works fine.
> Only linux and darwin variants ready for now -http://www.crystax.net/data/android-ndk-1.6_r1-linux-x86-crystax.tar.bz2,http://www.crystax.net/data/android-ndk-1.6_r1-darwin-x86-crystax.tar....
> Diff I've created to build customized ndk -http://www.crystax.net/data/android-ndk-1.6_r1-crystax.diff.
Just want to inform that windows build is also done - http://www.crystax.net/data/android-ndk-1.6_r1-windows-crystax.zip
Dmitry Moskalchuk
01.02.2010, в 13:13, Hywel написал(а):
> --
> You received this message because you are subscribed to the Google
> Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com.
> To unsubscribe from this group, send email to android-ndk...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/android-ndk?hl=en
> .
>
Congratulations Dmitry!
This is obviously a big deal for C++ developers, especially adding
support for exceptions which is otherwise pretty tricky to work-
around.
I haven't tried this yet, but by the look of the diff it doesn't look
like a big change.
Question to NDK maintainers: would it be possible to support this
build in the next release?
Presumably it would be possible to make a single ndk build that does
exactly what the current ndk build does at the moment (i.e. no
overhead for supporting exceptions as previously mentioned), and only
adds full C++ support when enabled via compiler flags? (maybe that is
what Dmitry's build already does?).
My general impression though is that many helper functions need to be provided by the systemto have things to work correctly. I'd be glad if this was not the case.
Hi David,I really would like to get feedback about my attempt - there of course could be problems I've not seen yet even after using my code with exceptions and STL on android. Tests can only find problems if they exists but can not assert there are no more them.These nasty things you've mentioned - could you explain more detailed? I'm very concerned to know them - quality of my code will depend on that.My general impression though is that many helper functions need to be provided by the systemto have things to work correctly. I'd be glad if this was not the case.As I know, GCC uses table approach to handle exceptions which means it has no runtime overhead in case if exception was not thrown. No exception setup code at start/finish of each frame. The only overhead is little bit larger data segment size. Also there are no hardware-specific bindings in exception support code because GCC supports too much hardware platform to allow this. Please correct me if I'm wrong.
Hi David,I really would like to get feedback about my attempt - there of course could be problems I've not seen yet even after using my code with exceptions and STL on android. Tests can only find problems if they exists but can not assert there are no more them.These nasty things you've mentioned - could you explain more detailed? I'm very concerned to know them - quality of my code will depend on that.
My general impression though is that many helper functions need to be provided by the systemto have things to work correctly. I'd be glad if this was not the case.As I know, GCC uses table approach to handle exceptions which means it has no runtime overhead in case if exception was not thrown. No exception setup code at start/finish of each frame. The only overhead is little bit larger data segment size. Also there are no hardware-specific bindings in exception support code because GCC supports too much hardware platform to allow this. Please correct me if I'm wrong.
Dmitry Moskalchuk
>> <mailto:crys...@gmail.com>> wrote:
>> > Hi all,
>> >
>> > I've built my own version of android ndk which support full C++
>> > standard library (including STL), exceptions and RTTI. I
>> did it using
>> > official ndk build scripts and sources, just little patched
>> them.
>> > Actually I was wonder how easy it was. I've used exceptions
>> in massive
>> > piece of code which I have now ported to android (libstdc++
>> linked
>> > statically) and seems all works fine.
>> > Only linux and darwin variants ready for now
>> -http://www.crystax.net/data/android-ndk-1.6_r1-linux-x86-crystax.tar.bz2,http://www.crystax.net/data/android-ndk-1.6_r1-darwin-x86-crystax.tar....
>> > Diff I've created to build customized ndk
>> -http://www.crystax.net/data/android-ndk-1.6_r1-crystax.diff.
>> > Hope it would help to you guys :)
>> >
>> > On Jan 5, 11:26 am, zzeng <zz...@mail.ru
>> <mailto:andro...@googlegroups.com>.
>> To unsubscribe from this group, send email to
>> android-ndk...@googlegroups.com
>> <mailto:android-ndk%2Bunsu...@googlegroups.com>.
>> For more options, visit this group at
>> http://groups.google.com/group/android-ndk?hl=en.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the
>> Google Groups "android-ndk" group.
>> To post to this group, send email to andro...@googlegroups.com
>> <mailto:andro...@googlegroups.com>.
>> To unsubscribe from this group, send email to
>> android-ndk...@googlegroups.com
>> <mailto:android-ndk...@googlegroups.com>.
>> For more options, visit this group at
>> http://groups.google.com/group/android-ndk?hl=en.
>
> --
> You received this message because you are subscribed to the Google
> Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com
> <mailto:andro...@googlegroups.com>.
> To unsubscribe from this group, send email to
> android-ndk...@googlegroups.com
> <mailto:android-ndk%2Bunsu...@googlegroups.com>.
This doesn't conclude any thing. Can we get a more conclusive answer
on this, 'not possible without system support' or 'static linking with
libstdc++' is going to work'. While we look for NDK team to release
its next version with full C++ support, we are looking for
intermediate solutions provided in this group (like stlport ..., which
seemed to work properly). I am not sure if i can rely on the above or
avoid it?
Thanks and regards,
KKK
On Feb 1, 11:48 pm, David Turner <di...@android.com> wrote:
> >http://www.crystax.net/data/android-ndk-1.6_r1-linux-x86-crystax.tar......
> > android-ndk...@googlegroups.com<android-ndk%2Bunsubscribe@googlegr oups.com>
"My general impression though is that many helper functions need toThis doesn't conclude any thing. Can we get a more conclusive answer
be
provided by the system
to have things to work correctly. I'd be glad if this was not the
case"
on this, 'not possible without system support' or 'static linking with
libstdc++' is going to work'. While we look for NDK team to release
its next version with full C++ support, we are looking for
intermediate solutions provided in this group (like stlport ..., which
seemed to work properly). I am not sure if i can rely on the above or
avoid it?
To unsubscribe from this group, send email to android-ndk...@googlegroups.com.
KKK.
On Feb 10, 7:09 am, David Turner <di...@android.com> wrote:
> To be more precise, if you have a solution that works 100% reliably on
> currently
> deployed Android devices, and only use the stable ABIs exposed by the NDK,
> the chances that a platform update will break it are pretty slim (because
> all the
> code required would have been statically linked to your executable).
>
> It's really people trying to link to non-stable libraries that worry me the
> most.
>
> What I'm concerned about the proposed solution is that it may not work
> correctly
> in a few corner cases (and I'm not saying this is the case, just that I'm
> not confident
> enough to guarantee it, otherwise I would gladly integrate this into the NDK
> itself).
>
> If you use it and that it works for you, in the limits of the NDK, please go
> for it.
>
>
>
> On Tue, Feb 9, 2010 at 6:06 PM, David Turner <di...@android.com> wrote:
>