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: Using C++ in GCC is OK

On Wed, Jun 2, 2010 at 1:38 AM, Ian Lance Taylor <> wrote:
> DJ Delorie <> writes:
>>> I did mean that all virtual functions should be protected.
>> This forbids the most useful thing about virtual functions - letting
>> child classes implement a public ABI defined by the base class.
> There are really two cases to consider, and actually the coding
> standard should describe this.
> 1) The parent class consists only of pure virtual methods. ?In that
> case it is perfectly reasonable for those methods to be public.
> 2) The parent class does not consist only of pure virtual methods. ?In
> that case I am arguing that all virtual methods should be protected.
> In cases where the virtual method implements something which is part
> of the public interface, there should be a public method which calls
> the protected method.
> The reason for the latter case is that the parent class is providing a
> public interface, and it is doing so by using a separate interface
> defined by child classes. ?The two interfaces are obviously related,
> but they are not the same. ?In particular, as new child classes are
> implemented and the parent class interface evolves, they evolve in
> different ways. ?Keeping the two interfaces separate from the start
> avoids confusion and makes it easy to redesign either interface
> separately from the other one.
>>> > ?* All data members should be private.
>>> > ?* All data members should have names which end with an underscore.
>>> >
>>> > This makes all structures illegal. ?I'd remove the first "All" and
>>> > replace the second with "Private":
>>> This text only refers to classes. ?As the convention says in the
>>> following major bullet, structs are handled as they are today.
>> I don't agree that *all* data members of classes should be private.
>> It's not always appropriate - it depends on the design of the class.
>> I'd hate to be forced to do this for every datum:
>> ? ? ? int count;
>> ? ? ? int get_count ();
>> ? ? ? void set_count (int);
>> That gets messier when the datum are pointers. ?foo->bounds->left is
>> cleaner than foo->get_bounds()->get_left().
> I think I'm advocating a reasonable position here. ?With our current
> data structures such as tree and rtx, we generally do not use direct
> field access, but always use accessors. ?For cases where direct field
> access is appropriate can use structs. ?What do other people think?
>>> > * Use C-style comments for multi-line comments, and C++-style comments
>>> > ? for single-line comments.
>>> I'm not sure i agree with this, because I don't see anything wrong
>>> with multi-line C++-style comments.
>> It assumes your editor can do block-reformatting while preserving the
>> comment syntax. ?I've had too many // cases of Emacs guessing wrong //
>> and putting // throughout a reformatted // block.
> I don't see why the coding standard should prohibit using a good
> editor, but I'm willing to hear what other people think.

I'd like us to stick with C comments only.  I defintely do not like
a mix of both styles and I can't see an advantage of C++ comments.


> Ian

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