435,446 Members | 2,998 Online
Need help? Post your question and get tips & solutions from a community of 435,446 IT Pros & Developers. It's quick & easy.

# What does the expression "sizeof(int)*p" mean?

 P: n/a Does it mean "(sizeof(int))* (p)" or "sizeof( (int)(*p) )" ? According to my analysis, operator sizeof, (type) and * have the same precedence, and they combine from right to left. Then this expression should equal to "sizeof( (int)(*p) )", but the compiler does NOT think so. Why? Can anyone help me? Thanks. Best regards. Roy Jul 19 '05 #1
70 Replies

 P: n/a "Roy Yao" wrote in message news:... Does it mean "(sizeof(int))* (p)" or "sizeof( (int)(*p) )" ? According to my analysis, operator sizeof, (type) and * have the same precedence, and they combine from right to left. Then this expression should equal to "sizeof( (int)(*p) )", but the compiler does NOT think so. Why? Can anyone help me? Thanks. Best regards. Roy Hey, Both "(sizeof(int))* (p)" or "sizeof( (int)(*p) )" are not same. "(sizeof(int))* (p)" means you are multiplying sizeof(int), i.e. 2 (bytes), with the value of "p". Whereas "sizeof( (int)(*p) )" means, First you are getting the value of at the adderess p (because *p gives the value of another variable), then you are converting the returned value into interger format and finally you are detecting the size of that result. If you have any doubts contact at my ID ke***********@yahoo.co.in. Be Cool, Y. Keerthi Sagar & Ashok. Jul 19 '05 #2

 P: n/a Hello Keerthi, Thanks for your enthusiasm. My email to you was rejected by your mail server, so I reply you here. In this expression, what confused me is how the compilers (or ANSI C) determine the combination of operator sizeof, (type) and *. In my opion it should equal to expression "sizeof( (int)(*p) )". The reason is that operator sizeof, (type) and * have the same precedence, and they combine from right to left. But the compilers prefer "(sizeof(int))* (p)". Now can you give me a convictive explain from the precedence and combination order of operator ? Thanks again. Best regards, Roy Yao Jul 19 '05 #3

 P: n/a On Tue, 16 Sep 2003 08:44:02 +0800, Roy Yao wrote: Hello Keerthi, Thanks for your enthusiasm. My email to you was rejected by your mail server, so I reply you here. In this expression, what confused me is how the compilers (or ANSI C) determine the combination of operator sizeof, (type) and *. In my opion it should equal to expression "sizeof( (int)(*p) )". The reason is that operator sizeof, (type) and * have the same precedence, and they combine from right to left. But the compilers prefer "(sizeof(int))* (p)". Now can you give me a convictive explain from the precedence and combination order of operator ? I told you in my other post, that's NOT the (type) operator! (type) is the /operand/ of sizeof. Josh Jul 19 '05 #4

 P: n/a On Mon, 15 Sep 2003 22:00:09 -0400, Josh Sebastian wrote: : On Tue, 16 Sep 2003 08:44:02 +0800, Roy Yao wrote: : : > Hello Keerthi, : > : > Thanks for your enthusiasm. : > : > My email to you was rejected by your mail server, so I reply you here. You(Roy) are supposed to reply here. : > In this expression, what confused me is how the compilers (or ANSI C) : > determine the combination of operator sizeof, (type) and *. : > : > In my opion it should equal to expression "sizeof( (int)(*p) )". The : > reason is that operator sizeof, (type) and * have the same : > precedence, and they combine from right to left. But the compilers prefer : > "(sizeof(int))* (p)". : > : > Now can you give me a convictive explain from the precedence and : > combination order of operator ? : : I told you in my other post, that's NOT the (type) operator! (type) is the : /operand/ of sizeof. You are right, but he wants to know why. :) Some relevent production rules: unary-expression: postfix-expression ++ cast-expression -- cast-expression unary-operator cast-expression sizeof unary-expression sizeof ( type-id ) new-expression delete-expression unary-operator: one of * & + - ! ~ The expression in question: sizeof (int) * p '(int) * p' isn't a unary-expression, because it is not starting with ++, --, *, &, +, -, !, ~, sizeof, new, or delete, and it is not a postfix-expression (believe me!). So a compiler can't parse the expression in question as 'sizeof unary-expression'. Regards, tx Jul 19 '05 #5

 P: n/a "Roy Yao" wrote in message news:bk***********@mail.cn99.com... Hello Keerthi, Thanks for your enthusiasm. My email to you was rejected by your mail server, so I reply you here. In this expression, what confused me is how the compilers (or ANSI C) determine the combination of operator sizeof, (type) and *. In my opion it should equal to expression "sizeof( (int)(*p) )". The reason is that operator sizeof, (type) and * have the same precedence, and they combine from right to left. But the compilers prefer "(sizeof(int))* (p)". Now can you give me a convictive explain from the precedence and combination order of operator ? sizeof is a function, and the parameter it takes is whatever is inside the parens. If you wrote sizeof((int)*p), you'd evaluate the expression inside the outer parens first. You cast whatever *p is to an int, then take the size of that. Same as sizeof(int). But what you wrote in your subject is not exactly the same as either of the 2 options in your text message. Jul 19 '05 #6

 P: n/a jeffc wrote: sizeof is a function, No, it's not. It is an operator. and the parameter it takes is whatever is inside the parens. If you wrote sizeof((int)*p), you'd evaluate the expression inside the outer parens first. No, sizeof's operand is not evaluated. -Kevin -- My email address is valid, but changes periodically. To contact me please use the address from a recent posting. Jul 19 '05 #7

 P: n/a "jeffc" wrote in message news:3f********@news1.prserv.net... sizeof is a function, sizeof is not a function. It's an operator. and the parameter it takes is whatever is inside the parens. Sorry untrue. The parens aren't strictly requird. The grammar of sizeof is: sizeof unary-expression // note no parens here. swizeof ( type-id ) you'd evaluate the expression inside the outer parens first. Parens have no bearing on order of evaulation in C++. Jul 19 '05 #8

 P: n/a "jeffc" wrote in message news:3f********@news1.prserv.net... "Roy Yao" wrote in message news:bk***********@mail.cn99.com... Hello Keerthi, Thanks for your enthusiasm. My email to you was rejected by your mail server, so I reply you here. In this expression, what confused me is how the compilers (or ANSI C) determine the combination of operator sizeof, (type) and *. In my opion it should equal to expression "sizeof( (int)(*p) )". The reason is that operator sizeof, (type) and * have the same precedence, and they combine from right to left. But the compilers prefer "(sizeof(int))* (p)". Now can you give me a convictive explain from the precedence and combination order of operator ? sizeof is a function, and the parameter it takes is whatever is inside the parens. If you wrote sizeof((int)*p), you'd evaluate the expression inside the outer parens first. You cast whatever *p is to an int, then take the size of that. Same as sizeof(int). But what you wrote in your subject is not exactly the same as either of the 2 options in your text message. Additionally, his second option: (sizeof(int)*(p)) is exactly the same as the one in his subject line. DrX. Jul 19 '05 #9

 P: n/a "jeffc" wrote in message news:3f********@news1.prserv.net... sizeof is a function, and the parameter it takes is whatever is inside the parens. If you wrote sizeof((int)*p), you'd evaluate the expression inside the outer parens first. You cast whatever *p is to an int, then take the size of that. Same as sizeof(int). But what you wrote in your subject is not exactly the same as either of the 2 options in your text message. No, sizeof is an operator. The paranteses are only required for uses with a type expression. Any other use only need them because of precedence. Examples are: sizeof(int) sizeof 12345 sizeof 'a' sizeof (a + b) DrX. Jul 19 '05 #10

 P: n/a "Xenos" wrote in message news:bk*********@cui1.lmms.lmco.com... No, sizeof is an operator. The paranteses are only required for uses with a type expression. Makes no difference. Jul 19 '05 #11

 P: n/a "Xenos" wrote in message news:bk*********@cui1.lmms.lmco.com... But what you wrote in your subject is not exactly the same as either of the 2 options in your text message. Additionally, his second option: (sizeof(int)*(p)) is exactly the same as the one in his subject line. True. Jul 19 '05 #12

 P: n/a jeffc wrote: "Xenos" wrote in message news:bk*********@cui1.lmms.lmco.com... No, sizeof is an operator. The paranteses are only required for uses with a type expression. Makes no difference. You stated that sizeof is a function. It is not. It is an operator. Makes all the difference possible. It is an operator, same way as the + sign ot the () function call operator. -- WW aka Attila Jul 19 '05 #13

 P: n/a "Ron Natalie" wrote in message news:3f*********************@news.newshosting.com. .. "jeffc" wrote in message news:3f********@news1.prserv.net... sizeof is a function, sizeof is not a function. It's an operator. Same thing. and the parameter it takes is whatever is inside the parens. Sorry untrue. The parens aren't strictly requird. I didn't say they were required. I said it takes whatever is inside the parens. Are you arguing with the term "parameter"? I could easily argue that all operators take parameters (or arguments). This is more clear in C++ than C. Parens have no bearing on order of evaulation in C++. Of course they do. Compare: 1 + (2 * 3) (1 + 2) * 3 But that's beside the point. What I wrote was "If you wrote sizeof((int)*p), you'd evaluate the expression inside the outer parens first." That is true. Let's say p were of type double*. We are taking the size of an int, not double, and not int multiplied by double. Jul 19 '05 #14

 P: n/a "WW" wrote in message news:bk**********@phys-news1.kolumbus.fi... jeffc wrote: "Xenos" wrote in message news:bk*********@cui1.lmms.lmco.com... No, sizeof is an operator. The paranteses are only required for uses with a type expression. Makes no difference. You stated that sizeof is a function. It is not. It is an operator. Makes all the difference possible. It is an operator, same way as the + sign ot the () function call operator. Operators are functions. It's just that the syntax is sometimes a little different. It sure does not make "all the difference possible". Why do you think the term "Operator Functions" exists? Jul 19 '05 #15

 P: n/a jeffc wrote: "Ron Natalie" wrote in message news:3f*********************@news.newshosting.com. .. "jeffc" wrote in message news:3f********@news1.prserv.net... sizeof is a function, sizeof is not a function. It's an operator. Same thing. No, it is not. See the standard. See any language book. Please explain if operator is same as function, that how the heck can a *function call operator* exist? -- WW aka Attila Jul 19 '05 #16

 P: n/a jeffc wrote: "WW" wrote in message news:bk**********@phys-news1.kolumbus.fi... jeffc wrote: "Xenos" wrote in message news:bk*********@cui1.lmms.lmco.com... No, sizeof is an operator. The paranteses are only required for uses with a type expression. Makes no difference. You stated that sizeof is a function. It is not. It is an operator. Makes all the difference possible. It is an operator, same way as the + sign ot the () function call operator. Operators are functions. It's just that the syntax is sometimes a little different. It sure does not make "all the difference possible". Why do you think the term "Operator Functions" exists? Jeff it is not a shame to be a beginner, but it is a shameful to see years later your incorrect statements still in the newsgroup archives. Been there. So making the mistake of calling operators as functions is one thing. Insisting on it when you have been told it is not true is another thing. In 13.5 Oveerloaded operators Paragraph one Simon says: "A function declaration having one of the following /operator-function-ids/ as its name declares an operator function. An operator function is said to implement the operator named in its /operator-function-ids/." Read it carefully. It does not say operators are functions. It says: overloaded operators (overloaded ones!) are *implemented as* functions. -- WW aka Attila Jul 19 '05 #17

 P: n/a "WW" wrote in message news:bk**********@phys-news1.kolumbus.fi... jeffc wrote: "Ron Natalie" wrote in message news:3f*********************@news.newshosting.com. .. "jeffc" wrote in message news:3f********@news1.prserv.net... sizeof is a function, sizeof is not a function. It's an operator. Same thing. No, it is not. See the standard. See any language book. I obviously don't mean an operator is EXACTLY the same thing as a function. I mean for the purposes of what I was saying, and in context, it amounts to the same thing. int and long are 2 different things, but in some contexts they are the same thing. On some machines they take the same amount storage, on others they might not. In some operations they yield the same results, in others they do not. This is the same silly argument as when Ron tried to argue that calls to base class constructors from initializer lists are not function calls merely because the physical order they appear in don't mean that's the order they'll necessarily be called in. It doesn't matter if you write sizeof 'a' sizeof('a') The results are the same. Jul 19 '05 #18

 P: n/a "WW" wrote in message news:bk**********@phys-news1.kolumbus.fi... "A function declaration having one of the following /operator-function-ids/ as its name declares an operator function. An operator function is said to implement the operator named in its /operator-function-ids/." Read it carefully. It does not say operators are functions. It says: overloaded operators (overloaded ones!) are *implemented as* functions. It also says "a function declaration". What does that mean? And does that prove anything? You're being silly. Operators take arguments. They act like functions. If the context of this discussion were different, you'd be arguing the opposite side just as vehemently. You know exactly what I'm talking about, so you're just being arbitrary. Jul 19 '05 #19

 P: n/a jeffc wrote: No, it is not. See the standard. See any language book. I obviously don't mean an operator is EXACTLY the same thing as a function. I mean for the purposes of what I was saying, and in context, it amounts to the same thing. You have said for the sizeof operator to be a function. It is not. It can be compared to one (knowing the differences) but it is not a function from *any* valid viewpoint. int and long are 2 different things, but in some contexts they are the same thing. In no context they are the same thing. They both belong to types if that is what you mean but functions and the sizeof operators only meet at the expression level. Functions are called or inlined while the implementation for operators is not defined etc. They are not the same in any repspect. Especially when talking about sizeof. On some machines they take the same amount storage, on others they might not. Which has no significance in the matter of operators are not functions. They are both integral types, their coherence is much much higher than the one between operators and functions. In some operations they yield the same results, in others they do not. Irrelevant to the topic. This is the same silly argument as when Ron tried to argue that calls to base class constructors from initializer lists are not function calls merely because the physical order they appear in don't mean that's the order they'll necessarily be called in. Sure. They are not function calls. There are several reasons to it. One of ehich Ron told. Another (which leads to the same) is that contsructors are not functions. They are *special* member functions, which special semantics. It doesn't matter if you write sizeof 'a' sizeof('a') The results are the same. Yes. How does that support your theory of sizeof being a function from the C++ language point of view? -- WW aka Attila Jul 19 '05 #20

 P: n/a "WW" wrote in message news:bk**********@phys-news1.kolumbus.fi... This is the same silly argument as when Ron tried to argue that calls to base class constructors from initializer lists are not function calls merely because the physical order they appear in don't mean that's the order they'll necessarily be called in. Sure. They are not function calls. There are several reasons to it. One of ehich Ron told. Really? They're not function calls because the order in which they appear does not necessarily match the order in which they're called? Is that what you're saying the "proof" is that they're not functions? Another (which leads to the same) is that contsructors are not functions. They are *special* member functions, which special semantics. Ah, I see. They're not functions. They're *special* functions. Thanks for clearing that up. It doesn't matter if you write sizeof 'a' sizeof('a') The results are the same. Yes. How does that support your theory of sizeof being a function from the C++ language point of view? It supports my view that my comments are relevant to the context of the OP's original question. He wrote sizeof((int)*p). Now if context makes no difference, then how about if you come up and explain to the class the difference between these 4 expressions. short s; sizeof s*(double)s sizeof (double)s*s sizeof (s*(double)s) sizeof ((double)s*s) And please don't tell me they're the same. Jul 19 '05 #21

 P: n/a jeffc wrote: "WW" wrote in message news:bk**********@phys-news1.kolumbus.fi... "A function declaration having one of the following /operator-function-ids/ as its name declares an operator function. An operator function is said to implement the operator named in its /operator-function-ids/." Read it carefully. It does not say operators are functions. It says: overloaded operators (overloaded ones!) are *implemented as* functions. It also says "a function declaration". What does that mean? I am sorry? You do not know what a function declaration means? Oh boy. And does that prove anything? It only proves that operators are not functions. You're being silly. Really? Since when are you a mental health expert? Operators take arguments. Yeah. That makes them more functional than you are. Try to read the exceprt from the standard again. They act like functions. No, they don't. One reason is because they are not functions. Take the member access operator for example (the . operator). Does that act as a function? Nope. Some (actually very very few) operators may *look* like a function call in code in some of their allowed form(s). But just the same way as yellow snow is not from tee with lemon, operators in C++ are not functions. Overloaded operators are *implemented* as functions. If the context of this discussion were different, you'd be arguing the opposite side just as vehemently. Now you are a mind reader, too. Boy are you talented! How come I have never heard about your achivements before? You know exactly what I'm talking about, so you're just being arbitrary. Yes, I am being arbitrary. By the "absolute" meaning of the word "arbitrary". How come? There is only one absolute which decides what is what in C++. And that is the standard. And that clearly makes a fundamental distinction between operators and functions. Therefore they are not the same. -- WW aka Attila Jul 19 '05 #22

 P: n/a jeffc wrote: "WW" wrote in message news:bk**********@phys-news1.kolumbus.fi... This is the same silly argument as when Ron tried to argue that calls to base class constructors from initializer lists are not function calls merely because the physical order they appear in don't mean that's the order they'll necessarily be called in. Sure. They are not function calls. There are several reasons to it. One of ehich Ron told. Really? They're not function calls because the order in which they appear does not necessarily match the order in which they're called? Amongst other things, yes. Is that what you're saying the "proof" is that they're not functions? What are they? The proof that constructors are not functions is in the standard. Read it. They are special member functions. For one example how special they are: they have no names. But again: read the standard. Another (which leads to the same) is that contsructors are not functions. They are *special* member functions, which special semantics. Ah, I see. They're not functions. They're *special* functions. Thanks for clearing that up. No. They are *special* member functions. One of their specialty is that they do not have a name. The have special semantics. It doesn't matter if you write sizeof 'a' sizeof('a') The results are the same. Yes. How does that support your theory of sizeof being a function from the C++ language point of view? It supports my view that my comments are relevant to the context of the OP's original question. He wrote sizeof((int)*p). Now if context makes no difference, then how about if you come up and explain to the class the difference between these 4 expressions. short s; sizeof s*(double)s sizeof (double)s*s sizeof (s*(double)s) sizeof ((double)s*s) And please don't tell me they're the same. By meaning they are the same. All are takig the size of the type of the expression (double)s*(double(s), which is sizeof(double). I still see the above as an example against your idea of operators being functions. -- WW aka Attila Jul 19 '05 #23

 P: n/a jeffc wrote: "Ron Natalie" wrote in message news:3f*********************@news.newshosting.com. ..sizeof is not a function. It's an operator. Same thing. Absolutely not. A few differences are that sizeof is never 'called' (it is evaluated at compile time), and sizeof does not have an address. A consequence of the first point is that the operand of 'sizeof' is not evaluated: int i = 0; sizeof(++i); assert(i == 0); // OK, i has not changed. Parens have no bearing on order of evaulation in C++. Of course they do. No, they don't. Compare: 1 + (2 * 3) (1 + 2) * 3 This is an example of parens being used to change precedence. Precedence and order of evaluation are not the same. Given exp1 + exp2 the order that exp1 and exp2 are evaluated is not specified. Adding parens does not change this: (exp1 + exp2) (exp1) + exp2 exp1 + (exp2) None of these make the order of evaluation specified. Similarly, given a statement that modifies a variable twice without an intervening sequence point: i = i++; You cannot make the result of this well-defined by adding any number of parens, because the order of evaluation of the assignment and the increment is not specified and parens don't change it: i = (i++); // still undefined -Kevin -- My email address is valid, but changes periodically. To contact me please use the address from a recent posting. Jul 19 '05 #24

 P: n/a jeffc wrote: It also says "a function declaration". What does that mean? And does that prove anything? You're being silly. Operators take arguments. They act like functions. Please show me how to take the address of the sizeof function. I know all functions have addresses, and thanks to you I now know that sizeof is a function, therefore must have an address. Can you please show me how to determine this address? Thank you. -Kevin -- My email address is valid, but changes periodically. To contact me please use the address from a recent posting. Jul 19 '05 #25

 P: n/a Kevin Goodsell wrote: jeffc wrote: It also says "a function declaration". What does that mean? And does that prove anything? You're being silly. Operators take arguments. They act like functions. Please show me how to take the address of the sizeof function. I know all functions have addresses, and thanks to you I now know that sizeof is a function, therefore must have an address. Can you please show me how to determine this address? Thank you. It is: Dwight Look College of Engineering | Texas A&M University 301 Harvey R. Bright Bldg, College Station, TX 77843-3112 Do you also want a phone number? ;-) -- WW aka Attila Jul 19 '05 #26

 P: n/a Kevin Goodsell wrote: jeffc wrote: It also says "a function declaration". What does that mean? And does that prove anything? You're being silly. Operators take arguments. They act like functions. Please show me how to take the address of the sizeof function. I know all functions have addresses, and thanks to you I now know that sizeof is a function, therefore must have an address. Can you please show me how to determine this address? Thank you. Here's another revelation thanks to this new "operators are functions" rule. The following is no longer undefined: int i = 0; i = i++; assert(i == 0); i = ++i; assert(i == 1); Since '=' is a function, there is a sequence point before it is called, and the increment operation is finalized. Unfortunately, some compilers still seem to give incorrect results for this. I guess they haven't implemented "operators are functions" yet. -Kevin -- My email address is valid, but changes periodically. To contact me please use the address from a recent posting. Jul 19 '05 #27

 P: n/a "jeffc" wrote in message news:3f********@news1.prserv.net... "Xenos" wrote in message news:bk*********@cui1.lmms.lmco.com... No, sizeof is an operator. The paranteses are only required for uses with a type expression. Makes no difference. Makes all the difference in the world. The argument to sizeof is not evaluated as would be for a function. saying "sizeof(++i)" does not change the value of i. Futhermore, I don't know any function that can take a type as an argument, as in sizeof(int). sizeof is a compiler constructor, it is never executed by the runtime. DrX. Jul 19 '05 #28

 P: n/a "WW" wrote in message news:bk**********@phys-news1.kolumbus.fi... jeffc wrote: "WW" wrote in message news:bk**********@phys-news1.kolumbus.fi... "A function declaration having one of the following /operator-function-ids/ as its name declares an operator function. An operator function is said to implement the operator named in its /operator-function-ids/." Read it carefully. It does not say operators are functions. It says: overloaded operators (overloaded ones!) are *implemented as* functions. It also says "a function declaration". What does that mean? I am sorry? You do not know what a function declaration means? Oh boy. You do not know how to draw logical conclusions? Oh boy. Obviously I meant "what does that mean with regard to your argument?" It called it a "function declaration". That implies a "function". What you wrote supports my argument, not yours. And does that prove anything? It only proves that operators are not functions. Try again. Jul 19 '05 #29

 P: n/a "Kevin Goodsell" wrote in message news:qP*****************@newsread3.news.pas.earthl ink.net... jeffc wrote: It also says "a function declaration". What does that mean? And does that prove anything? You're being silly. Operators take arguments. They act like functions. Please show me how to take the address of the sizeof function. I know all functions have addresses, and thanks to you I now know that sizeof is a function, therefore must have an address. Can you please show me how to determine this address? Thank you. Can't be done Kevin. As I've already said, my comments are to be taken in context. You're just another pedant with too much time on your hands. Why don't *you* explain why WW quoted text referring to "function declarations" in the context of operators? I'm sure that will occupy you for quite awhile. Jul 19 '05 #30

 P: n/a "jeffc" wrote in message news:3f********@news1.prserv.net... "Xenos" wrote in message news:bk*********@cui1.lmms.lmco.com... No, sizeof is an operator. The paranteses are only required for uses with a type expression. Makes no difference. Sure as hell does. Jul 19 '05 #31

 P: n/a "jeffc" wrote in message news:3f********@news1.prserv.net... Operators are functions No they are not. User overloaded operators are functions. Other than that they do not have anything in common with functions and the rules of functions do not apply to the ones that aren't implemented as functions. It's just that the syntax is sometimes a little different. The syntax is not the same at all and the semantics are completely different. Jul 19 '05 #32

 P: n/a jeffc wrote: It also says "a function declaration". What does that mean? And does that prove anything? You're being silly. Operators take arguments. They act like functions. Please show me how to take the address of the sizeof function. I know all functions have addresses, and thanks to you I now know that sizeof is a function, therefore must have an address. Can you please show me how to determine this address? Thank you. Can't be done Kevin. As I've already said, my comments are to be taken in context. You're just another pedant with too much time on your hands. Why don't *you* explain why WW quoted text referring to "function declarations" in the context of operators? I'm sure that will occupy you for quite awhile. Dear Clever Boy, I did that because *you* were bringing up the term "Operator Functions". I have shown you from the standard that the place defining what operator functions are does nto say that operators are functions, but it says that some special functions are used to implement user defined operators. You are the one taking the quotes out of context. -- Attila aka WW Jul 19 '05 #33

 P: n/a jeffc wrote: "A function declaration having one of the following /operator-function-ids/ as its name declares an operator function. An operator function is said to implement the operator named in its /operator-function-ids/." Read it carefully. It does not say operators are functions. It says: overloaded operators (overloaded ones!) are *implemented as* functions. It also says "a function declaration". What does that mean? I am sorry? You do not know what a function declaration means? Oh boy. You do not know how to draw logical conclusions? Oh boy. Obviously I meant "what does that mean with regard to your argument?" It called it a "function declaration". That implies a "function". What you wrote supports my argument, not yours. Thank you for the clarification. It means that operators are not functions, but certain special function declarations are used to implement operators. And does that prove anything? It only proves that operators are not functions. No need to. It is proven by several people, even known experts, all over this thread. My goal is not to necessarily convince you, but to show to those who are ready to think and read that operators are not functions. -- Attila aka WW Jul 19 '05 #34

 P: n/a "WW" wrote in message news:bk**********@phys-news1.kolumbus.fi... jeffc wrote: "WW" wrote in message news:bk**********@phys-news1.kolumbus.fi... This is the same silly argument as when Ron tried to argue that calls to base class constructors from initializer lists are not function calls merely because the physical order they appear in don't mean that's the order they'll necessarily be called in. Sure. They are not function calls. There are several reasons to it. One of ehich Ron told. Really? They're not function calls because the order in which they appear does not necessarily match the order in which they're called? Amongst other things, yes. Then I'm sure you'd agree that f(), g() and h() are not functions? int f(){return 2;} int g(){return 3;} int h(){return 4;} int i = f() * (g() + h()); What is the result? If the functions are called in the order they appear, then the result will be 10. Is that the result? Since the order the functions appear is not the order in which they're called, then by your definition they are not functions, right? It supports my view that my comments are relevant to the context of the OP's original question. He wrote sizeof((int)*p). Now if context makes no difference, then how about if you come up and explain to the class the difference between these 4 expressions. short s; sizeof s*(double)s sizeof (double)s*s sizeof (s*(double)s) sizeof ((double)s*s) And please don't tell me they're the same. By meaning they are the same. All are takig the size of the type of the expression (double)s*(double(s), which is sizeof(double). Ho ho! Nice try. Try using a compiler and running some code for a change. You have no idea what you're talking about. Jul 19 '05 #35

 P: n/a "Kevin Goodsell" wrote in message news:QL*****************@newsread3.news.pas.earthl ink.net... sizeof is not a function. It's an operator. Same thing.Absolutely not. A few differences are that sizeof is never 'called' (itis evaluated at compile time), and sizeof does not have an address. Aconsequence of the first point is that the operand of 'sizeof' is notevaluated:int i = 0;sizeof(++i);assert(i == 0); // OK, i has not changed. I meant for purposes of this discussion, but... I see your point. Point conceded. Parens have no bearing on order of evaulation in C++. Of course they do. No, they don't. Compare: 1 + (2 * 3) (1 + 2) * 3 This is an example of parens being used to change precedence. Precedence and order of evaluation are not the same. But order of evaluation is changed, one way or another. Jul 19 '05 #36

 P: n/a Ron Natalie wrote: [SNIP] No, sizeof is an operator. The paranteses are only required for uses with a type expression. Makes no difference. Sure as hell does. As Ron usually is very calm I have to say I sense a troll who is even able to push him too far... -- Attila aka WW Jul 19 '05 #37

 P: n/a jeffc wrote: Really? They're not function calls because the order in which they appear does not necessarily match the order in which they're called? Amongst other things, yes. Then I'm sure you'd agree that f(), g() and h() are not functions? int f(){return 2;} int g(){return 3;} int h(){return 4;} int i = f() * (g() + h()); You have to really learn what expressions are. Here you have several of them. short s; sizeof s*(double)s sizeof (double)s*s sizeof (s*(double)s) sizeof ((double)s*s) And please don't tell me they're the same. By meaning they are the same. All are takig the size of the type of the expression (double)s*(double(s), which is sizeof(double). Ho ho! Nice try. Try using a compiler and running some code for a change. You have no idea what you're talking about. I do. I just want to know if you do, too. But it seems there is no way to make you show up any C++ knowledge. BTW you above game with operator precedence is nice as a trick. Also nice because it nicely supports the fact that operators are not functions. Since functions have no precedence. The function call operator - however - does -- Attila aka WW Jul 19 '05 #38

 P: n/a "Attila Feher" wrote in message news:bk**********@newstree.wise.edt.ericsson.se... short s; sizeof s*(double)s sizeof (double)s*s sizeof (s*(double)s) sizeof ((double)s*s) And please don't tell me they're the same. By meaning they are the same. All are takig the size of the type of the expression (double)s*(double(s), which is sizeof(double). Ho ho! Nice try. Try using a compiler and running some code for a change. You have no idea what you're talking about. I do. I just want to know if you do, too. But it seems there is no way to make you show up any C++ knowledge. In other words, those are not all sizeof(double) correct? You didn't try it, did you? BTW you above game with operator precedence is nice as a trick. The point being that you were being pedantic. You said that if the order the calls appear does not match the order in which they're called, then the things being called aren't functions. This "proves" that constructors aren't functions, according to you, because the order in which they appear on the initializer list doesn't necessarily match the order in which they're called. This has nothing to do with any definition of functions. Jul 19 '05 #39

 P: n/a "Ron Natalie" wrote in message news:3f***********************@news.newshosting.co m... "jeffc" wrote in message news:3f********@news1.prserv.net... Operators are functions No they are not. User overloaded operators are functions. Other than that they do not have anything in common with functions and the rules of functions do not apply to the ones that aren't implemented as functions. They absolutely do have things in common with functions, and it's ridiculous to say otherwise. In fact, if I show you a statement with an operator in it, you wouldn't even be able to tell me if it was a function or not. a = b + c; In fact, since I've already conceded the point to Kevin, it would be just as logical to argue that sizeof is not even an operator, since it doesn't follow the exact same rules as other operators. It doesn't necessarily mean it's not an operator, and it doesn't necessarily mean operators aren't functions, depending on the context of the discussion. Some of you guys just love to try to read the letter of the law rather than the intent. By the way, how do *you* explain the differences between these 4? short s; sizeof s*(double)s sizeof (double)s*s sizeof (s*(double)s) sizeof ((double)s*s) Jul 19 '05 #40

 P: n/a jeffc wrote: "Ron Natalie" wrote in message news:3f***********************@news.newshosting.co m... "jeffc" wrote in message news:3f********@news1.prserv.net... Operators are functions No they are not. User overloaded operators are functions. Other than that they do not have anything in common with functions and the rules of functions do not apply to the ones that aren't implemented as functions. They absolutely do have things in common with functions, and it's ridiculous to say otherwise. In fact, if I show you a statement with an operator in it, you wouldn't even be able to tell me if it was a function or not. Opps. You say that operators *are* functions. So why would anyone need to tell them apart??? You are loosing your argument. -- WW aka Attila Jul 19 '05 #41

 P: n/a jeffc wrote: "Attila Feher" wrote in message news:bk**********@newstree.wise.edt.ericsson.se...> short s;> sizeof s*(double)s> sizeof (double)s*s> sizeof (s*(double)s)> sizeof ((double)s*s)> And please don't tell me they're the same. By meaning they are the same. All are takig the size of the type of the expression (double)s*(double(s), which is sizeof(double). Ho ho! Nice try. Try using a compiler and running some code for a change. You have no idea what you're talking about. I do. I just want to know if you do, too. But it seems there is no way to make you show up any C++ knowledge. In other words, those are not all sizeof(double) correct? You didn't try it, did you? No. And I know they aren't. I just want to see if *you* know why and what are they and *why* (what language rules apply). BTW you above game with operator precedence is nice as a trick. The point being that you were being pedantic. The point being is that you have posted a fallacy that operators are functions and although it has been proven here a million times that they are not, you still insist. Therefore mixing up poor newbies who are here to learn about C++ and not egos. You said that if the order the calls appear does not match the order in which they're called, then the things being called aren't functions. I was not talking about expressions! Could you please tell me that in which order those functions are called in your example? Please give me a specific order. What is true. So what will their order be? This "proves" that constructors aren't functions, No. This *also* proves that they are not. Furthermore the *standard* proves that they are not. They are special member functions with *no names* and *no addresses*. according to you, because the order in which they appear on the initializer list doesn't necessarily match the order in which they're called. Since the initialization list is not an expression itself, yes. They have a *defined* evaluation order which is not their order. You function-calls-in-an-expression example has *no* defined evaluation order for the function calls! This has nothing to do with any definition of functions. That is your opinion. -- WW aka Attila Jul 19 '05 #42

 P: n/a "jeffc" wrote in message news:3f********@news1.prserv.net... = They absolutely do have things in common with functions, and it's ridiculous to say otherwise. In fact, if I show you a statement with an operator in it, you wouldn't even be able to tell me if it was a function or not. a = b + c; I would if you showed me the types of b and c. If they are not ones elligible for operator overloading, then no function is involved. As a result, there is no sequence point before and after the evaluation and anything else that's inherent in the function call that does NOT exist. In fact, since I've already conceded the point to Kevin, it would be just as logical to argue that sizeof is not even an operator, since it doesn't follow the exact same rules as other operators. It's an operator because that is how operators are defined in the language. You can invent all the vocabulary you want, but the truth is that the language defines sizeof, operator, and function and as much as you wish your views to be the correct ones, they are wrong. Some of you guys just love to try to read the letter of the law rather than the intent. Oh and you're an expert on intent? There is not and has never been an intent to equivelence function and operator. As a matter of fact, the idea is to hide the fact that there is a function inherent there in certain circumstances. By the way, how do *you* explain the differences between these 4? Language syntax, and the syntax of the sizeof OPERATOR. Fucntions play no role in it. short s; sizeof s*(double)s This is parsed (sizeof s) * (double) s; As you wrote it, it's undefined behavior since s has indeterminate value. But if we assume sizeof(short) is 2 and we set s to value 10000, the value is 2*10000 or 20000 sizeof (double)s*s This is ill-formed. It's parsed as (sizeof (double) ) s * s sizeof (s*(double)s) This is sizeof (double) because the entire parentheiszed expression has type double and that is what the sizeof operator is applied to. sizeof ((double)s*s) Same as above. Jul 19 '05 #43

 P: n/a WW wrote: Since the initialization list is not an expression itself, yes. They have a *defined* evaluation order which is not their order. You have a *defined* evaluation order which is not their order of appearance. Your function-calls-in-an-expression example has *no* defined evaluation order for the function calls! -- WW aka Attila Jul 19 '05 #44

 P: n/a jeffc wrote: Can't be done Kevin. As I've already said, my comments are to be taken in context. You're just another pedant Thank you. But flattery won't help win the debate. But in no context is 'sizeof' a function. -Kevin -- My email address is valid, but changes periodically. To contact me please use the address from a recent posting. Jul 19 '05 #45

 P: n/a "Kevin Goodsell" wrote in message news:2v****************@newsread3.news.pas.earthli nk.net... jeffc wrote: Can't be done Kevin. As I've already said, my comments are to be taken in context. You're just another pedant Thank you. But flattery won't help win the debate. But in no context is 'sizeof' a function. Whatever you gotta believe. Jul 19 '05 #46

 P: n/a "Ron Natalie" wrote in message news:3f***********************@news.newshosting.co m... "jeffc" wrote in message news:3f********@news1.prserv.net... = They absolutely do have things in common with functions, and it's ridiculous to say otherwise. In fact, if I show you a statement with an operator in it, you wouldn't even be able to tell me if it was a function or not. a = b + c; I would if you showed me the types of b and c. If they are not ones elligible for operator overloading, then no function is involved. The point is that the syntax looks different, but not so different that you can tell them apart. Would you deny that b and c are arguments? In the abstract, operators have much in common with function, regardless of implementation. Some of you guys just love to try to read the letter of the law rather than the intent. Oh and you're an expert on intent? I know what I intend, and apparently you don't. Between us, I'd have to be considered the expert. In fact, since I've already conceded the point to Kevin, it would be just as logical to argue that sizeof is not even an operator, since it doesn't follow the exact same rules as other operators.It's an operator because that is how operators are defined in the language. Kind of like how constructors are functions, regardless of how much you want to argue that? By the way, how do *you* explain the differences between these 4? Language syntax, and the syntax of the sizeof OPERATOR. Fucntions play no role in it. Again, not bothering to answer the question in context, as you enjoy doing so much. The context of the question did not have to do with functions. The context of the question was the significance of parentheses. Jul 19 '05 #47

 P: n/a "jeffc" wrote in message news:3f********@news1.prserv.net... The point is that the syntax looks different, but not so different that you can tell them apart. Would you deny that b and c are arguments? Well, I call the operands. They're not necessarily function arguments. In the abstract, operators have much in common with function, regardless of implementation. In the abstract they have nothing in common. The only parallel I can see that they might be implemented by an underlying function. Other than that the only thing the operands to + have and function arguments do is that they are both expressions. I know what I intend, and apparently you don't. Between us, I'd have to be considered the expert. What you intend doesn't add up to a pile of beans. I thought you were talking about the language intent (as proposed by the creator, the standards committee or the implementors). By the way, how do *you* explain the differences between these 4? Language syntax, and the syntax of the sizeof OPERATOR. Fucntions play no role in it. Again, not bothering to answer the question in context, as you enjoy doing so much. The context of the question did not have to do with functions. The context of the question was the significance of parentheses. Well since you didn't ask that question, it's hard to imagine what you expect the answer context to be. As I said, the language syntax, which is clearly specified tells you what the expressions mean. The semantics of sizeof (and the underlying type and value of s) tell you the value of the expression. As we've pointed out, a left paren after the keyword sizeof can mean one of two things. 1. It can if followed by a typeid, means that the sizeof is applied to the typeid. 2. If the next thing is not a typeid, then it must be part of a unary expression. 3. If it is none of these the program is ill formed. Rule 1 applies to the first example Rule 2 applies to the third and forth. Rule 3 applies to your second. It's a simple process of applying the expression parsing rules from section 5 of the standard. You can create other figments of your imagination such as function calls or whatever but the language rules are clear and simple here. Jul 19 '05 #48

 P: n/a "Ron Natalie" wrote in message news:3f***********************@news.newshosting.co m... "jeffc" wrote in message news:3f********@news1.prserv.net... The point is that the syntax looks different, but not so different that you can tell them apart. Would you deny that b and c are arguments? Well, I call the operands. They're not necessarily function arguments. I didn't say function arguments, I said arguments. In the abstract, operators have much in common with function, regardless of implementation. In the abstract they have nothing in common. The only parallel I can see that they might be implemented by an underlying function. Other than that the only thing the operands to + have and function arguments do is that they are both expressions. That's just plain wrong, and I don't understand why you're being so pigheaded about it, other than just to disagree with everything I say. Conceptually, there is no difference between a = b + c and a = +(b,c) That is to say, it's perfectly reasonable to assume a language could be written to implement the exact same code with either syntax. This "Argument" and "operand" mean basically the same thing. I know what I intend, and apparently you don't. Between us, I'd have to be considered the expert. What you intend doesn't add up to a pile of beans. Well excuse me for thinking otherwise. I know perfectly well what I intend when I say something, and if you don't then don't bother commenting. I've got every right to post here and don't think that a response from you is going to change that. You can create other figments of your imagination such as function calls or whatever but the language rules are clear and simple here. But "language rules" are a figment of your imagination, since I never mentioned them from the beginning, did I? You just wanted to argue from that point of view because that's what you enjoy doing, so you just imagined that's what my comments meant. You didn't bother discussing or asking, you just assumed your usual inflexible, narrow minded pose. I'm not too offended though, since you took the same posture with Mr. Stroustrup himself. Jul 19 '05 #49

 P: n/a jeffc wrote: The point is that the syntax looks different, but not so different that you can tell them apart. Would you deny that b and c are arguments? Well, I call the operands. They're not necessarily function arguments. I didn't say function arguments, I said arguments. Operator have operands. Not arguments. In the abstract, operators have much in common with function, regardless of implementation. In the abstract they have nothing in common. The only parallel I can see that they might be implemented by an underlying function. Other than that the only thing the operands to + have and function arguments do is that they are both expressions. That's just plain wrong, and I don't understand why you're being so pigheaded about it, other than just to disagree with everything I say. Conceptually, there is no difference between a = b + c and a = +(b,c) But the C++ language is not defined conceptually, but defined by a standard. And in that standard it is clearly visible that there are substantial differences between operators and function. Read D&EoC++. That is to say, it's perfectly reasonable to assume a language could be written to implement the exact same code with either syntax. This "Argument" and "operand" mean basically the same thing. Yes. but this language would not be C++ would it? So it is off-topic here. You can create other figments of your imagination such as function calls or whatever but the language rules are clear and simple here. But "language rules" are a figment of your imagination, since I never mentioned them from the beginning, did I? You just wanted to argue from that point of view because that's what you enjoy doing, so you just imagined that's what my comments meant. You didn't bother discussing or asking, you just assumed your usual inflexible, narrow minded pose. I'm not too offended though, since you took the same posture with Mr. Stroustrup himself. Crap/ -- WW aka Attila Jul 19 '05 #50

70 Replies

### This discussion thread is closed

Replies have been disabled for this discussion.

### Similar topics

Browse more C / C++ Questions on Bytes