C++11 feature rollout

[Nico Weber]

Hi,

I believe all (*) our toolchains are now in a state where they understand C++11

language features. 

We won't want to use every single C++11 feature, just like we don't use every

available C++98 feature. Here's how it's going to work: There's a list of

C++11 features at http://chromium-cpp.appspot.com . At the moment, almost all

of them are marked as "to be discussed". A few are already pre-approved.

You can propose to make a feature available or to ban a feature by sending an

email to chromium-dev. Ideally include a short blurb on what the feature is,

and why you think it should or should not be allowed. Ideally, the list will

arrive at some consensus and the wiki page will be updated to mention that

consensus. If there's no consensus, src/styleguide/C++/OWNERS get to decide --

for divisive features, we expect the decision to be to not use the feature yet

and possibly discuss it again a few months later, when we have more experience

with the language.

Factors for allowing or banning a feature include:

* purely technical (for example, uniform initialization doesn't really

  make sense without std::initializer_list)

* the feature's complexity/convenience trade-off (for example, if you want to

  allow rvalue references, you should be able to make a convincing case that

  most chromium developers can explain the difference between std::move and

  std::forward)

So go ahead, propose your favorite feature :-) To get used to the process,

it's probably best to start with a simple feature like lowercase final/override.

Nico

*: Some conditions apply: Targets that have build_glibc or build_newlib set

to 1 don't work. The exhaustive list of these targets is currently gtest,

liblouis, libjingle, modp_b64. It's all third-party code, and not much.

ps: Thanks to all the folks who helped to make this happen: scottmg is

keeping us on a recent Visual Studio, dschuff and mseaborn got the nacl

IRT converted to use the pnacl compiler instead of an old gcc, torne and

primiano worked with Android build engineers to move the webview

build from an old gcc to a fairly new clang, pasko and fdegans are keeping

chrome/android's gcc up-to-date, the chromeos compiler team is doing the same

for chromeos, and lots of people helped to move the linux build and the

chrome/android and simplechrome chromeos host compilers to clang.  Thanks also

to hans for keeping our clang binaries up-to-date, the goma team for quickly

fixing various bugs triggered by all these changes, and to the clang and llvm

community for building a versatile compiler that supports modern language

features while still working with the libstdc++ that ships on precise.

[Peter Kasting]

On Tue, Sep 23, 2014 at 1:51 PM, Nico Weber <tha...@chromium.org> wrote:

You can propose to make a feature available or to ban a feature by sending an

email to chromium-dev. Ideally include a short blurb on what the feature is,

and why you think it should or should not be allowed. Ideally, the list will

arrive at some consensus and the wiki page will be updated to mention that

consensus. If there's no consensus, src/styleguide/C++/OWNERS get to decide --

for divisive features, we expect the decision to be to not use the feature yet

and possibly discuss it again a few months later, when we have more experience

with the language.

I'm concerned that this process doesn't seem to include anything about harmonizing with (or even learning lessons from) the Google styleguide's recommendations on C++11.  It seems like ultimately we ought to be in a place where our rules are "the Google styleguide, with a few tweaks/exceptions", like we do for most other style rules.

Perhaps the process to get there is multi-stage (e.g. we can't use any library features for a while yet), but at the very least I'd like to know if this is an intentional non-goal and if so why.  Otherwise, rather than discuss every feature, it seems like we should try to simply allow features that guide allows except where something exceptional is relevant.

PK

[William Chan (陈智昌)]

On Tue, Sep 23, 2014 at 1:58 PM, 'Peter Kasting' via blink-dev
<blin...@chromium.org> wrote:
> On Tue, Sep 23, 2014 at 1:51 PM, Nico Weber <tha...@chromium.org> wrote:
>>
>> You can propose to make a feature available or to ban a feature by sending
>> an
>> email to chromium-dev. Ideally include a short blurb on what the feature
>> is,
>> and why you think it should or should not be allowed. Ideally, the list
>> will
>> arrive at some consensus and the wiki page will be updated to mention that
>> consensus. If there's no consensus, src/styleguide/C++/OWNERS get to
>> decide --
>> for divisive features, we expect the decision to be to not use the feature
>> yet
>> and possibly discuss it again a few months later, when we have more
>> experience
>> with the language.
>
>
> I'm concerned that this process doesn't seem to include anything about
> harmonizing with (or even learning lessons from) the Google styleguide's
> recommendations on C++11. It seems like ultimately we ought to be in a
> place where our rules are "the Google styleguide, with a few
> tweaks/exceptions", like we do for most other style rules.

FWIW, the Google policy here is summed up as
(http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#C++11):

"""
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 (other than lambda 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.
Default lambda captures.

[James Robinson]

On Tue, Sep 23, 2014 at 1:58 PM, 'Peter Kasting' via blink-dev <blin...@chromium.org> wrote:

The Google style guide recommendations are based on a different set of toolchains than we use in Chromium.  For example, many C++11 library features are allowed in the Google style guide but are not supported in our toolchains.  As a result, we can't simply use the same features.

There are also a number of features that will be considered in comparison to equivalent or overlapping functionality that we have in the Chromium tree (like base::Bind to pick a somewhat obvious one).  We'll have to make decisions on these that will probably only apply to Chromium and not other repositories that have a different set of libraries available.

- James

PK

[Peter Kasting]

On Tue, Sep 23, 2014 at 2:06 PM, James Robinson <jam...@chromium.org> wrote:

The Google style guide recommendations are based on a different set of toolchains than we use in Chromium.  For example, many C++11 library features are allowed in the Google style guide but are not supported in our toolchains.  As a result, we can't simply use the same features.

Right, I tried to explicitly mention that as part of noting that clearly our initial guidelines can't look the same.  That doesn't mean we can't have "converge to the Google styleguide" as an eventual goal.

There are also a number of features that will be considered in comparison to equivalent or overlapping functionality that we have in the Chromium tree (like base::Bind to pick a somewhat obvious one).  We'll have to make decisions on these that will probably only apply to Chromium and not other repositories that have a different set of libraries available.

That seems more likely to apply to library features than language-only features.  It also seems like something that would lead to Chromium restricting a few more things than the Google styleguide does.  Which is fine, but there's no need in that case to ultimately discuss every feature individually.  We could start by: (1) banning/allowing all language-only features to match what the Google styleguide does, then (2) when library features come up, do the same thing, except reserve for explicit discussion all features whose functionality overlaps with some part of the Chromium codebase.

This would not only be simpler and faster than trying to discuss every single feature, it would make clear that, philosophically, our goal with C++11 is the same as our goal with all other aspects of our styleguide, namely to conform to the Google guide except in a few specific cases.

PK

[Jeremy Roman]

Does the same list of approved C++11 features apply to Blink as to
Chromium, or will those evolve separately? What about formatting rules
for new features (like lambda expressions)?

[Nico Weber]

On Tue, Sep 23, 2014 at 2:23 PM, Jeremy Roman <jbr...@chromium.org> wrote:

Does the same list of approved C++11 features apply to Blink as to
Chromium, or will those evolve separately? What about formatting rules
for new features (like lambda expressions)?

The Guide applies to Chromium and its subprojects. Subprojects can choose to be more restrictive if they need to compile on more toolchains than Chromium.

Most of the features don't have much formatting questions to argue about, but for the ones that do, the feature thread is probably a good place for that. (Formatting will be slightly different for Blink and Chromium – indents are different, line lengths are different, etc.)

[Pozdnyakov, Mikhail]

Hi,

Great that it is happening :)

I'd like to ask about C++11 features that are *already* used in Blink (e.g. move semantics):
Can those be automatically considered as 'allowed'?

Another question: can the dedicated ifdef guards (#if COMPILER_SUPPORTS(..)) be now removed from the code?

BR,
Mikhail

________________________________________
From: tha...@google.com [tha...@google.com] on behalf of Nico Weber [tha...@chromium.org]
Sent: Tuesday, September 23, 2014 11:51 PM
To: Chromium-dev; blink-dev
Subject: [blink-dev] C++11 feature rollout

Hi,

I believe all (*) our toolchains are now in a state where they understand C++11
language features.

We won't want to use every single C++11 feature, just like we don't use every
available C++98 feature. Here's how it's going to work: There's a list of

C++11 features at http://chromium-cpp.appspot.com<http://chromium-cpp.appspot.com/> . At the moment, almost all

of them are marked as "to be discussed". A few are already pre-approved.

You can propose to make a feature available or to ban a feature by sending an
email to chromium-dev. Ideally include a short blurb on what the feature is,
and why you think it should or should not be allowed. Ideally, the list will
arrive at some consensus and the wiki page will be updated to mention that

consensus. If there's no consensus, src/styleguide/C++/OWNERS<https://chromium.googlesource.com/chromium/src/+/master/styleguide/c++/OWNERS> get to decide --

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org<mailto:blink-dev+...@chromium.org>.
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[James Robinson]

Where do you see Blink using move semantics today? My understanding is that it does not.

You can remove compiler guards for C++11 language features on the permissible list today. I'm pretty sure we do not have any guards for things like using >> in templates but if you know of any please send the review to me.

- James

[Victor Khimenko]

On Wed, Sep 24, 2014 at 12:51 AM, Nico Weber <tha...@chromium.org> wrote:

Hi,

I believe all (*) our toolchains are now in a state where they understand C++11

language features. 

We won't want to use every single C++11 feature, just like we don't use every

available C++98 feature. Here's how it's going to work: There's a list of

C++11 features at http://chromium-cpp.appspot.com . At the moment, almost all

of them are marked as "to be discussed". A few are already pre-approved.

You can propose to make a feature available or to ban a feature by sending an

email to chromium-dev. Ideally include a short blurb on what the feature is,

and why you think it should or should not be allowed. Ideally, the list will

arrive at some consensus and the wiki page will be updated to mention that

consensus. If there's no consensus, src/styleguide/C++/OWNERS get to decide --

for divisive features, we expect the decision to be to not use the feature yet

and possibly discuss it again a few months later, when we have more experience

with the language.

Factors for allowing or banning a feature include:

* purely technical (for example, uniform initialization doesn't really

  make sense without std::initializer_list)

It's funny that you'll say so because it actually makes perfect sense - or at least one fairly limited form of it does:

  int x[5]{};

is zero-initialized array from five alements. "()" works in constructors and with "new" but will not work here for obvious reason.

I'm not sure if I like this syntax or not thus I'm not proposing it, but, well, {} form of uniform initialization is quite usable without std::initializer_list ...

 

* the feature's complexity/convenience trade-off (for example, if you want to

  allow rvalue references, you should be able to make a convincing case that

  most chromium developers can explain the difference between std::move and

  std::forward)

So go ahead, propose your favorite feature :-) To get used to the process,

it's probably best to start with a simple feature like lowercase final/override.

Nico

*: Some conditions apply: Targets that have build_glibc or build_newlib set

to 1 don't work. The exhaustive list of these targets is currently gtest,

liblouis, libjingle, modp_b64. It's all third-party code, and not much.

ps: Thanks to all the folks who helped to make this happen: scottmg is

keeping us on a recent Visual Studio, dschuff and mseaborn got the nacl

IRT converted to use the pnacl compiler instead of an old gcc, torne and

primiano worked with Android build engineers to move the webview

build from an old gcc to a fairly new clang, pasko and fdegans are keeping

chrome/android's gcc up-to-date, the chromeos compiler team is doing the same

for chromeos, and lots of people helped to move the linux build and the

chrome/android and simplechrome chromeos host compilers to clang.  Thanks also

to hans for keeping our clang binaries up-to-date, the goma team for quickly

fixing various bugs triggered by all these changes, and to the clang and llvm

community for building a versatile compiler that supports modern language

features while still working with the libstdc++ that ships on precise.

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

[Nico Weber]

Factors for allowing or banning a feature include:

* purely technical (for example, uniform initialization doesn't really

  make sense without std::initializer_list)

It's funny that you'll say so because it actually makes perfect sense - or at least one fairly limited form of it does:

  int x[5]{};

is zero-initialized array from five alements. "()" works in constructors and with "new" but will not work here for obvious reason.

I'm not sure if I like this syntax or not thus I'm not proposing it, but, well, {} form of uniform initialization is quite usable without std::initializer_list ...

Well, it works, but not only does it not make sense, it's actively dangerous. Consider

  vector<int> a{10};

If your standard library knows std::initializer_list, then this will initialize the vector from an initializer list containing a single element (10), calling the vector(std::initializer_list) constructor. If your standard library doesn't know about std::initializer_list, this will still compile, but instead call the vector(int) constructor, which will initialize the vector to 10 elements, each of them default-initialized (which for integers means each of them 0).

[Victor Khimenko]

But that's different. I'm talking strictly and explicitly about version with NO arguments between braces. It's special because of how C++98/03 was designed.

You always had a way to call constructor with value of 10: just use "vector<int> a(10)" or "int a(10);", that's all. On the other hand it's IMPOSSIBLE to value-initialize objects in C++03 with default values (zeros for PODs): without () it's default constructor which does not initialize PODs and with () it's function declaration, not declaration of value-initialized object!

Basically this forms does not offer just a syntax sugar, it kind of plugs the hole in the C++98/03 design instead. But syntax is somewhat unintuitive and I'm not sure how often people actually need to zero-initialize non-trivial objects on stack thus I'm not sure if this feature is worth adding.

[Hendrik]

Unless I'm misunderstand what you're after:

struct A { int i; }; // POD

A a = {};

int x[5] = {};

Everything here would initialize to zero in C++03.

On Wednesday, September 24, 2014 9:11:53 AM UTC-7, khim wrote:

... it's IMPOSSIBLE to value-initialize objects in C++03 with default values (zeros for PODs): without () it's default constructor which does not initialize PODs and with () it's function declaration, not declaration of value-initialized object!

[Victor Khimenko]

On Wed, Sep 24, 2014 at 8:30 PM, Hendrik <hend...@chromium.org> wrote:

Unless I'm misunderstand what you're after:

struct A { int i; }; // POD

A a = {};

int x[5] = {};

Everything here would initialize to zero in C++03.

This only works with PODs, uniform constructors work for all objects (hence the name).

Actually I think in C++11 syntax shown above works with non-PODs, too, which is probably enough.

 

On Wednesday, September 24, 2014 9:11:53 AM UTC-7, khim wrote:

... it's IMPOSSIBLE to value-initialize objects in C++03 with default values (zeros for PODs): without () it's default constructor which does not initialize PODs and with () it's function declaration, not declaration of value-initialized object!

Basically this forms does not offer just a syntax sugar, it kind of plugs the hole in the C++98/03 design instead. But syntax is somewhat unintuitive and I'm not sure how often people actually need to zero-initialize non-trivial objects on stack thus I'm not sure if this feature is worth adding.

[Nico Weber]

To get this track back on track, as a general point I think we should be hesitant to approve features that work well only in certain cases. "X is allowed" is a simpler, easier to remember rule than "X is allowed, except when Y and Z".

(There's some room for interpretation of course, and in some cases the benefits might outweigh the more complicated rule, see for example the "foreach + auto" thread.)

[Stuart Morgan]

On Tue, Sep 23, 2014 at 2:12 PM, 'Peter Kasting' via Chromium-dev <chromi...@chromium.org> wrote:

This would not only be simpler and faster than trying to discuss every single feature, it would make clear that, philosophically, our goal with C++11 is the same as our goal with all other aspects of our styleguide, namely to conform to the Google guide except in a few specific cases.

Based on the threads so far, a big +1. It seems like we should be restricting the discussions on Google-guide-approved items to Chromium-specific objections, not general "I think this could be a foot-gun in some specific generic case" objections.

Deviating from the Google style guide as little as necessary has been a goal for us in the past, and it would be nice to not change course on that just for C++11.

-Stuart

[Hendrik]

While I agree that we should allow the features that they have allowed (except where toolchains are a concerned), there are some features that that they disallow that should still be up for discussion.  For example, they don't allow std::forward, which can lead to difficult situations when working correctly with move semantics and templates.

[Alex Vakulenko]

+1000 on std::forward<T>()

I had to write really ugly and less functional code just because I needed to work around of not using std::forward. Official Google style guide allows using std::move with move-only types, so one can use move-only types (like unique_ptr) in google3 code base. Yet with the (irrational) ban on forward, you can't pass move-only type to generic functions (think base::Bind)

template<typename Functor, typename T>

void LoggingCallback(Functor callback, T value) {

  LOG(INFO) << "Callback called";

  callback(value);

}

So, here you can't use unique_ptr with value.

Here is a "very complicated" fix to this problem:

template<typename Functor, typename T>

void LoggingCallback(Functor callback, T&& value) {

  LOG(INFO) << "Callback called";

  callback(std::forward<T>(value));

}

And one doesn't really need to understand the inner workings of std::forward to read and understand the above code.

--

[James Robinson]

On Wed, Sep 24, 2014 at 11:58 AM, Alex Vakulenko <avaku...@chromium.org> wrote:

+1000 on std::forward<T>()

std::forward<> is a language feature, so I see no value in the rest of this post to chromium today.  We don't have language support today.  When we do it would be valuable to talk about use of them in chromium, but we don't and so it is not.

- James

[Nico Weber]

On Wed, Sep 24, 2014 at 12:02 PM, James Robinson <jam...@chromium.org> wrote:

On Wed, Sep 24, 2014 at 11:58 AM, Alex Vakulenko <avaku...@chromium.org> wrote:

+1000 on std::forward<T>()

std::forward<> is a language feature, so I see no value in the rest of this post to chromium today.  We don't have language support today.

s/language/library/ :-)

 

- James

[Vincent Scheib]

Please post a separate PSA or equivalent thread to chromium-dev when features gain consensus and the style guide is updated.

[Scott Graham]

Given the excitement and refactorings people are excitedly starting -- when did the toolchains become compatible?

In particular, if we're building a Chrome Stable 37/38/whatever on an older toolchain, is it worth lagging any of these rollouts to make back merges not-harder?

On Tue, Sep 23, 2014 at 1:51 PM, Nico Weber <tha...@chromium.org> wrote:

[Jeffrey Yasskin]

If the only objection to std::move and std::forward were that they're
provided by the standard library, we could trivially provide
base::move and base::forward with the same functionality.

Let's keep to the real objections against rvalue reference use.

[Viet-Trung Luu]

On Tue, Sep 23, 2014 at 1:51 PM, Nico Weber <tha...@chromium.org> wrote:

Hi,

I believe all (*) our toolchains are now in a state where they understand C++11

language features. 

We won't want to use every single C++11 feature, just like we don't use every

available C++98 feature. Here's how it's going to work: There's a list of

C++11 features at http://chromium-cpp.appspot.com . At the moment, almost all

of them are marked as "to be discussed". A few are already pre-approved.

clang-format appears to still prefer "> >" over ">>" (AFAICT). Who should I talk to to get this fixed?

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dana Jansens]

On Wed, Sep 24, 2014 at 9:19 PM, Viet-Trung Luu <viettr...@chromium.org> wrote:

On Tue, Sep 23, 2014 at 1:51 PM, Nico Weber <tha...@chromium.org> wrote:

Hi,

I believe all (*) our toolchains are now in a state where they understand C++11

language features. 

We won't want to use every single C++11 feature, just like we don't use every

available C++98 feature. Here's how it's going to work: There's a list of

C++11 features at http://chromium-cpp.appspot.com . At the moment, almost all

of them are marked as "to be discussed". A few are already pre-approved.

clang-format appears to still prefer "> >" over ">>" (AFAICT). Who should I talk to to get this fixed?

File an internal bug against clang-format.

[Nico Weber]

On Wed, Sep 24, 2014 at 6:19 PM, Viet-Trung Luu <viettr...@chromium.org> wrote:

On Tue, Sep 23, 2014 at 1:51 PM, Nico Weber <tha...@chromium.org> wrote:

Hi,

I believe all (*) our toolchains are now in a state where they understand C++11

language features. 

We won't want to use every single C++11 feature, just like we don't use every

available C++98 feature. Here's how it's going to work: There's a list of

C++11 features at http://chromium-cpp.appspot.com . At the moment, almost all

of them are marked as "to be discussed". A few are already pre-approved.

clang-format appears to still prefer "> >" over ">>" (AFAICT). Who should I talk to to get this fixed?

Top Engineers are working on this http://crbug.com/417296

[Nico Weber]

On Wed, Sep 24, 2014 at 5:24 PM, Scott Graham <sco...@chromium.org> wrote:

Given the excitement and refactorings people are excitedly starting -- when did the toolchains become compatible?

In particular, if we're building a Chrome Stable 37/38/whatever on an older toolchain, is it worth lagging any of these rollouts to make back merges not-harder?

That's an excellent question! m38 should have most of this, but I'm not sure it has the nacl toolchain bits.

I think it makes to consider c++11 features and the follow-up giant rewrites separately: We've done automatic rewrites before, and that has caused some merge pain, but it was usually not too bad (as far as I know).

I think merge CLs are usually relatively small, the c++11 feature rollout is spread out a bit, and every feature proposed so far is relatively easily to revert to its c++98 form. So I I like to think that we should be fine :-)

[Ryan Sleevi]

On Sep 24, 2014 6:21 PM, "Dana Jansens" <dan...@chromium.org> wrote:
>
> On Wed, Sep 24, 2014 at 9:19 PM, Viet-Trung Luu <viettr...@chromium.org> wrote:
>>
>> On Tue, Sep 23, 2014 at 1:51 PM, Nico Weber <tha...@chromium.org> wrote:
>>>
>>> Hi,
>>>
>>> I believe all (*) our toolchains are now in a state where they understand C++11
>>> language features. 
>>>
>>> We won't want to use every single C++11 feature, just like we don't use every
>>> available C++98 feature. Here's how it's going to work: There's a list of
>>> C++11 features at http://chromium-cpp.appspot.com . At the moment, almost all
>>> of them are marked as "to be discussed". A few are already pre-approved.
>>
>>
>> clang-format appears to still prefer "> >" over ">>" (AFAICT). Who should I talk to to get this fixed?
>
>
> File an internal bug against clang-format.
>  

http://llvm.org/bugs/enter_bug.cgi

Or a public one. I'm an email, not a cop.

[Avi Drissman]

There are at least two proposals where we're considering rewriting the world to a new way (enum class over enum, using over typedef). If the new way is strictly preferred to the old way, are we going to add support to the clang plugin to warn about doing it the old way? If we don't, I fear that new instances will surely be introduced.

(The third proposal is nullptr over NULL, but removing the definition of NULL would fix that quickly.)

[Nico Weber]

On Wed, Sep 24, 2014 at 9:06 PM, Avi Drissman <a...@chromium.org> wrote:

There are at least two proposals where we're considering rewriting the world to a new way (enum class over enum, using over typedef). If the new way is strictly preferred to the old way, are we going to add support to the clang plugin to warn about doing it the old way? If we don't, I fear that new instances will surely be introduced.

No, the clang plugin is for things that are likely bugs, not for stylistic things.

 

(The third proposal is nullptr over NULL, but removing the definition of NULL would fix that quickly.)

NULL is in the compiler's stddef.h, removing a definition from there is tricky :-)

[Dana Jansens]

On Sep 25, 2014 12:17 AM, "Nico Weber" <tha...@chromium.org> wrote:
>
> On Wed, Sep 24, 2014 at 9:06 PM, Avi Drissman <a...@chromium.org> wrote:
>>
>> There are at least two proposals where we're considering rewriting the world to a new way (enum class over enum, using over typedef). If the new way is strictly preferred to the old way, are we going to add support to the clang plugin to warn about doing it the old way? If we don't, I fear that new instances will surely be introduced.
>
>
> No, the clang plugin is for things that are likely bugs, not for stylistic things.

We could add presubmit warnings for these. They both sound like things a regex could easily find.

[Scott Graham]

Our long Chromium nightmare of > > is over... Our clang-format works; our great mailing list of "C++11 Feature Proposal"s will continue. Here the people rule.

https://crrev.com/57e3f0ac1042d7acbf6ff2d62b47f7d4033dc51d

 

[Pozdnyakov, Mikhail]

At the moment move semantics is used in WTF smart pointers and vector and also in platform KURL and Length classes.
Would be nice to get rid of those "#if COMPILER_SUPPORTS(CXX_RVALUE_REFERENCES)".

BR,
Mikhail

________________________________________
From: jam...@google.com [jam...@google.com] on behalf of James Robinson [jam...@chromium.org]
Sent: Wednesday, September 24, 2014 6:35 PM
To: Pozdnyakov, Mikhail
Cc: blink-dev; Chromium-dev; Nico Weber
Subject: RE: [blink-dev] C++11 feature rollout

Where do you see Blink using move semantics today? My understanding is that it does not.

You can remove compiler guards for C++11 language features on the permissible list today. I'm pretty sure we do not have any guards for things like using >> in templates but if you know of any please send the review to me.

- James

On Sep 24, 2014 4:32 AM, "Pozdnyakov, Mikhail" <mikhail.p...@intel.com<mailto:mikhail.p...@intel.com>> wrote:
Hi,

Great that it is happening :)

I'd like to ask about C++11 features that are *already* used in Blink (e.g. move semantics):
Can those be automatically considered as 'allowed'?

Another question: can the dedicated ifdef guards (#if COMPILER_SUPPORTS(..)) be now removed from the code?

BR,
Mikhail

________________________________________

From: tha...@google.com<mailto:tha...@google.com> [tha...@google.com<mailto:tha...@google.com>] on behalf of Nico Weber [tha...@chromium.org<mailto:tha...@chromium.org>]

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org<mailto:blink-dev%2Bunsu...@chromium.org><mailto:blink-dev+...@chromium.org<mailto:blink-dev%2Bunsu...@chromium.org>>.

[James Robinson]

Looking at the history those were added in the WebKit days (pre-Blink) and are not compatible with the current Chromium or Blink style guides.  This should not be considered blanket approval for these features and we should probably just delete them until we can allow this functionality across the board.

One use of rvalue refs in WTF::OwnPtr<> is really about trying to emulate the behavior of = delete for constructors.  We should replace that one with = delete.

- James

[Elliott Sprehn]

I thought this was done in WTF and the Length classes to reduce copying. What's the performance impact of removing it?

[Pozdnyakov, Mikhail]

Yeah, move semantics was added for the performance sake, I do not have the numbers but the impact can be quite significant: for instance move semantics is enabled for WTF::Strings (via RefPtr) and those are used everywhere.
BTW here is an example of move semantics introduction to KURL which was made quite recently https://codereview.chromium.org/297223005

BR,
Mikhail

________________________________________
From: blin...@chromium.org [blin...@chromium.org]
Sent: Thursday, September 25, 2014 11:55 AM
To: James Robinson
Cc: Pozdnyakov, Mikhail; blink-dev; Chromium-dev; Nico Weber
Subject: Re: [blink-dev] C++11 feature rollout

I thought this was done in WTF and the Length classes to reduce copying. What's the performance impact of removing it?

On Wednesday, September 24, 2014, James Robinson <jam...@chromium.org<mailto:jam...@chromium.org>> wrote:
Looking at the history those were added in the WebKit days (pre-Blink) and are not compatible with the current Chromium or Blink style guides. This should not be considered blanket approval for these features and we should probably just delete them until we can allow this functionality across the board.

One use of rvalue refs in WTF::OwnPtr<> is really about trying to emulate the behavior of = delete for constructors. We should replace that one with = delete.

- James

[Alexey]

C++11 Standard Library features are completely banned for now.

Do we have any plans to enable move semantics support for std containers?

On Thursday, September 25, 2014 at 7:38:47 PM UTC+10, Mikhail Pozdnyakov wrote:

Yeah, move semantics was added for the performance sake, I do not have the numbers but the impact can be quite significant: for instance move semantics is enabled for WTF::Strings (via RefPtr) and those are used everywhere.
BTW here is an example of  move semantics introduction to KURL which was made quite recently  https://codereview.chromium.org/297223005

BR,
Mikhail

________________________________________
From: blin...@chromium.org [blin...@chromium.org]
Sent: Thursday, September 25, 2014 11:55 AM
To: James Robinson
Cc: Pozdnyakov, Mikhail; blink-dev; Chromium-dev; Nico Weber
Subject: Re: [blink-dev] C++11 feature rollout

I thought this was done in WTF and the Length classes to reduce copying. What's the performance impact of removing it?

On Wednesday, September 24, 2014, James Robinson <jam...@chromium.org<mailto:jame...@chromium.org>> wrote:
Looking at the history those were added in the WebKit days (pre-Blink) and are not compatible with the current Chromium or Blink style guides.  This should not be considered blanket approval for these features and we should probably just delete them until we can allow this functionality across the board.

One use of rvalue refs in WTF::OwnPtr<> is really about trying to emulate the behavior of = delete for constructors.  We should replace that one with = delete.

- James

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org<mailto:blink-dev+unsub...@chromium.org>.

[Victor Khimenko]

On Mon, Jun 22, 2015 at 4:55 AM, Alexey <lo...@chromium.org> wrote:

C++11 Standard Library features are completely banned for now.

Mostly because GCC 4.2-provided libstdc++ on MacOS is VERY old and does not include many things needed by C++11. Perhaps we could extend approach used by Red Hat Developer Toolset ? It's C++ package includes peculiar version of libstdc++.so which looks like this:

$ cat /usr/lib/gcc/i686-redhat-linux/4.9.2/libstdc++.so 

/* GNU ld script

   Use the shared library, but some functions are only in

   the static library, so try that secondarily.  */

OUTPUT_FORMAT(elf32-i386)

INPUT ( /usr/lib/libstdc++.so.6 -lstdc++_nonshared )

/usr/lib/libstdc++.so.6 is, of course, version of libstdc++ provided by RHEL6 or RHEL7 and libstdc++_nonshared.a is an addon needed to provide full support for GCC 4.9, including C++11/C++14 support.

Sadly it only covers system-provided libstdc++ 4.4.4 and newer but for MacOS we need something to cover libstdc++ 4.2. I'm not sure how hard it'll be to extend libstdc++_nonshared.a to cover GCC 4.2.

Sources for GCC 4.9 from Red Hat Developer Toolset live here:

  https://git.centos.org/tree/rpms!devtoolset-3-gcc/5733f8a4d0eee309692c30c1b15febc5243f7858

Patch to provide libstdc++_nonshared.a is here:

  https://git.centos.org/blob/rpms!devtoolset-3-gcc/5733f8a4d0eee309692c30c1b15febc5243f7858/SOURCES!gcc49-libstdc++-compat.patch

 

Do we have any plans to enable move semantics support for std containers?

On Thursday, September 25, 2014 at 7:38:47 PM UTC+10, Mikhail Pozdnyakov wrote:

Yeah, move semantics was added for the performance sake, I do not have the numbers but the impact can be quite significant: for instance move semantics is enabled for WTF::Strings (via RefPtr) and those are used everywhere.
BTW here is an example of  move semantics introduction to KURL which was made quite recently  https://codereview.chromium.org/297223005

BR,
Mikhail

________________________________________
From: blin...@chromium.org [blin...@chromium.org]
Sent: Thursday, September 25, 2014 11:55 AM
To: James Robinson
Cc: Pozdnyakov, Mikhail; blink-dev; Chromium-dev; Nico Weber
Subject: Re: [blink-dev] C++11 feature rollout

I thought this was done in WTF and the Length classes to reduce copying. What's the performance impact of removing it?

On Wednesday, September 24, 2014, James Robinson <jam...@chromium.org<mailto:jam...@chromium.org>> wrote:
Looking at the history those were added in the WebKit days (pre-Blink) and are not compatible with the current Chromium or Blink style guides.  This should not be considered blanket approval for these features and we should probably just delete them until we can allow this functionality across the board.

One use of rvalue refs in WTF::OwnPtr<> is really about trying to emulate the behavior of = delete for constructors.  We should replace that one with = delete.

- James

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org<mailto:blink-dev+...@chromium.org>.

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.