C++ (alle ISO-Standards)

• ?

  vorkommen von best. character in STL string zaehlen
  • Gast  

  3
  0
  Stimmen
  3
  Beiträge
  747
  Aufrufe

  ?

  jau, das wars. danke.
• P

  Umlautkonverter mit CStrings funktioniert nicht
  • Phisherman  

  14
  0
  Stimmen
  14
  Beiträge
  2917
  Aufrufe

  P

  Jetzt funktioniert es einwandfrei! Ich habe nun diese If-Else Kaskade entfernt und eine Switch-Case Anweisung dafür integriert. Das mit den Umlauten habe ich ganz einfach gelöst, wie ihr sehen könnt. Ich glaube, dass das Programm aber nur auf Windows System funktioniert, da die Werte der Sonderzeichen von der Codepage 850 sind. #include <iostream> #include <conio.h> using namespace std; int main() { char s1[200], s2[400]; int x=0; cout<<"Satz eingeben: "; cin.getline(s1, 200); for (int i=0; i<strlen(s1); i++) { switch (int(s1[i])) { case 132: //ae { s2[x]='a'; s2[++x]='e'; break; } case 148: //oe { s2[x]='o'; s2[++x]='e'; break; } case 129: //ue { s2[x]='u'; s2[++x]='e'; break; } case 142: //AE { s2[x]='A'; s2[++x]='E'; break; } case 153: //OE { s2[x]='O'; s2[++x]='E'; break; } case 154: //UE { s2[x]='U'; s2[++x]='E'; break; } case 225: //ss { s2[x]='s'; s2[++x]='s'; break; } default: s2[x]=s1[i]; } x++; } s2[x]='\0'; cout<<'\n'; for (int i=0; i<strlen(s2); i++) cout<<s2[i]; getch(); }
• F

  Producer-Consumer-Problem
  • fabske  

  28
  0
  Stimmen
  28
  Beiträge
  6034
  Aufrufe

  F

  hustbaer ich hab es eingesehen. Die Idee mit den iteratoren war keine gute. Ich weiß nicht warum aber mit der Zeigerlösung schaffe ich es immer nur 319 Objekte vom Erzeuger zum Verbraucher zu schauffeln, danach kommt ein Speicherzugriffsfehler. Liegt wohl an den Erklärungen dieses Threads: http://www.c-plusplus.net/forum/viewtopic-var-t-is-256167-and-highlight-is-.html Ich habe nun umgebaut auf IDs. Die hatte ich schon vorher. Es handelt sich um einen timestamp der Erstellungszeit meiner Daten die ich nun als ID benutze. Anstatt die iteratoren übergebe ich nun IDs und lass sie in den deques suchen. Puffer hab ich auch abgeschafft und direkt in Modul.cpp integriert. Falls es dich interessiert: http://codepad.org/lBGbcbNS
• ?

  Frage zur Optimierfähigkeit meines Compilers
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  870
  Aufrufe

  ?

  Dass die Warnung überhaupt ausgegeben wird, sollte ein Zeichen dafür sein, dass der Compiler gemerkt hat, welche Umstände vorliegen und demnach den Ausdruck optimieren wird. Wenn du den Assembly-Output überprüfst, dann siehst du, dass z.B. für Klasse<34> test; test.foo(100); keinerlei Code erzeugt wird. Übrigens: den Compiler, den du verwendest, ist gcc bzw. g++. Code::Blocks ist "nur" eine IDE.
• ?

  Exception Handling Buchstaben rausfiltern
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  1332
  Aufrufe

  

  du solltest dir ganz schnell abgewöhnen integers zu werfen. wird std::exception oder noch besser std::runtime_error oder davon abgeleitete klassen. und fang sie mit "catch (std::exception const& e)"
• ?

  Guter Anfang? Medienbibliothek
  • Gast  

  6
  0
  Stimmen
  6
  Beiträge
  1115
  Aufrufe

  N

  Artchi schrieb: Memberfunctions sind dann nötig, wenn man auf private oder protected Members zugreifen muß. Alles andere, was nicht auf diese Members zugreifen muß, lagere ich immer in eine freie Funktion aus. Ist eine ziemlich einfache Regel. Dem kann ich weitgehend zustimmen. Freie Funktionen erlauben prinzipiell mehr Code-Wiederverwendung. Sie können überladen werden und mit Objekten arbeiten, deren Typ bereits feststeht (z.B. Nicht-Klassen-Typen wie int , aber auch Klassen aus Bibliotheken, die nicht verändert werden sollen). Zudem wird die Kapselung erhöht, wenn nur wenige Memberfunktionen direkten Zugriff auf private Daten haben. Globale Funktionen müssen dann die Schnittstelle der Klasse nutzen. Manchmal hört man auch, dass freie Funktionen gegen die Objektorientierung sprechen (aber gerade das Kapselungsbeispiel zeigt doch was anderes; abgesehen davon halte ich es für fragwürdig, OOP der Aufrufsyntax nach zu beurteilen). Wichtig ist ausserdem, dass nicht alle Funktionen, die unmittelbar mit der Klasse verbunden sind, als Member implementiert werden müssen. Das Interface einer Klasse besteht im Allgemeinen aus ihren public -Membern plus den freien Funktionen oder Typen, welche im selben Header ausgeliefert werden.
• ?

  Typumwandlungskonstruktor
  • Gast  

  8
  0
  Stimmen
  8
  Beiträge
  1080
  Aufrufe

  N

  Soviel ich weiss, ist die Erstellung eines temporären Objekts bei A a = 1 im Gegensatz zu A a(1); implementierungsabhängig. Der Kopierkonstruktor muss nicht zwingend involviert sein. Ein Beispiel aus dem C++-Standard; hier allerdings auf ein Objekt, das bereits Typ X hat, bezogen. Ich bin mir daher nicht ganz sicher, ob implizite Konvertierungen durch entsprechende Konstruktoren auch darunter fallen, aber meines Erachtens wäre dies logisch. 12.2/2 schrieb: [Example: class X { // ... public: // ... X(int); X(const X&); ˜X(); }; X f(X); void g() { X a(1); X b = f(X(2)); a = f(a); } Here, an implementation might use a temporary in which to construct X(2) before passing it to f() using X’s copy-constructor; alternatively, X(2) might be constructed in the space used to hold the argument. Also, a temporary might be used to hold the result of f(X(2)) before copying it to b using X’s copyconstructor; alternatively, f()’s result might be constructed in b. On the other hand, the expression a=f(a) requires a temporary for either the argument a or the result of f(a) to avoid undesired aliasing of a. ]
• ?

  this Zeiger
  • Gast  

  16
  0
  Stimmen
  16
  Beiträge
  2107
  Aufrufe

  C

  Skalare rvalues sind niemals cv-qualifiziert und zwar einfach deshalb, weil es handelt sich nicht um Objekte handelt, d.h. Speicherbereiche, deren Inhalt man sich als änderbar vorstellen könnte. (3.10/9)
• M

  Init-Liste Konstruktor
  • matzehilto  

  7
  0
  Stimmen
  7
  Beiträge
  1224
  Aufrufe

  M

  Okay ich denk so einigermaßen hab ich des jetzt verstanden. Nochmals DANKE!
• N

  Vergleichsmöglichkeiten von std::tr1::function
  • Nexus  

  11
  0
  Stimmen
  11
  Beiträge
  2247
  Aufrufe

  N

  Hat noch jemand Vorschläge? Ich tendiere momentan zu geteilten Besitzverhältnissen, weil dieser Weg sehr komfortabel und sicher ist. Aber grundsätzlich lasse ich die Benutzer ungerne für Dinge zahlen, welche sie nicht brauchen...
• ?

  frage zu STL containern
  • Gast  

  8
  0
  Stimmen
  8
  Beiträge
  1113
  Aufrufe

  N

  Ich habe eben die MSVC++-Implementierung getestet: #include <cstdlib> #include <fstream> #include <deque> #include <vector> size_t allocations; size_t bytes; std::ofstream logger("log.txt"); void* operator new(size_t size) { ++allocations; bytes += size; return malloc(size); } void operator delete(void* mem) { free(mem); } template <size_t Bytes> struct byter { char arr[Bytes]; }; template <typename T> void test_container() { allocations = 0; bytes = 0; std::deque<T> c(1048576 / sizeof(T)); logger << "Groesse des Typs: " << sizeof(T) << std::endl; logger << "Anzahl Elemente: " << c.size() << std::endl; logger << "Allokationen: " << allocations << std::endl; logger << "Speicherverbrauch (Total): " << bytes << std::endl; logger << "Speicherverbrauch (Daten): " << c.size() * sizeof(T) << std::endl; logger << "Anteil Speicher fuer Daten: " << static_cast<float>(c.size() * sizeof(T)) / bytes << std::endl; logger << c[rand()%c.size()].arr << std::endl; // Wegoptimieren verunmöglichen } int main() { test_container<byter<4> >(); test_container<byter<16> >(); test_container<byter<64> >(); test_container<byter<256> >(); test_container<byter<1024> >(); } Nun zu den Resultaten. Der STL-Container std::deque ist bezüglich Speicherverbrauch nicht sehr effizient, wenn die Elementtypen klein sind. Je grösser sie werden, desto vernachlässigbarer wird der Overhead. Groesse des Typs: 4 Anzahl Elemente: 262144 Allokationen: 65560 Speicherverbrauch (Total): 1995280 Speicherverbrauch (Daten): 1048576 Anteil Speicher fuer Daten: 0.525528 Groesse des Typs: 16 Anzahl Elemente: 65536 Allokationen: 65560 Speicherverbrauch (Total): 1995280 Speicherverbrauch (Daten): 1048576 Anteil Speicher fuer Daten: 0.525528 Groesse des Typs: 64 Anzahl Elemente: 16384 Allokationen: 16405 Speicherverbrauch (Total): 1329052 Speicherverbrauch (Daten): 1048576 Anteil Speicher fuer Daten: 0.788965 Groesse des Typs: 256 Anzahl Elemente: 4096 Allokationen: 4113 Speicherverbrauch (Total): 1103936 Speicherverbrauch (Daten): 1048576 Anteil Speicher fuer Daten: 0.949852 Groesse des Typs: 1024 Anzahl Elemente: 1024 Allokationen: 1038 Speicherverbrauch (Total): 1064936 Speicherverbrauch (Daten): 1048576 Anteil Speicher fuer Daten: 0.984638 Nun zum Vergleich der std::vector (identischer Code bis auf Containerdeklaration): Groesse des Typs: 4 Anzahl Elemente: 262144 Allokationen: 2 Speicherverbrauch (Total): 1048580 Speicherverbrauch (Daten): 1048576 Anteil Speicher fuer Daten: 0.999996 Groesse des Typs: 16 Anzahl Elemente: 65536 Allokationen: 2 Speicherverbrauch (Total): 1048580 Speicherverbrauch (Daten): 1048576 Anteil Speicher fuer Daten: 0.999996 Groesse des Typs: 64 Anzahl Elemente: 16384 Allokationen: 2 Speicherverbrauch (Total): 1048580 Speicherverbrauch (Daten): 1048576 Anteil Speicher fuer Daten: 0.999996 Groesse des Typs: 256 Anzahl Elemente: 4096 Allokationen: 2 Speicherverbrauch (Total): 1048580 Speicherverbrauch (Daten): 1048576 Anteil Speicher fuer Daten: 0.999996 Groesse des Typs: 1024 Anzahl Elemente: 1024 Allokationen: 2 Speicherverbrauch (Total): 1048580 Speicherverbrauch (Daten): 1048576 Anteil Speicher fuer Daten: 0.999996 Aber dieser Vergleich ist natürlich etwas unfair, da der std::vector seinen Speicher in den wenigsten Fällen so gut ausnutzen kann. Als Konstrast dazu, nachdem ich nach der Deklaration die Anweisung c.resize(c.capacity()+1); eingefügt habe: Groesse des Typs: 4 Anzahl Elemente: 262145 Allokationen: 3 Speicherverbrauch (Total): 2621444 Speicherverbrauch (Daten): 1048580 Anteil Speicher fuer Daten: 0.400001 Groesse des Typs: 16 Anzahl Elemente: 65537 Allokationen: 3 Speicherverbrauch (Total): 2621444 Speicherverbrauch (Daten): 1048592 Anteil Speicher fuer Daten: 0.400005 Groesse des Typs: 64 Anzahl Elemente: 16385 Allokationen: 3 Speicherverbrauch (Total): 2621444 Speicherverbrauch (Daten): 1048640 Anteil Speicher fuer Daten: 0.400024 Groesse des Typs: 256 Anzahl Elemente: 4097 Allokationen: 3 Speicherverbrauch (Total): 2621444 Speicherverbrauch (Daten): 1048832 Anteil Speicher fuer Daten: 0.400097 Groesse des Typs: 1024 Anzahl Elemente: 1025 Allokationen: 3 Speicherverbrauch (Total): 2621444 Speicherverbrauch (Daten): 1049600 Anteil Speicher fuer Daten: 0.40039 Ganz so rosig sieht es also auch beim std::vector nicht immer aus, die Wahrheit liegt irgendwo dazwischen. Die std::deque benötigt zwar bei kleinen Objekten relativ viel Speicher (die Hälfte ist Overhead), aber vor allem bei grösseren bzw. sehr vielen Elementen kann sie sich trotzdem auszahlen, weil sie flexibler ist, was Reallokationen und Speicherfreigaben betrifft. Schlussendlich kommts halt immer auf den Anwendungsfall an, deshalb vorhin auch mein Vorschlag mit dem Herumexperimentieren.
• R

  suchen von \\
  • rasidrasid  

  11
  0
  Stimmen
  11
  Beiträge
  1274
  Aufrufe

  R

  Du meinst aufgrund der beschreibung ließt er an der Stelle ein wo keine Beschreibung vorhanden ist und nimmt dafür einen andern PC-Namen. Müsste ich ausprobieren Danke
• ?

  Frage zur Umwandlung von 32 Bit Zahlen in 64 Bit Zahlen im Hinblick auf Endianess
  • Gast  

  6
  0
  Stimmen
  6
  Beiträge
  1109
  Aufrufe

  

  static_cast + shift ist mit an sicherheit grenzender wahrscheinlichkeit die schnellste variante.
• ?

  Nich aufgelöstes Symbol bei Templateklasse
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  1225
  Aufrufe

  ?

  Achso ok vielen dank
• C

  Adapter für integer nach float
  • Croatiancow  

  7
  0
  Stimmen
  7
  Beiträge
  1080
  Aufrufe

  C

  Du hast vollkommen recht. Zu dem geleichen Schluss bin auch gekommen. Wozu ein Interface wenn die das schon können. Wir arbeiten definitiv die Design Patterns durch. Wir meinen das gleiche.
• R

  Probleme mit Parameterübergabe
  • r2009  

  9
  0
  Stimmen
  9
  Beiträge
  1531
  Aufrufe

  R

  Hi, ich habe eine Lösung (mit QT4 geschrieben): Die Kollegen der Delphi-Praxis haben mir ganz schnell und unkonventionell geholfen. Damit nicht nocheinmal jemand auf diese Typecastsch.. reinfällt hier ein Stück Code aus der man ersehen kann wie das Problem gelöst werden kann. wtoc und wtoci habe ich selbst geschrieben (nach einer Vorlage aus dem Internet). Das Teil soll eine DLL und aus Delphi heraus benutzt werden. Achtung: diese Funktionen sind so modifiziert, dass Pascal-Strings übergeben werden können. Pascal Strings speichern ihre Länge im ersten Byte, danach folgt der eigentliche String. Sicher gibt es hier den einen oder anderen der das besser kann. Würde mich freuen wenn das jemand optimieren könnte. Ich bin gerne bereit den Delphi Code zur Verfügung zu stellen. struct MyStruct { char TestA[101]; char TestB[101]; char TestC[101]; char TestD[101]; int NumA; int NumB; int NumC; char const* str; void wtoc(char* Dest, TCHAR* Source, int SourceSize) { for(int i = 0; i < SourceSize; ++i) Dest[i+1] = (char)Source[i]; Dest[0] = char(SourceSize); } void wtoci(TCHAR* Dest,char* Source, int SourceSize) { for(int i = 0; i < SourceSize; ++i) Dest[i] = (char)Source[i+1]; } extern "C" __declspec( dllexport ) int QtTestINI_read(struct MyStruct *strct) { int r; TCHAR Test[255]; TCHAR Sektion[101]; TCHAR Steuerwort[101]; TCHAR Pfad[101]; INT destSize=100; wtoci(Sektion,strct->TestA,sizeof(strct->TestA)); wtoci(Steuerwort,strct->TestB,sizeof(strct->TestB)); wtoci(Pfad,strct->TestD,sizeof(strct->TestD)); r = GetPrivateProfileString(Sektion,Steuerwort,TEXT("HUHU"),Test,destSize,Pfad); wtoc(strct->TestA,Test,sizeof(Test)); return(r); } extern "C" __declspec( dllexport ) int QtTestINI_write(struct MyStruct *strct) { int r; TCHAR Inhalt[101]; TCHAR Sektion[101]; TCHAR Steuerwort[101]; TCHAR Pfad[101]; wtoci(Inhalt,strct->TestC,sizeof(strct->TestC)); wtoci(Sektion,strct->TestA,sizeof(strct->TestA)); wtoci(Steuerwort,strct->TestB,sizeof(strct->TestB)); wtoci(Pfad,strct->TestD,sizeof(strct->TestD)); r = WritePrivateProfileString(Sektion, Steuerwort, Inhalt, Pfad); return(r); } Rainer
• L

  Variable im Register verändern
  • laura84  

  37
  0
  Stimmen
  37
  Beiträge
  5218
  Aufrufe

  L

  So, ich habs jetzt doch noch geschafft das Programm mit Threads aufzubauen. Ich hab einfach die cout Befehle aus der ThreadFunc rausgenommen und in den main Thread geschoben. Da hätte ich auch echt früher drauf kommen können. Das Programm ist aber deswegen trotzdem nicht schneller geworden, wie sollte es auch. Da ich ja immer 1 Sekunde warte um den neuen Wert zu addieren geht es ja nicht anders.
• K

  Wp64
  • Kóyaánasqatsi  

  3
  0
  Stimmen
  3
  Beiträge
  1928
  Aufrufe

  K

  Komisch, mein erster Treffer bei Google war die Fehlercode-Spezifikation auf der englischen Seite. Danke!
• S

  Speicherbereich erweitern
  • StefanKittel  

  3
  0
  Stimmen
  3
  Beiträge
  866
  Aufrufe

  ?

  Nimm std::vector und reserviere anfangs einfach deine Schätzung + 1 MB oder so. Selbst wenn selbst das nicht reicht, kümmert sich std::vector ohne weiteres Zutun darum.
• ?

  Umwandlung binär -&gt; Dezimal
  • Gast  

  9
  0
  Stimmen
  9
  Beiträge
  3822
  Aufrufe

  K

  Du kannst auch einfach GMP verwenden.