Eigenen Typ "String" in c++ deffinieren - wie?

[Nexus]

bastl schrieb:

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?

[unskilled]

Ich dachte, er wollte einfach nur das hier wissen:

const char[] hallo = "hallo";

ansonsten hf noch hier

bb

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

[Dravere]

bastl schrieb:

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

[bastl]

Dravere schrieb:

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!

[Don06]

Du glaubst wirklich, dass im folgenden Code die Länge des Strings mehrmals berechnet wird?

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

[Nexus]

bastl schrieb:

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.

[unskilled]

imho ist unter pascal string einfach nur zu verstehen, dass im ersten zeichen (also index 0) die länge steht - was allerdings zur folge hat, dass das ganze nur bis zu 255 zeichen lang werden konnte - das erkannte man dann iwann als fehler und hatte glaub ich dann ne ganz normale variable für die länge eingeführt...

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

[Dravere]

Alles bis auf eines wurde ja schon beantwortet, also lasse ich den Rest weg. Du solltest aber echt einmal sinnvoll C++ lernen, vor allem wenn du so überzeugt von deinen falschen Annahmen bist.

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

[Simon2]

bastl schrieb:

...

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.

[bastl]

Don06 schrieb:

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!

[audacia]

bastl schrieb:

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.

[Simon2]

bastl schrieb:

...
Das mit dem berechnen ist nicht mein Problem ....

Das war aber bislang das Einzige, worauf Du abzieltest ... der einzige (vermeintliche) Nachteil von std::strings, den Du als Arugment brachtest.

bastl schrieb:

...daß length() ein Funktionsaufruf ist und nicht ein Zeiger auf diese Variable! - also einige Takte mehr benötigt....

Auch ein Indirektion (wie sie bei Deiner "Zeigervariante" nötig wäre) kostet Zeit - selbst das Auslesen einer Variable kostet Zeit.

bastl schrieb:

... - Das hat mich irgendwie gestört - ...

Nun gut - wer keine Arbeit hat, macht sich welche
Natürlich hindert Dch niemand, die Zahl der Funktionsaufrufe zu verringern - allerdings solltest Du bedenken, dass Compiler sowas heutzutage exzellent können (gerade bei simplen Gettern) - Mach doch einfach mal einen Vergkeichstest (im Releasemode compiliert).

bastl schrieb:

...Wenn die Länge nicht gespeichert würde, müsste sie jedesmal neu berechnet werden! - würde keiner machen! ...

Wie ? Jetzt doch nicht mehr? Hast Du nicht oben erklärt, genau so und nur so würden std::strings funktionieren?

bastl schrieb:

...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!...

Japp - die Anzahl der Zeichen eines Strings ist eine separate Information und man tut deshalb gut daran, sie separat zu behandeln.
Was war jetzt Dein Problem dabei?

bastl schrieb:

...Man benötigt halt immer eine Klasse, auch wenn man nur eine Funktion damit anstebt....

Wer strebt weswegen wofür "nur eine Funktion an"?
Und was ist falsch daran, eine Klasse zu verwenden?
Hast Du Berührungsängste mit objektorientierter Programmierung?

bastl schrieb:

...

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!...

Dann lass es doch einfach: Ich habe den starken Eindruck, dass niemandem hier die Pascal-Parallele geholfen hat, zu verstehen, was Du sagen willst.
Warum auch? Hier ist

• ein C++-Forum,
• in dem Leute, die C++ kennen
• sich über C++ unterhalten

Warum nicht in C++ sagen, was man zu sagen hat?

bastl schrieb:

...Bei mir ist das einzigste Problem, daß QStrings nicht mit std::string harmonieren ...

Ich kenne mich mit "QStrings" nun leider gar nicht aus. Aber da ich immer noch annehmen muss, dass Du mit std::string nicht allzu viel Erfahrung hast, könnte ich mir vorstellen, dass diese Analyse unzutreffend ist.
Selbst wenn Du jetzt einen eigenen Stringtypen entwirfst, wirst Du den mit QStrings "harmonisieren" müssen ... und ob das wirklich besser funktioniert als mit std:string?

bastl schrieb:

...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!

Ich stimme Dir vollkommen zu: Man kann viel Aufregendes und Spannendes programmieren ... und nicht Alles muss sich wirtschaftlich rechnen.
Allerdings:
- "Linuxspezifisches" sehe ich im ganzen Szenario nicht.
- "Vorzeitige Optimierung" ist in 99% der Fälle vergebliche Liebesmüh: Man hat hinterher einen Haufen Fingerbrecherei gemacht für schlecht wartbaren Code und ein Programm, das langsamer läuft.
- die Möglichkeiten der StdLib (std::string aber auch viele Andere nützliche Dinge) sind sehr weitgehend ... damit kann man fast alle "spezial Sachen" machen.

Nochmal mein Tipp: Versuche eine gute Implementierung auf Basis der StdLib hinzubekommen, baue das Ganze dann einmal ohne StdLib und vergleiche:
- Performance (wie gesagt: Releasemode compiliert)
- Codelänge
- Allgemeinverständlichkeit (kannst mal einem Freund den jeweiligen (unkommentierten) Code geben und raten lassen, was er macht)
- Wartbarkeit (für Erweiterungen, Fehlersuche, ...)
- Nettoaufwand bei Implementierung und Test.

DAS wäre doch gleichzeitig spannend als auch lehrreich (egal, welche Variante dann "gewinnt").

Gruß,

Simon2.

[Nexus]

bastl schrieb:

hab ja sonst nichts besseres zu tun!

Das Gefühl habe ich auch, wenn ich mir so ansehe, ab welchen Kleinigkeiten (die zum Teil noch falsch sind) du dich aufregst.

bastl schrieb:

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!

Du kannst auch gerne das erste Array-Element zum Speichern der Länge benutzen, wenn du so Freude daran hast. Die Trennung macht schon Sinn, und du hast bisher noch kein Argument dagegen gebracht (nein, weil es in Pascal so ist, ist kein Argument).

bastl schrieb:

Man benötigt halt immer eine Klasse, auch wenn man nur eine Funktion damit anstebt.

So ein Unsinn. Es gibt in C++ nicht umsonst freie Funktionen.

bastl schrieb:

Es geht [...] 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

Wie gesagt macht das durch Compileroptimierungen keinen Unterschied (selbst wenn es das tun würde, solltest du dich zuerst um wichtigere Dinge kümmern.

bastl schrieb:

- ist aber trivial, gauso wie das Problem, das ich hier lösen wollte!

Hast du dein Problem jetzt gelöst? Falls nicht, würde es vielleicht helfen, es in aller Ruhe nochmals zu formulieren. Vielleicht mehr in die Richtung, was man erreichen möchte und nicht, welcher Teil von C++ einen aufgrund mangelnder Kenntnisse daran hindert.

[hustbaer]

Nexus schrieb:

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.

Klassische Pascal String verwenden ein fixed-size Array (typischerweise 256 Byte gross). Im ersten Byte steht die aktuelle Länge, danach kommt der Text. Nullterminiert sind sie dafür nicht.

In neueren Pascal-Dialekten werden sie logischerweise nichtmehr verwendet, da 255 als maximale String-Länge einfach nichtmehr ausreicht.

Und dann gibt es natürlich viele Abarten davon. z.B. Strings die die Länge in zwei oder mehr Byte speichern, die kein fixed-size Array verwenden sondern eins was immer nur so lange ist wie nötig, etc.

In Windows gibt's auch einen ähnlichen Typ, nämlich BSTR. Ein BSTR ist ein nullterminierter UTF-16 String. BSTR ist ein Typedef auf "wchar_t*", und dieser Zeiger zeigt auf das erste Zeichen des Strings. Das "minus erste" Zeichen gibt die Länge an.

----

Der Vorteil von solchen Strings ist, dass sie unabhängig von der ABI einer bestimmten Programmiersprache sind -- da direkt das Layout im Speicher definiert ist. Dadurch kann man unabhängig von der Sprache Strings herumreichen, hat aber trotzdem den Vorteil, dass man a) die Länge nicht zählen muss und b) Null-Zeichen mitten im String haben kann.
Der Nachteil ist natürlich dass man sich genau an dieses Layout halten muss, und man dadurch weniger flexibel ist was diverse Optimierungen angeht.

----

Im Prinzip könnte man nach diesem Schema auch std::string implementieren. Macht bloss glaube ich keiner.

[Bitsy]

Der Aufbau einer eigenen Stringklasse ist zumindest sehr lehrreich.
Lange Zeit bevor STL wirklich Standard war habe ich allen solchen Paketen mißtraut und meine eigene Klasse gebaut, die ich auch debuggen konnte.
Als Basisklasse sollte man einen ganz simplen char* nehmen, und dann eine Klasse bauen, die dann eben auch herkömmliche C-Strings einfach behandeln kann.
Klar hätte die eigene Stringklasse den Längenwert bereits intus.
Dazu muß man aber auch sicherstellen, daß es einfach nicht gelingt, nachträglich ein 0-Zeichen in dem String unterzubringen.
Für eine solche Operation wäre eine von String abgeleitete Klasse sinnvoll.

Für weiteres Training programmiere man sich dann mit Templates noch ein Array, damit man dynamisch eine Textdatei einlesen kann und sie direkt in einem Stringarray zur Verfügung steht - wie im guten alten GFA-Basic

Wenn ich heute irgendwas mit viel Stringgewurschtel (privat) schnell machen will, pack ich diese Sachen immer noch aus.

[volkard]

Bitsy schrieb:

Dazu muß man aber auch sicherstellen, daß es einfach nicht gelingt, nachträglich ein 0-Zeichen in dem String unterzubringen.

WARUM?

Für eine solche Operation wäre eine von String abgeleitete Klasse sinnvoll.

WARUM?

Ich sehe die Gefahr nicht. In einen std::string kann ich auch 0-Zeichen reinstopfen, wie ich mag und habe ich damit keinen Ärger.

[volkard]

hustbaer schrieb:

Klassische Pascal String verwenden ein fixed-size Array (typischerweise 256 Byte gross). Im ersten Byte steht die aktuelle Länge, danach kommt der Text. Nullterminiert sind sie dafür nicht.

Das erste Byte als Größenangabe, der Rest als Zeichenfolge, keine Nullterminierung. Soweit klar.
Aber fixed-fized Array klingt nach tierischer Speicherplatzverschwendung. Daran mag ich nicht glauben. Zumal es nicht notwendig wäre, weil Pascal (im Gegensatz zu Basic) schon zu Zeiten des 64-ers eine Freispeicherverwaltung hatte. Kann es sein, daß die 640k vom DOS, sagen wir mal 500k Vokabelprogramm frei, nur 1000 Vokabelsätze gepaßt haben oder nur 500 Records mit Name/Vorname/Straße/Ort.

[audacia]

volkard schrieb:

hustbaer schrieb:

Klassische Pascal String verwenden ein fixed-size Array (typischerweise 256 Byte gross). Im ersten Byte steht die aktuelle Länge, danach kommt der Text. Nullterminiert sind sie dafür nicht.

Das erste Byte als Größenangabe, der Rest als Zeichenfolge, keine Nullterminierung. Soweit klar.
Aber fixed-fized Array klingt nach tierischer Speicherplatzverschwendung. Daran mag ich nicht glauben. Zumal es nicht notwendig wäre, weil Pascal (im Gegensatz zu Basic) schon zu Zeiten des 64-ers eine Freispeicherverwaltung hatte.

War aber so, gerade weil man dem Programmierer beim Arbeiten mit Strings manuelle Speicherverwaltung à la C ersparen wollte.

Modernere Implementationen von Pascal (Delphi) verwenden ähnlich wie BSTR zusätzliche vier Bytes vor den eigentlichen Stringdaten, wo die Länge gespeichert wird; der String wird vollständig auf dem Heap alloziert (mit Referenzzählung und COW-Semantik), und so sind String-Variablen nur sizeof(void*) groß. Der Nachteil ist, daß Length(theString) öfter mal einen Cache-Miss verursacht - aber i.d.R. kann der Compiler redundante Aufrufe (z.B. in einer Schleifenbedingung) ohnehin wegoptimieren.

Ein schöner Aspekt dieser Implementation ist, daß der Compiler Stringliteralen gleich die Länge und einen angpaßten Referenzzähler voranstellen kann, so daß bei

const
  cSomeLiteral = 'some literal';
var
  S: String;
  SL: Integer;
begin
  S := cSomeLiteral;

keine Kopie angelegt, sondern nur der Referenzzähler erhöht werden muß, und

SL := Length (cSomeLiteral);

sich auf eine Zeigerdereferenzierung beschränken kann.

Zwecks Kompatibilität mit dem Windows-API und C++Builder sind die Strings natürlich dennoch zusätzlich nullterminiert.

[volkard]

audacia schrieb:

War aber so, gerade weil man dem Programmierer beim Arbeiten mit Strings manuelle Speicherverwaltung à la C ersparen wollte.

die operatoren für strings waren doch eingebaut, oder? also kein new, strcpy und strcat.
hast du irgend eine quelle für diene these?

[audacia]

volkard schrieb:

die operatoren für strings waren doch eingebaut, oder? also kein new, strcpy und strcat.

In Wirths Pascal war, soweit ich mich erinnere, gar nichts dergleichen eingebaut; es gab nicht einmal einen Stringtypen (http://www.moorecad.com/standardpascal/pascalfaq.html#Q.%20How%20do%20I%20perform%20string%20operations%20in%20standa).

volkard schrieb:

hast du irgend eine quelle für diene these?

Nicht zur Hand, nein. Aber es liegt eigentlich nahe: für jeden String eine Heap-Allokation wurde als zu teuer angesehen, und so war ein stackbasierter String mit Komfort-Erweiterungen gegenüber array[0..x] of char ein guter Kompromiß.

In der Implementation von Turbo Pascal war es darüber hinaus möglich, die Maximallänge des Strings explizit anzugeben:

var
  S: String[20]; // 21 Bytes groß

Übrigens kannst du ja einfach Turbo Pascal herunterladen und nachschauen.