On Tue, Jun 12, 2012 at 9:58 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
>
> I think it's the best we can do in C++. We really want a ton of
> common non-cut-n-pasted code between the vector and scalar FE classes,
> we don't want the gross inefficiencies (and backwards compatibility
> breakage) implied by a runtime polymorphic design, and so that leaves
> us with templates.
Backwards compatibility breakage issues aside, are we potentially
being guilty of premature optimization here?
I think with a reasonably smart design, a polymorphic hierarchy need
not be unreasonably slow... and I think we should only be convinced by
profiling in any case.
But I can't reasonably sit back and demand that someone implement and
profile a complete polymorphic FE hierarchy either... any C++ expert
PECOS grad students there?
>> Also, it might be handy if we could keep using the equivalent of
>> FEBase::build() in the new system... if the base class is templated,
>> does this functionality become trickier to implement?
>
>
> Slightly. FEBase::build() will only work if you know you're asking
> for a scalar FE type, likewise for FEVectorBase::build() and vector
> types. FEAbstract::build() will work for either, but will give a
> higher-level base class without the output-type-specific
> functionality. And we'll have something like "bool
> FEAbstract::rank()" (returning 0 for scalar, 1 for vector, etc) for
> cases where your code really needs the output-type-specific
> functionality but doesn't know a priori which output type code path
> it's going to have to go down for a given FE type.
OK, hopefully there won't be too much code duplication between the
different build() methods.
>>> Which would then allow us to add a default template parameter to FE
>>> giving something like
>>>
>>> template <unsigned int Dim, FEFamily T, typename
>>> OutputType=FEGenericBase<OutputOf<T>::type>
>>> class FE : public FEBase {...};
>>
>>
>> Hmm, so then FE is *not* derived from this new FEGenericBase class at
>> all, but rather an untemplated FEBase class, similar to what we have
>> now?
>
>
> No, I was just typing too fast. Trying again:
>
>
> template <unsigned int Dim, FEFamily T, typename
> OutputType=FEGenericBase<OutputOf<T>::type>
> class FE : public FEGenericBase<OutputType> {...};
I see. So then the point is *not* to have two separate names, e.g.
template <unsigned int Dim, FEFamily T>
class FEScalar : public FEGenericBase<Real> {...};
template <unsigned int Dim, FEFamily T>
class FEVector : public FEGenericBase<RealGradient> {...};
but just one "FE" from which all (real and vector-valued) classes are
template specializations?
I think I need to draw some inheritance diagrams...
--
John
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
