2dimensionales Array

Hi C64,

das Array ist dann 5x5.

Grüße
Dave

5x5

Index von 0-4

Bei C++ : array[5] --> 0-4 also insgesamt 5 Elemente haben Platz
Bei VB : array(5) --> 0-5 hier haben insgesamt 6 Elemente Platz

Das ist ein wesentlicher Unterschied :-)

Gruß,
Willi

Die werden auch String-Arrays genannt, obwohl es in C und C++ keinen 
eigenen Datentyp "string" gibt. Das mit der \0 zum Schluss hat einen 
guten Grund. Es gibt einen ganzen Haufen String-Funktionen in C und C++ 
(string.h), die sich nach der 0 am Schluss orientieren. Beispiel: 
"strlen".
Das nur so zur Ergänzung.

lg,
willi

In VB gibts aber auch die Möglichkeit, array(x TO y) zu schreiben, dann 
sieht man, welche Indizes möglich sind; Also array(5) = array(0 TO 5)

Willi S. schrieb:
> Die werden auch String-Arrays genannt, obwohl es in C und C++ keinen
> eigenen Datentyp "string" gibt. Das mit der \0 zum Schluss hat einen
> guten Grund. Es gibt einen ganzen Haufen String-Funktionen in C und C++
> (string.h), die sich nach der 0 am Schluss orientieren. Beispiel:
> "strlen".
> Das nur so zur Ergänzung.
>
> lg,
> willi

Mh zumindest in C++ gibts strings ;)

Karl heinz Buchegger schrieb:

> Die STL ist offizieller Bestandteil von C++ und sollte als solcher auch
> verwendet werden.

Nichts sollte verwendet werden, nur weil es da ist. Warte mal ab, was 
fuer ein Zeug sie noch in C++ stopfen...

Karl heinz Buchegger schrieb:

> In Zusammenhang mit der Aussage 'In C++ gibt es keine String Klasse'
> kann man trotzdem aber nur auf die in der STL vorhandene std::string
> verweisen.

Dem Teil habe ich ja auch nicht widersprochen, sondern dem danach.

Karl heinz Buchegger schrieb:

> Hintergrund: man hört immer wieder die Aussage, dass std::string und
> Konsorten nicht zu C++ gehören, weil die ja in einer STL (igitt)
> residieren und damit nicht zur Sprache gehören. Und das ist ganz einfach
> Unsinn. Mit der gleichen Argumentation könnte man auch sagen, dass
> strcpy nicht zu C gehört, weil es ja schliesslich nicht in der Syntax
> verankert ist.

Stimmt. Den beiden ist gemeinsam, dass man sie sehr gut von der 
eigentlichen Sprache trennen kann. Und das ist das Schoene an C und C++ 
und das macht sie so geeignet fuer viele Platformen. Der Overhead, den 
man mitschleppen muss, ist extrem klein.

> Wenn man aber diese Zwänge nicht hat, spricht nichts gegen
> std::string. Immer noch besser, als wenn sich Lieschen Müller selbst die
> x-te Stringklasse baut.

Doch sicher gibt es genuegend Gruende fuer so eine Entscheidung. Aber es 
ist wohl muessig, das hier zu diskutieren. Das hatten wir schon und das 
fuehrt leider zu gar nichts.

> Meistens sind es einfach nur historische Gründe, warum man mit
> std::string nicht weiterkommt.

std::string hat irgendein compilerspezifisches Encoding und ist in der 
Regel nicht unicode-geeignet. std::wstring ist das teilweise, solange 
man die Strings nicht von irgendwo lesen oder irgendwo hinschreiben 
will. Dann hat man nämlich auch das Problem, daß man zwischen 
irgendeinem compilerspezifischen Encoding und dem externen Encoding 
konvertieren muß. Das ist mit standard-C++ dann recht umständlich und 
wird längst nicht von allen Compilern vernünftig unterstüzt. Die Namen 
der Encodings sind dann dazu auch noch compilerspzifisch,  und eine 
Liste der verfügbaren Encodings kann man in standard-C++ auch nicht 
ermitteln.
Mit einer Kombination aus std::wstring und iconv kann man aber 
einigermaßen arbeiten. Allerdings ist std::wstring nicht gerade 
sonderlich komfortabel. Deshalb gibt es wohl so viele APIs, die ihre 
eigene String-Klasse mitliefern.