C++11 Banned Feature: exception-handling additions

[Peter Kasting]

What: Ban exception features, e.g. noexcept, exception_ptr, etc.

Why: These are banned by the Google style guide.  They aren't necessary in Chromium since we don't use exceptions.

Detail: I don't see any reason to leave these on the "TBD" list.  Banning them seems safe and keeps us consistent with the Google style guide.

PK

[Jeffrey Yasskin]

This is just context, not an objection to banning these features.

Banning 'noexcept' has caused some problems inside Google because vector<T> optimizes better if T's move constructor is marked noexcept. On the other hand, the clang team is motivated to find some way to deal with that, without adding code to all move constructors.

It's also less pressing since move constructors aren't allowed in Chromium yet.

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

[Peter Kasting]

On Wed, Sep 24, 2014 at 4:27 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

This is just context, not an objection to banning these features.

Banning 'noexcept' has caused some problems inside Google because vector<T> optimizes better if T's move constructor is marked noexcept. On the other hand, the clang team is motivated to find some way to deal with that, without adding code to all move constructors.

If the compiler is told that exceptions are disabled, shouldn't that effectively imply "noexcept" everywhere, at least for optimization purposes?

This wouldn't help if exceptions are enabled-but-unused, but AFAIK we actually forcibly disable exceptions in e.g. MSVC.

PK 

[Jeffrey Yasskin]

On Wed, Sep 24, 2014 at 4:30 PM, Peter Kasting <pkas...@google.com> wrote:
> On Wed, Sep 24, 2014 at 4:27 PM, Jeffrey Yasskin <jyas...@chromium.org>
> wrote:
>>
>> This is just context, not an objection to banning these features.
>>
>> Banning 'noexcept' has caused some problems inside Google because
>> vector<T> optimizes better if T's move constructor is marked noexcept. On
>> the other hand, the clang team is motivated to find some way to deal with
>> that, without adding code to all move constructors.
>
>
> If the compiler is told that exceptions are disabled, shouldn't that
> effectively imply "noexcept" everywhere, at least for optimization purposes?

One would think that. ;-)

Internal bug 15770138 for any googlers who want to follow along. Sorry
everyone else. :-/

[Peter Kasting]

On Wed, Sep 24, 2014 at 5:02 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

On Wed, Sep 24, 2014 at 4:30 PM, Peter Kasting <pkas...@google.com> wrote:
> On Wed, Sep 24, 2014 at 4:27 PM, Jeffrey Yasskin <jyas...@chromium.org>
> wrote:
>>
>> This is just context, not an objection to banning these features.
>>
>> Banning 'noexcept' has caused some problems inside Google because
>> vector<T> optimizes better if T's move constructor is marked noexcept. On
>> the other hand, the clang team is motivated to find some way to deal with
>> that, without adding code to all move constructors.
>
>
> If the compiler is told that exceptions are disabled, shouldn't that
> effectively imply "noexcept" everywhere, at least for optimization purposes?

One would think that. ;-)

Internal bug 15770138 for any googlers who want to follow along. Sorry
everyone else. :-/

Oh, there are cases on there I hadn't considered.  Ugh.

If we really wanted, I would support an explicit style-guide exception that says noexcept can be used in cases where doing so produces a meaningful performance win, with some background on when and why that might be.

PK 

[Vitalii]

Is there any progress on this? It seems like not, because both threads are 2 years old, but it is hard to believe that this issue is so rare.

I recently found out that one cannot use resize() on a vector of noncopyable (but movable) type due to missing noexcept on move constructor. We had to use pop_back()'s.

[Avi Drissman]

On Wed, Oct 26, 2016 at 7:44 PM, 'Vitalii' via Chromium-dev <chromi...@chromium.org> wrote:

I recently found out that one cannot use resize() on a vector of noncopyable (but movable) type

I've been encountering this problem on Android, but due to their STL implementation not being fully C++11 compliant. Are you seeing this on Android or everywhere?

Moving to the cxx list, as it's more appropriate.

Avi

 

due to missing noexcept on move constructor. We had to use pop_back()'s.

On Wednesday, September 24, 2014 at 5:07:59 PM UTC-7, Peter Kasting wrote:

On Wed, Sep 24, 2014 at 5:02 PM, Jeffrey Yasskin <jyas...@chromium.org> wrote:

On Wed, Sep 24, 2014 at 4:30 PM, Peter Kasting <pkas...@google.com> wrote:
> On Wed, Sep 24, 2014 at 4:27 PM, Jeffrey Yasskin <jyas...@chromium.org>
> wrote:
>>
>> This is just context, not an objection to banning these features.
>>
>> Banning 'noexcept' has caused some problems inside Google because
>> vector<T> optimizes better if T's move constructor is marked noexcept. On
>> the other hand, the clang team is motivated to find some way to deal with
>> that, without adding code to all move constructors.
>
>
> If the compiler is told that exceptions are disabled, shouldn't that
> effectively imply "noexcept" everywhere, at least for optimization purposes?

One would think that. ;-)

Internal bug 15770138 for any googlers who want to follow along. Sorry
everyone else. :-/

Oh, there are cases on there I hadn't considered.  Ugh.

If we really wanted, I would support an explicit style-guide exception that says noexcept can be used in cases where doing so produces a meaningful performance win, with some background on when and why that might be.

PK 

--

[Chris Blume]

There is official wording for noexcept being added to the Google standard. It is in review right now, actually.

In the mean time, they said go ahead with noexcept on move ctors.

--

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

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

[Peter Kasting]

On Wed, Oct 26, 2016 at 5:00 PM, 'Chris Blume' via Chromium-dev <chromi...@chromium.org> wrote:

There is official wording for noexcept being added to the Google standard. It is in review right now, actually.

In the mean time, they said go ahead with noexcept on move ctors.

So should we morph this thread to be "allow noexcept under the same rules as the Google style guide, ban other exception-related features"?

PK 

[dan...@chromium.org]

SGTM

[Claudio deSouza]

Move Constructors aren't allowed in Chromium? Are you sure? What about base::Process

- Claudio

[Karl Wiberg]

They're allowed now. The message you're replying to is more than 2 years old.

---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.

--

Karl Wiberg, Google

[Peter Kasting]

On Wed, Oct 26, 2016 at 5:08 PM, Peter Kasting <pkas...@chromium.org> wrote:

As of https://crrev.com/c6a6ebf1a9b6a18eade0d15df027b607d7d912e2 , this is done.

PK 

[Vitalii]

Sorry for the confusion, I figured out that we were missing a default constructor (it is required for resize(number) on a vector) and technically I did not need noexcept.

I believe if it was allowed in Google standard, then there are must be some other reasons in addition to my "debunked" one above, so this should not change anything.

[Chris Blume]

The reasoning to allow noexcept on move ctors is because std::vector implementations often have two code paths for its realloc.
If std::vector knows its contained type has a noexcept move, it can use move instead of copying. This can be a performance win.

You can still have std::vector realloc without a noexcept move. It will just copy instead.
So the reasoning behind noexcept move ctor is performance, not correctness.
(That said, please use it correctly.)


This performance win could actually be gained in many other places as well. These other places have not been approved.
Any code that is written to be exception safe and requires extra precaution (read: slowdown) could benefit from a code path that knows it cannot throw. This includes things other than moves. std::vector's realloc is one of the rare cases where two code paths exist.
Since we do not use exceptions within Google, we do not always write code that is slower to be exception safe.

Libraries we use might. But very few libraries have multiple code paths like std::vector's realloc.

Chris Blume | Software Engineer | cbl...@google.com | +1-614-929-9221

[Peter Kasting]

On Fri, Nov 11, 2016 at 3:29 PM, 'Chris Blume' via Chromium-dev <chromi...@chromium.org> wrote:

This performance win could actually be gained in many other places as well. These other places have not been approved.

I would summarize the style decision here as "you can use noexecept to gain a performance win today, but please know what you're doing before electing to do so."

PK

[Денис]

Hi!

Recently I've encountered a problem. I was trying to write a noexcept move constructor.

At first I did it like this (I'm keeping the name to show the error message):
*.h
HistoryInfoMapValue(HistoryInfoMapValue&& other) noexcept;

*.cc

HistoryInfoMapValue::HistoryInfoMapValue(HistoryInfoMapValue&& other) noexcept =  default;

On mac it compiles, but I get an error while compiling  android_compile_dbg.
error: function 'HistoryInfoMapValue::HistoryInfoMapValue(HistoryInfoMapValue&&)' defaulted on its redeclaration with an exception-specification that differs from the implicit declaration 'HistoryInfoMapValue::HistoryInfoMapValue(HistoryInfoMapValue&&)' HistoryInfoMapValue::HistoryInfoMapValue(HistoryInfoMapValue&& other) noexcept =

If I declare it inline that the noexcept specification will be deduced by the compiler but I get an error:

[chromium-style] Complex constructor has an inlined body.

  HistoryInfoMapValue(HistoryInfoMapValue&& other) = default;

It seems like I can't make nothrow_move_constructible. What should I do?

четверг, 25 сентября 2014 г., 2:24:12 UTC+3 пользователь Peter Kasting написал:

[dan...@chromium.org]

On Sun, Feb 26, 2017 at 2:19 PM, Денис <dyar...@yandex-team.ru> wrote:

Hi!

Recently I've encountered a problem. I was trying to write a noexcept move constructor.

At first I did it like this (I'm keeping the name to show the error message):
*.h
HistoryInfoMapValue(HistoryInfoMapValue&& other) noexcept;

*.cc

HistoryInfoMapValue::HistoryInfoMapValue(HistoryInfoMapValue&& other) noexcept =  default;

On mac it compiles, but I get an error while compiling  android_compile_dbg.
error: function 'HistoryInfoMapValue::HistoryInfoMapValue(HistoryInfoMapValue&&)' defaulted on its redeclaration with an exception-specification that differs from the implicit declaration 'HistoryInfoMapValue::HistoryInfoMapValue(HistoryInfoMapValue&&)' HistoryInfoMapValue::HistoryInfoMapValue(HistoryInfoMapValue&& other) noexcept =

If I declare it inline that the noexcept specification will be deduced by the compiler but I get an error:

[chromium-style] Complex constructor has an inlined body.

  HistoryInfoMapValue(HistoryInfoMapValue&& other) = default;

It seems like I can't make nothrow_move_constructible. What should I do?

I'm not sure if this would help because this isn't a virtual case: https://groups.google.com/a/chromium.org/d/msg/chromium-dev/rdF1mT3V_PM/BPI8EAJnAwAJ

Other possible alternative would be to teach the plugin to allow inline move constructors so that noexcept works. I couldn't say if that's reasonable tho without re-reading that whole thread. Maybe you can find something in there.

 

четверг, 25 сентября 2014 г., 2:24:12 UTC+3 пользователь Peter Kasting написал:

What: Ban exception features, e.g. noexcept, exception_ptr, etc.

Why: These are banned by the Google style guide.  They aren't necessary in Chromium since we don't use exceptions.

Detail: I don't see any reason to leave these on the "TBD" list.  Banning them seems safe and keeps us consistent with the Google style guide.

PK

--

[Daniel Cheng]

Hmm... can you link to a CL? I just did a quick test, and gcc seems to accept it, as long as noexcept is specified on the declaration in the header, and on the explicitly defaulted definition in the .cc:

$ cat test.cc

#include "test.h"

C::C(C&&) noexcept = default;

$ cat test.h

#ifndef TEST_H_

#define TEST_H_

class C {

  C(C&&) noexcept;

};

#endif  // TEST_H_

$ g++ -std=c++11 -c test.cc -o test.o
$

Daniel

[Денис]

This is the CL: https://codereview.chromium.org/2690303012/

Unfortunatly old compilation errors are not avaliable, but the last patch refers only to this problem.

And here is a comment from commit bot:

Try jobs failed on following builders:
  android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)

суббота, 4 марта 2017 г., 1:15:54 UTC+3 пользователь Daniel Cheng написал: