Eigenen Datentyp?

[Gast]

Gugelmoser schrieb:

Hacker schrieb:

1. Kein return 0;

Was habt ihr eigentlich immer an return 0 zu meckern?

Es ist unnötig!

Ach ja! Ein Sache vergessen, du musst natürlich auch die init() Deklaration in der Klasse löschen, damit es keine Linkerfehler gibt.

[Gast]

Hacker schrieb:

Gugelmoser schrieb:

Hacker schrieb:

1. Kein return 0;

Was habt ihr eigentlich immer an return 0 zu meckern?

Es ist unnötig!

Ach ja! Ein Sache vergessen, du musst natürlich auch die init() Deklaration in der Klasse löschen, damit es keine Linkerfehler gibt.

Ich finds inkonsistent.

[Gast]

Gugelmoser schrieb:

Hacker schrieb:

Gugelmoser schrieb:

Hacker schrieb:

1. Kein return 0;

Was habt ihr eigentlich immer an return 0 zu meckern?

Es ist unnötig!

Ach ja! Ein Sache vergessen, du musst natürlich auch die init() Deklaration in der Klasse löschen, damit es keine Linkerfehler gibt.

Ich finds inkonsistent.

Quatsch, es erleichtert allen Pro's das Lesen. return 0; suggeriert, dass uns der Rückgabewert von main() (gerade in diesem Fall) interessiert. Tut er aber nicht! Also kein return; .

[Michael E.]

Hacker schrieb:

Stop. Wieso? Der C++11-Standard behält doch viel vom alten.

Mit dem Textverständnis ists heute nicht so weit her, oder? Der neue Standard enthält Dinge, die nicht im alten Standard stehen (sonst bräuchte man gar keinen neuen Standard). Also "gibt es noch mehr Dinge im C++11 Standard, die der 98er Standard noch nicht kennt". Das hat nix damit zu tun, dass der neue Standard gut über den alten Standard Bescheid weiß.

[Bashar]

Hacker schrieb:

Quatsch, es erleichtert allen Pro's das Lesen.

Woher weißt du das, kennst du einen?

[Michael E.]

Bashar schrieb:

Hacker schrieb:

Quatsch, es erleichtert allen Pro's das Lesen.

Woher weißt du das, kennst du einen?

Er müsste sogar ziemlich viele kennen, um eine Aussage über alle "Pro's" (das tut so weh beim Lesen, haben wir auch Leute hier, die "Tisch'e" schreiben?) machen zu können.

[Gast]

Na,

#include <iostream>

int main()
{
    std::cout << "A" << std::endl;
}

ist IMO viel schöner als

#include <iostream>

int main()
{
    std::cout << "A" << std::endl;
    return 0;
}

[unr'eg]

Hacker schrieb:

Na, [2-SLOC-Code] ist IMO viel schöner als [3-SLOC-Code]

Bläht das ganze Programm ja auch um die Hälfte auf.

Ich als Pro würde natürlich schreiben

int main() { return !(std::cout << "A\n"); }

[Gast]

Kann da überhaupt was schiefgehen?

[Gast]

Hacker schrieb:

...

[vip*r]

Hacker schrieb:

1. Kein return 0;
2. Kein system("pause");
3. Du hast den Destruktor nicht definiert -> lösch die " ~meinDatentyp(); " Zeile wenn er sowieso trivial sein soll
4. Den Konstruktor hast du ebenso wenig definiert -> änder in Zeile 24

void meinDatentyp::init(int n)

zu

void meinDatentyp::meinDatentyp(int n)

Soviel erstmal.
Bitte Initialisierungs-listen verwenden:

void meinDatentyp::meinDatentyp(int n):
feld( new int[n]() )
{
}

Mit dem () nach den Indiz-Klammern wird automatisch alles mit 0 initialisiert.

void meinDatentyp::min()
{
    int ergebnis = 0;
    float mittelwert = 0;//wird nicht verwendet (sollte warnungen geben)
    for(int i(0); i < n; i++)
        ergebnis = ergebnis + feld[i];

    std::cout << "Mittelwert = " << static_cast<float>(ergebnis) / n; // C++-Casts
}

NIE using namespace ...; in Headern!

srand(...) muss in die main() (wird nur einmal ausgeführt)

Danke, hab das jetzt mal alles umgesetzt und es scheint zu funktionieren! Danke!

Ich hätt hier übrigens wieder ein neues "Problem". Die methode "add" soll mir das Ergebnis der Matrizenaddition zurückgeben. Wenn ich allerdings "return ergebnis;" am Ende der methode schreibe, mosert der Compiler, dass "ergebnis" deklariert sei! Was hat das zu bedeuten? Hier der Code:

#include<iostream>
using namespace std;

class matrix
{
private:
	int m;
	int n;
	int size;
	int *feld;

public:
	matrix(int m, int n);
	~matrix();

	void init();
	void print();
	void input();
	matrix *add(matrix *M);
	void mult();
};

matrix::matrix(int m, int n)
{
	this->m = m;
	this->n = n;

	size = m*n;

	feld = new int [size];
}		//Konstruktor

matrix::~matrix()
{
	delete feld;
}		//Destruktor

void matrix::init()
{
	for(int i=0; i<size; i++)
	{
		feld[i] = 0;
	}
}

void matrix::print()
{
	int counter = 0;

	for(int i=0; i<m; i++)
	{
		for(int j=0; j<n; j++)
		{
			cout << feld[counter++];
		}
		cout << endl;
	}
}

void matrix::input()
{
	for(int i=0; i<size; i++)
	{
		cout << "Wert " << i << " eingeben: ";
		cin >> feld[i];
	}
}

matrix *matrix::add(matrix *M)
{
	if((M->m != m) || (M->n != n))
	{
		cout << "Matrizen nicht gleich gross! Abbruch!";
	}
	else
	{
		matrix *ergebnis = new matrix (m,n);

		for(int i=0; i<size; i++)
		{
			ergebnis->feld[i] = feld[i] + M->feld[i];
		}
	}

return ergebnis;
}

int main()
{
	matrix myMatrix(2,2), myMatrix_M(2,2);

	myMatrix.init();
	myMatrix.input();
	myMatrix.print();

	myMatrix_M.init();
	myMatrix_M.input();
	myMatrix_M.print();

	myMatrix.add(&myMatrix_M);

}

PS: Das "using namespace std;" hab ich jetzt dennoch mal drin gelassen, da es mir jetzt zu aufwändig war, überall den Scope-Operator zu setzen! Sorry, aber das is mir echt zu viel Aufwand, auch wenn es "poor-style" is!

[Gast]

vip@r schrieb:

Ich hätt hier übrigens wieder ein neues "Problem". Die methode "add" soll mir das Ergebnis der Matrizenaddition zurückgeben. Wenn ich allerdings "return ergebnis;" am Ende der methode schreibe, mosert der Compiler, dass "ergebnis"

nicht deklariert sei! Dann pack return ergebnis vor die vorletzte } .

Und eine weitere gute Frage wäre: Who deletes that object?

[Gast]

matrix *matrix::add(matrix *M)
{
    if((M->m != m) || (M->n != n))
    {
        cout << "Matrizen nicht gleich gross! Abbruch!";
    }
    else
    {
        matrix *ergebnis = new matrix (m,n);

        for(int i=0; i<size; i++)
        {
            ergebnis->feld[i] = feld[i] + M->feld[i];
        }
    }

return ergebnis;
}

Er meckert, dass es nicht deklariert ist. Ist es auch nicht. Wie dir (schon lange hoffe ich) klar sein dürfte, bilden Bereiche in den geschweiften Klammern eigene Namensräume (danke an gugelmoser) scopes aus. Es müsste wahrscheinlich so aussehen:

matrix *matrix::add(matrix *M)
{    
    if(M->m != m || M->n != n)
    {
        std::cout << "Matrizen nicht gleich gross! Abbruch!";//Hier kannst du ja auch was werfen
        return 0;
    }

    matrix *ergebnis = new matrix (m,n);

    else
        for(int i=0; i < size; i++)
            ergebnis->feld[i] = feld[i] + M->feld[i];

      return ergebnis;
}

[Gast]

Hacker schrieb:

bilden Bereiche in den geschweiften Klammern eigene Namensräume aus.

Namensraum ist hierfür das falsche Wort.

[Gast]

Gugelmoser schrieb:

Hacker schrieb:

bilden Bereiche in den geschweiften Klammern eigene Namensräume aus.

Namensraum ist hierfür das falsche Wort.

Korrigiert.

[Gast]

Hacker schrieb:

Gugelmoser schrieb:

Hacker schrieb:

bilden Bereiche in den geschweiften Klammern eigene Namensräume aus.

Namensraum ist hierfür das falsche Wort.

Korrigiert.

:p Das nennt sich compound statement (Verbundanweisung / Block). Und eine Verbundanweisung führt einen local scope / block scope ein.

[cooky451]

What the? Matrixaddition gibt Speicher zurück den man wieder freigeben muss? Ist das ernst gemeint?

[pumuckl]

cooky451 schrieb:

Ist das ernst gemeint?

Vermutlich nicht so ganz, sondern einfach nur von einer der zig bestehenden Uralt-Bibliotheken inspiriert, die genau solche Dummheiten machen. Sowas von 90er

[vip*r]

Danke für eure Antworten! Dass diese Variable im compound statment der else-Abzweigung gültig ist, ist mir natürlich schon länber bewusst. Ich hab halt nur noch nicht so die große Erfahrung, dass ich solche Fehler auf Anhieb sehe. Danke an euch!

Gugelmoser schrieb:

Und eine weitere gute Frage wäre: Who deletes that object?

Dass hier noch nicht zerstört wird, ist auch klar. Das sollte ich wohl auch noch implementieren. Danke! Ich liefere bei Gelegenheit den gesamten Code nach. Wahrscheinlich heute noch.

pumuckl schrieb:

cooky451 schrieb:

Ist das ernst gemeint?

Vermutlich nicht so ganz, sondern einfach nur von einer der zig bestehenden Uralt-Bibliotheken inspiriert, die genau solche Dummheiten machen. Sowas von 90er

Bitte zerreisst halt meinen Code jetzt nicht in so große fetzen. Es funktioniert. Ich bin halt noch etwas unerfahren. Übung macht den Meister und nur durch die Fehler bei der Übung lernt man. Wie hättet ihr denn das gemacht? Mir war halt einfach nur diese Möglichkeit in den Sinn gekommen, dass die Additionsfunktion einen Speicherbereich auf das Ergebnis zurückgibt!

[SeppJ]

vip@r schrieb:

Bitte zerreisst halt meinen Code jetzt nicht in so große fetzen. Es funktioniert.

Das ist kein gutes Kriterium. Eine Bruchbude, die beim ersten Windstoß einfällt, nennst du auch nicht Haus, bloß weil es momentan noch hält.

Ich bin halt noch etwas unerfahren. Übung macht den Meister und nur durch die Fehler bei der Übung lernt man. Wie hättet ihr denn das gemacht?

Guck doch auf der ersten Seite! Da habe ich einen langen Roman mit vielen googlebaren Stichwörtern geschrieben, wie man den Code ganz einfach (sogar einfacher als er momentan ist!) viel robuster machen kann, so dass man sich um gar nichts mehr sorgen braucht und es einfach funktioniert. Außerdem habe ich dir erklärt, was am Momentanen Code nicht so gut ist.

Dein Beitrag auf Seite 3 hat mich dann doch etwas entsetzt , denn wie es scheint, hast du dir nicht einmal die Mühe gemacht, meine Erklärungen auch nur quer zu lesen, geschweige denn, dich mal mit den Stichworten weiterzubilden.