Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

C++11 standard library support enabled on all Tier-1 platforms

74 views
Skip to first unread message

Nathan Froyd

unread,
May 26, 2016, 9:51:02 PM5/26/16
to dev-platform, dev-fxos, mobile-fi...@mozilla.org
[CC mobile-firefox-dev and dev-fxos for notes below.]

Bug 1246743 (Mac libc++ support) and bug 1273934 (Android libc++
support for local development builds) have landed on mozilla-central.
This change means that all of our Tier-1 platforms now have a
more-or-less conformant C++11 standard library. We can therefore
begin removing a decent amount of code that we required to support
pre-C++11 standard libraries and use standard facilities instead. You
are still strongly encouraged to use Gecko-specific data structures
(nsTArray ns{C,}String, etc.) in preference to the standard library
ones, unless you need to interface with a third-party library.

Given the standard library's pervasive use of exceptions, and our
aversion to the same, if you are using a standard library header
that's not listed here:

http://dxr.mozilla.org/mozilla-central/source/config/stl-headers

you need to ask for review to get that header added to the list, per
policy in that file.

This change also means that any non-Tier-1 platforms (FxOS, for
instance) that don't provide a C++11 standard library will probably
break in very short order as various code is removed from the tree.

Developers who work on the C++ side of Firefox for Android are
strongly encouraged to upgrade to an r11 NDK; the r10 NDK should work,
but test results in the presence of crashes might be slightly wonky.

Enjoy!
-Nathan

Mike Hommey

unread,
May 26, 2016, 10:09:33 PM5/26/16
to Nathan Froyd, dev-platform, dev-fxos, mobile-fi...@mozilla.org
On Thu, May 26, 2016 at 09:50:56PM -0400, Nathan Froyd wrote:
> This change also means that any non-Tier-1 platforms (FxOS, for
> instance) that don't provide a C++11 standard library will probably
> break in very short order as various code is removed from the tree.

When do we actively remove support for stlport (which b2g still uses,
and which is still an option of --with-android-cxx-stl)?

Mike

Kurt Roeckx

unread,
May 27, 2016, 6:34:05 AM5/27/16
to
On 2016-05-27 03:50, Nathan Froyd wrote:
> Given the standard library's pervasive use of exceptions, and our
> aversion to the same, if you are using a standard library header
> that's not listed here:

Are there plans to start using C++ exception? The wiki seems to suggest
there are plans, but it was last modified in 2008.


Kurt


Josh Matthews

unread,
May 27, 2016, 8:24:56 AM5/27/16
to
Do we have any automation that prevents using headers that aren't in the
list?

Cheers,
Josh

Nathan Froyd

unread,
May 27, 2016, 9:48:30 AM5/27/16
to Mike Hommey, dev-platform, dev-fxos, mobile-fi...@mozilla.org
On Thu, May 26, 2016 at 10:08 PM, Mike Hommey <m...@glandium.org> wrote:
> On Thu, May 26, 2016 at 09:50:56PM -0400, Nathan Froyd wrote:
>> This change also means that any non-Tier-1 platforms (FxOS, for
>> instance) that don't provide a C++11 standard library will probably
>> break in very short order as various code is removed from the tree.
>
> When do we actively remove support for stlport (which b2g still uses,
> and which is still an option of --with-android-cxx-stl)?

"Soon"? I'll probably do this next week.

-Nathan

Benjamin Smedberg

unread,
May 27, 2016, 9:57:13 AM5/27/16
to Josh Matthews, dev-platform
It used to be that using STL headers not in the approved list would fail to
compile. I don't know whether that mechanism is still turned on or works
correctly.

--BDS

On Fri, May 27, 2016 at 8:24 AM, Josh Matthews <jo...@joshmatthews.net>
wrote:
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

Nathan Froyd

unread,
May 27, 2016, 10:02:33 AM5/27/16
to Kurt Roeckx, dev-platform
There was a discussion about this topic recently that I thought was on
dev-platform, but some searching doesn't turn it up. The consensus I
remember was that was it was semi-desirable, but auditing all of the
existing code for exception safety was a long, tedious task. We'd
have to see what the size and runtime penalties looked like as well.

I don't think anybody's planning on tackling this anytime soon.

-Nathan
0 new messages