C++ (alle ISO-Standards)

• ?

  const bei typedefs auf Zeigern
  • Gast  

  14
  0
  Stimmen
  14
  Beiträge
  2968
  Aufrufe

  ?

  Java hat deutlich komplexere Zeiger als wir es von C und C++ gewohnt sind, und jedes Objekt schleppt Informationen für den Garbage-Collector mit. Das erlaubt die Implementation eines präzisen Garbage-Collectors im Gegensatz zu einem heuristischen. In D ist das nicht der Fall, und das ist ein echtes Problem für eine Sprache, die sich auf ihren GC verlässt. Hier wird der Stack nach Werten durchsucht, die ein Zeiger sein könnten und Deallokation unter Umständen ewig verzögert. Das Szenario ist auch auf Plattformen mit breiten Zeigern weit weniger unwahrscheinlich, als man zunächst vermuten könnte - nehmt beispielsweise void foo() { char *s = new char[1000000]; // Ich verlasse mich auf Garbage-Collection int data[100]; } void bar() { int data[100]; // Hiervon werden in der Praxis höchstens die ersten 80 benutzt while(true) { do_server_stuff(); } } int main() { foo(); bar(); } ...und da bei einem nach unten wachsenden Stack der ehemalige Speicherort von s in foo am üblicherweise unbenutzten Ende von data in bar liegt, kriege ich das Megabyte Speicher niemals wieder. Ganz zu schweigen von komplexeren Adressierungsmethoden wie XOR-verlinkten Listen. Jetzt ist Javas Garbage-Collection nicht frei von Problemen - an die genannte XOR-verlinkte Liste beispielsweise ist in Java gar nicht zu denken - aber um eine Heuristik handelt es sich dabei nicht. Sonst wäre Java wohl auch nicht so erfolgreich.
• X

  Zahlendaten aus Datei filtern und zur Verarbeitung in ein Array schreiben
  • xyllyxy  

  4
  0
  Stimmen
  4
  Beiträge
  747
  Aufrufe

  C

  Ein Container ist vector<>, deque<>, map<> etc. - das sind Klassen zur Unterbringung von Daten, die wesentlich leichter verwendet werden können als Arrays.
• H

  Probleme eines Anfängers
  • Heeiiigou  

  5
  0
  Stimmen
  5
  Beiträge
  819
  Aufrufe

  ?

  Versteh mich nicht falsch, so was mal von Hand zu machen, ist eine gute Übung, aber letztendlich kannst du das sehr viel einfacher haben: int a, b; char op; std::cin >> a >> op >> b; if(std::cin) { // Bei Eingabe von beispielsweise "3 + 4" ist jetzt a == 3, op == '+' und b == 4 } else { // Lesefehler }
• ?

  Destructor, Copy Constructor und ein paar weitere Probleme
  • Gast  

  13
  0
  Stimmen
  13
  Beiträge
  2378
  Aufrufe

  ?

  jetzt funktioniert es. danke
• ?

  Nächster Eintrag von Map
  • Gast  

  3
  0
  Stimmen
  3
  Beiträge
  644
  Aufrufe

  W

  Such mal nach Iterator... und dann noch nach C++ Reference
• ?

  boost asio async_read
  • Gast  

  7
  0
  Stimmen
  7
  Beiträge
  1617
  Aufrufe

  ?

  theta schrieb: 3. Der übergebene Buffer an async_read/async_write muss anscheinend länger existieren, also er darf nicht lokal sein, richtig? Richtig, nicht lokal in der Funktion. Entweder mit new anlegen oder aber z.B. als Member der Klasse, welche async_read aufruft. Simon Was passiert aber wenn mehrmals hintereinander async_read aufgerufen wird? Gibt es dann eine Race-Condition?
• ?

  Uint32-Wert ändert sich beim Konstruktoraufruf.
  • Gast  

  2
  0
  Stimmen
  2
  Beiträge
  604
  Aufrufe

  ?

  oh man, ich seh den fehler. sorry, bitte thread löschen. knobbers
• F

  Typ size_t beim Überschreiben von new
  • FlashBurn  

  54
  0
  Stimmen
  54
  Beiträge
  8026
  Aufrufe

  *

  FlashBurn schrieb: Naja, ich würde es vorziehen wenn man eindeutig definierte Typen hätte (z.B. uin8, int8, uint16, int16, ...) ohne das durch Testen (und ich will auch keine Header-Dateien vom Compiler, das muss Compiler unabhängig sein) herauszufinden und size_t müsste auch ein Standardtyp sein (so wie int, char, ...) und wäre dann so groß wie ein sizeof(void*). In C und C++ ist das nun einmal so, daß typedefs keine eigenen Typen definieren, aber size_t ist immer definiert, wenn man den passenden Header inkludiert. Ich sehe da nicht das große Problem, Fehlermeldungen sind nicht unbedingt so transparent wie sie sein könnten, und man hat leider keine Typunterscheidung die man zuweilen gebrauchen könnte. FlashBurn schrieb: Es geht mir auch nicht darum das size_t eine festgelegte Größe hat (naja irgendwo schon ;)), sondern dass ich size_t Compiler unabhängig nutzen oder definieren kann. Das ist eindeutig der Fall! Man muß sich daran gewöhnen, daß size_t niemals eine exakte Größe besitzt, da dieser Typ immer den ganzen möglichen Adreßraum für vom Nutzer anforderbaren Speicher besitzt. FlashBurn schrieb: Wenn ich jetzt nen int auf ner 32bit Architektur habe und der ist dort 4Byte groß und ich arbeite z.B. mit dem Überlauf und portiere den Code dann auf eine 64bit Architektur und dort ist int mit einmal 8Byte groß und schon funktioniert mein Code nicht mehr, weil die Typen halt nicht eindeutig definiert sind. Ein int ist üblicherweise ein word groß. Und ein word ist nun einmal ein maschinenabhängiges Konstrukt. Wenn man ohne OS und spezieller Laufzeitumgebung Systeme programmieren will, muß man solche Dinge nun einmal kennen. Auch auf Plattformen mit OS muß man diese Kenntnis haben, wenn man möglichst nah an der Maschine arbeiten will. Zudem wird in den Header alle Notwendigen Informationen definiert, wie groß der jeweilige Typ in Wirklichkeit ist. FlashBurn schrieb: Kritik ist meiner Meinung immer angebracht, Problem hier (C++) ist halt nur das man die Kritik nur schwer an die richtigen Stellen bekommt In diesem Fall ist keine Kritik angebracht, denn Du willst die Quadratur des Kreises haben, und das ist nicht möglich.
• N

  Template Fehler
  • Nasghat  

  14
  0
  Stimmen
  14
  Beiträge
  3051
  Aufrufe

  N

  Das Buch von Wolf habe ich schon lange weggepackt und alle Sachen dort verdrängt, ich orientiere mich mittlerweile an Stroustrups Büchern, die allerdings auch nicht immer leicht zu verstehen sind als Anfänger. Das mit der Vererbung wäre mein Schritt gewesen, wenn es absolut keine Lösung gibt, oder der Lösungsweg absolut ausserhalb meines Horizonts liegt Aber wie kann man denn mit einem Klassentemplate ein Objekt unbekannten/variablen Typs erstellen, oder geht das einfach nicht? Vielen Dank für die Hilfe, MkG Nas
• ?

  std::tr1::array in Initialisierungliste initialisieren
  • Gast  

  12
  0
  Stimmen
  12
  Beiträge
  2680
  Aufrufe

  3

  krümelkacker schrieb: #include <iostream> #include <ostream> #include <utility> #include <array> template<class Iter> inline void assign_helper(Iter) {} template<class Iter, class U, class...More> inline void assign_helper(Iter it, U&& u, More&&...more) { *it = std::forward<U>(u); ++it; assign_helper(it,std::forward<More>(more)...); } template<class T> std::array<T,0> make_array() { return std::array<T,0>(); } template<class T, class U, class...Args> std::array<T,1+sizeof...(Args)> make_array(U&& u, Args&&...args) { std::array<T,1+sizeof...(Args)> result; assign_helper(&result[0],std::forward<U>(u),std::forward<Args>(args)...); return result; } int main() { using namespace std; auto a = make_array<long>(1,2,3,5,8,13,21,34); int s = a.size(); cout << "---" << endl; for (int i=0; i<s; ++i) { cout << a[i] << '\n'; } cout << "---" << endl; } Sehr elegante Lösung
• ?

  kettenmodifikation
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  701
  Aufrufe

  

  Hi zusammen, das entspricht dem Named Parameter Idiom
• *

  NULL und 0
  • *Rewind*  

  25
  0
  Stimmen
  25
  Beiträge
  4085
  Aufrufe

  A

  FutterBeidieTische schrieb: Gibt es eigentlich irgendwas, was gegen NULL spricht, außer dass es ein int ist, wenn man den neuen Standard nicht hat? 1. Die Verwendung von NULL gibt keine zusätzliche Typsicherheit, d.h. man kann z.B. nach wie vor einer Funktion versehentlich NULL übergeben, wenn an der Stelle eigentlich ein int o.ä. gefordert war. In Zeiten von IDEs mit Calltips passiert sowas allerdings ohnehin kaum mehr. 2. Ist länger als 0. Dass man NULL jedoch mit einer einzigen Ersetzaktion im gesamten Projekt zu nullptr ändern kann (und notfalls auch wieder zurück) ist allerdings ein absolutes K.O.-Argument, das für NULL spricht.
• ?

  Anzahl der Dezimalstellen bei std::ofstream
  • Gast  

  2
  0
  Stimmen
  2
  Beiträge
  793
  Aufrufe

  E

  std::cout << std::setfill('0') << std::setw(2);
• ?

  Kurze Frage zu Pointern
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  683
  Aufrufe

  ?

  Danke für die Antwort dann werde ich mir das hier mal anschauen: http://msdn.microsoft.com/en-us/library/aa366525(v=vs.85).aspx
• ?

  Frage zu Delete
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  739
  Aufrufe

  A

  Ist zwar in Ordnung falls das nur zur Übung dient, aber normalerweise sollte in solchen Situationen ptr_vector verwenden.
• J

  Höchsten Wert aus nichtprimitiven Vektor picken
  • Jay1980  

  5
  0
  Stimmen
  5
  Beiträge
  1416
  Aufrufe

  E

  CStoll schrieb: Wenn schon jemand es geschafft hat, die <algorithm> zu finden und zu nutzen, empfehle ich ihm doch nicht eine selbstgebaute Schleife dafür) Stimmt, sorry. CStoll schrieb: wobei - in C++0x könnte man die Vergleichsfunktion auch als Lambda-Expression zusammenbauen std::vector<FloatInside>::iterator = std::max_element(MeinVec.begin(),MeinVec.end(),[](const FloatInside& Left, const FloatInside& Right){return Left.InnerFloat() < Right.InnerFloat()}); CStoll schrieb: ist das nicht vorgeschrieben *BuchHervorhol* Mist, hast recht. Ich dachte, dass der RandomAccessIter immer einen Konvertierungsoperator zu und von einem rohen Zeiger bietet.
• X

  C++, C++0x und C#
  • xBlackKnightx  

  29
  0
  Stimmen
  29
  Beiträge
  4757
  Aufrufe

  K

  xBlackKnightx schrieb: krümelkacker schrieb: "Inheriting constructors" braucht man nicht wirklich. Das kann man per variadische Templates + Perfect Forwarding emulieren. Beispiel? class base { public: explicit basis(int); basis(int,int); basis(double,double,double); ... }; class derived : public base { public: template<class...Args> explicit derived(Args&&...args) : base(std::forward<Args>(args)...) {} };
• ?

  Priority Queue
  • Gast  

  9
  0
  Stimmen
  9
  Beiträge
  1701
  Aufrufe

  C

  MaxC++ schrieb: node* priority_queue::pop() { /* Insert your code here. */ node* temp = _root; _root = _root->get_next(); delete temp; return _root; } Das löscht das bisherige Kopf-Element und gibt das neue Kopf-Element zurück. Du solltest da vermutlich temp zurückgeben anstatt es zu vernichten. size_t priority_queue::size() const { /* Insert your code here. */ *_root = priority_queue().size(); _root->get_next() == NULL; return 0; } Ich hab' echt keine Ahnung, was dieser Code macht. Die erste Zeile sieht nach einem rekursiven Aufruf der Methode aus, die zweite Zeile kappt die Verbindung zwischen dem Kopf und der restlichen Kette (was dir zumindest ein Speicherleck beschert). Wenn du die Größe/Länge deiner Queue zurückgeben willst, hast du zwei Möglichkeiten: Entweder du merkst dir die Größe und aktualisierst sie bei jedem insert() und pop() oder du läufst einmal durch die Struktur und zählst die Elemente. //Variante 1: void priority_queue::insert(node* node_) { //dein Code ++_size; } node* priority_queue::pop() { node* tmp = _root; _root = _root->get_next(); --_size; return tmp; } size_t priority_queue::size() const { return _size; } //Variante 2 size_t priority_queue::size() const { node* tmp = root; size_t sz=0; for( ; tmp!=NULL ; tmp=tmp->ge_next(),++sz ) ; return sz; }
• X

  Kopiermethode virtualisieren?
  • xBlackKnightx  

  14
  0
  Stimmen
  14
  Beiträge
  2064
  Aufrufe

  

  So extrem finde ich das jetzt nicht. OK, wenn man möchte dass ein von std::logic_error oder std::runtime_error abgeleiteter Fehler fliegt, dann ist es nicht gut. Ansonsten halte ich std::bad_cast für ausreichend.
• ?

  Frage zur Arraydeklaration
  • Gast  

  8
  0
  Stimmen
  8
  Beiträge
  1015
  Aufrufe

  ?

  Ich danke euch beiden