Re: SELECT TYPE remark

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Tobias,

I think that we are going to wind up with something provisional by the
end of stage 1.  This is already a triumph and is largely due to
Janus' efforts.  Let's get something working, expose it and see what
bugs and implementation problems emerge.  We will have to warn users
that the API will certainly change but that this will give them a
taste.

One thing that we must do, rather urgently, is compare the scope
issues in C++ and fortran.  I am sharply aware that much can be done
with pointers to tables but do not quite know how these are
transmitted across the scope barriers that might arise in fortran

Further down the line, we can almost certainly absorb the vindex, or
whatever, into the array descriptor.  We will have to allow rank=0
descriptors too :-)

Anyway, I am going to go hell for leather towards a dynamic dispatch
implementation tonight and tomorrow.  Janus and I have exchanged
messages and have a clear view of how to complete SELECT TYPE.

I would like that we ask for three exemptions for gfortran, beyond
stage 1; We could probably do with a week or two to shake down OOP;
-fwhole-file needs revisiting; and I would dearly like to fix
allocatable components.

Thanks for your support in all this!

Cheers

Paul

On Tue, Sep 22, 2009 at 10:34 AM, Tobias Burnus <burnus@net-b.de> wrote:
> On 09/19/2009 07:57 PM, Paul Richard Thomas wrote:
>
> The simple
> merging/sorting would only work if all the types were known at compile time.
>
>
> I am feeling very stupid.....  Why does run-time come into this at
> all? [...] CLASS IS can introduce types that are unknown, though.
>
>
> I was thinking of CLASS IS. Sorry, if it wasn't clearly written.
>
> We also need temporaries (in my example: b and c), since
>
> EXTENDS_TYPE_OF works on variables, and not the types themselves. But
> then we're only left with how to implement EXTENDS_TYPE_OF.
>
>
> How about that we add a character field to the class container that
> either points to the parent type name or contains the name?
>
>
> I was chatting with a C++ programmer, who is a computer freak but no
> compiler programmer. He wrote that in g++ for RTTI one has mangled names of
> the kind _ZTV<mangledName> (_Z = prefix; TV = virtual table) and that then
> the check is done as in
> ?? if (self->parent->typeinfo == &_ZTI<mangledName>)
> i.e. one compares pointer addresses and not strings. (In C++ one has the
> additional complication that one can inherit from more than one "class"
> while in Fortran one can fortunately one only extends a single "type".)
>
> Maybe we could ask also Bill Long <longb@cray.com> how they handle it. I
> know they have an "int class" or something like that in their array
> descriptor for polymorphic class support.
>
> ?* * *
>
> Searching for RTTI (Run-time type information) might also give some more
> ideas. In C the "id" is accessed via "typeid". For issues using shared
> libraries, see http://gcc.gnu.org/faq.html#dsofor the C++ ABI see
> http://www.codesourcery.com/public/cxx-abi/
>
> Actually, http://www.codesourcery.com/public/cxx-abi/abi.html#rtti is quite
> interesting. There the "class type_info" is defined as:
>
>   namespace std {
>     class type_info {
>       public:
> 	virtual ~type_info();
> 	bool operator==(const type_info &) const;
> 	bool operator!=(const type_info &) const;
> 	bool before(const type_info &) const;
> 	const char* name() const;
>       private:
> 	type_info (const type_info& rhs);
> 	type_info& operator= (const type_info& rhs);
>     };
>
>   }
>
> I think we need someting alike: A mangled name, a comparison (which can be
> done via pointer comparison in the most (!) cases [or all in Fortran?])
>
> Tobias
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy