Gegenstück zu atoi/atof
-
@SeppJ:
Da die Socketfunktionen ( z.b. read ) sowieso einen Buffer (char) wollen, macht ein char-Array an der Stelle Sinn. Ein konstantes normalerweise.Man kann aber genauso gut einen char* Buffer mit einer Initialen Laenge anlegen und, wenn man Hinweise hat, dass mehr Daten kommen, den Buffer vergroessern. Hab das zwar so noch nie gemacht, aber es wäre zumindest ein denkbares Szenario.
Da "read" nur char* nimmt, fällt vector sowieso aus, und wenn man einen flexiblen Buffer haben will, bleibt einem nichts anderes übrig
Das Szenario ist jetzt arg konstruiert, das gebe ich zu, aber es zumindest nicht undenkbar.
-
It0101 schrieb:
Da "read" nur char* nimmt, fällt vector sowieso aus
Nein. Dann hast du es doch falsch verstanden. vector wäre hier genau das richtige. Geradezu Paradebeispiel für den Denkfehler, den ich mit
Weil ein Interface einen char* verlangt malloc/new zu nehmen, das ist falsch verstanden, was die Bedeutung dieser Datenstruktur ist.
meinte.
Hier wird vom Interface ein Zeiger auf deine Daten verlangt. Das heißt nicht, dass du deine Daten mit einem Zeiger halten musst, sondern dass deine Daten "zeigbar" sein müssen! Sonst würde mit diesem Argument ja nicht einmal das statische char-Array gehen.
-
Ach so meintest du das. Naja ich bin kein Freund davon auf die Art zu arbeiten.
Wenn gewollt wäre, dass man an die Adresse des internen Arrays von std::vector rankäme, dann wäre das entsprechend mit einer Funktion vorgesehen wie z.b. "c_str" bei std::string.
Ich betrachte das eher als "Workaround", denn als "schöne" Variante.Zumal es bei vector ja tatsächlich gegeben ist, dass die Daten hintereinander im Speicher liegen. Das heißt es wäre geradezu lächerlich einfach, eine Funktion zu bauen, die die Adresse zurückliefert. Das Standardkomitee wird schon seine Gründe haben, warum es eine solche Funktion nicht mitliefert.
Mich wundert, dass du und andere das wirklich so verwenden, wo ihr doch sonst immer den Standard als die einzige wahre Bibel preist.
-
It0101 schrieb:
Zumal es bei vector ja tatsächlich gegeben ist, dass die Daten hintereinander im Speicher liegen. Das heißt es wäre geradezu lächerlich einfach, eine Funktion zu bauen, die die Adresse zurückliefert. Das Standardkomitee wird schon seine Gründe haben, warum es eine solche Funktion nicht mitliefert.
Tut es jetzt wie ich gerade lese: data(). Mich würde auch mal interessieren, ob du das meintest oder was sonst.
-
It0101 schrieb:
Zumal es bei vector ja tatsächlich gegeben ist, dass die Daten hintereinander im Speicher liegen. Das heißt es wäre geradezu lächerlich einfach, eine Funktion zu bauen, die die Adresse zurückliefert. Das Standardkomitee wird schon seine Gründe haben, warum es eine solche Funktion nicht mitliefert.
Seit C++11 gibt es sie.
Aber auch ohne C++11 ist es möglich, da man mit &vector[0] an die Adresse des ersten Arrayelementes kommt (ist vom Standard garantiert).
