C++ (alle ISO-Standards)

• ?

  Kartendeck intialisieren
  • Gast  

  3
  0
  Stimmen
  3
  Beiträge
  927
  Aufrufe

  T

  maumau schrieb: Nur wie mache ich das am besten? Ich muss dazu ja einmal über meine enums iterieren und gleichzeitig über meinen Vektor. Kann man das irgendwie eleganter lösen als durch zich ineinander verschachtelte Schleifen? Je nach Geschmack sind das entweder eine oder zwei Schleifen. Wo ist das Problem? for (int c = 0; c < color_count; ++c) { for (int t = 0; t < type_count; ++t) { cards.push_back(Card( static_cast<type>(t), static_cast<color>(c))); } } std::random_shuffle(cards.begin(), cards.end()); Warum ist Card eigentlich nicht kopierbar und wozu der Destruktor?
• ?

  std::get&lt;i&gt; bei std::tuple
  • Gast  

  11
  0
  Stimmen
  11
  Beiträge
  2037
  Aufrufe

  N

  otze, du kannst std::array auch ohne C++11 Initializer List Support direkt füllen: std::array<unsigned char, 3> color = {r, g, b}; Eventuell könnte man mit gut unterstütztem C++11 sogar direkt colors.push_back({r, g, b}); schreiben. Bin mir hier allerdings nicht sicher, da std::array ein Aggregat ist und keine Konstruktoren hat. Jedenfalls ist mit leichtem C++11 auch das möglich: struct rgb { explicit rgb(unsigned char r, unsigned char g, unsigned char b); std::array<unsigned char, 3> values; }; std::vector<rgb> colors; colors.emplace_back(r, g, b);
• L

  Einige Anfängerfragen zu Klassen
  • Likemike  

  24
  0
  Stimmen
  24
  Beiträge
  2790
  Aufrufe

  L

  Erst mal vielen Dank Decimad. Ich bin mir nicht ganz sicher, ob du deine Antwort schon geschrieben hattest, bevor ich meine 2. geschrieben habe, oder ob es die Antwort auf meine 2. Frage war... ich übergebe das Array an die Funktion, und zwar bisher so: apfelzaehler(ar); Ist daran schon etwas falsch? Wie gesagt, in der Funktion wird auch alles richtig berechnet, nur das ändert eben nichts an dem array in der Main - wie gesagt, ich muss die Werte wohl zurückgeben, damit sie im Ursprungsarray überschrieben werden - nur weiß ich leider nicht wie. Edit: Fehler im Code verbessert...
• S

  Karten-Spiel Mau-Mau
  • Sireextrem  

  5
  0
  Stimmen
  5
  Beiträge
  1964
  Aufrufe

  ?

  Tut mir leid hatte einen anderen Kartenspiel-Quellcode mit einer anderen Lösung in Erinnerung. Dein Quelltext "mischt" ja die 2 bis 6, ignoriert sie dann ja. Also okay. "C++" ist der Button unten rechts direkt neben "Code"
• S

  Wie deklariere ich einen Pointer auf String??
  • silent_max  

  25
  0
  Stimmen
  25
  Beiträge
  2454
  Aufrufe

  S

  char * s = "Joe"; Wirklich? Keiner?
• ?

  Klassen-Enum mit Konstanten?
  • Gast  

  8
  0
  Stimmen
  8
  Beiträge
  1112
  Aufrufe

  C

  SeppJ schrieb: C++11: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf Eine bessere Wahl ist: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf Dieses Dokument ist tatsächlich identisch mit dem Standard mit Ausnahme einiger redaktioneller Korrekturen.
• C

  Vererben von Konstruktoren (C++11)
  • class_1974  

  10
  0
  Stimmen
  10
  Beiträge
  2854
  Aufrufe

  C

  Vielen Dank für deine Geduld mit mir hab's kapiert cooky451 schrieb: Sollte gehen, aber das kann man halt auch so erreichen, da braucht man erstmal kein C++11: class Vater { public: Vater(int ival = 0) { cout << "Vater : " << ival << endl; } Vater(string s) { cout << "Vater : " << s << endl; } };
• K

  Leerzeichen entfernen
  • khati  

  9
  0
  Stimmen
  9
  Beiträge
  932
  Aufrufe

  ?

  khati schrieb: danke. ich werde mir anschauen ich dachte dass j nur hochgezehlt wird wenn eine leerzeichen dabei ist und auch in 2. String gespeichert j wird hochgezählt wenn du kein Leerzeichen hast. Bei Stringende wir die for-Schleife aber nicht mehr ausgeführt. D.H die '\0' wird nicht kopiert. Die musst nach der for-Schleife noch setzten.
• ?

  Formatierte Textdatei
  • Gast  

  2
  0
  Stimmen
  2
  Beiträge
  370
  Aufrufe

  

  forM schrieb: Mit den Funktionen aus iomanip kann man ja glaub ich nur die Ausgabe auf der Konsole verändern oder? Nein, C++ kennt keine Konsolen. Alles ist ein Strom aus Zeichen. Daher ist auch völlig egal, wo dieser landet. Die Manipulatoren aus iomanip sind schon das richtige. Je nach System tut es aber vielleicht auch ein guter alter Tabulator '\t'.
• ?

  Übersicht STL Container
  • Gast  

  10
  0
  Stimmen
  10
  Beiträge
  999
  Aufrufe

  ?

  krümelkacker schrieb: So richtig doll überlegen muss ich da eigentlich nicht. Es gibt ja nur zwei Klassen von Containern: Sequenz-Container. Das sind vector , list , deque . Assoziative Container. Das sind set , map , multimap , und ab C++11 noch die unodered_ -Varianten. Bei Sequenz-Containern lässt sich die Ordnung der Elemente vom Benutzer festlegen und ändern. Diesen Containern ist das egal, in welcher Ordnung die Elemente drin stehen. Die Ordnung bleibt so erhalten, wie der Benutzer die Elemente hinzufügt. Bei assoziativen Containern geben die Container die Ordnung vor. Die Reihenfolge der Elemente ist entweder nach dem Schlüssel sortiert ( set , map , multimap ) oder eben pseudo-zufällig ( unordered_ * ab C++11) in Abhängigkeit einer Hash-Funktion. Alles andere ( stack , queue , priority_queue ) sind nur Adapter, die unter der Motorhaube einen der schon genannten Sequenz-Containern verwenden (jedenfalls per Default). Sie haben eine relativ minimale Schnittstelle und falls sie genau das anbieten, was man braucht, sollte man sie wohl auch benutzen. Braucht man einen Sequenz-Container mit einer mächtigeren Schnittstelle, steht man vor der Wahl zwischen vector , deque und list . Nach Stroustrup, sollte man im Zweifel einfach vector verwenden. deque wird interessant, wenn man auch am Anfang Elemente hinzufügen oder löschen können will und list<T> wird interessant, wenn der Aufwand, ein T-Objekt von einem Speicherort zu einem anderen zu bewegen, sehr groß ist und man gar kein "random access" benötigt. Braucht man einen assoziativen Container hat man die Wahl zwischen den "normalen" und den "ungeordneten". Wenn man auf die sortierte Reihenfolge verzichten kann und man schon auf eine gute Hashfunktion zurückgreifen kann, würde ich die unordered_ *-Container empfehlen. Sonst einfach die "normalen". Ob es dann ein set , eine map oder eine multimap wird, hängt ja davon ab, was man damit machen will. set heißt so, weil es sich an eine mathematische Menge anlehnt. Bei map ist das ähnlich, es speichert eindeutige Zuordnungen wohingegen eine multimap einen "Schlüssel" mit mehreren "Werten" verknüpfen kann. Hmm ... der Text ist doch länger geworden, als eigentlich gedacht ... Ist wohl doch nicht ganz so trivial. Ob lang oder nicht, wurde aber als Info aufgenommen. Danke
• C

  Prozess schützen
  • Centurius  

  15
  0
  Stimmen
  15
  Beiträge
  1284
  Aufrufe

  S

  unbekannt schrieb: aber wie oben schon erwähnt kann du dein programm mit diversen mechanismen vor debuggern schützen so des es sich garnicht erst starten lässt ergo auch kein rausnehmen von inhalten Nein. Du kannst es nur erschweren. Alles was du machen kannst ist, es dem Angreifer so schwer wie möglich zu machen an die Daten zu kommen und sie so zu manipulieren wie er will. Aber verhindern ist unmöglich.
• D

  Klasse / Konstruktor / doppelten Aufruf verhindern.
  • djhaefd  

  19
  0
  Stimmen
  19
  Beiträge
  2269
  Aufrufe

  D

  Super, vielen Dank
• F

  Recursive Decent Parser: Rekursionsanker?
  • freakC++  

  20
  0
  Stimmen
  20
  Beiträge
  2677
  Aufrufe

  ?

  freakC++ schrieb: Was sagst Du denn zu dieser Grammatik, deren Linksrekursion entfernt wurde? Durch die Epsilon-Produktion kann diese versteckt auftreten, sodass Epsilon-Produktionen entfernt werden müssen. A -> BAbb | a B -> epsilon Das ist ein konstruiertes Beispiel, indem die Rekursion eben nicht entfernt wurde. Du hast gesagt: Durch die Eliminierung werden neue Linksrekursionen eingeführt. Das ist aber nicht wahr. Durch das Schema oben wurde ein neues Terminal C und eine Epsilonproduktion C->eps eingeführt. Das kann aber nicht zu einer neuen versteckten Rekursion führen, da C vorher noch nicht in der Grammatik aufgetaucht ist. Dieses Beispiel aus der PDF besagt viel eher, dass man vorsichtig sein sollte, wenn die Grammatik vorher bereits epsilons enthält. Denn dann könnten versteckte Linksrekursionen enthalten sein, die das Eliminierungsschema nicht auf rein mechanische Weise auffinden und beseitigen würde. Würde auch sagen: Zeige uns Deine Grammatik. Am besten die Ausgangsform, also eine die durchaus noch Mehrdeutig sein kann. Dann können wir das eindeutig machen, Rekursionen entfernen und Faktorisieren.
• C

  Mehrere Dateien mit Code::Blocks
  • climits  

  4
  0
  Stimmen
  4
  Beiträge
  2934
  Aufrufe

  C

  So nach viel Rumprobieren, hab ich statt "Empty File" als neues Projekt jetzt einfach "Console Application" gewählt, und es hat endlich funktioniert. Wenn noch jemand weiß, warum dass einen Unterschied macht, wäre toll, ansonsten bin ich um diese Uhrzeit aber wunschlos glücklich
• T

  GCC und (nicht-variadische) Template-Rekursion
  • TdZ  

  3
  0
  Stimmen
  3
  Beiträge
  678
  Aufrufe

  T

  decay kannte ich noch gar nicht, dank Dir für den Tip! Allerdings ist das nicht ganz das, was ich suche. Ich habe mittlerweile den Fehler gefunden: Die Reihenfolge der Qualifier war nicht ganz richtig, dann braucht man gar keine Rekursion. So funktioniert es jetzt erstmal: template<class VM, typename T> static String fullName() { typedef typename boost::decay<typename boost::remove_all_extents<typename boost::remove_const<typename boost::remove_pointer<typename boost::remove_reference<T>::type>::type>::type>::type>::type DecomposedType; String name = TypeInfo::name<VM, DecomposedType >(); bool isPointer = boost::is_pointer<typename boost::remove_reference<T>::type>(); bool isConst = boost::is_const<typename boost::remove_pointer<typename boost::remove_reference<T>::type>::type>(); bool isReference = boost::is_reference<T>(); if(!TypeInfo::isValid<VM,DecomposedType>()) return ""; return TypeInfo::combined<VM>(name, isConst, isReference, isPointer); } Das VM und der Funktionsname waren irrelevant, daher bin ich nicht weiter drauf eingegangen. Das hier ist jetzt die Funktion direkt aus dem Quellcode. Mega umständlich und funktioniert nur für recht primitive Typen. Egal, das reicht mir erstmal. VM ist ein Template Parameter für die Virtual Machine, das gehört nämlich zu einem Binding-Utility für meine Script-Engine. Danke nochmal, dass Du mich auf die richtige Fährte gebracht hast
• K

  Ob Strings anagramm sind? Meine Problemmstellung: zeichen aus string entfernen
  • khati  

  16
  0
  Stimmen
  16
  Beiträge
  5075
  Aufrufe

  K

  Danke vielmals
• ?

  Objekt übergeben
  • Gast  

  9
  0
  Stimmen
  9
  Beiträge
  939
  Aufrufe

  C

  A bekommt über den Konstruktor jetzt die Werte, die B im Konstruktor braucht, sodass B automatisch beim Anlegen von A erzeugt wird. Nein. Oder sagen wir mal, nur bedingt. Wenn B nur einen Parameter im Konstruktor erwartet (und der nicht als explicit definiert ist), dann geht das. Man modelliert damit eine Art "ist ein", wie z.B. bei std::string: void foo(std::string s); int main() { foo("Hallo"); } Das ist aber eher eine Art Sonderregel, allgemein schreibt man void foo(std::string s); int main() { foo(std::string("Hallo")); } Und genau so sieht das dann auch bei dir aus: std::vector<A> v; while(blubb) { v.push_back(A(B(/* Parameter? */))); } Oder, wenn jedes a mit dem gleichen B erzeugt werden soll, wahlweise auch std::vector<A> v; B b(/* Parameter? */); while(blubb) { v.push_back(A(b)); }
• M

  Stream verstecken
  • mike4  

  20
  0
  Stimmen
  20
  Beiträge
  3193
  Aufrufe

  ?

  DocShoe schrieb: Unter Windows kannst du die Datei nicht verstecken. Ein Benutzer mit ausreichenden Rechten und passenden Tools kann zu jedem Prozess auflisten, welche Ressourcen der Prozess benutzt, und dazu gehören nun auch einmal Dateien. Wenn der Dateiname (inkl. Pfad) frei wählbar ist kannst du ihn in dem Windows Ordnergewühl "verstecken". Mit genügend vielen kryptischen Unterverzeichnissen unter "c:\Dokumente und Einstellungen" kann man selbst hart gesottene Schnüffler abschrecken :D. Für unversierte Benutzer reicht es wahrscheinlich schon, das "Hidden" Flag der Datei zu setzen und die Windows Explorer Optionen so einstellen, dass er keine versteckte Dateien mehr anzeigt. Das Verstecken einer Datei funktioniert mit der SetFileAttributes und dem Flag FILE_ATTRIBUTE_HIDDEN . Du bist wohl einer von denen die Adminrechte für ihr Programm brauchen weil sie alles im Installationsordner spoeichern?
• ?

  Compiletime Schnittstellen
  • Gast  

  16
  0
  Stimmen
  16
  Beiträge
  1526
  Aufrufe

  K

  Decimad schrieb: Irgendwie erscheint mir das geistig "quer" (weil die Interface-Garantie nicht teil der Implementierung ist), da verstehe ich etwas noch nicht. Muss sie das explizit angeben? Ich finde dieses Compile-Time-Duck-Typing gar nicht schlecht. Zumindest muss es "auto-Konzepte" geben. Keiner will an jeden Typen extra dranschreiben müssen, dass er kopierbar, zuweisbar, default-konstruirbar ist u.s.w. Das verrät einem die Schnittstelle ja schon. "auto concepts" sind dann solche, die sich automatisch auf alles übertragen, was "strukturell" passt. Im vorherigen Posting hätte ich z.b. mindestens bei bei Swappable und Assignable ein "auto" davor setzen müssen, weil ich nicht für jeden Typen extra per concept_map sagen will, dass man ein swap aufrufen kann oder eine Zuweisung durchführen kann. Das ergibt sich ja schon aus der Schnittstelle. Man unterscheidet da zwischen Bedingungen, die rein "strukturell" sind und semantischen Bedingungen. Wenn ich ein swap für ein T aufrufen kann, dann reicht mir das. Das ist der strukturelle Teil. Der semantische Teil eines solchen Constraints würde dann sagen "wenn man dieses swap ausführt, wird auch tatsächlich der Inhalt/die Werte der beiden Objekte getauscht". Das lässt sich nicht in Code aufschreiben und deswegen gab es auch die Möglichkeit Konzepte so zu definieren, dass man doch explizit sagen muss, welche Typen alle dieses Konzept modellieren. Ein Haken bei der ganzen Concepts-Geschichte war, dass man viel zu viel Code schreiben musste. Ich will kein "modular typechecking" haben, wenn ich dafür viel viel mehr Code schreiben muss. Ach, eins, was Concepts ermöglichen sollte, was wir aber noch nicht genannt haben, war "concept-based overloading", also: template<ForwardIterator Iter> void advance(Iter & iter, Iter::difference_type step) { assert(step>=0); while (step>0) { ++iter; --step; } } template<BidirectionalIterator Iter> void advance(Iter & iter, Iter::difference_type step) { while (step>0) { ++iter; --step; } while (step<0) { --iter; ++step; } } template<RandomAccessIterator Iter> void advance(Iter & iter, Iter::difference_type step) { iter += step; } Das macht man im Moment per "tag dispatching", aber dieses concept-based overloading wär natürlich ein netter Ersatz dafür. Also alles in allem ... die Ziele von Concepts waren hoch gesteckt. Kurzfassung: Ein Typsystem für Typen.
• ?

  make_shared Problem/Frage
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  863
  Aufrufe

  K

  secondsun schrieb: auto loginRequest = make_shared<_ns2__login>(); loginRequest->ns2__LoginRequest = make_shared<_ns2__LoginRequest>(); Diese versuche ich ebenfalls mit make_shared zu instanziieren. Leider kommt aber die Fehlermeldung: "Fehler 1 error C2440: '=': 'std::tr1::shared_ptr<_Ty>' kann nicht in 'BasicService::_ns2__LoginRequest *' konvertiert werden" Ich begreife natürlich den Fehler aber werden solche Objekte nicht mehr mit make_shared erstellt oder wie geht man hier vor? Immerhin bekomme ich ja einen shared_ptr zurück. Wie geht man vor? Man überlegt sich vorher ein Design und versucht es dann umzusetzen. Es hat aber keiner so richtig einen Überblick über das, was du machen willst. Es sieht nur auf den ersten Blick so aus, als ob du shared_ptr missbrauchen würdest. Ich habe den Eindruck, als ob dir das Konzept der Besitzverhältnisse in C++ nicht ganz vertraut ist und dass du shared_ptr einfach nur als "poor man's garbage collection" einsetzen willst. Das "shared" in shared_ptr bezieht sich nämlich auf genau das. Mehrere shared_ptr-Instanzen "teilen sich den Besitz" eines anderen dynamisch allozierten Objekts. Du solltest wirklich anfangen, in solchen Besitzverhältnissen zu denken. Mit "Besitz" meint man u.a. die Verantwortung zur Verwaltung und Freigabe dessen, was einer oder mehrere zusammen besitzen. Werden diese Besitzverhältnisse beim Design berücksichtigt, wird auch klar, wann du wo welche Art von Zeiger (wenn überhaupt) verwenden solltest. T* --> Ein roher Zeiger besitzt nichts. Er kann für "kennt"-Beziehungen verwendet werden. unique_ptr<T> --> Ein unique_ptr ist alleiniger Besitzer einer Resource und gibt sie wieder frei, wenn der unique_ptr zerstört wird. Das ist praktisch für "besteht-aus"-Beziehungen, bei denen du polymorphes Verhalten haben willst oder bei denen das, worauf er zeigt, optional ist oder verzögert erstellt wird. shared_ptr<T> --> Ein shared_ptr kann sich den Besitz mit anderen shared_ptrs teilen. Es gibt sicherlich Situationen, wo so etwas sinnvoll ist. Aber typischerweise kann man einen einzigen "Besitzer" identifizieren und einfach unique_ptr nehmen Und oft macht es auch viel mehr Sinn, gar keinen Zeiger zu verwenden. Du kannst Objekte ja auch direkt als Subobjekte in andere einbetten oder im automatischen Speicher anlegen. Überleg dir also genau, ob du ein make_shared oder new überhaupt brauchst. Für delete und delete[] gibt es in modernem C++ Code aber wirklich so gut wie keinen Platz mehr. Dafür gibt's die Container aus der Standardbibliothek und eben diese "Schlau-Zeiger". Übrigens gehören Bezeichner mit "Doppelunterstrichen" zu denen, die reserviert sind. Du darfst sie also nicht verwenden. Gleiches gilt für Bezeichner, die mit einem Unterstrich anfangen und dann mit einem Großbuchstaben weiter gehen, wie z.B. "_Ty". Die Microsoftentwickler haben den Template-Parameter von shared_ptr nicht "_Ty" genannt, weil sie ihn schön finden, sondern weil der C++ Standard den "Normalos" verbietet, solche Namen zu verwenden; denn sonst könnten sie ja einfach #define _Ty "fucked up" vor die Includes packen und nix geht mehr. Namen mit Doppelunterstrichen gehören auch dazu.