Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • openfoam openfoam
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 381
    • Issues 381
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 13
    • Merge requests 13
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • openfoamopenfoam
  • Issues
  • #1304

Closed
Open
Created May 01, 2019 by Mark Olesen@markMaintainer

template specialization for processorFvPatchScalarField

@andy @Mattijs

While doing the mingw port I keep hitting a very strange compilation issue. It complains about duplicate thunks for processorFvPatchField<scalar>::initInterfaceMatrixUpdate etc. Oddly enough, it doesn't have any problem with processorFaPatchField<scalar>::initInterfaceMatrixUpdate which is structured exactly the same way.

I've looked high and low, but can't find anything indicating duplicate inclusion of the file. Also tried with including the declaration of the specialization into processorFvPatchField.H itself.

To make a virtue out of a necessity, I simply discarded the specialization and made an 'in-line' specialization within processorFvPatchField.C itself. For example,

// Consume straight from scalarReceiveBuf_
 
if (!std::is_fundamental<Type>::value)
{
    // Transform according to the transformation tensor
    transformCoupleField(scalarReceiveBuf_, cmpt);
}

This will skip the transformCoupleField for label, scalar, solveScalar etc and thus does the same as the template specialization. For C++11, the compiler will presumably be intelligent enough to remove this as unused code (depending on the type). For C++17 the if-constexpr means that it will definitely be removed, as if it were a templated bit of code.

From my perspective, I think that this would be a reasonably good change to make since it does remove some code duplication (and helps with my compilation).

  • Anything that I might be missing?
  • Any other places with template specialization could also be addressed like this?
Edited May 01, 2019 by Mark Olesen
Assignee
Assign to
Time tracking