Apache C++ Standard Library

[Olivier Guilyardi]

Hi,

as anyone tried to use Apache's stdcxx ?
http://stdcxx.apache.org/

Any alternative?

I mainly need strings, containers and iterators.

Regards,

--
Olivier

--
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.

[andrej sarkic]

Do you need apache stdcxx specifically or just *an* implementation of
the standard library? There are at least two known implementations
that have been ported to Android:

http://www.crystax.net/android/ndk-r3.php

STLPort:
http://www.anddev.org/viewtopic.php?p=29939

On May 19, 2:23 pm, Olivier Guilyardi <l...@samalyse.com> wrote:
> Hi,
>

> as anyone tried to use Apache's stdcxx ?http://stdcxx.apache.org/

[Olivier Guilyardi]

On 05/19/2010 09:56 PM, andrej sarkic wrote:
> Do you need apache stdcxx specifically or just *an* implementation of
> the standard library? There are at least two known implementations
> that have been ported to Android:

I actually need any implementation, even minimal, but *stable*.

> http://www.crystax.net/android/ndk-r3.php

Oh yes, I read about this customized NDK many times, but the following is not
possible in my case: "Application built using this version could be potentially
broken when using on the next Android versions".

Do you think I could use Crystax's standard library with the official NDK?

> STLPort:
> http://www.anddev.org/viewtopic.php?p=29939

This looks interesting too.

However, I'm a bit worried about stability. For example, I have seen extremely
weird issues in pure C code, which I believe were caused by some bugs in Bionic
or so.

To be honest, I am not deeply excited about (very) fresh implementations of such
critical components as libc or libstdc++.

And I feel much better when I read "Ten years of deployment in the world's most
critical enterprise systems", on the stdcxx homepage.

I may give a try to the implementations you mention though.

Thank you for your answer and these pointers

[Dmitry Moskalchuk]

Hi,

My NDK distribution is not more in experimental stage. Read please more carefully - there is "Update 2" section where I inform that no more such problems. Application built with my distribution will not differ by ABI from those built with official NDK.

You can use _instead_ of official NDK. There are lot of peoples around who use it, just read this group.


Dmitry Moskalchuk

20.05.2010, в 0:32, Olivier Guilyardi написал(а):

[Olivier Guilyardi]

Hello Dmitry,

sorry I read too fast, but I didn't expect that what's being said on one line is
not true anymore in the next line ;-)

What you're saying is really encouraging. And if I was in the situation of
porting a large existing c++ program or library then I would say that your NDK
is a blessing.

But I'm not in this situation, I'm just trying to improve productivity with
powerful standard C++ features. Now, having spent many days of work on different
behaviors between Android versions, I became very doubtful about compatibility.

So, unless forced, I'm sorry but I want official tools from official Android devs.

Can any official developer confirm that Crystax NDK is ok for production and
forward compatibility?

Olivier

[appforce.org]

I'm not official Android developer, but I will say my opinion that
CrystaX's NDK is the best you could get at the moment. It is supported
and you have greater chance to have requested features added, rather
than relying on the official NDK. Of course you can get forward
compatibility assured only with official NDK. Another thing is that
forward compatibility is questioned with such rapid OS updates, even
for the official Java SDK.

> >> For more options, visit this group athttp://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.
> To unsubscribe from this group, send email to android-ndk...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/android-ndk?hl=en.

[Dmitry Moskalchuk]

Hi,

Of course, this is up to you - use my NDK distribution or not. The only
I want to draw attention is that actually I don't add code which is not
part of the official sources. I just enabled full C++ features which was
disabled in Google NDK. There is no my code in STL/exceptions/RTTI
support. This all - very well designed and tested implementation of GNU
C++ (which was tested on thousands, if not millions installations). So
think about this.

And one more moment. If you'll try to use 3d party STL implementation
with official NDK, it will not be fully standard compatible anyway.
Standard describes number of operations with STL containers which could
throw exceptions and this is the _only_ way to report about errors for
such operations (for example, vector::at). But in Google NDK exceptions
are not supported so 3d party implementation must workaround this either
changing public interface of such operations or silently ignore errors.
Both ways are not standard, of course. In my distribution it will work
_exactly_ as designed - with full STL, exceptions if needed and RTTI.

Dmitry Moskalchuk


20.05.2010 01:15, Olivier Guilyardi пишет:

[Olivier Guilyardi]

I understand what you're saying. This is a community supported NDK, great. It
has more features, cool.

Now, when a new Android version will be in the process of being released, which
NDK will be used during the testing stage to ensure backward compatibility?

Unless I'm wrong, this will be the official one, and no other.

And to some, not tested is the same as not working. I suppose that Crystax NDK
may get fixed very fast in case of trouble. But what about people who already
installed my app and get their firmware upgraded?

About compatibility problems with the official releases, yes I know, I've spent
a lot of time on this. And I don't feel like adding complications by going
unofficial.

But of course, I may change my mind ;-)

Olivier

[Olivier Guilyardi]

Hi Dmitry,

that's a good point, GNU libstdc++ provides the stability that I need.

About non-standard 3rd party STL, this is quite ok for me. For instance, the
STLPort mentioned by Andrej seems not to need RTTI and exceptions, which is ok
for me, especially if it works with the official NDK.

But if your NDK is working great, why aren't RTTI and exceptions enabled in the
official NDK?

Is it a licensing issue?

Olivier

[appforce.org]

Apache's stdcxx or STLport are not officially part of NDK either, so
if you want to stick to official NDK you should use only what's listed
in STABLE-APIS.TXT. That means you can use:

- standard C library (subset)
- pthread (subset)
- math.h
- logging
- Zlib
- OpenGL ES

You can't use:
- standard C++ library
- kernel calls
- exceptions
- RTTI

That's the official way of keeping your app forward compatible.

[Olivier Guilyardi]

No, to me staying official here means using the official compiling tools,
and doesn't prevent me from using any third party library. Any library which
compiles fine with the official NDK (and doesn't use private/hidden features)
should be ok, and satisfy forward compatibility, otherwise there is a bug in the
NDK, in my opinion.

And I actually use quite a lot of such third party libraries. I just wish that I
could find some kind of STL which behaves as such and compiles with the official
NDK.

Basically, I'm now even thinking about finding some other kind of library which
provides utilities similar to strings, lists, iterators and such, even if its
API is different from the STL, provided that it doesn't use RTTI and exceptions.

Olivier

[Dmitry Moskalchuk]

Hi,

> About non-standard 3rd party STL, this is quite ok for me. For instance, the
> STLPort mentioned by Andrej seems not to need RTTI and exceptions, which is ok
> for me, especially if it works with the official NDK.

Yes, I know, STLport on Android does not need exceptions. But that mean
it is not fully standard compatible. There is just no way to get fully
standard STL implementations without exceptions. I just looked how they
work around this in STLport - actually is not very good. They just abort
whole application in case if exception need to be thrown. Application
will crash and you could not even catch it.

> But if your NDK is working great, why aren't RTTI and exceptions enabled in the
> official NDK?
>
> Is it a licensing issue?

Well, this is a question to Android team. As David Turner said, it was
done due to historical reasons, meaning that GCC generate bad code for
exceptions when Android project has started. Now GCC has one of the best
C++ implementation but they are not yet ready to include this to the
mainstream. Nevertheless, some time ago David promised full C++ will be
included to the one of the future NDK releases and, citation, "result is
likely to be very similar to Dmitry's patches"
(http://groups.google.com/group/android-ndk/msg/070787784e399ea6).

Dmitry Moskalchuk


20.05.2010 15:51, Olivier Guilyardi пишет:

[appforce.org]

That probably leaves you with STLport as only option, other famous
open source implementations require RTTI and exceptions (even uClibc+
+). STLport is the oldest and most community-tested option I believe.

[Olivier Guilyardi]

Hi,

On 05/20/2010 02:20 PM, Dmitry Moskalchuk wrote:

At least, top-posting time is over :-)

>> About non-standard 3rd party STL, this is quite ok for me. For
>> instance, the
>> STLPort mentioned by Andrej seems not to need RTTI and exceptions,
>> which is ok
>> for me, especially if it works with the official NDK.
>
> Yes, I know, STLport on Android does not need exceptions. But that mean
> it is not fully standard compatible. There is just no way to get fully
> standard STL implementations without exceptions. I just looked how they
> work around this in STLport - actually is not very good. They just abort
> whole application in case if exception need to be thrown. Application
> will crash and you could not even catch it.

That's not a problem to me, because I can make sure that my code runs fine on
x86, with standard Linux gcc and libstdc++. This way I can squash bugs with gdb,
leaks with valgrind, etc.... Then I compile with the NDK. I am actually already
doing this in C with great success. That's very productive.

But for this method to be more real-world-like, the best would be to compile
with Bionic x86 instead of the GNU libc on my Linux machine. That would be very
cool. Is this feasible?

>> But if your NDK is working great, why aren't RTTI and exceptions
>> enabled in the
>> official NDK?
>>
>> Is it a licensing issue?
>
> Well, this is a question to Android team. As David Turner said, it was
> done due to historical reasons, meaning that GCC generate bad code for
> exceptions when Android project has started. Now GCC has one of the best
> C++ implementation but they are not yet ready to include this to the
> mainstream. Nevertheless, some time ago David promised full C++ will be
> included to the one of the future NDK releases and, citation, "result is
> likely to be very similar to Dmitry's patches"
> (http://groups.google.com/group/android-ndk/msg/070787784e399ea6).

Great pointer thanks. This is the other point I was worried about: "the GNU
libstdc++ is really *huge* when linked statically". If I understand correctly,
even when it's included mainstream it won't be possible to use it as a shared
library, for backward compatibility...

Then this uSTL mentioned by David looks very interesting, and it's even MIT
licensed. Maybe that I could hack that one to disable exceptions.

Anyway, your work look really good Dmitry and I might take a deeper look at your
NDK in the future. Thanks for all these informations.

[Olivier Guilyardi]

Okay, that's quite an answer to my original question. Thank you.

Olivier

[Dmitry Moskalchuk]

> That's not a problem to me, because I can make sure that my code runs fine on
> x86, with standard Linux gcc and libstdc++. This way I can squash bugs with gdb,
> leaks with valgrind, etc.... Then I compile with the NDK. I am actually already
> doing this in C with great success. That's very productive.
>
> But for this method to be more real-world-like, the best would be to compile
> with Bionic x86 instead of the GNU libc on my Linux machine. That would be very
> cool. Is this feasible?
>

Yes, I know there is project Android-x86 but I have no tried it yet so
can not say anything regarding it. Sorry.

> Great pointer thanks. This is the other point I was worried about: "the GNU
> libstdc++ is really *huge* when linked statically". If I understand correctly,
> even when it's included mainstream it won't be possible to use it as a shared
> library, for backward compatibility...
>

Yes, you are right but you forgot that GNU linker is not so dumb and can
throw away unreferenced staff. Therefore, if you will use STL only (no
iostreams), libstdc++ itself will not be compiled into final binary.

[Olivier Guilyardi]

On 05/20/2010 03:15 PM, Dmitry Moskalchuk wrote:
>
>> That's not a problem to me, because I can make sure that my code runs
>> fine on
>> x86, with standard Linux gcc and libstdc++. This way I can squash bugs
>> with gdb,
>> leaks with valgrind, etc.... Then I compile with the NDK. I am
>> actually already
>> doing this in C with great success. That's very productive.
>>
>> But for this method to be more real-world-like, the best would be to
>> compile
>> with Bionic x86 instead of the GNU libc on my Linux machine. That
>> would be very
>> cool. Is this feasible?
>>
> Yes, I know there is project Android-x86 but I have no tried it yet so
> can not say anything regarding it. Sorry.

I would only need Bionic (and dependencies?) I think, not Dalvik, etc..
IIRC, I saw a x86 version of Bionic in Git. Any information about this would be
greatly appreciated. I have never tried to use an alternative libc with gcc on
my Debian system.

>
>> Great pointer thanks. This is the other point I was worried about:
>> "the GNU
>> libstdc++ is really *huge* when linked statically". If I understand
>> correctly,
>> even when it's included mainstream it won't be possible to use it as a
>> shared
>> library, for backward compatibility...
>>
> Yes, you are right but you forgot that GNU linker is not so dumb and can
> throw away unreferenced staff. Therefore, if you will use STL only (no
> iostreams), libstdc++ itself will not be compiled into final binary.

Very important detail, thanks.

>
>> Then this uSTL mentioned by David looks very interesting, and it's
>> even MIT
>> licensed. Maybe that I could hack that one to disable exceptions.

Actually, (sort of) already done:
http://groups.google.com/group/android-ndk/msg/86b7e37e096b680b

There also seem to be a (clean) exception-free uSTL in eCos OS:
http://ecos.sourceware.org/docs-latest/ref/ustl-overview.html

But STLport looks like the most straightforward in my current case.

Thanks

[andrej sarkic]

I had a similar decision to make as Olivier. I chose Dmitry's NDK with
the gcc libstdc++, for all the reasons stated in this thread. It's
stable, community supported, I can understand the changes, it's fully
standard compliant, and it's ABI safe. True, the binary size is large,
but I figure if and when the official NDK comes out with a version
that supports dynamic linking to lidstdc++, or another implementation
that is smaller and/or more efficient, I can make the choice whether I
want to rebuild and move to that.

I think it's the best choice today.

I did try STLPort, and it works, but in a few cases deviates from the
standard enough that I would have had to conditionally change my
code.

Thanks,
Andrej

[Olivier Guilyardi]

And what about uSTL?

The more I look at it, the more it looks cute to me. I love all these "Bloat
gone" in the documentation ;-)

Whether on Android or not, does anybody have any experience with it and its
compliance with standards?

I also suppose Dmitry's NDK could provide optional uSTL support.

Olivier

[David Turner]

On Wed, May 19, 2010 at 1:42 PM, Dmitry Moskalchuk <cry...@gmail.com> wrote:

Hi,

My NDK distribution is not more in experimental stage. Read please more carefully - there is "Update 2" section where I inform that no more such problems. Application built with my distribution will not differ by ABI from those built with official NDK.

*cough* *cough*, as much as I would like that to be true, I do not guarantee it 100% at the moment (and I'm the official Android NDK designer/maintainer). Let's say 95% though.

I still encourage anyone to use Crystax's NDK if you want to use the features it provides, it is by far the best thing to use at the moment.

The worst that can happen is that some of the code does not run on a future platform release (for example one that provides better native support for C++ and RTTI, or built with a different toolchain). However, if such a thing would happen, I would ensure there is a backup solution for you to rebuild your source code, unmodified, so that the corresponding machine code runs on all platforms anyway.

By the way, Android NDK r4 is out :-)

http://developer.android.com/sdk/ndk/index.html

[David Turner]

On Thu, May 20, 2010 at 4:51 AM, Olivier Guilyardi <li...@samalyse.com> wrote:

Hi Dmitry,

that's a good point, GNU libstdc++ provides the stability that I need.

About non-standard 3rd party STL, this is quite ok for me. For instance, the
STLPort mentioned by Andrej seems not to need RTTI and exceptions, which is ok
for me, especially if it works with the official NDK.

But if your NDK is working great, why aren't RTTI and exceptions enabled in the
official NDK?

Is it a licensing issue?

No, it's not a licensing issue at all. It is due to the state of the Android toolchain when the project was started,

and the fact that there are plenty of horrifying details to get right, and require careful review of the relevant specs.

Exceptions and RTTI are not enabled in the system because they are not needed by the Android system libraries

(by design) and would bloat the generated code needlessly (not a good thing on an embedded system).

We never meant applications to not be able to use them, but it's not high on our priority list.

[David Turner]

On Thu, May 20, 2010 at 5:06 AM, appforce.org <ogi.a...@gmail.com> wrote:

Apache's stdcxx or STLport are not officially part of NDK either, so
if you want to stick to official NDK you should use only what's listed
in STABLE-APIS.TXT. That means you can use:

- standard C library (subset)
- pthread (subset)
- math.h
- logging
- Zlib
- OpenGL ES

You can't use:
- standard C++ library
- kernel calls
- exceptions
- RTTI

That's the official way of keeping your app forward compatible.

You can use these as long as you put their implementation in your own native code.

The thing is, you can't rely on unexposed system libraries to do that kind of thing for you.

That's what happens with Crystax's NDK (and other STL ports).

system calls are a bit special. If one is missing from the C library, it's generally an omission but

the kernel would support it (unless it's a very platform-specific thing like the ARM flush cache stuff

and other things like that).

[Olivier Guilyardi]

On 05/20/2010 07:24 PM, David Turner wrote:
>
>
> On Wed, May 19, 2010 at 1:42 PM, Dmitry Moskalchuk <cry...@gmail.com
> <mailto:cry...@gmail.com>> wrote:
>
> My NDK distribution is not more in experimental stage. Read please
> more carefully - there is "Update 2" section where I inform that no
> more such problems. Application built with my distribution will not
> differ by ABI from those built with official NDK.
>
> *cough* *cough*, as much as I would like that to be true, I do not
> guarantee it 100% at the moment (and I'm the official Android NDK
> designer/maintainer). Let's say 95% though.
>
> I still encourage anyone to use Crystax's NDK if you want to use the
> features it provides, it is by far the best thing to use at the moment.
>
> The worst that can happen is that some of the code does not run on a
> future platform release (for example one that provides better native
> support for C++ and RTTI, or built with a different toolchain). However,
> if such a thing would happen, I would ensure there is a backup solution
> for you to rebuild your source code, unmodified, so that the
> corresponding machine code runs on all platforms anyway.

Okay, thanks for clarifications.

> By the way, Android NDK r4 is out :-)
>
> http://developer.android.com/sdk/ndk/index.html

Wow, that looks great :-) I have to check this ndk-gdb, and give a try to the
FPU support with my FFT code.

About FPU:
- will this work on many devices, like... 90%?
- can I still target android-3?

[David Turner]

It will work on devices that have an ARMv7-A CPU (Droid and N1 for example, I suspect the Desire and Incredible as well).

You can easily build for both ABIs at the same time if you want 100% coverage.

 

- can I still target android-3?

Yes, of course.

 

--
 Olivier

--
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.

[Olivier Guilyardi]

On 05/20/2010 10:20 PM, David Turner wrote:
>
>
> On Thu, May 20, 2010 at 12:31 PM, Olivier Guilyardi <li...@samalyse.com

> <mailto:li...@samalyse.com>> wrote:

[...]

> > By the way, Android NDK r4 is out :-)
> >
> > http://developer.android.com/sdk/ndk/index.html
>
> Wow, that looks great :-) I have to check this ndk-gdb, and give a
> try to the
> FPU support with my FFT code.
>
> About FPU:
> - will this work on many devices, like... 90%?
>
>
> It will work on devices that have an ARMv7-A CPU (Droid and N1 for
> example, I suspect the Desire and Incredible as well).
> You can easily build for both ABIs at the same time if you want 100%
> coverage.
>
>
> - can I still target android-3?
>
> Yes, of course.

Okay, cool, then I may provide conditional features to people who have a
supported CPU, as I see that you made that possible.

Thanks

[David Turner]

On Thu, May 20, 2010 at 2:02 PM, Olivier Guilyardi <li...@samalyse.com> wrote:

On 05/20/2010 10:20 PM, David Turner wrote:
>
>
> On Thu, May 20, 2010 at 12:31 PM, Olivier Guilyardi <li...@samalyse.com

> <mailto:li...@samalyse.com>> wrote:

[...]

>     > By the way, Android NDK r4 is out :-)
>     >
>     > http://developer.android.com/sdk/ndk/index.html
>
>     Wow, that looks great :-) I have to check this ndk-gdb, and give a
>     try to the
>     FPU support with my FFT code.
>
>     About FPU:
>     - will this work on many devices, like... 90%?
>
>
> It will work on devices that have an ARMv7-A CPU (Droid and N1 for
> example, I suspect the Desire and Incredible as well).
> You can easily build for both ABIs at the same time if you want 100%
> coverage.
>
>
>     - can I still target android-3?
>
> Yes, of course.

Okay, cool, then I may provide conditional features to people who have a
supported CPU, as I see that you made that possible.

the thing is, if you .apk contains an armeabi-v7a binary, and no armeabi, then Market will not list

your application on armeabi devices. See docs/CPU-ARCH-ABIS.TXT for a detail of how filtering

works.

 

Thanks

--
 Olivier


--
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.