C++ doch nicht so gut?!

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*

wenns dumm läuft über die daten eines systemtreibers

zum glück gibt es ja den protected mode.

Floh

wenns gut läuft schreibt er ins leere, aber trotzdem *peng*

DrGreenthumb

Shade Of Mine schrieb:

StaticArray<int, 10> arr;

Was macht das? Eine Index-Überprüfung bei jedem Zugriff?

Shade Of Mine schrieb:

raw pointer verwendet man auch nicht mehr

hm, Wie ist das zu verstehen? Tust du für jeden Zeiger, nen auto_ptr oä. benutzen?

Fänd ich beides schlimm. Dann lieber gleich Java etc., da haben sich schon andere um sowas gekümmert.

Shade Of Mine

verwendet das echt niemand??

ein staticArray hat ne fixe groesse -> also template param
speed ist also identisch wie int arr[10];

vorteil: du kannst die groesse leichter aenern, da du die groesse ja immer ueber arr.size() abfragen kannst (welches inline ist und eine konstante returned - also gratis)

index ueberwachung hast du in der debug version drinnen:

reference operator[](size_type index)
{
ASSERT(index<SIZE);
return array[index];
}

geil, oder?
in der debug version hast du alle sicheren geilen features, die java und co auch haben - und in der release version bist du schnell.

ein zeiger, der speicher besitzt, also mit new angelegt wurde, existiert bei mir nicht.
es gibt immer eine wrapper klasse, dabei rede ich weniger von smart pointern also einfach von abstraktion.

statt
char* p=new char[size];

schreibe ich
cstring p(size);

performance ist gleich -> nur in der debug version habe ich in cstring geile features, wie zB checken ob ueber die grenzen geschrieben wurde.

normale zeiger auf objekte (also keine arrays) gibt es natuerlich schon.
aber da kann man ja nicht viel falsch machen, denn ein ASSERT(p); steht ueberall wo noetig. und wenn ich p[1] schreiben sollte, bin ich ja n depp.
smart pointer verwende ich eigentlich nie.

bedenke:
performance einbussen in der release version sind gleich null
sicherheit in der debug version ist gleich 100%

wenn es einen fehler in der release version gibt, bringt das natuerlich nix - aber das muss man dann eben abwegen, ob man diese debug-features auch in der release version haben will...

der vorteil sollte klar sein: man kann selber waehlen, wo man was wofuer bezahlen will - bei Java und Co hat man konstante kosten -> auch wenn man es nicht braucht.

volkard

Shade Of Mine schrieb:

verwendet das echt niemand??
ein staticArray hat ne fixe groesse -> also template param
speed ist also identisch wie int arr[10];

nein, keiner.
außer dir vielleicht noch bja.
und ich hab nicht den blassesten schimmer, warum das so ist.

Erhard Henkes

siehe auch:
http://www.iste.uni-stuttgart.de/se/people/Schmidberger/Cpp200207.pdf

Unix-Tom

Andere Sprachen nehmen, da C/C++ unsicher!
Bsp. PHP

FRAGE: Wie wurde PHP programmiert?
ANTWORT: In PHP !

Der Artikel sagt aber etwas wichtiges aus.
"Jeder der heute HALLO WELT programmieren kann wird auch bereits als Softwareentwickler eingesetzt"

Das kann ich eigentlich so bestätigen.

AndreasD

@Shade Of Mine: PL1 hat dieses Feature schon seit den 60ern... Wenn ich meine Source mit "Testschalter" umwandle, erfolgen ebenfalls Arrayindex-Prüfungen. Mach ich den Schalter aus, dann fehlen die Prüfungen, aber das Programm läuft mit optimaler Geschwindigkeit!

Kann man mal sehen, wie alt manche Sachen schon sind....

Aber staticArray's in C++ hab ich bislang auch noch nicht genutzt...

rüdiger

Der Artikel ist ziemlich schlecht. Stellt heise nur noch Script Kiddies ein oder die Trolle aus ihren Foren?

nein, keiner.
außer dir vielleicht noch bja.

und kingruedi