3. size_t u size_type

size_t u size_type

  • S

    Ist hier der Zusammenhang von size_t und size_type richtig verwendet worden?

    #include <iostream>
#include <vector>

using namespace std;

int main()
{
    string sentence = "Hallo Uschi";
    string::size_type x1 = 6;
    cout << sentence[x1] << endl; // U

    string words[3] = {"Hallo", "Bernd", "Uschi"};
    size_t x2 = 1;
    cout << words[x2] << endl; // Bernd

    return 0;
}

    Gehts euch auch so, dass sind doch so viele Typen, die kann sich doch kein Mensch merken?

    MfG
    Stromberg

    0
  • P

    basic_string<charT, traits, Allocator>::size_type ist das selbe wie Allocator::size_type. Für den standard-Allocator ist wiederum allocator<T>::size_type gleich std::size_t.
    Also ist std::string::size_type gleich std::size_t.

    Da es sich bei den size_types sowieso immer um einen vorzeichenlosen integralen Typen handeln muss, brauchst du dir um den exakt richtigen Typ keine großen Sorgen machen, wenn du bei Werten kleiner als 255 bleibst. Im Zweifel würd ich einfach std::size_t nehmen, das sollte eigentlich immer hinhauen, wenns nicht grade dick und fett in irgendeiner Doku drinsteht dass was anderes benutzt werden muss.

    0
  • E

    Ich verstehe den Unterschied von size_t und unsigned int allerdings auch nicht. Bei meinem Compiler (MSVC) scheint size_t dasselbe wie unsigned int zu sein (mit typedef definiert).
    Kann mir jemand die Unterschiede erklaeren? 🙂

    Finde es auch sehr verwirrend, dass es so viele Namensbezeichnungen fuer die selben Typen gibt.
    Ist size_t nicht in cstddef definiert? Steht zumindest so in meinem Buch ...

    Gruss
    Cartman

    0
  • P

    Eric Cartman schrieb:

    Finde es auch sehr verwirrend, dass es so viele Namensbezeichnungen fuer die selben Typen gibt.
    Ist size_t nicht in cstddef definiert? Steht zumindest so in meinem Buch ...

    Ist es: http://www.cplusplus.com/reference/clibrary/cstddef/size_t.html
    Welcher der vorzeichenlosen integralen Typen es genau ist hängt vom Compiler und der Plattform ab.
    Hier auf dem Rechner ist ein VC6-<stddef.h> mit

    typedef unsigned int size_t;

    im VC8 siehts wie folgt aus:

    #ifdef  _WIN64
typedef unsigned __int64    size_t;
#else
typedef _W64 unsigned int   size_t;
#endif
    0
  • E

    Okay...
    Kann es dann sein, dass der Threadersteller die include-Direktive fuer cstddef vergessen hat? Oder ist size_t auch in einer der Header definiert? Wenn ja, wo denn ueberall?
    Ich binde naemlich immer cstddef ein, wenn ich size_t benutzen will (z.B. um ein vector Element fuer Element zu bearbeiten).
    Sorry, bin ein absoluter Anfaenger.

    Gruss
    Cartman

    0
  • P

    Eric Cartman schrieb:

    Oder ist size_t auch in einer der Header definiert? Wenn ja, wo denn ueberall?

    Ist es, siehe oben: std::string deklariert wie oben beschrieben seinen size_type über drei Ecken als std::size_t. <iostream> wiederum bindet auf zig Ecken die Definition von basic_string mit ein (im MSVC8 ist die Kette z.B. iostream->istream->ostream->ios->xlocnum->streambuf->xiosbas->xlocale->stdexcept->xstring -> Definition von basic_stream (!))

    Ich für meinen Teil versuche normalerweise die Standard-Header einzubinden, die die von mir benutzten Typen definieren um mich nicht darauf verlassen zu müssen, dass solche Include-Ketten überall gleich sind. Bei size_t mache ich da allerdings häufig ne Ausnahme, weil in fast jedem Teil der Standardbibliothek irgendwo ein size_t auftaucht. <cstddef> einzubinden wenn man size_t benutzt ist allerdings durchaus legitim.

    0
  • E

    pumuckl schrieb:

    Eric Cartman schrieb:

    Oder ist size_t auch in einer der Header definiert? Wenn ja, wo denn ueberall?

    Ist es, siehe oben: std::string deklariert wie oben beschrieben seinen size_type über drei Ecken als std::size_t. <iostream> wiederum bindet auf zig Ecken die Definition von basic_string mit ein (im MSVC8 ist die Kette z.B. iostream->istream->ostream->ios->xlocnum->streambuf->xiosbas->xlocale->stdexcept->xstring -> Definition von basic_stream (!))

    Ich für meinen Teil versuche normalerweise die Standard-Header einzubinden, die die von mir benutzten Typen definieren um mich nicht darauf verlassen zu müssen, dass solche Include-Ketten überall gleich sind. Bei size_t mache ich da allerdings häufig ne Ausnahme, weil in fast jedem Teil der Standardbibliothek irgendwo ein size_t auftaucht. <cstddef> einzubinden wenn man size_t benutzt ist allerdings durchaus legitim.

    Vielen Dank fuer die Aufklaerung! Damit sind meine Fragen beantwortet 🙂

    Gruss
    Cartman

    0
  • N

    Welchen Sinn hat es eigentlich, dass fast jede Klasse ihren eigenen size_type mitbringt, wenn dieser schlussendlich indirekt trotzdem wieder auf std::size_t definiert ist? Oder ist das auch je nach Standardbibliothek wieder verschieden? Gibt es denn unterschiedliche Grössentypen innerhalb einer Standardbibliothek?

    0
  • S

    Nexus schrieb:

    Welchen Sinn hat es eigentlich, dass fast jede Klasse ihren eigenen size_type mitbringt, wenn dieser schlussendlich indirekt trotzdem wieder auf std::size_t definiert ist?

    Achtung.
    container::size_type wird ueber allocator::size_type definiert.
    ein standard allocator hat nun size_t als size_type.
    Aber du kannst einen eigenen allocator schreiben der OmfgMegaRiesenInteger_t als size_type hat (oder aber auch zB unsigned) und somit wird container::size_type eben diesen typen annehmen.

    Das Problem dabei ist folgendes:
    size_t kann nur limitiert viel RAM ansprechen.
    Und hard limits sind idR schlecht.
    Also braucht man einen mechanismus um unendlich viel RAM ansprechen zu koennen. Und size_type bietet eben genau das.

    0
  • D

    Nexus schrieb:

    Welchen Sinn hat es eigentlich, dass fast jede Klasse ihren eigenen size_type mitbringt, wenn dieser schlussendlich indirekt trotzdem wieder auf std::size_t definiert ist? Oder ist das auch je nach Standardbibliothek wieder verschieden? Gibt es denn unterschiedliche Grössentypen innerhalb einer Standardbibliothek?

    Mir wäre das jetzt noch nie wirklich aufgefallen, aber ich denke alleine, dass man die Möglichkeit hätte die Grössen zu ändern ohne, dass der bisherige Code verändert werden müsste ist schon ein Grund.

    0
  • N

    Shade Of Mine, vielen Dank für die Erläuterung, das macht natürlich Sinn.

    drakon, hast du dich auch auf Shades Beispiel bezogen, oder was meinst du genau?

    0
  • D

    Nexus schrieb:

    Shade Of Mine, vielen Dank für die Erläuterung, das macht natürlich Sinn.

    drakon, hast du dich auch auf Shades Beispiel bezogen, oder was meinst du genau?

    War nicht auf seinen Beitrag bezogen, habe den gar nicht gesehen, aber meinte in etwa das gleiche.

    0
Anmelden zum Antworten