Sauber Klasse?

leicht enttäuscht schrieb:

boah, ich dachte "nix da" kennt sich aus.

Und dann macht er soviele Fehler.

und Deutsch kann er auch nicht

rüdiger

@DrGreenthumb
auch in C++? Hab mir das () mal angewöhnt, weil volkard sonst nie meinen Code lesen wollte

Aber ich weiss nicht wie man auf die Liste zugreifen sollte, da va_start ja den letzten Parameter vor der Liste erwartet.

Jester

nix da schrieb:

weil ich nicht umbedingt immer sowas schreiben wollte:
vector angle (0,0,0;
angle = angle2 (vector1, vector2);

Häh? seit wann ist denn ein Winkel ein Vektor???

double theta = angle(vector1,vector2);

fertig.

Und was ist mit op+, op*? die sollten über die entsprechenden op+= bzw. op*= implementiert sein (diese wiederum dann als Member).

nix da

cd9000 schrieb:

Nein. getX() ist eine inline-Funktion, daher generiert diese Zeile exakt den gleichen Code wie:
float _31 = vector.x;

Naja aber sind wir doch mal ehrlich: Würdest Du sowas machen bei einer Matrixklasse in einer Matrizenmultiplikationsfunktion? Wenn ja biste echt ein C++ Hoschi (nichts für Ungut aber man kann es auch etwas "übertreiben")

Jester
Also sollte man als "Faustregel" es so ausdrücken: op+-/ sollen "normale" Funktionen sein und op +-/= in die Klasse implementiert werden. Sehe ich das richtig?

Und op+-/ sollen per op+-/= implementiert werden?

DrGreenthumb

kingruedi schrieb:

@DrGreenthumb
auch in C++?

nee nee, meine heutiges C.

Jester

nix da schrieb:

Also sollte man als "Faustregel" es so ausdrücken: op+-/ sollen "normale" Funktionen sein und op +-/= in die Klasse implementiert werden. Sehe ich das richtig?

Und op+-/ sollen per op+-/= implementiert werden?

Ja, das ist gut.
Grund ist, daß dadurch sicher gestellt ist, daß Operatoren mit gleichem Namen auch das gleiche tun. Achte auch darauf die korrekten Rückgabewerte zu verwenden.

op+= sollte als Rückgabe ne const& haben, op+ ein const-Objekt. Andere analog.

MfG Jester

interpreter

Jester schrieb:

op+= sollte als Rückgabe ne const& haben, op+ ein const-Objekt. Andere analog.

Darüber lässt sich streiten. Schließlich sollte man sich ja an den Spruch "Do
as the ints do" halten und sowas geht ja auch:

int j=0;
(j+=2)=3;

Blue-Tiger

nix da schrieb:

kingruedi schrieb:

2. Die Variablen sind in der public Schnitstelle. Auch hier solltest du den Link lesen

Naja ich wollte es eigentlich konfortabel halten und nicht immer sowas machen:
float _31 = vector.getX();
Das würde bei einer 4x4 Matrix schon sehr auf die Performance hauen, sofern ich mir das Logisch zusammen wurschtel, vorallem bei Matrizenmulitplikationen. Währe es zu Sachen des "Speeds" nicht logisch das OCP zu "sträken"? Denn ich weis nicht eine get_32() funktion bei einer Matrixklasse fände ich extrem bäh.

zum void: ich finde das bei Syntaxhighlight schöner und erkennlicher, aber jedem das seine, denkst du das ist ein Starkes Kriterium?

1. schonmal was von inline gehoert? ein vector.getX() kann genauso schnell sein wie ein vector.x

2. void foo(void) ist C, und in C++ ist dafuer ausdruecklich void foo() vorgesehen.

nix da

Blue-Tiger schrieb:

2. void foo(void) ist C, und in C++ ist dafuer ausdruecklich void foo() vorgesehen.

Wo steht denn das geschrieben?

nix da

Jester
Hab noch eine frage zu den Operatoren:

inline const bool operator == (const vector &vec1, const vector &vec2)
{
    for (int i=0; i<4; ++i)
    {
        if (vec1.values[i] != vec2.values[i])
            return (false);
    }
    return (true);
}

inline const bool operator != (const vector &vec1, const vector &vec2)
{
    return (!(vec1==vec2));
}

So habe ich die beiden Operatoren != und == implementiert, ich hoffe so ist richtig

Nur bei dem Operator = weis ich nicht weiter. Den muss man aber wie die x= Operatoren IN die klasse stopfen, weil intern elemente verändert werden, gell?

@nix da
wenn ich mich recht erinner kannst du dir den operator!= sparen da der schon als template version in der STL ist.

Mal ne frage, wenn ich sowas schreibe:

inline const vector operator + (const vector &left, const vector &right)
{
    return (vector(left.getX()+right.getX(), left.getY()+right.getY(), left.getZ()+right.getZ()));
}

//und will nun folgendes tun:
int main (void)
{
    vector vec1 (3,2,1);
    vector vec2 (1,2,3);;

    loki::vector x = vec1+vec2;
}

Bekomme ich diesen Fehler:
error C2593: 'operator +' is ambiguous

Wieso, was habe ich falsch gemacht??

denkt euch das loki:: weg, war ein flüchtigkeitsfehler beim schreiben. alles im globalen namespace

fehler kommt aber trotzdem noch

peterchen

Geb ich auch noch meinen Senf dazu...

1) Kritisch:
Mathemsatisch falsche Implementation von * (hier erwartet man das Skalarprodukt), und das "sinnlose" operator/(). Zeigt, daß du wenig Erfahrung mit Vektorrechnung hast. Schlecht wenn du dich als Programmierer bei einer 3D-Speileschmiede bewerben willst.

Mangelhafte Dokumentation. was ist w?

Verwendung einer platformspezifischen Assembler-Implementation ohne eine Entsprechende portable variante.

2) Verwirrend
Dieses this. Ich hab schlimmeres gesehen, aber man fragt sich schon...

3) Dein Anliegen
Was willst du mit dem Code zeigen?
Eine vector-Klasse ist nix wirklich ungewöhnliches, und eher eine Fleißarbeit. Außerdem kann man da jederzeit eine abschreiben. Ich würd' mal kurz drüberlesen ob mir was auffällt (und wenn du Glück den operator* - Lapsus übersehen)

Hier wären höchstens die Gründe für deine Design-Entscheidungen interessant (Member zugänglich für Komfort? Oder ist Kapselung wichtig/sinnvoll? wie werden plattformspezifische Optimierungen unterstützt?)

Wenn du ein ineressantes problem elegant löst, wäre das nett. Prinzipiell erwarte ich aber gar keinen Code bei den Bewerbungsunterlagen oder im Anschreiben.

peterchen

@ ***: du kannst gern eine neue Frage aufmachen...

(ganz IMHO - hier würd' ich mich von einem Kandidaten auch vom Gegenteil überzeugen lassen )
Kapselung:
Wie weit man eine Klasse kapselt ist m.E. eine Design-Entscheidung, die man natürlich vertreten können muß.

vector ist in den meisten Anwendungsfällen so kritisch, daß man sehr starke Performance-Garantien geben muß - hier genügt nicht mal "amortized constant time", sondern wirklich: ist X ist ein Member, und float.
Welche Implementationsalternativen existieren denn? anderer Datentyp -> muß man nach außen sehen. Polarkoordinaten? killen jegliche Performance-Garantie.

In diesem Sinn sind public - Member in diesem Fall nicht nur Komfort (insbesondere beim Lesen von Komplexeren Vektorarithmetik-Ausdrücken), sondern auch Performance-Garantie.

Gregor

Warum ist die Klasse nicht generisch implementiert? Willst du das gleiche für int, double usw. nochmal schreiben?

interpreter

Gregor schrieb:

Warum ist die Klasse nicht generisch implementiert? Willst du das gleiche für int, double usw. nochmal schreiben?

Float reicht doch (deckt ja int mit ab).

Gregor

interpreter schrieb:

Float reicht doch (deckt ja int mit ab).

Nein.

interpreter

Gregor schrieb:

interpreter schrieb:

Float reicht doch (deckt ja int mit ab).

Nein.

Tolle Antwort. Begründung?