Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。文字列値を返したい場合、その返り値の型はおおよそ次の3つに分類できるかと思います。実体を生成するパターンです。std::filesystem::path::*string()はこのパターンにあたります。m_member;}メンバ変数の参照を何らかの形で表現した型を返すパターンです。LLVMのAPIにはこのパターンが見られます。};}メンバ変数のスマートポインタを返すパターンです。参照カウントはthisと共有されます。これが用いられているのを目にしたことはありません。https://wandbox.org/permlink/xWWJWpAbCAN9UWH2それぞれに考えられるメリット、デメリットを挙げます。参照のライフタイムなどの余計な考慮が必要なくなる。長い文字列に対して呼び出しごとにコピーのコストがかかる。(RVOが有効な場合でも1回のコピーが必要。呼び出しごとのコピーが必要ない。返り値の参照の有効範囲を実装から見極める必要がある。参照先の変更に影響される。内部にstd::stringを直接的/間接的に実体として持つことを要求する。参照の有効範囲の考慮が必要ない。参照先の変更に影響される。(例の場合)クラスがshared_ptrによって管理されることを要求する。どのパターンがふさわしいか意見をお聞かせください。条件:C++11以降である。(十分長い文字列も入りうる。)RVOを期待できる。対象のメンバは他のメンバ関数などによって値を変更されることはない。頻繁に呼ばれる可能性がある。元質問文に追記していただけると幸いです。2:28std::string_viewを用いてはいるのですが、これはC++11以降であればboost::string_ref/boost::string_viewなどのように同様のクラスを簡単に作成できること、また質問内容に直接影響するような言語機能の追加はそれよりあとの規格にはないことからC++11以降を想定します。それを質問文の条件以下に追記しました。constを使っています。interesting}のような使い方の場合は、その場で値を見るだけなので、参照を気にする必要がありません。&rs{obj.getString()};のような場合は、参照を気にする必要がありますが、明示的に参照を使っているのですから、責任は呼び出し側にあると考えます。getString()は、メンバ関数で動的に文字列を生成するときにしか使っていません。std::filesystem::path::stringも、おそらく、そのような実装を想定していると思います。個の銅バッジUncle-Keisさんの回答と同じく目的により返り値型を変えるものですね。std::filesystem::path::string系の関数にはエンコーディング変換の処理が行われるため仰る通りだと思います。(同時にpathの場合にはpath::nativeが内部文字列への参照を直接に出力できますね。目的に応じて参照の出力/実体の出力を使い分けるべきであると考えるようにしたいと思います。|2個人的な方針について述べてみます。他にもあると思いますが、ありがちな2つの目的について考えてみました。目的(a).対象クラスに固有の文字列を取得する場合。目的(b).対象クラスに文字列演算を依頼する場合。質問にはいわゆる(getter)を想定すると明言されていますので目的(a)を想定しているのかもしれません。個人的には目的(a)の場合は方法2.を使います。方法1.はプロトタイプだけから判別すると、原理的には合理的な時間内で完了する保障がないと見積もられるためです。自分の小さなグループ内ではレギュレーション違反と判定されるかもしれません。(実装の内部を見ることができないという条件です)目的(b)の場合は、加工結果を入れる文字列クラス(の参照又はポインタ)を引数で渡すことにしています。戻り値で戻したいケースも(おおいに)あるのですが、この実装方法によって、ネストしたコードを書きにくくなることを目的としています。(ネストがきつくなると実行速度はたして改善しないわりに、可読性がひどく落ちるため。)従って、戻り値に文字列を戻すことはありえません。方法3.は単体のクラスでなくてよいという条件になると解釈できます。この条件であれば、その目的に最も適した実装を選択できます。ゆえに、なんとも言えません。以上から、個人的には方法2.だけが選択可能という結論になります。個の銅バッジ目的により出力の方法を変えることで、外部に公開されるインターフェースから内部の実装を想像させるという思想ですね。参照で渡すことを規約と定めるのはその種の可読性を期待出来るものと思います。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。メンバー関数内でクラスをnewしていないことの確認0可変長引数テンプレートメンバ関数へのポインタ。その引数が期待通りにならない。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。