On Mon, 31 Mar 2008 13:22:10 -0700 (PDT), Maciej Sobczak wrote:
> Consider a generic subprogram that makes sense for arguments of both
> class-wide type and a concrete type.
>
> As a motivating example, there might be a hierarchy of iterator types
> rooted in some imaginary Iterator type that is itself defined in the
> generic package with the element type as its own formal parameter.
> There are concrete iterator types that are derived from this root
> Iterator type (exactly: from some instantiation thereof).
>
> There might be also a generic subprogram that operates on the iterator
> given as its parameter. This subprogram takes two formal generic
> parameters: the element type and the iterator type.
>
> Now - on one hand it makes sense to have a hierarchy of iterators and
> benefit from loose coupling and other features of OO, but on the other
> hand the iterators themselves can be lightweight objects that are used
> in tight loops and we can expect them to be fast, therefore we could
> benefit from *avoiding* the dynamic dispatch if there is enough
> context to do so.
>
> Both make sense, depending on the context at the call site.
>
> To achieve both benefits the user might instantiate the subprogram for
> the Iterator'Class type (to be exact: for the 'Class of some
> instantiation of Iterator) in the context where only a class-wide type
> is available, like within some other polymorphic subprogram; and for
> the concrete type, like My_Concrete_Iterator, in the context where the
> concrete type is available, with the hope that such an instantiation
> can be more easily inlined.
Just a small side note. If you care about performance you should do
exactly
the opposite you tried to, i.e. you should instantiate it with a specific
type rather than with a class of. Doing so, you will force the compiler to
resolve primitive operations statically without dispatching overhead. When
you use class-wide, then its will dispatch somewhere, maybe later in the
bodies, maybe more than once.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
|
