C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Habitual optimization          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Steven T. Hatton Guest Posted: Wed Dec 20, 2006 7:41 pm    Post subject: Habitual optimization I have long wondered about certain programming styles/strategies and how they can impact performance. I understand that the intent of the examples in _C++ GUI Programming with Qt 4_ is pedagogical and, therefore, they should stress clarity over optimal efficiency. Nonetheless, the code shown on pg 130 gives me an opportunity to ask a question about coding strategy in general. Page 18 of _C++ Coding Standards_ by Sutter and Alexandrescu tells us "It is not premature optimization to reduce spurious temporary copies of objects, especially in inner loops, when doing so doesn't impact code complexity." My question is whether any clock cycles might be saved by moving some of the arithmetic out of the loops? For example, would anything be gained by defining: const int dTick((rect.width() - 1)/settings.numXTicks); and then writing: int x = rect.left() + i * dTick;? Or even `int x(rect.left());' outside the loop, and `x+=dTick'; inside the loop? What about calls to functions such as settings.spanX()? If these values are unchanged during the loop, can anything be gained by assigning them to a constant before entering the loop? void Plotter::drawGrid(QPainter *painter) { QRect rect(Margin, Margin, width() - 2 * Margin, height() - 2 * Margin); if (!rect.isValid()) return; PlotSettings settings = zoomStack[curZoom]; QPen quiteDark = palette().dark().color().light(); QPen light = palette().light().color(); for (int i = 0; i <= settings.numXTicks; ++i) { int x = rect.left() + (i * (rect.width() - 1) / settings.numXTicks); double label = settings.minX + (i * settings.spanX() / settings.numXTicks); painter->setPen(quiteDark); painter->drawLine(x, rect.top(), x, rect.bottom()); painter->setPen(light); painter->drawLine(x, rect.bottom(), x, rect.bottom() + 5); painter->drawText(x - 50, rect.bottom() + 5, 100, 15, Qt::AlignHCenter | Qt::AlignTop, QString::number(label)); } //... } I'm confident that the first part of any answer to these questions will be "It depends...". The term "optimizer" will probably arise as well. I also realize my arithmetic modifications might change the behavior of the code due to the evaluation order of the multiplicative operations. One additional question I have deals with for-loops. std::vector<Object> v; // fill the vector for(unsigned i(0); i<v.size(); ++i){ //do something. } Is it likely that an optimizer could improve performance if it could determine that v.size() is unchanged during the loop, and thus eliminate calls to v.size()? -- Regards, Steven [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top dhruv Guest Posted: Thu Dec 21, 2006 11:50 pm    Post subject: Re: Habitual optimization Steven T. Hatton wrote: Quote: I have long wondered about certain programming styles/strategies and how they can impact performance. [snip].... Quote: const int dTick((rect.width() - 1)/settings.numXTicks); and then writing: int x = rect.left() + i * dTick;? Or even `int x(rect.left());' outside the loop, and `x+=dTick'; inside the loop? Yes, definitely there is a gain to use the additive operation inside of the loop. Two in fact: [1] You are executing an add operation instead of a multiply every time, which is less time consuming. [2] You are touching lesser number of variables. Typically, on an x86 machine, the former would be: (a) Load dTick into a temporary. (b) Multiply i and dTick. (c) Store the result of rect.left() in a temporary. (d) Add the result of the above 2 temporaries. However, the latter would be: (a) Store the result of rect.left() in a temporary. (b) Add the above temporary and the value of dTick. [snip].... Quote: One additional question I have deals with for-loops. std::vector<Object> v; // fill the vector for(unsigned i(0); i<v.size(); ++i){ //do something. } Is it likely that an optimizer could improve performance if it could determine that v.size() is unchanged during the loop, and thus eliminate calls to v.size()? Yes, definitely it would result in a performance gain. The C++ standard specifies that the size() member function should be constant time. It may be implemented as a difference of 2 pointers, which boils down to difference followed by a divide with the type's size. If these 2 operations can be eliminated(which btw involve an AGI) then there's nothing better for speed!!!! Regards, -Dhruv. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Simon Farnsworth Guest Posted: Fri Dec 22, 2006 3:13 am    Post subject: Re: Habitual optimization Steven T. Hatton wrote: Quote: Page 18 of _C++ Coding Standards_ by Sutter and Alexandrescu tells us "It is not premature optimization to reduce spurious temporary copies of objects, especially in inner loops, when doing so doesn't impact code complexity." My question is whether any clock cycles might be saved by moving some of the arithmetic out of the loops? For example, would anything be gained by defining: const int dTick((rect.width() - 1)/settings.numXTicks); and then writing: int x = rect.left() + i * dTick;? Or even `int x(rect.left());' outside the loop, and `x+=dTick'; inside the loop? What about calls to functions such as settings.spanX()? If these values are unchanged during the loop, can anything be gained by assigning them to a constant before entering the loop? There's two standard compiler optimizations you're thinking about here; loop-invariant code motion, and strength reduction. Given the code you're showing, it'd take quite an advanced optimizer to spot the opportunities here, so doing it manually is not a bad idea. As always, remember Knuth's point on premature optimization; if the code is made less clear by doing either of these, don't do them. Wikipedia has reasonable articles on both optimizations: http://en.wikipedia.org/wiki/Loop-invariant_code_motion http://en.wikipedia.org/wiki/Strength_reduction -- Simon Farnsworth [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dave Harris Guest Posted: Fri Dec 22, 2006 10:10 am    Post subject: Re: Habitual optimization hattons (AT) globalsymmetry (DOT) com (Steven T. Hatton) wrote (abridged): Quote: My question is whether any clock cycles might be saved by moving some of the arithmetic out of the loops? Probably. The drawback to pre-calculating and storing the value in a variable is that it uses more memory. (Or rather, the same memory for longer.) You may find that all the other code in the loop causes the variable to be spilled out of hardware caches. It's conceivable that: x = rect.left() + (i * (rect.width() - 1) / settings.numXTicks); be quicker to execute than: x += dTick; if dTick requires a memory read and the other expression doesn't. It's unlikely, but to be sure you'd need to measure. Mind you, the difference will probably be insignificant anyway, compared to the work being done elsewhere in the loop. Pure arithmetic expressions with no tests or branches, and all functions inlined, tend to be jolly quick on modern CPUs. Quote: I also realize my arithmetic modifications might change the behavior of the code due to the evaluation order of the multiplicative operations. Indeed. In particular, you'll probably get rounding errors that accumulate as the loop progresses. For example, if settings.numXTicks is 20 and rect.width() is 155, then dTick is 7 and dTick*20 is 140, which is wrong by 14 units. That is probably a significant bug. -- Dave Harris, Nottingham, UK. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top James Kanze Guest Posted: Fri Dec 22, 2006 8:36 pm    Post subject: Re: Habitual optimization Steven T. Hatton wrote: Quote: I have long wondered about certain programming styles/strategies and how they can impact performance. I understand that the intent of the examples in _C++ GUI Programming with Qt 4_ is pedagogical and, therefore, they should stress clarity over optimal efficiency. Nonetheless, the code shown on pg 130 gives me an opportunity to ask a question about coding strategy in general. Page 18 of _C++ Coding Standards_ by Sutter and Alexandrescu tells us "It is not premature optimization to reduce spurious temporary copies of objects, especially in inner loops, when doing so doesn't impact code complexity." I'm not sure I'd agree with that, but it probably depends on what they mean by "doesn't impact code complexity". If I have to think about it, it could be argued that it impacts code complexity. In the end, you need to use a little bit of common sense as well. If the temporary copie is of an std::list with a couple of hundred thousand entries, you're probably better off paying attention to it up front (supposing it is in a tight loop, of course). If you're worried about copying an iterator a couple times more than necessary, you're wasting your time. In general, write the code cleanly, and if it isn't fast enough, use the profile, and optimize what needs optimization. Worrying about speed before the program actually works is generally counter-productive. Quote: My question is whether any clock cycles might be saved by moving some of the arithmetic out of the loops? For example, would anything be gained by defining: const int dTick((rect.width() - 1)/settings.numXTicks); and then writing: int x = rect.left() + i * dTick;? Or even `int x(rect.left());' outside the loop, and `x+=dTick'; inside the loop? It might. The results might also end up running slower (although it's not too likely). This is the sort of optimization compilers are very good at, however, so I wouldn't worry about it in general. More importantly, any modifications to do it this way later are local, so acting on it before the profiler says you have to is simply stupid. Quote: What about calls to functions such as settings.spanX()? If these values are unchanged during the loop, can anything be gained by assigning them to a constant before entering the loop? Maybe. It depends on the compiler. The only way to know is to profile. Quote: void Plotter::drawGrid(QPainter *painter) { QRect rect(Margin, Margin, width() - 2 * Margin, height() - 2 * Margin); if (!rect.isValid()) return; PlotSettings settings = zoomStack[curZoom]; QPen quiteDark = palette().dark().color().light(); QPen light = palette().light().color(); for (int i = 0; i <= settings.numXTicks; ++i) { int x = rect.left() + (i * (rect.width() - 1) / settings.numXTicks); double label = settings.minX + (i * settings.spanX() / settings.numXTicks); painter->setPen(quiteDark); painter->drawLine(x, rect.top(), x, rect.bottom()); painter->setPen(light); painter->drawLine(x, rect.bottom(), x, rect.bottom() + 5); painter->drawText(x - 50, rect.bottom() + 5, 100, 15, Qt::AlignHCenter | Qt::AlignTop, QString::number(label)); } //... } I'm confident that the first part of any answer to these questions will be "It depends...". The term "optimizer" will probably arise as well. I also realize my arithmetic modifications might change the behavior of the code due to the evaluation order of the multiplicative operations. In sum, you know the answer. So why ask the question? Quote: One additional question I have deals with for-loops. std::vector<Object> v; // fill the vector for(unsigned i(0); i<v.size(); ++i){ //do something. } Is it likely that an optimizer could improve performance if it could determine that v.size() is unchanged during the loop, and thus eliminate calls to v.size()? Maybe. I'm sure that some compilers can do this. But not all. On the other hand, if v.size() is inlined, "calling" it each time through the loop, rather than keeping it in a register, is one extra memory access. It would have to be a very simple loop for this to make a difference. Again---write the most natural form, then if the program is too slow, and the profiler says that it is because of this loop, start experimenting. -- James Kanze (Gabi Software) email: james.kanze (AT) gmail (DOT) com 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 James Kanze Guest Posted: Fri Dec 22, 2006 8:36 pm    Post subject: Re: Habitual optimization dhruv wrote: Quote: Steven T. Hatton wrote: I have long wondered about certain programming styles/strategies and how they can impact performance. [snip].... const int dTick((rect.width() - 1)/settings.numXTicks); and then writing: int x = rect.left() + i * dTick;? Or even `int x(rect.left());' outside the loop, and `x+=dTick'; inside the loop? Yes, definitely there is a gain to use the additive operation inside of the loop. That's what a naïve person might think. Quote: Two in fact: [1] You are executing an add operation instead of a multiply every time, which is less time consuming. On some machines. On most modern machines, I don't think that there's any difference. On some machines, certain combinations of operations are faster---I've seen machines which could optimize a*x+b much better than a simple multiplication or addition. Quote: [2] You are touching lesser number of variables. Except that a good optimizer will have put them in registers, so that it doesn't matter. Quote: Typically, on an x86 machine, the former would be: (a) Load dTick into a temporary. (b) Multiply i and dTick. (c) Store the result of rect.left() in a temporary. (d) Add the result of the above 2 temporaries. However, the latter would be: (a) Store the result of rect.left() in a temporary. (b) Add the above temporary and the value of dTick. Both sequences are signs of a pretty bad compiler. If values are being cumulated during a loop, the compiler should be storing them in a register. And compilers are very good at strenght reduction (replacing multiplication with addition when it does make a difference) and loop invariant motion---these have been standard optimizations for over twenty years. Quote: [snip].... One additional question I have deals with for-loops. std::vector<Object> v; // fill the vector for(unsigned i(0); i<v.size(); ++i){ //do something. } Is it likely that an optimizer could improve performance if it could determine that v.size() is unchanged during the loop, and thus eliminate calls to v.size()? Yes, definitely it would result in a performance gain. The C++ standard specifies that the size() member function should be constant time. It may be implemented as a difference of 2 pointers, which boils down to difference followed by a divide with the type's size. If these 2 operations can be eliminated(which btw involve an AGI) then there's nothing better for speed!!!! And a good optimizer can do it. Why should the programmer worry about such things? And of course, most of the time, even if the optimizer doesn't do it, the program will still be fast enough. Wasting time optimizing what doesn't have to be optimized is pretty unprofessional, when it comes down to it. -- James Kanze (Gabi Software) email: james.kanze (AT) gmail (DOT) com 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 Andrei Alexandrescu (See Guest Posted: Sat Dec 23, 2006 4:45 am    Post subject: Re: Habitual optimization James Kanze wrote: Quote: Steven T. Hatton wrote: I have long wondered about certain programming styles/strategies and how they can impact performance. I understand that the intent of the examples in _C++ GUI Programming with Qt 4_ is pedagogical and, therefore, they should stress clarity over optimal efficiency. Nonetheless, the code shown on pg 130 gives me an opportunity to ask a question about coding strategy in general. Page 18 of _C++ Coding Standards_ by Sutter and Alexandrescu tells us "It is not premature optimization to reduce spurious temporary copies of objects, especially in inner loops, when doing so doesn't impact code complexity." I'm not sure I'd agree with that, but it probably depends on what they mean by "doesn't impact code complexity". If I have to think about it, it could be argued that it impacts code complexity. We were hesitant about how to phrase that one. The whole idea was "all other things being equal" which tacitly included programmer's intellectual effort. If the slightly faster code is just as clear and written with your bone marrow, fine. If actual brain neurons are busy with minute optimality, that quickly becomes wasteful. The kind of laborious femto-optimizations mentioned by the OP is a sign that even our subdued message could be taken too strongly. Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Martin Eisenberg Guest Posted: Sat Dec 23, 2006 4:55 am    Post subject: Re: Habitual optimization James Kanze wrote: Quote: Steven T. Hatton wrote: My question is whether any clock cycles might be saved by moving some of the arithmetic out of the loops? For example, would anything be gained by defining: const int dTick((rect.width() - 1)/settings.numXTicks); and then writing: int x = rect.left() + i * dTick;? Or even `int x(rect.left());' outside the loop, and `x+=dTick'; inside the loop? It might. The results might also end up running slower (although it's not too likely). This is the sort of optimization compilers are very good at, however, so I wouldn't worry about it in general. More importantly, any modifications to do it this way later are local, so acting on it before the profiler says you have to is simply stupid. Compare the version Steven proposed last to the original: get distance from voodoo get starting point repeat { plant object here advance position } repeat { get point from voodoo put object there } Where "voodoo" means something too long to take in with a sideways glance if one hadn't written it many times before. I find it worth pointing out that whether a person reads the former rendition as micro-optimization or as the "natural" way to cast what's going on depends on personal mode of thinking -- one is more processual, the other more structural. Neither way is necessarily smarter. Martin -- The man who does not read good books has no advantage over the man who cannot read them. --Mark Twain [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Steven T. Hatton Guest Posted: Sat Dec 23, 2006 10:10 am    Post subject: Re: Habitual optimization Andrei Alexandrescu (See Website For Email) wrote: Quote: James Kanze wrote: Steven T. Hatton wrote: I have long wondered about certain programming styles/strategies and how they can impact performance. I understand that the intent of the examples in _C++ GUI Programming with Qt 4_ is pedagogical and, therefore, they should stress clarity over optimal efficiency. Nonetheless, the code shown on pg 130 gives me an opportunity to ask a question about coding strategy in general. Page 18 of _C++ Coding Standards_ by Sutter and Alexandrescu tells us "It is not premature optimization to reduce spurious temporary copies of objects, especially in inner loops, when doing so doesn't impact code complexity." I'm not sure I'd agree with that, but it probably depends on what they mean by "doesn't impact code complexity". If I have to think about it, it could be argued that it impacts code complexity. We were hesitant about how to phrase that one. The whole idea was "all other things being equal" which tacitly included programmer's intellectual effort. If the slightly faster code is just as clear and written with your bone marrow, fine. If actual brain neurons are busy with minute optimality, that quickly becomes wasteful. The kind of laborious femto-optimizations mentioned by the OP is a sign that even our subdued message could be taken too strongly. I wasn't suggesting that I would get much of an ROI from the specific example. What I'm really trying to establish is whether there are more efficient styles of programming which are worth internalizing as a habit. In the case given, the code resided in a top level loop, so it really doesn't apply to your advice, per se. It might be more relevant in the context of computing the positions of fluid coordinates in a finite element model which iterates over each coordinate point, performing multiple calculations to determine the subsequent state. -- Regards, Steven [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Bo Persson Guest Posted: Sun Dec 24, 2006 1:15 am    Post subject: Re: Habitual optimization Martin Eisenberg wrote: Quote: Compare the version Steven proposed last to the original: get distance from voodoo get starting point repeat { plant object here advance position } repeat { get point from voodoo put object there } Where "voodoo" means something too long to take in with a sideways glance if one hadn't written it many times before. I find it worth pointing out that whether a person reads the former rendition as micro-optimization or as the "natural" way to cast what's going on depends on personal mode of thinking -- one is more processual, the other more structural. Neither way is necessarily smarter. No, but the question was: "Is the longer version actually running faster?". If it is not obvious that it does (and that it matters), the shorter code seems to have fewer places to get things wrong. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dave Harris Guest Posted: Mon Dec 25, 2006 1:20 am    Post subject: Re: Habitual optimization martin.eisenberg (AT) udo (DOT) edu (Martin Eisenberg) wrote (abridged): Quote: I find it worth pointing out that whether a person reads the former rendition as micro-optimization or as the "natural" way to cast what's going on depends on personal mode of thinking -- one is more processual, the other more structural. Neither way is necessarily smarter. As I said in my other post, one accumulates massive rounding errors, the other doesn't. One is wrong, the other right. (Unless, of course, rect.width() - 1 is an exact multiple of settings.numXTicks: but now we are relying on specific knowledge that is not apparent to someone reading the given code in isolation.) -- Dave Harris, Nottingham, UK. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top James Kanze Guest Posted: Sun Dec 31, 2006 10:10 am    Post subject: Re: Habitual optimization Martin Eisenberg wrote: Quote: James Kanze wrote: Steven T. Hatton wrote: My question is whether any clock cycles might be saved by moving some of the arithmetic out of the loops? For example, would anything be gained by defining: const int dTick((rect.width() - 1)/settings.numXTicks); and then writing: int x = rect.left() + i * dTick;? Or even `int x(rect.left());' outside the loop, and `x+=dTick'; inside the loop? It might. The results might also end up running slower (although it's not too likely). This is the sort of optimization compilers are very good at, however, so I wouldn't worry about it in general. More importantly, any modifications to do it this way later are local, so acting on it before the profiler says you have to is simply stupid. Compare the version Steven proposed last to the original: get distance from voodoo get starting point repeat { plant object here advance position } repeat { get point from voodoo put object there } Where "voodoo" means something too long to take in with a sideways glance if one hadn't written it many times before. I find it worth pointing out that whether a person reads the former rendition as micro-optimization or as the "natural" way to cast what's going on depends on personal mode of thinking -- one is more processual, the other more structural. Neither way is necessarily smarter. That's a very good point. Choosing one form or the other is, in many cases, a form of documentation, stating how you were thinking about the problem, and how it was analysed to prove correctness. As Dave Harris has pointed out, in many cases, particularly when floating point arithmetic is involved, the two forms are not guaranteed to give the same results; you obviously want to use the form that has been validated to give correct results. Regardless of which it is. My comment should be restricted to the idea of not changing the original form (whichever it was) for presumed performance reasons, unless actual measures show it to be necessary. -- James Kanze (Gabi Software) email: james.kanze (AT) gmail (DOT) com 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 Gennaro Prota Guest Posted: Sat Jan 06, 2007 3:21 am    Post subject: Re: Habitual optimization On 22 Dec 2006 09:36:10 -0500, James Kanze wrote: Quote: Steven T. Hatton wrote: I have long wondered about certain programming styles/strategies and how they can impact performance. I understand that the intent of the examples in _C++ GUI Programming with Qt 4_ is pedagogical and, therefore, they should stress clarity over optimal efficiency. Nonetheless, the code shown on pg 130 gives me an opportunity to ask a question about coding strategy in general. Page 18 of _C++ Coding Standards_ by Sutter and Alexandrescu tells us "It is not premature optimization to reduce spurious temporary copies of objects, especially in inner loops, when doing so doesn't impact code complexity." I'm not sure I'd agree with that, but it probably depends on what they mean by "doesn't impact code complexity". If I have to think about it, it could be argued that it impacts code complexity. In the end, you need to use a little bit of common sense as well. That's probably the main point. I'm not sure I'd agree with "if I have to think about it, it could be argued that it impacts code complexity", if you mean thinking in the coding phase (as opposed to thinking when reading/inspecting the code). I'd rather say that obtaining simplicity often requires more thinking than writing complicated stuff (or requires talent and experience ). In practice we all develop some sort of "habit" such as, for instance, writing ++x instead of x++ unless needed otherwise. And we write const T & in function parameters lists with about the same instinct. My understanding was that the OP was asking for things of this sort to be added to the list. Quote: [...] One additional question I have deals with for-loops. std::vector<Object> v; // fill the vector for(unsigned i(0); i<v.size(); ++i){ //do something. } Is it likely that an optimizer could improve performance if it could determine that v.size() is unchanged during the loop, and thus eliminate calls to v.size()? Maybe. I'm sure that some compilers can do this. But not all. I don't usually look at the generated assembly, but I'm noticing that optimizers are making big leaps forward. Take for instance this: <http://preview.tinyurl.com/y9lwod> All the compilers I tried generate code with exactly the same performance (probably exactly the same code) for both versions; I wouldn't consider that change "trivial" for a non-human interpreter. ___ \|||/ Gennaro Prota - For hire (o o) https://sourceforge.net/projects/breeze/ --ooO-(_)-Ooo----- (to mail: name _ surname / yaho ! com) -- [ 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 Page 1 of 1   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.