zwei zahlen von methode ans hauptprogramm übergeben!



  • Hi Leute,

    ich bin noch völlig unerfahren und scheitere an folgendem:
    ich möchte in meinem Hauptprogramm zwei Zahlen an eine Methode einer Klasse übergeben. Die Methode soll dann einfach nur die zwei Zahlen im Hauptprogramm zurückgeben:

    Code Hauptprogramm

    #include "stdafx.h"
    #include <iostream>
    using namespace std;
    #include "Klassen.h"
    
    // Deklaration
    int zahl1;
    int zahl2;
    
    void main()
    {
    	klasse1 Zahlenausgeben; // Methode initialisieren?
    
    	cout << "Zahlen ausgeben: \n";
    	Zahlenausgeben.m_zahlenausgeben(55,8);
    	cout << zahl1;
    	cout << zahl2;
    
    	system("pause");
    	 // Peters ersten Lauf initialisieren 
    
    }
    

    eingebundene Klassen.h:

    class klasse1 // Klasse 
    {
    public:	
    		int m_zahlenausgeben(int wert1,int wert2) {
    		int zahl1 = wert1;
    		int zahl2 = wert2;
    		return(0);
    		}
    };
    

    eigentlich hatte ich gedacht, ich versuche das ins return einzubauen, da kann ich aber nur eine zahl ausgeben (was funktioniert hat). An Zeiger hab ich mich noch nicht rangetraut. Dann hab ich das mal so wie gezeigt versucht, aber so einfach ist es wohl nicht, von einer Methode auf das Hauptprogramm zuzugreifen, er gibt mir dann nämlich 00 aus.

    Vielleicht könnt ihr mir helfen?

    Gruß, Patrick



  • #include <utility>
    
    typedef std::pair<int, int> IntPair;
    
    IntPair getValues(int a, int b)
    {
       return std::make_pair(b, b);
    }
    

    Dein Problem könnte mit einem pair<..> gelöst werden, wie der Bsp. Code zeigt.

    Simon

    Edit:
    BTW, die main routine mit void als Return Typ gibts nicht.

    int main()
    {
    }
    


  • gastolino schrieb:

    #include "stdafx.h"
    #include <iostream>
    using namespace std;
    #include "Klassen.h"
    

    Merke: NIE eine using direktive vor einem #include, und NIE in einem Header, wenn du nicht ganz genau weißt was du damit anrichtest!



  • pumuckl schrieb:

    Merke: NIE eine using direktive vor einem #include, und NIE in einem Header, wenn du nicht ganz genau weißt was du damit anrichtest!

    Merke: Diese Regel kenne ich zwar und beachte sie meistens, aber NIE ist etwas Schlimmes bei mißachtung passiert.
    Derwegen ist sie auch nur minderwichtig.



  • pumuckl schrieb:

    ...Merke: NIE eine using direktive vor einem #include, ...

    Da habe ich mir auch schonmal Gedanken drüber gemacht (und mache das auch immer so, weil es mir "logischer" erscheint) und einige Fragen sind bei mir offen:
    Was kann eigentlich schief gehen? Sollten die Header nicht "using-fest" sein (solange sie selbst auch keine using Direktive verwenden)?
    Reicht es nicht eigentlich aus, wenn "using" vor der ersten Verwendung (also dem ersten unqualifizierten Bezeichner) steht?
    In welchem Scope darf using stehen?

    Gruß,

    Simon2.



  • Was kann eigentlich schief gehen?

    Nameskonflikte können auftreten, die sonst durch Namespaces gelöst würde. Es hebelt genau den Namespace Mechanismus aus.

    Sollten die Header nicht "using-fest" sein (solange sie selbst auch keine using Direktive verwenden)?

    Das geht ja gar nicht...

    Reicht es nicht eigentlich aus, wenn "using" vor der ersten Verwendung (also dem ersten unqualifizierten Bezeichner) steht?

    Ja. Und das using gilt dann für den ganzen, aktuellen Scope.

    In welchem Scope darf using stehen?

    Würde mal salop sagen, dort wo auch Klassen Dekl. sein dürfen.
    (Eigentlich überall.)

    Simon


  • Administrator

    Simon2 schrieb:

    Was kann eigentlich schief gehen? Sollten die Header nicht "using-fest" sein (solange sie selbst auch keine using Direktive verwenden)?

    Kollisionen? Es gibt immer noch C++ Header von Bibliotheken, welche nicht alles oder sogar gar nichts in einem Namespace deklarieren. Plötzlich könnte man doppelte Klassendefinitionen haben. ODR wäre dann verletzt.
    Bin mir jetzt zu faul das genau durchzustudieren, aber ich dachte es wäre sogar möglich, dass falsche Funktionen aufgerufen werden könnten. Ich hatte vor sehr langer Zeit, glaub ich, mal so einen Fall, als ich auf solche Dinge noch nicht so acht gegeben hatte 🙂

    Simon2 schrieb:

    Reicht es nicht eigentlich aus, wenn "using" vor der ersten Verwendung (also dem ersten unqualifizierten Bezeichner) steht?

    Doch.

    Simon2 schrieb:

    In welchem Scope darf using stehen?

    Vom Standard gibt es keine Einschränkung. Ich selber benutze using oft in einem lokalen Scope oder einem Namensraum. So verunreinige ich den globalen Scope nicht.

    Grüssli



  • danke theta!



  • volkard schrieb:

    Merke: Diese Regel kenne ich zwar und beachte sie meistens, aber NIE ist etwas Schlimmes bei mißachtung passiert.

    Dann freu dich, ich hatte in inzwischen 2 Projekten schon nach Fehlern aufgrund eines unachtsamen "using namespace" suchen dürfen. Und vor allem: Wenn man von vorne herein diese Regel missachtet, ist das beheben schwerer wenn eine neue Bibliothek Namenskonflikte verursacht.

    Daher: Mag auf dich zutreffen, aber bitte nicht einfach als unwichtig deklarieren, nur weil DU das Problem bislang nicht hattest. Warum nicht Anfängern erst einmal die unproblematische Variante nennen (Man kann einen ja auch sagen unter welchen Umständen man darauf verzichten kann - Aber der Anfänger sollte dies Wissen, damit er selbst abwägen kann).

    cu André



  • Simon2 schrieb:

    Was kann eigentlich schief gehen?

    Ein einfaches Beispiel:

    //x.h
    struct X
    {
      int i;
    };
    
    void swap(X& lhs, X& rhs)
    {}
    
    //main.cpp
    #include <iostream>
    #include <algorithm>
    //using namespace std; (!)
    #include "X.h"
    
    struct Y : public X
    {};
    
    int main()
    {
      Y a;
      a.i = 0;
      Y b;
      b.i = 1;
      swap(a,b);
      std::cout << a.i << ' ' << b.i << std::endl;
    }
    

    ohne using-direktive greift swap(X&, X&) und tut nichts. Mit Using-direktive greift std::swap<Y>(Y&, Y&) und vertauscht die beiden.

    In Alexandrescu/Sutters "C++ Coding Standards" gibts noch ein ausgefeilteres Beispiel, das noch viel schwerer zu erkennende seltsame Verhaltensweisen an den Tag legt.

    Richtig Schlimm wirds wenn das, was ich oben in die main() gepackt hab in irgendeinem Header Y.h steht, z.B. in einer inline-Funktion. Wenn dann in a.cpp einfach nur Y.h includiert wird und in b.cpp erst die using-direktive kommt und dann der #include, dann wird allein dadurch die inline-Funktion in den beiden Übersetzungseinheiten verschiedenes Verhalten haben und die ODR verletzen. Man weiß also nie, was man mit einer using-direktive in den nachfolgend includierten Headern überhaupt anstellt, wenn man den header nicht komplett durchgelesen hat.


Log in to reply