Clearance on C++11 Features?

[Yuta Kitamura]

Hi all,

After we updated the default compiler on Linux to Clang, we are in a state that we can technically use C++11 features. However, we haven't declared a clearance on using C++11 features yet, if I recall correctly.

Despite of that, we already have some code using C++11 features (such as enum-class style access for regular enums, and unordered_map<>) as I showed in the last email thread, intentionally or not, without a clear consensus on their uses.

I believe people are using these features with a good intention, but the use of C++11 features without coordination sounds a little bit risky for the whole project. Many people are not very seasoned on C++11 features, I assume (including me), so I'd like to see a clear guidance on these features, in addition to the set of allowed C++11 features (either whitelist or blacklist), before we get too much code that depends on C++11 features inadvertently.

Unfortunately I'm not the right person to make the call, as I don't know much about C++11 features and cross-compiler compatibility, but I'm sure some folks in this list are. WDYT?

Thanks,

Yuta

[Anthony Berent]

My understanding is that, until recently at least, the Android C++ standard library didn't support C++11. Does anybody know if this has been fixed?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Victor Khimenko]

On Mon, Aug 18, 2014 at 12:17 PM, Yuta Kitamura <yu...@chromium.org> wrote:

Hi all,

After we updated the default compiler on Linux to Clang, we are in a state that we can technically use C++11 features. However, we haven't declared a clearance on using C++11 features yet, if I recall correctly.

Despite of that, we already have some code using C++11 features (such as enum-class style access for regular enums, and unordered_map<>) as I showed in the last email thread, intentionally or not, without a clear consensus on their uses.

I believe people are using these features with a good intention, but the use of C++11 features without coordination sounds a little bit risky for the whole project. Many people are not very seasoned on C++11 features, I assume (including me), so I'd like to see a clear guidance on these features, in addition to the set of allowed C++11 features (either whitelist or blacklist), before we get too much code that depends on C++11 features inadvertently.

List is in the style guide:

  http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#C++11

It's blacklist:

C++11 features may be used unless specified otherwise. In addition to what's described in the rest of the style guide, the following C++11 features may not be used:

• Functions with trailing return types, e.g. writing auto foo() -> int; instead of int foo();, because of a desire to preserve stylistic consistency with the many existing function declarations.

• Compile-time rational numbers (<ratio>), because of concerns that it's tied to a more template-heavy interface style.

• The <cfenv> and <fenv.h> headers, because many compilers do not support those features reliably.

• Lambda expressions, or the related std::function or std::bind utilities.

Unfortunately I'm not the right person to make the call, as I don't know much about C++11 features and cross-compiler compatibility, but I'm sure some folks in this list are. WDYT?

Thanks,

Yuta

--

[Daniel Cheng]

The Chromium C++ guide [http://www.chromium.org/developers/coding-style#TOC-C-11] has a brief stanza that "chromium does not yet allow most C++11 features" but doesn't really detail what those are.

However, I do recall that 'auto' was (is?) being used on Mac, once we built with a modern-enough clang. It appears a few Windows-specific files use the auto keyword as well now (win8/metro_driver/metro_driver.cc, win8/metro_driver/metro_driver_win7.cc), soo it might be useful to clarify what is/isn't allowed on that page.

Daniel

[Alex Vakulenko]

By the way. the style guide published at http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml (revision 3.274) is at least a couple revisions behind the official Google C++ Style Guide (https://engdoc.corp.google.com/eng/doc/devguide/cpp/styleguide.shtml?cl=head), revision 3.276, which allows a lot more C++11 features including lambdas and std::function with std::bind and rvalue references in move constructors.

I think we should update the Chromium C++ guide to be in line with the rest of the Google and use their experience when deciding on which features to allow or disallow...

[Nico Weber]

On Mon, Aug 18, 2014 at 1:17 AM, Yuta Kitamura <yu...@chromium.org> wrote:

Hi all,

After we updated the default compiler on Linux to Clang, we are in a state that we can technically use C++11 features.

No, things still aren't quite ready. (Some of the code is built with the nacl compiler, which is currently gcc 4.4. And the AOSP bot's host compiler is currently gcc 4.2.) I'll notify the list once things are ready.

 

However, we haven't declared a clearance on using C++11 features yet, if I recall correctly.

Despite of that, we already have some code using C++11 features (such as enum-class style access for regular enums, and unordered_map<>) as I showed in the last email thread, intentionally or not, without a clear consensus on their uses.

enum-class style enums will be work relatively soon, as it's a language feature. This just requires that all our compilers are new enough. This isn't quite the case yet, but we're pretty close.

unordered_map<> won't work, as it's a library feature. While there are plans for getting c++11 library support, this requires much more work. We're going to have access to language features way before we have access to library features. (See the various earlier c++11 threads on this list.)

Nico

[Nico Weber]

On Mon, Aug 18, 2014 at 2:17 AM, Daniel Cheng <dch...@chromium.org> wrote:

The Chromium C++ guide [http://www.chromium.org/developers/coding-style#TOC-C-11] has a brief stanza that "chromium does not yet allow most C++11 features" but doesn't really detail what those are.

However, I do recall that 'auto' was (is?) being used on Mac, once we built with a modern-enough clang. It appears a few Windows-specific files use the auto keyword as well now (win8/metro_driver/metro_driver.cc, win8/metro_driver/metro_driver_win7.cc), soo it might be useful to clarify what is/isn't allowed on that page.

Don't use C++11 features yet.

[Carlos Pizano]

Yes please don't use C++11 yet. The metro code is a special case because has no chance in hell being multi-platform and the sdk headers it uses use C++11 extensively.

[Robert Knight]

Hello,

Can anyone provide background on the rationale for the lambda rule? That was added some time ago to the style guide but I wondered whether thinking on the matter has changed within Google since then.

[Victor Khimenko]

On Thu, Aug 21, 2014 at 7:51 PM, Robert Knight <robert...@gmail.com> wrote:

Hello,

Can anyone provide background on the rationale for the lambda rule? That was added some time ago to the style guide but I wondered whether thinking on the matter has changed within Google since then.

Thinking withing Google most definitely have changed. Revision 3.276 of the style guide (not yet published externally AFAICS) now says something drastically different about lambdas:

-- cut --

Lambda expressions

Use lambda expressions where appropriate. Do not use default lambda captures; write all captures explicitly.

-- cut --

I think it's related to problems with lambda implementations in certain compilers.

On Monday, 18 August 2014 09:18:33 UTC+1, Yuta Kitamura wrote:

Hi all,

After we updated the default compiler on Linux to Clang, we are in a state that we can technically use C++11 features. However, we haven't declared a clearance on using C++11 features yet, if I recall correctly.

Despite of that, we already have some code using C++11 features (such as enum-class style access for regular enums, and unordered_map<>) as I showed in the last email thread, intentionally or not, without a clear consensus on their uses.

I believe people are using these features with a good intention, but the use of C++11 features without coordination sounds a little bit risky for the whole project. Many people are not very seasoned on C++11 features, I assume (including me), so I'd like to see a clear guidance on these features, in addition to the set of allowed C++11 features (either whitelist or blacklist), before we get too much code that depends on C++11 features inadvertently.

Unfortunately I'm not the right person to make the call, as I don't know much about C++11 features and cross-compiler compatibility, but I'm sure some folks in this list are. WDYT?

Thanks,

Yuta

--