C++ doch nicht so gut?!

[dreaddy]

Die Tatsache das Pointer und die Möglichkeit Arrays über ihre eigentliche Grenze hinaus zu beschreiben sehr oft sehr sinnvoll sind und das mehr Sicherheit gegen Programmiereruntauglichkeit oft recht viel Systemleistung frisst und nicht selten selber undefinierbare Fehler produziert(die man nichtmal beheben kann) wird verschwiegen

"oh nein sein Auto fährt besser und schneller als das gelbe da hinten, wir sollten es ihm schnell weg nehmen sonst baut er noch einen Unfall"
Was soll denn seiner Meinung nach kommen? Gleichzeitig mit der PSbegrenzung der Autos auch kein C und C++ vor Überschreiten des 25ten Lebensjahres?

Als ob man in anderen Sprachen weniger Fehler macht =[ Und in der WIN NT Serie die grad ja aktuell ist(98,95 und ME is ja bekanntlich ein totes Gleis) kann man nicht mehr viel mit Pointern ausserhalb erschiessen.

[Gregor]

dreaddy schrieb:

Die Tatsache das Pointer und die Möglichkeit Arrays über ihre eigentliche Grenze hinaus zu beschreiben sehr oft sehr sinnvoll sind [...] wird verschwiegen

Da bin ich jetzt aber mal gespannt. Nenn mir mal ein Beispiel, wo es sinnvoll ist, bei einem Zugriff auf ein Array außerhalb der Arraygrenzen zu arbeiten.

[Bashar]

dreaddy: inwiefern ist denn die Möglichkeit, über Arraygrenzen hinausschreiben zu können, sinnvoll?

[volkard]

[/quote]
Da bin ich jetzt aber mal gespannt. Nenn mir mal ein Beispiel, wo es sinnvoll ist, bei einem Zugriff auf ein Array außerhalb der Arraygrenzen zu arbeiten.[/quote]
da fällt mir eigentlich nur der alte

struct message
{
   int sender;
   int receiver;
   char text[1];
};
nebst
message* buildMessage(int s,int r,char* t)
{
   void* m=malloc(8+strlen(t)+1);
   m->sender=s;
   m->receiver=r;
   strcpy(m->text,t);
}

dazu ein.
<ima badguy>geht sogar mit dem mavc und c++ (so ähnlich), aber mit dem gcc nicht, weil er den vptr hinter die members legt.</ima badguy>

[virtuell Realisticer]

...
Service Pack C++.

lol, ich wusste doch, dass C++ nur en Service Pack ist

mfg
v R

[y]

Ist der Artikel vom Spieleprogrammierer?

[Newbie1]

Kann das also keiner befürworten?!
In dem Artikel steht allerdings das nur diejenigen die nicht mit C++ umgehen können das der Fall ist.

[Floh]

wenn man mit etwas nicht umgehen kann, egal womit, kanns tierisch in die hose gehen. wenn man zu dumm ist einen gasherd zu bedienen fliegt man in die luft - deshalb darf man sich trotzdem einen gasherd kaufen.

mit der sprache an sich hat das null zu tun.

[Bashar]

Wie gesagt: Der Artikel ist eine Lachnummer wegen offensichtlicher Ahnungslosigkeit des Autors. Über das Thema an sich kann man sich natürlich unterhalten, das ist was anderes.

[kartoffelsack]

Würde verhindert werden, dass man über die Grenze schreibt/liest, müsste bei jedem Zugriff eine Prüfung stattfinden. Und eine Prüfung kostet.
Zwar mag ein einzelner if-Vergleich wenig erscheinen, aber wenn man z.B. ein Array aus integern hat ist ein

if( Array[3] == 5)

mit Überprüfung der Grenzen schlicht und einfach doppelt so teuer wie ohne. Und es macht schon einen Unterschied, ob eine Abfrage von zigtausend Werten 1 Minute oder zwei dauert.

[dreaddy]

naja ein einfaches Beispiel wäre sowas:

char felder1[10];
char felder2[5];
char felder3[30];

void init(void)
{
  for(int i = 0; i < 45; i++)felder1[i] = 0;
}

das mag jetzt zwar umgehbar aussehen(ist es meist auch) aber es gibt halt Kombinationen wo sowas halt mal Sinn macht.
Beispielsweise wenn man an der Struktur nichts ändern kann oder man halt auch mal auf felder2 Zugriff haben will ohne offiziell mit Pointern zumwursten zu müssen.

[Bashar]

Das Programm hat undefiniertes Verhalten.

[HumeSikkins]

Das Programm hat undefiniertes Verhalten.

Und zwar zurecht, wie ich finde

Was stört dich z.B. an:

char felder1[10] = {0}; 
char felder2[5] = {0}; 
char felder3[30] = {0};

[Marilyn]

Aus dem Heise-Forum:
"Hallo,

bevor das hier groessere Kreise zieht: Es handelt sich
bei dem Beitrag um einen Kommentar -- also einen Betrag
der versucht, mit diversen Stilmitteln eine Diskussion
anzuregen.Dazu gehoert auch das *fiktive*
Advisory (und damit auch die erfundenen Zitate von K&R).

Ich dachte das "Kuerzlich auf heise Security" und
die kursive Schrift machen das ausreichend deutlich.
Vielleicht muessen wir das doch noch deutlicher
kennzeichnen."

Wo der Sinn jetzt dahinter steckt, kann ich mir auch nicht erklären...

[Bashar]

Naja, im heise-Forum hat irgendwer die FIKTIV-Tags nicht gesehen und gefragt, warum er das Adivsory nicht auf securityfocus findet. Ob das Advisory unlustig ist oder nicht, darum gehts aber primär nicht, sondern um das Geschreibsel darunter.

[Shade Of Mine]

der artikel bezieht sich auf C und nicht auf C++

denn mitlerweile sind wir von

int arr[10];

ja zum glueck weg.

denn ein
StaticArray<int, 10> arr;

ist nicht nur sicherer, sondern man kann die laufzeit kosten selber einstellen (Stichwort: policies)

raw pointer verwendet man auch nicht mehr - und durch templates gibt es eine enorme typsicherheit.

allerdings muss ich dem artikel teilweise recht geben:

C/C++ verlangt dem Programmierer viel an Eigenverantwortung ab, mit der offensichtlich zu viele überfordert sind.

traurig, aber wahr.

wenn man keine dieser C++ features verwendet die solchen Fehler vorbeugen, dann kann man nix machen.
nur wuerde ich dafuer nicht die sprache beschuldigen, sondern die programmierer.

programmieren ist teilweise so einfach geworden, dass jeder dummkopf ein programm schreiben kann -> nur wird dieser dummkopf nie mit C++ fertig werden - denn C++ ist keine leichte sprache wie PHP oder Visual Basic.

[dreaddy]

Es ist nicht definiert das untereinander stehende Variablen auch untereinander stehen müssen?
Hm dachte da das jeder macht sei es so.

[Bashar]

Wer macht das so?

[Floh]

wenn sachen untereinander stehen stehen sie untereinander das stimmt schon

das steht oben
das steht unten

spaß beiseite.
wenn du arrays untereinander deklarierst wie in deinem beispiel könnte man vielleicht meinen daß das programm an einer speicheradresse diese zuzuordnen und dann einfach weiter macht. das muss das programm aber nicht! deswegen darf man nicht davon ausgehen daß es vielleicht doch so sein könnte. im allgemeinen enthält die speicheradresse nach dem array irgendetwas mit dem man nichts anfangen kann.
kleines beispiel: du benutzt ein multitaskingfähiges os, dein programm schreibt grad ein array. nachdem es damit fertig ist bekommt ein anderes programm rechenzeit zugeteilt und schreibt direkt nach deinem array in den speicher, und so fort. stell dir vor du schreibst dann fünf integers hinter deinem array ein neues array, wenns dumm läuft über die daten eines systemtreibers.
*peng*

[puh]

wenns dumm läuft über die daten eines systemtreibers

zum glück gibt es ja den protected mode.