C++ (alle ISO-Standards)

• B

  [ERLEDIGT]Wie kann ich ein Verzeichnis durchsuchen? (z.B. nach Dateien mit einer bestimmten Endung)
  • BrennenderVogel  

  4
  0
  Stimmen
  4
  Beiträge
  543
  Aufrufe

  A

  Nö, geht in dem Forum nicht. Du kannst aber dein erstes Posting editieren und den Titel ändern und da [Erledigt] reinschreiben. Aber macht hier niemand.
• ?

  String in char funktioniert nicht
  • Gast  

  7
  0
  Stimmen
  7
  Beiträge
  710
  Aufrufe

  A

  Fr3yr schrieb: ...ich habe Microsoft Visual C++ 6.0 Author Edition... Man sollte nicht mit einem uralten Compiler arbeiten, wie von anderen geschrieben gibt es mehrere Alternativen (wenn du vorher mit MSVC gearbeitet hast würde ich dir empfehlen die MSVC 2008 Expressversion zu verwenden)... Argh, ich sehe grade das du vielleicht MFC einsetzt. Dann wird dir die Expressedition nicht reichen und du müsstest etwa 100-200 Euro für die Standardedition berappen (wobei es ab und zu Aktionen von MS gibt wo man die Standardedition kostenlos bekommen kann, z.B. mit der Auflage sich 5 Lernviedoclips anzuschauen und die Codes im Anschluß zu notieren [So kam ich z.B. an meine private MSVC 2005 Standard Version - und ich brauche wegen Plugins mindestens die Standard]). cu André
• E

  Wert aendert sich ohne Zugriff?
  • etlam  

  5
  0
  Stimmen
  5
  Beiträge
  403
  Aufrufe

  E

  Vielen Dank, jetzt habe ich das Problem behoben. Irgenwie kam der falsche Wert im zweiten Schleifendurchgang, obwohl mit dem Wert kaum etwas gemacht wird in der Schleife. Ich hatte deshalb auch nicht daran gedacht, weil der Fehler aus einer Funktion kam, die eigentlich keinen solchen Fehler macht, allerdings hatte ich diese umbenannt und eine andere Funktion so genannt... Vielen dank, etlam
• ?

  Variable in Funktion überall bekannt
  • Gast  

  10
  0
  Stimmen
  10
  Beiträge
  540
  Aufrufe

  J

  Wenn überall bedeutet in einem .cpp File, dann nimm einen unbenamten namespace, also: namespace { int blub; }; in mehreren .cpp Files, dann benutze das Singleton Entwurfsmuster, wenn Dir (wie mir auch) globale Variablen nicht gefallen
• ?

  Frage zu Tutorial von www.c-worker.ch (TCP/UDP Socket Programmierung)
  • Gast  

  7
  0
  Stimmen
  7
  Beiträge
  450
  Aufrufe

  S

  Hier kannst Du übrigens die Socket Errors nachschlagen: http://msdn2.microsoft.com/en-us/library/ms740668(VS.85).aspx Hier ist die Doku zu recvfrom(..) auf MSDN: http://msdn2.microsoft.com/en-us/library/ms740120.aspx Da steht, dass wenn WSAEINVAL (10022) auftritt vermutlich das socket nicht geunden ist. -> Beim empfangen musst Du dem socket mitteilen auf welchem interface (ip addr) und auf welchem port Du Daten empfangen möchtest. Das geschieht mit der Funktion bind. Q. Warum giengs dann nach dem 1. mal senden??? A. Weil da das socket implizit gebunden wird. Ich würde als Test mal den Sender und Empfänger Code trennen. Das hilft das ganze zu verstehen. Ich korrigiere die anderen Fehler absichtlich nicht, da sie nichts mit deinem eigentlichen Problem zu tun haben (ev. sind sie auch nur hier im Forum Code...). Grüsse Simon
• M

  Hex to Text bzw string
  • MasterTobi  

  2
  0
  Stimmen
  2
  Beiträge
  547
  Aufrufe

  T

  Zum Zurückwandeln benötigst du einen istringstream: istringstream istr(text); istringstream eos; char c; // evtl. int while(istr != eos) { istr >> hex >> showbase; istr >> c; cout << c; // evtl. static_cast<char>(c); } [ungetestet]
• A

  Windows-Forms-Steuerelement
  • Auryn  

  2
  0
  Stimmen
  2
  Beiträge
  328
  Aufrufe

  ?

  Hallo Du solltest wirklich konkrete Fragen stellen oder dein Vorhaben ins Projekteforum stellen und Geld bieten damit jemand deine Hausaufgaben macht. Desweiteren hört es sich so an, als ob du .net verwenden willst und dafür gibt es hier auch ein extra Forum. chrische
• ?

  sprintf mit %s bringt programm zum absturz
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  599
  Aufrufe

  D

  buffer ist ja ein std::stringstream, kein std::string. EDIT: Dies bzog sich auf Scorchers Müll
• ?

  Wofür istringstream und ostringstream?
  • Gast  

  2
  0
  Stimmen
  2
  Beiträge
  419
  Aufrufe

  Q

  für funktionen wie to_string und from_string z.b.
• ?

  Kann der Compiler das optimieren?
  • Gast  

  32
  0
  Stimmen
  32
  Beiträge
  1610
  Aufrufe

  A

  Konrad Rudolph schrieb: Hmm, nein, ehrlich gesagt gerade nicht. Kann sein, dass ich auf dem Schlauch stehe aber was hindert einen daran, einen Proxy zurückzugeben, der operator= überlädt und erst zum Zeitpunkt der Zuweisung das Auslesen übernimmt? Gar nicht ungeschickt soweit. Zufällig hatte ich gerade Lust dazu: #include <windows.h> #include <vector> #include <iterator> class File { private: HANDLE hFile; DWORD pos; public: template <typename T> class FilePart { friend class File; private: HANDLE file; DWORD pos; DWORD cnt; FilePart (HANDLE hFile, DWORD dwPos, DWORD dwCnt) : file (hFile), pos (dwPos), cnt (dwCnt) {} public: class const_iterator; friend class const_iterator; class const_iterator { friend class FilePart; private: const FilePart* fp; DWORD pos; const_iterator (const FilePart* filepart, DWORD dwPos) : fp (filepart), pos (dwPos) {} public: typedef int difference_type; typedef T value_type; typedef T* pointer; typedef T& reference; typedef std::input_iterator_tag iterator_category; const_iterator& operator ++ (void) { pos += sizeof (T); } const_iterator& operator -- (void) { pos -= sizeof (T); } const_iterator& operator ++ (int) { const_iterator rv (*this); pos += sizeof (T); return rv; } const_iterator& operator -- (int) { const_iterator rv (*this); pos -= sizeof (T); return rv; } bool operator == (const_iterator& rhs) { return (fp == rhs.fp) && (pos == rhs.pos); } bool operator != (const_iterator& rhs) { return (fp != rhs.fp) || (pos != rhs.pos); } T operator * (void) const { T rv; DWORD nobr; OVERLAPPED ov; ZeroMemory (&ov, sizeof (ov)); ov.Offset = pos; ReadFile (fp->file, &rv, sizeof (T), &nobr, &ov); return rv; } // T* operator -> (void) const wird aus naheliegenden Gründen // nicht implementiert }; const_iterator begin (void) const { return const_iterator (this, pos); } const_iterator end (void) const { return const_iterator (this, pos + cnt * sizeof (T)); } }; // ... File (const char* lpFilename, DWORD dwAccess = GENERIC_READ, DWORD dwShareMode = FILE_SHARE_READ, DWORD dwCreationDisposition = OPEN_ALWAYS) : pos (0) { hFile = CreateFile (lpFilename, dwAccess, dwShareMode, NULL, dwCreationDisposition, 0, NULL); } template <typename T> FilePart <T> read (DWORD dwCnt) { union u { T t; }; // schlägt fehl, wenn T nicht trivial ist DWORD opos = pos; // evtl. Bereichsüberprüfungen pos += dwCnt * sizeof (T); return FilePart <T> (hFile, opos, dwCnt); } }; int main (void) { File file ("myFile.bin"); std::vector <int> v; File::FilePart <int> fp = file.read <int> (42); v.insert (v.begin (), fp.begin (), fp.end ()); return 0; } Wirklich wunderschön, das gebe ich zu. Nur: #include <windows.h> #include <vector> int main (void) { std::vector <int> v; HANDLE hFile; DWORD nobr; v.resize (42); hFile = CreateFile (lpFilename, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_ALWAYS, 0, NULL); ReadFile (hFile, &*(v.begin ()), sizeof (T) * 42, &nobr, NULL); } Irgendwie ist das hier (bzw. eine etwas mehr gekapselte, exceptionsichere Version hiervon) dann doch zu bevorzugen, meinst du nicht? Schon weil ReadFile 41-mal weniger ausgeführt werden muß Und auch sonst ist das ein bißchen wartungsfreundlicher. Konrad Rudolph schrieb: Das Leben [eines Programmierers] besteht aus faulen Kompromissen. ... und großen Momenten
• T

  std::list mit Templateklasse
  • Thundernail  

  6
  0
  Stimmen
  6
  Beiträge
  504
  Aufrufe

  T

  Danke für die Erklärung.
• ?

  Statischer Methoden-Zeiger -&gt; Zuweisung
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  463
  Aufrufe

  S

  Letztlich kannst Du vermutlich alles auf void* und wieder woanders hin zurück casten ... aber ob das dann (immer) funtkioniert wie gewünscht, steht auf einem anderen Blatt. Da der C++-Standard nichts über EXC-Register, VTables und ASM sagt, zumindestens nicht standardkonform ... und damit hängst Du auf jeden Fall in der Plattform, wenn nicht gar am Compiler. Gruß, Simon2.
• L

  Problem mit 'sort' Algorithmus
  • LukasBanana  

  6
  0
  Stimmen
  6
  Beiträge
  455
  Aufrufe

  ?

  nimm doch gleich ein std::set
• N

  Valgrind
  • NoPanic2007  

  5
  0
  Stimmen
  5
  Beiträge
  1508
  Aufrufe

  N

  Ich habe das gleiche Programm mal auf zwei unterschiedlichen Rechnern laufen lassen: mit dem Aufruf: valgrind --leak-check=full 1.) ==18965== Memcheck, a memory error detector. ==18965== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==18965== Using LibVEX rev 1575, a library for dynamic binary translation. ==18965== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==18965== Using valgrind-3.1.1, a dynamic binary instrumentation framework. ==18965== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==18965== For more details, rerun with: -v ==18965== ==18982== ==18982== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 2) ==18982== malloc/free: in use at exit: 0 bytes in 0 blocks. ==18982== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==18982== For counts of detected errors, rerun with: -v ==18982== All heap blocks were freed -- no leaks are possible. ==18984== ==18984== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 2) ==18984== malloc/free: in use at exit: 0 bytes in 0 blocks. ==18984== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==18984== For counts of detected errors, rerun with: -v ==18984== All heap blocks were freed -- no leaks are possible. ==18986== ==18986== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 2) ==18986== malloc/free: in use at exit: 0 bytes in 0 blocks. ==18986== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==18986== For counts of detected errors, rerun with: -v ==18986== All heap blocks were freed -- no leaks are possible. *** glibc detected *** double free or corruption (!prev): 0x0000000000728b60 *** [0]0:Return code = 0, signaled with Aborted ==18965== ==18965== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 5 from 2) ==18965== malloc/free: in use at exit: 0 bytes in 0 blocks. ==18965== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==18965== For counts of detected errors, rerun with: -v ==18965== All heap blocks were freed -- no leaks are possible. 2.) ==12182== Memcheck, a memory error detector. ==12182== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==12182== Using LibVEX rev 1732, a library for dynamic binary translation. ==12182== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==12182== Using valgrind-3.2.3, a dynamic binary instrumentation framework. ==12182== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==12182== For more details, rerun with: -v ==12182== ==12183== ==12183== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==12183== malloc/free: in use at exit: 107,481 bytes in 719 blocks. ==12183== malloc/free: 2,268 allocs, 1,549 frees, 226,623 bytes allocated. ==12183== For counts of detected errors, rerun with: -v ==12183== searching for pointers to 719 not-freed blocks. ==12183== checked 491,096 bytes. ==12183== ==12183== 6,595 (1,045 direct, 5,550 indirect) bytes in 5 blocks are definitely lost in loss record 6 of 11 ==12183== at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12183== by 0x43A402: (within /bin/tcsh) ==12183== by 0x440B49: (within /bin/tcsh) ==12183== by 0x4072E5: (within /bin/tcsh) ==12183== by 0x408D22: (within /bin/tcsh) ==12183== by 0x405953: (within /bin/tcsh) ==12183== by 0x52C1B53: (below main) (in /lib64/libc-2.6.1.so) ==12183== ==12183== LEAK SUMMARY: ==12183== definitely lost: 1,045 bytes in 5 blocks. ==12183== indirectly lost: 5,550 bytes in 112 blocks. ==12183== possibly lost: 0 bytes in 0 blocks. ==12183== still reachable: 100,886 bytes in 602 blocks. ==12183== suppressed: 0 bytes in 0 blocks. ==12183== Reachable blocks (those to which a pointer was found) are not shown. ==12183== To see them, rerun with: --leak-check=full --show-reachable=yes ==12190== ==12190== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==12190== malloc/free: in use at exit: 108,280 bytes in 722 blocks. ==12190== malloc/free: 2,321 allocs, 1,599 frees, 236,928 bytes allocated. ==12190== For counts of detected errors, rerun with: -v ==12190== searching for pointers to 722 not-freed blocks. ==12190== checked 491,112 bytes. ==12190== ==12190== 6,559 (1,045 direct, 5,514 indirect) bytes in 5 blocks are definitely lost in loss record 6 of 11 ==12190== at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12190== by 0x43A402: (within /bin/tcsh) ==12190== by 0x440B49: (within /bin/tcsh) ==12190== by 0x4072E5: (within /bin/tcsh) ==12190== by 0x408D22: (within /bin/tcsh) ==12190== by 0x405953: (within /bin/tcsh) ==12190== by 0x52C1B53: (below main) (in /lib64/libc-2.6.1.so) ==12190== ==12190== LEAK SUMMARY: ==12190== definitely lost: 1,045 bytes in 5 blocks. ==12190== indirectly lost: 5,514 bytes in 112 blocks. ==12190== possibly lost: 0 bytes in 0 blocks. ==12190== still reachable: 101,721 bytes in 605 blocks. ==12190== suppressed: 0 bytes in 0 blocks. ==12190== Reachable blocks (those to which a pointer was found) are not shown. ==12190== To see them, rerun with: --leak-check=full --show-reachable=yes ==12197== ==12197== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==12197== malloc/free: in use at exit: 107,349 bytes in 719 blocks. ==12197== malloc/free: 2,306 allocs, 1,587 frees, 238,853 bytes allocated. ==12197== For counts of detected errors, rerun with: -v ==12197== searching for pointers to 719 not-freed blocks. ==12197== checked 489,616 bytes. ==12197== ==12197== 6,315 (1,045 direct, 5,270 indirect) bytes in 5 blocks are definitely lost in loss record 6 of 11 ==12197== at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12197== by 0x43A402: (within /bin/tcsh) ==12197== by 0x440B49: (within /bin/tcsh) ==12197== by 0x4072E5: (within /bin/tcsh) ==12197== by 0x408D22: (within /bin/tcsh) ==12197== by 0x405953: (within /bin/tcsh) ==12197== by 0x52C1B53: (below main) (in /lib64/libc-2.6.1.so) ==12197== ==12197== LEAK SUMMARY: ==12197== definitely lost: 1,045 bytes in 5 blocks. ==12197== indirectly lost: 5,270 bytes in 112 blocks. ==12197== possibly lost: 0 bytes in 0 blocks. ==12197== still reachable: 101,034 bytes in 602 blocks. ==12197== suppressed: 0 bytes in 0 blocks. ==12197== Reachable blocks (those to which a pointer was found) are not shown. ==12197== To see them, rerun with: --leak-check=full --show-reachable=yes ==12202== ==12202== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==12202== malloc/free: in use at exit: 108,733 bytes in 743 blocks. ==12202== malloc/free: 2,338 allocs, 1,595 frees, 243,089 bytes allocated. ==12202== For counts of detected errors, rerun with: -v ==12202== searching for pointers to 743 not-freed blocks. ==12202== checked 490,360 bytes. ==12202== ==12202== 6,199 (1,045 direct, 5,154 indirect) bytes in 5 blocks are definitely lost in loss record 6 of 11 ==12202== at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12202== by 0x43A402: (within /bin/tcsh) ==12202== by 0x440B49: (within /bin/tcsh) ==12202== by 0x4072E5: (within /bin/tcsh) ==12202== by 0x408D22: (within /bin/tcsh) ==12202== by 0x405953: (within /bin/tcsh) ==12202== by 0x52C1B53: (below main) (in /lib64/libc-2.6.1.so) ==12202== ==12202== LEAK SUMMARY: ==12202== definitely lost: 1,045 bytes in 5 blocks. ==12202== indirectly lost: 5,154 bytes in 112 blocks. ==12202== possibly lost: 0 bytes in 0 blocks. ==12202== still reachable: 102,534 bytes in 626 blocks. ==12202== suppressed: 0 bytes in 0 blocks. ==12202== Reachable blocks (those to which a pointer was found) are not shown. ==12202== To see them, rerun with: --leak-check=full --show-reachable=yes ==12201== ==12201== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==12201== malloc/free: in use at exit: 107,794 bytes in 720 blocks. ==12201== malloc/free: 2,353 allocs, 1,633 frees, 244,636 bytes allocated. ==12201== For counts of detected errors, rerun with: -v ==12201== searching for pointers to 720 not-freed blocks. ==12201== checked 489,384 bytes. ==12201== ==12201== 6,199 (1,045 direct, 5,154 indirect) bytes in 5 blocks are definitely lost in loss record 6 of 11 ==12201== at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12201== by 0x43A402: (within /bin/tcsh) ==12201== by 0x440B49: (within /bin/tcsh) ==12201== by 0x4072E5: (within /bin/tcsh) ==12201== by 0x408D22: (within /bin/tcsh) ==12201== by 0x405953: (within /bin/tcsh) ==12201== by 0x52C1B53: (below main) (in /lib64/libc-2.6.1.so) ==12201== ==12201== LEAK SUMMARY: ==12201== definitely lost: 1,045 bytes in 5 blocks. ==12201== indirectly lost: 5,154 bytes in 112 blocks. ==12201== possibly lost: 0 bytes in 0 blocks. ==12201== still reachable: 101,595 bytes in 603 blocks. ==12201== suppressed: 0 bytes in 0 blocks. ==12201== Reachable blocks (those to which a pointer was found) are not shown. ==12201== To see them, rerun with: --leak-check=full --show-reachable=yes ==12205== ==12205== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==12205== malloc/free: in use at exit: 109,749 bytes in 747 blocks. ==12205== malloc/free: 2,395 allocs, 1,648 frees, 249,754 bytes allocated. ==12205== For counts of detected errors, rerun with: -v ==12205== searching for pointers to 747 not-freed blocks. ==12205== checked 490,600 bytes. ==12205== ==12205== 6,155 (1,045 direct, 5,110 indirect) bytes in 5 blocks are definitely lost in loss record 6 of 11 ==12205== at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12205== by 0x43A402: (within /bin/tcsh) ==12205== by 0x440B49: (within /bin/tcsh) ==12205== by 0x4072E5: (within /bin/tcsh) ==12205== by 0x408D22: (within /bin/tcsh) ==12205== by 0x405953: (within /bin/tcsh) ==12205== by 0x52C1B53: (below main) (in /lib64/libc-2.6.1.so) ==12205== ==12205== LEAK SUMMARY: ==12205== definitely lost: 1,045 bytes in 5 blocks. ==12205== indirectly lost: 5,110 bytes in 112 blocks. ==12205== possibly lost: 0 bytes in 0 blocks. ==12205== still reachable: 103,594 bytes in 630 blocks. ==12205== suppressed: 0 bytes in 0 blocks. ==12205== Reachable blocks (those to which a pointer was found) are not shown. ==12205== To see them, rerun with: --leak-check=full --show-reachable=yes ==12204== ==12204== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==12204== malloc/free: in use at exit: 108,878 bytes in 724 blocks. ==12204== malloc/free: 2,410 allocs, 1,686 frees, 251,253 bytes allocated. ==12204== For counts of detected errors, rerun with: -v ==12204== searching for pointers to 724 not-freed blocks. ==12204== checked 489,688 bytes. ==12204== ==12204== 6,155 (1,045 direct, 5,110 indirect) bytes in 5 blocks are definitely lost in loss record 6 of 11 ==12204== at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12204== by 0x43A402: (within /bin/tcsh) ==12204== by 0x440B49: (within /bin/tcsh) ==12204== by 0x4072E5: (within /bin/tcsh) ==12204== by 0x408D22: (within /bin/tcsh) ==12204== by 0x405953: (within /bin/tcsh) ==12204== by 0x52C1B53: (below main) (in /lib64/libc-2.6.1.so) ==12204== ==12204== LEAK SUMMARY: ==12204== definitely lost: 1,045 bytes in 5 blocks. ==12204== indirectly lost: 5,110 bytes in 112 blocks. ==12204== possibly lost: 0 bytes in 0 blocks. ==12204== still reachable: 102,723 bytes in 607 blocks. ==12204== suppressed: 0 bytes in 0 blocks. ==12204== Reachable blocks (those to which a pointer was found) are not shown. ==12204== To see them, rerun with: --leak-check=full --show-reachable=yes ==12208== ==12208== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==12208== malloc/free: in use at exit: 111,081 bytes in 751 blocks. ==12208== malloc/free: 2,452 allocs, 1,701 frees, 256,587 bytes allocated. ==12208== For counts of detected errors, rerun with: -v ==12208== searching for pointers to 751 not-freed blocks. ==12208== checked 491,112 bytes. ==12208== ==12208== 6,163 (1,045 direct, 5,118 indirect) bytes in 5 blocks are definitely lost in loss record 6 of 11 ==12208== at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12208== by 0x43A402: (within /bin/tcsh) ==12208== by 0x440B49: (within /bin/tcsh) ==12208== by 0x4072E5: (within /bin/tcsh) ==12208== by 0x408D22: (within /bin/tcsh) ==12208== by 0x405953: (within /bin/tcsh) ==12208== by 0x52C1B53: (below main) (in /lib64/libc-2.6.1.so) ==12208== ==12208== LEAK SUMMARY: ==12208== definitely lost: 1,045 bytes in 5 blocks. ==12208== indirectly lost: 5,118 bytes in 112 blocks. ==12208== possibly lost: 0 bytes in 0 blocks. ==12208== still reachable: 104,918 bytes in 634 blocks. ==12208== suppressed: 0 bytes in 0 blocks. ==12208== Reachable blocks (those to which a pointer was found) are not shown. ==12208== To see them, rerun with: --leak-check=full --show-reachable=yes ==12207== ==12207== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==12207== malloc/free: in use at exit: 110,459 bytes in 729 blocks. ==12207== malloc/free: 2,468 allocs, 1,739 frees, 258,483 bytes allocated. ==12207== For counts of detected errors, rerun with: -v ==12207== searching for pointers to 729 not-freed blocks. ==12207== checked 490,448 bytes. ==12207== ==12207== 6,163 (1,045 direct, 5,118 indirect) bytes in 5 blocks are definitely lost in loss record 6 of 11 ==12207== at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12207== by 0x43A402: (within /bin/tcsh) ==12207== by 0x440B49: (within /bin/tcsh) ==12207== by 0x4072E5: (within /bin/tcsh) ==12207== by 0x408D22: (within /bin/tcsh) ==12207== by 0x405953: (within /bin/tcsh) ==12207== by 0x52C1B53: (below main) (in /lib64/libc-2.6.1.so) ==12207== ==12207== LEAK SUMMARY: ==12207== definitely lost: 1,045 bytes in 5 blocks. ==12207== indirectly lost: 5,118 bytes in 112 blocks. ==12207== possibly lost: 0 bytes in 0 blocks. ==12207== still reachable: 104,296 bytes in 612 blocks. ==12207== suppressed: 0 bytes in 0 blocks. ==12207== Reachable blocks (those to which a pointer was found) are not shown. ==12207== To see them, rerun with: --leak-check=full --show-reachable=yes *** glibc detected *** ../torrey: double free or corruption (!prev): 0x000000000100fbc0 *** ======= Backtrace: ========= /lib/../lib64/libc.so.6[0x2ab867a7f21d] /lib/../lib64/libc.so.6(cfree+0x76)[0x2ab867a80f76] ../torrey[0x41523e] ../torrey(__gxx_personality_v0+0x373)[0x411bf3] /lib/../lib64/libc.so.6(__libc_start_main+0xf4)[0x2ab867a2eb54] ../torrey(__gxx_personality_v0+0x129)[0x4119a9] ======= Memory map: ======== 00400000-00deb000 r-xp 00000000 08:03 3630324 /home/jochen/code/TORREY/torrey 00feb000-00fed000 r-xp 009eb000 08:03 3630324 /home/jochen/code/TORREY/torrey 00fed000-00ff8000 rwxp 009ed000 08:03 3630324 /home/jochen/code/TORREY/torrey 00ff8000-0113b000 rwxp 00ff8000 00:00 0 [heap] 2ab865992000-2ab8659ae000 r-xp 00000000 08:02 2567073 /lib64/ld-2.6.1.so 2ab8659ae000-2ab8659b0000 rwxp 2ab8659ae000 00:00 0 2ab865bad000-2ab865baf000 rwxp 0001b000 08:02 2567073 /lib64/ld-2.6.1.so 2ab865baf000-2ab865cdf000 r-xp 00000000 08:02 2333306 /usr/lib64/libX11.so.6.2.0 2ab865cdf000-2ab865edf000 ---p 00130000 08:02 2333306 /usr/lib64/libX11.so.6.2.0 2ab865edf000-2ab865ee5000 rwxp 00130000 08:02 2333306 /usr/lib64/libX11.so.6.2.0 2ab865ee5000-2ab865ef9000 r-xp 00000000 08:02 2560915 /lib64/libnsl-2.6.1.so 2ab865ef9000-2ab8660f8000 ---p 00014000 08:02 2560915 /lib64/libnsl-2.6.1.so 2ab8660f8000-2ab8660fa000 rwxp 00013000 08:02 2560915 /lib64/libnsl-2.6.1.so 2ab8660fa000-2ab8660fd000 rwxp 2ab8660fa000 00:00 0 2ab8660fd000-2ab866105000 r-xp 00000000 08:02 2560934 /lib64/librt-2.6.1.so 2ab866105000-2ab866304000 ---p 00008000 08:02 2560934 /lib64/librt-2.6.1.so 2ab866304000-2ab866306000 rwxp 00007000 08:02 2560934 /lib64/librt-2.6.1.so 2ab866306000-2ab86695f000 r-xp 00000000 08:02 410420 /opt/intel/mkl/9.1.023/lib/em64t/libmkl_lapack.so 2ab86695f000-2ab866a5e000 ---p 00659000 08:02 410420 /opt/intel/mkl/9.1.023/lib/em64t/libmkl_lapack.so 2ab866a5e000-2ab866a69000 rwxp 00658000 08:02 410420 /opt/intel/mkl/9.1.023/lib/em64t/libmkl_lapack.so 2ab866a69000-2ab866ac2000 r-xp 00000000 08:02 410412 /opt/intel/mkl/9.1.023/lib/em64t/libguide.so 2ab866ac2000-2ab866bc1000 ---p 00059000 08:02 410412 /opt/intel/mkl/9.1.023/lib/em64t/libguide.so 2ab866bc1000-2ab866bc5000 rwxp 00058000 08:02 410412 /opt/intel/mkl/9.1.023/lib/em64t/libguide.so 2ab866bc5000-2ab866bcc000 rwxp 2ab866bc5000 00:00 0 2ab866bcc000-2ab866be1000 r-xp 00000000 08:02 2560930 /lib64/libpthread-2.6.1.so 2ab866be1000-2ab866de1000 ---p 00015000 08:02 2560930 /lib64/libpthread-2.6.1.so 2ab866de1000-2ab866de3000 rwxp 00015000 08:02 2560930 /lib64/libpthread-2.6.1.so 2ab866de3000-2ab866de7000 rwxp 2ab866de3000 00:00 0 2ab866de7000-2ab866de9000 r-xp 00000000 08:02 2560910 /lib64/libdl-2.6.1.so 2ab866de9000-2ab866fe9000 ---p 00002000 08:02 2560910 /lib64/libdl-2.6.1.so 2ab866fe9000-2ab866feb000 rwxp 00002000 08:02 2560910 /lib64/libdl-2.6.1.so 2ab866feb000-2ab866ff8000 r-xp 00000000 08:02 2560985 /lib64/libgcc_s.so.1 2ab866ff8000-2ab8671f7000 ---p 0000d000 08:02 2560985 /lib64/libgcc_s.so.1 2ab8671f7000-2ab8671f9000 rwxp 0000c000 08:02 2560985 /lib64/libgcc_s.so.1 2ab8671f9000-2ab8671fa000 rwxp 2ab8671f9000 00:00 0 2ab8671fa000-2ab8672b4000 r-xp 00000000 08:02 2333126 /usr/lib64/libgfortran.so.2.0.0 2ab8672b4000-2ab8674b3000 ---p 000ba000 08:02 2333126 /usr/lib64/libgfortran.so.2.0.0 2ab8674b3000-2ab8674b5000 rwxp 000b9000 08:02 2333126 /usr/lib64/libgfortran.so.2.0.0 2ab8674b5000-2ab867507000 r-xp 00000000 08:02 2560912 /lib64/libm-2.6.1.so 2ab867507000-2ab867706000 ---p 00052000 08:02 2560912 /lib64/libm-2.6.1.so 2ab867706000-2ab867708000 rwxp 00051000 08:02 2560912 /lib64/libm-2.6.1.so 2ab867708000-2ab8677f4000 r-xp 00000000 08:02 2333496 /usr/lib64/libstdc++.so.6.0.9 2ab8677f4000-2ab8679f4000 ---p 000ec000 08:02 2333496 /usr/lib64/libstdc++.so.6.0.9 2ab8679f4000-2ab8679fa000 r-xp 000ec000 08:02 2333496 /usr/lib64/libstdc++.so.6.0.9 2ab8679fa000-2ab8679fd000 rwxp 000f2000 08:02 2333496 /usr/lib64/libstdc++.so.6.0.9 2ab8679fd000-2ab867a11000 rwxp 2ab8679fd000 00:00 0 2ab867a11000-2ab867b4d000 r-xp 00000000 08:02 2560904 /lib64/libc-2.6.1.so 2ab867b4d000-2ab867d4c000 ---p 0013c000 08:02 2560904 /lib64/libc-2.6.1.so 2ab867d4c000-2ab867d4f000 r-xp 0013b000 08:02 2560904 /lib64/libc-2.6.1.so 2ab867d4f000-2ab867d51000 rwxp 0013e000 08:02 2560904 /lib64/libc-2.6.1.so 2ab867d51000-2ab867d57000 rwxp 2ab867d51000 00:00 0 2ab867d7a000-2ab867d7b000 r-xp 00000000 08:02 2332796 /usr/lib64/libxcb-xlib.so.0.0.0 2ab867d7b000-2ab867f7a000 ---p 00001000 08:02 2332796 /usr/lib64/libxcb-xlib.so.0.0.0 2ab867f7a000-2ab867f7c000 rwxp 00000000 08:02 2332796 /usr/lib64/libxcb-xlib.so.0.0.0 2ab867f7c000-2ab867f97000 r-xp 00000000 08:02 2332806 /usr/lib64/libxcb.so.1.0.0 2ab867f97000-2ab868196000 ---p 0001b000 08:02 2332806 /usr/lib64/libxcb.so.1.0.0 2ab868196000-2ab868198000 rwxp 0001a000 08:02 2332806 /usr/lib64/libxcb.so.1.0.0 2ab868198000-2ab868199000 rwxp 2ab868198000 00:00 0 2ab868199000-2ab86819b000 r-xp 00000000 08:02 2332648 /usr/lib64/libXau.so.6.0.0 2ab86819b000-2ab86839a000 ---p 00002000 08:02 2332648 /usr/lib64/libXau.so.6.0.0 2ab86839a000-2ab86839c000 rwxp 00001000 08:02 2332648 /usr/lib64/libXau.so.6.0.0 2ab86839c000-2ab86839e000 rwxp 2ab86839c000 00:00 0 2ab86c000000-2ab86c021000 rwxp 2ab86c000000 00:00 0 2ab86c021000-2ab870000000 ---p 2ab86c021000 00:00 0 7fff45102000-7fff45118000 rwxp 7fff45102000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vdso] [0]0:Return code = 0, signaled with Aborted ==12182== ==12182== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1) ==12182== malloc/free: in use at exit: 109,118 bytes in 708 blocks. ==12182== malloc/free: 2,476 allocs, 1,768 frees, 258,631 bytes allocated. ==12182== For counts of detected errors, rerun with: -v ==12182== searching for pointers to 708 not-freed blocks. ==12182== checked 488,000 bytes. ==12182== ==12182== 5,773 (1,020 direct, 4,753 indirect) bytes in 4 blocks are definitely lost in loss record 5 of 10 ==12182== at 0x4C21D06: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==12182== by 0x43A402: (within /bin/tcsh) ==12182== by 0x440B49: (within /bin/tcsh) ==12182== by 0x4072E5: (within /bin/tcsh) ==12182== by 0x408D22: (within /bin/tcsh) ==12182== by 0x405953: (within /bin/tcsh) ==12182== by 0x52C1B53: (below main) (in /lib64/libc-2.6.1.so) ==12182== ==12182== LEAK SUMMARY: ==12182== definitely lost: 1,020 bytes in 4 blocks. ==12182== indirectly lost: 4,753 bytes in 103 blocks. ==12182== possibly lost: 0 bytes in 0 blocks. ==12182== still reachable: 103,345 bytes in 601 blocks. ==12182== suppressed: 0 bytes in 0 blocks. ==12182== Reachable blocks (those to which a pointer was found) are not shown. ==12182== To see them, rerun with: --leak-check=full --show-reachable=yes
• ?

  Zeiger und Konstruktoren bei dynamischen Arrays
  • Gast  

  2
  0
  Stimmen
  2
  Beiträge
  373
  Aufrufe

  Q

  hallo, new kann damit nicht umgehen. besser, du verwendest std::vector , da arbeitest du auch automatisch dynamisch und ersparst dir lästige arbeit mit rohem speicher. std::vector<Auto> fuhrpark (100, Auto(42)); //zugriff wie mit arrays: fuhrpark[23].drive_away(); //PS: die alternative wäre wohl, mit algorithmen wie fill_n oder generate_n zu arbeiten. Auto* fuhrpark = new Auto[100]; fill_n (fuhrpark, 100, Auto(42)); es gibt noch eine hässlichere version, die willst du aber ganz sicher nicht verwenden.
• A

  Ist Static innerhalb von Methoden in C++ noch angebracht?
  • Ankou  

  7
  0
  Stimmen
  7
  Beiträge
  500
  Aufrufe

  

  Wenn die Klasse multi-threaded verwendet werden soll ist beides problematisch. Wenn nicht sind IMO statische Member besser, da sie "sichtbarer" sind.
• T

  design-frage &quot;ergebniss-cache&quot;
  • Treb  

  6
  0
  Stimmen
  6
  Beiträge
  474
  Aufrufe

  

  Ich würde das Puffern der FFT Daten entweder im "sound pre prozessor" machen oder im "stream stück". Es in der FFT Klasse zu machen halte ich für ziemlich unsauber.
• ?

  private static variablen einer klasse außerhalb der klasse initialisieren?
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  2375
  Aufrufe

  Q

  nun ja, ich würde nicht sagen, dass das "von außerhalb" ist. class Foo { void Bar (); }; void Foo::Bar () { } die definition von Foo::Bar liegt jetzt auch außerhalb der klasse. verletzung der kapselung? wohl kaum.
• ?

  zufälligen char aus ansisatz erstellen
  • Gast  

  3
  0
  Stimmen
  3
  Beiträge
  462
  Aufrufe

  ?

  das ist ja gut. also: danke nochmal
• ?

  Daten in Datei Schreiben
  • Gast  

  8
  0
  Stimmen
  8
  Beiträge
  757
  Aufrufe

  ?

  wite -> write