This is the mail archive of the 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: Switching to C++ by default in 4.8

On Mon, Apr 16, 2012 at 3:48 PM, Duncan Sands <> 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;

> 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

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

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

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