rfg@MCC.COM (Ron Guilmette) (01/21/89)
I'm not sure if this is a bug in G++ (1.32.0), a bug in the language
definition itself, or just a strange feature, but here goes. Consider
the following code:
////////////////////////////////////////////////////////////////////////////
class first_class;
class second_class {
public:
first_class some_function ();
}
another_function ()
{
second_class second_class_object;
second_class_object.some_function ();
}
////////////////////////////////////////////////////////////////////////////
No errors are generated when G++ 1.32.0 compiles the code above.
I believe that this is wrong for two reasons.
1) After the call to some_function() a type "first_class"
object should be returned on the stack. Unfortunately,
the compiler cannot possibly know how big such objects are
and thus it cannot possibly pop the returned object off
of the stack correctly.
2) The "first_class" object returned from the call to some_function()
may also need to have it's associated destructor called
before the space it is occupying can be reclaimed.
Unfortunately, the compiler cannot possibly know (at the
point of the call to some_function()) whether or not the full
definition of the class "first_class" has a destructor or not.
Thus, it cannot possibly know whether or not it should
generate a call to the destructor at that point.
I believe that a proper response to the above code would have been to issue
an error message at the point at which the function "some_function" is
first declared. The message should say that the return type for the function
(i.e "first_class") is not yet fully defined.
Any comments? Could somebody please see what AT&T cfront does with this.
// Ron Guilmette - MCC - Experimental (parallel) Systems Kit Project
// 3500 West Balcones Center Drive, Austin, TX 78759 - (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {ihnp4,seismo,ucb-vax,gatech}!cs.utexas.edu!pp!rfgschmidt@crimee.ics.uci.edu (Doug Schmidt) (01/21/89)
In article <8901202252.AA10430@riunite.aca.mcc.com> rfg@MCC.COM (Ron Guilmette) writes: > >I'm not sure if this is a bug in G++ (1.32.0), a bug in the language >definition itself, or just a strange feature, but here goes. Consider >the following code: > >//////////////////////////////////////////////////////////////////////////// >class first_class; > >class second_class { >public: > first_class some_function (); >} > >another_function () >{ > second_class second_class_object; > > second_class_object.some_function (); >} >Any comments? Could somebody please see what AT&T cfront does with this. > cfront screws up also, here's the diagnostics from 1.2.1: ---------------------------------------- CC foo.c: "foo.c", line 13: warning: second_class_object used but not set "foo.c", line 13: warning: no value returned from another_function() cc foo.c..c /cd/ua/schmidt/lib/sun4/mylib.a /cd/ua/schmidt/lib/sun4/strlib.a -lC "foo.c", line 12: undefined structure or union mv: foo.c..o: Cannot access: No such file or directory ---------------------------------------- The last error is propagated through to the C compiler! Here's a portion of the generated C source code: ---------------------------------------- "foo.c", line 13: warning: second_class_object used but not set "foo.c", line 13: warning: no value returned from another_function() struct second_class { /* sizeof second_class == 2 */ char _dummy; }; struct first_class _second_class_some_function (); int another_function () { struct second_class _au1_second_class_object ; _second_class_some_function ( & _au1_second_class_object ) ; } ; ---------------------------------------- Doug -- schmidt@ics.uci.edu (ARPA) | Per me si va nella citta' dolente. office: (714) 856-4043 | Per me si va nell'eterno dolore. | Per me si va tra la perduta gente. | Lasciate ogni speranza o voi ch'entrate.
ekrell@ulysses.att.com (01/21/89)
I think cfront 2.0 has it right: "x.C", line 12: error: first_class undefined, size not known "x.C", line 10: warning: second_class_object used but not set