C++ support?

[fingolfin]

Some of us have been pondering the use of some very limited C++ in the GAP kernel (for now mostly template programming to reduce code duplication, but I guess some other bits could come in handy).

But of course as long as ward does not support C++, that's a no-go, at least if we don't want to give up on HPC-GAP for good.

Then again, I think @rbehrends was working on some C++ support for Singular anyway, and so I am now wondering at which stage that is, and whether we could benefit from it for GAP, too?

[rbehrends]

As a temporary workaround, it is possible to have ward ignore C++ code (e.g. by bracketing it with #ifndef WARD_ENABLED ... #ifdef). We are already doing this for some low-level C code that shouldn't be annotated. These parts of the code may require explicit guards, obviously.

Note that – depending on what you want to do in C++ – it may be possible to have guards handled via C++ mechanisms (e.g. similar to how smart pointers work). This could revolve around wrapping the Obj type and its various instantiations in a C++ type with methods that have the necessary guards. E.g. by having a GapList object that has explicit methods to get and set elements.

The major problem here is that ward actually does data flow analysis of the code. In order to do this for C++, it would require writing a complete C++ parser, unless we are willing to limit ourselves to a manageable subset of C++ or are conforming to specific guidelines. Parsing C++ is very much a non-trivial exercise, unfortunately. It's not impossible, as we don't actually have to parse ALL of C++ (I'm only interested in stuff that manipulates Obj type variables, basically), but it's still work.

What I've been doing for Singular isn't applicable to GAP, as I'm not doing data flow analysis there and don't have to (the main point of my work there is to automatically identify global and static variable declarations and to make them thread-local). That said, there is some overlap, as I've been drawing on the work I'd begun on Ward2 in order to write the C++ scanner and fuzzy parser that I'm using.

[fingolfin]

@rbehrends Thanks for the explanation!

[rbehrends]

To expand on what I wrote above: Assume that you have three types, OpaqueObj, WritableObj, and ReadableObj (the names are placeholders and unnecessarily verbose so that the explanation is easier to understand). OpaqeObj would only have methods to convert an instance into either an instance of WritableObj or ReadableObj by performing a read/write guard check and a typecast; WritableObj would have methods to read and write the underlying GAP object, ReadableObj would have methods to only read the underlying GAP object.

This is not perfectly safe, because an unlock operation could occur mid-function, but such a case should be easy to spot by code review. We could also have a debug mode, where constructors and destructors of WritableObj and ReadableObj track the number of open instances and have unlock operations raise an error if that happens.

[fingolfin]

This sounds like an interesting approach, though some more details will be needed to implement it, I guess. It sounds to me like you are proposing using RAII pattern for accessing the content of Obj. Your OpaqueObj really would be the current Obj, but we'd replace accessors like ADDR_OBJ or PTR_BAG by methods of ReadObj and ReadWriteObj classes. Right? Wrong? Something like this pseudo-code:

class ReadObj {
  ReadObj(Obj obj) : _wrappedObj(obj) {
#ifdef HPCGAP
    ... read guard check
#endif
  }
#ifdef HPCGAP
  ~ReadObj() { ... unlock ... }
#endif
  const Obj *getAddr() { ... } // can only read
private:
  const Obj _wrappedObj;
}

class ReadWriteObj {
  ReadWriteObj(Obj obj) : _wrappedObj(obj) {
#ifdef HPCGAP
    ... write guard check
#endif
  }
#ifdef HPCGAP
  ~ReadWriteObj() { ... unlock ... }
#endif
  Obj *getAddr() { ... } // can read & write
private:
  const Obj _wrappedObj;
}

and then in code:

int MyKernelFunc( Obj a, Obj b ) {
  if ( IS_INTOBJ(a) ) { // is OK, as this only inspects the bitpattern of a
    return 42;
  } else if (...) {
    ReadObj A(a);
    WriteObj(b).getAddr()[0] = a.getAddr()[2];
  }
  return 0;
}

For non-HPC-GAP mode, the wrapper objects hopefully can be removed with zero cost by the compiler.

But how would we get there incrementally? Rewriting the whole kernel and then "flipping a switch" one day won't do it. We'd also need adapt all kernel extensions -- though we likely need to do that for HPC-GAP anyway). Thing is, in order to use these new objects, we'd have to use C++, but then we can't necessarily use ward (well, perhaps we can if the code keeps "looking" like C?).

[rbehrends]

C++ code could be used selectively and we could also add better support to Ward for ignoring sections of code without having to do it via the preprocessor (which should be fairly straightforward).

I'll also add that this approach could be used with C as well, not just C++, it would just be a bit more verbose.