[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [ALPHA-PATCH] THIRD try at fixing up socklen issues on Solaris
From:       Oswald Buddenhagen <ob6 () inf ! tu-dresden ! de>
Date:       2001-04-06 8:23:43
[Download RAW message or body]

> You seem to think (at least your last mails indicate this), that a
> typedef introduces somehow a new thing or name.
no. a typedef is an alias for the data type it represents.

> A typedef is nearly exactly like a #define which can't be
> #undef'ined or #ifdef'ed.
and that's the relevant point:
- one of rob's (i think it was his) patches actually tried to #ifdef
  a typedef; that motivated me to point this out
- check out this code:
-------------
#define type int //only in variant 1
//typedef int type; //only in variant 2

int f1()
{
  int type;
  for (type = 0; type < 10; type++)
    /*blahblahblah ...*/;
}

int f2()
{
  type var;
  /* do something with var*/
}
------------
variant 1 breaks, variant 2 works. very simple demonstration of the
differences.

> I.e. with a "typedef int Bla;" in effect
>   void A(int);
>   void A(Bla);
> are _exactly_ the same thing, [...]. The mangling is the same and
> everything (every compiler that mangles them different would be
> broken for C++).
>
for c i agree 100% (no mangeling anyway), 
for c++ ... i don't know actually.

<extra pedant> :)
> (ergo not allowed in the same file, because of equal signatures)
the above two prototypes _are_ allowed in the same file in any
case - exactly because they are prototypes (for the same function).
void A(int) {} 
void A(Bla) {}
in the same file are forbidden. 
but that's what you had in mind, right? :)
</extra pedant>

> So, a typedef and a #define are not obviously completely different,
> not w/r the effects both have.
>
yes, but the fine print is sometimes important (i hope, i demonstrated
it cleary enough), so it is important not to use them as synonyms - at
most as analogies. in a discussion about a concrete implementation
the right terms (hmm, actually c++ keywords / preprocessor directives) 
should be used.
yes, i'm a nitpicker. :)

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Nothing is fool-proof to a sufficiently talented fool.
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]