[olesen]

Originally Posted by melanie

Ok, I should have written

autoPtr<myProcessorMeshes> procMeshes;

The class is named myProcessorMeshes, the variable is procMeshes.
But still I do not understand the details of the implementation you suggested with the autoPtr, I did not find documentation about this. And I don't know either if there is a subclass in all this. And it still does not work ! Please excuse my mistakes that may seem trivial to you, I am just learning C++ and OF programming...

Sorry, you should trust the documentation before you trust the coding quality of posts. And I obviously didn't check the docs before posting my suggestion (sorry for the confusion).

This might work better,

autoPtr<myProcessorMeshes> procMeshes;
if (USE_DECOMP_CONDITION)
{
   procMeshes.set(new myProcessorMeshes( ...));
}

but please be safe and read the documentation (http://foam.sourceforge.net/doc/Doxy..._1autoPtr.html) or the header files before believing me (or anyone).

[melanie]

Thanks again and again Mark, now it is working fine!
Actually I also had to modify the lines where functions of procMeshes are called; since procMeshes is now a pointer and no more a variable,

procMeshes.readUpdate()

for instance does not work. I have written instead

procMeshes->readUpdate()

It is good programming?

Is anyone interested in this utility, either to test and/or to use it?

Anyway, many thanks for your patience Mark, I know I got much to learn left on C++ and OF-programming! I think that on the same model, I will modify foamToTecplot utility to include this reconstruction option.

melanie

[olesen]

Originally Posted by melanie

I have written instead

procMeshes->readUpdate()

It is good programming?

There is nothing wrong or dangerous about it, but I would normally prefer to write it like this:

autoPtr<myProcessorMeshes> procMeshesPtr;
// ... some logic here

myProcessorMeshes& procMeshes = procMeshesPtr();

// or with const-only access
 const myProcessorMeshes& procMeshes = procMeshesPtr();

// .. later
procMeshes.readUpdate();

This would let you reuse most of the existing code needing to change the '.' to '->' everywhere. It also provides a *slightly* better measure against passing about invalid pointers.

Check the autoPtr docs again for information about the autoPtr:perator() methods.

[olesen]

Hi Melanie,
Any more progress to report?
/mark

[melanie]

Hello Mark,

Actually I was able to successfuly correct my code with your latest suggestions. However, about one week after that, the machine on which I used to compile crashed. And on the other machines, I always have a compilation error, even with code written by others (like foamToTecplot utility). I did not post a bug description since I am not sure of where is the problem, OF paths or Linux Suse version, or something else.

The real problem is that I am also unable to use the code compiled previously; the same error as on compilation is issued, saying

~/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so: file not recognized: File format not recognized

It is looking for libraries without finding them; everything is at its correct place, since the bug nothing else changed; OF is installed on my home directory so I really don't understand what's going on...

mélanie

[olesen]

Originally Posted by melanie

The real problem is that I am also unable to use the code compiled previously; the same error as on compilation is issued, saying

~/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so: file not recognized: File format not recognized

It is looking for libraries without finding them; everything is at its correct place, since the bug nothing else changed; OF is installed on my home directory so I really don't understand what's going on...

This sound really ugly. Perhaps a filesystem error?
What does the 'file' command report?
eg,

$ file ~/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so

Mine reports
"ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped"

If that reports okay, but you still have problems, see if the symbol table looks intact (eg, objdump -t ~/OpenFOAM/OpenFOAM-1.6/lib/linux64GccDPOpt/libfiniteVolume.so).

Beyond that it's hard to say what's wrong.

[melanie]

The answer to the "file" command is:

ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped

I do not have the "dynamically linked" attribute, and the answer to the "objdump -t" command is

File format not recognized

Do you know what it means?

[olesen]

Originally Posted by melanie

the answer to the "objdump -t" command is

File format not recognized

Do you know what it means?

Whatever it means, it doesn't sound good.
Have you tried recompiling finiteVolume recently? It would probably help (and can't hurt).

[melanie]

Actually on another machine the reply to the last command is a bit different, and the compilation error is also different. It seems similar to what is reported in this thread so I will firstly try to compile GCC on one of my machines and see if this helps...