🚀 go-pugleaf

>Steven Correll (sjc@netcom.com) wrote:
>>         struct x;
>>         struct y;
>>  
>>         void
>>         p(x *arg0, y *arg1)
>>           {
>>           delete [] arg0;
>>           delete arg1;
>>           }
>>  
>> I don't see how a compiler could avoid noticing that it hasn't a clue what
>> destructor to invoke at compilation time. Is there a reason (aside from
>> encouraging people to migrate to Java) not to require the compiler to
>> diagnose this as an error, instead of allowing it to fault at execution
>> time?

In article <4jcdp0$b3p@venus.mcs.com>, Martin J. Maney <maney@mcs.com> wrote:
>So why not make this sort of thing ill-formed?  Probably so that PODS can
>continue to be used, as in legacy code that has been only partially ported
>to C++.  (I'm thinking here of code that's been cleaned up to compile as
>C++, and use some of the features such as new/delete, but that hasn't been
>redesigned as OO.  Been there, done that, and it was quite worthwhile as
>an intermediate step without which the code probaly would have had to
>remain in Plain C until it was abandoned.)...
>
>Now that you've pointed this out, I should have to agree that it would be 
>very nice to see compilers diagnose this, but I wouldn't want them to 
>reject such a program as ill-formed for reasons that must be obvious.  
>Therefore it has to be a "quality of implementation" issue, or perhaps 
>even a job for a lint++ tool, since in general one might have to examine 
>files that are not normally, nor are intended to be, compiled together.

Your argument is so persuasive that I withdraw my question and ask a different
one: why the silly rule that a function must be declared before it can be
invoked? If C++ were rid of that rule, it would be much easier to port legacy
C code which has been partly converted to C++. Of course, such code will often
crash in nigh-impossible-to-debug ways, but we wouldn't want a compiler to
reject such code as ill-formed; this is a "quality of implementation" issue,
or perhaps a job for a lint++ tool which could, by examining source files that
are not normally compiled together, determine whether or not the compiler was
right when it inferred the formal argument types based on the actual argument
types.

:-)
-- 
Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == sjc@netcom.com


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]