はい、別のrealloc質問とstd::vector質問です。私はあなたが何を言おうとしているのか知っています、そして私は同意します、手動のメモリ割り当てを忘れて、そしてただを使用しstd::vectorます。残念ながら、私の教授は、この割り当てにSTLの何かを使用することを禁じています。
そうですね、私はの動的配列を持っていて、Tサイズを変更できる必要があり、を使用することはできませんstd::vector。私は暗黒時代に戻りmalloc、家族と一緒にすべてを行うことができましたが、それを使用できれば、それnewは完全に素晴らしいことです。
みんなが「いや、できない、使うstd::vector」と言っているスレッドをたくさん読んだのですが、2011年8月以前に投稿されたもので、C+の黎明期から何かが変わったのではないかと期待しています。 +11。それで、教えてください、私は運がいいですか、それともCスタイルのメモリ割り当てに戻す必要がありますか？
reallocそのようなC++オブジェクトを移動することはできないため、とにかく完全に 回避する必要があります。
buf = new unsigned char[sizeof(T) * capacity]新しいバッファを作成するために使用しますunsigned char *これらT *のTポインタを今後使用しますnewのように、「配置」を介して新しい要素を構築しますnew (&buf[i]) T(original_copy)std::uninitialized_copy（ではなく std::copy）を使用してから、を使用して古いバッファの要素を破棄し、を使用buf[i].~T()して古いバッファの割り当てを解除しますdelete [] buf。これはすべて、例外安全性について心配する必要がないことを前提としています。これはおそらく割り当てには問題ありません。
実際のコードでは、例外の安全性を保証する必要があり、これよりもはるかに面倒であることに注意してください。
The problem with realloc is that is may move the existing data to a different range of contiguous addresses. Should it need to do so, given it's a C function the data is copied without any nod to C++ object lifetime:
This can cause fatal consequences - for example, when the objects being moved contain pointers/references that remain pointing at addresses in the memory area being vacated.
Sadly, normal malloc implementations don't allow a callback hook allowing you to replace the memory-content-copying code with your own C++-safe implementation. If you're determined you could try to find a more flexible "malloc" library, but it's unlikely to be worth the hassle and risk.
Consequently, in the general case you should use new to change your capacity, copy/move each object, and delete the originals afterwards.
If you're certain your data is simple enough that a memcpy-style relocation won't cause adverse consequences, then you can use realloc (at your own risk).