This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: About TYPE_DECL, typedefs and TYPE_NEXT_VARIANT


Alberto Lozano Alelu <alelus@gmail.com> a Ãcrit:

> When I get a typedef, I would like to show the definition. I use:
>
> tree v_next_type=DECL_ORIGINAL_TYPE(TYPE_NAME(v_type));
>
> But this expression isn't always correct.

You are correct.  There are times where typedefs are thrown away
(stripped) and only the underlying type is kept.

To my knowledge, this is done when in a template instantiation the
argument is a typedef.  For instance:

    template<class T>
    struct S {
      T p; //#1
    };
    typedef int tint0;
    typedef int tint1;

    S<tint0> s0; //#2
    S<tint1> s1; //#3

At #2, tint0 is stripped (and thus becomes int) when we build the
instantiation S<tint0>.  So what is built is really S<int>.  Then when
we are to build S<tint1> at #3, we strip tint1 to get int, and so we
don't build a new S<int> type, we just re-use the one we already have.

So for the instantiation S<tint0>, when you look at type type of p at
#1, you get int.  Not tint0.

I believe this is done to save resources.  It's more efficient to have
just one S<int> in the system, rather than having S<tint0>, S<tint1>
and S<int>.

Unfortunately, there is no easy way around this at the moment.

Otherwise, outside of the context of template arguments, I think we
pretty much keep typedefs around.

-- 
		Dodji


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]