|
[Sponsors] |
It has to include complete definition of a type (not just fwd declaration), isn't it? |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
August 12, 2016, 17:59 |
It has to include complete definition of a type (not just fwd declaration), isn't it?
|
#1 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 |
While scanning the source code of OpenFoam 4.x I see this file files which lists sources to be build into finiteVolume library:
Code:
//--- src/finiteVolume/Make/files --- ... finiteVolume/fvc/fvcFlux.C ... LIB = $(FOAM_LIBBIN)/libfiniteVolume Code:
//--- src/finiteVolume/fvc/fvcFlux.C --- #include "fvcFlux.H" #include "surfaceInterpolate.H" ... Foam::tmp<Foam::surfaceScalarField> Foam::fvc::flux ( const volVectorField& vvf ) { return scheme<vector> ( vvf.mesh(), "flux(" + vvf.name() + ')' )().dotInterpolate(vvf.mesh().Sf(), vvf); } ... Code:
//--- src/finiteVolume/fvc/fvcFlux.H --- #include "volFieldsFwd.H" #include "surfaceFieldsFwd.H" ... Code:
//--- src/finiteVolume/interpolation/surfaceInterpolation/surfaceInterpolation/surfaceInterpolate.H #include "tmp.H" #include "volFieldsFwd.H" #include "surfaceFieldsFwd.H" #include "surfaceInterpolationScheme.H" #include "one.H" ... Code:
//--- src/finiteVolume/fields/volFields/volFieldsFwd.H #include "fieldTypes.H" class volMesh; template<class Type> class fvPatchField; template<class Type, template<class> class PatchField, class GeoMesh> class GeometricField; typedef GeometricField<scalar, fvPatchField, volMesh> volScalarField; typedef GeometricField<vector, fvPatchField, volMesh> volVectorField; typedef GeometricField<sphericalTensor, fvPatchField, volMesh> volSphericalTensorField; typedef GeometricField<symmTensor, fvPatchField, volMesh> volSymmTensorField; typedef GeometricField<tensor, fvPatchField, volMesh> volTensorField; ... |
|
August 12, 2016, 18:34 |
|
#2 |
Super Moderator
Tobias Holzmann
Join Date: Oct 2010
Location: Bad Wörishofen
Posts: 2,711
Blog Entries: 6
Rep Power: 52 |
Hi Zeppo,
nice post (clear and with all information). Here, you need only the forward declaration nothing more. Why? It is easy, we are building libraries and for that the compiler just need to know the class but not the definition of classes (just needed if you make an instance and hence you need to allocate memory).
__________________
Keep foaming, Tobias Holzmann |
|
August 13, 2016, 11:49 |
|
#3 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 |
Tobias, I don't think your answer is correct. Look at fvcFlux.C ance again:
Code:
//--- src/finiteVolume/fvc/fvcFlux.C --- #include "fvcFlux.H" #include "surfaceInterpolate.H" ... Foam::tmp<Foam::surfaceScalarField> Foam::fvc::flux ( const volVectorField& vvf ) { return scheme<vector> ( vvf.mesh(), "flux(" + vvf.name() + ')' )().dotInterpolate(vvf.mesh().Sf(), vvf); } ... 1. To ensure that the very method volVectorField::mesh() do exist. If not (or it is private/protected), it searches for mesh() in volVectorField's base classes. 2. If function mesh() is found, the compiler must know it's return type so that it can ensure that the return type matches (possible with additional conversion) the type of the input parameter for function scheme<vector>: Code:
//--- src/finiteVolume/interpolation/surfaceInterpolation/surfaceInterpolation/surfaceInterpolate.H ... //- Return weighting factors for scheme given from Istream template<class Type> static tmp<surfaceInterpolationScheme<Type>> scheme ( const fvMesh& mesh, Istream& schemeData ); ... So the question is still open: how the compiler can "see" the definition of GeometricField<scalar, fvPatchField, volMesh>? I can't. |
|
August 13, 2016, 13:11 |
|
#4 |
Super Moderator
Tobias Holzmann
Join Date: Oct 2010
Location: Bad Wörishofen
Posts: 2,711
Blog Entries: 6
Rep Power: 52 |
Maybe your are correct if you say that I am wrong... I have not time to check it in such detail. But here is the way it should be. First of all. The method volVectorField::mesh does not exist because the volVectorField is just a typedef from the GeometricField and even this has no function called mesh(). You have to dig deeper because the ::mesh() function you are referring to is inherit by the DimensionedField class.
The problem you mentioned, that the compiler need to know everything is correct (here I was wrong). But luckily it knows everything. The first stuff that the compiler gets to know is the pre-compiled library called libOpenFOAM.so (Make/options). The volFields are included in line 231 in the Make/files file (src/finiteVolume) and here the compiler gets all information about the field (how they are build and which function is inherit by the classes). The compilation of you file fvcFlux.C comes in line 395. So the compiler knows the fields.
__________________
Keep foaming, Tobias Holzmann |
|
August 13, 2016, 14:01 |
|
#5 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 |
Believe me or not, Tobias, volVectorField::mesh() is literally the same as GeometricField<scalar, fvPatchField, volMesh>::mesh(). If volVectorField::mesh() does not exist, GeometricField<scalar, fvPatchField, volMesh>::mesh() does not exist either.
While a compiler does its job compiling a source file it doesn't care about any object code (object files (.o), static libraries (.a), shared libraries (.so)). Compiler goes in loop though all files listed in Make/files compiling each file independently. To be more specific, it is not a source file, it is a compilation unit to be compiled which is what the compiler see when the content of all #includes have been inserted into the source file by a preprocessor. fvcFlux.C and volFields.C are in different compilation units and don't see each other. Source files can ever be compiled in parallel independently. When all files have been compiled into object files, the linker teakes over building either a library or executable. |
|
August 13, 2016, 15:12 |
|
#6 |
Super Moderator
Tobias Holzmann
Join Date: Oct 2010
Location: Bad Wörishofen
Posts: 2,711
Blog Entries: 6
Rep Power: 52 |
Hello Sergei,
I am sorry for the non-helpful answers.
Code:
src cd finiteVolume wclean Code:
shorty@finiteVolume: wmake libso /home/shorty/OpenFOAM/OpenFOAM-4.x/src/finiteVolume wmakeLnInclude: linking include files to ./lnInclude Making dependency list for source file finiteVolume/fvc/fvcFlux.C g++ -std=c++0x -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -O3 -DNoRepository -ftemplate-depth-100 -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/triSurface/lnInclude -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/meshTools/lnInclude -IlnInclude -I. -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/OpenFOAM/lnInclude -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/OSspecific/POSIX/lnInclude -fPIC -c finiteVolume/fvc/fvcFlux.C -o /home/shorty/OpenFOAM/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/src/finiteVolume/finiteVolume/fvc/fvcFlux.o g++ -std=c++0x -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -O3 -DNoRepository -ftemplate-depth-100 -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/triSurface/lnInclude -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/meshTools/lnInclude -IlnInclude -I. -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/OpenFOAM/lnInclude -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/OSspecific/POSIX/lnInclude -fPIC -shared -Xlinker --add-needed -Xlinker --no-as-needed /home/shorty/OpenFOAM/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/src/finiteVolume/finiteVolume/fvc/fvcFlux.o -L/home/shorty/OpenFOAM/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/lib \ -lOpenFOAM -ltriSurface -lmeshTools -o /home/shorty/OpenFOAM/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so '/home/shorty/OpenFOAM/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so' is up to date. Code:
3.2.2.1 Including headers The compiler searches for the included header files in the following order, specified with the -I option in wmake:
Two things that I learned
I hope that this is now the answer to your question and I am sorry for the first two useless answers. To sum up: You were right in all points and the missing definition comes from the header files that are included automatically by wmake (src/OpenFoam/lnInclude)
__________________
Keep foaming, Tobias Holzmann Last edited by Tobi; October 14, 2017 at 08:03. |
|
August 13, 2016, 17:43 |
|
#7 | |||
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 |
Quote:
Code:
//--- src/finiteVolume/fvc/fvcFlux.C --- #include "fvcFlux.H" #include "surfaceInterpolate.H" ... Foam::tmp<Foam::surfaceScalarField> Foam::fvc::flux ( const volVectorField& vvf ) { return scheme<vector> ( vvf.mesh(), "flux(" + vvf.name() + ')' )().dotInterpolate(vvf.mesh().Sf(), vvf); } ... Code:
#include "fvcFlux.H" #include "surfaceInterpolate.H" Quote:
I don't have my OpenFoam environment at hand. Please, can you show what you have in fvcFlux.dep file when you have compiled fvcFlux.C. According to the UserGuide this file (fvcFlux.dep) contains a list of files which fvcFlux.C depends on. Here the cite from UserGuide: Quote:
|
||||
August 13, 2016, 18:23 |
|
#8 |
Super Moderator
Tobias Holzmann
Join Date: Oct 2010
Location: Bad Wörishofen
Posts: 2,711
Blog Entries: 6
Rep Power: 52 |
I was lying on my couch when I got the point. Based on the include files of the fvcFlux.H, there is no file that includes the header of the GeometricField.H file. Finally I got your question. Hmmm... there is also no fvcFlux.dep file.
Code:
#ifdef NoRepository #include "fvcFluxTemplates.C" #endif
__________________
Keep foaming, Tobias Holzmann |
|
August 13, 2016, 20:10 |
|
#9 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 |
As UserGuide says, fvcFlux.dep should be in your Make/linux64GccDPInt32Opt/
Even if DimensionedField.H was included into fvcFlux.C (through fvcFluxTemplates.C) it wouldn't help much as the compiler still doesn't know that GeometricField is inherited from DimensionedField so the compiler can't allow invocation of any DimensionedField's methods from an object of GeometricField type. Agree? I am still at the position where I started from: there seems to be no trace of GeometricField.h in fvcFlux.C file. |
|
August 13, 2016, 20:37 |
|
#10 | |
Super Moderator
Tobias Holzmann
Join Date: Oct 2010
Location: Bad Wörishofen
Posts: 2,711
Blog Entries: 6
Rep Power: 52 |
Quote:
__________________
Keep foaming, Tobias Holzmann |
||
August 14, 2016, 06:49 |
|
#11 |
Super Moderator
Tobias Holzmann
Join Date: Oct 2010
Location: Bad Wörishofen
Posts: 2,711
Blog Entries: 6
Rep Power: 52 |
Dear Zappo,
I checked the *dep file now and indeed there is the GeometricField.H included: Code:
$(OBJECTS_DIR)/finiteVolume/fvc/fvcFlux.C.dep: \ finiteVolume/fvc/fvcFlux.C \ finiteVolume/fvc/fvcFlux.H \ lnInclude/volFieldsFwd.H \ $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/fieldTypes.H \ $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/label.H \ $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/int.H \ $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/int32.H \ ... $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/GeometricField.H \ $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/dimensionedTypes.H \ $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/dimensionedVector.H \ $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/dimensionedSphericalTensor.H \ $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/dimensionedSymmTensor.H \ ... $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/GeometricField.C \ $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/GeometricBoundaryField.C \ $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/emptyPolyPatch.H \ ...
__________________
Keep foaming, Tobias Holzmann |
|
August 14, 2016, 10:32 |
|
#12 |
Senior Member
Sergei
Join Date: Dec 2009
Posts: 261
Rep Power: 21 |
Now, it would be a good thing to have someone explain how that $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/GeometricField.H got into fvcFlux.C's dependency list. Tobias, any ideas?
|
|
August 16, 2016, 15:01 |
|
#13 |
Super Moderator
Tobias Holzmann
Join Date: Oct 2010
Location: Bad Wörishofen
Posts: 2,711
Blog Entries: 6
Rep Power: 52 |
Hello Zappo,
I was searching one hour yesterday to figure out where the place is, that includes the header of GemoetricField.H. Unfortunately I could not find the file. Now I am also very interested how this works. If you figure it out, I would be glad to hear the answer. Maybe wyldckat could know it?
__________________
Keep foaming, Tobias Holzmann |
|
Tags |
compiler, complete definition, forward declaration, include |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
compilation problem with "fvPatch::lookupPatchField" | Ya_Squall2010 | OpenFOAM Programming & Development | 9 | November 15, 2021 23:01 |
Modified pimpleFoam solver to MRFPimpleFoam solver | hiuluom | OpenFOAM Programming & Development | 12 | June 14, 2015 22:22 |
LES supersonic free jet | martyn88 | OpenFOAM | 22 | April 17, 2015 07:00 |
T Junction Stability | ignacio | OpenFOAM Running, Solving & CFD | 5 | May 2, 2013 11:44 |
Problems in compiling paraview in Suse 10.3 platform | chiven | OpenFOAM Installation | 3 | December 1, 2009 08:21 |