#include <jni.h>
JNIEXPORT class MyClass
{
public:
// PUBLIC AREA MUST BE BLANK
protected:
// PROTECTED AREA MUST BE BLANK
private:
// PRIVATE AREA IS ALLOWED for Print functioin only
virtualvoid Print()
{
cout << "MyClass" << endl;
}
};
1 2 3 4 5 6 7 8 9 10 11
publicclass MyClass
{
private native void Print();
publicstaticvoid main(String[] args)
{
System.loadLibrary("MyClass");
MyClass mc = new MyClass();
mc.Print();
}
}
That's using the JNI interface through Java. Apparently, friends are no longer the only ones that want to touch your privates. Think of Java as the sex-offender next-door.
Disclaimer: I didn't compile / test the above code, but it's similar to a job that I'm working on now.
As I'm not smart enough to code-cheat my way around it, I'll apply my methodology of assumption-based cheating:
Assumption 1: "Can't change this class!" is enforced by keeping the class definition in a different file so the tester knows it hasn't been changed.
Assumption 2: Since the one and only rule is strictly enforced by assumption 1, the tester only needs to confirm the output to check the correctness.
Hahaha Gaminic - I thought it was implicitly disallowed because the idea was to call the print function in the class I gave rather than just do what it would have done. Clever and unique, but not the intended solution ;)