goto...

THX 1138 schrieb:

Windooof schrieb:

Wie macht Ihr das denn, wenn ihr Speicher, so Stück für Stück? mit new anlegen müsst und gleichzeitig prüfen müsst, ob da noch genuch ist?

Ich nem STL Container die das für mich übernehmen

Leder sind da einige (ich persönlich) nicht in der Lage sowas (STL nicht kompatibel mit dem Compiler) anzuwenden (man kann ja nicht immer alles haben,oder? :))..

THX 1138

Windooof schrieb:

THX 1138 schrieb:

Windooof schrieb:

Wie macht Ihr das denn, wenn ihr Speicher, so Stück für Stück? mit new anlegen müsst und gleichzeitig prüfen müsst, ob da noch genuch ist?

Ich nem STL Container die das für mich übernehmen

Leder sind da einige (ich persönlich) nicht in der Lage sowas (STL nicht kompatibel mit dem Compiler) anzuwenden (man kann ja nicht immer alles haben,oder? :))..

Dann biste irgendwie im falschen Subforum, oder hol Dir nen anständigen Kompeiler..

THX 1138 schrieb:

Dann biste irgendwie im falschen Subforum, oder hol Dir nen anständigen Kompeiler..

Ich hab ja den Thread nich aufgemacht ... Hab mich nur angeschlossen

Mit meinem Compiler bin ich aber sehr zufrieden. Ich schreibe ja meine Programme nur quasi nebenbei :).

Was ist eigentlich mit dem Thema dieses Threads? Interessiert mich immer noch, ob mein Prog mit goto schneller laufen würde? Gibt es da irgendwelche Vorteile oder nur Nachteile?

Schildkroete

Windooof schrieb:

THX 1138 schrieb:

Dann biste irgendwie im falschen Subforum, oder hol Dir nen anständigen Kompeiler..

Ich hab ja den Thread nich aufgemacht ... Hab mich nur angeschlossen

Mit meinem Compiler bin ich aber sehr zufrieden. Ich schreibe ja meine Programme nur quasi nebenbei :).

Was ist eigentlich mit dem Thema dieses Threads? Interessiert mich immer noch, ob mein Prog mit goto schneller laufen würde? Gibt es da irgendwelche Vorteile oder nur Nachteile?

Ich sage wieder mal, dass du dir den asm-output angucken sollst. Da kannst du sehen, dass goto mit einem einfachen JUMP Befehl übersetzt wird, dass heißt, dass der Code zwischen goto und Ziel übersprungen wird, was natürlich sehr schnell ist. Letzendlich wird aber bei jeder Bedingung (if else if else switch etc.) die erfüllt/nicht erfüllt ist zu dem passenden code-teil gesprungen, und daher wird dein Programm durch den Einsatz von gotos nicht schneller...
Gruß,
Chrissi

PS: Du solltest generell solche Frickelein dem Compiler mit seinem Optimizer überlassen, die machen das in der Regel schneller und besser

Also verstehe ich, dass es keinen Unterschied macht ob man if...else if, goto oder Sonstige einsetzt - am Maschinen-Code kommt immer dasselbe dabei raus. Richtig?

volkard

Windooof schrieb:

Also verstehe ich, dass es keinen Unterschied macht ob man if...else if, goto oder Sonstige einsetzt - am Maschinen-Code kommt immer dasselbe dabei raus. Richtig?

jup.

es gab mal einen fall bei mir mit MSVC6, wo

while(frickelcode);

schneller als jede alternative war.

es gab einige, wo

for(ganz_normal1){
   ganz_normal2;
}

schneller als jede alternative war.

fast immer (zu mehr als 99%) war aber immer

for(a;b;c)
 d;

identisch mit

{a;
 while(b){
  d;
  c;
}

und ich konnte mich auch ansonsten auf den kopf stellen, for, while, do, if-goto, alle schleifen, die das gleiche resultat berechnen, sind gleich schnell.

aber eine fast lustige sache gilt darüberhinaus: "schöne" schleifen kapiere ich besser und kann sie dann nachoptimieren.
aso ich baue erstmal if-goto oder while oder for. gerade das, was mir einfällt. innendrin mache ich auch if/else auch mal ein if-continue. dann schaue ich mal, ob ich die schleife auf- oder abwickeln kann.

a;
while(x){
 b;
 c;
 a;
}

wird zu

while(x){
 a;
 b;
 c;
}
//bei dateisachen nicht selten

und sonst noch so allerlei. nicht selten zerfällt ein zehn-zeilen-monster bei sowas in einen vierzeiler. dann kann ich dem einen bessewren funktionsnamen geben, weil ich erst jetzt kapiere, was der eigentlich macht (es war ja eigentlich ganz einfach). auf einmal werden die aufrufer der funktion deswegen auch verständlicher und da mach ich dann gleich weiter...

also ich empfehle dringend, unabhängig von den sehr seltenen einzelfällen, wo dieses oder jenes konstrukt schnmeller ist, immer dahin zu optimieren, wo man den code besser versteht. das fürht dann zu erleuchtung . damit erreicht man mehr speed. und nebenbei fehlerarmut bin ins ungelaubliche. natürlich hält man sich frei, bestimmte funktionen später noch zu verunvereinfachen, um dort speziellen speed zu bekommen. aber bei lichte betrachtet ist das immer nur das anpassen an einen compilerbug. in dem fall tuste gut daran, die einfache funktion als kommentar drüber leben zu lassen.

Konrad Rudolph

Windooof schrieb:

Mit meinem Compiler bin ich aber sehr zufrieden.

Also, wenn der doofe Compiler nicht mal die STL kann, dann hast Du eigentlich keinen Grund, damit zufrieden zu sein. Was für ein Unding von Compiler verwendest Du denn da? Zufällig den alten MSVC-Compiler?

Krux

Zitat aus einem Tutorial, das ich mal gelesen hatte: "verwende niemals goto goto ist böse"

Wenn man goto verwendet, kann man nurnoch schlecht Datenkapselung durchführen, was den ganzen Quellcode übersichtlich macht. Auch geht dabei eine feste Struktur flöten, was den Code unübersichtlich macht. Man kann auch ohne goto sehr gut optimieren.

PS: ich hab mir hier nichts durchgelesen bis auf den Titel.

Schildkroete

Konrad Rudolph schrieb:

Windooof schrieb:

Mit meinem Compiler bin ich aber sehr zufrieden.

Also, wenn der doofe Compiler nicht mal die STL kann, dann hast Du eigentlich keinen Grund, damit zufrieden zu sein. Was für ein Unding von Compiler verwendest Du denn da? Zufällig den alten MSVC-Compiler?

Es gibt bestimmte Bereiche (bei Windows z.B. die Programmierung von Ring0-"Programmen") bei denen nicht der volle Umfang der C++-Features benutzt werden können und daher gibt es dafür spezielle Compiler welche bewusst STL usw. nicht understüzten.

GCoder

Mein Ausbilder schlägt mich, wenn ich gotos verwende