Re: Switching to C++ by default in 4.8

[Chiheng Xu <chiheng dot xu at gmail dot com>]

On Mon, Apr 16, 2012 at 3:48 PM, Duncan Sands <baldrick@free.fr> wrote:
>>> And I want to say that tree/gimple/rtl are compiler's data(or state),
>>> not compiler's text(or logic), the most important thing about them is
>>> how to access their fields.
>>>
>>
>> Given the above assumption, now I doubt the necessity of accessor
>> macros or C++ getter/setter method.
>>
>> Is "tree->code" more direct and efficient than "TREE_CODE(tree)" or
>> "tree->get_code()" ?
>
>
> On a side note, the dragonegg plugin (which is written in C++) defines
>
> Â/// isa - Return true if the given tree has the specified code.
> Âtemplate<enum tree_code code> bool isa(const_tree t) {
> Â Âreturn TREE_CODE(t) == code;
> Â}
>
> which lets you write things like
>
> Âif (isa<INTEGRAL_TYPE>(t)) ...
>
> and so on.
>
> While this is a bit more compact than "if (TREE_CODE(t) == INTEGRAL_TYPE",

Sorry, I totally disagree with you.

Your code :

 /// isa - Return true if the given tree has the specified code.
 template<enum tree_code code> bool isa(const_tree t) {
   return TREE_CODE(t) == code;
 }

 if (isa<INTEGRAL_TYPE>(t)) ...

can be easily replaced by :

bool tree_is_a(const_tree t, enum tree_code code)
{
   return TREE_CODE(t) == code;
}

if(tree_is_a(t, INTEGRAL_TYPE)) ...

Your code is like a abuse of template.

And, I think GCC developers would more like "if (TREE_CODE(t) ==
INTEGRAL_TYPE)" style code than the above code.

my proposal is
if (t->code == INTEGRAL_TYPE){
      integral_type  p_integer_type =  (integral_type) t;
      do_some_work_integral_type(p_integer_type);
}


> the main advantage to my mind is that it is a standard C++ idiom that should
> be natural for many C++ programmers.
>
I don't know what you mean by saying the "standard C++ idiom". Do you
mean abuse of template or the use of getter/setter method ?
In the first case, I will not comment any more.

But if you mean that getter/setter method is the "standard C++ idiom",
I want to say something.

In my understanding, getter/setter methods are used in GUI programming
area, where user level C++ objects encapsulate kernel objects.
People use getter/setter methods to access the properties of kernel
object. C++ object use getter/setter method to capture user's request
and forward it to kernel. This is the simple case.

Sometimes, C++ GUI library add artificial properties that do not
directly correspond to kernel object's properties. The values of these
properties are store in C++ object, not in kernel object.  Getter
methods of these artificial properties are simple, just retrieve the
values stored in C++ object. But, setter methods need to do more work,
besides storing values in C++ object,  normally, several calls to the
kernel API is needed to manipulate the kernel object.

But in GCC, we don't need to wrap kernel object, and we don't have
artificial properties. So, I see no necessity of getter/setter
methods.

Why GCC currently have TREE_CODE() or TREE_TYPE() macros ?
My understanding is that this is because C language does not support
inheritance. The field names in base type does not go directly into
derived type.  In C, "p_derived_type->field_of_base_type" does not
work. You must use "p_derived_type->m_base_type.field_of_base_type" .
For multilevel of derivation, the expression is even longer.
Apparently, this is not as clear as
FIELD_OF_BASE_TYPE(p_derived_type).

But once you use C++, there will be no such trouble.
"p_derived_type->field_of_base_type" just works regardless of the
levels of derivation !


-- 
Chiheng Xu