Unterschiedliche Typen obwohl eigentlich gleich?

unskilled

warner schrieb:

weil ich zb weiter unten den Wert an eine Funktion übergebe, die ein uint erwartet..)

selbst geschrieben?
eigtl kann ich mir kaum vorstellen, warum man uint dem size_t vorziehen sollte...
ich würd an deiner stelle also die fkt ändern, wenn du sie selbst geschrieben hast... ansonsten würde ich die warning da lassen, da man sonst vll ungewollt den index "beschneidet", wenn man auf ner x64 plattform arbeitet...

bb

unskilled schrieb:

warner schrieb:

weil ich zb weiter unten den Wert an eine Funktion übergebe, die ein uint erwartet..)

selbst geschrieben?
eigtl kann ich mir kaum vorstellen, warum man uint dem size_t vorziehen sollte...
ich würd an deiner stelle also die fkt ändern, wenn du sie selbst geschrieben hast... ansonsten würde ich die warning da lassen, da man sonst vll ungewollt den index "beschneidet", wenn man auf ner x64 plattform arbeitet...

bb

Wieso sollte ich meine Funktion umschreiben? Mein uint hab NICHTS mit einer Größe zu tun - es ist einfach ein vorzeichenloser Int (abgesehen davon, dass ich uint wesentlich schöner als size_t finde)
Ich caste jetzte einfach den size_t auf meinen uint.

unskilled

warner schrieb:

Mein uint hab NICHTS mit einer Größe zu tun

offensichtlich schon - sonst müsstest du nich iwann mal von nem size_t her casten...

Nein - cast würd ich aus oben genannten Gründen nicht nehmen...

und welche Nachteile hat denn ein size_t (dort) ggnüber dem uint?

die warnings sind eben nicht ganz um sonst da - aber wenn du es für den richtigen weg hältst, es mit nem cast zu lösen, dann lass es halt so - vll gibts deshalb iwann mal ne ganze menge unerklärlicher fehler, aber vll gehts auch gut...
wenn du nicht für x64 programmieren willst, dann kannst du die kompatibilitätswarnungen auch deaktiveren und dann ist so gar der cast unnötig.

bb

audacia

unskilled schrieb:

warner schrieb:

Mein uint hab NICHTS mit einer Größe zu tun

offensichtlich schon - sonst müsstest du nich iwann mal von nem size_t her casten...

Offensichtlich hast du seinen Post nicht gelesen.

warner schrieb:

uint resultDimension = coordVectors.size();

Wenn seine Nomenklatur aussagekräftig ist, will er die Dimension eines Vektors feststellen. Ob und inwiefern sein Ansatz dafür angebracht ist, kann ohne mehr Code freilich nicht beurteilt werden - aber auch die Aussage "Mein uint hat NICHTS mit einer Größe zu tun" ist IMHO hinreichend eindeutig. std::vector<>::size() gibt nun mal size_t zurück; in einer konsequenten Anwendung der Analogie aus der Mathematik hätte die Methode dimension() geheißen und uint zurückgegeben. (Ich will nicht sagen, daß das für den Anwendungszweck von std::vector<> angemessener wäre - eher, daß die gewählte Analogie fraglich ist und die Klasse std::array<> hätte heißen sollen.) Entsprechend sehe ich keinen Grund, size_t für irgendetwas zu verwenden, das keine Größe ist.

hustbaer

Entsprechend sehe ich keinen Grund, size_t für irgendetwas zu verwenden, das keine Größe ist.

Eine Dimensions-Anzahl *ist* eine Grösse.

Schwachsinn. size_t hat klar einen Bezug zu Größe wie Größe eines Vektors. Wenn man Funktionen hat, die einfach einen unsigned int brauchen um damit Dinge wie Rekursionstiefe, Indizes etc zu beschreiben, würde ich auch niemals size_t nehmen.

unskilled

hustbaer schrieb:

...

/signed

audacia

Ah, ich bin dir zu unpräzise

Du liegst natürlich richtig; die Zahl der Dimensionen ist eine Größe. Die Frage ist aber eher, was size_t aussagt, und das ist meist:
- Eine Anzahl von Bytes, etwa bei sizeof() und vielen C-Funktionen, oder
- Eine Anzahl von Elementen einer Datenstruktur.

Schon diese beiden hätte man besser auseinandergehalten; ein besonders schönes Beispiel ist

size_t fread (void* ptr, size_t size, size_t count, FILE* stream);

. Was gibt fread() zurück: die Zahl der gelesenen Bytes, oder die Zahl der Elemente? Und welches der size_t -Argumente ist nun welches? Es wäre viel offensichtlicher, wenn die Funktion als

number_t fread (void* ptr, size_t size, number_t count, FILE* stream);

definiert wäre.

(Daß size_t eher mit einer Byte-Anzahl zu assoziieren ist, rechtfertige ich primär damit, daß das grundlegende Sprachelement sizeof() in size_t resultiert.)

Nun bedient sich, wie ich oben bereits erwähnte, die Standardbibliothek einer fragwürdigen Metapher, nämlich der des Vektors. Mit einem solchen hat eine Datenstruktur, die die push_back() -Semantik unterstützt und überhaupt eine variable Elementzahl hat, herzlich wenig zu tun. Gehen wir also davon aus, wir dürften die Datenstruktur std::array<> und die fragliche Funktion count() oder length() taufen - was gäbe sie zurück? Wenn es existierte, böte sich number_t an, doch der Standard definiert nur size_t , und aufgrund oben ausgeführter Ambiguität ist es dann durchaus legitim, für diesen Zweck stattdessen int oder uint zu verwenden wie in jeder anderen Sprache auch.

Tachyon

audacia schrieb:

Nun bedient sich, wie ich oben bereits erwähnte, die Standardbibliothek einer fragwürdigen Metapher, nämlich der des Vektors.

Und was soll daran fragwürdig sein? In der Informatik ist "Vektor" ein gängiger Begriff (und synonym) für n-Tupel.
Außerdem sollte man besser std::vector<T>::size_type benutzen. Das ist zwar i.d.R. das Gleiche wie size_t , aber das muss nicht so sein.
Und wenn der Typ keine Größe sondern was anderes ausdrücken soll, dann den den Typen nach dem was er sein soll. unsigned int ist auch nicht sonderlich sprechend.

typedef std::vector<T>::size_type TypeForSomethingThatDependsOnSizeButIsNotSize;
TypeForSomethingThatDependsOnSizeButIsNotSize something = vec.size();

unsigned int und size_t zu mischen, ist so ziemlich eine von den dümmsten Sachen, die man machen kann, wenn man will, dass ein Programm auch Fehlerfrei auf 64 Bit Maschinen läuft.