Another way to do it is to always have a server process which is authoritative, even when running a single-player game locally. You can even continue communicating over sockets between the two, by using the local loopback address. IIRC, quake worked this way. You also have plenty of other communication channels available locally -- IPC, named pipes, or just adding a layer of abstraction between the "client" and the "server"--one implementation could implement the logic locally, and other could just be a conduit to an actual server across the network.

This isn't a direct answer to your question, but would allow you to re-use your code without resorting to conditionally-enabling or disabling code statements, and it should make using the authoritative code in two different apps (the client and stand-alone server) easier (via static library or DLL) easier if you go that route.

This is easy to solve with a little bit of composition. I'll demonstrate two options in a single source snippet:

// SharedLogic.h
class Berzerker
{
public:
    Matrix4x4 Transform;
    unsigned Health;
 
private:
    bool IsAngry;
 
 
    void MakeAngry()
    {
        IsAngry = true;
        Health += 10;
    }
 
    friend class ServerLogic;
 
 
 
public:
    bool CheckAngry() const
    {
        return IsAngry;
    }
};
 
// Server.cpp
#include "SharedLogic.h"
 
class ServerLogic
{
public:
    void Run()
    {
 
       Berzerker b;
 
       while(ServerActive())
       {
           if(PlayerShotBerzerker(b))
               b.MakeAngry();
 
           // etc. 
       }
 
    }
};
 
int main()
{
    ServerLogic sl;
    sl.Run();
}
 
// Client.cpp
#include "SharedLogic.h"
 
template<typename T>
class Renderable
{
private:
    T SharedLogicObject;
 
public:
    T& GetObject() { return SharedLogicObject; }
    const T& GetObject() const  { return SharedLogicObject; }
 
public:
    void Draw(const Model& model)
    {
        GraphicsApi::DrawModelWithTransform(model, SharedLogicObject.Transform);
    }
};
 
class ServerLogic
{
public:
    static void Update(Berzerker& b)
    {
        if(NetworkSaysBerzerkerIsAngry(b))
            b.MakeAngry();
    }
};
 
int main()
{
    Model happyBerzerker("some.mesh");
    Model angryBerzerker("other.mesh");
 
    Renderable<Berzerker> rb;
 
    while(ClientActive())
    {
        if(PlayerFiredWeapon())
            NotifyServer();
 
        CollectServerResponse();
 
        ServerLogic::Update(rb);
 
        if(rb.GetObject().CheckAngry())
            rb.Draw(angryBerzerker);
        else
            rb.Draw(happyBerzerker);
    }
}

Option One

Your shared logic lives in a file that both client and server can access. Stats which are visible to both can be public; stats which need to be purely server-authoritative can be private with access controlled via friendship. Your ServerLogic class depends on which code you build; on the server, it's the actual authoritative logic, whereas on the client, it simply polls the network for updated state.

Option Two

The way I deal with separating the rendering shows a similar but alternative form of composition. In this case, you build the special logic in terms of the different pieces the client or server needs to work with. In this example, the client has a Renderable<> template which holds the shared logic object as well as enables drawing via a model. The template isn't strictly necessary, but it shows how you can apply broad swaths of rendering logic to all of your shared "entity" code with a simple construct.

Basically neither option is inherently superior, and as above, a blend may work nicely as well. But in general, the idea is you should build your code in small, reusable chunks, and then use (or reuse) them where appropriate on client and server. No need for #ifdefs or other evilness :-)