#include <iostream>
#include <cstdlib>

int random(int lowerbounds, int upperbounds)
{
return lowerbounds + std::rand() % (upperbounds - lowerbounds + 1);
}

using namespace std;

int main()
{
for (unsigned u = 0; u < 20; u++)
{
cout << random(1, 49) << endl;
}

return 0;

Thx Thorsten
}

Gruß Tobi

hmm wuerd mal sagen um am Programm zu sparen wo man kann
unsing namespace std lädt ja den ganzen namensraum, wenn du aber weißt das du nur einige speziele variablen bzw funktionen brauchst oder sie nicht so oft benutztsr, kannst du es auch "manuel" machen mit std::.

Wär schön, wenn das was ausmachen würde

own::cout und
std::cout verwende, weiss ich welches welches ist - aber so

using namespace own;
using namespace std;

cout // welches ?

genauso alle anderen sachen die in std definiert sind
das das programm langsamer wird stimmt nicht, es wird beim compile wegoptimiert
nur so weiss ich - das und jenes sind funktionen aus dem standard, und nicht irgendwoher

braucht nur irgendwer auf die idee kommen ein namen zu verwenden der im std auch vorkommt, evtl durch unwissenheit, und ich habe das std mit using geoeffnet, und benutzt dann seinen haeder, dann hab cih massig probleme

man kann auch

using namespace std::cout; machen, kommt auf selbe

demzufolge:
using namespace == boese

using std::cout; // no 'namespace'

Im Header sollte man niemals 'using namespace ...' benutzen, und in den Sourcedateien ist es Geschmackssache (bzw. Tipparbeit -).

Also bedeuet das, dass man in jeder datei nur einmal namespace benutzen sollte ???

Nein, aber Du solltest nach Möglichkeit "using namespace XYZ" gar nicht verwenden. Qualifizierung von Namen ist nur mehr Tipparbeit hat sonst aber keinerlei negative Auswirkungen. Das benutzen von Nichtqualifizierten Bezeichnern hingegen führt zu Doppeldeutigkeiten und Überdeckungseffekten.

Ja, aber wenn man nur einen Namensraum verwendet gibts doch keinen Überdeckungseffekt, und ich verwende nur den Namespace std....

Ja ... aber das bedeutet, er nutzt alles aus diesem Namensraum - und das ist eine ganze Menge !!
All das kann mit Namen kollidieren, die Du selbst deklarieren oder wo anders her importieren willst.
Da man sogar nachträglich alles Mögliche in den namespace importieren kann, wird's noch komplexer:

namespace std {
   void SimonsFunktion() { }
   void openGLDraw() {}
   void directXdraw() {}
}
// Hoppla, jetzt sind diese Funktionen ebenfalls im Namensraum std.

... sprich: Nicht tun.

Gruß,

Simon2.

Ja, aber wenn man nur einen Namensraum verwendet gibts doch keinen Überdeckungseffekt, und ich verwende nur den Namespace std.

std ist fürs Beschreiben Tabu! Du blendest via "using namenspace std" "std" in den globalen Namensraums ein. In diesem globalen Namensraum tummeln sich alle C-Libraries etc. Die Gefahr, daß es hierbei zu Namenskollisionen oder Überdeckungseffekten der "std" Objekte kommt ist extrem groß. Wenn Du eigenen Library Projekte oder Komponenten entwirfst, solltest Du sie in einen eigenen Namensraum ablegen, dadurch verhinderst Du Namenskollisionen. Ich weiß auch nicht warum bei vielen C++-Programmieren so eine Abneigung gegen Namensräume existiert, sachlich gibt es bei neuen Projekten dafür keinen Grund.

namespace ubernoon {
  namespace projektx {
     class Foo {
     };
  }
}

ubernoob schrieb:

Also bedeuet das, dass man in jeder datei nur einmal namespace benutzen sollte ???

Nein, aber Du solltest nach Möglichkeit "using namespace XYZ" gar nicht verwenden. Qualifizierung von Namen ist nur mehr Tipparbeit hat sonst aber keinerlei negative Auswirkungen. Das benutzen von Nichtqualifizierten Bezeichnern hingegen führt zu Doppeldeutigkeiten und Überdeckungseffekten.

Ach was. In Implementierungsdateien ist das doch alles irrelevant, denn hier sollte man überschauen können, welche Symbole verfügbar sind bzw. sich eventuell überdecken.

Und überall vollqualifizierte Bandwurmbezeichner zu verwenden ist für die Lesbarkeit auch nicht gerade das beste. Im Gegenteil: C++ ist sowieso meist schon ziemlich komplex, da muss man nicht auch noch vollqualifizierte Namen verwenden, wenn es sich auch vermeiden lässt.

Ach was. In Implementierungsdateien ist das doch alles irrelevant, denn hier sollte man überschauen können, welche Symbole verfügbar sind bzw. sich eventuell überdecken.

Es verschlechtert die Lesbarkeit des Codes, und macht damit die Softwarewartung aufwendiger. Wenn man "vector<int>" liest, denkt doch jeder an "std::vector<int>" und nicht an "john::vector<int>" oder gar "::vector<int>".

// Header Datei
namespace john {
namespace std {
  template <typename T>
  class vector {
  ...
  };
}}

// CC Datei
#include "my_header.h"

using namespace john;

int main {
  std::vector<int> v;
}

Konrad Rudolph schrieb:

Ach was. In Implementierungsdateien ist das doch alles irrelevant, denn hier sollte man überschauen können, welche Symbole verfügbar sind bzw. sich eventuell überdecken.

Es verschlechtert die Lesbarkeit des Codes, und macht damit die Softwarewartung aufwendiger. Wenn man "vector<int>" liest, denkt doch jeder an "std::vector<int>" und nicht an "john::vector<int>" oder gar "::vector<int>".

Nö. Wer es nicht schafft, kontextabhängig zu denken, hat eh verloren. Wenn ich in einem Linear-Algebra-Code mit einem nicht näher qualifizierten Vektor arbeite, dann erwarte ich natürlich, dass das ein algebraischer Vektor ist und kein 'std::vector'. Und wenn ich gerade einen Wrapper für die 3rd-Party-Bibliothek „john“ schreibe, dann erwarte ich natürlich einen 'john::vector'.