Parameterübergabe (call by reference)

drakon

Nein. Hat schon gestummen. Draverer meinte lediglich, dass der Fehler, den du bekommst das sagt. Also stimmt dort etwas nicht..

Dravere

Lies mal die Fehlermeldung! Dein Funktionskopf lautet:
void searchForSubStr(string& searchStr, MusicTrack*& mT)
Nach dem MusicTrack kommt ein Stern bei deinem Funktionskopf. Er stimmt also nicht mit dem überein, welchen du gezeigt hast.

Grüssli

cryps

aah jetz klingelts

hab die objekte ja mit new.... erzeugt dh.. das heißt ich hab sowieso nur zeiger erzeugt und in den vector ghaut.....na gut dann wär das geklärt..

hätt noch zwei, drei frage: wann is es sinnvoll objekte(zeiger) mit new zu erzeugen und wann soll man sie einfach normal am Stack erzeugen?
Sollte man in erster linie immer Referenzen übergeben oder Objektkopien? (außeracht gelassen ob sich nun am originalobjekt etwas verändern soll oder nicht)...
des weiteren weiß ich noch nicht wie freizügig ich mit konstanten funktionen und variablen umgehen soll ? ... einfach wenn ich glaub dass ich bei übergebenen sachen nix ändert const machen??? ...

drakon

Grunsätzlich alles möglichst ohne new erzeugen, wenn es möglich ist. Ansonsten halt eine dynamische Variante nehmen.
Die Übergabe per Referenz lohnt sich überall, wo nicht gerade eingabaute Typen übergeben werden. Aber so Sachen, wie std::string, o.ä sollte in der Regel mittels Referenz übergeben werden. (Wenn nichts geändert werden soll const).

const solltest du da machen, wo es Sinn macht. (Man kann es auch übertreiben). Funktione sollten, wenn möglich const sein und Übergabeparameter ebenfalls. Da lohnt es sich eigentlich immer das zu machen, wenn es möglich ist. Rückgabewerte sind da so eine Sache. Es gibt Leute, die sagen, dass man Rückgabewerte, die per Kopie erzeugt werden ebenfalls const sein sollen, um so etwas zu verhindern:

if ( f.foo () = 2 ) //merke: kein == , sondern = - Operator
{}

Ob du es machen willst, oder du auf die Intelligenz der Programmierer vertraust seie dir überlassen.

Nexus

cryps schrieb:

hätt noch zwei, drei frage: wann is es sinnvoll objekte(zeiger) mit new zu erzeugen und wann soll man sie einfach normal am Stack erzeugen?

Der Stack (automatischer Speicherbereich) ist schneller, aber hat begrenzten Speicherplatz. Zudem ist man damit weniger flexibel, da Arrays zum Beispiel keine dynamische Grösse besitzen können. Also für kleine lokale Objekte ist der Stack meistens geeignet, für grössere oder dynamischere Dinge nimmt man den Heap (eigentlich Freestore, dynamischer Speicherbereich). Die STL-Container allokieren normalerweise auf dem Heap.

cryps schrieb:

Sollte man in erster linie immer Referenzen übergeben oder Objektkopien? (außeracht gelassen ob sich nun am originalobjekt etwas verändern soll oder nicht)...

Als Faustregel kann man sich merken, dass man Built-In-Typen wie int , bool , double als Kopie übergeben kann, während Klassentypen als Const-Referenz übergeben werden. Bei kleinen Typen lohnt sich eine Übergabe nicht, da das Anlegen einer Referenz oder eines Zeigers etwa gleich lange dauert wie die Kopie und anschliessend noch die Dereferenzierungskosten dazu kommen. Bei grösseren Typen fängt es sich jedoch schnell zu lohnen an. Zudem können gewisse Objekte gar nicht kopiert werden, so zum Beispiel die C++-Streams.

cryps schrieb:

des weiteren weiß ich noch nicht wie freizügig ich mit konstanten funktionen und variablen umgehen soll ? ... einfach wenn ich glaub dass ich bei übergebenen sachen nix ändert const machen??? ...

Ja, grundsätzlich zeigst du mit const an, das sich etwas nicht verändert. Wenn du also Variablen hast, die einmal initialisiert und dann nicht mehr zugewiesen werden, kannst du die konstant machen. Oder Übergabe an Funktionen, die ein Objekt nicht ändern sollen, machst du per Const-Referenz.

Das nachgestellte const bei Memberfunktionen zeigt an, dass die Funktion nichts am operierenden Objekt ändert. Das wird oft bei Get-Methoden, die nur etwas zurückgeben, eingesetzt.

cryps

herzlichen dank für die schlüssigen antworten

noch ne kleine (dumme) frage:

kleine lokale Objekte

ab wann ist ein objekt "groß" genug sodass ich mir überlegen muss ob der heap geeigneter wär ?

Nexus

cryps schrieb:

ab wann ist ein objekt "groß" genug sodass ich mir überlegen muss ob der heap geeigneter wär ?

Dafür gibt es eigentlich keine klare Regel. Du brauchst dir auch nicht zu grosse Gedanken darum zu machen, ich würde wenn möglich auf dem Stack arbeiten. Es ist auch legitim, zum Beispiel lokale Streams (die eher als "grösser" gelten) den Stack zu benutzen. Oder auch Container, da diese sowieso intern den Heap benutzen.

cryps

thx

eine letzte frage noch:

gibt es eine möglichkeit zu überprüfen ob und welche objekte es gibt bei denen man vergessen hat speicherplatz wieder freizugeben?
ich denke bei einem großem projekt und wenn man viel am heap arbeitet verliert man vielleicht auch leicht die übersicht.. und das programm läuft ja auch "korrekt" durch ohne dass man jedes memory-leak gestopft hat....

drakon

Nennt man Memory Leak detector.

Valgrind kann das zum Beispiel:
http://valgrind.org/

Nexus

Ist auch ganz spannend, sowas selber zu programmieren. Besonders, wenn einen die Speicherverwaltung interessiert.

Wenn du Microsoft Visual C++ benutzt, hast du schon einen eingebauten Memory Leak Detector zur Verfügung.

cryps

Microsoft Visual C++

nein verwend ich nicht.. eigentlich verwend ich zZ. noch gar keine ide und arbeite mich mit einem normalen editor mit syntax-highlighting durch.
hab mir ms visual c++ angeschaut und es gefällt mir sehr gut. allerdings wird in der lva (auf die ich mich vorbereite) gcc verwendet also werd ich wohl später auf eclipse zurückgreifen...

drakon schrieb:

Hat schon gestummen.

Es gibt tatsächlich 1200 Treffer bei Google für "gestummen". Das u könnte man ja noch als vertipptes i werten, aber "gestimmen" wäre immer noch falsch. "gestimmt" hätte gestimmt.

Dravere

1200 schrieb:

drakon schrieb:

Hat schon gestummen.

Es gibt tatsächlich 1200 Treffer bei Google für "gestummen". Das u könnte man ja noch als vertipptes i werten, aber "gestimmen" wäre immer noch falsch. "gestimmt" hätte gestimmt.

Er ist Schweizer und im Schweizerdeutschen gibt es nunmal:
"Es het gstumme."
Daraus macht man dann schnell den Fehler:
"Es hat gestummen."

@cryps,
Und wenn sie den GCC verwenden, wieso kannst du nicht den MSVC verwenden? Bei uns an der Uni verwenden sie auch den GCC, bisher konnte ich aber ohne Probleme immer den MSVC einsetzen. Solange der Code dem Standard nachkommt, sollten die beiden Kompiler ohne Probleme damit klar kommen.

Grüssli

drakon

1200 schrieb:

drakon schrieb:

Hat schon gestummen.

Es gibt tatsächlich 1200 Treffer bei Google für "gestummen". Das u könnte man ja noch als vertipptes i werten, aber "gestimmen" wäre immer noch falsch. "gestimmt" hätte gestimmt.

Unglaublich, wie einige nonreg auf die Rechtschreibung fixiert sind..
Ich weiss, dass es gestimmt heisst, allerdings schreibe ich nicht immer mit voller Konzentration auf die Rechtschreibung.. und da kann es mal passieren, dass man sich vertippt, oder halt, wie es mir passiert ein zu sehr verschweizerdeutschtes Wort ohne gross überlegen mal so hinschreibe.. Jetzt kannst du dich über das Wort "verschweizerdeutscht" aufregen, dass es auch nicht gibt..

cryps

Und wenn sie den GCC verwenden, wieso kannst du nicht den MSVC verwenden? Bei uns an der Uni verwenden sie auch den GCC, bisher konnte ich aber ohne Probleme immer den MSVC einsetzen. Solange der Code dem Standard nachkommt, sollten die beiden Kompiler ohne Probleme damit klar kommen.

hm werd ich vielleicht probieren ich möchte nur keine unangenehmen überraschungen erleben zB: dass ich mit dem programm fertig bin und gcc dann doch meckert

Solange der Code dem Standard nachkommt

was wäre denn ein kleines beispiel für einen nicht dem standard entsprechenden code?

drakon

Indem du Spracherweiterungen des Compilers nutzt oder du dich auf ein Verhalten davon verlässt. (z.B in welcher Reihenfolge Ausdrücke ausgewertet werden).

Oder z.B muss eine Datei mit einem Whitespace enden. MSVC erlaubt mit der Spracherweitung auch mit einem normalen Zeichen. Das kann dazu führen, dass der Code auf einem anderen Compiler plötzlich nicht mehr kompiliert.