Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Is cast operator unary or binary? How many operands?

Reply
Thread Tools

Is cast operator unary or binary? How many operands?

 
 
Chris Torek
Guest
Posts: n/a
 
      04-30-2008
In article <(E-Mail Removed)>
JoseMariaSola <(E-Mail Removed)> wrote:
>So both following expressions have one operator and one operand?
> sizeof(int)
> (int)x


Yes.

>typename is considered an operand in the firs expressin but not in the
>second one?


Yes. (In the second one, the type name is part of the operator.)

This is just a matter of terminology, in this case, as applied to
parsing. Since the terminology is made up by humans, it need not
be entirely consistent, or even make all that much sense, as long
as it lets one human communicate with another.

The way to view this, to make sense out of it, is that the cast
operator is inherently made up of the token sequence '(',
type-name-keyword [%], ')'. Having consumed the type-name by this
point, the only "argument" left to call an "operand" is the value
being cast. The sizeof operator is inherently made up of the
keyword token 'sizeof', and if its operand is a type-name, the
type-name is syntactically required to have outer-level parentheses.
Since the parentheses are (again) consumed by the syntax, the
"argument" that is left, that can be called an "operand", is the
type-name (without, in this case, the parentheses, although it
makes no real difference anyway).

[% In C as originally defined by Dennis Ritchie, "typedef" did not
even exist. So all type names were keywords, which made parsing
C easy. All declarations were instantly obvious, as they always
started with a keyword, and since the total set of keywords was
small, everyone knew all of them at a glance. When typedef was
later added, some time in the late 1970s, the language became much
more complicated syntactically, since typedef identifiers are only
distinguishable from other identifiers by context. For instance,
the C89 -- but not C99 -- code fragment:

void f(x);

can mean either:

- declare f as function taking one argument of type int, and
returning void; or

- declare f as function taking one argument of type x, and
returning void.

The former makes use of C89's "implicit int"; the latter occurs if
and only if "x" is a typedef-name. C99 removes this particular
ambiguity by outlawing "implicit int", but other difficult parsing
situations remain. From the parser's point of view, typedef-ed
identifiers are "just like" keywords, except when they are not.
If one attempts to use a conventional scanner and parser generator
like (f)lex and (b)yacc, one must invent clever feedback and/or
feed-forward mechanisms by which the parser can tell the lexer
whether to claim a potential typedef name is a "type name" or an
"identifier name". (Or one could use a more powerful parsing
technique, but that means abandoning yacc.)

Because it is impossible to tell at a glance whether some identifier
is actually a typedef-name, C programmers often find themselves
using some sort of self-imposed (or company coding standard imposed)
typographic convention to "mark" all typedefs. For instance, some
people use _t suffixes, so that it is clear that greeble_t is a
type-name. Others use an initial capital letter, or all-uppercase.]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      04-30-2008
JoseMariaSola wrote:
> How may operators and operands does (typename) expression has?
>
> I'd say one operator, the cast operator, and two operands: typename
> and expression.
>
> But everywhere I read, cast is categorized as an unary operator. Why
> is that? Is it just a syntax cotegory?
>
> Thanks.
>
> José María.


It has one argument: the expression, and a *result*
of type "typename"

When I write

(double)i;

I am conceptually calling

double TransformIntegerToDouble(int);

a function that takes ONE integer argument and outputs
a double number. Obviously there is no such a function
since the compiler inlines this cast when compiling, but
in some cases an actual function call will be generated.



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
 
 
 
Richard Tobin
Guest
Posts: n/a
 
      04-30-2008
In article <(E-Mail Removed)>,
Chris Torek <(E-Mail Removed)> wrote:

>The way to view this, to make sense out of it, is that the cast
>operator is inherently made up of the token sequence '(',
>type-name-keyword [%], ')'.


If you take this view, it makes more sense to say "... cast operators
are inherently made up of ...", since even if (int) is an operator,
it's clearly not the same operator as (double). The C standard seems
to do this except in the index, where "cast operator, ( )" points to
the section entitled "Cast operators".

-- Richard
--
:wq
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      04-30-2008
In article <fv9s2t$mu7$(E-Mail Removed)>, jacob navia <(E-Mail Removed)> wrote:

>When I write
>
>(double)i;
>
>I am conceptually calling
>
>double TransformIntegerToDouble(int);


Why are you not conceptually calling Transform(int, double)?

-- Richard
--
:wq
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      04-30-2008
Richard Tobin wrote:
> In article <fv9s2t$mu7$(E-Mail Removed)>, jacob navia <(E-Mail Removed)> wrote:
>
>> When I write
>>
>> (double)i;
>>
>> I am conceptually calling
>>
>> double TransformIntegerToDouble(int);

>
> Why are you not conceptually calling Transform(int, double)?
>
> -- Richard


Because the "int" is the RESULT type, not the input type!

Besides, a hyper hyper generic procedure:
Transform(anything,anything)
is just a dream...

You can have only concrete procedures:

Something TransformToSomething(something_else);

TransformIntegerToDouble exists (at least in lcc-win),
and will take care of the details, correct rounding, etc etc.

Transform(int,double) doesn't exist and can't exist since
it would have to take ANY two input types and transform the
second into the first, an impossible task!


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      04-30-2008
In article <fva02f$8jm$(E-Mail Removed)>, jacob navia <(E-Mail Removed)> wrote:


>Besides, a hyper hyper generic procedure:
> Transform(anything,anything)
>is just a dream...


Well, it's easily implementable:

#define Transform(value, type) ((type)(value))

>You can have only concrete procedures:


You were the one who said "conceptually":

>>> I am conceptually calling
>>>
>>> double TransformIntegerToDouble(int);


Conceptually, you can have whatever you like.

-- Richard
--
:wq
 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      05-12-2008
On 30 Apr 2008 13:10:55 GMT, Chris Torek <(E-Mail Removed)> wrote:

> [% In C as originally defined by Dennis Ritchie, "typedef" did not
> even exist. So all type names were keywords, which made parsing
> C easy. All declarations were instantly obvious, as they always


AIUI very early (Labs/pre-K&R1) C allowed file-scope declarations with
no decl-specifiers at all, using implicit int AND implicit extern.
This was still easy enough for humans to read, and to parse.

> started with a keyword, and since the total set of keywords was
> small, everyone knew all of them at a glance. When typedef was
> later added, some time in the late 1970s, the language became much
> more complicated syntactically, since typedef identifiers are only
> distinguishable from other identifiers by context. For instance,
> the C89 -- but not C99 -- code fragment:
>
> void f(x);
>
> can mean either:
>
> - declare f as function taking one argument of type int, and
> returning void; or
>
> - declare f as function taking one argument of type x, and
> returning void.
>
> The former makes use of C89's "implicit int"; the latter occurs if
> and only if "x" is a typedef-name. <snip>


A function _declaration_ can't have an identifier-list; it's either
empty-parens () or a prototype. The difficulty occurs with a
definition, and isn't actually ambiguous; but, as you say ...

> <snip> From the parser's point of view, typedef-ed
> identifiers are "just like" keywords, except when they are not.
> If one attempts to use a conventional scanner and parser generator
> like (f)lex and (b)yacc, one must invent clever feedback and/or
> feed-forward mechanisms by which the parser can tell the lexer
> whether to claim a potential typedef name is a "type name" or an
> "identifier name". (Or one could use a more powerful parsing
> technique, but that means abandoning yacc.)
>

Well, either the parser steers the lexer, or the lexer provides
(typically additional/different) information which allows the parser
to handle both possibilities. Either way it's a nuisance.

- formerly david.thompson1 || achar(64) || worldnet.att.net
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Ordinary unary function to STL adaptable unary predicate how? SpOiLeR C++ 10 10-19-2005 01:18 PM
Can someone tell me why? (Unary pre and post increment operator Andreas Sheriff C++ 10 09-25-2004 02:33 AM
unary operator- question John J C++ 7 04-18-2004 11:14 AM
c++ unary increment operator MSDousti C++ 1 11-01-2003 07:52 PM



Advertisments