Log/Trace Condicional

[Fabio Mazzarino]

Há alguns anos eu trabalhei num time no qual havia um monte de entrada no código mais ou menos assim:

char *logtrace = ::getenv("LOGTRACE");

// ...
if (logtrace) std::cout << "*** Starting CUtil::promoteSale ***" << std::endl
if (logtrace) std::cout << "* Arg saleID: " << saleID << std::endl;

O código ficava esquisito cheio desses ifs e td mais. Eu até tentei propor uma solução, mas os desenvolvedores mais antigos não gostavam da proposta.

Esse foi um dos primeiros posts do Lab C++:

https://labcpp.com.br/trace-condicional/

Eu tb propus um exercício no post, mas nunca publique a soluição, e aí? Vcs querem a solução? Não é tão difícil assim, é?

[de...@roo.com.br]

ficou interessante.

quando preciso de algo assim, uso:

https://github.com/yksz/c-logger

https://log4c.sourceforge.net/

[Fabrício Cabral]

Fabio,

Não está faltando um ")" no #define LOGTRACE ?

Em tempo: mesmo com a sua solução, ainda vai ter o overhead de vários if's, certo? Há alguma solução que permita ativar/desativar os logs sem ter este overhead?

At.te.

--
http://ccppbrasil.github.io/
https://twitter.com/ccppbrasil
 
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
---
Você recebeu essa mensagem porque está inscrito no grupo "ccppbrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para ccppbrasil+...@googlegroups.com.
Para ver esta conversa, acesse https://groups.google.com/d/msgid/ccppbrasil/2d1dda57-8163-43b4-8436-2b4ff261d6b0n%40googlegroups.com.

--

--fx

[Augusto Rodrigues]

Como assim overhead de ifs?

Tipo por ser macro o codigo vai ficar cheio de ifs, mesmo que o dev não veja esses ifs durante a edição do código.

Para nao aumentar o codigo, uma solução seria atrelar a macro LOGTRACE uma chamada de função que emitiria o log.

E essa macro pode ser vazia quando o dev for entregar o código para produção.

Dessa forma poderia diminuir o overhead de código por causa dos ifs

Para ver esta conversa, acesse https://groups.google.com/d/msgid/ccppbrasil/CAKUebb9wz_QuN2CZt8wz5OANDoq8XLQO7qe_vdEwRoDQVeDjQQ%40mail.gmail.com.

[Fabio Mazzarino]

Fabrício:

De fato, estavam faltando os parênteses. Posso citar seu nome no edit da correção? Quer que eu coloque algum link no teu nome?

Sobre sua dúvida.

De fato existe a possibilidade de adicionar o overhead por conta de tantos ifs no código, mas vamos começar voltando para os computadores 8 bits.

Falando de 8 bits esse ifs iriam gerar o seguinte código, lembre-se que estamos testando se uma variável contém 0:

LDA @LOGTRACE

XRA A

JNZ @NEXT1

Então se estivermos falando de 8 bits, esse teste pode, sim gerar algum overhead. Mas conforme a gente vai avançando na tecnolgia, a qtde de registros, opcodes mais eficientes, e testes diretos a partir da memória, vai tudo deixando mais rápido e mais prático.

Mas se a gente pensar oq vai acontecer em caso de sucesso no if, que é uma operação de I/O, possívelmente em disco, overhead para de ser uma preocupação.

Adicionalmente a chamada de macro evita a chamada de uma função, esse sim *talvez* possa ser considerado, dependendo do sistema.

No caso específico do sistema que citei no post, ele rodava inicialmente em ambiente RS/6000 POWER3, e depois foi migrado para ambiente virtualizado, mas ainda assim RISC. O overhead era considerado irrelevante.

A questão de fato que levantei no post, não era de performance, e sim de semântica. Utilizando a macro o código fica mais limpo e fácil de entender, evitando a profusão de ifs, e deixando o código muito mais limpo e fácil de compreender.

[Fabio Mazzarino]

Pessoal que manja de assembly, há algumas décadas não tenho contato com assembly de 8085, desculpe se escrevi alguma besteira nas poucas linhas de assembly que escrevi.

[Fabrício Cabral]

Olá Fabio!

Não precisa citar meu nome por um typo. Já fico feliz por te ajudado!

Quanto ao overhead, eu pensei em algo assim:

#ifdef LOG

char *logtrace = ::getenv("LOGTRACE");

// ...

if (logtrace) std::cout << "*** Starting CUtil::promoteSale ***" << std::endl
if (logtrace) std::cout << "* Arg saleID: " << saleID << std::endl;

#endif

Então ativaria/desativaria o log. O problema é que teria que recompilar, o que pode demorar. Mas isso seria apenas para jogar no ambiente de produção.

Só que esta abordagem não evita a "poluição" do código, o que afetaria a legibilidade. Aí este problema ficaria em "aberto".

At.te.

Para ver esta conversa, acesse https://groups.google.com/d/msgid/ccppbrasil/65b58959-f533-46df-ae7e-8d9d23a568e0n%40googlegroups.com.

--

--fx

[Fabio A Mazzarino]

Fabrício:

Sem dúvida alguma resolveria a questão do overhead qdo for significativa.

No caso do time em questão essa solução não atenderia, pois eles precisavam de um trace que seria ativado facilmente através de uma mudança bem simples, sem mudar o binário.

O intuito do trace era fazer com que o binário que estivesse em produção gerasse dados sem que ele fosse alterado, somente através de uma configuração, um arquivo ou uma variável de ambiente.

Ainda assim, se fosse viável trocar o binário para executar o trace, a visualização do código ficaria ainda pior, pois mesmo com a utilização da macro LOGTRACE, para cada trace vc teria que colocar um ifdef e um endif.

Lab C++ - Código, Dicas e Snippets

http://labcpp.com.br

Para ver esta conversa, acesse https://groups.google.com/d/msgid/ccppbrasil/CAKUebb_DkmmO_vwzTSbbDby67wvB2%2B4rS%2BTMrdV1vPfeqin8BQ%40mail.gmail.com.