This is the mail archive of the gcc@gcc.gnu.org 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: Converting GCC to compilation with C++


DJ Delorie wrote:

Things to allow
---------------

Overloaded functions, *iff* they vary only in parameter type, and not
parameter order/meaning/semantics or function semantics.  Occasionally
replacing a single arg with an arg pair (i.e. buffer class vs
pointer+length), where obvious, on a case by case basis.

I would minimize overloaded functions. They often make debugging more annoying. Certainly I would use them only where they really help readability. Readability should be the ONLY criterion, not convenience in coding. This is the rule we use in GNAT, and generally works out OK. The above rule is certainly a reasonable approach.

Single inheritance, where inheritance is obviously appropriate, with virtual functions also subject to the above restrictions.

Probably reasonable, although of course everything is in the phrase "obviously appropriate", which I fear will have widely differning interpretations.

Operator overload only for purely arithmetic types (i.e. arbitrary length integers, etc).

Indeed (this is the same rule we use in GNAT).


Simple string buffer type WITHOUT operator overloading (i.e. use plain
methods to access), except for operands corresponding to Pascal string
ops.

Seems reasonable


Declaring variables where they're used in the block, instead of at the
beginning, where such variables are used in a small locality of the
block.

That should be standard coding style in C if you ask me!


Things to avoid
---------------

Multiple inheritance.

Template/envelope classes (makes debugging and following code
trickier).

Reference counting (it never works simply enough in complex programs).

Overloading except as allowed above, especially overloading that
changes the common semantics of the operator (i.e. "+" should add
numbers, not add objects to a list).

"First class" types that don't correspond to categories of simple
types.

I would agree with all these exclusions.



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