Interface wouldn't work, the variables would be local to the object still.
By 'C style', do you mean having a singleton-style variable that is a STRUCT with all your globals in some kind of header, and each file has an include of that header? If so, that's exactly what having a separate unit and including it in uses clause does.
If you want to be OO, rather than STRUCT/record based, you could have a global.pas, and define
type
TGlobals=class
//your globals go here
// either make everything public, like a glorified record,
// or use properties with proper accessors...
public
constructor create; //do default values here
destructor destroy; override; //free any created resources
end;
var Globals:TGlobals
then at the end of the implementation..
initialization
Globals:=TGlobals.create;
finalization
Globals.Free;
end.
You then have a Globals object which can be passed around. For extra security, you could put class functions in to reference count (or descend from TInterfacedObject and override the AddRef) and generate an exception if more than 1 object is created at a time, to ensure the singleton status. Of course, if it's your own code, and only you will manage it, then that might be overboard for what you need.
How very smalltalk, how very Eiffel
I often have a unit with just consts and globals, or a file with each. I've never seen the point of making an object when I don't have to, there's the advantages and disadvantages, but overall, if there's just a value in memory, I would prefer direct access rather than through an accessor.
Be aware that your globals won't be thread safe. To ensure thread safety, then it
would be worth making an object, and having properties with write methods which use critical sections. Examine your needs, and act accordingly
DSP