Was macht folgende Zeile #define for if(false);else for

Hi,

ich bin letztens in irgendeinem Forumsbeitrag im Offtopicforum ueber diese Zeile gestolpert und mich wuerde gerne ineressieren was diese genau bewirkt ich kenne bisher nur solche #define Anweisungen

#define MAX 100

Aber was macht diese Anweisung

#define for if(false);else for

C Newbie

Damit wird ein fehlerhaftes Verhalten des MSVC 6 ausgebügelt.

Ohne diesen "Hack" ist eine Variable im Schleifenrumpf einer For-Schleife auch
auserhalb dieser gültig.

int i;

for(int i = 0; i < 10; ++i)
{...}

Ohne dieses Define wird eine Fehler angezeigt, weil i 2x definiert wurde.

volkard

sie macht aus
for(int i=0;i<10;++i) cout<<i;
ein
if(false);else for(int i=0;i<10;++i) cout<<i;

zweck: bei ms ist die variable i nicht im for eingesperrt (lokal). man kann nach der schleife noch auf i zugreifen. das ist aber im standard anders geregelt.
mit dem makro ist auf einmal die variable im else eingesperrt und doch so brav lokal, wie sie sein soll.

Tatsache ist mir davor noch nie richtig aufgefallen Will MS diesen Bug den gar nicht beseitigen ?

*aleph_0

Anonymous schrieb:

Will MS diesen Bug den gar nicht beseitigen ?

Seit VC++7 ist er beseitigt.

Walli

Jo, aber aus Kompatibilitätsgründen kann man den auch umschalten damit alte Codes noch problemlos kompiliert werden können. hm, da werden sich wohl einige leute umstellen müssen. wie oft habe ich schon so etwas gesehen?

for(int i = 0; i< 100, ++i)
  // ...

for(i = 0; i< 200, ++i)
  // ...

operator void

In VC7.1, das ja eigentlich einen ziemlich guten Compiler hat, gelten auch noch per default die alten for-Regeln - man muss also umschalten, wenn man _richtiges_ C++ schreiben will...

wer 2 nicht verschachtelte schleifen zusammen in einer funktion/methode schreibt, hat eh was falsch gemacht

Helium

wer 2 nicht verschachtelte schleifen zusammen in einer funktion/methode schreibt, hat eh was falsch gemacht

Wieso? Es gibt durchaus Algorithmen, die es erfordern in mehreren Schritten ausgeführt zu werden. Soll ich dann zwei private Methoden basteln und die nacheinander in einer dritten aufrufen? Welchen Vorteil hätte das? Ich sehe grade nur Nachteile: ÜBerflüssige Methodenaufrufe und Unübersichtlichkeit, da der Code an einer falschen Stelle getrennt wurde.

Also ich hätte es dann so gemacht, wie du gesagt hast. Volkard hat mir gelehrt stehts kurze Funktionen zu schreiben.

Shade Of Mine

Unregistrierter schrieb:

Also ich hätte es dann so gemacht, wie du gesagt hast. Volkard hat mir gelehrt stehts kurze Funktionen zu schreiben.

auch 2 schleifen koenenn kurz sein...
sicher, es kommt nicht oft vor - aber manchmal muss eine aufgabe in 2 schritten erledigt werden und da sind zusaetzliche methoden (solange ein schritt recht kurz ist) overkill und erschweren das lesen.

volkard

Helium schrieb:

Wieso? Es gibt durchaus Algorithmen, die es erfordern in mehreren Schritten ausgeführt zu werden. Soll ich dann zwei private Methoden basteln und die nacheinander in einer dritten aufrufen? Welchen Vorteil hätte das? Ich sehe grade nur Nachteile: ÜBerflüssige Methodenaufrufe und Unübersichtlichkeit, da der Code an einer falschen Stelle getrennt wurde.

überflüssige methodenaufrufe? kann dein compiler kein inline?

an der falschen stelle getrennt? ja, das macht manb auch nicht.

wo könnten denn mal zwei schleifen vorkommen? vieleicht beim einsteinrätsel, wenn man ein köstchen bestimmt hat und dann macht

for(int i=0;i<maxx;++i)
   kannSein[y][i]=NEIN;
for(int i=0;i<maxy;++i)
   kannSein[i][x]=NEIN;
kannSein[y][x]=JA;

leider haben die beiden schleifen, die ne ganze spalte verneinen bzw ne ganze zeile verneinen sehr schöne eigenständige bedeutung.
und das kommt bei schleifen verdammt oft vor. solange die schöne eigenständige bedeutung da ist, hacke ich die funktionen auch klein. das oben wären drei funktionen.

es gibt natürlich ausnahmen. nicht immer sollte man schleifen auslagern. findest du mal schnell eine ausnahme, wo man zwei untereinanderstehende schleifen nicht auslagern sollte, und stellst die vor?