nach ein paar Jahren Abstinenz wollte ich mich heute mal wieder was mit C++ beschäftigen. Als Einstieg hab ich mal den folgenden Code generiert:

#include<iostream>
using namespace std;

class Spiel {
	private:
	public:
	Spiel();
};

int main() {
	Spiel meinSpiel();
	cout << "Hallo";
	cin.get();
}

//Methoden der Klasse Spiel
Spiel::Spiel() {
	cout << "test, test\n";
}

Mein g++ Compiler compiliert auch ohne jede Probleme nur das die Anwendung nur das "Hallo" und nicht die Ausgabe im Konstruktor der Klasse, also das "test, test", ausgiebt. Ein Freund von mir hat den Code auch noch mal durch Visual laufen lassen, auch da das selbe Problem. Könnt ihr mir/uns helfen?

Ist eine Funktionsdeklaration, nicht wie erwartet (und ein typischer Anfängerfehler) ein Konstruktoraufruf.

Spiel meinSpiel;

Sollte funktionieren.

Wenn ich dem Konstruktor jetzt aber Daten übergeben müsste, dann muss ich diese Klammern behalten oder?

Also so zum Beispiel:

#include<iostream>
using namespace std;

class Spiel {
    private:
    public:
    Spiel(int);
};

int main() {
    Spiel meinSpiel(1);
    cout << "Hallo";
    cin.get();
}

//Methoden der Klasse Spiel
Spiel::Spiel(int i) {
    cout << i;
}

Ja. Wird doch auch kompiliert haben, daher weißt du doch, dass es so geht^^

Ganz ganz ganz böse Einstellung...

Wieso? Trail und Error ist sehr gut zum lernen. Wenn der Compiler es kompiliert, er sich noch erinnert, dass es so oder ähnlich ging und es genau das tut, was es soll, soll das ne ganz schlechte Einstellung sein?

Anzunehmen das Code richtig ist, nur weil er kompiliert, ist eine sehr schlechte Einstellung.

Trial and Error ist eine der schlechtesten Lernmethoden. Man hat zwar schnell Fortschritte, lernt jedoch nichts wirklich richtig.

Wieso? Trail und Error ist sehr gut zum lernen. Wenn der Compiler es kompiliert, er sich noch erinnert, dass es so oder ähnlich ging und es genau das tut, was es soll, soll das ne ganz schlechte Einstellung sein?

Ja ist ne schlechte Einstellung. Wenn du weißt dass es "irgendwie so in der Art" geht und so lange rumprobierst bis der Compiler keine Zähne mehr spuckt und dann schaust was rauskommt und dir das Ergebnis gefällt, heißt das folgendes:

1. Du hast in Wirklichkeit keine Ahnung wie du erreichen kannst was du willst.
2. Du hast dem Compiler etwas zu Fressen gegeben von dem du in Wirklichkeit keine Ahnung hast was es tut
3. Du glaubst, weißt aber nicht, was los ist und wunderst dich später wenn die nach einer winzigen, harmlosen Änderung plötzlich alles um die Ohren fliegt.

Für den Glauben hat der Herrgott die Kirche erfunden. Hier gehts darum, zu wissen was man tut und dass das was man tut auch so richtig ist.

Spiel meinSpiel();

Ist eine Funktionsdeklaration

Warum haben die das so bescheuert gemacht? Gibt es irgendeinen Fall wo man eine Funktionsdeklaration in einer Funktion braucht?

Also ihr meint im ernst, dass ausprobieren schlecht ist?
Was schlagt ihr sonst vor? Nur durch Üben und probieren lernt man wirklich.
Das man nachguckt, wie es aussehen muss, ist klar. Sonst hat man ja keine Ahnung wo man anfangen soll

Durch lesen eines guten Buches und langem nachdenken, darüber was der Code machen soll und wie er es macht.

asc schrieb:

Spiel meinSpiel();

Ist eine Funktionsdeklaration

Warum haben die das so bescheuert gemacht? Gibt es irgendeinen Fall wo man eine Funktionsdeklaration in einer Funktion braucht?

Möchtest du eine unterschiedliche Syntax in Funktionen und außerhalb?

kingcools schrieb:

Also ihr meint im ernst, dass ausprobieren schlecht ist?
Was schlagt ihr sonst vor? Nur durch Üben und probieren lernt man wirklich.
Das man nachguckt, wie es aussehen muss, ist klar. Sonst hat man ja keine Ahnung wo man anfangen soll

Durch lesen eines guten Buches und langem nachdenken, darüber was der Code machen soll und wie er es macht.

und nachdenken und trail und error schließen sich aus? wäre mir neu

Programmieren lernt man durch programmieren und nicht durch langes nachdenken. Wie die Syntax einer Sprache richtig ist, lern man auch am besten, wenn man programmiert und Fehler macht.

Programmieren und Syntax lernt man durch eine Kombination aus Lernen (Bücher, Tutorials [zu meiner Zeit hatten wir noch kein Modem, was damals auch sehr teuer gewesen wäre]) und Praxis (Programmieren). Der Mensch lernt am meisten, wenn er viele Quellen verwendet. Reines Ausprobieren hilft ebenso wenig wie reines Bücherlernen.

4000$ schrieb:

Ich glaub nicht, dass einer von den "Experten" hier ein paar Bücher gelesen, lang nachgedacht, alles verstanden und dann ohne Fehler los programmiert hat.

Nein, aber ein Kapitel gelesen, versucht ob man es verstanden hat, und dann das nächste Kapitel gelesen. Ich rechne meine Fachbücher im IT bereich inzwischen auch eher in Metern (wobei ich neuerdings tendenziell in elektronischer Form meine Fachliteratur erwerbe, da die eh recht schnelllebig ist)...

warum nur schrieb:

asc schrieb:

Spiel meinSpiel();

Ist eine Funktionsdeklaration

Warum haben die das so bescheuert gemacht? Gibt es irgendeinen Fall wo man eine Funktionsdeklaration in einer Funktion braucht?

Möchtest du eine unterschiedliche Syntax in Funktionen und außerhalb?

Wieso? Einfach nur keine Funktionsdeklaration in einer Funktion erlauben. Compileerror und jeder weiß, dass das kein Konstruktor Aufruf ist.

Programmieren lernt man durch programmieren und nicht durch langes nachdenken. Wie die Syntax einer Sprache richtig ist, lern man auch am besten, wenn man programmiert und Fehler macht

Das stimmt, den Grossteil der Erfahrung sammelt man, indem man selbst programmiert. Dennoch ist dafür ein theoretisches Grundwissen erforderlich. Bevor man etwas anwenden kann, muss man es erst einmal kennen. Und sehr wohl muss man sich ab und zu Zeit nehmen, um etwas in Ruhe durchzudenken – als erfahrener Programmierer ebenso wie als Anfänger. Sowohl über Design und API als auch über konkrete Implementierungen.

warum nur schrieb:

Wieso? Einfach nur keine Funktionsdeklaration in einer Funktion erlauben. Compileerror und jeder weiß, dass das kein Konstruktor Aufruf ist.

Warum sollte man keine lokale Funktionsdeklaration erlauben? Und wie will man hier konsistent bleiben? Denk dran, man kann Objekte auch global definieren, dann hätte man wieder das gleiche Problem.

warum nur schrieb:

Wieso? Einfach nur keine Funktionsdeklaration in einer Funktion erlauben. Compileerror und jeder weiß, dass das kein Konstruktor Aufruf ist.

Warum sollte man keine lokale Funktionsdeklaration erlauben?

Lokale Funktionsdefinitionen sind unzulässig. Wieso dann Funktionsdeklaration erlauben?

Und wie will man hier konsistent bleiben? Denk dran, man kann Objekte auch global definieren, dann hätte man wieder das gleiche Problem.

Nochmal. Wieso wollt ihr die Syntax ändern?

Lokale Funktionsdefinitionen sind unzulässig. Wieso dann Funktionsdeklaration erlauben?

Weil man eine Funktion vielleicht nur innerhalb einer anderen Funktion und nicht in der ganzen Datei bekannt machen möchte.

warum nur schrieb:

Nochmal. Wieso wollt ihr die Syntax ändern?

Was heisst hier ändern? Man macht es so, wie es für global deklarierte Objekte und für BuiltIn-Typen üblich ist. Das ist nichts als Konsistenz. Während dein Vorschlag das Gegenteil davon ist.

Du willst also Folgendes:

void Function()
{
    MyClass var();
}

Aber bei anderen Typen schreibt man:

void Function()
{
    int var;
}

Und bei globalen Objekten schreibt man:

namespace MyNamespace
{
    MyClass var;
}

Und diese Sonderbehandlung nur, weil man als Anfänger ein einziges Mal darüber stolpert, dass MyClass var(); eine Funktionsdeklaration ist? Denkst du nicht, die Fallunterscheidung bei deinem Vorschlag würde noch viel mehr Leuten zu schaffen machen? Mal davon abgesehen, dass sie jegliche Generizität (z.B. T var; in Templates) verunmöglicht.

warum nur schrieb:

Lokale Funktionsdefinitionen sind unzulässig. Wieso dann Funktionsdeklaration erlauben?

Weil man eine Funktion vielleicht nur innerhalb einer anderen Funktion und nicht in der ganzen Datei bekannt machen möchte.

Hast du sowas schon jemals gebraucht? Und die Funktionsdefinitionen muss dann sowieso außerhalb sein, was ja total inkonsistent ist.

warum nur schrieb:

Nochmal. Wieso wollt ihr die Syntax ändern?

Was heisst hier ändern? Man macht es so, wie es für global deklarierte Objekte und für BuiltIn-Typen üblich ist. Das ist nichts als Konsistenz. Während dein Vorschlag das Gegenteil davon ist.

Du willst also Folgendes:
...

Nein. Ihr redet von Syntax ändern. Ich frage: Wozu?

Ich will nur lokale Funktionsdeklaration verbieten.

Nein. Ihr redet von Syntax ändern. Ich frage: Wozu?

Ich will nur lokale Funktionsdeklaration verbieten.

Nexus hat nichts davon geredet, dass die Syntax verändert wird, sondern dass dein Lösungsvorschlag inkonsistent ist:

// Bei globalen Variablen:
MyClass object;

// Wenn du bei globalen Variablen die Klammern hinmachst:
MyClass object(); // <- Zack, Funktionsdekleration.

int foo()
{
  // Deshalb hat man hier:
  MyClass object;
  // Schön einheitlich zum Rest.

  // Wenn man hier plötzlich das hier darf:
  MyClass object();
  // Hat man eine Inkonsistenz zu den globalen Objekten, was noch viel verwirrender ist.
}

Jetzt verstanden?

Grüssli

// Bei globalen Variablen: JA
MyClass object;

// Wenn du bei globalen Variablen die Klammern hinmachst:
MyClass object(); // <- Zack, Funktionsdekleration. JA

int foo()
{
  // Deshalb hat man hier:
  MyClass object;
  // Schön einheitlich zum Rest. JA

  // Wenn man hier plötzlich das hier darf: DAS DARF MAN SCHON UND DAS IST MÜLL WEIL MAN JETZT EINE LOKALE FUNKTIONSDEKLARATION HAT WAS EIGENTLICH KEINER WILL
  MyClass object();  //ICH WILL HIER EINEN COMPILEERROR
}

Jetzt verstanden?

Ich will nur lokale Funktionsdeklaration verbieten.

Warum?