Eigener Vector
-
Swordfish schrieb:
Für Speichergrößen verwendet man in der Regel
std::size_t.Auch
xy::size_type,unsigned intoderstd::ptrdiff_t(unter Anderem).std::size_twird vielleicht am häufigsten verwendet, aber nicht einmal die Standardbibliothek ist diesbezezüglich konsistent.
-
Nexus schrieb:
Auch
xy::size_type,unsigned intoderstd::ptrdiff_t(unter Anderem).Da gibt es aber feine Unterschiede zwischen dem, was diese Datentypen/typedefs bedeuten.
std::size_twird vielleicht am häufigsten verwendet, aber nicht einmal die Standardbibliothek ist diesbezezüglich konsistent.Wo denn nicht?
-
std::vector<X> vec = ...; std::size_t n = vec.size(); std::ptrdiff_t m = std::count(vec.begin(), vec.end(), x);std::istream& stream = ...; std::vector<char> data = ...; stream.read(&data[0], data.size()); // std::size_t -> std::streamsizeAuch ist die Bedeutung nicht immer exakt die gleiche.
std::size_tsteht zwar für irgendeine Grösse, kann aber sowohl Anzahl Elemente als auch Anzahl Bytes bedeuten.Von Member-Typedefs wie
size_typeoderdifference_typewill ich gar nicht erst anfangen. Gibt es eigentlich Leute, welche diese konsequent im Programm nutzen?
-
Nexus schrieb:
Von Member-Typedefs wie
size_typeoderdifference_typewill ich gar nicht erst anfangen. Gibt es eigentlich Leute, welche diese konsequent im Programm nutzen?size_typeja,difference_typenie.
-
Nexus schrieb:
Swordfish schrieb:
Für Speichergrößen verwendet man in der Regel
std::size_t.Auch
xy::size_type,unsigned intoderstd::ptrdiff_t(unter Anderem).unsigned int? Wo steht das? IMHO garantiert der Standard, daß Speichermengen immer instd::size_tpassen - beiunsigned intist das ein Ratespiel.Nexus schrieb:
std::size_twird vielleicht am häufigsten verwendet, aber nicht einmal die Standardbibliothek ist diesbezezüglich konsistent.Wenn eine Implementierung der STL an entsprechenden Stellen nicht
std::size_t,container::size_typebzw. entsprechende verwendet, ist sie kaputt.
-
size_type stammt vom verwendeten Allokator. Und der default allocator muss hierfür size_t benutzen.
streams sind keine Container, insbesondere können entsprechende Files ja ohne weiteres größer sein, als durch size_t (32-bit System) darstellbar. Logischerweise ist hier size_t nicht angebracht.
-
camper schrieb:
size_type stammt vom verwendeten Allokator. Und der default allocator muss hierfür size_t benutzen.
Und wieder was gelernt...
Allerdings drückt es die Intention wieder besser aus, finde ich - was aber schnell zu einem kryptischen
typename-Gefrickel werden kann.
-
Swordfish schrieb:
unsigned int?Einige Bibliotheken benutzen
intoderunsigned int, um Objekte zu zählen -- also auch Speichergrösse, wenn letztere sich in Containern befinden. Das ist übrigens auch, was mir nicht gefällt: Korrekterweise müsste man ständigstd::size_tweiterreichen, auch wenn in einem High-Level-Kontext andere Datentypen verwendet werden (und Container Implementierungsdetails sind).Swordfish schrieb:
IMHO garantiert der Standard, daß Speichermengen immer in
std::size_tpassen - beiunsigned intist das ein Ratespiel.Das stimmt (sollte auf heutigen Plattformen aber erst bei Grössen ab 2^32 relevant werden).
camper schrieb:
size_type stammt vom verwendeten Allokator. Und der default allocator muss hierfür size_t benutzen.
Ja. Die Typedefs existieren doch, um andere Typen zu ermöglichen... Nutzt das jemand?
camper schrieb:
streams sind keine Container, insbesondere können entsprechende Files ja ohne weiteres größer sein, als durch size_t (32-bit System) darstellbar. Logischerweise ist hier size_t nicht angebracht.
Danke für die Erklärung. Bedeutet das, dass ein
std::size_timmer problemlos in einenstd::streamsizekonvertierbar ist (kompatibler Typ, kein Datenverlust)?
-
n3337 schrieb:
27.5.2 Types [stream.types]
typedef implementation-defined streamoff;
1 The type streamoff is a synonym for one of the signed basic integral types of sufficient size to represent
the maximum possible file size for the operating system.296
typedef implementation-defined streamsize;
2 The type streamsize is a synonym for one of the signed basic integral types. It is used to represent
the number of characters transferred in an I/O operation, or the size of I/O buffers.297- streamsize is used in most places where ISO C would use size_t. Most of the uses of streamsize could use size_t,
except for the strstreambuf constructors, which require negative values. It should probably be the signed type corresponding
to size_t (which is what Posix.2 calls ssize_t).
- streamsize is used in most places where ISO C would use size_t. Most of the uses of streamsize could use size_t,
-
Also nein.