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
70  8788 
"Roy Yao" <fl***@263.net> wrote in message news:<bk***********@mail.cn99.com>... 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.
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
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
On Mon, 15 Sep 2003 22:00:09 -0400, Josh Sebastian <cu****@cox.net>
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
"Roy Yao" <fl***@263.net> 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.
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.
"jeffc" <no****@nowhere.com> 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++.
"jeffc" <no****@nowhere.com> wrote in message
news:3f********@news1.prserv.net...
"Roy Yao" <fl***@263.net> 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.
"jeffc" <no****@nowhere.com> 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.
"Xenos" <do**********@spamhate.com> 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.
"Xenos" <do**********@spamhate.com> 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.
jeffc wrote: "Xenos" <do**********@spamhate.com> 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
"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f*********************@news.newshosting.com. ..
"jeffc" <no****@nowhere.com> 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.
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi... jeffc wrote: "Xenos" <do**********@spamhate.com> 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?
jeffc wrote: "Ron Natalie" <ro*@sensor.com> wrote in message
news:3f*********************@news.newshosting.com. ..
"jeffc" <no****@nowhere.com> 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
jeffc wrote: "WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi... jeffc wrote: "Xenos" <do**********@spamhate.com> 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
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi... jeffc wrote: "Ron Natalie" <ro*@sensor.com> wrote in message
news:3f*********************@news.newshosting.com. ..
"jeffc" <no****@nowhere.com> 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.
"WW" <wo***@freemail.hu> 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.
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
"WW" <wo***@freemail.hu> 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.
jeffc wrote: "WW" <wo***@freemail.hu> 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
jeffc wrote: "WW" <wo***@freemail.hu> 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
jeffc wrote: "Ron Natalie" <ro*@sensor.com> 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.
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.
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
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.
"jeffc" <no****@nowhere.com> wrote in message
news:3f********@news1.prserv.net...
"Xenos" <do**********@spamhate.com> 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.
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi... jeffc wrote: "WW" <wo***@freemail.hu> 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.
"Kevin Goodsell" <us*********************@neverbox.com> 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.
"jeffc" <no****@nowhere.com> wrote in message news:3f********@news1.prserv.net...
"Xenos" <do**********@spamhate.com> 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.
"jeffc" <no****@nowhere.com> 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.
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
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
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi... jeffc wrote: "WW" <wo***@freemail.hu> 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.
"Kevin Goodsell" <us*********************@neverbox.com> 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' (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.
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.
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
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
"Attila Feher" <at**********@lmf.ericsson.se> 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.
"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f***********************@news.newshosting.co m...
"jeffc" <no****@nowhere.com> 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)
jeffc wrote: "Ron Natalie" <ro*@sensor.com> wrote in message
news:3f***********************@news.newshosting.co m...
"jeffc" <no****@nowhere.com> 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
jeffc wrote: "Attila Feher" <at**********@lmf.ericsson.se> 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
"jeffc" <no****@nowhere.com> 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.
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
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.
"Kevin Goodsell" <us*********************@neverbox.com> 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.
"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f***********************@news.newshosting.co m...
"jeffc" <no****@nowhere.com> 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.
"jeffc" <no****@nowhere.com> 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.
"Ron Natalie" <ro*@sensor.com> wrote in message
news:3f***********************@news.newshosting.co m...
"jeffc" <no****@nowhere.com> 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.
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Roy Yao |
last post by:
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...
|
by: aarklon |
last post by:
Hi all,
why printf("....%d",sizeof((int)(double)(char) i)) always gives the
size of int ???
is it because sizeof doesn't evaluate its operand....???
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
