CまたはC ++で構造体を返すのは安全ですか？

私が理解しているのは、これを行うべきではないということですが、このようなことを行う例を見たことがあると思います（コードは必ずしも構文的に正しいとは限りませんが、アイデアはそこにあります）

typedef struct{
    int a,b;
}mystruct;

そして、ここに関数があります

mystruct func(int c, int d){
    mystruct retval;
    retval.a = c;
    retval.b = d;
    return retval;
}

このようなことをしたい場合は、mallocされた構造体へのポインターを常に返す必要があることを理解しましたが、このようなことを行う例を見たことがあると確信しています。これは正しいです？個人的には、常にmallocされた構造体へのポインターを返すか、関数を参照してパスを実行し、そこで値を変更します。（私の理解では、関数のスコープが終了すると、構造を割り当てるために使用されたスタックはすべて上書きされる可能性があります）。

質問に2番目の部分を追加しましょう：これはコンパイラによって異なりますか？もしそうなら、デスクトップ用のコンパイラの最新バージョン（gcc、g ++、Visual Studio）の動作はどうなりますか？

問題についての考え？

それは完全に安全であり、そうすることは間違いではありません。また、コンパイラによって異なりません。

通常、（あなたの例のように）構造体が大きすぎない場合、このアプローチは、mallocされた構造体を返すよりも優れていると主張します（mallocコストのかかる操作です）。

それは完全に安全です。

あなたは価値によって戻ってきています。未定義の動作につながるのは、参照によって戻ってきた場合です。

//safe
mystruct func(int c, int d){
    mystruct retval;
    retval.a = c;
    retval.b = d;
    return retval;
}

//undefined behavior
mystruct& func(int c, int d){
    mystruct retval;
    retval.a = c;
    retval.b = d;
    return retval;
}

スニペットの動作は完全に有効であり、定義されています。コンパイラによって異なりません。大丈夫です！

個人的には、mallocされた構造体へのポインタを常に返します。

あなたはすべきではありません。可能な場合は、動的に割り当てられたメモリを避ける必要があります。

または、関数を参照してパスを実行し、そこで値を変更します。

このオプションは完全に有効です。それは選択の問題です。一般に、元の構造体を変更しながら、関数から何か他のものを返したい場合は、これを行います。

私の理解では、関数のスコープが終了すると、構造を割り当てるために使用されたスタックはすべて上書きされる可能性があります

これは間違っています。つまり、それは一種の正しいことですが、関数内で作成した構造体のコピーを返します。理論的には。実際には、RVOは発生する可能性があり、発生する可能性があります。戻り値の最適化について読んでください。これはretval、関数が終了するとスコープ外に見えるが、余分なコピーを防ぐために、実際には呼び出し元のコンテキストでビルドされる可能性があることを意味します。これは、コンパイラーが自由に実装できる最適化です。

mystruct関数内のオブジェクトの存続期間は、関数を終了すると実際に終了します。ただし、returnステートメントでオブジェクトを値で渡します。これは、オブジェクトが関数から呼び出し元の関数にコピーされることを意味します。元のオブジェクトはなくなりましたが、コピーは存続しています。

structCでaを返すのが安全であるだけでなく（またはclassC ++で、struct-sは実際にclassはデフォルトのpublic:メンバーで-esです）、多くのソフトウェアがそれを行っています。

^{もちろん、classC ++でを返すとき、言語はいくつかのデストラクタまたは移動コンストラクタが呼び出されることを指定しますが、これがコンパイラによって最適化される可能性がある場合が多くあります。}

さらに、Linux x86-64 ABIはstruct、2つのスカラー（たとえば、ポインター、またはlong）値を持つをレジスター（%rax＆%rdx）を介して返すことを指定しているため、非常に高速で効率的です。したがって、その特定のケースでは、struct他のことを行うよりも、そのような2スカラーフィールドを返す方がおそらく高速です（たとえば、引数として渡されるポインターにそれらを格納する）。

そのような2スカラー場を返すことは、それを-ingしてポインタを返すstructよりもはるかに高速ですmalloc。

これは完全に合法ですが、構造体が大きい場合は、速度とスタックサイズという2つの要素を考慮する必要があります。

構造体型は、関数によって返される値の型にすることができます。コンパイラは構造体のコピーを作成し、関数内のローカル構造体ではなくそのコピーを返すため、安全です。

typedef struct{
    int a,b;
}mystruct;

mystruct func(int c, int d){
    mystruct retval;
    cout << "func:" <<&retval<< endl;
    retval.a = c;
    retval.b = d;
    return retval;
}

int main()
{
    cout << "main:" <<&(func(1,2))<< endl;


    system("pause");
}

安全性は、構造体自体がどのように実装されたかによって異なります。似たようなものを実装しているときにこの質問に出くわしました。これが潜在的な問題です。

コンパイラは、値を返すときに、いくつかの操作を実行します（おそらく他の操作もあります）。

1. コピーコンストラクターを呼び出しますmystruct(const mystruct&)（コンパイラー自体によって割り当てられた関数の外部のthis一時変数です）func
2. ~mystruct内部に割り当てられた変数のデストラクタを呼び出しますfunc
3. mystruct::operator=戻り値が他の何かに割り当てられている場合に呼び出す=
4. ~mystructコンパイラが使用する一時変数でデストラクタを呼び出します

さて、場合は、mystructここに記載されているような、単純なようであることは、すべての罰金ですが、それはポインタ（のように持っている場合char*）、またはより複雑なメモリ管理を、それはすべての方法に依存しmystruct::operator=、mystruct(const mystruct&)、および~mystruct実装されています。したがって、複雑なデータ構造を値として返す場合は注意が必要です。

行ったように構造体を返すことは完全に安全です。

ただし、このステートメントに基づくと、関数のスコープが終了すると、構造体の割り当てに使用されたスタックはすべて上書きできると理解しているため、構造体のメンバーのいずれかが動的に割り当てられたシナリオのみを想像します（ malloc'edまたはnew'ed）。この場合、RVOがないと、動的に割り当てられたメンバーは破棄され、返されるコピーには、ガベージを指すメンバーが含まれます。

私もsftrabbitに同意します。Lifeは実際に終了し、スタック領域はクリアされますが、コンパイラはすべてのデータをレジスタまたはその他の方法で確実に取得できるほど賢いです。

確認のための簡単な例を以下に示します（Mingwコンパイラアセンブリから取得）

_func:
    push    ebp
    mov ebp, esp
    sub esp, 16
    mov eax, DWORD PTR [ebp+8]
    mov DWORD PTR [ebp-8], eax
    mov eax, DWORD PTR [ebp+12]
    mov DWORD PTR [ebp-4], eax
    mov eax, DWORD PTR [ebp-8]
    mov edx, DWORD PTR [ebp-4]
    leave
    ret

bの値がedxを介して送信されていることがわかります。デフォルトのeaxにはaの値が含まれています。

構造を返すことは安全ではありません。私は自分でそれを行うのが大好きですが、誰かが後で返された構造にコピーコンストラクターを追加すると、コピーコンストラクターが呼び出されます。これは予期しないことであり、コードを壊す可能性があります。このバグを見つけるのは非常に困難です。

もっと詳しく答えましたが、モデレーターは気に入らなかった。だから、あなたの費用で、私のヒントは短いです。

質問に2番目の部分を追加しましょう：これはコンパイラによって異なりますか？

私が自分の痛みを発見したように、確かにそうです：http： //sourceforge.net/p/mingw-w64/mailman/message/33176880/

私はwin32（MinGW）でgccを使用して、構造体を返すCOMインターフェイスを呼び出していました。MSはGNUとは異なる方法で処理するため、私の（gcc）プログラムはスタックが破壊されてクラッシュしました。

ここではMSの方が高いかもしれませんが、私が気にしているのは、Windows上で構築するためのMSとGNU間のABI互換性だけです。

含まれている場合、デスクトップ用の最新バージョンのコンパイラ（gcc、g ++、およびVisual Studio）の動作はどうなりますか。

MSがどのようにそれを行っているように見えるかについてのいくつかのメッセージをWineメーリングリストで見つけることができます。

注：この回答はc ++ 11以降にのみ適用されます。「C / C ++」のようなものはなく、異なる言語です。

いいえ、ローカルオブジェクトを値で返す危険はありません。そうすることをお勧めします。しかし、ここでのすべての答えに欠けている重要な点があると思います。他の多くの人は、構造体がコピーされているか、RVOを使用して直接配置されていると述べています。ただし、これは完全には正しくありません。ローカルオブジェクトを返すときに発生する可能性のあることを正確に説明しようと思います。

移動セマンティクス

c ++ 11以降、安全に盗むことができる一時オブジェクトへの参照である右辺値参照がありました。例として、std :: vectorには、ムーブコンストラクターとムーブ代入演算子があります。これらは両方とも一定の複雑さを持ち、移動元のベクトルのデータへのポインターをコピーするだけです。ここでは、移動セマンティクスについて詳しくは説明しません。

関数内でローカルに作成されたオブジェクトは一時的なものであり、関数が戻るとスコープ外になるため、返されたオブジェクトがc ++ 11以降でコピーされることはありません。移動コンストラクターは、返されるオブジェクトで呼び出されます（または、後で説明します）。つまり、大きなベクターのように、高価なコピーコンストラクターで安価な移動コンストラクターを使用してオブジェクトを返す場合、データの所有権のみがローカルオブジェクトから返されたオブジェクトに転送されます。これは安価です。

特定の例では、オブジェクトのコピーと移動に違いはないことに注意してください。構造体のデフォルトのmoveおよびcopyコンストラクターは、同じ操作になります。2つの整数をコピーします。ただし、構造体全体が64ビットCPUレジスタに収まるため、これは少なくとも他のソリューションよりも高速です（間違っている場合は訂正してください。CPUレジスタについてはあまり知りません）。

RVOとNRVO

RVOは戻り値の最適化を意味し、コンパイラが実行する数少ない最適化の1つであり、副作用が発生する可能性があります。c ++ 17以降、RVOが必要です。名前のないオブジェクトを返す場合、呼び出し元が戻り値を割り当てる場所に直接構築されます。コピーコンストラクターも移動コンストラクターも呼び出されません。RVOがないと、名前のないオブジェクトは最初にローカルで構築され、次に返されたアドレスで構築されて移動し、次にローカルの名前のないオブジェクトが破棄されます。

RVOが必要な場合（c ++ 17）または可能性が高い場合（c ++ 17より前）の例：

auto function(int a, int b) -> MyStruct {
    // ...
    return MyStruct{a, b};
}

NRVOは、名前付き戻り値の最適化を意味し、呼び出された関数にローカルな名前付きオブジェクトに対して実行されることを除いて、RVOと同じです。これはまだ標準（c ++ 20）によって保証されていませんが、多くのコンパイラはまだそれを行っています。名前付きのローカルオブジェクトを使用しても、返されるときに最悪の場合は移動されることに注意してください。

結論

値で返さないことを検討する必要がある唯一のケースは、名前が付けられた非常に大きい（スタックサイズのように）オブジェクトがある場合です。これは、NRVOがまだ保証されておらず（c ++ 20以降）、オブジェクトの移動でさえ遅いためです。私の推奨事項、およびCppコアガイドラインの推奨事項は、常に値でオブジェクトを返すことを優先することです（複数の戻り値がある場合は、struct（またはタプル）を使用します）。唯一の例外は、オブジェクトの移動にコストがかかる場合です。その場合は、非const参照パラメーターを使用してください。

C ++の関数から手動で解放する必要があるリソースを返すことは決して良い考えではありません。絶対にしないでください。少なくともstd :: unique_ptrを使用するか、リソースを解放するデストラクタ（RAII）を使用して独自の非ローカルまたはローカル構造体を作成し、そのインスタンスを返します。リソースに独自の移動セマンティクスがない場合は、移動コンストラクターと移動代入演算子を定義する（およびコピーコンストラクター/代入を削除する）こともお勧めします。