ほとんどのコードでCStringクラスを使用しています。ただし、char*に変換する必要がある場合もあります。現時点では、variable.GetBuffer（0）を使用してこれを行っており、これは機能しているようです（これは主に、関数がchar *を必要とする関数にCstingを渡すときに発生します）。関数はこれを受け入れ、続行します。
しかし、私たちは最近、これがどのように機能するか、そしてそれを行うためのより良い方法があるかどうかについて心配しています。
私がそれが機能することを理解する方法は、CStringの最初の文字を指す関数にcharポインターを渡し、すべてがうまく機能することです。
メモリリークや、これが適切ではない可能性のある予期しない状況について心配しているだけだと思います。
関数が文字列の読み取りのみを必要とし、変更を必要としない場合は、const char *の代わりに受け入れるように変更しますchar *。はCString自動的に変換されます。これがほとんどの MFC 関数のしくみであり、非常に便利です。(実際にはLPCTSTR、MFC は - の同義語である を使用し、 const TCHAR *MBC ビルドと Unicode ビルドの両方で機能します)。
文字列を変更する必要がある場合、GetBuffer(0)非常に危険です。結果の文字列に十分なメモリが割り当てられるとは限らず、バッファ オーバーラン エラーが発生する可能性があります。
ReleaseBuffer他の人が言及したように、 afterを使用する必要がありますGetBuffer。への変換のためにそれを行う必要はありませんconst char *。
@ the OP: >>> メモリリークか何かが心配なだけだと思います...
こんにちは、GetBuffer メソッドを呼び出してもメモリ リークは発生しません。とにかく、デストラクタはバッファの割り当てを解除するためです。ただし、このメソッドの呼び出しに関する潜在的な問題について、他の人がすでに警告しています。
@Can >>> getbuffer 関数を呼び出すと、メモリが割り当てられます。
この声明は完全に真実ではありません。GetBuffer(0) はメモリを割り当てません。CString クラスの「外部」から文字列を直接操作するために使用できる内部文字列バッファへのポインタを返すだけです。
ただし、GetBuffer(N) のように N などの数値を渡す場合、N が現在のバッファーの長さよりも大きい場合、関数はより多くのメモリを割り当てることによって、返されるバッファーが少なくとも N と同じ大きさであることを保証します。 .
乾杯、ラジェッシュ。MVP、ビジュアル++。
getbuffer関数を呼び出すと、メモリが割り当てられます。使い終わったら、releasebufferを呼び出して割り当てを解除する必要があります
そのヘルプについては、 http：//msdn.microsoft.com/en-us/library/awkwbzyc.aspxのドキュメントを試してください。