Quote:
Originally Posted by Schlüsselbein
Wenn die Objekte schon unbedingt aufm Heap liegen sollen, dann benutze wenigstens smart pointer.
|
Da er anscheinend ein Array mit dynamisch veränderbarer Größe haben möchte, sind Smart Pointer hier keine Lösung, sondern lediglich ein unnötiger Overhead - unique_ptr ist nicht CopyConstructible (zwar noexcept MoveConstructible, aber das nicht in der Implementation von VS2012 Nov'12 CTP) und shared_ptr hat einen unnötigen Overhead.
---
Quote:
Originally Posted by Shadow992
Dass ich ein Copy ausführen muss versuchte mir Google auch klar zu machen. Aber genau das wollte ich nicht. Ich will nicht alle Elemente, die eventuell nicht einmal verändert wurden, neu beschreiben.
|
Um das kopieren kommt man nicht drumherum: Man kann weder via malloc noch new[] (und ähnlichen) sagen, dass der reservierte Speicher erweitert werden soll, weil dort ja bereits anderes liegen könnte. Man kann lediglich komplett neu allozieren, das alte kopieren und dann das alte freigeben. Intern macht realloc das gleiche, indem es malloc, memcpy und free benutzt.
In C++ aber sollte man nie memcpy benutzen, wenn man nicht POD-Datentypen (POD = Plain-Old-Data) kopiert. Der Hintergrund ist, dass Klassen einen CopyConstructor definieren können, der bei std::string intern etwas macht, dass mit memcpy nicht erreicht werden kann.
Quote:
Originally Posted by Shadow992
Meine Idee war wie du beschrieben hast einen Pointer auf den assozierten Speicher zu geben und dann auf basis dieses Speichers die String-Objekte zu erstellen.
Mir geht es also prinzipiell um eine equivalente Methode zur Reassoziierung von Speicher für komplexe Speichertypen.
|
Zunächst einmal verwechselst du anscheinend die Bedeutung der Wörter allozieren und assoziieren. Das sind zwei total verschiedene Dinge. Und zum Rest: Das ist Schwachsinn. Die einzige Methode, mit der du um das Kopieren herum kommst, ist eine Linked-List wie etwa std::list, die jedoch beim Zugriff auf die Array-Elemente vom Index abhängig langsamer ist.
Quote:
Originally Posted by Shadow992
Mir geht es hier gar nicht um die Anwendbarkeit oder die Geschwindigkeit dieser Methode, sondern nur um die Möglichkeit ohne erneutes Kopieren ein Array zu vergrößern und zwar ohne std::vector.
|
Ein Array ohne Kopie zu vergrößern ist nicht ohne weiteres machbar. Dennoch kann man mit Tricks zumindest bis zu einem gewissen Limit etwas ähnliches erreichen:
Code:
template <typename T, size_t N>
class storage
{
typedef typename std::aligned_storage<sizeof(T) * N, alignof(T)>::type storage_type;
storage_type data_;
T *end_;
public:
storage() : end_(reinterpret_cast<T *>(std::addressof(data_)))
{
}
~storage()
{
for (T &obj : *this)
obj.~T();
}
T &operator[](size_t index)
{
if (std::addressof(data_) >= end_)
throw std::out_of_range("out of range");
return *(reinterpret_cast<T *>(std::addressof(data_)) + index);
}
template <typename... Args>
void emplace(Args &&... args)
{
if (end_ >= &end_)
throw std::bad_alloc();
new(end_++) T(std::forward<Args>(args)...);
}
T *begin()
{
return reinterpret_cast<T *>(std::addressof(data_));
}
T *end()
{
return end_;
}
};
Das kann in so verwendet werden, dass man z.B. via storage st<std::string, 1000> Platz für 1000 std::string Objekte reserviert. Via st.emplace(...) werden diese dann erzeugt und via st[index] können diese benutzt werden. Das ist übrigens in etwa wie std::vector, nur dass dieser Platz für die Objekte dynamisch reserviert und bei Bedarf mehr alloziert und dann aber auch kopiert. Da du dies ja vermeiden möchtest ist diese Lösung eine der elegantesten, die ich mir vorstellen kann.