Remoção de Hints e Warning do ACBr

[Daniel Simoes]

OK... já no SVN... obrigado mais uma vez...

[Waldir Paim]

Daniel,

Segue novas units para avaliação.

As alterações é apenas uma proposta mas procurei manter fielmente a funcionalidade anterior.

Com as alterações nas unit ACBrDFeConfiguracoes e ACBrNFeConfiguracoes zerei os avisos de mais um projeto.

ACBrDFeConfiguracoes.pas

ACBrNFeConfiguracoes.pas

Como já havia dito, só ficou avisos do tipo W0157 e W1058 e outros avisos das Units da pasta ACBrSerial.

Nessa pasta ACBrSerial deve enviar algumas correções para remover os avisos do tipo W1000 e com isso encerro minha tarefa.

[Daniel Simoes]

Mesmo com a adição de "Reintroduce" como está nos fontes atuais... o Delphi acusa um warning ? Se SIM, qual é a msg ?

    procedure Assign(DeGeralConf: TGeralConf); reintroduce; virtual;

PS: Noto que você não tem muita preocupação com a edentação dos fontes... (não vejo um padrão, e não está nos semelhate ao dos fontes atuais..)

No inicio do ACBr usávamos 3 espaços.. atualmente tentamos seguir as recomendações do Delphi Team

[Waldir Paim]

Daniel,

As mensagens são essas.

Eu não alterei a edentação evito até alterar a estrutura da unit para não gerar muitas diferenças.

Segue abaixo um trecho do log apresentado.

Citar

 [dcc32 Warning] ACBrNFeConfiguracoes.pas(66): W1010 Method 'Assign' hides virtual method of base type 'TGeralConf'
 [dcc32 Warning] ACBrNFeConfiguracoes.pas(107): W1010 Method 'Assign' hides virtual method of base type 'TArquivosConf'
 [dcc32 Warning] ACBrNFeConfiguracoes.pas(138): W1010 Method 'Assign' hides virtual method of base type 'TConfiguracoes

 

Me desculpe pela falta de atenção,

Realmente não me detive a edentação das partes que escrevi na proposta, um dos motivos seria esse mesmo se tratar de um código a ser analisado e sem o devido acabamento esperado.

No meu código final utilizo a endentação automática que aciono pela tecla Crtl+W do plugin http://www.cnpack.org/index.php?lang=en

Mas me atentarei ao fato nas oportunidades.

  

[Daniel Simoes]

Segundo as informações dessa página...

http://docwiki.embarcadero.com/RADStudio/Seattle/en/W1010_Method_'%25s'_hides_virtual_method_of_base_type_'%25s'_%28Delphi%29

o "Reintroduce" é uma das maneiras de suprimir essa Warning...

Citar

You could add the reintroduce directive to the procedure declaration to cause the warning to be silenced for that particular method. The reintroduce keyword instructs the Delphi compiler to hide the respective method and suppress the warning, because it is unlikely to override a method of the same name from a base class that is not virtual or dynamic.

Mas no nosso caso, o método redeclarado com o "reintroduce", tem parâmetros diferentes, do original...  Será que falta uma declaração de "overload" ?

[Waldir Paim]

@Daniel Simoes

Vou tentar remover os avisos e manter o código original.

[Waldir Paim]

Segue unit com alteração para manter o código original e remover os avisos.

Utilizei o  reintroduce  para conseguir suprimir os avisos.

Só foi preciso alteração em uma das duas units.

ACBrNFeConfiguracoes.pas

[Daniel Simoes]

Bem melhor... obrigado pela ajuda Waldir... já está no SVN...

[Waldir Paim]

@Daniel Simoes

Dessa forma apenas um de meus projetos apresenta os avisos decorrente do ACBr.

Como já tive a oportunidade em outros posts a grande maioria dos avisos são do tipo W1000 na pasta ACBrSerial.

Posso incluir ele na minha lista que já possui os W0157 e W1058 ou prefere que continuemos a tarefa até a extinção total do mesmo?

Digo dele pois não terei tempo para dar continuidade nos avisos da minha lista de mensagens ignoradas.

Desde já agradeço a oportunidade e a confiança de poder contribuir um pouco com esse projeto tão valioso para muitos desenvolvedores. 

 

PS: Poderia por favor re-enviar a atualização do ultimo(s) commit(s), o SVN deve ter revertido alguma coisa lá.

[Daniel Simoes]

Fiquei curioso a respeito das Warnings "W1000 Symbol '%s' is deprecated"... não deve ser difícil eliminá-las...
Mas fique a vontade de analisá-las quando tiver um tempo livre...

Ainda lhe devo uma resposta a respeito das modificações no TEFD...

Foi muito bom contar com a sua ajuda... essas Warnings me incomodavam a um bom tempo... (e ainda sobrou vários de convrsão de String)

O SVN já está de volta....

[hleorj]

Quando de precisar de outra nota 8  , estaremos sempre aqui.

[Waldir Paim]

@Daniel Simoes

Vamos dar fim então nos avisos W1000.

Pensando aqui acredito que em vez de encher o código fonte de $IFDEF poderemos agir da seguinte forma:

Na função abaixo ela apresenta o aviso W1000, mas se incluirmos ela ou uma variação dela na ACBrUtil.pas já removeremos muitos dos alertas apresentados

function LeftStr(const AText: AnsiString; const ACount: Integer): AnsiString; overload;
begin
  Result := Copy(AText, 1, ACount);
end;

Uma sugestão para ACBrUtil seria:

function LeftStrExt(const AText: AnsiString; const ACount: Integer): AnsiString;
begin
  Result := {$IFDEF DELPHIXE4_UP}AnsiStrings.{$ENDIF}LeftStr(AText, 1, ACount);
end;

Com isso evitamos ambiguidade de nomes e mantemos o código limpo de $IFDEF da vida.

 

@hleorj

Sei que sua nota 8 não passou de uma brincadeira, então não leve a mau meu texto abaixo.

Já que você é da terra do samba, acostumado com nota 10, tenho aqui um exemplo que ocorreu ai na cidade maravilhosa e foi apresentado pela http://www.rio-carnival.net/carnaval/escola-de-samba/unidos-da-tijuca.php que conseguiu mostrar para o mundo que gente do mato "grosso", não da rocha nem sem cultura mas sim com muita coisa boa para mostrar, levou o nome da nossa cidade http://www.sorriso.mt.gov.br/ e região mostrando um pouco de nossa cultura e todo potencial existente aqui na nossa região.

Sei também que nem sempre uma nota 10 mostra o quão bom é o sujeito então assim eu muitos saíram do sambódromo com o sentimento de dever cumprido e de alma lavada em mostrar que podemos fazer e ser um pouco melhor a cada dia.

Um forte abraço e uma nota 10 para você.

 

[hleorj]

 

@Waldir Paim, sempre será uma brincadeira.. pois eu estou sempre de braços abertos para receber e dar sem pedir nada em troca.

Vida Longa , Grande Paim

[Daniel Simoes]

Waldir... se se tratar apenas do "LeftStr"... acho que o mais simples é substitui-lo por "Copy"

[Waldir Paim]

@Daniel Simoes

Vou te mandar uma proposta como dito no post anterior.

Como você propôs trocar por copy geraria mais W0157 e W1058 pois precisaria de uma conversão em muitos casos para AnsiString.

Segue anexo, compactei pois já lotou o espaço disponível para inclusão de arquivos.

ACBrSerial.zip

ACBrUtil.pas

[Daniel Simoes]

Oi Waldir

Estive pesquisando sobre LeftStr/RightStr, e seus derivados... 

Vi que você fez um grande trabalho, modificando todas essas Units... mas reluto em inserir uma nova versão para LeftStr e RightStr... Isso porque sempre receberemos códigos de outros usuários, que não terão conhecimento delas...

Acredito que o COPY seja a melhor opção... e pelo que pesquisei, o COPY tem um tratamento interno para usar AnsiString ou String

http://stackoverflow.com/questions/6056160/is-there-an-ansi-version-for-copy

Veja que o próprio Delphi, usa o Copy com AnsiString, no método LeftBStr

function LeftBStr(const AText: AnsiString; const AByteCount: Integer): AnsiString;
begin
  Result := Copy(AText, 1, AByteCount);
end;

 

[Waldir Paim]

@Daniel Simoes

Citar

mas reluto em inserir uma nova versão para LeftStr e RightStr... Isso porque sempre receberemos códigos de outros usuários, que não terão conhecimento delas...

Nesse ponto concordo contigo.

Citar

Acredito que o COPY seja a melhor opção... e pelo que pesquisei, o COPY tem um tratamento interno para usar AnsiString ou String

Acredito que usar o Copy teremos que incluir o terceiro parâmetro dele e pra mim a leitura fica prejudicada alem de gerar novos avisos pois o retorno dele é um string conforme descrito aqui http://docwiki.embarcadero.com/Libraries/XE7/en/System.Copy:

Citar

function Copy(S: <string or dynamic array>; Index: Integer; Count: Integer): string

 No meu ponto de vista a Embarcadero está decidida em separar o código Ansi do código Unicode.

Citar

Warning: LeftBStr is deprecated. Please use AnsiStrings.

Eu poderia enviar uma proposta de código com uso das diretivas que mesmo tornando o código mais sujo ele mantem a estrutura atual do código e separa o código conforme indica caminhar os novos compiladores.

 

[Daniel Simoes]

Solicitei a opinião de outros desenvolvedores do ACBr...

Como não sou usuário (ativo) do Delphi, fico pouco a vontade para tomar uma decisão dessas...

[EMBarbosa]

Pessoal, sobre esses warnings e a função StrUtils.LeftBStr. Custei pra entender que estavam falando de LeftBStr e não LeftStr.

Minha sugestão é fazer o mesmo que fizemos anteriormente e colocar o IFDEF para o XE4.

{$IFDEF DELPHIXE4_UP}AnsiStrings.{$ENDIF}LeftBStr( xxx

Isso vai remover os warnings que só aparecem após a versão XE4 de LeftBStr, não vai criar nenhuma imcompatibilidade nem vai alterar o objetivo da função chamada.
Na pior das hipóteses, ganhamos mais tempo pra poder analisar cada código.
Outra opção seria substituir por LeftBStr por LeftStr.

Mas acho que isso requer um pouco mais de cautela e precisaria avaliar cada linha onde o código está inserido:

Qual o objetivo de LeftBStr? É pegar um determinado número de caracteres? É pegar um determinado número de bytes?

Se for número de caracteres, LeftStr serve independente de ser passado uma string ou AnsiString. Mas se for bytes, apenas LeftBStr serve.

[Waldir Paim]

@EMBarbosa

Eu resolvi boa parte dos warnings remanescentes aplicado essa correção no ACBr.inc.

{$IFDEF DELPHI12_UP}
  {$DEFINE HAS_CHARINSET}
{$ENDIF}
{$IFDEF DELPHI15_UP}
  {$DEFINE HAS_FORMATSETTINGS}
  {$DEFINE HAS_REGEXPR}
  {$WARN IMPLICIT_STRING_CAST OFF}
  {$WARN IMPLICIT_STRING_CAST_LOSS OFF}
  {$WARN SYMBOL_DEPRECATED OFF}
{$ENDIF}

Desativei com o bloco acima as três ultimas definições que mais me causavam transtornos.

Vou adicionar o arquivo aqui caso tenha interesse de incluir no repositório e também resolver para os outros colegas da mesma forma.

ACBr.inc

Editado 1 Agosto, 2016 por Waldir Paim

[EMBarbosa]

6 horas atrás, Waldir Paim disse:

@EMBarbosa

Eu resolvi boa parte dos warnings remanescentes aplicado essa correção no ACBr.inc.

{$IFDEF DELPHI12_UP}
  {$DEFINE HAS_CHARINSET}
{$ENDIF}
{$IFDEF DELPHI15_UP}
  {$DEFINE HAS_FORMATSETTINGS}
  {$DEFINE HAS_REGEXPR}
  {$WARN IMPLICIT_STRING_CAST OFF}
  {$WARN IMPLICIT_STRING_CAST_LOSS OFF}
  {$WARN SYMBOL_DEPRECATED OFF}
{$ENDIF}

Desativei com o bloco acima as três ultimas definições que mais me causavam transtornos.

Vou adicionar o arquivo aqui caso tenha interesse de incluir no repositório e também resolver para os outros colegas da mesma forma.

ACBr.inc

Não... Esses warnings daí acho melhor serem analisados e corrigidos do que apenas desligados. Principalmente o último.

[Waldir Paim]

@EMBarbosa

No meu ponto de vista deixar eles ali só complica mais do que ajuda, hora visto que os voluntários não se manifestam e não se pronunciam para sanar o problema.

Desligando eles a gente corrige inúmeros outros que não estão visíveis, eu mesmo estou preparando um pacote de unit com outras correções que consigo ver sem eles nos log.

[EMBarbosa]

2 horas atrás, Waldir Paim disse:

@EMBarbosa

No meu ponto de vista deixar eles ali só complica mais do que ajuda, hora visto que os voluntários não se manifestam e não se pronunciam para sanar o problema.

Desligando eles a gente corrige inúmeros outros que não estão visíveis, eu mesmo estou preparando um pacote de unit com outras correções que consigo ver sem eles nos log.

Entendo, mas não é o correto a se fazer num código em produção.

Você pode utilizar o recurso para diminuir os avisos. Mas daí a enviar esse arquivo ao SVN seria imprudência.

[Waldir Paim]

Citar

Entendo, mas não é o correto a se fazer num código em produção.

Você pode utilizar o recurso para diminuir os avisos. Mas daí a enviar esse arquivo ao SVN seria imprudência.

Cada um tem seu ponto de vista, mas eu não fui muito longe para chegar nessa conclusão.

veja:

Citar

..

//old Delphi does not have MSWINDOWS define.
{$IFDEF WIN32}
  {$IFNDEF MSWINDOWS}
    {$DEFINE MSWINDOWS}
  {$ENDIF}
{$ENDIF}

{$IFDEF UNICODE}
  {$WARN IMPLICIT_STRING_CAST OFF}
  {$WARN IMPLICIT_STRING_CAST_LOSS OFF}
{$ENDIF}

unit blcksock;

interface

uses
  SysUtils, Classes,
  synafpc,
  synsock, synautil, synacode, synaip
{$IFDEF CIL}
  ,System.Net
  ,System.Net.Sockets
  ,System.Text
{$ENDIF}
  ;

...

 

Faz um pesquisa ai nos fontes, vai encontrar alguns exemplo de uso.

 

Citar

{$I ACBr_jedi.inc} // load common compiler defines

{$Q-}
{$R-}
{$H+}

{$IFDEF UNICODE}
  {$WARN IMPLICIT_STRING_CAST OFF}
  {$WARN IMPLICIT_STRING_CAST_LOSS OFF}
  {$WARN SUSPICIOUS_TYPECAST OFF}
{$ENDIF}

unit synautil;

interface

uses

Muito provavelmente esse pessoal tem seus motivos para usar.

 

[EMBarbosa]

2 horas atrás, Waldir Paim disse:

Cada um tem seu ponto de vista, mas eu não fui muito longe para chegar nessa conclusão.

veja:

 

Faz um pesquisa ai nos fontes, vai encontrar alguns exemplo de uso.

 

Muito provavelmente esse pessoal tem seus motivos para usar.

 

Sim. Eu sei os motivos. E não são um bons motivos para subir isso como uma alteração global no ACBr.

Os warnings existem por um motivo, simplesmente desligá-los globalmente sem entender o que se está fazendo, como eu disse antes, é imprudência.