Ich habe folgende Zeile:

uint resultDimension = coordVectors.size();

Diese Zeile liefert mir dieses Warning:

warning C4267: 'initializing' : conversion from 'size_t' to 'uint', possible loss of data

Das versteh ich nicht, denn mein uint ist ein typedef auf unsigned int und wenn ich in der IDE mit der Maus über size_t geh dann sagt er mir, dass size_t AUCH ein typedef auf unsigned int.
Wieso zur Hölle gibt das dann ein Warning, wenn es exakt die gleichen Typen sind? (Und wie krieg ich das Warning am elegantesten weg? Casten? Ich könnte auch size_t resultDimension nehmen, aber das möchte ich eigentlich nicht, weil ich zb weiter unten den Wert an eine Funktion übergebe, die ein uint erwartet..)

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

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.

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

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.

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

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

...

/signed

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.

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();