Re: Why does debugging "pure virtual method called" have to be sohard?

[rich_paul at bigfoot dot com]

> Thanks for your patch. I personally like it; however, I'm not the one
> deciding on it.
> 
Thanks .. my first attempt at a gcc hack.  The sheer RUSH of power at
being able to modify your compiler is incredible to a recovering
windoze guy.


> - I'm not sure how good it is to put this into exception.cc. People
>   often complain that they have to link things they didn't
>   buy. Allowing fine-grained linkage of the runtime is a must, IMHO.

I'm not sure of this either, here's why I chose that spot:
  1) I moved it from libgcc2.c, becuase when it was there unexpected
                            ^^ 
  got called if __pure_virtual ( or something it called ) threw an
  exception, I suspected that functions in c files have implied
  throw() specifications.  True?

  2) It matches in form the other stuff that's there.  I assumed that
  things like new_handler are required for *ANY* c++ program.  True?
  If not, should it go (assuming it GOES at all) into a fresh file,
  or is there somewhere else.  Any program with a vtable, I suspect,
  will require __pure_virtual, although perhaps that would only be any
  program with a pure function.  
  
  Anybody know if vtables are prepped with __pure_virtual, or directly
  assigned to their final values?  I don't suppose there's much chance
  of anything happening while the vtables are being built, perhaps
  they're just binary data images.  Anyway, what do we think?

> - You are indeed free to use the double-underscore. Any such name is
>   reserved. In addition, any name starting with an underscore and
>   followed by an uppercase letter is reserved. Furthermore, any name
>   starting with an underscore is reserved in the global namespace and
>   in ::std.

	Hmmm ... in BOTH namespaces?  That's odd.  Is this true of names
	like 'xxx__yyy' which are also reserved?

> 
> - __pure_virtual absolutely must have "C" linkage, unless you want to
>   break compatibility with existing libraries. Not having any
>   decorations in the assembler output is the defining property of "C"
>   linkage. You can put extern "C" functions into namespaces.
> 
	Got you ... really, C linkage isn't a bad thing.  Just makes the
	header file less pretty.  I'd suggest, in that case, moving that
	function into the std namespace with the rest of the stuff them.
	
> - I agree that a new namespace might be a good idea, like __gnu.
>   __g++, of course, is not a valid identifier.
> 
	My little way to saying 'for exposition only'.  <G>


--------
Where do you want to crash, toady?
On Mon, 2 Nov 1998, Martin von Loewis wrote: