C/C++: @abstract "true" does not work

[vassik]

can get it write, on compilation get something like

[java.lang.UNIXProcess@f19d78 ERR] ThingDeSerializer.cpp: In function ‘void f_ThingDeSerializer_forward(ThingDeSerializer_Instance*)’:
[java.lang.UNIXProcess@f19d78 ERR] ThingDeSerializer.cpp:99:6: error: redefinition of ‘void f_ThingDeSerializer_forward(ThingDeSerializer_Instance*)’
[java.lang.UNIXProcess@f19d78 ERR] ThingDeSerializer.cpp:26:6: error: ‘void f_ThingDeSerializer_forward(ThingDeSerializer_Instance*)’ previously defined here

[nharrand]

What should be the behaviour of the @abstract annotation? Is the concept still useful? Is the problem still exist or shall I implement it?

[brice-morin]

If I remember well, it is basically like abstract function in Java. Let's say you have a PIM thing, whose behavior depends on an abstract f(). The implementation of f() being platform-specific, you still want to be able to use (call) f in your PIM thing, for example here. Then a PSM thing that would include the PIM thing would need to provide implementation for f(). The compiler should only consider the PSM f() in the end, and somewhat ignore the abstract f() (so that we do not end-up with many function f() defined in the code).

I found those abtract functions somewhat useful at some point, but we can discuss with @vassik and @ffleurey to see if we still need them. Also, this is very related to HEADS-project/heads_ide#44

Basically the whole point is to be able to have "interfaces" also for the synchronous behavior (functions) and not just for the asynchronous behavior (ports).

[brice-morin]

Actually, I added the support for asbtract functions (and probably did not really test it :-)) in the old C compiler. Not sure if @ffleurey or @Lyadis migrated this behavior in the new compiler...

See https://github.com/SINTEF-9012/ThingML/commit/4aeccd7bdf2f7622d0bd0697162c88bd3efd8688

[nharrand]

The problem seems to be resolved. (See testAbstractFunction.thingml)