Talk:C++ Programming/Code/Statements/Functions

In general, this page needs more hyperlinks (terms like method and such can be easily hyperlinked).

Also, the code snippets describing the two methods of return codes are badly formatted, and the first one is actually wrong in that it doesn't use the "Positive Means Success" paradigm. And the statement leading into it, "The major problem of this construct is that it creates more imbrication", I believe is incorrect (and the word imbrication, which means "overlap", is obscure and should be altered). A better way of stating it would be "The major problem with the construct is that it only provides a single error code ("Negative" or 0) when there could be many possible reasons why a function would return an error.

There was a later sentence that again used "imbrication" which seemed non-sensical to me.

I don't have time to make the edits right now, but I should be able to write something up in a week or so, unless there are objections, or someone else does it.

Admiralh - July 3, 2007

Please: do not change this page to state that arrays are pointers in C++; they are not, in all sorts of vital ways. It's true that in the context of an array argument declaration the syntax allows pointer parameters to be declared as if they were arrays, but arrays are not pointers in C++ (ever), and pointers are not arrays (except in that any object can be treated as an array of length 1, such as when taking a (&obj)+1 ).

I guess someone should go and hunt down any other occurrences of this error. Volunteers?

I've also tried to use the term "parameter" where appropriate, to distinguish the parameters declared for a function with the arguments passed by a caller. (Parameters are sometimes called "formal arguments", to distinguish them from "actual arguments".) —The preceding unsigned comment was added by James Dennett (talk • contribs).

Panic (or anyone else): if there is a specific change that you object to, please state why, and what the objection is. I don't see any examples above. If I do make an error (for example, write something that is nonsensical), I'm happy to have it pointed out. But please, do make specific points. I try to note when I'm correcting specific errors. For example, many people are confused because they don't understand the difference between the parameters (aka formal arguments) that appear in a function declaration and the actual arguments that are passed to it; understanding that distinction removes many other confusions.

The C++ standard is one source of the term "parameter" for this use (see e.g., [dcl.fct.def], preferring mnemonic references while the standard is being revised). [expr.call] uses the term "arguments" for the expressions used in a function call expression. Sticking to the terminology used by the C++ standard, where possible, ensures consistency and helps people to adapt to C++ instead of being confused by more general Computer Science terminology or terms from other languages.

"Methods" certainly are significant in Smalltalk, but don't correspond exactly to C++'s member functions. A Smalltalk method is the piece of code invoked as a result of message passing. Smalltalk doesn't have non-virtual methods, and indeed its dispatch mechanism is much more flexible than that of C++. (Smalltalk doesn't use the term virtual, of course, nor does it need to. All dispatch uses late binding in Smalltalk.)  C++ has member functions, data members (aka member variables, including static and non-static member variables), member templates, and so on. Indeed, the section of the standard introducing member functions is called "Member Functions" (mnemonic: "class.mfct"), and none of the 8 occurrences I find of the term "method" in the 2003 C++ standard uses the term in the sense of a kind of function.

Let's try to have a constructive discussion of how to present the material, and on the technical content. Wiki works best when you assume other contributors have something worthwhile to offer, unless they show themselves unable to work constructively and cooperatively. Throwing around terms like "nonsensical" and mentioning the possibility of reverting material should be a last resort. But please, do give specific criticism of anything you think is wrong. Here, if others may be interested, or on my talk page, if you think it likely not of interest elsewhere. -- James Dennett 05:45, 9 December 2006 (UTC)

OK, having looked at this module, I don't see any examples of nonsense caused by what I've written there, though I've fixed up a few more pieces of it (such as something that still confused an array with a pointer). So, specific notes of problems would be appreciated, if people find problems. Thanks! -- James Dennett

In the section of passing an array to a function, I doubt whether there is any way to pass the whole array by reference (I mean '&' but not through pointer). As to my limited knowledge, I think we can only pass elements by reference but not the whole array as it is pass through pointer. In case I am correct, the content about this issue in TODO may mislead the readers. -- Ron Lau

It's quite possible to pass an array to a function by reference; it's pretty common. Here's an example with a fairly trivial function template:

template  std::size_t array_size(ElementType (&)[ElementCount]) {   return ElementCount; }

This one looks a little odd as the array isn't really used, but it could be.

Another trivial example:

void set_array_to_1_2_3(int (&array)[3]) {   assert( sizeof array == 3*sizeof(int) ); array[0] = 1; array[1] = 2; array[2] = 3; }

I hope this explains a little better. -- James Dennett 07:55, 1 March 2007 (UTC)

Hello guys what about having a chapter calling Structural programming in C++ where we can have functions, struct, typedef, enum and union? Jayaram Ganapathy

This is just not formal at all
I assume a text book should be formal.

this is not "Woah, my a-paul-igies, I didn't mean to jump right into it, but I'm pretty sure that if you're understanding pointers, the declaration of a function that returns a pointer or a reference should seem relatively logical. The above piece of code shows how to declare a function that will return a reference or a pointer."

It should not speak in 1st person. should not "speak" or imply conversation between auther and reader. Rather than saying "I'm pritty sure" It should say smething like "it is assumed that" - not member here, contact oxinabox1 @ wikimedia or wikipedia, if you must.--60.230.247.35 12:18, 22 April 2007 (UTC)


 * A little informality seems harmless -- maybe even helpful in a book aimed largely at beginner to intermediate programmers about a fairly dry topic. Perl's Camel Book has plenty of jokes, as do numerous others.   However, I've re-written the section you quoted.


 * I also note that this module refers to const member functions, but I don't think it's covered member functions at all at that time (I could be wrong). We need to think about how to organize this material -- James Dennett 16:47, 22 April 2007 (UTC)

Missing inversion?
In the section "The advantage of this paradigm is that the error handling is closer to the test itself. For example the previous code becomes:

if (my_function1) {    //error handler for function 1 errors return FUNCTION_1_FAILED; } "

Should this read:

if (!my_function1) {    //error handler for function 1 errors return FUNCTION_1_FAILED; } --K1mgy (discuss • contribs) 22:27, 25 December 2011 (UTC)


 * You are right. I opted by being more verbose it is easier to understand and avoids type conversion issues. --Panic (discuss • contribs) 23:43, 25 December 2011 (UTC)

java
F Yusufsani264 (discuss • contribs) 23:22, 19 September 2017 (UTC)