Static assert that source code does not change in C++

Question

Say I have a method that must not change. Is there a way in C++ to create a compile time error (or runtime if compile time is impossible) if such a method changes?

There are many uses of such a method (consider ficky threading or security issues that you don't want a novice co-worker changing). My particular use case is in maintaining backwards compatibility where some old methods such as persistent data deserializers must not change.

I'm imagining something like the following:

static_assert(chechsumOfBelowFunction() != 0x123,
  "You changed the method! We can't do this because...")
std::string getRelaseDateForVersion3()
{
    // This should never change because "Version 3" was
    // only released once!
    return "2014-Jan-01";
}

Where checksumOfBelowFunction() computes a checksum or some other unique representation of the function (preferably cross platform) at compile time and 0x123 is the known reference checksum of what the function must stay as. Note that I've taken quite a bit or liberty with pseudo code but I hope I convey what I'm trying to do.

Answer 1

Say I have a method that must not change. Is there a way in C++ to create a compile time error (or runtime if compile time is impossible) if such a method changes?

No, there is no way (especially if you care about behavior, not source code). Remember that equality of behavior of two functions is an undecidable problem (equivalent to the Halting Problem). In other words, equivalence of lambda terms (i.e. of two C++ programs or subprograms or functions) is undecidable.

And your requirement (of a function or method that "should not change") is ill-defined. What if the C++ source file is just re-indented? Or a typo in some comment is corrected? Or the name of some local variable has simply changed? Or for readability reasons a for loop is replaced with some equivalent while? Or some linear scan replaced by a more efficient dichotomical approach; etc....!

Perhaps you could put that function in its own source file, compute some cryptographic hash of it, and put that in your build process (e.g. your Makefile for make).

You could spend months of work on more fancy approaches (e.g. customize your GCC compiler, perhaps with some extension in GCC MELT or some GCC plugin, to compute inside your g++ compiler an hash of the GIMPLE AST of your function which should stay the same, etc...). I am not sure it is worth the effort.

---

You could have some timestamp machinery.

In many of my Makefile-s I generate a __timestamp.c file e.g. like:

__timestamp.c: Makefile
    @(date +'const char bismon_timestamp[]="%c";'; \ 
     date +'%n const unsigned long bismon_timelong=%sL;' > __timestamp.tmp)
    @(echo -n 'const char bismon_lastgitcommit[]="' ; \
       git log --format=oneline --abbrev=12 --abbrev-commit -q  \
         | head -1 | tr -d '\n\r\f\"\\\\' ; \
       echo '";') >> __timestamp.tmp
    @(echo -n 'const char bismon_lastgittag[]="'; \
          (git describe --abbrev=0 --all || echo '*notag*') \
          | tr -d '\n\r\f\"\\\\'; echo '";') >> __timestamp.tmp
    @(echo -n 'const char bismon_checksum[]="'; cat bismon.h \
      $(BM_HEADERS) $(CSOURCES) | $(MD5SUM) \
     | cut -d' ' -f1 | tr -d '\n\r\f\"\\' ; echo '";') >> __timestamp.tmp
    @(echo -n 'const char bismon_directory[]="'; \
       /bin/pwd | tr -d '\n\\"' ; echo '";') >> __timestamp.tmp
    @(echo -n 'const char bismon_makefile[]="'; \
      echo -n  $(realpath $(lastword $(MAKEFILE_LIST))); \
      echo '";') >> __timestamp.tmp
    @mv __timestamp.tmp __timestamp.c

and then I link __timestamp.o in the executable; you could configure your build automation tool likewise.

---

I have a method that must not change.

Notice that this is a social requirement (related to code reviews), not a software one. Code does change (you want to avoid technical debt by code refactoring). Your team should wisely use some good version control software (e.g. git) and you have to somehow trust your colleagues (a malicious competent developer could always do bad things).

^{(it looks like some XY problem; perhaps you are seeking a purely technical solution to a social problem)}

My particular use case is in maintaining backwards compatibility where some old methods such as persistent data deserializers must not change.

The usual way is to record in the persisted data a version (or signature) of the used format. For inspiration look into ELF or simply the XML version declaration (XMLDecl).

^{(papers on dynamic software updating could interest you)}