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