C++ Funktionen auslagern



  • Habe im Projektmappen-Explorer folgende Dateien:

    Headerdateien:
    ausFunktion.h
    stdafx.h
    targetver.h

    Quelldateien:
    funktionen01.cpp
    stdafx.cpp

    Quellcode aus funktionen01.cpp:
    #include "stdafx.h"
    #include <iostream>
    #include "ausFunktion.h"

    using namespace std;

    int main(void)
    {
    int iWert1 = 2, iWert2 = 3, iErg = 0;
    iErg = iMultiplikation(iWert1, iWert2);
    cout <<iErg << endl;
    return 0;
    }

    Quellcode aus ausFunktion.h:
    int iMultiplikation(int iWert1, int iWert2)
    {
    int iRueck = 0;
    iRueck = iWert1 * iWert2;
    return iRueck;
    }

    Um eine Mehrfachdeklaration zu vermeiden, wo/was für C++ Code muss man wo einfügen? Wie funktioniert es, wenn ich später die Funktionen zu einer Bibliothek zusammenfassen möchte?

    Danke für eure Hilfe.



  • Verwende [cpp]-Tags (erste Schaltfläche), um deinen Code zu formatieren.

    Du darfst in der Headerdatei nur die Deklaration der Funktion haben:

    int Multiplikation(int Wert1, int Wert2);
    

    Die Definition schreibst du in die zugehörige Implementierungsdatei – diese hat den selben Namen wie die Headerdatei, nur die Endung .cpp:

    int Multiplikation(int Wert1, int Wert2) 
    { 
        return Wert1 * Wert2;
    }
    

    Was soll eigentlich dieses fragwürdige "i" vor jedem Bezeichner?



  • Nexus, danke für die Hilfestellung.

    Das mit

    ...
    

    merke ich mir für mein nächstes Problem.

    Der i-Index soll zeigen, dass es sich bei der Variable um einen Integer Typ handelt. Wie macht es normalerweise um zu erkennen, um was für ein Variablentyp es sich handelt?



  • Nexus schrieb:

    Was soll eigentlich dieses fragwürdige "i" vor jedem Bezeichner?

    http://de.wikipedia.org/wiki/Ungarische_Notation



  • Nexus schrieb:

    Was soll eigentlich dieses fragwürdige "i" vor jedem Bezeichner?

    Ist 'ungarische Notation' und sehr sinnvoll, um im Code die deklarierten Datentypen gleich erkennen zu können. Gehört in die Rublik 'Programmierstil' und darauf sollte man auch achten! 😋



  • berniebutt schrieb:

    Ist 'ungarische Notation' und sehr sinnvoll, um im Code die deklarierten Datentypen gleich erkennen zu können. Gehört in die Rublik 'Programmierstil' und darauf sollte man auch achten! 😋

    Dass es sich um Ungarische Notation handelt, ist mir schon bewusst. Nur ist diese ein Relikt aus der Zeit der strukturierten Programmierung mit ganz wenigen Datentypen. Ich bin der Meinung, in C++ ist Ungarische Notation äusserst sinnlos. Hier meine Begründung.



  • berniebutt schrieb:

    Ist 'ungarische Notation' und sehr sinnvoll, um im Code die deklarierten Datentypen gleich erkennen zu können. Gehört in die Rublik 'Programmierstil' und darauf sollte man auch achten! 😋

    Aus dem Wikipedia-Artikel:

    Letzteres ist für den schlechten Ruf der Konvention verantwortlich, weil die Benennung einer Variablen nach dem Datentyp wenig zum Verständnis des Inhalts beiträgt und trotzdem viel Aufwand verursacht.

    Eingeführt hat die Konvention, den Präfix nicht nach seiner Bedeutung sondern nach dem Datentyp zu belegen, angeblich Microsoft 😉

    Ich persönlich werde durch die Präfixe in der Lesegeschwindigkeit gebremst. Vor allem wenn die Namen eh schon recht kryptisch sind kommt ein zusätzliches "i" am Anfang doch total in die Quere. Ist sicher alles geschmackssache, mir schmeckt es nicht 😉



  • Joachim1980 schrieb:

    Wie macht es normalerweise um zu erkennen, um was für ein Variablentyp es sich handelt?

    Man muss sich auch die Frage stellen, was man durch die Kennzeichnung von Variablen nach Typen überhaupt erreicht. Am besten denkt man etwas weiter als nur "es ist praktisch, weil man den Typen sofort sieht". C++ bietet einem sehr viele Konzepte, um von konkreten Typen zu abstrahieren (Laufzeitpolymorphie, Templates, Funktionsüberladung, typedef ). Und warum? Weil es in vielen Fällen nicht darum geht, den exakten Typ zu kennen, sondern die unterstützte Semantik.

    Und was hat das mit UN zu tun? Mechanismen, die den Typen einer Variable anhand von Präfixen in Stein meisseln, gehen genau den entgegengesetzten Weg. Man bindet sich fest an einen Typen, was Flexibilität und Abstraktion stark einschränkt. Ein gutes Beispiel ist deine Funktion iMultiplikation() : Wenn du in Zukunft eine Funktion bereitstellen willst, die float s multipliziert, musst du sie fMultiplikation() nennen, statt sinnvoll Überladung einzusetzen.

    Weitere Argumente findest du im von mir verlinkten Thread, lies doch ein paar davon durch. 😉



  • Ich verstehe das alles und letztendlich doch nicht. Mit früheren Compilern hatte man für Bezeichner meist nur 8 Stellen zur Verfügung. Das war noch viel unübersichtlicher. FORTRAN unterschied die Datentypen sogar nach dem ersten Zeichen des Bezeichners. i bis n waren integer, alles andere float. Wollt ihr das zurück? Ich werde mit der 'ungarische Notation' nicht in der Lesegeschwindigkeit gebremst. Doch ich gebe zu, dass selbst nicht mehr voll durchzuziehen. Lassen wir dem ungarischen MS-Programmierer die Ehre, die ihm gebührt!


  • Administrator

    @berniebutt,
    Wie jetzt? Verwendest du die ungarische Notation nur, um Herrn Simonyi die Ehre zu erweisen? 😕
    Ansonsten verstehe ich deine Argumentation im Ganzen nicht ganz. Ist die nun dafür oder dagegen?

    Übrigens möchte ich hier noch den ganzen Auschnitt aus Wikipedia zitieren, nicht nur den Satz, welcher l'abra d'or gezeigt hat. Für diejenigen, welche das nicht genauer nachlesen gehen, damit es auch klar ist, worum es geht:

    Die von Simonyi entwickelte Konvention wurde bei Microsoft in der Application Group (Excel, Word etc.) mit großem Erfolg angewandt und in der Folge von der Systems Group (Windows) übernommen, wobei es zu einem grundlegenden Missverständnis kam. Simonyi spricht in seinem Paper vom „type“ einer Variablen, was vielfach als „Datentyp“ interpretiert wurde. Gemeint ist vielmehr die Art der Variablen im spezifischen Kontext einer Applikation. Es geht also nicht so sehr darum, ob eine Variable Ganzzahl oder Kommazahl ist, sondern ob es sich um einen Zähler handelt, eine Koordinate auf dem Bildschirm, einen Index in einem Array o. ä.

    Durch diese Zweideutigkeit existieren zwei Strömungen der Ungarischen Notation, das Apps Hungarian, welches die echte Notation im Sinne Simonyis ist, und das Systems Hungarian, welches durch die Fehlinterpretation der Microsoft’schen Betriebssystemabteilung entstanden ist. Letzteres ist für den schlechten Ruf der Konvention verantwortlich, weil die Benennung einer Variablen nach dem Datentyp wenig zum Verständnis des Inhalts beiträgt und trotzdem viel Aufwand verursacht.

    Also das, was man heutzutage meistens unter ungarische Notation versteht, ist nur ein völliger Unsinn von Microsoft und gar nicht das, was Simonyi eigentlich bezwecken wollte mit seiner Notation.

    Ich hoffe, dass berniebutt auf die richtige Weise dem Herrn Simonyi die Ehre erweist 🙂

    Grüssli



  • berniebutt schrieb:

    Mit früheren Compilern hatte man für Bezeichner meist nur 8 Stellen zur Verfügung. Das war noch viel unübersichtlicher.

    Auf früheren Computern hatte man nur wenige Kilobytes Speicherplatz zur Verfügung. Das ist noch viel weniger als ein Megabyte.
    Und trotzdem reicht heute ein Megabyte nicht mehr aus.

    berniebutt schrieb:

    Wollt ihr das zurück?

    Willst du die paar Kilobytes zurück?

    ...

    Schon mal was von Fortschritt gehört? Warum sollten wir uns an antiquitiere Techniken klammern, wenn sie offensichtlich keine relevanten Vorteile haben? Schreibst du absichtlich schlechten Code, um diversen Leuten "die Ehre zu erweisen"?



  • Ich versteh den Wirbel um die "ungarische Notation" nicht. Gut, dass die Kennzeichnung des Datentyps eine dämliche Idee ist, darin sind sich inzwischen alle einig (wie würde man das eigentlich bei Templates machen? :p), aber den Sinn der Variable zu kennzeichnen, ist so oder so üblich. Und ob ich jetzt

    int record_id;
    

    oder

    int idRecord;
    

    schreibe, scheint mir wirklich nicht besonders wichtig zu sein.

    Natürlich gibt es Fälle, in denen eine strenge Auslegung solcher Notationsregeln unübersichtlich und deshalb auch eher unüblich ist - Schleifenvariablen etwa. Ich kenne eigentlich niemanden, der ernsthaft

    for(int ixX = 0; ixX < dimX; ++ixX) {
      for(ixY = 0; ixY < dimY; ++ixY) {
        arr2dGrid[ixX][ixY] = calculateStuff();
      }
    }
    

    schreibt. (wahlweise mit x_ix, y_ix, x_dim, y_dim usw. - sieht genau so dämlich aus) Diese Dinge sollen der Übersichtlichkeit dienen; wenn das Ergebnis unübersichtlich ist, lässt man's eben sein.



  • seldon schrieb:

    Ich versteh den Wirbel um die "ungarische Notation" nicht. ... aber den Sinn der Variable zu kennzeichnen, ist so oder so üblich ... Schleifenvariablen etwa. Ich kenne eigentlich niemanden, der ernsthaft schreibt. (wahlweise mit x_ix, y_ix, x_dim, y_dim usw. - sieht genau so dämlich aus) Diese Dinge sollen der Übersichtlichkeit dienen; wenn das Ergebnis unübersichtlich ist, lässt man's eben sein.

    Das ist richtig. Es geht nur um die Übersichtlichkeit und um das leichte Verständnis eines eigenen oder fremden Codes. Für Schleifen verwendet man nach altbekannter Sitte gewöhnlich die alten FORTRAN-Regeln i, j, k ... Für vieles hat sich die 'ungarischen Notation' überholt. Für lokale Variable innerhalb von Funktionen macht es aber ohne besondere Ehrerbietung an Symonyi durchaus Sinn, wenn es damit verständlicher wird.

    Aber war das jetzt das Thema?


  • Administrator

    berniebutt schrieb:

    Aber war das jetzt das Thema?

    Ja:

    Joachim1980 schrieb:

    Wie macht es normalerweise um zu erkennen, um was für ein Variablentyp es sich handelt?

    Ich begreife aber deine vorherige Argumentation immer noch nicht, berniebutt 😉

    berniebutt schrieb:

    Es geht nur um die Übersichtlichkeit und um das leichte Verständnis eines eigenen oder fremden Codes.

    Weshalb man ganz sicher auf die ungarische Notation à la Microsoft verzichten sollte 😃

    berniebutt schrieb:

    Für Schleifen verwendet man nach altbekannter Sitte gewöhnlich die alten FORTRAN-Regeln i, j, k

    Ich verwende es nicht, weil es mal in FORTRAN eine Regel gewesen sein soll. Ich verwende i, weil es die Abkürzung für index ist und die meistens das so verstehen. Wobei ich auch schon index direkt verwendet habe. Ich verwende aber oft auch zum Beispiel x und y, für die X und Y Koordinate. Aber ich halte mich da sicher nicht, an irgendwelche alten FORTRAN Regeln, käme mir nicht in den Sinn. Ich habe ja noch nicht einmal mit FORTRAN programmiert.

    berniebutt schrieb:

    ... Für vieles hat sich die 'ungarischen Notation' überholt. Für lokale Variable innerhalb von Funktionen macht es aber ohne besondere Ehrerbietung an Symonyi durchaus Sinn, wenn es damit verständlicher wird.

    1. Nochmals: Welche ungarische Notation jetzt? Die, welche Joachim1980 eingesetzt hat, ist nämlich von Microsoft und die macht ja nicht viel Sinn.
    2. Inwiefern setzt du sie ein? Inwiefern macht sie Sinn? Was verstehst du unter verständlicher?

    Gerade weil die ungarische Notation immer wie mehr überholt ist, wird sie weniger eingesetzt und ist daher weniger bekannt. Wenn dann jemand so einen Code liest mit ungarischer Notation, und derjenige die ungarische Notation nicht kennt, würde ich den Code für die Person nicht als verständlicher oder lesbarer bezeichnen.

    Grüssli



  • Ich finde die ungarische Notation (im Microsoft-Sinn) übrigens oft nützlich für dynamisch typisierte Programmier/Scriptsprachen, wo man den (aktuellen) Typ einer Variablen nicht aus der Deklaration entnehmen kann. Für C++ allerdings nicht.

    Bsp:

    function fadeout(sId) //es wird klargemacht, dass hier ein String erwartet wird
    {
       ...
    }
    


  • Dravere schrieb:

    berniebutt schrieb:

    Für Schleifen verwendet man nach altbekannter Sitte gewöhnlich die alten FORTRAN-Regeln i, j, k

    Ich verwende es nicht, weil es mal in FORTRAN eine Regel gewesen sein soll. Ich verwende i, weil es die Abkürzung für index ist und die meistens das so verstehen. Wobei ich auch schon index direkt verwendet habe. Ich verwende aber oft auch zum Beispiel x und y, für die X und Y Koordinate. Aber ich halte mich da sicher nicht, an irgendwelche alten FORTRAN Regeln, käme mir nicht in den Sinn. Ich habe ja noch nicht einmal mit FORTRAN programmiert.

    Du verwendest doch selbst diese Regeln für Bezeichner aus alten Zeiten, obwohl du es nicht müsstest. Warum? Wegen der besseren Übersichtlichkeit und des besseren Verständnisses eben. Also: Die alten Säcke der Programmierer mussten mit weniger Komfort der Compiler klarkommen, haben selbst zur eigenen Erleichterung sinnvolle Programmierstile verwendet und geprägt. Die alles entscheidende Grundlage jeder Programmierung bleibt: Ein Programm muss mit möglichst wenig Aufwand stabil, leicht verständlich und jederzeit (auch von fremden Personen) nachvollziehbar und erweiterbar sein. Nichts ist schlimmer als ein Programmierer, der nach einer Weile selbst nicht mehr durchsteigt und verborgene Fehler nicht findet!

    Die 'Ungarische Notation' war und ist da eines von vielen Hilfsmitteln in Richtung verständlich nachvollziehbarer Programmierstil, mehr nicht. Siehe dir die Standardbibliotheken von C/C++ und der WinApi an - überall findest du solche Konventionen, die Sinn machen. Die waren doch nicht alle blöd die alten Säcke der Programmierer - zu denen ich mich auch zähle!

    daddeldu 😋


  • Administrator

    berniebutt schrieb:

    Die waren doch nicht alle blöd die alten Säcke der Programmierer - zu denen ich mich auch zähle!

    Das hat auch überhaupt niemand gesagt. Nur stimmt deine Argumentation hinten und vorne nicht. Du verwendest Dinge wie ungarische Notation oder die Abkürzungen für Variablen in for-Schleifen, weil es früher mal in einem Kontext Sinn gemacht hat, und schlussfolgerts daraus, dass es heute auch noch Sinn macht. Die Sprachen und Techniken entwickeln sich aber weiter, wodurch heutzutage es keinen Sinn mehr machen kann, sowas zu verwenden.

    Man verwendet etwas, nicht weil es eine altbekannte Sitte ist, sondern weil es im aktuellen Kontext Sinn macht. Das ist doch ein riesiger Unterschied!
    Ich verwende zum Beispiel das i in for-Schleifen, nicht weil es früher mal in FORTRAN Sinn ergeben hat, sondern weil ich es im heutigen aktuellen Kontext als sinnvoll betrachte. In Zukunft könnte ich allerdings zu einem anderen Ergebnis kommen und damit aufhören, obwohl es früher Sinn gemacht hat.

    Du klingst wie altes verrostetes Eisen:
    <use voice="grandpa" show="index finger">
    Was wir früher gemacht haben, war das Beste! Deshalb verwende ich dies auch heute noch! Dieser ganze neue Schnick-Schnack ist doch Unsinn!
    </use>
    😉

    Grüssli



  • Dravere schrieb:

    Du klingst wie altes verrostetes Eisen:
    <use voice="grandpa" show="index finger">
    Was wir früher gemacht haben, war das Beste! Deshalb verwende ich dies auch heute noch! Dieser ganze neue Schnick-Schnack ist doch Unsinn!
    </use>

    Vielen Dank für den netten Kommentar. Damit kann ich gut leben. Ich weiss aber auch, wie man das Rosten vermeiden kann, nicht nur bei Eisen! Ich habe nie gesagt, dass alles frühere in der Programmierung das Beste gewesen sei und man heute das auch noch so machen muss. Ich und viele andere wären dann doch nie von ALGOL, FORTRAN, PL1, PASCAL &co erst auf C und später auf C++ umgestiegen, wenn der neue 'Schnick-Schnack' - wie nur du das nennst - nichts getaugt hätte.
    daddeldu 😋



  • ...und wir verstehen immer noch nicht, was du ursprünglich sagen wolltest.

    Falls du Argumente für die Ungarische Notation hast, so bring diese! Dass sie früher einmal nützlich war, bestreitet ja gar niemand. Aber das ist das einzige, was du bisher gesagt hast, und reicht sicher nicht als Grund aus, um sie immer noch zu benutzen.


Log in to reply