dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

Anders Logg wrote:
> ok, *now* I know what the problem is.
> 
> You will get the same error if you replace LSM_grad.h with the
> following code:
> 
>   #ifndef __FOO_H
>   #define __FOO_H
> 
>   class Foo
>   {
>   public:
> 
>     int foo();
> 
>   };
> 
>   int Foo::foo() { return 0; }
> 
>   #endif
> 
> If, on the other hand, you define foo() directly in the class
> definition:
> 
>   #ifndef __FOO_H
>   #define __FOO_H
> 
>   class Foo
>   {
>   public:
> 
>     int foo() { return 0; }
> 
>   };
> 
>   #endif
> 
> then everything will compile. (You also need to change Class1 -->
> Class2 in Class2.cpp).
> 
> I few fixes were made to FFC to get around some problems with SWIG not
> being able to handle nested classes. Some function definitions were
> then moved outside the classes and as a result we get this problem.
> 

Does SWIG need to know about the nested classes? If not, this

http://swig.cvs.sourceforge.net/*checkout*/swig/SWIG/Doc/Manual/SWIGPlus.html#SWIGPlus_nested_classes

(this first one) seems like a pretty simple work around.

Garth

> We are working on a new specification for the code that is being
> generated by FFC (UFC - Unified Form-assembly Code). The plan is to
> support this in the next version of FFC. Then this won't be a problem.
> 
> In the meantime, just include the form-file in one place, declare the
> form object and send it around to each class that needs it (if
> possible).
> 
> /Anders
> 
> 
> 
> On Mon, Oct 30, 2006 at 10:57:53AM +0100, Garth N. Wells wrote:
>>
>> Anders Logg wrote:
>>> I think I found the problem. Look in your file Class2.cpp:
>>>
>>>   #include "Class1.hpp"
>>>
>>>   using namespace dolfin;
>>>
>>>   Class1::Class1()
>>>   {}
>>>
>>> Notice something wrong? :-)
>>>
>> I saw this too, but is doesn't help. You can get rid of Class2
>> completely and the problem remains. The code in LSM_grad.h still gets
>> compiled into Class1.o and main.o.
>>
>> Garth
>>
>>> /Anders
>>>
>>>
>>> On Mon, Oct 30, 2006 at 10:44:09AM +0100, Garth N. Wells wrote:
>>>> Dag Lindbo wrote:
>>>> ...
>>>>
>>>>>>> I'm no C++ boffin, but it seems to me the the linker (g++) is getting
>>>>>>> confused over the fact there is code in the form headers that has been
>>>>>>> compiled multiple times (once for each class that uses the particular
>>>>>>> form)  . Did libtool do a better job at figuring this out? How do I use
>>>>>>> libtool?
>>>>>>>
>>>>>> Can you give a stripped down example where it goes wrong?
>>>>> The attached files are _very_ simple. Just two classes (that do nothing)
>>>>> and a main (that does nothing). /Dag
>>>>>
>>>> The problem seems to stem from LSM_grad.h containing definitions
>>>> and not just declarations. The definitions are compiled each time they
>>>> appear. I'm not sure how to get around it. Note that if you put the
>>>> definitions for Class1 and Class2 into the header files and remove
>>>> Class1.cpp and Class2.cpp, everything works.
>>>>
>>>> Garth
>>>>
>>>>
>>>>>> Garth
>>>>>>
>>>>>>> /Dag
>>>>>>>
>>>>>>>> Garth
>>>>>>>>
>>>>>>>>> Thanks a lot!
>>>>>>>>> Dag Lindbo
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> DOLFIN-dev mailing list
>>>>>>>>> DOLFIN-dev@xxxxxxxxxx
>>>>>>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>>>>>>>>
>>>>
>>>> _______________________________________________
>>>> DOLFIN-dev mailing list
>>>> DOLFIN-dev@xxxxxxxxxx
>>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>> _______________________________________________
>>> DOLFIN-dev mailing list
>>> DOLFIN-dev@xxxxxxxxxx
>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>>>
>>
>> _______________________________________________
>> DOLFIN-dev mailing list
>> DOLFIN-dev@xxxxxxxxxx
>> http://www.fenics.org/mailman/listinfo/dolfin-dev
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>