0

これには別の質問が必要だとは思わないので、この非常に関連性の高い質問を編集しています。

char* から wchar_t* に変換してテキストを描画するコードがありましたが、プログラム メモリが異常なペース (数分で 5,000 K から 1,500,000 に) 増加するため、メモリ エラーが疑われました。

私は mbstowcs() を疑っていましたが、今では問題を発見したと思います。

私は一般的に物事を描くために色を取得するかなり悪い方法を使用しています。

class MainClass {
    public:
        ID2D1SolidColorBrush* custom_color;
        ID2D1SolidColorBrush  get_rgba(float r, float g, float b, float a) {
            // render is a validated ID2D1RenderTarget*
            render->CreateSolidColorBrush(D2D1::ColorF(r,g,b,a),&custom_color);
            return custom_color;
        }
};

メモリ使用量の増加は、ほぼ確実にこの機能によるものです。このようなカスタム色を返すより良い方法はありますか?

4

3 に答える 3

1

実際にメモリ リークが発生しているようには見えません。また、メモリ リーク ツールによって報告される多くの「リーク」は、誤検知である場合があります。ただし、リークの可能性がある nxtx を排除するための簡単な修正方法が 1 つあります。毎回固定量 (250 文字) を割り当てているため、これをスタックから簡単に割り当てることができます。

    const int MY_MAX_STRING_SIZE = 1000;
    wchar_t ntxt[MY_MAX_STRING_SIZE]; // simple stack allocation
    mbstowcs(ntxt,text.c_str(),MY_MAX_STRING_SIZE);
    ntxt[MY_MAX_STRING_SIZE-1] = 0; //insure null termination
    render->DrawTextA(ntxt,text.length(),font,trect,color);
}

私が気づいたことの 1 つは、あなたの mbstowc 呼び出しがコピーする文字の最大数として「サイズ」を指定しているが、長さとして 250 をハードコーディングしていることです。「サイズ」が常に250未満であると確信していますか?

于 2013-03-01T07:21:44.003 に答える
0

私の問題は、カラー変数として ID2D1SolidColorBrush* を返すコードにありました。このコードは、呼び出されるたびに Release ではなく Create() を実行していたため、ブラシが蓄積されてメモリ リークが発生していました。

于 2013-03-01T23:08:10.460 に答える
0

メモリリークがあるため、見た目は良くありません。しかし、危険な動作があるかもしれません: mbstowcsは dest のwchar_tの最大長を受け入れますが、文字列の長さを指定します。これを修正します：

    int size=text.length()+1;
    enum { NTXT_LEN = 250 };
    wchar_t* ntxt= new wchar_t[NTXT_LEN];
    mbstowcs(ntxt, text.c_str(), NTXT_LEN);

また、 raw newをscoped_arrayのようなものに置き換える価値があります

于 2013-03-01T07:24:17.470 に答える