TheXpert: Padrão é padrão, portanto, não há nada a ser incluído, de jeito nenhum. Se houver um erro, informe-o aos desenvolvedores. Não há outra maneira.
Se você não quiser fazer isso dessa forma, o RtlGetLastError é semelhante.
Sim, eu entendo as dicas desde a primeira vez, apenas os desenvolvedores de MQ também prestam atenção em nós, caso contrário, eles não codificam para ninguém e as pessoas sofrem.
Ao aplicar suas classes em meu código, deparei-me com o seguinte problema: se o tamanho da memória compartilhada for maior que 4096 bytes, memcpyX em CMemMapApi::Write / Read (linhas 219 e 231 em memmaplib.mqh) mostra "Access Violation". Você poderia me dizer "onde procurar" para "fazer" o memcpy ler blocos de memória maiores que 4kb?
Agradeço imensamente ao autor pelo trabalho realizado. Se o autor não se importar, incluirei essas duas classes em minha biblioteca de classes SCL.
Entretanto, há erros nas classes em termos de definição de tipos padrão da Microsoft que causam outros erros no algoritmo. Por exemplo, o tipo DWORD não é int, mas uint. Por causa disso, tive de revisar alguns algoritmos nas classes, mas não foi muito difícil.
Se, de acordo com a Microsoft, nos métodos em que DWORD < 0 for uma condição, haverá um aviso, porque DWORD não pode ser menor que 0. Isso não é essencial, é claro, especialmente porque você pode ajustar a lógica de alguns métodos. Em geral, gostei dessas duas classes :)
Não entendo muito bem como a segurança de thread é implementada? Suponhamos que vários processos escrevam e leiam ao mesmo tempo. Logicamente, deve haver algo como o Lockfile, mas não o encontrei na biblioteca. Ou isso já está implementado no nível do winapi?
Al_key: Não entendo muito bem como a segurança de thread é implementada? Suponhamos que vários processos escrevam e leiam ao mesmo tempo. Logicamente, deve haver algo como o Lockfile, mas não o encontrei na biblioteca. Ou isso já está implementado no nível do winapi?
A biblioteca não tem vinculação de seção porque, teoricamente, o código pode ser executado em processos diferentes.
Para login e uso do site MQL5.com, você deve ativar o uso de cookies.
Ative esta opção no seu navegador, caso contrário você não poderá fazer login.
Você entrou na conta. A autenticação de dois fatores foi desativada. Configure-a novamente e escaneie um novo código QR ou continue com a autenticação de dois fatores desativada.
Padrão é padrão, portanto, não há nada a ser incluído, de jeito nenhum. Se houver um erro, informe-o aos desenvolvedores. Não há outra maneira.
Na Bíblia padrão, a chamada é GetLastError.
mas deveria ser assim ::GetLastError.
Caso contrário, kernel32::GetLastError é um bug.
Como não corrigi-lo?
Como você não pode editá-lo?
Eu dei dicas, mostrei e escrevi.
#importar
int GetLastError(int )
---
e pronto, o contexto é livre.
Se você não quiser fazer isso dessa forma, o RtlGetLastError é semelhante.
Eu dei dicas, mostrei e escrevi.
#importar
int GetLastError(int )
---
e pronto, o contexto é livre.
Se você não quiser fazer isso dessa forma, o RtlGetLastError é semelhante.
você não quer fazer isso desta forma - RtlGetLastError - semelhante
Agradeço imensamente ao autor pelo trabalho realizado. Se o autor não se importar, incluirei essas duas classes em minha biblioteca de classes SCL.
Entretanto, há erros nas classes em termos de definição de tipos padrão da Microsoft que causam outros erros no algoritmo. Por exemplo, o tipo DWORD não é int, mas uint. Por causa disso, tive de revisar alguns algoritmos nas classes, mas não foi muito difícil.
_Konstantin_:
Por exemplo, o tipo DWORD não é int, mas uint.
Isso é suficiente para a chamada
Não entendo muito bem como a segurança de thread é implementada? Suponhamos que vários processos escrevam e leiam ao mesmo tempo. Logicamente, deve haver algo como o Lockfile, mas não o encontrei na biblioteca. Ou isso já está implementado no nível do winapi?
A biblioteca não tem vinculação de seção porque, teoricamente, o código pode ser executado em processos diferentes.
Para controlá-lo, use sua variante ou https://www.mql5.com/pt/code/1835.