C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  efficiency of new/delete Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Paul Rosen Guest Posted: Wed Jun 15, 2005 10:48 pm    Post subject: efficiency of new/delete I've been profiling some time-critical code and have generally made good progress, but I'm not sure what to do about this: In my test case, I am spending about 25% of the entire run of the program on malloc and free combined. I have two options that I see: 1) Write my own allocation routine 2) Call malloc/free less. I prefer the second option. I've already combed through my code adding reserve() to all vectors, and looking for unnecessary temporary objects, but that didn't give me much of a difference. Unfortunately, although the profiler will tell me that I've called malloc 529,984 times, it doesn't tell me how many times I'm calling it from different places, so I can't really tell who's the culprit. First, does anyone have any ideas about how I can figure out who's calling malloc so much? (I could put a breakpoint in malloc and step back through the stack, but with so many calls, I probably won't get a very clear picture of what's going on.) Second, if I were to write my own allocation routines, how should I approach it? Unless I figure out who's calling malloc so much, I would probably have to replace the global new/delete, but I'd rather not do that since my test program is actually taken out of a much larger program. ---- Background: (Environment: Windows, MSVC 7.1, DevPartner Community Edition, MFC application, heavy use of the STL that comes with MSVC 7.1.) Here are the collections that I'm using, in approximate order of frequency: string, vector, map, set. The test program consists of two parts: 1) A lengthly initialization period (half of the allocations happen here) where many objects are created that then are constant for the run of the program. This part doesn't necessarily have to be sped up. 2) The actual thread which runs slow, which is very time critical. Just as many allocations happen here as during initialization. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Bradley Guest Posted: Thu Jun 16, 2005 8:14 am    Post subject: Re: efficiency of new/delete Paul Rosen wrote: Quote: Unfortunately, although the profiler will tell me that I've called malloc 529,984 times, it doesn't tell me how many times I'm calling it from different places, so I can't really tell who's the culprit. Sounds like you need better profiling software. I know Quantify will give you want you want. It provides # of calls and time spent in a function within the context of another function. There are also various third party heap managers that you can use as well that provide quite an improvement in allocating things. I believe nuMega has such a product, it's been ages since I've looked at it. Shouldn't be too hard to find a few products at your local internet search engine. David [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Swampmonster Guest Posted: Thu Jun 16, 2005 8:15 am    Post subject: Re: efficiency of new/delete Quote: Unfortunately, although the profiler will tell me that I've called malloc 529,984 times, it doesn't tell me how many times I'm calling it from different places, so I can't really tell who's the culprit. First, does anyone have any ideas about how I can figure out who's calling malloc so much? (I could put a breakpoint in malloc and step back through the stack, but with so many calls, I probably won't get a very clear picture of what's going on.) The answer that you don't want to hear is: get a better profiler. I really can't understand why MS stripped the profiler from VC, the one built into VC6 was ... well not the best but at least usable. Another thing you could try: Define your own global "operator new" and make it track all allocations in a "map<size, count>". Then you'll at least know what the sizes of the most frequently allocated objects are, and maybe that gives you a hint which classes could be involved. If there are many many different sizes with only a few allocations per distinct size, then you can at least forget special-casing new for fixed sizes. Of course if memory is not an issue you can always implement "new" so that it only allocates powers of 2 (up to some reasonable maximum size), and use fixed size allocators for all the powers of 2. Even another way would be to "#define vector myVector" (and the other collections) over the whole project, copy & rename the whole VC7.1 implementation and add tracking to it. Then you'd know which containers (including template-parameters if you do it right) cause how many allocations - and ideally why & when, and you can go from there. And of course: never call "clear" on vectors. It deallocates storage, at least the VC7.1 implementation. Should be the same for string, but I have not checked it. Hope any of this helps. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Le Chaud Lapin Guest Posted: Thu Jun 16, 2005 8:16 am    Post subject: Re: efficiency of new/delete Paul Rosen wrote: Quote: First, does anyone have any ideas about how I can figure out who's calling malloc so much? (I could put a breakpoint in malloc and step back through the stack, but with so many calls, I probably won't get a very clear picture of what's going on.) With compile-time/link-time trickery, you could replace malloc (and free for that matter) with your own versions. Look up the calling convention, figure out where on the stack the return address is, extract it (_asm works nicely), then track how many times malloc has been called from that address: map<void *, unsigned long int> count_of_calls_to_malloc(); map<void *, unsigned long int> count_of_calls_to_free(); and of course you forward to the real malloc/free after incrementing for each call. The culprit should reveal itself thereafter. -Chaud Lapin- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Greg Guest Posted: Thu Jun 16, 2005 8:18 am    Post subject: Re: efficiency of new/delete Paul Rosen wrote: Quote: I've been profiling some time-critical code and have generally made good progress, but I'm not sure what to do about this: In my test case, I am spending about 25% of the entire run of the program on malloc and free combined. I have two options that I see: 1) Write my own allocation routine 2) Call malloc/free less. I prefer the second option. I've already combed through my code adding reserve() to all vectors, and looking for unnecessary temporary objects, but that didn't give me much of a difference. Unfortunately, although the profiler will tell me that I've called malloc 529,984 times, it doesn't tell me how many times I'm calling it from different places, so I can't really tell who's the culprit. First, does anyone have any ideas about how I can figure out who's calling malloc so much? (I could put a breakpoint in malloc and step back through the stack, but with so many calls, I probably won't get a very clear picture of what's going on.) Second, if I were to write my own allocation routines, how should I approach it? Unless I figure out who's calling malloc so much, I would probably have to replace the global new/delete, but I'd rather not do that since my test program is actually taken out of a much larger program. ---- Generally, writing a custom memory manager to overcome performance issues due to memory allocation is likely to prove ineffective (there is one notable exception however, which I will get to). It would probably be much easier to reduce the 529,984 allocations by a factor of 10 or more, than it would be to write a memory manager 10 times faster than the current one. The questions to ask about the implementation would be: is the program passing or returning containers by value in function calls? Or is it passing objects by value that have containers as data members? How many containers are declared locally especially in code that runs in a loop? It seems just running the program, then putting a breakpoint at delete is likely to provide a crude but still useful sampling of the program's memory allocation patterns. Remember that though a container like a std::vector may be declared on the stack, it still allocates memory for its items on the heap. So favor passing (and returning) containers by reference, avoid declaring many containers locally (instead reuse existing containers when possible), and pay particular attention to the local variables of any code executed in a loop. There is one case where writing a custom allocator does make sense: when all the allocations are of equal size. Fixed-sized allocators (or "pools") are not too difficult to write, and unless the implementation is really poor, will always perform at least as well as a standard memory manager; but pools can perform much better because a fixed-size allocator can promise both constant time allocations and deallocations, while a general memory manager can guarantee only the latter. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Andrei Alexandrescu (See Guest Posted: Thu Jun 16, 2005 8:18 am    Post subject: Re: efficiency of new/delete Paul Rosen wrote: Quote: I've been profiling some time-critical code and have generally made good progress, but I'm not sure what to do about this: It's likely your strings are the culprit. Collect statistics of the lengths of the strings you're using, and then use SSO for a well-chosen cut. A friend of mine working at a well-known company has done that, found that 87% of the strings were of length <= 15, and applied SSO with flex_string to slash the number of requests to the memory allocator by a factor of 7. Andrei [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Erik Guest Posted: Thu Jun 16, 2005 8:19 am    Post subject: Re: efficiency of new/delete Paul Rosen wrote: Quote: First, does anyone have any ideas about how I can figure out who's calling malloc so much? (I could put a breakpoint in malloc and step back through the stack, but with so many calls, I probably won't get a very clear picture of what's going on.) Hi Paul, You can track memory allocation by using makros. Here is a code snippet written in C. You can place the malloc-Makros e. g. in a header file "track_malloc.h". Than you simply have to replace "malloc.h" by "track_malloc.h". If you want to use the macros maybe you should write the log data to a file. //begin of code snippet #include "stdio.h" #include "malloc.h" #define __MEMTRACK__ #ifdef __MEMTRACK__ #define __MALLOC #define __FREE #endif #ifdef __MALLOC #define MALLOC(x) TrackMalloc(__FILE__,__LINE__,x,#x) #define malloc(x) MALLOC(x) #endif #ifdef __FREE #define FREE(x) TrackFree(__FILE__,__LINE__,x,#x) #define free(x) FREE(x) #endif #ifdef __MALLOC void * TrackMalloc(char* file, int line, size_t size, char * param) { void * ptr; #undef malloc(x) ptr = malloc(size); #define malloc(x) MALLOC(x) printf("---------------------- malloc ----------------------n"); printf("file: %sn",file); printf("line: %2dn",line); printf("size: 0x%02X bytesn",size); printf("parameter: %sn",param); printf("start address: %8pn",(long)ptr); printf("end address: %8pn",(long)ptr + size); return ptr; } #endif #ifdef __FREE void TrackFree(char* file, int line, void * block, char * param) { printf("---------------------- free ------------------------n"); printf("file: %sn",file); printf("line: %2dn",line); printf("parameter: %sn",param); printf("start address: %8pn",(long)block); #undef free(x) free(block); #define free(x) FREE(x) } #endif int main(int argc, char* argv[]) { int * i; i = (int*)malloc(sizeof(int)); *i = 42; printf("---------------------- value -----------------------n"); printf("value of i = %dn",*i); free(i); return 0; } //end of code snippet The program delivers the following output: ---------------------- malloc ---------------------- file: M:appdoxygenprjC++ Einfhrungsourcescope and lifetimeC-Makrosmemtrack.cpp line: 56 size: 0x04 bytes parameter: sizeof(*i) start address: 00BA2E1C end address: 00BA2E20 ---------------------- value ----------------------- value of i = 42 ---------------------- free ------------------------ file: M:appdoxygenprjC++ Einfhrungsourcescope and lifetimeC-Makrosmemtrack.cpp line: 60 parameter: i start address: 00BA2E1C [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Joshua Lehrer Guest Posted: Thu Jun 16, 2005 8:22 am    Post subject: Re: efficiency of new/delete Consider using special flags to your linker to route calls to new/malloc to your own allocation functions. Find a way to get the filename and line numbers passed into your special functions. This can be *very* valuable once you get it working. joshua lehrer [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Timo Geusch Guest Posted: Thu Jun 16, 2005 8:23 am    Post subject: Re: efficiency of new/delete Paul Rosen wrote: Quote: I've been profiling some time-critical code and have generally made good progress, but I'm not sure what to do about this: In my test case, I am spending about 25% of the entire run of the program on malloc and free combined. Erm, you mentioned new/delete in your subject - which of the two is it? Or are you referring to new calling malloc/free? Quote: Unfortunately, although the profiler will tell me that I've called malloc 529,984 times, it doesn't tell me how many times I'm calling it from different places, so I can't really tell who's the culprit. You *need* to find out who's calling malloc/free and then make a decision based on this. Quote: First, does anyone have any ideas about how I can figure out who's calling malloc so much? (I could put a breakpoint in malloc and step back through the stack, but with so many calls, I probably won't get a very clear picture of what's going on.) Doesn't your profiler show you the call tree? Or give you a breakdown of the callers and callees on a per-function basis? If not you may need to approach your boss to cough up for a decent profiler... That said, in absence of a profiler that can do the above I'm afraid your breakpoint method is probably the best way to find out. Quote: Second, if I were to write my own allocation routines, how should I approach it? Unless I figure out who's calling malloc so much, I would probably have to replace the global new/delete, but I'd rather not do that since my test program is actually taken out of a much larger program. I wouldn't replace the global new/delete as I would doubt that you can do a better job for the general case. That said, if you find out that a lot of time is spent allocating memory for objects of the same type it may be beneficial to replace the new/delete operators for this class with one that is tailored specifically for this job by, say, allocating out of a memory pool or similar... [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Thomas Richter Guest Posted: Fri Jun 17, 2005 10:06 am    Post subject: Re: efficiency of new/delete Hi, Quote: 1) Write my own allocation routine 2) Call malloc/free less. I prefer the second option. This is a good option, though 1) might do just the same implicitly. Personally, I say 3) is the best option, where 3) is that you need to rethink the design a bit, see below for my idea. Quote: I've already combed through my code adding reserve() to all vectors, and looking for unnecessary temporary objects, but that didn't give me much of a difference. The idea should be that you need to check which objects are allocated/ released most often, and then try to cache them and reuse them. I personally prefer a "factory design" for these objects, i.e. I have a class that "allocates" and "releases" them, but instead of getting the memory from the system, this factory rather tries to recycle objects. Quote: Unfortunately, although the profiler will tell me that I've called malloc 529,984 times, it doesn't tell me how many times I'm calling it from different places, so I can't really tell who's the culprit. A profiler worth its money should actually be able to give you a call graph, i.e. which function was called from where. The GNU gprof does, at least. It is available under win32, for example in the CygWin environment. Though this possibly doesn't help you much... A second approach would be - if you have at least some idea who might be guilty - to provide (temporarely) a custom operator new and operator delete for some of the classes. This operator would increment a counter, depending on class type, and then perform the memory allocation itself. Inspecting the counters before the program exits should give you some hints. Quote: First, does anyone have any ideas about how I can figure out who's calling malloc so much? (I could put a breakpoint in malloc and step back through the stack, but with so many calls, I probably won't get a very clear picture of what's going on.) Second, if I were to write my own allocation routines, how should I approach it? Unless I figure out who's calling malloc so much, I would probably have to replace the global new/delete, but I'd rather not do that since my test program is actually taken out of a much larger program. First step: Figure out who's guilty. (-: One additional hint: You may also use the size argument of operator new to get a clue on who's allocating so many objects. This would mean that you replace operator new, and operator delete, and within it, you have a static array of ints that is indexed by the size of the allocation. On allocation, find the right slot for the array, then increment. This will give you a "histogram" of the allocation and thus possibly a hint of which object to look for. Concerning replacing operator new/delete: You could either go for replacing the operator globally, but if this is not an option, write a small "base class" that provides its own operator new/delete. Derive all your objects ("the usual suspects") from this class to get their memory allocation tracked. So long, Thomas [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Fri Jun 17, 2005 10:12 am    Post subject: Re: efficiency of new/delete Paul Rosen wrote: Quote: I've been profiling some time-critical code and have generally made good progress, but I'm not sure what to do about this: In my test case, I am spending about 25% of the entire run of the program on malloc and free combined. I have two options that I see: 1) Write my own allocation routine This probably won't win you much, unless you have a specific use pattern for which a specialized algorithm may be more efficient. Quote: 2) Call malloc/free less. I prefer the second option. I've already combed through my code adding reserve() to all vectors, and looking for unnecessary temporary objects, but that didn't give me much of a difference. Unfortunately, although the profiler will tell me that I've called malloc 529,984 times, it doesn't tell me how many times I'm calling it from different places, so I can't really tell who's the culprit. Change the profiler. The profilers I know indicate how many times from where. Failing that, wrap malloc (or operator new) is a separate function, and call that in some specific cases. The frequency that function is called will indicate how many times malloc is called from those specific cases. Quote: First, does anyone have any ideas about how I can figure out who's calling malloc so much? (I could put a breakpoint in malloc and step back through the stack, but with so many calls, I probably won't get a very clear picture of what's going on.) There are non-portable ways of doing a stack walkback; keeping a map of return address->counter could provide some information. (Be very, very careful to avoid recursively calling malloc if you do this.) Quote: Second, if I were to write my own allocation routines, how should I approach it? Unless I figure out who's calling malloc so much, I would probably have to replace the global new/delete, but I'd rather not do that since my test program is actually taken out of a much larger program. Formally, the only solution is to replace the global new and delete. In practice, although it is undefined behavior, it is generally possible to replace malloc and free directly. But in most compilers, the implementation of malloc and free is already pretty good; you'll have a hard time beating it, unless there is some, particular known pattern of use in your application. -- James Kanze GABI Software 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 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ralf Fassel Guest Posted: Fri Jun 17, 2005 10:14 am    Post subject: Re: efficiency of new/delete * "Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail (AT) moderncppdesign (DOT) com> Quote: Collect statistics of the lengths of the strings you're using, and then use SSO for a well-chosen cut. Excuse my ignorance, 'SSO'? String-Size-Optimization? (The TLA isn't mentioned in the C++FAQ, all I can google is 'Single-Sign-On'...) {Short String Optimisation -mod/fwg} R' [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top wkaras@yahoo.com Guest Posted: Fri Jun 17, 2005 10:19 am    Post subject: Re: efficiency of new/delete Paul Rosen wrote: Quote: I've been profiling some time-critical code and have generally made good progress, but I'm not sure what to do about this: In my test case, I am spending about 25% of the entire run of the program on malloc and free combined. I have two options that I see: 1) Write my own allocation routine 2) Call malloc/free less. I prefer the second option. I've already combed through my code adding reserve() to all vectors, and looking for unnecessary temporary objects, but that didn't give me much of a difference. Unfortunately, although the profiler will tell me that I've called malloc 529,984 times, it doesn't tell me how many times I'm calling it from different places, so I can't really tell who's the culprit. First, does anyone have any ideas about how I can figure out who's calling malloc so much? (I could put a breakpoint in malloc and step back through the stack, but with so many calls, I probably won't get a very clear picture of what's going on.) Second, if I were to write my own allocation routines, how should I approach it? Unless I figure out who's calling malloc so much, I would probably have to replace the global new/delete, but I'd rather not do that since my test program is actually taken out of a much larger program. ---- Background: (Environment: Windows, MSVC 7.1, DevPartner Community Edition, MFC application, heavy use of the STL that comes with MSVC 7.1.) Here are the collections that I'm using, in approximate order of frequency: string, vector, map, set. The test program consists of two parts: 1) A lengthly initialization period (half of the allocations happen here) where many objects are created that then are constant for the run of the program. This part doesn't necessarily have to be sped up. 2) The actual thread which runs slow, which is very time critical. Just as many allocations happen here as during initialization. A quick and dirty thing to try is to put code like this in malloc/free (and maybe new/delete): if (!(--malloc_dc)) malloc_dc = malloc_dc_init; // put breakpoint here. assuming: unsigned malloc_dc_init = 11 * 11 * 11; // or whatever. unsigned malloc_dc = malloc_dc_init; to "sample" the calls to these functions and look at the call stack. It may or may not be useful for the downcount initial value to be relatively prime to loop counts in the code. If you decide you need to write your own allocator, my web page, http://www.geocities.com/wkaras , has some links to memory allocator code. This page also has an AVL tree template, which could be used in place of a map or set, but using a statically allocated array (the second example shows this). [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Michael Olea Guest Posted: Fri Jun 17, 2005 10:24 am    Post subject: Re: efficiency of new/delete Andrei Alexandrescu (See Website For Email) wrote: Quote: Paul Rosen wrote: I've been profiling some time-critical code and have generally made good progress, but I'm not sure what to do about this: It's likely your strings are the culprit. Collect statistics of the lengths of the strings you're using, and then use SSO for a well-chosen cut. A friend of mine working at a well-known company has done that, found that 87% of the strings were of length <= 15, and applied SSO with flex_string to slash the number of requests to the memory allocator by a factor of 7. Andrei What does SSO stand for? What is flex_string? I couldn't find these in the faq, though "Secure Sign On" and "Single Sign On" came up. Is it true you beat your wife (that didn't turn up in the faq either )? {Short String Optimisation -mod} [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Paul Rosen Guest Posted: Fri Jun 17, 2005 1:19 pm    Post subject: Re: efficiency of new/delete [Thanks to everyone who responded! There were lots of good ideas. I hope you don't mind me combining replies to different emails to cut down on list traffic.] Quote: Erm, you mentioned new/delete in your subject - which of the two is it? Or are you referring to new calling malloc/free? Sorry to be imprecise -- new/delete calls malloc/free, so either is correct in my case. The profiler shows malloc/free as the heavy users, but I thought if I said that then someone would assume *I'm* calling a *gasp* C library routine directly. (But then I slipped in the next sentence and said malloc anyway.) Quote: Doesn't your profiler show you the call tree? Or give you a breakdown of the callers and callees on a per-function basis? If not you may need to approach your boss to cough up for a decent profiler... Interestingly enough, the profiler *almost* does a great job. It shows a call tree, but it doesn't show how many times each branch was taken. (It shows the percentage of the time that malloc took compared to the total time of each calling routine. I can't figure out how that would be useful.) In addition, there are a lot of different calls to malloc, and they are usually buried in a few layers of wrappers, so there's a lot of clicking to figure out what is going on. Quote: That said, in absence of a profiler that can do the above I'm afraid your breakpoint method is probably the best way to find out. I decided to try that, and it wasn't as bad as I thought. The key was to put a breakpoint at the beginning of a loop that I suspected was important, and only then put a breakpoint in malloc so I didn't have to wade through a bunch of uninteresting calls. I did find some things to improve. Quote: It's likely your strings are the culprit. Collect statistics of the lengths of the strings you're using, and then use SSO for a well- chosen cut. A friend of mine working at a well-known company has done that, found that 87% of the strings were of length <= 15, and applied SSO with flex_string to slash the number of requests to the memory allocator by a factor of 7. A quick Google found your article. I'm going to look into it. (BTW, I loved your book, but can't say I've absorbed it yet.) I do have a number of strings under 16 characters. I also noticed that I'm getting a malloc on string assignment where I know I won't be modifying either the source or destination, and string assignment is hard to avoid without sacrificing maintainability. I think I could probably use reference counting there. One hesitation I have is that I'd like the interface to have parameters of "string" so that I'm not changing the API. In other words, it is important that the public functions be: class MyIncreasinglyFasterClass { public: std::string GetStuff() const; void SetStuff(const std::string& str); void GetLotsOfStuff(std::vector }; and not a different object. But, maybe I can persuade everyone to standardize on flex_string. Quote: And of course: never call "clear" on vectors. It deallocates storage, at least the VC7.1 implementation. Should be the same for string, but I have not checked it. That's surprising. I thought that vectors were guaranteed never to free memory. I do depend on that in one place: I have a scratch vector that I reserve() to a maximum value, then freely use, hoping that it never calls malloc/free. (I don't happen to call clear() on it, though, I just repeatedly call resize().) [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] 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++ Language (Moderated) All times are GMT Goto page 1, 2  Next Page 1 of 2   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.