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