C++の修飾子や指定子について

Question

const int func(int a){...};  // 1

int const func(int a){...};  // 2

int func(int a) volatile {...}; // 3

1番と2番は全く同じ意味ですよね？
これは返り値がconstになる・・・？？という意味ですか？？

3番めはメンバ関数にできることですが、これは・・・この関数が呼び出されている間だけメンバ変数を最適化抑止するという意味ですか？？

１番と２番については紛らわしくなりそうです。
例えば

constexpr int func(){...};

constexpr関数になりますが・・・これだと変数を修飾しているように見えませんか？？

以下のほうが関数を修飾しているように見えません？？

int constexpr func(){...};

逆に、以下のようにすると、関数全体を最適化抑止しているのかな？？という風に見えませんか？？

volatile int func(){...};

これも返り値が最適化抑止ということですよね？？
なんか紛らわしいですね・・・

inlineにも同じことが言えそうなんですが・・・
noexceptもわかりにくいです。

int noexcept func(){...}; // ERROR!!!　前には書けない。

noexceptの場合は、上記はダメでした。
お尻のほうに書かないといけないようです。
例外を送出しない関数なら前に書いたほうが良いような気がするんですが・・・

リンク内容
mutable const volatile inline など細かく分類されているようです。

修飾子と指定子の違いがよく分かりません。
記述する場所もイマイチはっきりしていません。
先頭に記述する場合と後ろに記述する場合の違いがよくわからないです。

修飾したい対象のものの直前と統一すれば分かりやすいと考えています。
しかし実際にはそうなっていないですよね。

どなたか教えてください。
わかりにくい。
予約語によって記述箇所が異なるので、全パターン覚えないといけないんですかね？

環境は　Linux 64bit gcc です。

Answer 1

こんにちは。

constは型を修飾します。int const、const intはどちらも変更不可なint型の意味ですね。
メンバ関数の後ろに記述するconstは判りにくいですね。
メンバ関数は隠しパラメータとして*thisを持っています。その*thisの型を修飾しています。要するにthisの指す先をconst（変更不可）として扱います。

volatileはconstと同じく型を修飾します。メンバ関数の後ろに書いているのを見たことはないですが、同じことの筈です。thisの指す先をvolatileとして扱う筈です。この場合、volatileが有る時と無い時で何が変わるのか私は良く分かりません。何も変わらないような気もします。

その使い方のconstexprは関数を修飾します。陶芸家の中３女子の方の解説が詳しいです。
constexprの読み方はチュウサンジョシと言われる程です。

noexceptも関数を修飾します。これは覚えましょう。

予約語によって記述箇所が異なるので、全パターン覚えないといけないんですかね？

そういうことですね。数もたかがしれていますし、直ぐ慣れますよ。

---

【蛇足ですが】
個人的にはnoexceptはあまり使わない方がよいように思います。例外が飛んでくるのに間違って付けると例外が投げられた時、エラー情報が消えてしまうので。
コンパイラはnoexceptな関数が直接例外を投げないことしかチェックしてくれません。その関数が呼び出している関数が投げないことはチェックしてくれないのです。
noexcept関数内でtry-catchして例外情報を残すか、小さな関数でパッと見て例外が投げられないことが明確な場合のみしか付けるべきではないように思います。

#include <iostream>

void bar()
{
    throw 12345;
}

void foo() noexcept // ←このnoexceptをなくせば例外の内容が表示される
{
    bar();
}

int main()
{
    try
    {
        foo();
    }
    catch(int e)
    {
        std::cout << "catch(" << e << ")\n";
    }
}

wandbox

Comments

[KSwordOfHaste]

class A {
int a = 0;
int foo() volatile { return a+a; }
int bar() { return a+a };
};
これをg++ -Ofast -Sでアセンブリソースを見てみました。Chironianさん回答にあるように*thisへの修飾となるようでfooの方はaを2回明示的にアクセスしbarは1回のみのアクセスに最適化されてました。volatileの目的はメモリーマップドI/Oや非同期処理などにからむ「領域アクセスの最適化抑止」だと思っていますが、メンバーに付けずにメンバー関数に付けるということは「ある時はvolatileで別のときはそうでないように振舞わせる」ということなので「どんな場合に有効なのだろう」という点がわかりませんでした。

メモリーマップドi/oならある場合はアクセスして別の場合は省略という論理は考えにくい気がしたので非同期処理において同期がとられている間は最適化可能でそうでない場合に毎回アクセスを要求するというようなことと想像はするのですが・・・

[catsforepaw]

> 個人的にはnoexceptはあまり使わない方がよいように思います。例外が飛んでくるのに間違って付けると例外が投げられた時、エラー情報が消えてしまうので。

これについてはちょっと異論があります。
`noexcept`を付けた関数が例外を投げる可能性が残っているとしたら、それはバグなので修正しなければいけません。`noexcept`を付けた関数は例外を投げてはいけないと明確に規定されていますので、`noexcept`を付ける以上は、例外を投げないことを保証する責務が設計者にはあります。もし内部で例外が発生する可能性があるのなら、関数内でキャッチしておかないといけません。`noexcept`は最適化にも関わってくるので、付けるか付けないかはきちんとした設計の元で判断すべきでしょう。
「間違って付けると問題を起こすから使わない方が良い」ではなく、「仕様を理解して正しく使いましょう」です。

[strike1217]

「メンバ関数は隠しパラメータとして*thisを持っています。その*thisの型を修飾しています。要するにthisの指す先をconst（変更不可）として扱います。 」

そうなんですか！！
なるほど！
納得です。

全パターン覚えないといけないんですね。
わかりました。

[strike1217]

メンバ変数の部分的最適化抑止は確かに使い道がイマイチ・・・
わからないですね。

https://qiita.com/YukiMiyatake/items/1191ab03b6c0b5a22876

最適化を全て禁止したくない 場合に使用しているようです。
「せっかくコンパイラが最適化をしてくれているのにflag に関わる場所を全部最適化禁止するのは　もったいない」とのこと・・・

[strike1217]

const volatile は修飾子ですよね？？

noexceptやinlineは・・・修飾子？？指定子って言うんですかね？？
イマイチ違いが・・・

[Chironian]

KSwordOfHasteさん。
フォローありがとう。そんな効果があるのですね！！　なるほどです。

catsforepawさん。
「間違って付けると問題を起こすから使わない方が良い」というか「間違って付けると問題を起こすから安易には使わない方が良い」と言いたかったのですよ。
必要性（最適化性能改善）に対して手間（当該関数の例外による報告を断念し、かつ、例外を投げないことを保証する）が見合うなら使うのだと思います。でも、それって結構レアとも思います。

strike1217さん。
volatileメンバ関数で局所的な最適化抑止に使えるとはちょっとびっくり。
でも、const参照と同じ使い方でvolatile参照を使ったほうが良さそうに感じます。
volatile int& flag_ref = flag;
while(flag_ref == 0){
}
アセンブリ出力をみたことはありませんが、flag_refについてはポインタのようにメモリを消費せず、直接flagをアクセスするコードを出すコンパイラが多いのではないかと期待します。（参照は「別名」ですから。）

因みに、大昔volatileはI/Oアクセスや割り込みハンドラーでの変更をメイン・ループで検出する際などに使ってました。マルチ・スレッド登場後はQiitaの記事のような使い方をした人達も多いと思います。
今でもKSwordOfHasteさんの言うとおりI/Oアクセス時に使うと思います。

標準規格上は、volatileはあくまでも最適化抑止です。マルチスレッドでのアクセス保証をするものではありません。リード・モディファイ・ライトすると危険ですし、もし、long long intとかだと32ビット処理系では書き換え途中のデータが読み出される可能性もあり、危険です。

[Chironian]

> noexceptやinlineは・・・修飾子？？指定子って言うんですかね？？
イマイチ違いが・・・

あは、あまり気にしたこと無いです。それらを纏めて呼びたいことってあまりないですし。

[catsforepaw]

Chironian さん

> でも、それって結構レアとも思います。

うーん。noexceptが付いていれば、使う側とすれば例外のハンドリングをしなくて済むと期待できますが、付いていなければ考慮する必要性が出てきます。先のコメントでは最適化についてしか触れませんでしたが、エラー処理全般に影響すると思うので、必要性についてはレアとは思えません（一応try/catchブロックも最適化に影響しますし……）。
それに、経験の浅い人に「間違って付けると困るから（安易には）使わない方が良い」と言ってしまうと、noexceptの存在理由に気づけないままそれを理解しようとする動機が失われてしまうのではないかと危惧します。それが気になって先のコメントをした次第であります。

[Chironian]

> うーん。noexceptが付いていれば、使う側とすれば例外のハンドリングをしなくて済むと期待できます

それが期待できるのはnoexceptが付いていない関数を使っていない{}ブロックだけですよ。そして、コンストラクタは例外以外にエラーを直接返却できないので、コンストラクタも含めてnoexcept無し関数を使わないで済むケースってどの程度あるのでしょうか？
しかも、そのブロックを囲むブロックなどが例外を投げるなら、どうせ例外ハンドリングは必要になります。狭い{}ブロックで例外ハンドリングを省略できるメリットは事実上無いと思います。

そして、noexceptは、例えばprivateのようなプログラマのミスを指摘してくれる機能と勘違いしやすい機能と思います。しかし、そうではなく性能アップ機能です。しかも、劇的な効果がでるケースはレアな筈です。（例外を実際に投げない時の性能が極端に落ちるようだとC++の思想に反すると思います。）

更に、noexceptするとエラーを例外で伝達できないので、その他の手段を用意するか、そもそも例外的な処理が不要（当該関数が呼び出すものも全て含めて）でないといけません。これは確実に生産性を低下させます。

以上を考慮すると、noexceptを使うのはアセンブラコードを見ながらガチガチの高速化を行う的な場面でのみ使うことが妥当と感じます。なので、これはレアと思います。

> 経験の浅い人に「間違って付けると困るから（安易には）使わない方が良い」と言ってしまうと、noexceptの存在理由に気づけないままそれを理解しようとする動機が失われてしまうのではないかと危惧します。

ガチガチの高速化が必要になった時に学べば十分では？

ああ、もしかして「noexceptの存在理由」の理解がcatsforepawさんと私で異なっているかも？
私は上述したように最適化の改善と理解しています。
https://cpplover.blogspot.jp/2014/10/c.html
例外を断念してまで使うメリットは他にはないと考えています。

[strike1217]

「それが期待できるのはnoexceptが付いていない関数を使っていない{}ブロックだけですよ」

ああ〜〜

回答中にあるvoid foo()が一見例外を送出しないような関数に見えるので、noexceptを付けるべき・・・と考えますが、その中にある関数は例外を送出するので、これは混乱しそうですね。

高速化や効率化を重視するなら、noexcept付けるべきと・・・考えています。

[strike1217]

とあるEffective modern C++ という書籍には
「関数をnoexceptと宣言するのは、noexceptな実装を長期に渡り確約する糸がある場合のみに限定するべきです。」
「殆どの関数が例外中立であるというのは、事実その通りです。」
「例外を単に伝搬することがある以上、例外中立の関数がnoexceptになることはありません。そのため大半の関数ではnoexceptを宣言しなくとも極めて正当なのです。」

「この関数が絶対に例外を発生させるべきではないと断言できるならば、間違いなくnoexceptと宣言するべきです。」

catsforepawさんの言いたいこともなんとなくはわかりますが、う〜〜ん？？
なんか難しい議論ですね。

[catsforepaw]

Chironian さん

おっしゃることはよく判りますが、それはご自身の経験ではnoexceptに必要性を感じないというだけですよね。私の経験の話をするなら、例えば、Win32APIやLinuxのシステムコール、あるいはオープンソースのライブラリーなどの純粋なC関数群を使いやすくするためのラッパークラスを作るということはよくあります。当然それらは例外を投げないのでtry/catchは使いません。APIの作法に合わせたエラー処理をすることになります。ただ、処理の過程でSTLや自分で作ったC++の関数を呼ぶことはあります。その際は例外の可能性に注意を払わないといけません。C関数と強調するような処理では「例外を投げてもらっては困る」ことも多いので、それを保証する必要性も出てきます。
こういうことは「結構レア」なことでしょうか。

> ガチガチの高速化が必要になった時に学べば十分では？

「必要になった時」は誰が教えてくれるのでしょうか？　「noexceptは使ってはいけないもの」と覚えてしまった人が、「どういうときに必要か」などと考えるようになるとは思えないのですが（誰かに教わらない限りは）。

私は、noexceptをリスク要因と考えるChironianの意見を否定するわけではありません。人によって作るものが違いますし、作るものが違えばnoexceptの利用価値も違ってきますから。ただ、それを相手にも当てはめて「使わない方が良い」とアドバイスするのはいかがなものか、と考えるわけです。相手が何を作るのかを知らないのであれば。ということで、すべきアドバイスとしては最初のコメントの通りだと思うのであります。あえて付け加えるとするなら、「仕様が理解できないうちは無理して使う必要はない」でしょう。

[strike1217]

「それはご自身の経験ではnoexceptに必要性を感じないというだけですよね。」

自分も今「人によって変わるのでは？？」と思いました。
例外をかなりの頻度で使用するような人なら、noexceptを指定するとバグの原因になりそうですもんね。

[catsforepaw]

strike1217 さん

> 回答中にあるvoid foo()が一見例外を送出しないような関数に見えるので、noexceptを付けるべき・・・と考えますが、その中にある関数は例外を送出するので、これは混乱しそうですね。

私の最初のコメントにも書きましたが、noexceptを付けた関数が例外を投げるのはバグです。仕様通りに実装できていません。
noexceptが付いていたらその関数は例外を投げないものと判断して良いです。

[strike1217]

そうですね。
ビャーネ・ストラウストラップにも近しいことが書いてあったようなーー気が・・・

記憶が曖昧です。

[strike1217]

「noexceptを付けた関数が例外を投げるのはバグです。」

ケイロニアンさんが言いたいのは、ここですよね。
プログラマが知らぬ間にバグを作ってしまう可能性が増える・・・のでおすすめしない。

ということでは？？（セキュアコーディングの話ではないかな？）

[Chironian]

おお、strike1217さん、その通りです。
例外の働きや使い方をきちんと理解しないとnoexceptはハマります。その割に性能改善効果が多少あるだけですから、メリットの割にデメリットが多く、あまり使わない方が良い機能と思います。
超熟練者向け機能と考えています。

[strike1217]

ああ、そうなんですね。コメント読み返して思いました。

[yohhoy]

「メンバ関数へのvolatile修飾」により*thisの型がvolatile修飾されますが、実用上の意味はほとんどないでしょう。

強いてユースケースを挙げるとしたら、クラスTで(1)volatile修飾メンバ関数mfと(2)通常のメンバ関数mfをオーバーロードしたとき、volatile T型のオブジェクトに対するmf呼び出しでは(1)が、T型オブジェクトに対するmf呼び出しでは(2)と、クラス変数型によってメンバ関数の実装を切り替え可能という点だけです。（この説明文はconst修飾の説明をvolatileに差し替えただけですね）

volatile: The Multithreaded Programmer's Best Friend
http://www.drdobbs.com/cpp/volatile-the-multithreaded-programmers-b/184403766
上記オーバーロードを利用して、「オーバーヘッドがあるスレッドセーフな処理と、スレッドセーフでないが効率の良い実装を切り替える」古い記事(2001年！)があります。ただし、C++がスレッドを正式にサポートした2018年現在は、この記事の内容は陳腐化しておりバッドノウハウと言っても差し支えないと思います。真似するべきではありません。

# C++ではvolatile＝スレッドセーフを**意味しません**。真にスレッドセーフな実装では、ミューテックス(mutex)のロック(lock)を取るか、アトミック変数(atomic)を利用します。

[yohhoy]

> 個人的にはnoexceptはあまり使わない方がよいように思います。

noexceptに関しては、私もChironianさんコメントの「間違って付けると問題を起こすから安易には使わない方が良い」が近いスタンスです。
もっと直接的な表現だと「あなたがnoexceptの意味を理解するまでは、自作関数にnoexceptをつけるな」ですね。この態度でも、標準ライブラリや他ライブラリがnoexpcetを適切に利用している恩恵にあやかることはできますし、C++例外安全の考え方に慣れ親しんでからnoexceptを学んでも決して遅くないと思います。

なお、「外部仕様上あきらかに例外送出しないのだがnoexceptをつけるべきでない」ケースも存在します。C++標準ライブラリの設計では例外に関する広い契約(wide contract)という考え方が敷かれています。
https://cpprefjp.github.io/article/lib/dont_use_noexcept.html

[catsforepaw]

yohhoy さん

> 「あなたがnoexceptの意味を理解するまでは、自作関数にnoexceptをつけるな」

私

> 「仕様が理解できないうちは無理して使う必要はない」

向いている方向は同じだと思うのですが……。

私は当初からnoexceptを使うか使わないかを問題にしてはいません。使いたくない人に無理に使えと言うつもりもありません。
やや白熱気味になりましたが、私の主張は最初から一貫して「仕様の理解を促す」べきだということです。ただ、利用価値の方に話がずれてしまい、うまく伝わっていなかったようで自分の文章力の無さを恥じ入るばかりです。
「バグると困るから使うな」というアドバイスが、果たして理解を促すことにつながるのかどうか、と疑問に思ったまでのことです。

[yohhoy]

catsforepawさん の主張を否定する意図はなくて、（というかそちらは深く読んでなかったごめんなさい）、回答主体であるChironianさん該当言及への賛同意図のみでした。
つまるところ相手・チームの力量次第ですが、個人的には「バグると困るから使うな」というスタンスも許容する派ですね。悲しいかなそういうケースもあると思います。

[catsforepaw]

yohhoy さん

> つまるところ相手・チームの力量次第ですが、個人的には「バグると困るから使うな」というスタンスも許容する派ですね。悲しいかなそういうケースもあると思います。

それは確かにその通りですね。もはやぐうの音も出ません。
ただ、そう言ってしまうとstrike1217さんの立場が……。

[Chironian]

catsforepawさんの「仕様が理解できないうちは無理して使う必要はない」は「仕様が理解できないうちに無理して使ってもよい」と言い換えることができますね。
そして、私の思いは「仕様を理解できていないなら使うな」で合っています。
こうしてみるとcatsforepawさんの思いは「多少無理してでも使って仕様を理解すべし」のように感じました。

また、学習面については、私はnoexceptを学ぶ準備が出来ている人は例外をマスターしている人と思います。そして例外の難易度は大変高く、更にnoexceptを同時に学ぶのは現実的ではない程難易度が高いと感じます。でも、例外をマスターした後ならなんてことないとも思いますし、そのようなレベルの人に「理解を促す」必要もないと思います。
catsforepawさんの見解は、「理解を促す」必要があるレベルの人でもnoexceptを学ぶ準備が出来ているということと思います。

結局、noexceptの有用性とnoexcept学習難易度に対する見解の相違と思います。
程度の問題ですからこれ以上議論しても結論を得ることはできないような気もしますが、折角整理したので書きました。ｺﾞﾒﾝﾅｻｲ

----------------------------------------
こんなに長いコメントを読む人は他に居ないかもしれませんが、念のためにこの場を借りて一つ。
noexceptの有用性は、高速化だけと私は主張していますが、１つ付け加えさせて下さい。
std::vectorはnoexceptでないムーブ・コンストラクタは採用しません。
https://qiita.com/kei10in/items/00f65e68a3d08093aceb
これは、一連のムーブ処理の途中で例外が発生すると対処できない（しづらい？）からのようです。
このような使い方はプログラムの安全性に有用な使い方と思います。

[catsforepaw]

Chironian さん

どうやらうまく伝わらなかったようですね。

> catsforepawさんの「仕様が理解できないうちは無理して使う必要はない」は「仕様が理解できないうちに無理して使ってもよい」と言い換えることができますね。

それの何がいけないのでしょうか？　無理を承知で何かをしたいと思っている相手を引き留める権利は、私にはありません（仕事の関係なら別ですが）。少なくとも、無理してでも使おうとするなら、当然仕様を理解しようという動機が生まれます。それはそれで良いことだと思います。

> こうしてみるとcatsforepawさんの思いは「多少無理してでも使って仕様を理解すべし」のように感じました。

繰り返しになりますが、使うか使わないかはどうでも良いのです。私は相手の自由意志を尊重します（仕事以外なら）。ただ、使ってみないと判らないということはありますし、使うことで仕様の理解が進むことに異論を唱える人はいないと思いますし、理解が進むのは喜ばしいことだと思うのですが、Chironianさんは違うのでしょうか？　レベルの話が出ましたが、相手のそれをどうやって判断するのでしょうか。明らかにそのレベルに達していない場合はだいたい判りますが……。

仕方がないのではっきりと書きますが、私が長々と文章を書いて反論した理由は、デメリットだけを説明して「間違えると困るから使うな」では、「どうせあんたが使うと間違えるだろうからとにかく使うな」と言っているように思えたからです。

---
> これは、一連のムーブ処理の途中で例外が発生すると対処できない（しづらい？）からのようです。
> このような使い方はプログラムの安全性に有用な使い方と思います。

私の二つ目のコメントで書いたことの延長ですね。でも否定的な返答でしたね……。

[Chironian]

どうも立ち位置の違いのような気がしてきました。
私は、ここは教育の場ではなく対等な技術者間のQAの場と考えています。
catsforepawさんの『私の主張は最初から一貫して「仕様の理解を促す」べきだということです。』からするとここは教育の場としての面が強いとお考えかもしれないですね。

> 理解が進むのは喜ばしいことだと思うのですが

それはその通りです。
そして、確かに私はnoexceptを学習することを促していません。寧ろ否定し「noexceptは安易に使うな」と警鐘を鳴らしているだけです。
しかし、ここは教育の場ではなく技術者間のQAの場と考えていますので、あまり知られていないリスクを告知するだけでも有用な行為と考えています。非難されるのは妥当ではないと感じています。

私はcatsforepawさんの立ち位置を否定するつもりはありません。教育の場として捉えて動機づけまですることは歓迎されると思います。
しかし、私はそこまでしなくてもteratailは有用と考えています。有用と考える情報を提供するまでで動機づけまでしない場合がほとんどです。catsforepawさんには、できれば私の立ち位置もご理解頂けると幸いです。

> レベルの話が出ましたが、相手のそれをどうやって判断するのでしょうか。

これは見ている方ご自身です。私は問題点を再現できる簡単なソースを提示しています。それを理解できるできないはご自身が判断されるでしょう。私ではありません。

> 「間違えると困るから使うな」では、「どうせあんたが使うと間違えるだろうからとにかく使うな」と言っているように思えたからです。

そのような意図は全くありません。メリット／デメリットを比較して機能の採用／不採用を決める方は、ご自身の裁量でメリットとデメリット情報を収集されると思います。私の説明とソースは、そのデメリット情報として有用と思います。見た方がご自身で検証できますので、決して一方的に「使うな」にはなっていないと思います。

因みに、私自身はnoexceptを使うと直ぐにバグりそうです。使うためにはかなりの工数を割く必要があるので、よほど必要でない限り使いません。例外を流出させない苦労はデストラクタだけで十分お腹いっぱいと感じてます。

[catsforepaw]

教育云々はあまり関係がありません。理解するには動機が必要であり、動機の妨げは理解の妨げと考えたまでです。教えるからには理解してほしいですから。

ここに来てようやく議論の本質が見えてきました。これは「何をリスクと捉えるか」の見解の相違のようです。
Chironianさんはnoexceptの使用をリスクと捉えているようですが、私はnoexceptの不理解をリスクと考えています。お互いリスク回避の方策をあれこれ書き連ねていたわけですね。

strike1217 さん

質問とは関係ないことを長々と書いてしまってすみませんでした。

[Chironian]

あああ、なるほど。そういうことだったのですね！
確かにstrike1217 さんには申し訳なかったです。