Programm für Parkhaussteuerung

_matze

Sprechende Variablennamen sind wesentlich sinnvoller. Dann weißt du auch nach ein paar Tagen, Wochen, Monaten noch, wofür eine Variable eigentlich steht.

memphiz schrieb:

Also l= Etage ( 4 Etagen )

m= Reihe ( 3 Reihen )

n= Parkplätze (Etage 1-3 90 Parkplätze, Etage 4 80 Parkplätze)

k= Etage

j= Reihe

i= Parkplätze in einer Reihe

Ich bin noch anfänger in diesem Gebiet.. daher will ich erstmal keine anderen befehle außer diese benutzen.

GERADE als Anfänger sollte man sich nicht damit rausreden. Ich hab die STL auch viel zu lange schleifen lassen, aber wenn man sie kennt, ist sie Gold wert!
Warum nicht das ganze Objektorientiert lösen? Dafür ist es doch C++. Mit sowas wie von Dir kannst auch gleich ANSI C programmieren.

class CParkplatz
{
public:
   bool IstBelegt() const { return m_belegt; }
   void SetzeBelegt(bool b) { m_belegt = b; }

private:
  bool m_belegt;
};
// ich gehe mal von einer festen zahl von 5 Parkplätzen aus
class CReihe
{
public: 
   void BelegeParkplatz(int index) { m_parkplatz[index].UmschaltenBelegt(true); }
   void ParkplatzFrei(int index) { m_parkplatz[index].UmschaltenBelegt(false); }

   int FreieParkPlätze() const 
   {
      int nResult = 0;
      for ( int i = 0; i<4;i++ )
      {
          if ( m_parkplatz[i].IstBelegt() )
          {
++nResult;
          }
      }
      return nResult;
   }
private:
   CParkplatz m_parkplatz[4];
};

// wieder fester wert, 20 Reihen pro Etage
class Etage
{

private:
  CReihe m_reihen[20]
};

Das mal als schnell reingehämmertes Beispiel, wie sowas vieeeel eleganter und viel lesbarer geht.
rya.

ps.:

void main ()

AUA! int main() oder int main(int argc, char** argv) aber nicht void! Niemals nimmer.

wie wärs denn wenn du mal dein gehirn nutzen würdest? den anfang hast du doch schon

lg der cplusprofi

volkard

Scorcher24 schrieb:

void main ()
AUA! int main() oder int main(int argc, char** argv) aber nicht void! Niemals nimmer.

warum nicht? kann dein compiler das nicht? ist es verboten, das zu schreiben? ist es den compolerbauern verboten, das zu erlauben?

volkard schrieb:

warum nicht?

ich vermute mal: weil es falsch ist. in diesem forum geht es nämlich um c++ nach dem iso-standard. abweichungen davon bringen einem potenziell probleme ein, wenn man z.b. den compiler wechselt. deshalb ist es gut und richtig, auf die einhaltung des standards hinzuwirken und entsprechende fehler, vor allem wenn sie unnötig sind, aufzuzeigen und zu korrigieren. so lernen die anfänger nämlich korrektes c++, und nicht irgendeinen dialekt, den ein compilerbauer gut findet.

P.S.: traurig, dass man das einem moderator erklären muss. noch trauriger ist, dass ein moderator so unbehelligt rumtrollen darf wie du das ständig tust.

audacia

trolljäger schrieb:

abweichungen davon bringen einem potenziell probleme ein, wenn man z.b. den compiler wechselt.

Ich bin mir relativ sicher, daß es beim Migrieren von C++-Code auf einen anderen Compiler dringlichere Probleme gibt als den Rückgabewert der Einstiegsfunktion.

audacia schrieb:

Ich bin mir relativ sicher, daß es beim Migrieren von C++-Code auf einen anderen Compiler dringlichere Probleme gibt als den Rückgabewert der Einstiegsfunktion.

und? es ist vielleicht nur ein kleines steinchen im mosaik. es gibt dann wahrscheinlich auch dringlichere probleme als ein #include <iostream.h> , soll man deshalb solchen quatsch jetzt einfach unkommentiert stehen lassen?

volkard schrieb:

Scorcher24 schrieb:
void main ()
AUA! int main() oder int main(int argc, char** argv) aber nicht void! Niemals nimmer.
warum nicht? kann dein compiler das nicht? ist es verboten, das zu schreiben? ist es den compolerbauern verboten, das zu erlauben?

DU weisst ganz genau warum, Mr. Autor :p.
http://faq.cprogramming.com/cgi-bin/smartfaq.cgi?id=1043284376&answer=1044841143
Es ist nicht standardkonform. Punkt. Und als newbie soll er lernen wie das Standardkonform funktioniert. Ich bin da auch nicht 100% perfekt, aber die groben Fehler kann man doch ansprechen. Und im Gegensatz zu manch anderem bin ich lernwillig/-fähig.
rya.

edith rief grade an:
http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.3

volkard

Scorcher24 schrieb:

DU weisst ganz genau warum, Mr. Autor :p.

mich stört die vehemenz, mit der die einäugigen den blinden was vorschreiben. "aber nicht void! Niemals nimmer.", als wenn das ein staatsverbrechen wäre.
dieses verhalten sehe ich übrigens nicht nur bei c++, sondern in allen fachbereichen.

volkard schrieb:

Scorcher24 schrieb:

DU weisst ganz genau warum, Mr. Autor :p.

mich stört die vehemenz, mit der die einäugigen den blinden was vorschreiben. "aber nicht void! Niemals nimmer.", als wenn das ein staatsverbrechen wäre.
dieses verhalten sehe ich übrigens nicht nur bei c++, sondern in allen fachbereichen.

Ok, wenn ich das zu "stark" rübergebracht habe tut mir das leid.
Aber ich hab das früher auch so geschrieben und zwar ne ziemliche Zeit lang ;). Stand in meinem Buch damals so drin von M&T. Leider ist das immer noch sehr verbreitet :(.
rya.

Nexus

volkard schrieb:

dieses verhalten sehe ich übrigens nicht nur bei c++, sondern in allen fachbereichen.

Das Problem besteht auch darin, dass Anfänger es nicht ernst nehmen, wenn man sagt: " void main() ist nicht unbedingt so gut, vielleicht wäre int main() besser."

Das ist ähnlich wie mit goto - als Anfänger lässt man lieber ganz die Finger davon, da man es mit grosser Wahrscheinlichkeit falsch einsetzen wird und sich dadurch ein schlechter Codestil herausbildet. Mit der Zeit bildet man sich aber weiter und hört automatisch neue Meinungen. Dazu sollte man auch beginnen, Dinge zu hinterfragen. Strikte Anweisungen sind anfangs oft geeigneter - auch wenn es später dazu berechtigte Ausnahmen geben mag.

Hier hingegen kann man auch immer int main() schreiben, ohne irgendwann etwas zu verpassen. Besser, man tut das von Anfang an, gerade weil es gegenüber void main() nur Vorteile bietet.

volkard schrieb:

mich stört die vehemenz, mit der die einäugigen den blinden was vorschreiben.

der standard schreibt vor, nicht die "einäugigen" (ist das eigentlich zwanghaft bei dir?)

"aber nicht void! Niemals nimmer.", als wenn das ein staatsverbrechen wäre.

im staate c++ ist es ja auch ein verbrechen.

Scorcher24 schrieb:

Ok, wenn ich das zu "stark" rübergebracht habe tut mir das leid.

volkard

jägertroll schrieb:

"aber nicht void! Niemals nimmer.", als wenn das ein staatsverbrechen wäre.

im staate c++ ist es ja auch ein verbrechen.

nö. lies 3.6.1.2
da stehts ganz deutlich, daß compilerbauer auch andere formen anbieten dürfen.

7H3 N4C3R

volkard schrieb:

jägertroll schrieb:

"aber nicht void! Niemals nimmer.", als wenn das ein staatsverbrechen wäre.

im staate c++ ist es ja auch ein verbrechen.

nö. lies 3.6.1.2
da stehts ganz deutlich, daß compilerbauer auch andere formen anbieten dürfen.

Ja und nein.

3.6.1(2) schrieb:

An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main: [blablabla]

Andere Formen sind zusätzlich zulässig, aber sie müssen int zurückgeben.

volkard schrieb:

nö. lies 3.6.1.2
da stehts ganz deutlich, daß compilerbauer auch andere formen anbieten dürfen.

3.6.1.2 schrieb:

It shall have a return type of type int, but otherwise its type is implementation-defined.

ach, zu spät.

volkard

7H3 N4C3R schrieb:

Ja und nein.

3.6.1(2) schrieb:

An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main: [blablabla]

Andere Formen sind zusätzlich zulässig, aber sie müssen int zurückgeben.

mist. da habe ich das "otherwise" als "anderenfalls" statt als "im übrigen" übersetzt. jetzt bin ich aber verunsichert.

drakon

volkard schrieb:

7H3 N4C3R schrieb:

Ja und nein.

3.6.1(2) schrieb:

An implementation shall not predefine the main function. This function shall not be overloaded. It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main: [blablabla]

Andere Formen sind zusätzlich zulässig, aber sie müssen int zurückgeben.

mist. da habe ich das "otherwise" als "anderenfalls" statt als "im übrigen" übersetzt. jetzt bin ich aber verunsichert.

Wie ich das sehe sind das nichtmal die einzigen beiden deutungen..
Irgendwie wiederspricht sich das ganze ja auch. int ist ja ansich schon Implementierungsabhängig. Von dem her erübrigt sich der zweite Teil ja. Wie sollte dann (im Falle von "im übrigen") int sonst noch anders sein? Oder im Falle von "andernfalls" wiederspricht sich das mit dem ersten Teil..

So Sachen würde ich gerne die Leute fragen, die das geschrieben haben..

_matze

drakon schrieb:

Wie sollte dann (im Falle von "im übrigen") int sonst noch anders sein?

Die Rückgabe steht so wohl fest, aber vielleicht ein dritter Parameter, der bei irgendeinem (Phantasie-)OS theoretisch einen Sinn haben könnte?

drakon

_matze schrieb:

drakon schrieb:

Wie sollte dann (im Falle von "im übrigen") int sonst noch anders sein?

Die Rückgabe steht so wohl fest, aber vielleicht ein dritter Parameter, der bei irgendeinem (Phantasie-)OS theoretisch einen Sinn haben könnte?

Hmm. Ich habe das immer bezogen auf den Rückgabewert gelesen. Mit der Funktionssignatur macht es natürlich mehr Sinn, aber das ist ja eigentlich kein Typ..
Eine Stickwortliste wäre hier wahrscheinlich eher verständlich gewesen.

_matze

drakon schrieb:

Hmm. Ich habe das immer bezogen auf den Rückgabewert gelesen.

Ja, so hört es sich auch an. Mit "its type" muss eigentlich der Rückgabewert, der Typ der Funktion, gemeint sein. Ich habe nur versucht, in dem Halbsatz irgendeine Logik zu entdecken...