Re: [wwwdocs] Update coding conventions for C++

2012-06-27 Thread Chiheng Xu
On Wed, Jun 27, 2012 at 2:19 AM, Lawrence Crowl  wrote:
> On 6/26/12, Jason Merrill  wrote:
>> On 06/25/2012 06:26 PM, Lawrence Crowl wrote:
>> > +orgcc_unreachable.  If the checks are expensive or the
>> > +compiler can reasonably carry on after the error, they may be
>> > +conditioned on--enable-checking.
>>
>> by using gcc_checking_assert
>
> I inserted that suggestion, but note that I did not create that text,
> only moved it.
>
>> [Rationale]
>> > +FIXME: Discussion of deleting inappropraite special members.
>>
>> Is this FIXME still needed?  The text following it seems to cover the
>> issue well enough.
>
> No longer needed.
>
>> > +However, by default, RTTI is not permitted
>> > +and the compiler must build cleanly with -fno-rtti.
>>
>> This seems like an unnecessary restriction to me.
>>
>> > +Disabling RTTI will save space in the compiler.
>>
>> This is a fine reason to disable RTTI if it isn't used, but doesn't
>> seem like a strong reason to prohibit using it.  The information is
>> only emitted for classes with virtual functions, isn't very large,
>> is typically emitted in only one object file, and since it lives
>> in .rodata it can be shared between multiple compiler processes.
>>
>> > +Checking the type of a class at runtime usually indicates a design 
>> > problem.
>>
>> The tree_contains_struct machinery recently added to GCC maps
>> directly onto dynamic_cast;
>>
>> if (CODE_CONTAINS_STRUCT(TREE_CODE(t),TS_DECL_WRTL))
>>   /* do something with t->decl_with_rtl */
>>
>> translates roughly to to
>>
>> if (decl_with_rtl *p = dynamic_cast (t))
>>   /* do something with p */
>>
>> When new interfaces are added partway down an inheritance tree,
>> dynamic_cast is the right way to access them.  This isn't checking
>> what the type is, it's checking whether the object supports a
>> particular method.
>>
>> The fact that we've gone to the trouble to implement this
>> functionality in C suggests to me that using it isn't always
>> indicative of a design problem.  :)
>
> Personally, I am fine with using dynamic_cast.  I was writing up what
> I thought was a consensus on the wiki.  I can live without it, or I
> can use it profitably.  Whatever you all decide, I will write up.
>

dynamic_cast use RTTI, while TREE_CODE are poor man's type info. RTTI
is better than TREE_CODE. But, If you decide to use RTTI,  TREE_CODE
become redundant, that means all use of TREE_CODE should be removed,
sooner or later. Are you prepared for that ?

If every types in the type hierarchy, not just the root type and
leaves types,  has a TREE_CODE,  and you maintain a database of
inheritance relationship and other info of types of different
TREE_CODEs,  then,  for a object of a given TREE_CODE,  you know its
TREE_CODE and type info,   you know whether or not the object can be
cast to another type,  and,  you can know other info about the type,
like the size of object of the type, string name of the type.

This can be implemented as below. For every type in the type
hierarchy, static define a object of meta type( meta class, or class
class) to describe the type info of the specific type for a given
TREE_CODE. All of the meta type objects of different TREE_CODEs are
organized as an array, which is indexed by the value of TREE_CODE. And
you provide a set of C functions , that judge whether a object that
has a given TREE_CODE can be cast to a type that has another TREE_CODE
and retrieve the type info of a object that has a given TREE_CODE.


>> > +If you need to know the type of a class for some other reason,
>> > +use an enum or a virtual member function
>> > +that coverts a pointer to the more derived class.
>> > +For example,
>> > +
>> > +
>> > +
>> > +common_type *p = ;
>> > +if (specific_type *q = p->to_specific ()) {
>> > +  // We have and can use a specific_type pointed to by q.
>> > +}
>> > +
>>
>> This is basically equivalent to dynamic_cast except that you need
>> to clutter up your root base class with one virtual function for
>> each derived class you want to be able to convert to.
>
> Note quite equivalent, as you can implement to_specific with
> non-virtual classes using the TREE_CODE.  Thus would could implement
> a type-save dynamic pointer converter before converting to virtual
> classes.
>
> OTOH, we could probably work up a template function that looks like
> dynamic_cast but uses the TREE_CODE instead, achieving the same
> intermediate step.
>
> I agree that it does clutter up the base class.
>

Template function may be not necessary.
And, virtual method is not necessary.
Just normal C functions can work if you have the type info of a given TREE_CODE.

> Shall we enable RTTI?
Are you prepared to remove all use of TREE_CODE ?



-- 
Chiheng Xu


Re: [wwwdocs] Update coding conventions for C++

2012-06-27 Thread Chiheng Xu
On Tue, Jun 19, 2012 at 6:28 AM, Lawrence Crowl  wrote:
>  Function prototypes for extern functions should only occur in
>  header files.  Functions should be ordered within source files to
>  minimize the number of function prototypes, by defining them before
> @@ -121,13 +208,13 @@
>  necessary, to break mutually recursive cycles.
>

If you always put entry functions in the bottom of a source file, and
generically, always put upper layer functions below the lower layer
functions. Then probably there will be no need for function prototypes
in a source file.


> +Namespaces
> +
> +
> +Namespaces are encouraged.
> +All separable libraries should have a unique global namespace.
> +All individual tools should have a unique global namespace.
> +Nested include directories names should map to nested namespaces when
> possible.
> +

Do all people have a consensus on the use of namespace ?

> +
> +
> +Header files should have neither using directives
> +nor namespace-scope using declarations.
> +
> +
> +
> +There is no alternative to using declarations
> +in class definitions to manage names within an inheritance hierarchy,
> +so they are necessarily permitted.
> +


> +Exceptions
> +
> +
> +Exceptions and throw specifications are not permitted
> +and the compiler must build cleanly with -fno-exceptions.
> +
> +
> +
> +Rationale and Discussion
> +
> +
> +
> +The Standard Library
> +
> +
> +Use of the standard library is permitted.
> +Note, however, that it is currently not usable with garbage collected
> data.
> +
> +
> +
> +For compiler messages, indeed any text that needs i18n,
> +should continue to use the existing facilities.
> +
> +
> +
> +For long-term code, at least for now,
> +we will continue to use printf style I/O
> +rather than <iostream> style I/O.
> +For quick debugging code,
> +<iostream> is permitted.
> +

Is iostream really suitable or necessary for GCC ?
Have you think about writing another thinner interface , like Java's IO stream.


-- 
Chiheng Xu