C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Probleme mit vector.push_back Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ (German) View previous topic :: View next topic   Author Message Michael Gebhart Guest Posted: Sun Dec 05, 2004 11:24 am    Post subject: Probleme mit vector.push_back Hi zusammen, ich hab ein Programm, welches zum einen mit mehreren Threads und zum anderen viel mit vectors arbeitet. Für Threads werden pthreads genommen (ich weiß, ist kein ISO, darum geht es hier ja auch nicht ) und die vectors aus der STL. Meine Frage ist nun: Unter welchen Bedingungen kann ein push_back bei einem Vector zu einem Absturz führen? Ich hab die Anwendung auf mehreren Rechnern laufen (ohne neu compilen) und die Anwendung zeigt merkwürdiges Verhalten. Ab und zu stürzt sie einfach bei einem push_back ab und ich weiß nicht wieso. Ich hab die Anwendung auch schon statisch gelinkt, zeigt auch keine Wirkung. Ich habe sogar eine ganze map, mit Index Integer und Inhalten Vectors. Kann das Probleme machen? Würde mich freuen, wenn jemand einen Tipp hat, wann so etwas Probleme verursachen kann. Gruß Michael -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Thomas Maeder Guest Posted: Sun Dec 05, 2004 6:52 pm    Post subject: Re: Probleme mit vector.push_back Michael Gebhart <mail (AT) miketech (DOT) net> writes: Quote: ich hab ein Programm, welches zum einen mit mehreren Threads und zum anderen viel mit vectors arbeitet. Für Threads werden pthreads genommen (ich weiß, ist kein ISO, darum geht es hier ja auch nicht ) und die vectors aus der STL. Meine Frage ist nun: Unter welchen Bedingungen kann ein push_back bei einem Vector zu einem Absturz führen? Ich hab die Anwendung auf mehreren Rechnern laufen (ohne neu compilen) und die Anwendung zeigt merkwürdiges Verhalten. Ab und zu stürzt sie einfach bei einem push_back ab und ich weiß nicht wieso. Sieht so aus, als ob die dynamische Speicherverwaltung nicht thread-sicher ist. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Michael Gebhart Guest Posted: Sun Dec 05, 2004 11:47 pm    Post subject: Re: Probleme mit vector.push_back Hi, ich hab alles mit Mutexes abgesichert. Da dürfte eigentlich nichts mehr passieren. Gruß Michael -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Daniel Albuschat Guest Posted: Mon Dec 06, 2004 7:23 am    Post subject: Re: Probleme mit vector.push_back Michael Gebhart wrote: Quote: Meine Frage ist nun: Unter welchen Bedingungen kann ein push_back bei einem Vector zu einem Absturz führen? Wenn der Vektor, auf den das push_back aufgerufen wird, nichtmehr existiert oder nie existierte, oder zu wenig Speicher vorhanden ist. Ich glaube nichtmals, dass das was mit den Threads zu tun hat. Leider kann man dann aber afaik valgrind oder aehnliches nicht so gut mit Threads benutzen... Achso, und um welche Art "Absturz" handelt es sich denn? MfG, Daniel Albuschat -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top kanze@gabi-soft.fr Guest Posted: Mon Dec 06, 2004 12:53 pm    Post subject: Re: Probleme mit vector.push_back Michael Gebhart wrote: Quote: ich hab alles mit Mutexes abgesichert. Da dürfte eigentlich nichts mehr passieren. Was meinst du genau mit « alles mit Mutexes abgesichert »? Normalerweise, wenn ich in Thread 1 mit vector a arbeite, und in Thread 2 mit vector b, absichere ich nichts. Obwohl beide vector mit demselben Allocator-Objekt arbeiten. Die Verantwortung dieser Sicherung gehört zum vector, und nicht zu mir. Gewöhnlicherweise braucht man besondere Optionen bei der Kompilierung, damit std::vector Thread-sicher ist, und diese Verantwortung übernimmt. Welchen, hängt vom Compiler un von der Bibliothek ab. -- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Torsten Robitzki Guest Posted: Mon Dec 06, 2004 4:39 pm    Post subject: Re: Probleme mit vector.push_back Michael Gebhart wrote: Quote: Hi, ich hab alles mit Mutexes abgesichert. Da dürfte eigentlich nichts mehr passieren. Alles klingt nicht gut. Wenn Deine Runtime Library thread save ist, ist das zu viel, ist sie es nicht, ist es mit hoher Wahrscheinlichkeit immer noch zu wenig. Und Du synchronisierst wirklich _jeden_ direkten und indirekten / potenziellen Aufruf der Allocator Funktionen? mfg Torsten -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Stephan Menzel Guest Posted: Mon Dec 06, 2004 5:03 pm    Post subject: Re: Probleme mit vector.push_back Michael Gebhart wrote: Quote: Hi, ich hab alles mit Mutexes abgesichert. Da dürfte eigentlich nichts mehr passieren. Ist die Iteration mit gelockt? Ich hatte mal das gleiche Problem. Unerklaerliche Abstuerze an solchen stellen obwohl ich den vector mit Mutexen geschuetzt hatte. Aber eben nur waehrend des push_back. Ich haette ihn aber komplett schuetzen muessen waehrend der gesamten Zeit in der die Iteratoren gueltig sein muessen, was dann auch des Pudels Kern war. Also mein Tip: Sieh zu dass das Locking um die ganze Schleife rum ist. Stephan -- Freedom isn't lost in one big step when the storm-troopers show up at your door. It is lost in little pieces, each so small that they tend to be ignored. Richard B. Johnson -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Sven Lukas Guest Posted: Mon Dec 06, 2004 7:28 pm    Post subject: Re: Probleme mit vector.push_back Du solltest auch mal testen, ob Du bessere Ergebnisse erzielst, wenn Du auf jede nur mögliche Compileroptimierung verzichtest. Falls das Ergebnis positiv ist, mußt Du Dir Gedanken darüber machen, wo ein "volatile" in Deinem Programmcode Sinn macht. Quote: Hi, ich hab alles mit Mutexes abgesichert. Da dürfte eigentlich nichts mehr passieren. Gruß Michael -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Torsten Robitzki Guest Posted: Tue Dec 07, 2004 2:54 pm    Post subject: Re: Probleme mit vector.push_back Sven Lukas wrote: Quote: Du solltest auch mal testen, ob Du bessere Ergebnisse erzielst, wenn Du auf jede nur mögliche Compileroptimierung verzichtest. Falls das Ergebnis positiv ist, mußt Du Dir Gedanken darüber machen, wo ein "volatile" in Deinem Programmcode Sinn macht. Das volatile irgend etwas mit threading zu tun hätte ist ein Märchen, das leider immer wieder Nahrung dadurch bekommt, das es auf einigen populären Plattformen funktioniert. Auf anderen Plattformen führt volatile z.B. lediglich dazu, das dem Compiler Optimierungsmöglichkeiten genommen werden, Änderungen am Hauptspeicher durch eine CPU von einer anderen CPU aber immer noch in einer anderen Reihenfolge beobachtbar sind. mfg Torsten -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Markus Schaaf Guest Posted: Tue Dec 07, 2004 3:29 pm    Post subject: Re: Probleme mit vector.push_back "Torsten Robitzki" <MyFirstname (AT) Robitzki (DOT) de> schrieb: Quote: Das volatile irgend etwas mit threading zu tun hätte ist ein Märchen, das leider immer wieder Nahrung dadurch bekommt, das es auf einigen populären Plattformen funktioniert. Es ist weder schwarz, noch weiß. Was »volatile« mit Multi-Threading zu tun hat, muß man der Dokumentation des Compilers entnehmen. Unter Win32 z.B. benötigten Microsoft-Compiler für "bestimmte Dinge" genau dieses Schlüssel- wort. Das wird auch für Signal-Handler unter Unix-artigen gelten. Oder anders: Es gibt Threading-Bibliotheken/Spezifikationen (POSIX-Threads), die dieses Schlüsselwort i.a. nicht benötigen. Das beweist jedoch nichts. Quote: Auf anderen Plattformen führt volatile z.B. lediglich dazu, das dem Compiler Optimierungsmöglichkeiten genommen werden, Änderungen am Hauptspeicher durch eine CPU von einer anderen CPU aber immer noch in einer anderen Reihenfolge beobachtbar sind. Was vom Sprachstandard her erlaubt ist, solange keine Sequenzpunkte zwischen den Zuweisungen liegen. Daß Compiler sich u.U. Reordering auf Objekt-Code-Ebene verbieten, dann aber Code erzeugen, der auf der Ziel- plattform Reordering durch die CPU zuläßt, ist nur ein trauriger Bug neben anderen. Oder ein Indiz dafür, daß Hardware-Hersteller Speicher- modelle entwickeln, auf denen kein Mensch programmieren kann/will. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Sven Lukas Guest Posted: Tue Dec 07, 2004 4:05 pm    Post subject: Re: Probleme mit vector.push_back Torsten Robitzki wrote: Quote: Das volatile irgend etwas mit threading zu tun hätte ist ein Märchen, Du hast ja Ahnung! Hier nun ein bisschen Nachhilfe mit Pseudocode: Globale Variable: int a(0); Thread 1: ... 1. // Hier: Sperre z.B. durch einen Semaphore 'X' (X = X-1) 2. ++a; 3. // Hier: Sperre 'X' wieder aufheben (X = X+1) ... Thread 2: das selbe! Anschliessend sollte a = 2 sein. Allerdings kann es in seltenen Fällen auch passieren, dass a = 1 ist, denn korrekt müsste die Deklaration von a mit volatile erfolgen (Erklärung später). "volatile" ist das Gegenteil von "register", wird keines angegeben nimmt ein Compiler i.d.R. bei voller Optimierung implizit "register" an, bei keiner Optimierung implizit "volatile". "register" ist ein Freifahrtschein für den Compiler die Variable "hinzupacken" wo er will - insbesondere in ein Prozessorregister. Natürlich liegt die Variable weiterhin an einer bestimmten Speicheradresse im Hauptspeicher, aber das "++a" (Zeile 2) kann so erfolgen, dass der Compiler einen Maschinencode erzeugt, der den Inhalt hinter der Adresse &a z.B. in das 32Bit Register eax läd (386'er-Register), dort incrementiert und den Inhalt >irgend wann< erst wieder in den Hauptspeicher an die Stelle &a zurück schreibt. (Spätestens wird dies dann geschehen, wenn eax mit einem neuen Wert geladen wird) Wenn der Compiler hier durch Optimierung nun "register" annimmt, so kann es vorkommen, dass er den inkrementierten Inhalt von "eax" (nun also 1) erst nach dem Aufheben der Sperre X in den Speicher schreibt (der Compiler hat ja keine Ahnung, welchen semaphore ich zum sperren welcher Variablen verwende, der kennt ja nicht mal semaphoren, dass ist etwas des verwendeten OS). Somit liesst Thread 2 nun statt der 1 immer noch eine 0 aus &a und rechnet folglich auch "++0", irgend wann schreibt auch Thread 2 den Inhalt zurück, egal nun ob dies zuerst Thread1 oder Thread2 macht, es kann durch das Thread-Scheduling dazu kommen, dass anschliessend a=1 gilt. "volatile" dagegen erzwingt das sofortige Zurückschreiben in den Hauptspeicher, somit steht in "a" auch die 1 VOR dem entsperren von X drin. Darum: volatile hat mit threading etwas zu tun. Ich würde sogar sagen, dass volatile ausschlisslich etwas mit threading zu tun hat - mir fällt jedenfalls kein anderer Grund ein, woru man sonst das Schlüssenwort einsetzten sollte. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Rolf Magnus Guest Posted: Tue Dec 07, 2004 4:58 pm    Post subject: Re: Probleme mit vector.push_back Markus Schaaf wrote: Quote: "Torsten Robitzki" <MyFirstname (AT) Robitzki (DOT) de> schrieb: Das volatile irgend etwas mit threading zu tun hätte ist ein Märchen, das leider immer wieder Nahrung dadurch bekommt, das es auf einigen populären Plattformen funktioniert. Es ist weder schwarz, noch weiß. Was »volatile« mit Multi-Threading zu tun hat, muß man der Dokumentation des Compilers entnehmen. Unter Win32 z.B. benötigten Microsoft-Compiler für "bestimmte Dinge" genau dieses Schlüssel- wort. Das wird auch für Signal-Handler unter Unix-artigen gelten. Signal-Handler haben aber nichts mit Multithreading zu tun. Quote: Oder anders: Es gibt Threading-Bibliotheken/Spezifikationen (POSIX-Threads), die dieses Schlüsselwort i.a. nicht benötigen. Das beweist jedoch nichts. Auf anderen Plattformen führt volatile z.B. lediglich dazu, das dem Compiler Optimierungsmöglichkeiten genommen werden, Änderungen am Hauptspeicher durch eine CPU von einer anderen CPU aber immer noch in einer anderen Reihenfolge beobachtbar sind. Was vom Sprachstandard her erlaubt ist, solange keine Sequenzpunkte zwischen den Zuweisungen liegen. Es ist alles erlaubt, was das durch ein konformes Programm beobachtbare Verhalten nicht ändert. Da die C++-Norm Threads nicht definiert, braucht sich die Implementation im Zusammenhang mit Threads an gar nichts zu halten, was dort steht. Quote: Daß Compiler sich u.U. Reordering auf Objekt-Code-Ebene verbieten, dann aber Code erzeugen, der auf der Ziel-plattform Reordering durch die CPU zuläßt, ist nur ein trauriger Bug neben anderen. Nein. Es ist eine zulässige Optimierung, die oft von der Software (auch dem Compiler) gar nicht beeinflusst werden kann. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Rolf Magnus Guest Posted: Tue Dec 07, 2004 5:06 pm    Post subject: Re: Probleme mit vector.push_back Sven Lukas wrote: Quote: Darum: volatile hat mit threading etwas zu tun. Ich würde sogar sagen, dass volatile ausschlisslich etwas mit threading zu tun hat - mir fällt jedenfalls kein anderer Grund ein, woru man sonst das Schlüssenwort einsetzten sollte. Ein Beispiel sind Hardware-Register, die in den Adressraum der CPU gemappt sind und "von außen" (z.B. durch einen Timer-Baustein) verändert werden. Oder shared-Memory, über den Daten zwischen zwei Programmen ausgetauscht werden. Ãœberall dort eben, wo der Speicher eines Programms durch irgendwas verändert (oder gelesen) werden kann, das nicht Teil des Programms selbst ist. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Thomas Maeder Guest Posted: Tue Dec 07, 2004 6:16 pm    Post subject: Re: Probleme mit vector.push_back Sven Lukas <sven.lukas (AT) post (DOT) rwth-aachen.de> writes: Quote: Das volatile irgend etwas mit threading zu tun hätte ist ein Märchen, Du hast ja Ahnung! Hier nun ein bisschen Nachhilfe mit Pseudocode: Globale Variable: int a(0); Thread 1: ... 1. // Hier: Sperre z.B. durch einen Semaphore 'X' (X = X-1) 2. ++a; 3. // Hier: Sperre 'X' wieder aufheben (X = X+1) ... Thread 2: das selbe! Anschliessend sollte a = 2 sein. Allerdings kann es in seltenen Fällen auch passieren, dass a = 1 ist, denn korrekt müsste die Deklaration von a mit volatile erfolgen (Erklärung später). Aber nur, wenn die Dokumentation der verwendeten C++-Implementation das so sagt. Im C++ Standard (und um den geht es in dieser Gruppe) kommt Threading nicht vor; deshalb kann volatile mit Threading per Definition nichts zu tun haben, ausser eine Implementation schafft einen Bezug zwischen diesen beiden Dingen. Quote: "volatile" ist das Gegenteil von "register", Entschuldigung, aber das ist Unfug. Quote: wird keines angegeben nimmt ein Compiler i.d.R. bei voller Optimierung implizit "register" an, [snip] Das ist vielleicht bei der Implementierung so, welche Du verwendest. -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Stefan Reuther Guest Posted: Tue Dec 07, 2004 7:00 pm    Post subject: Re: Probleme mit vector.push_back Sven Lukas wrote: Quote: Torsten Robitzki wrote: Das volatile irgend etwas mit threading zu tun hätte ist ein Märchen, Du hast ja Ahnung! Hier nun ein bisschen Nachhilfe mit Pseudocode: Globale Variable: int a(0); Thread 1: ... 1. // Hier: Sperre z.B. durch einen Semaphore 'X' (X = X-1) 2. ++a; 3. // Hier: Sperre 'X' wieder aufheben (X = X+1) ... Thread 2: das selbe! Anschliessend sollte a = 2 sein. Allerdings kann es in seltenen Fällen auch passieren, dass a = 1 ist, denn korrekt müsste die Deklaration von a mit volatile erfolgen (Erklärung später). In der Praxis ist das nicht ganz so schlimm. Das gilt nur, solange der Compiler der Meinung sein könnte, alle Eigenschaften dieses Codes aus einer C++-Datei entnehmen zu können. Dem kann in deinem Code einiges entgegenstehen: - du hast unterschlagen, wie die Semaphoren implementiert wurden. Meistens durch einen Aufruf an eine externe Funktion. Da diese Funktion z.B. selbst 'a' modifizieren könnte, muss der Compiler sie zurückschreiben. - angenommen, 'a' sei eine Variable mit file-scope. Dann könnte ein kleverer Compiler auf die Idee kommen, sie modul-lokal in einem Register zu halten. Das kann er aber nur, wenn er beweisen kann, dass niemand anders auf die Variable zugreift. Allerdings könnte jemand eine Funktion deines Moduls aufrufen, welche die Variable modifiziert. Dieser Jemand könnte 'ReleaseSemaphore' sein. Bitte nicht falsch verstehen: volatile ist für viele Anwendungsfälle mit mehreren Threads notwendig (aber nicht unbedingt hinreichend), aber bei weitem nicht für alle. Explizit mit Mutexen geschützte Variablen gehören in 99.9% aller Fälle nicht dazu. Ich finde es hilfreich, sich die Frage zu stellen: welche Eigenschaften könnte der hyperintelligenteste Compiler der Welt aus meinem Code ableiten? Bei einer Übersetzungseinheit void AcquireSemaphore(), ReleaseSemaphore(); int a = 0; void Thread() { AcquireSemaphore(); ++a; ReleaseSemaphore(); } sind das erschreckend wenige. Quote: Darum: volatile hat mit threading etwas zu tun. Ich würde sogar sagen, dass volatile ausschlisslich etwas mit threading zu tun hat - mir fällt jedenfalls kein anderer Grund ein, woru man sonst das Schlüssenwort einsetzten sollte. Signale. Deswegen heißt der atomar schreibbare Typ auch sig_atomic_t. Hardwarezugriffe, die strikt sequenzialisiert sein müssen. volatile char& ENABLE_TX_REGISTER = *(char*) 123; volatile char& TX_DATA_REGISTER = *(char*) 124; /* Transmitter aktivieren */ ENABLE_TX_REGISTER = 1; /* Daten auf den Transmitter geben */ TX_DATA_REGISTER = 'x'; Hier dürfen die Writes nicht vom Compiler umsortiert oder kombiniert werden. Es gibt allerdings auch Probleme, die hier auch volatile nicht löst. Da Speicher langsam sind (der Controller, mit dem ich arbeite, braucht für einen SDRAM-Zugriff 30 Takte, eine Zahl, bei der mir durchaus erstmal die Kinnlade runtergefallen ist), haben moderne CPUs Write-Buffer oder Caches. Die CPU 'posted' eine Schreiboperation und eine unabhängige Buseinheit bringt das Ding irgendwann mal raus. Selbst, wenn der Compiler also die Stores in der richtigen Reihenfolge generiert, landen sie nicht unbedingt in der gleichen Reihenfolge auf dem Bus. Freilich, Prozessorhersteller sind keine Arschlöcher, die den Programmierern möglichst viel Ärger aufhalsen wollen. Daher bauen sie üblicherweise Instruktionen ein, mit denen man dieses Verhalten steuern kann (Stichwort 'memory barrier') oder mit denen man diese Umsortierung nebst dem Cache für diverse Speicherbereiche ausschalten kann. An die kommst du aber portabel nicht ran. Das trifft natürlich nur zu, wenn mehrere Einheiten Zugriff auf den gleichen Speicher haben sollen. Sprich, in Multiprozessorsystemen oder beim Zugriff auf Speicher eines Peripheriegerätes (z.B. Grafikspeicher). In Einprozessorsystemen mit "normalen" Variablen reicht 'volatile' auf jeden Fall aus. Stefan -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (German) All times are GMT Goto page 1, 2, 3  Next Page 1 of 3   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.