C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Can elements of STL sequence containers be updated on the f          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message kc_heaser@yahoo.com Guest Posted: Sat Jul 30, 2005 10:15 am    Post subject: Can elements of STL sequence containers be updated on the f Surely a trivial question, but not when you're a newbie and you've been staring a STL Tutorials online for the last several hours. for (list<Unit *>::iterator i = wCompIter->transitoryObjects.begin(); i != wCompIter->transitoryObjects.end(); i++) { Unit *u = *i; u->canIndex = 27 // some new value } The above compiles and runs but the new canIndex never seems to be retained between occurrences of the code. I'm I not doing the right, or is this something that STL doesn't support. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Thomas Maeder Guest Posted: Sun Jul 31, 2005 1:14 am    Post subject: Re: Can elements of STL sequence containers be updated on t [email]kc_heaser (AT) yahoo (DOT) com[/email] writes: Quote: for (list<Unit *>::iterator i = wCompIter->transitoryObjects.begin(); i != wCompIter->transitoryObjects.end(); i++) { Unit *u = *i; u->canIndex = 27 // some new value } The above compiles and runs but the new canIndex never seems to be retained between occurrences of the code. I'm I not doing the right, or is this something that STL doesn't support. Please post a complete, minimal (<50 lines) programs that also shows how you come to the conclusion that "the new canIndex never seems to be retained". [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top White Wolf Guest Posted: Sun Jul 31, 2005 1:28 am    Post subject: Re: Can elements of STL sequence containers be updated on t [email]kc_heaser (AT) yahoo (DOT) com[/email] wrote: Quote: Surely a trivial question, but not when you're a newbie and you've been staring a STL Tutorials online for the last several hours. for (list<Unit *>::iterator i = wCompIter->transitoryObjects.begin(); i != wCompIter->transitoryObjects.end(); i++) ++i Quote: { Unit *u = *i; u->canIndex = 27 // some new value } The above compiles and runs but the new canIndex never seems to be retained between occurrences of the code. I'm I not doing the right, or is this something that STL doesn't support. It may be the late hour, but I see nothing more wrong with the code above. (Except the question why does it hold pointers.) Are you sure you are not passing your list by copy (instead of by reference) to the function, which contains the above loop? -- WW aka Attila ::: Only dead fish go with the flow. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Carlos Moreno Guest Posted: Sun Jul 31, 2005 11:48 am    Post subject: Re: Can elements of STL sequence containers be updated on t White Wolf wrote: Quote: Are you sure you are not passing your list by copy (instead of by reference) to the function, which contains the above loop? Even then, the code should work -- a *shallow* copy is made, and the pointer values in the list inside the function are the same. The changes should reflect in the original list. My guess is that he did something else wrong, or the fragment of code that he uses to verify the results is the one that is wrong. You didn't explain to him why he should use ++i instead of i++. For the OP, it's not just a matter of style. When dealing with iterators, one should always favor pre-increment over post-increment. The way operator++ are implemented, the post-increment form returns by value, and thus you have an unnecessary inefficiency (that I guess the compiler would have a very hard time optimizing away). The pre-increment form returns by reference, and so optimizing that away is quite trivial. Carlos -- [ 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: Mon Aug 01, 2005 10:27 am    Post subject: Re: Can elements of STL sequence containers be updated on th Carlos Moreno wrote: Quote: White Wolf wrote: Are you sure you are not passing your list by copy (instead of by reference) to the function, which contains the above loop? Even then, the code should work -- a *shallow* copy is made, and the pointer values in the list inside the function are the same. The changes should reflect in the original list. In the elements pointed to by the original list, you mean of course. I think that's your point: he doesn't make any changes in the list at all. Quote: My guess is that he did something else wrong, or the fragment of code that he uses to verify the results is the one that is wrong. You didn't explain to him why he should use ++i instead of i++. Probably becuase there is no real valid reason. It's one of those things that people do because "Herb Sutter said so", or whatever. It just happens that this time, Herb forgot to do his measurements. Quote: For the OP, it's not just a matter of style. When dealing with iterators, one should always favor pre-increment over post-increment. The way operator++ are implemented, the post-increment form returns by value, and thus you have an unnecessary inefficiency (that I guess the compiler would have a very hard time optimizing away). Measurements? My measurements show that for all of the iterators in the standard containers (including reverse iterators), there is no measurable difference using g++. The only way there can be a measurable difference is if copying of an iterator is relatively expensive, and the compiler cannot optimize it. The STL copies iterators like crazy, however, so if copying an iterator is relatively expensive, you will have performance problems regardless of which form you use. I've nothing against preferring pre-increment on a green fields project, on the grounds that it it will never result in worse performance (which I suspect is true -- barring operator overload abuse). But the point is hardly worth mentionning in general. -- 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 Carlos Moreno Guest Posted: Mon Aug 01, 2005 6:08 pm    Post subject: Re: Can elements of STL sequence containers be updated on th [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote: Quote: For the OP, it's not just a matter of style. When dealing with iterators, one should always favor pre-increment over post-increment. The way operator++ are implemented, the post-increment form returns by value, and thus you have an unnecessary inefficiency (that I guess the compiler would have a very hard time optimizing away). Measurements? My measurements show that for all of the iterators in the standard containers (including reverse iterators), there is no measurable difference using g++. Hmmm, not to doubt your technical abilities, but I would like to see those measurements. I'm suspecting that you may not be measuring the real difference, but the overall effect of the difference in a program that otherwise does lots of other stuff; in your defense (if that is the case), that's what matters anyway... But still, see my argument below. Quote: The only way there can be a measurable difference is if copying of an iterator is relatively expensive, and the compiler cannot optimize it. The STL copies iterators like crazy, however, so if copying an iterator is relatively expensive, you will have performance problems regardless of which form you use. The way I see it, it's more like we *know* that there is (or at least there is the potential for) an up-front inefficiency that is otherwise gratuitous -- we don't have any advantage whatsoever in using post-increment (other than the subjective "it looks nicer", which many -- not all -- people subscribe to; but that's not a strong advantage); so, why put up with any, however minimal, gratuitous disadvantage if we have an alternative that is exactly the same from all other points of view? Notice that it's dfefinitely not premature optimization! It's not like we're obsessed and turning our code into a monster, a tricky-code-o-rama just to gain a few nanoseconds. No. We're not sacrificing anything. We're not spending any extra effort. We're not paying any price whatsoever, so why not go for it as a regular and even strict habit? Perhaps that's exactly what you meant (only with fewer words ) with your next paragraph? Quote: I've nothing against preferring pre-increment on a green fields project, on the grounds that it it will never result in worse performance (which I suspect is true -- barring operator overload abuse). But the point is hardly worth mentionning in general. Cheers, Carlos -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Allan W Guest Posted: Tue Aug 02, 2005 10:22 am    Post subject: Re: Can elements of STL sequence containers be updated on th [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote: Quote: I've nothing against preferring pre-increment on a green fields project, on the grounds that it it will never result in worse performance (which I suspect is true -- barring operator overload abuse). That's exactly what I teach. My class USES operator++ long before they study operator overloading, of course. So it wouldn't do to get too technical about what the difference really is. What I teach is: If you're using operator ++ or -- and NOT using the result of the operation, use the prefix form. It's never slower. Eventually you'll find a situation where it is faster; until then, just consider it a "good habit." Quote: But the point is hardly worth mentionning in general. It's hardly worth ignoring either. There are some rules-of-thumb we can use without thinking about them, but not if we never heard them. (Like: Never expect floating-point values to be exact. foo==1.0 might never be true if foo is calculated. Or like: use preincrement unless there's some reason to prefer postincrement.) [ 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: Tue Aug 02, 2005 12:55 pm    Post subject: Re: Can elements of STL sequence containers be updated on th Carlos Moreno wrote: Quote: kanze (AT) gabi-soft (DOT) fr wrote: For the OP, it's not just a matter of style. When dealing with iterators, one should always favor pre-increment over post-increment. The way operator++ are implemented, the post-increment form returns by value, and thus you have an unnecessary inefficiency (that I guess the compiler would have a very hard time optimizing away). Measurements? My measurements show that for all of the iterators in the standard containers (including reverse iterators), there is no measurable difference using g++. Hmmm, not to doubt your technical abilities, but I would like to see those measurements. They used to be online. Since my last move, I've not got my site back up, so they're not available at present, but one of these days... Quote: I'm suspecting that you may not be measuring the real difference, but the overall effect of the difference in a program that otherwise does lots of other stuff; in your defense (if that is the case), that's what matters anyway... I used a fairly carefully designed benchmark harness, which attempts to isolate what is measured to a maximum. Still, I've noticed in the past that the harness does seem to introduce a bit of jitter, and the measurements were made on a production machine, where a number of other processes were active. The measurements were made on a Sparc; I've noticed in the past a lot of variance in a Sparc depending on things which apparently have nothing to do with what I am measuring (stack alignment, etc.). Repeated measurements showed no differences greater than the jitter in my test harness. I'm not saying that there was no difference, but that in all cases, the difference was small enough that my test rig couldn't measure it accurately. It's interesting to note that using the same rig to measure caching end() vs. calling end() each time in the loop found a very significant difference. Quote: But still, see my argument below. The only way there can be a measurable difference is if copying of an iterator is relatively expensive, and the compiler cannot optimize it. The STL copies iterators like crazy, however, so if copying an iterator is relatively expensive, you will have performance problems regardless of which form you use. The way I see it, it's more like we *know* that there is (or at least there is the potential for) an up-front inefficiency that is otherwise gratuitous -- we don't have any advantage whatsoever in using post-increment (other than the subjective "it looks nicer", which many -- not all -- people subscribe to; but that's not a strong advantage); so, why put up with any, however minimal, gratuitous disadvantage if we have an alternative that is exactly the same from all other points of view? There is a sometimes very strong objective (not subjective) advantage in post-incrementation: it's coherent with what all of your existing code does. If you value coherence, switching to pre-incrementation means modifying all of your existing code. A very expensive proposition, for no proven gain. Quote: Notice that it's dfefinitely not premature optimization! It's not like we're obsessed and turning our code into a monster, a tricky-code-o-rama just to gain a few nanoseconds. No. We're not sacrificing anything. We're not spending any extra effort. We're not paying any price whatsoever, so why not go for it as a regular and even strict habit? Perhaps that's exactly what you meant (only with fewer words ) with your next paragraph? More or less. Quote: I've nothing against preferring pre-increment on a green fields project, on the grounds that it it will never result in worse performance (which I suspect is true -- barring operator overload abuse). But the point is hardly worth mentionning in general. There are really two points: the first is simple, if you have existing code which uses post-incrementation, the switch is not free. It costs real money. Spending real money without concrete, measurable benefits just doesn't make good business sense. The second is in conjunction with your comment that "[He] didn't explain to him why he should use ++i". Your comment said that "one should always favor pre-increment over post-increment." That's an oversimplification. To the point that it is wrong -- if you have a large body of existing code using post-increment, for example. The real problem, of course, is that all the ink and electrons being used to tell people to use pre-incrementation is ink and electrons not being used to tell people e.g. to use RAII, or other important things. Given the emphises which it is being given, I also fear that it will lead people to use pre-incrementation when it would be incorrect -- when the results of the expression are used, and the results must be the value before incrementation. -- 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 Carlos Moreno Guest Posted: Tue Aug 02, 2005 8:33 pm    Post subject: Re: Can elements of STL sequence containers be updated on th [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote: Quote: There are really two points: the first is simple, if you have existing code which uses post-incrementation, the switch is not free. It costs real money. Oh, of course!! Existing code is a completely different beast, and I was implicitly disregarding that particular case. Quote: The second is in conjunction with your comment that "[He] didn't explain to him why he should use ++i". Your comment said that "one should always favor pre-increment over post-increment." That's an oversimplification. To keep things in perspective (), notice that he simply quoted the for loop, and then wrote ++i. That was far more grave than an oversimplification -- it sounded to me like he was correcting a mistake, as if i++ were incorrect and HAD to be replaced with ++i. I put the explanation of why preferring ++i over i++ in that case; it is up to each person to choose -- certainly your argument has the validity that, without your comments, it would be an uninformed decision (arguably, at least -- we're still waiting for your benchmarks ) Quote: To the point that it is wrong -- if you have a large body of existing code using post-increment, for example. Yes -- but as I said, I was implicitly putting aside the case of existing code. Quote: The real problem, of course, is that all the ink and electrons being used to tell people to use pre-incrementation is ink and electrons not being used to tell people e.g. to use RAII, or other important things. I guess this is simple enough (it's a clear cut, objective and directly observable thing that *anyone*, no matter how competent or incompetent, can understand), and it is easy to state (like, pass strings by const & instead of by value -- well, or most UDT's for that matter) Quote: Given the emphises which it is being given, I also fear that it will lead people to use pre-incrementation when it would be incorrect -- when the results of the expression are used, and the results must be the value before incrementation. I don't think it will get to that extreme. A programmer would have to be severely incompetent for that -- unless you mean that so much using ++i could lead to oversights, to one's fingers "automatically" typing ++i out of habit even if one is thinking i++? Still, in the pre-iterators era (when I used the post- increment form *always* for this sort of situations), I would never make the mistake of typing i++ when I *needed* the pre- increment form, ++i. I don't see why the opposite mistake would be made as a result of this "over-advice" regarding iterators. Carlos -- [ 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: Wed Aug 03, 2005 1:12 pm    Post subject: Re: Can elements of STL sequence containers be updated on th Allan W wrote: Quote: kanze (AT) gabi-soft (DOT) fr wrote: I've nothing against preferring pre-increment on a green fields project, on the grounds that it it will never result in worse performance (which I suspect is true -- barring operator overload abuse). That's exactly what I teach. My class USES operator++ long before they study operator overloading, of course. So it wouldn't do to get too technical about what the difference really is. What I teach is: If you're using operator ++ or -- and NOT using the result of the operation, use the prefix form. It's never slower. Eventually you'll find a situation where it is faster; until then, just consider it a "good habit." In the case of beginners, I wouldn't say anything. My examples would happen to use prefix, but that seems enough, unless someone specifically asks. Quote: But the point is hardly worth mentionning in general. It's hardly worth ignoring either. Part of my point is that it can generally be ignored. At least if my measurements using g++ are correct. Quote: There are some rules-of-thumb we can use without thinking about them, but not if we never heard them. The problem is that you can't really use this one without thinking about it. You have to consider the cost of inconsistancy or the cost of updating existing code. Quote: (Like: Never expect floating-point values to be exact. Not necessarily a good rule of thumb either. In fact, floating-point values are always exact. Floating-point arithmetic is precisely defined -- in some ways, even more so that real number arithmetic, and certainly more so that most of the input you're likely to get. The problem is that machine floating point can be a faulty abstraction for real numbers. But it's the abstraction which fails, not machine floating point. Quote: foo==1.0 might never be true if foo is calculated. But that's true for integral arithmetic too. With regards to floating point arithmetic, the only real rule of thumb that I would suggest is: don't use floating point unless you know what you are doing. Where "know what you are doing" means that you are aware of the differences between floating point arithmetic and real arithmetic, and know how to cope with them. (I could say the same thing about machine integral arithmetic and integers. Coping with the differences is a lot, lot easier than for floating point and real, but you still have to do it.) Quote: Or like: use preincrement unless there's some reason to prefer postincrement.) I'd settle for example. If you look at any large quantity of C code, you'll find that post-increment prevails. Overwehlmingly. Not because anyone ever presented a rule of thumb. But because Kernighan and Richie used post-increment in their book. As far as rules go, I would say that if you're teaching C++, you should use pre-increment in your examples. If you're specifying a coding guideline for a green fields project, I'd favor pre-incrementation as well (but very few people will ever find themselves in such a circumstance). More generally, however, the only valid rule of thumb would be: do whatever the other people on the project do. -- 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 Martin Bonner Guest Posted: Wed Aug 03, 2005 1:14 pm    Post subject: Re: Can elements of STL sequence containers be updated on th Carlos Moreno wrote: Quote: kanze (AT) gabi-soft (DOT) fr wrote: Given the emphasis which it is being given, I also fear that it will lead people to use pre-incrementation when it would be incorrect -- when the results of the expression are used, and the results must be the value before before before incrementation. I don't think it will get to that extreme. [snip] in the pre-iterators era (when I used the post- increment form *always* for this sort of situations), I would never make the mistake of typing i++ when I *needed* the pre- increment form, ++i. I don't see why the opposite mistake would be made as a result of this "over-advice" regarding iterators. I don't think James is worrying about /you/ making that mistake . It's the less experienced/competent programmers that might make it. -- MJB [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Carlos Moreno Guest Posted: Wed Aug 03, 2005 2:32 pm    Post subject: Re: Can elements of STL sequence containers be updated on th Martin Bonner wrote: Quote: Carlos Moreno wrote: [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote: Given the emphasis which it is being given, I also fear that it will lead people to use pre-incrementation when it would be incorrect -- when the results of the expression are used, and the results must be the value before before before incrementation. I don't think it will get to that extreme. [snip] in the pre-iterators era (when I used the post- increment form *always* for this sort of situations), I would never make the mistake of typing i++ when I *needed* the pre- increment form, ++i. I don't see why the opposite mistake would be made as a result of this "over-advice" regarding iterators. I don't think James is worrying about /you/ making that mistake . Why thanks for the subtle compliment :-) Quote: It's the less experienced/competent programmers that might make it. Still; the less experienced programmers do struggle with the distinction between the two forms -- in the general case. After all, in a regular for loop (with an int control variable), you have to put one or the other, and the beginner tends to wonder which one to choose, and whether one of them is correct and the other isn't. At that point, you have to explain to them that in that particular case, it makes no difference. That in turn -- following James' reasoning/concern -- should get us worried, because they might think that in the general case, they can always use either one with the same effect. My point is: you want to teach beginners that in a for loop with iterators, they should prefer ++i over i++ (with ot without an explanation -- perhaps without an explanation would be better, if we're really talking about beginners). For the other cases, well, you would have to explain the issue more in detail. Carlos -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Wed Aug 03, 2005 6:36 pm    Post subject: Re: Can elements of STL sequence containers be updated on th In article <C_3Ie.64650$Dw5.1275534 (AT) weber (DOT) videotron.net>, Carlos Moreno <moreno_at_mochima_dot_com (AT) xx (DOT) xxx> writes Quote: My point is: you want to teach beginners that in a for loop with iterators, they should prefer ++i over i++ (with ot without an explanation -- perhaps without an explanation would be better, if we're really talking about beginners). For the other cases, well, you would have to explain the issue more in detail. Well you are going to have to tell them something as soon as they look at some legacy code (which the keen ones will do pretty soon by browsing the web.) -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Carlos Moreno Guest Posted: Wed Aug 03, 2005 10:36 pm    Post subject: Re: Can elements of STL sequence containers be updated on th Francis Glassborow wrote: Quote: In article <C_3Ie.64650$Dw5.1275534 (AT) weber (DOT) videotron.net>, Carlos Moreno [email]moreno_at_mochima_dot_com (AT) xx (DOT) xxx[/email]> writes My point is: you want to teach beginners that in a for loop with iterators, they should prefer ++i over i++ (with ot without an explanation -- perhaps without an explanation would be better, if we're really talking about beginners). For the other cases, well, you would have to explain the issue more in detail. Well you are going to have to tell them something as soon as they look at some legacy code (which the keen ones will do pretty soon by browsing the web.) Surely, at some point they will have to *fully* understand the issue, and be perfectly clear on when to use one or the other one, and whether or not it makes a difference (and what kind of a difference, if any) in a given situation. Following Martin's remark, I wouldn't worry too much about the keen ones; they will ask me (when they see it in some code they found on the web), and they will most likely understand and be perfectly happy with the not-so-complicated explanation about the difference. But keep in mind where the discussion started: James' comment about being concerned that the excessive and obsessive advice of using ++i instead of i++ with iterators might lead to people then using the pre-incr. form in a situation that requires the post-increment form, to which Martin commented that this concern would be mostly applicable to beginners, and not to people with some experience. This is what my reply was focused on. Carlos -- [ 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: Thu Aug 04, 2005 12:28 pm    Post subject: Re: Can elements of STL sequence containers be updated on th Francis Glassborow wrote: Quote: In article <C_3Ie.64650$Dw5.1275534 (AT) weber (DOT) videotron.net>, Carlos Moreno [email]moreno_at_mochima_dot_com (AT) xx (DOT) xxx[/email]> writes My point is: you want to teach beginners that in a for loop with iterators, they should prefer ++i over i++ (with ot without an explanation -- perhaps without an explanation would be better, if we're really talking about beginners). For the other cases, well, you would have to explain the issue more in detail. Well you are going to have to tell them something as soon as they look at some legacy code (which the keen ones will do pretty soon by browsing the web.) You tell them that both work, but that coherence is good, so you should settle on one or the other in any given set of code. And that in the code they do for the course, the choice is pre-increment. If they want more, I'd say that most C experts prefer post-increment, and most C++ experts prefer pre-increment. I would definitly *not* get into the details of why in certain cases one might be faster than the other, or at least not slower. In a course for relative beginners, of course. -- 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 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.