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

[WW]

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]

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).

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.

 

[Ron Natalie]

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]

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

 

[Kevin Goodsell]

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

 

[jeffc]

Thank you. But flattery won't help win the debate.

But in no context is 'sizeof' a function.

Whatever you gotta believe.

 

[jeffc]

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.

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.

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?

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.

 

[Ron Natalie]

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).

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.

 

[jeffc]

Well, I call the operands. They're not necessarily function arguments.

I didn't say function arguments, I said arguments.

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.

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.

 

[WW]

I didn't say function arguments, I said arguments.

Operator have operands. Not arguments.

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.

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/

 

[Ron Natalie]

That's just plain wrong, and I don't understand why you're being so
pigheaded about it,

I don't know why you're being pigheaded about it. You're wrong on just
about every point. Do you notice the intense lack of agreement with you
from this group?

Conceptually, there is no difference between
a = b + c
and
a = +(b,c)

In C++ they both have valid and different meaning.

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.

You keep inventing hypotheticals and trying to imagine equivelences that don't
exist. They don't exist however. You are wrong in both theory and practice.
Yes, binary has operands, and postfix expressions have operands, but that
doesn't make one the same as the other.

But "language rules" are a figment of your imagination,

They are NOT a figment, they are the underlying supposition of anybody
posting in this group which is about the C++ language as defined by the
language specification, not some imaginary langage you are conjuring up
in that pea brain of yours.

I'm not too
offended though, since you took the same posture with Mr. Stroustrup
himself.

What in the name of Knuth are you talking about now? I've never maligned Mr.
Stooustrup here. Unlike yourself, he has a clue.

 

[Alexander Terekhov]

Ron Natalie wrote:
[...]

What in the name of Knuth...

jeffc, may I suggest that you should sort of bypass von Neumann, go
straight to "Hitler hitler hitler" and be done with it, so to speak?

regards,
alexander.

 

[jeffc]

But the C++ language is not defined conceptually, but defined by a

standard.

So what? Where did I mention a standard anywhere? You brought it up,
because that's the point of view you want to argue from.

 

[WW]

So what? Where did I mention a standard anywhere? You brought it up,
because that's the point of view you want to argue from.

From the welcome.txt:

"First of all, please keep in mind that comp.lang.c++ is a group for
discussion
of general issues of the C++ programming language, as defined by the
ANSI/ISO
language standard."

 

[WW]

Ron Natalie wrote:
[...]

What in the name of Knuth...

jeffc, may I suggest that you should sort of bypass von Neumann, go
straight to "Hitler hitler hitler" and be done with it, so to speak?

Not really. Intentional mentioning of Him (or It) prevents Godwin's Law
from working.

 

[jeffc]

I don't know why you're being pigheaded about it. You're wrong on just
about every point.

No, you are.

In C++ they both have valid and different meaning.

So predictable of you. So robotic. So pedantic.

You keep inventing hypotheticals and trying to imagine equivelences that don't
exist.

If you can't understand anything outside of The Standard you keep hidden
under your mattress, that's your problem.

They are NOT a figment, they are the underlying supposition of anybody
posting in this group which is about the C++ language as defined by the
language specification, not some imaginary langage you are conjuring up
in that pea brain of yours.

Ouch, that's really gonna leave a mark.

What in the name of Knuth are you talking about now? I've never maligned Mr.
Stooustrup here. Unlike yourself, he has a clue.

Sorry, I was thinking of a post that someone else made - I thought it was
you. Generous of you to concede that he "has a clue" though.

 

[jeffc]

From the welcome.txt:

"First of all, please keep in mind that comp.lang.c++ is a group for
discussion
of general issues of the C++ programming language, as defined by the
ANSI/ISO
language standard."

The language is defined by the standard, the discussion is of GENERAL
ISSUES.

 

[jeffc]

Ron Natalie wrote:
[...]

What in the name of Knuth...

jeffc, may I suggest that you should sort of bypass von Neumann, go
straight to "Hitler hitler hitler" and be done with it, so to speak?

My understanding is that would be cheating. If it's worth doing, we
shouldn't cut corners.....

 

[WW]

The language is defined by the standard, the discussion is of GENERAL
ISSUES.

From the welcome.txt of this newsgroup:

"First of all, please keep in mind that comp.lang.c++ is a group for
discussion of general issues of the C++ programming language, *as* *defined*
*by* *the* *ANSI/ISO* *language* *standard*."

 

[WW]

No, you are.


So predictable of you. So robotic. So pedantic.

So trolling... Feel yourself killfiled "jeffc".