c++ bitte um hilfe

du musst nach dem

#include <iostream>

folgende Zeile schreiben:

using namespace std;

dann müssts gehen

probiers mal mit:

using namespace std;

nach #include <iostream>

dann sollten cin und cout deklariert sein

std ist der standard namespace.

gib mal std:: ein, dann wirst du sehen, was da alles drinnen steckt..
Ist im Prinzip wie ein include..

Zitat von Swoncen

std ist der standard namespace.

gib mal std:: ein, dann wirst du sehen, was da alles drinnen steckt..
Ist im Prinzip wie ein include..

naja. include isses nicht wirklich, der Vergleich schmerzt. Du sagst mit std::cin, dass du das cin nehmen willst, das im namespace std definiert ist. Du könntest auch ein uberstd::cin definieren, dann ist es wichtig, dass du zwischen den cin-s auswählen kannst. Ist sozusagen eine Gruppierung. der namespace std wird von vielen stdlibs benutzt. Damit dein compiler weiß, dass du immer std::foo nehmen willst, wenn es global nicht definiert ist, schreibst du als fauler C-Programmierer "using namespace std".

Zitat von Swoncen

gib mal std:: ein, dann wirst du sehen, was da alles drinnen steckt..

Swoncen: Ich nehme an, du meinst hier eine bestimmte IDE? welche?

Zitat von JohannesBuchner

naja. include isses nicht wirklich, der Vergleich schmerzt. Du sagst mit std::cin, dass du das cin nehmen willst, das im namespace std definiert ist. Du könntest auch ein uberstd::cin definieren, dann ist es wichtig, dass du zwischen den cin-s auswählen kannst. Ist sozusagen eine Gruppierung.

Namespaces haben nur den Sinn, unzureichende OOP zu kompensieren.

Zitat von master_fluc

Namespaces haben nur den Sinn, unzureichende OOP zu kompensieren.

Wie kommst du auf die Idee?

Zitat von JohannesBuchner

Swoncen: Ich nehme an, du meinst hier eine bestimmte IDE? welche?

Eine beliebige IDE mit Code Completion

Visual Studio, kdevelop, sogar vim....

Zitat von sauzachn

Wie kommst du auf die Idee?

Weil bei guter OOP keine Funktion zweimal vorkommen wird, da sie in Klassen als Methoden gekapselt sind und eine Klasse auch nicht zweimal vorkommen sollte (was mach ich zB mit zwei Klassen namens Person? - eine Person ist eben eine Person)

C++ ist allerdings keine objektorientierte Sprache und man kanns auch nie komplett objektorientiert programmieren, da man sonst "Funktionsrestklassen" definieren müsste, wie zB für die mathematische Funktionssammlung...

das Objekt cin (als Instanz der Klasse istream) würde bei guter OOP auch niemals zweimal vorkommen, dadurch wird die Idee von Namespaces konterkariert (ich liebe dieses Wort ), die ja gerade verhindern sollen, das der Compiler nicht weiß, welches Objekt / welche Funktion gemeint ist.

Beispiel:

datei1.hpp:
...
foo()
...


datei2.hpp:
...
foo()
...


datei3.cpp:
#include <datei2.hpp>
#include <datei1.hpp>
...
foo();
...

Dem kann man mit Namespaces abhelfen, was aber nichts daran ändert, dass es bei guter Programmierung nicht vorkommen sollte.

Zitat von Ivy

okay ich bin ein fauler c-programmierer, deshalb schreib ich using namespace std. gg

Das sind wohl viele, bis sie mal ein namespace-Konflikt beißt und sie eine Woche lang suchen, warum die Klasse nicht so funktioniert wie in der Dokumentation angegeben

Zitat von master_fluc

Weil bei guter OOP keine Funktion zweimal vorkommen wird, da sie in Klassen als Methoden gekapselt sind und eine Klasse auch nicht zweimal vorkommen sollte (was mach ich zB mit zwei Klassen namens Person? - eine Person ist eben eine Person)

Ich definier natürlich keine zwei Klassen, die jeweils Person heißen, aber man verwendet immer wieder Libraries. Wenn zwei Libraries gleiche Klassennamen deklarieren, hat man den Salat; Namespaces helfen da. (Und ja, Libraries verwenden oft eigene Präfixe für alle Symbole, die sie exportieren -- bingo, genau diese Präfixe kann man sich mit Namespaces theoretisch sparen bzw. hat mit dem Namespace halt eine andere Art Präfix.)

Zitat

C++ ist allerdings keine objektorientierte Sprache und man kanns auch nie komplett objektorientiert programmieren, da man sonst "Funktionsrestklassen" definieren müsste, wie zB für die mathematische Funktionssammlung...

Bitte was? Magst du in Smalltalk demonstrieren, das so eine Funktionsrestklasse sein soll?

Zitat von master_fluc

Weil bei guter OOP keine Funktion zweimal vorkommen wird, da sie in Klassen als Methoden gekapselt sind und eine Klasse auch nicht zweimal vorkommen sollte (was mach ich zB mit zwei Klassen namens Person? - eine Person ist eben eine Person)

Ich hatte diese Situation in CG2 -- ein Model im Model Loader ist was anderes als ein Model in der Physik-Engine oder ein Model in der Graphik-Engine. Schlechtes OOP wäre gewesen, diese alle in eine Klasse zu stecken.

Ohne namespaces hätte ich mit Prefixen anfangen müssen, die nichts anders als eine schlechte Implementation dieses Konzepts sind.

Dass C++ keine echte objektorientierte Programmiersprache ist, da muss ich zustimmen, wenn auch nicht wegen denen von dir angegebenen Gründen.

"I invented the term object oriented, and I can tell you that C++ wasn't what I had in mind." -- Alan Kay

Zitat von Plantschkuh!

Bitte was? Magst du in Smalltalk demonstrieren, das [sic] so eine Funktionsrestklasse sein soll?

http://www.google.com/search?q=Funktionsrestklassen ist sehr aufschlussreich

Zitat von master_fluc

Weil bei guter OOP keine Funktion zweimal vorkommen wird, da sie in Klassen als Methoden gekapselt sind und eine Klasse auch nicht zweimal vorkommen sollte (was mach ich zB mit zwei Klassen namens Person? - eine Person ist eben eine Person)

Natürlich hast du im Prinzip recht - man müsste nur jede Klasse/Funktion vollständig (und damit eindeutig) benennen. Aber dass das nicht funktioniert oder höchst unbequem sein kann, zeigt dir schon, dass es in praktisch jeder prozeduralen oder objektorientierten (aber auch funktionalen) Sprache ein Konstrukt "Modul" gibt (wie auch immer das konkret geartet ist), das mehrere Funktionen/Klassen zu einer Einheit zusammenfügt. Seien es Namespaces in C++, Packages in Java oder Ada, Cluster in Eiffel, Module in Haskell usw.

In allen anderen Sprachen hilft man sich mit einem Präfix (was um einiges häßlicher ist als ein Namespace).

Plantschkuh hat schon auf die Verwendung von fremdem Code hingewiesen, was in diesem Punkt auch eine große Rolle spielt.

Zitat von master_fluc

C++ ist allerdings keine objektorientierte Sprache und man kanns auch nie komplett objektorientiert programmieren, da man sonst "Funktionsrestklassen" definieren müsste, wie zB für die mathematische Funktionssammlung...

Warum ist C++ keine oo Sprache?! Ich würde jetzt nicht behaupten, dass es eine besonders elegante oo Sprache wäre (das Gegenteil ist der Fall), aber sie weist die typischen Merkmale der OOP auf: Klassen, Vererbung, Generizität, ...

Dass man nie komplett OO programmieren kann, trifft nur auf die main() Funktion zu. Aber schau mal in Java/C#: Das public static void main(String[] args) hat auch nicht viel mit OO zu tun.

Eine Sprache, die es konsequent oo macht, ist Eiffel: Dort gibt es kein main oder so was, sondern du gibst im "Makefile" eine (beliebige) Klasse an, die der Startpunkt des Programms sein soll. Von dieser Klasse wird dann (automatisch) zu Programmstart eine Instanz erzeugt und ihr Konstruktor aufgerufen.

Zitat von hal

Ich hatte diese Situation in CG2 -- ein Model im Model Loader ist was anderes als ein Model in der Physik-Engine oder ein Model in der Graphik-Engine. Schlechtes OOP wäre gewesen, diese alle in eine Klasse zu stecken.

Eine Alternative wäre "PhysicalModel" und "GraphicalModel" gewesen. Die könnten sogar evt. von "Model" erben

Aber das Problem ist, dass es dann unbequem und/oder unintuitiv wird: Entweder es artet in einen generellen Präfix "Physical" für alle zusammengehörigen Klassen aus oder du weißt nicht mehr, welche Klassen mit welchen zusammenspielen.

Zitat von sauzachn

Warum ist C++ keine oo Sprache?! Ich würde jetzt nicht behaupten, dass es eine besonders elegante oo Sprache wäre (das Gegenteil ist der Fall), aber sie weist die typischen Merkmale der OOP auf: Klassen, Vererbung, Generizität, ...

Allerdings kein message passing, und proxies sind auch eine Illusion.
Generizität ist nichts anderes als ein Workaround für das Fehlen von object introspection (deswegen ist es in Java auch so deplaciert).

Zitat

Dass man nie komplett OO programmieren kann, trifft nur auf die main() Funktion zu. Aber schau mal in Java/C#: Das public static void main(String[] args) hat auch nicht viel mit OO zu tun.

Eine Sprache, die es konsequent oo macht, ist Eiffel: Dort gibt es kein main oder so was, sondern du gibst im "Makefile" eine (beliebige) Klasse an, die der Startpunkt des Programms sein soll. Von dieser Klasse wird dann (automatisch) zu Programmstart eine Instanz erzeugt und ihr Konstruktor aufgerufen.

Das unterscheidet sich aber nur minimal vom Java/C#-Ansatz. Diese beiden machen das höchstwahrscheinlich nur, damit sich C++-Programmierer nicht zu sehr umstellen müssen (die müssten ja noch was neues lernen, oh mein gott).

Ein echter OOD-Ansatz wird in Cocoa verfolgt, wo keine Klasse an sich ein "Einstiegspunkt" ist, sondern du hast einfach verschiedene Klassen mit verschiedenen Zuständigkeiten. Dieses Konzept funktioniert halt nicht bei Kommandozeilenprogrammen.

Zitat von sauzachn

Eine Alternative wäre "PhysicalModel" und "GraphicalModel" gewesen. Die könnten sogar evt. von "Model" erben

Diesen Ansatz hab ich eh erwähnt in meinem Post? Das ist nichts anderes als ein Workaround für ein fehlendes Sprachfeature.

Zitat

Aber das Problem ist, dass es dann unbequem und/oder unintuitiv wird: Entweder es artet in einen generellen Präfix "Physical" für alle zusammengehörigen Klassen aus oder du weißt nicht mehr, welche Klassen mit welchen zusammenspielen.

Und wo ist das Problem, wenn alles, was mit Physik zu tun hat, in seinem eigenen Physik-Namespace gekapselt ist? Genau so hab ichs gemacht.

Zitat von hal

Allerdings kein message passing, und proxies sind auch eine Illusion.
Generizität ist nichts anderes als ein Workaround für das Fehlen von object introspection (deswegen ist es in Java auch so deplaciert).

Du willst also so was wie Smalltalk haben? Ja, das geht natürlich mit C++ nicht, weil es halt doch eine statische und keine dynamische OO Sprache ist.