char s1[] = { '\5', 'h', 'a', 'l', 'l', 'o' }; // zum Testen <<, '\0'>> am Ende noch einfügen

Ich benötige solche Strings zum schnellen Vergleichen in den unterschiedlichsten Dateien; also ist die länge zur Laufzeit solcher Strings bekannt!
Da der Compiler nun die Länge kennt, könnte man ja solch einen Typ generieren.
Möglicherweise mit template ? - um nicht jeden String abzählen zu müssen, ist für die anderen, die diese Klasse benützen müssen, ja nicht gerade angenehm,
daß z.B. diese Initialisierung:

char s1[] = "hallo" // mit s1[0]=5, s1[1]='h' ...

möglich ist.

Bin für jede Idee offen, die mich diesem String näher bringt.

template <std::size_t S>
std::size_t length(char (&str)[S])
{
    return S;
}

Du kannst natürlich auch einen generischen, 1 Zeichen sparenden Typen schreiben:

template <std::size_t S>
class small_string
{
	private:
		char str[S];

	public:
		small_string(const char* text)
		{
			std::copy(text, text+S, str);
		}

		std::size_t length() const
		{
			return S;
		}

		char& operator[] (std::size_t index)
		{
			assert(index < S);
			return str[index];
		}
};

Deinen Ideen sind sehr wenige Grenzen gesetzt...

Grüssli

Ja, Templates sind das Stichwort. Die Länge eines char -Arrays kannst du wie folgt bestimmen:

O.K. vielen dank für diese supper schnelle Antwort.
Dann muss man wohl mit dem 0-char am Ende auskommen und hat halt das zusätzliche byte am Ende.

Dravere schrieb:

Mir ist nicht so ganz klar, was hier eigentlich gegen einen std::string spricht?

Da diese Funktionen aus den unterschiedlichsten Instanzen aus aufgerufen werden und aus einem "event" heraus haben manche Instanzen nur einen Zeiger auf den String und müssen die Länge für eine mögliche Übergabe neu berechnen lassen - sehr aufwendig, langsam und Fehleranfällig - mögliches "Ruckeln" auf manchen Rechnern, im schlimmsten Fall hängt sich das Programm auf.
Für einen Thread spielt die Schnelligkeit eher weniger eine Rolle und dort würde ich auch standart Rutinen verwenden.
Da ich jedoch keine langen Strings habe wie du siehst <256 Zeichen, hat mich eher das Problem an sich interressiert.
Ich arbeit möglicherweise mit diesen Funktionen auch auf direkten Wertangaben in Dateien oder verändere den String zur Suchoptimierung

char s1[20];
s1[11]=1;
s1[12]=0; // dann ists aus mit der Länge.
oder char s1[] = {'\1','\0','\0','E','U','R'} // wie lang ist dieser String ?

Also ich nehme das Bsp. von Nexus mit dem template. Ist einfacher und sicherer. Wenn man mal einen Fehler suchen muss, der durch eine abgehackte Länge verursacht wurde - dann gute Nacht.

Zur Lösung von Nexus:
Das geht nur, so lange das Array vorhanden ist. Sobald du ein Zeiger hast, geht diese Lösung nicht mehr.

Grüssli

std::string führt schliesslich intern die Grösse des Strings mit.

Zur Lösung von Nexus:
Das geht nur, so lange das Array vorhanden ist. Sobald du ein Zeiger hast, geht diese Lösung nicht mehr.

Grüssli

Auch hää, wäre mir neu. gib dir mal den Wert c_string[0] aus.

Genau, sobald du einen Zeiger hast geht das mit c-string nicht mehr bzw. schwerer, da der c-String seine Länge nicht anthält sondern sie mit 0 als Ende markiert.
Vielleicht benützt du eine andere lib, Der Compiler kann jedoch nur c-Strings und gibt dir auch als sizeof den String bis zur abschließenden 0.
Wir sind hier nicht in Pascal oder Fortran ...
Ich check das mal aber da müsste ich mich stark irren ...
Ne, stimmt und c-strings machen mir riesen Probleme sehe ich gerade. - kommen also überhaupt nicht in Frage dann schon eher QString.

Sorry.

QString ? Dir ist bewusst, dass ein QString nichts mit Standard C++ zu tun hat und aus dem Qt Framework stammt? Wie gesagt, std::string , bzw. std::wstring , bzw. std::basic_string , ist die Stringklasse aus der Standardbibliothek.

Grüssli

Dir ist bewusst, dass ein QString nichts mit Standard C++ zu tun hat und aus dem Qt Framework stammt?

Grüssli

Jo, ich programmiere mit QT, also alles i.O. Und es ist allseits bekannt, daß c-Strings nicht so der Hit sind. Eine Lösung muss jedoch bestmöglichst den Zweck erfüllen und möglichst kompatibel bleiben, also hast du schon recht möglichst c-nahe libs zu verwenden. Für meinen Zweck sind sie aber nicht geeignet, umsomehr der "Pascal String" also werde ich auf den zurückgreifen. Is ja Programm intern und hat keine Auswirkung auf Kompatibilität.
C++ will halt möglicht uneingeschrängt bleiben und haben so diesen c-String gewählt.

Ich habe dir am Anfang so eine "spezielle" Lösung gepostet, weil ich dachte, du hättest einen Grund für solche Strings, zum Beispiel, weil du zur Compilezeit die Grösse wissen müsstest. Aber ich habe mich wohl geirrt, normale Strings sind die bessere Wahl.

Übrigens, was hat das mit Pascal-Strings und dem anderen Zeug zu tun?

...gib dir mal den Wert c_string[0] aus.

Genau, sobald du einen Zeiger hast geht das mit c-string nicht mehr bzw. schwerer, da der c-String seine Länge nicht anthält sondern sie mit 0 als Ende markiert....

Also nun bin ich genauso verwirrt und neugierig wie Dravere ...
Kann es sein, dass Du von C-Strings sprichst, wo er von std::string (etwas ganz Anderes) spricht?

Deine Forderung ("bestmöglichen Zweck erfüllen" und "kompatible wie möglich") scheint jedenfalls auch mir am Besten durch std::string erfüllbar - und ich habe irgendwie immer noch kein Argument gelesen (oder verstanden), was dem widerspräche.

Gruß,

Simon2.

bastl schrieb:

...gib dir mal den Wert c_string[0] aus.

Genau, sobald du einen Zeiger hast geht das mit c-string nicht mehr bzw. schwerer, da der c-String seine Länge nicht anthält sondern sie mit 0 als Ende markiert....

Also nun bin ich genauso verwirrt und neugierig wie Dravere ...
Kann es sein, dass Du von C-Strings sprichst, wo er von std::string (etwas ganz Anderes) spricht?

Ich dachte, daß allseits bekannt ist wie Strings in C, C++ verarbeitet werden.
Also C-Strings sind vom typ char abgeleitet genauso wie std::string oder <<char str[] = "text">>, nur daß <<char str[]>> deutlich mehr Freiheiten hat als std::string (ist eine Klasse).

(Nachfolgendes ist nicht 100%ig sicher)
Nach jeder Veränderung eines std::string wird die Länge des Strings beim Aufruf von sdt::length() neu berechnet mit oder ähnlich

int i=0
while( string[i]!=0 ) i++;
return i;

.

Wenn ein String an Position 0 keine Längenangabe hat, dann führt er auch seine Länge nicht mit sich !!!

Dravere schrieb:

std::string str = "hello";

hello wird als c-String zu <<hello0>>, str[0] = h bzw. 104 und somit nicht 5 oder 6.
Hat man nun einen std::string, der nicht const ist in einer for-Schleife:

for( int i=0; i<str.length(); i++)

so wird jedesmal die Länge der Abbruchbedingung durch einen Funktionaufruf übermittelt und nicht direckt durch eine Speicherangabe (wie bei pascal String (char)str[0]).
In c++ bedeutet dann gutes programmieren:

int l = str.length();
for( int i=0; i < l; i++)

wobei eine Längenänderung (z.B Teile ersetzen) des Strings und ein anschließender Zugriff über eine sdt:: Funktion in der Schleife nicht vorkommen darf, sonst ist die Mühe umsonst und die Länge wird neu berechnet.
(Ende des <<Nachfolgendes ist nicht 100%ig sicher>>)

Ganz im gegensatz zu Pascal Strings wo man selbst dafür sorgen muss mit new das array zu erweitern und die Länge neu eintragen kann, wenn man will, oder entsprechende Member schreibt.
Das erlaubt unheimliche Performance gegenüber c-Strings, die nicht entwickelt wurden um in einer for Schleife auf ihre Elemente zuzugreifen.

Für die die jetzt anfangen zu grübeln:
Sobald ich die Länge zu einem String speichere auch in einer Extra Variablen, habe ich das Prinzip Pascal String und nichts anderes, nur in einer etwas freieren Version. Kompakter und präziser ist es halt, wenn man die Längenangabe direkt im String speichert. Ob man jetzt 1, 4 oder 8 Byte für die Längenangabe verwendet ist im Prinzip egal.

Die Diskusion Pascal Strings in den c++ Standard aufzunehmen gab es schon und wurde abgelehnt.

Einfach im Netz googlen, dann erklärt sich das Problem von selbst.

...unsinn...

Nichts für ungut, aber da Du hier derart mit Deiner Unwissenheit glänzt, wäre std::string wirklich die beste Wahl. Das ist am sichersten.
Und nein, die Größe wird mit allergrößter Wahrscheinlichkeit nicht bei jedem Aufruf von std::string::size() neu berechnet.
Und mit Pascal-Strings hat das auch nichts zu tun. Das sind in Standardpascal erstmal auch nur char-Arrays fester Länge. Ich schätze mal, Du meinst die Turbopascal Version (und die der Derivate).

bastl schrieb:

...
Ich dachte, daß allseits bekannt ist wie Strings in C, C++ verarbeitet werden....

Da es in C keine std::string gibt, kann es schonmal nicht gleich sein, wie die beiden Sprachen diese "verarbeiten".

bastl schrieb:

...
Also C-Strings sind vom typ char abgeleitet ...

Was Du mit "abgeleitet" meinst, ist mir hier nicht klar, aber es spricht nichts dagegen std::basic_string<my_own_character_type> zu verwenden (außer evtl. unnötiger Mehraufwand) - und dann hat string überhaupt nichts mehr mit char zu tun.

bastl schrieb:

...nur daß <<char str[]>> deutlich mehr Freiheiten hat als std::string (ist eine Klasse)....

Was soll ein char-Arry an "Freiheiten" mehr haben als std::string? Und was soll das mit der "Klasseneigenschaft" zu tun haben?

bastl schrieb:

...
(Nachfolgendes ist nicht 100%ig sicher)
...

Das ist nicht nur nicht sicher, sondern sogar ziemlich sicher falsch!
Zwar gibt der C++-Standard dem StdLib-Entwickler diesbezüglich keine Vorgabe, aber der wäre schon sehr dämlich, wenn er aus

std::string s1 = s2 + s3;

den o.g. Code machen würde. std::string hat einfach ein Attribut (ist eine "Klasse", wie Du schon zurecht bemerkt hast und als solche kann es jede Menge interne Attribute haben), das die Länge hält und es besteht gar nicht die Notwendigkeit, diese Information irgendwo in den internen Buffer zu "pulen" (weder an den "Anfang" noch implizit via 0-Terminierung).
Kurz gesagt: Was Du als "tollen Performancetrick" anpreist (nämlich das "Merken der Längeninfo in einer Variable), macht std::string sowieso schon.

bastl schrieb:

...Ganz im gegensatz zu Pascal Strings wo man selbst dafür sorgen muss mit new das array zu erweitern und die Länge neu eintragen kann, wenn man will, oder entsprechende Member schreibt. ...

WAS ist "...im Gegensatz zu Pascal Strings ..."?
Ich vermute, Du sprichst von der std::string-internen Speicherverwaltung. Natürlich kann es sein, dass der eine oder andere Experte in seiner ganz speziellen Anwendug hier und da noch ein wenig optimieren kann - aber in 99,9% der Fälle ist das eher eine theoretische Möglichkeit. Du kannst davon ausgehen, das die StdLib-Etnwickler auch keine Dummköpfe sind ... und letztlich nutzen sie genauso new[]/delete[] wie Du das tätest.
An einen "Unheimliche Performance"-Vorteil glaube ich da schonmal gar nicht.

Sagen wir mal so: Selbst ich würde wohl aus dem Stand eine bessere std::string-Implementierung hinbekommen als Du da beschreibst - und ich gehe davon aus, dass die StdLib-Entwickler eher mehr (vermutlich deutlich) Ahnung und Ideen und Zeit dafür haben.
So ziemlich Nichts von Deinen Mutmaßung über das interne Handling von Strings wird im Standard be- geschweige denn vorschrieben....

bastl schrieb:

...
Einfach im Netz googlen, dann erklärt sich das Problem von selbst.

Ich würde eher zu einem guten C++-Buch raten.

Gruß,

Simon2.

std::string , wie auch ein C-String , sind nicht von char abgeleitet.

Ein char[] hat deutlich weniger Freiheiten als ein std::string ! Ein char[] kannst du nicht mal sinnvoll kopieren. Ein std::string kann einfach durch Zuweisung kopiert werden. Du kannst einen std::string auch ganz einfach vergrössern lassen. Und noch vieles mehr, die Liste geht fast ins unendliche, lies doch nur mal die Referenz:
http://www.cplusplus.com/reference/string/string/

Zudem ist std::string grundsätzlich ein typedef auf std::basic_string<char, std::char_trais<char>, std::allocator<char> > . Deshalb gibt es ja auch std::wstring . In Zukunft wird es auch noch std::u16string und std::u32string geben.

Die Länge eines std::string wird nicht immer neu berechnet, sondern sie wird mitgeführt. Nicht ohne Grund verbraucht ein std::string 28 Bytes an Speicher. Er führt nämlich nicht nur die Grösse mit, sondern meistens auch noch einen Capacity-Wert, weil dein std::string wahrscheinlich sinnvollerweise immer ein wenig mehr Speicher allokiert, als er benötigt, so kann er ganz einfach expandieren.

Allerdings kann ich dir deine Aussage der Neuberechnung auch ganz einfach entkräften. Ein std::string darf mehrere '\0' s enthalten:

#include <string>
#include <iostream>

int main()
{
  std::string str;

  str += "hello";
  str += '\0';
  str += " wo";
  str += '\0';
  str += "rld!":

  std::cout << str.length() << std::endl;
  // Ausgabe: 14

  return 0;
}

Die Länge eines std::string wird auch nicht im Array gespeichert, sondern eben separat in einer Variable vom Typ std::size_t .

Anmerkung: Über einen std::string iterieren tut man übrigens oft mit den Iteratoren.

Und wie war das? C-Strings wurden nicht dazu entwickelt, um auf ihre Elemente in einer For-Schleife zuzugreifen? Klar doch, damit wären alle C-String Funktionen überflüssing:
http://www.cplusplus.com/reference/clibrary/cstring/

Aber wahrscheinlich hast du den std::string gemeint und dich nur verschrieben. Mal schauen, std::string ünterstützt das Iteratoren-Konzept und viele von den folgenden Funktionen brauchen For-Schleifen:
http://www.cplusplus.com/reference/algorithm/

Allerdings kannst du auch mit einem Index problemlos in einer Schleife darauf zugreifen.

bastl schrieb:

Einfach im Netz googlen, dann erklärt sich das Problem von selbst.

Hast du dir so C++ beigebracht? Dann erstaunt es mich nicht mehr so sehr. Ich empfehle dir dringend, dass du C++ sinnvoll lernst, am besten ein Buch liest. Empfehlungen:
C++ Primer
Thinking in C++ 1&2 (auch gratis als PDF erhältlich, nur Englisch)

Grüssli

Makro? Definition? irgendwas einfaches, was keine Spuren im Programmkode hinterläßt.

Muß da noch recherchieren, obs da nicht doch irgendwas giebt.

Beachtet const string und string werden absolut unterschiedlich behandelt!

const std::string ist konstant. Da es zur Standardbibliothek gehört, sind dem Compiler vielleicht gewisse Optimierungen möglich. Aber mehr nicht, keine Ahnung worauf du abzielst.

bastl schrieb:

Alles strebt förmlich nach Verwendung von Pascal Strings, so auch std::string.
Da nun alle in C++ im Prinzip Pascal Strings verwenden

Du mit deinen Pascal-Strings... Was gefällt dir an den C++-Strings nicht? Und wieso vergleichst du dauernd mit Pascal?

bastl schrieb:

Warum kann der Compiler mir die Stringlänge nicht direkt initialisieren?
Der weiß die doch zur Kompilierungszeit!

Nein, in den meisten Fällen nicht. std::string wird normalerweise nicht dazu verwendet, Stringliterale zu speichern, dafür reicht const char* . Und was stellst du dir unter "direkt initialisieren" vor? Dass zur Compilezeit Speicher angefordert wird und sich das zur Laufzeit erübrigt? Ich hoffe nicht.

bastl schrieb:

Z.B.: "hallo" ist vom Typ char[6] dann müsste ich doch nicht selbst die Stringlänge bei der Initialisierung einbauen.

Dann nimm doch eben einen char[6] statt eines std::string s oder char* s...

Ich hab ehrlich gesagt keine Ahnung was du überhaupt willst. Die ganze Zeit redest du von irgendwelchen Pascal-Strings und drückst dich unklar aus. Also nochmals: Was ist am Status Quo nicht gut und was hindert dich daran, normale Arrays zu benutzen?

const char[] hallo = "hallo";

ansonsten hf noch hier

bb

PS: Der Thread-Titel wird beim schreiben noch immer nicht richtig angezeigt -.-

Beachtet const string und string werden absolut unterschiedlich behandelt!

Hä? Was willst du uns damit sagen?

bastl schrieb:

Und die Verwendung von size_t bringt schon die dringlichkeit von Pascal Strings zum Ausdruck. Alles strebt förmlich nach Verwendung von Pascal Strings, so auch std::string.

Noch mehr, hä? Ein C String ist bewusst nicht so aufgebaut, wie in Pascal, weil sonst einiges ziemlich seltsam wäre. Mit char Arrays kannst du rohen Speicher verwalten.
Ein Beispiel aus C:

char buffer[sizeof(int)];
int* p = (int*)buffer;

Wie bitte sollte man hier Pascal Strings reinbringen. Absolut unmöglich, da müsste man das Sprachkonzept zuerst verändern. Komm darüber hinweg, dass man es in C nunmal anders löst.

bastl schrieb:

Da nun alle in C++ im Prinzip Pascal Strings verwenden ...

Also das stimmt so nicht, aber von mir aus, wenn du von deinem Pascal nicht loskommen kannst.

bastl schrieb:

Z.B.: "hallo" ist vom Typ char[6] ...

Das ist schonmal insofern falsch, als dass "hallo" den Typ char const[6] hat.

bastl schrieb:

... dann müsste ich doch nicht selbst die Stringlänge bei der Initialisierung einbauen.

Musst du ja auch nicht. Schau dir nur meine Codes an, welche ich hier schon oft gezeigt habe:

std::string str = "hello"; // nicht nötig
char const* p = "hello";   // nicht nötig
char arr[] = "hello";      // nicht nötig

Grüssli

Hä? Was willst du uns damit sagen?

Das geht die was an, die meinen, daß die länge nicht berechnet wird.

Dravere schrieb:

Ein Beispiel aus C:

char buffer[sizeof(int)];
int* p = (int*)buffer;

Wie bitte sollte man hier Pascal Strings reinbringen. Absolut unmöglich, da müsste man das Sprachkonzept zuerst verändern. Komm darüber hinweg, dass man es in C nunmal anders löst.

Ich glaube du hast nicht verstanden, was Pascal Strings sind, oder?
Und was willst du mit diesem eingeschränkten Bsp. überhaupt aussagen?
Und natürlich bekommt man da einen P-String rein, erst bei sizeof(char) wirds eng!

Dravere schrieb:

Musst du ja auch nicht. Schau dir nur meine Codes an, welche ich hier schon oft gezeigt habe:

std::string str = "hello"; // nicht nötig
char const* p = "hello";   // nicht nötig
char arr[] = "hello";      // nicht nötig

Das erste wird intern zu einem abgewandelten P-String.
Sind leider keine P-Strings!!! - Also Bitte!

for( int i=0; i<str.length(); i++)

Das ist falsch. Schau dir doch mal den Code deiner Implementierung an. Das sollte in etwa so aussehen:

template <...>
basic_string<...>::length() const
{
    return m_length;
}

Da wird nicht nach einem Null-Charakter gesucht oder ähnliches.

Gruß
Don06

Das geht die was an, die meinen, daß die länge nicht berechnet wird.

Bei den meisten std::string -Implementierungen wird sie das auch nicht. Da du das bestimmt wieder besser weisst, will ich dir mal die Standardbibliothek vom MSVC++ zeigen:

size_type __CLR_OR_THIS_CALL length() const
		{	// return length of sequence
		return (_Mysize);
		}

	size_type __CLR_OR_THIS_CALL size() const
		{	// return length of sequence
		return (_Mysize);
		}

Siehst du? Es wird eine Membervariable zurückgegeben.

bastl schrieb:

Ich glaube du hast nicht verstanden, was Pascal Strings sind, oder?

Da diese Pascal-Strings dermassen wichtig sind und C++ ohne sie folglich abgrundtief schlecht sein muss, könntest du vielleicht mal erklären, wie diese funktionieren. Nicht jeder hat früher mal Pascal programmiert.

aber naja - da c++ keine pascal strings hat, ist es eben einfach doof - und man muss auf zwang versuchen, diese hässlichen gebilde, die imho weit weniger umfangreich als std::string sind, nachzubauen und sich dann wieder beschweren, dass es so schwer ist...

bb

bastl schrieb:

Ich glaube du hast nicht verstanden, was Pascal Strings sind, oder?

Doch, doch. Ein Pascalstring hat an der Stelle 0 die Länge des Strings gespeichert.

bastl schrieb:

Und was willst du mit diesem eingeschränkten Bsp. überhaupt aussagen?
Und natürlich bekommt man da einen P-String rein, erst bei sizeof(char) wirds eng!

Also ok, vielleicht war auch meine Wortwahl ein wenig schlecht, aber mit dem reinbringen war gemeint, wie man es in die Sprache bringen soll. Aber du hast ja anscheinend auch sonst nicht bemerkt, um was es mir ging.

Die Sache ist, dass ein Array in C und C++ nichts anderes ist, als eine gewisse Anzahl an Bytes und in diesen Bytes ist nichts anders als die Daten. Der Kompiler tut da überhaupt nichts selber rein.

Nehmen wir nochmals mein Beispiel:

// Normal jetzt:
char buffer[sizeof(int)]; // sizeof(int) gibt meistens 4, also 4 Bytes
int* p = (int*)buffer;
p = 0; // ok, alles 4 Bytes sind jetzt 0

// Wenn das Char Array nach Pascal Strings funktionieren würde:
char buffer[sizeof(int)]; // buffer braucht 5 Bytes, im Byte 0 ist die Grösse des Arrays gespeichert
int* p = (int*)buffer;
p = 0; // Die Grösse vom Array ist 0 -> ??? Fehler ...

Ein Pascalstring passt einfach nicht in die Sprache C oder C++ rein, weil er gegen das ganze Speicherverwaltungskonzept verstösst.

Grüssli

...

Dravere schrieb:

std::string str = "hello"; // nicht nötig
...

Das erste wird intern zu einem abgewandelten P-String. ...

Die Aussage ist einfach falsch: Da wird nichts "...intern zu einem abgewandelten P-String..."
(es sei denn, du definierst "abgewandelt" als "ersetzt duch std::string")

Natürlich kannst Du versuchen, die gesamte Welt über P-Strings zu erklären, das bringt aber niemanden weiter - und führt Dich offensichtlich nicht zu einem richtigen Verständnis von std::string.

Ich kenne das ja auch, dass man sich einer neuen Sprache erst einmal in den Denkmodellen der bisher bekannten nähert, aber irgendwann kommt der Punkt, an dem man "springen" muss; an dem man "Java" programmieren muss und nicht mehr "C++ in Java", "C in C++", "Cobol in Java" ... oder "Pascal in C++".
Wer nicht "springt", wird nie die Eigenschaften (Vor-/Nachteile) der neuen Sprache wirklich durchschauen.

Ich würde sagen: Your choice.

Gruß,

Simon2.

Das ist falsch. Schau dir doch mal den Code deiner Implementierung an. Das sollte in etwa so aussehen:

template <...>
basic_string<...>::length() const
{
    return m_length;
}

Das mit dem berechnen ist nicht mein Problem - jedoch gehe ich nochmal kurz darauf ein.- Es geht nicht darum wann und wo die Länge neu Eingetragen wird sondern darum, daß length() ein Funktionsaufruf ist und nicht ein Zeiger auf diese Variable! - also einige Takte mehr benötigt. - Das hat mich irgendwie gestört - ist aber trivial, gauso wie das Problem, das ich hier lösen wollte!
Wenn die Länge nicht gespeichert würde, müsste sie jedesmal neu berechnet werden! - würde keiner machen!
Jedoch ist es zwingend notwendig in C++ diese Variable getrennt vom Array zu halten, da die Aufgabe und Bedeutung der beiden sich total unterscheiden und somit auch deren Aufgaben in der Klasse!
Man benötigt halt immer eine Klasse, auch wenn man nur eine Funktion damit anstebt.

Simon2 schrieb:

Ich kenne das ja auch, dass man sich einer neuen Sprache erst einmal in den Denkmodellen der bisher bekannten nähert, aber irgendwann kommt der Punkt, an dem man "springen" muss; an dem man "Java" programmieren muss und nicht mehr "C++ in Java", "C in C++", "Cobol in Java" ... oder "Pascal in C++".

Gut erkannt, und immer wieder möchte man mit Hilfe einer anderen Programmiersprache etwas verdeutlichen oder erklären - man läuft immer auf!
Schlussendlich ist bei effektivster Programmierung der ausführbare Kode im Prinzip bei allen der gleiche.
Bei mir ist das einzigste Problem, daß QStrings nicht mit std::string harmonieren und ich sowiso eine spezial Suche und Vervollständigung im Umgang mit linuxdateien implementiren möchte. Gibt eine spezial Implementierung, ist aber kein Muss sonder eher aufregend und spannend und bringt hier und da noch ein paar Takte weniger - hab ja sonst nichts besseres zu tun!

Es geht nicht darum wann und wo die Länge neu Eingetragen wird sondern darum, daß length() ein Funktionsaufruf ist und nicht ein Zeiger auf diese Variable! - also einige Takte mehr benötigt.

Wenn dein Compiler auch nur irgendetwas taugt, kann er den Funktionsaufruf inline erweitern, so daß der Unterschied exakt 0 ist.