C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Use references where you can and pointers where you must Goto page 1, 2, 3, 4, 5  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message apm Guest Posted: Wed Jan 21, 2004 7:54 pm    Post subject: Use references where you can and pointers where you must I have heard the guideline "Use references where you can and pointers where you must" many times. I always considered it to be good advice. However, I have recently encountered a view that non-const references are *evil* because you cannot easily see from the code when an argument is being modified. The person that holds this view says that Stroustrup is on his side. In the 3rd Edition page 99 Stroustrup does seem to say that non-const reference function arguments don't convey that they may be modified and in such cases the function name should clearly indicate that this is the case. This does suggest that Stroustrup might consider this to be a weakness. So is the pointer-versus-reference debate a purely religious one? Or are there strong reasons for prefer references to pointers? I am, of course, referring to functions whose arguments refer to variables that MUST be there, i.e. if a pointer were to be used then the pointer would NEVER be null. IMO this is the strong argument for using a non-const reference instead. After all, a reference can never be null. My own religion is in keeping with the guideline. But I don't know how to deal with this bit in Stroustrup that seems to argue against the case. People that hold such views and use this bit of Stroustrup as defence and argue that non-const references are used for operator function signatures (e.g. overloading << for an ostream). Regards, Andrew Marlow [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jim Melton Guest Posted: Thu Jan 22, 2004 9:02 am    Post subject: Re: Use references where you can and pointers where you must "apm" <apm35 (AT) student (DOT) open.ac.uk> wrote Quote: I have heard the guideline "Use references where you can and pointers where you must" many times. I always considered it to be good advice. However, I have recently encountered a view that non-const references are *evil* because you cannot easily see from the code when an argument is being modified. The person that holds this view says that Stroustrup is on his side. In the 3rd Edition page 99 Stroustrup does seem to say that non-const reference function arguments don't convey that they may be modified and in such cases the function name should clearly indicate that this is the case. This does suggest that Stroustrup might consider this to be a weakness. I won't debate Bjarne, and this will certainly devolve into a religious preference discussion. But... A non-const reference communicates precisely the same intent as a pointer to a non-const object. void Foo(Bar& b); // the Bar object may (and probably will) be modified void Foo(Bar* b); // same as above, as long as the pointer is not null void Foo(Bar const& b); // now the Bar object cannot be modified void Foo(Bar const* b); // same as above, and the pointer may be null There may be other reasons to denigrate non-const references the the argument that the code does not communicate lack of intent to modify is specious. -- <disclaimer> Opinions posted are those of the author. My company doesn't pay me enough to speak for them. </disclaimer> -- Jim Melton Software Architect, Fusion Programs Lockheed Martin IS&S (303) 971-3846 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Daniel Krügler (nee Spang Guest Posted: Thu Jan 22, 2004 9:16 am    Post subject: Re: Use references where you can and pointers where you must Good Morning, Andrew Marlow! apm schrieb: Quote: I have heard the guideline "Use references where you can and pointers where you must" many times. I always considered it to be good advice. However, I have recently encountered a view that non-const references are *evil* because you cannot easily see from the code when an argument is being modified. The person that holds this view says that Stroustrup is on his side. In the 3rd Edition page 99 Stroustrup does seem to say that non-const reference function arguments don't convey that they may be modified and in such cases the function name should clearly indicate that this is the case. This does suggest that Stroustrup might consider this to be a weakness. Yes, I remember that section in Stroustrup's book, but I cannot draw the same conclusion as you or your friend. Stroustrup says, that the reader can't see from the notation increment(x); whether the function argument is changed or not and contrasts this to other notations like x = next(x); or incr(&x); Then he says, that one should only use "simple" reference arguments (whatever he means with that), if the function name provides a hint, that it changes its reference argument. Quote: My own religion is in keeping with the guideline. But I don't know how to deal with this bit in Stroustrup that seems to argue against the case. People that hold such views and use this bit of Stroustrup as defence and argue that non-const references are used for operator function signatures (e.g. overloading << for an ostream). I don't see that Stroustrup does recommend the usage of pointers, he simply points to one disadvantage in the notation of calling functions with reference arguments. I usually circumvent this possible problem by using a strongly const-correct coding-style. So a function call, which is written as: const int x = 42; .... increment(42); will result in compiler errors, if increment has a mutable int reference as argument. Greetings from Bremen, Daniel [ 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: Thu Jan 22, 2004 2:48 pm    Post subject: Re: Use references where you can and pointers where you must In message <bun4kv$otj2 (AT) cui1 (DOT) lmms.lmco.com>, Jim Melton <jim.melton (AT) lmco (DOT) com> writes Quote: I won't debate Bjarne, and this will certainly devolve into a religious preference discussion. But... A non-const reference communicates precisely the same intent as a pointer to a non-const object. void Foo(Bar& b); // the Bar object may (and probably will) be modified void Foo(Bar* b); // same as above, as long as the pointer is not null void Foo(Bar const& b); // now the Bar object cannot be modified void Foo(Bar const* b); // same as above, and the pointer may be null There may be other reasons to denigrate non-const references the the argument that the code does not communicate lack of intent to modify is specious. In the days when almost all C++ programmers had originally learnt C the issue was quite important because the expectation was that if you did not have to pass a pointer as an argument then the local state of objects would not be touched by a call of a function. However, if C++ is being taught ab initio the use of pointers should (IMO) be delayed till long after the student has been using functions in a wide range of ways. The difference between pass by value and pass by reference is important as is the principle that both pass by value and pass by const reference protect local state. However we should be strongly emphasising that the onus is on the user to know if a function can change the local state in the calling environment. I.e. int i(0); foo(i); should be assumed to change i unless you have explicitly checked that it does not. If there are reasons that you want to ensure that a variable is not changed by any function call including possible latter changes to a library then adopt the 'idiom': int i(0); int const & i_ref(i); foo(i_ref); which among other things works as desired when foo() has been overloaded on the constness of its first parameter. BTW, this should be cost free in the object code. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit [ 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 Jan 23, 2004 9:55 am    Post subject: Re: Use references where you can and pointers where you must [email]apm35 (AT) student (DOT) open.ac.uk[/email] (apm) wrote in message news:<d1a33011.0401210313.12b86d29 (AT) posting (DOT) google.com>... Quote: I have heard the guideline "Use references where you can and pointers where you must" many times. I always considered it to be good advice. However, I have recently encountered a view that non-const references are *evil* because you cannot easily see from the code when an argument is being modified. The person that holds this view says that Stroustrup is on his side. In the 3rd Edition page 99 Stroustrup does seem to say that non-const reference function arguments don't convey that they may be modified and in such cases the function name should clearly indicate that this is the case. This does suggest that Stroustrup might consider this to be a weakness. So is the pointer-versus-reference debate a purely religious one? It's religious in the same way that writing your comments in French or in English is religious. There are many cases where both pointers and functions can be made to work. The choice then becomes what you, as an author, want to say to your reader. Which in turn, depends on what he will understand -- where I work now, we write comments in French, but this would have been a very bad policy where I worked before. The important point is to decide on a convention within a project, and stick to it. There are several reasonable conventions; you've just presented two. Note that while I often hear the "use references where you can and pointers where you must" point of view espoused, I've almost never seen it practiced. Most people seem to prefer pointers when doing "pointery" things. What they consider pointery varies, but for example, I know of almost no one who would use a reference in a case like: Base& obj = createObj() ; // transfers ownership... // ... delete &obj ; Generally speaking, any time there is explicit transfer of ownership, a pointer will be used. That's another convention. Quote: Or are there strong reasons for prefer references to pointers? The main reason is that a reference is guaranteed to be non-null. Quote: I am, of course, referring to functions whose arguments refer to variables that MUST be there, i.e. if a pointer were to be used then the pointer would NEVER be null. IMO this is the strong argument for using a non-const reference instead. After all, a reference can never be null. There are at least three issues to be considered: - Can the pointer be null? - Is there transfer of ownership, i.e. is the called function responsible for deleting the objct? - Must the lifetime of the object extend beyond the return from the function? There are probably others. Obviously, if a null pointer is a valid value, then you pass a pointer. For the other two, it is a question of convention. Quote: My own religion is in keeping with the guideline. But I don't know how to deal with this bit in Stroustrup that seems to argue against the case. People that hold such views and use this bit of Stroustrup as defense and argue that non-const references are used for operator function signatures (e.g. overloading << for an ostream). In the case of operator<<, most of the conventions I've seen would require a reference. Null pointers are not allowed, there is no transfer of ownership, and the function doesn't save the address for later use. The only possible convention which would use a pointer here would be that a pointer is used in all cases in which the pointed to object will be modified. Also a reasonable convention, but judging from my experience, not a very frequent one. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top John Potter Guest Posted: Fri Jan 23, 2004 9:57 am    Post subject: Re: Use references where you can and pointers where you must On 22 Jan 2004 04:02:46 -0500, Jim Melton <jim.melton (AT) lmco (DOT) com> wrote: Quote: "apm" <apm35 (AT) student (DOT) open.ac.uk> wrote in message news:d1a33011.0401210313.12b86d29 (AT) posting (DOT) google.com... I have heard the guideline "Use references where you can and pointers where you must" many times. I always considered it to be good advice. However, I have recently encountered a view that non-const references are *evil* because you cannot easily see from the code when an argument is being modified. The person that holds this view says that Stroustrup is on his side. In the 3rd Edition page 99 Stroustrup does seem to say that non-const reference function arguments don't convey that they may be modified and in such cases the function name should clearly indicate that this is the case. This does suggest that Stroustrup might consider this to be a weakness. I won't debate Bjarne, and this will certainly devolve into a religious preference discussion. But... Very likely. You do need to understand the policy though. Quote: A non-const reference communicates precisely the same intent as a pointer to a non-const object. Not at the end which is important to the policy that you refute. Quote: void Foo(Bar& b); // the Bar object may (and probably will) be modified void Foo(Bar* b); // same as above, as long as the pointer is not null void Foo(Bar const& b); // now the Bar object cannot be modified void Foo(Bar const* b); // same as above, and the pointer may be null You left out one other. void Foo (Bar b); // The caller's object will not be modified. Quote: There may be other reasons to denigrate non-const references the the argument that the code does not communicate lack of intent to modify is specious. Now to understand the argument. void Bunk () { Bar b; Foo(b); // Foo does not modify b Foo(&b); // Foo modifies b } It is obvious from the call site because only three of the five possible forms are ever used by "good" programmers. Never use a const* or a non-const& and the invocation site will indicate whether the function modifies the argument or not. Exceptions allowed for well named functions. FooThatModifiesItsBar (Bar&); I make no claim to agree with the policy, but it must be understood to present a meaningful disagreement. John [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top George van den Driessche Guest Posted: Fri Jan 23, 2004 2:43 pm    Post subject: Re: Use references where you can and pointers where you must "apm" <apm35 (AT) student (DOT) open.ac.uk> wrote Quote: So is the pointer-versus-reference debate a purely religious one? Or are there strong reasons for prefer references to pointers? I would say the opposite - templates. A template can be coded to compile regardless of whether its parameter's member is a reference or a value, whereas a pointer will break that. class Bar { public: void drink(); }; class X { public: Bar& bar; }; class Y { public: Bar bar; }; // This function works with both X and Y, which would // not be true if X::bar were a pointer. template< class T > void foo( T& t ) { t.findABar().drink(); }; I'm sure someone can come up with a less contrived example than this, but my point remains: because reference syntax is the same as object syntax, templates work better with them. George [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top apm Guest Posted: Fri Jan 23, 2004 2:45 pm    Post subject: Re: Use references where you can and pointers where you must Francis Glassborow <francis (AT) robinton (DOT) demon.co.uk> wrote Quote: In the days when almost all C++ programmers had originally learnt C the issue was quite important because the expectation was that if you did not have to pass a pointer as an argument then the local state of objects would not be touched by a call of a function. Indeed. I find that people that hold the view that ptrs are better than non-const references tend to code their C++ in a C style and have a strong background in C. Quote: However, if C++ is being taught ab initio the use of pointers should (IMO) be delayed till long after the student has been using functions in a wide range of ways. The difference between pass by value and pass by reference is important as is the principle that both pass by value and pass by const reference protect local state. Well put. Quote: However we should be strongly emphasising that the onus is on the user to know if a function can change the local state in the calling environment. I.e. int i(0); foo(i); should be assumed to change i unless you have explicitly checked that it does not. I find this really helpful. Thanks. -Andrew M. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Kevin Cline Guest Posted: Fri Jan 23, 2004 2:47 pm    Post subject: Re: Use references where you can and pointers where you must [email]apm35 (AT) student (DOT) open.ac.uk[/email] (apm) wrote in message news:<d1a33011.0401210313.12b86d29 (AT) posting (DOT) google.com>... Quote: My own religion is in keeping with the guideline. But I don't know how to deal with this bit in Stroustrup that seems to argue against the case. People that hold such views and use this bit of Stroustrup as defence and argue that non-const references are used for operator function signatures (e.g. overloading << for an ostream). Generally you want to avoid functions that modify arguments, but it's not always convenient. If there is an output argument, the function's reason for being should be to do that modification, and the function name should make the action of the function clear, e.g. add_tax_to_order(order, deliveryState); I think that most English-speaking programmers would fully expect a function named "add_tax_to_order" to modify the order argument. Functions that modify arguments should almost always return void. You don't want to modify arguments as a side effect of computing something else. This sort of thing makes me crazy: double delivery_charge(Order& order) // compute the delivery charge, // and submit the order The code (not the comments) should indicate clearly what the code does. If it doesn't, then rename things or move code until it does. [ 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 Jan 23, 2004 2:55 pm    Post subject: Re: Use references where you can and pointers where you must [email]jim.melton (AT) lmco (DOT) com[/email] (Jim Melton) wrote (abridged): Quote: A non-const reference communicates precisely the same intent as a pointer to a non-const object. Not if there are local conventions which state otherwise. The issue is whether such conventions are a good idea. -- 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 Alexander J. Oss Guest Posted: Fri Jan 23, 2004 3:22 pm    Post subject: Re: Use references where you can and pointers where you must "Francis Glassborow" <francis (AT) robinton (DOT) demon.co.uk> wrote Quote: However, if C++ is being taught ab initio the use of pointers should (IMO) be delayed till long after the student has been using functions in a wide range of ways. The difference between pass by value and pass by reference is important as is the principle that both pass by value and pass by const reference protect local state. IMO, this should be "use references where you can, otherwise use smart pointers where you can, otherwise use pointers". With the advent of my own smart pointer long ago and its vastly superior replacement boost::shared_ptr, I haven't had to use a raw pointer *at all* in my code except for "legacy" API use. Typically, objects are allocated off the heap and saved into a smart pointer, and then references to the dereferenced smart pointer get passed down (up?) the stack to the rest of the application. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Attila Feher Guest Posted: Sat Jan 24, 2004 1:02 pm    Post subject: Re: Use references where you can and pointers where you must Francis Glassborow wrote: [SNIP] Quote: variable is not changed by any function call including possible latter changes to a library then adopt the 'idiom': int i(0); int const & i_ref(i); foo(i_ref); which among other things works as desired when foo() has been overloaded on the constness of its first parameter. BTW, this should be cost free in the object code. Could this be done in some way using a constructor-cast and an unnamed temporary? Can this temporary be a const ref, so that we ensure no copying will take place? Possibly stupid questions, my mind is on hold. I was thinking about sth like this: int i(0); foo((int const &)(i)); -- Attila aka WW [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jim Melton Guest Posted: Sat Jan 24, 2004 2:48 pm    Post subject: Re: Use references where you can and pointers where you must "John Potter" <jpotter (AT) falcon (DOT) lhup.edu> wrote Quote: On 22 Jan 2004 04:02:46 -0500, Jim Melton <jim.melton (AT) lmco (DOT) com> wrote: "apm" <apm35 (AT) student (DOT) open.ac.uk> wrote in message news:d1a33011.0401210313.12b86d29 (AT) posting (DOT) google.com... I have heard the guideline "Use references where you can and pointers where you must" many times. I always considered it to be good advice. However, I have recently encountered a view that non-const references are *evil* because you cannot easily see from the code when an argument is being modified. The person that holds this view says that Stroustrup is on his side. In the 3rd Edition page 99 Stroustrup does seem to say that non-const reference function arguments don't convey that they may be modified and in such cases the function name should clearly indicate that this is the case. This does suggest that Stroustrup might consider this to be a weakness. I won't debate Bjarne, and this will certainly devolve into a religious preference discussion. But... Very likely. You do need to understand the policy though. A non-const reference communicates precisely the same intent as a pointer to a non-const object. Not at the end which is important to the policy that you refute. I don't understand this statement. Which end? Quote: You left out one other. void Foo (Bar b); // The caller's object will not be modified. True, but since the topic was pointer vs. reference, I didn't think the call-by-value case was relevant. Quote: There may be other reasons to denigrate non-const references the the argument that the code does not communicate lack of intent to modify is specious. Now to understand the argument. void Bunk () { Bar b; Foo(b); // Foo does not modify b Foo(&b); // Foo modifies b } Your comments do not follow. Only by knowing Foo's signature can any assertion about the state of b be made. The call to Foo(&b) may very well be a function with a strong C legacy that passes by pointer. Quote: It is obvious from the call site because only three of the five possible forms are ever used by "good" programmers. Never use a const* or a non-const& and the invocation site will indicate whether the function modifies the argument or not. Exceptions allowed for well named functions. So you disallow functions that take string literals? void Foo(char const*); Foo("Some string"); Quote: I make no claim to agree with the policy, but it must be understood to present a meaningful disagreement. My point was not to challenge the policy, just the statement given in its defense: that non-const references are *evil* because you cannot easily see from the code when an argument is being modified. If you restrict the language to remove non-const references and const pointers, then you can make that statement, but there is nothing inherent in the definition of references or pointers, other than constness, that communicates whether an object can or will be modified. Note that just because an object *can* be modified doesn't mean it *will* be modified. The right solution is to be brutally const-correct and let the compiler tell you when you have tried to modify an object you shouldn't have. There! Now I've gone and made a religious stand. -- <disclaimer> Opinions posted are those of the author. My company doesn't pay me enough to speak for them. </disclaimer> -- Jim Melton Software Architect, Fusion Programs Lockheed Martin IS&S (303) 971-3846 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Keith H Duggar Guest Posted: Sat Jan 24, 2004 9:37 pm    Post subject: Re: Use references where you can and pointers where you must John Potter correctly outlined Stroustrup's point. Using non-const references does add ambiguity and removes some clarity from the perspective of client code. In my experience this has been especially important in coding projects involving multiple programmers, projects that have long shelf lives, and large projects whether single or multiple coders are involved. As in any writing, our goal should be to make code as clear, obvious, and foolproof as possible while meeting any design goals we have set. In this case forcing the client code to be written as: void foo ( & bar ) ; instead of : void foo ( bar ) ; helps to insure that future readers of the code recognize immediately that bar is being modified by foo. I found this especially helpful when debugging and when passing the code off to less experience programmers such as summer interns or UROP's. The latter were able to learn and understand the code more quickly when changes to arguments were clearly documented using this convention. I find apm's comment : Quote: I am, of course, referring to functions whose arguments refer to variables that MUST be there, i.e. if a pointer were to be used then the pointer would NEVER be null. IMO this is the strong argument for using a non-const reference instead. After all, a reference can never be null. very interesting though not compelling. I say that because using the convention : void foo ( & bar ) ; insures that the pointer is not null since you are taking the address of an existing object. Code such as this : bar * barptr = 0 ; // ... code that should set barptr void foo ( barptr ) ; is already risky and it's best to avoid these naked pointers except in isolated instances; smart pointers would be much better as Alexander pointed out. So it seems to me that there is no practical gain whatever to replacing the pointer with a reference. George just posted an example he claimed demonstrated an advantage for templates but his example honestly makes no sense to me. We are talking about arguments to functions not member variable syntax. Not to mention, I don't see a findABar function declared anywhere that would elucidate his point. Perhaps someone can clarify his intent for me or give another example where a non-const ref has advantages over a pointer? I agree with John and Kevin that exceptions should be well commented and the function name should clearly indicate that the object is being modified. However, having taught C++ myself several times, I agree with Francis that from a teaching perspective it is better to delay the introduction to points for a while. Though, it was rather easy for me to develop a curriculum that avoided pointers while also avoiding non-const references until they were ready to handle pointers. By the way, this comment : Quote: Indeed. I find that people that hold the view that ptrs are better than non-const references tend to code their C++ in a C style and have a strong background in C. is "religious" non-sense. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top apm Guest Posted: Sat Jan 24, 2004 9:38 pm    Post subject: Re: Use references where you can and pointers where you must [email]kanze (AT) gabi-soft (DOT) fr[/email] wrote in message news:<d6652001.0401220504.10ce9510 (AT) posting (DOT) google.com>... Quote: So is the pointer-versus-reference debate a purely religious one? It's religious in the same way that writing your comments in French or in English is religious. There are many cases where both pointers and functions can be made to work. The choice then becomes what you, as an author, want to say to your reader. The pointer view argues that they want to convey to the reader when a function argument is modifyable. Quote: Note that while I often hear the "use references where you can and pointers where you must" point of view espoused, I've almost never seen it practiced. Most people seem to prefer pointers when doing "pointery" things. What they consider pointery varies, but for example, I know of almost no one who would use a reference in a case like: Base& obj = createObj() ; // transfers ownership... Not applicable: I was talking about function arguments. Quote: The main reason is that a reference is guaranteed to be non-null. Indeed. This seems the strongest argument to me. Quote: There are at least three issues to be considered: - Can the pointer be null? - Is there transfer of ownership, i.e. is the called function responsible for deleting the objct? - Must the lifetime of the object extend beyond the return from the function? There are probably others. Obviously, if a null pointer is a valid value, then you pass a pointer. For the other two, it is a question of convention. My own religion is in keeping with the guideline. But I don't know how to deal with this bit in Stroustrup that seems to argue against the case. People that hold such views and use this bit of Stroustrup as defense and argue that non-const references are used for operator function signatures (e.g. overloading << for an ostream). In the case of operator<<, most of the conventions I've seen would require a reference. I'm not talking about operators; Stroustrup says on page 99 that a significant use of refernces is to better support operator overloading. I was talking about non-const reference arguments to functions. [ 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, 3, 4, 5  Next Page 1 of 5   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.