Pergunta

Eu tenho a seguinte situação:

void function(params)
{
  #ifdef _MULTIPLAYER
    if (isConnected)
    {
      if (isClient)
      {
        requestFunctionRemotely(params)
        return;
      }
      else if (isServer)
      {
        call realFunction(params) remotely on client;
      }
    }
  #endif

  realFunction(params);
}

realFunction(params)
{
  ...
}

Com esta situação, eu sou capaz de construir o meu projeto com o único exemplo do jogador ou multiplayer.

Esta abordagem tem sido usada porque function(params) é chamado todo o meu código, para que desta forma eu basta ligar para o nível mais baixo possível, sem ter problemas.

Eu tinha que dividir o function e realFunction porque remoto respostas recebidas por clientes deve ser executado através de realFunction para evitar loops (eu pudesse mudar o protótipo de função para adicionar um sinalizador, mas eu iria quebrar um monte de código).

A minha preocupação está relacionada com o desempenho quando desactivar o _MULTIPLAYER definir.Eu tenho UM MONTE de function(params) e eu vou chamá-los milhares de vezes.Eu vou ter que usar essa abordagem para todos eles.Vai g++ otimizar distância a chamada em espera quando ele vai encontrar

function(params) {
  realFunction(params);
}

para

function(params) {
  // body of realFunction
}

e não há maneira de forçá-lo a cada situação semelhante?

Apenas como uma dica:Eu uso atualmente o -O2 bandeira

Foi útil?

Solução

Se você quer ter certeza de que você poderia inverter o seu padrão e usar um parâmetro do modelo.De que forma você tem certeza de que o compilador irá remover o if (false) em tempo de compilação.

template <bool isMulti>
void Function(params) 
{ 
    if (isMulti)
        MultiFunction();

    // real function code
} 

void MultiFunction(params) 
{  } 

Nota:

Se trabalhar com uma classe, você pode mover-se até o modelo de parâmetro para a classe de concisão.

Outras dicas

É difícil dizer, mas este geralmente deve ser otimizado (você nunca pode ter certeza e o melhor que você pode fazer é dar algumas dicas, por exemplo,usando inline, mas o compilador normalmente tenta encontrar a melhor solução em si (também baseado em "otimizar tamanho" vs."otimizar a velocidade", ignorando as suas dicas (eles não DEVEM FAZER para ele).

Provavelmente, a melhor (e a prova de falhas) solução seria a escrita do código, de forma a evitar que este completamente, e.g.algo como isto:

type function(params)
{
#ifdef _MULTIPLAYER
    if(client)
    {
        // call server
    }
    else
#endif
    { // this bracket will be ignored, but saves adding another `#ifdef..#endif` block just to close it again below
        // do stuff here
    }
}
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top