ecst

ECST

Experimental e trabalha em andamento C ++ 14 Multithread-Time-Time-Component-System-System apenas biblioteca.

Visão geral

O desenvolvimento bem-sucedido de aplicativos e jogos complexos em tempo real requer um sistema de gerenciamento de entidades flexível e eficiente. À medida que um projeto se torna mais complexo, é fundamental encontrar uma maneira elegante de compor objetos para evitar a repetição de código, melhorar a modularidade e abrir possibilidades de otimização poderosas.

O padrão arquitetônico do sistema de entidade-componente foi projetado para alcançar os benefícios acima mencionados, separando os dados da lógica.

• As entidades podem ser compostas de componentes pequenos, reutilizáveis ​​e genéricos.

• Os componentes podem ser armazenados em áreas de memória contíguas, melhorando assim a localidade de dados e a simpatia do cache.

• A lógica do aplicativo pode ser facilmente paralela e abstraída dos próprios objetos e de suas políticas de armazenamento.

• O estado do aplicativo pode ser serializado e compartilhado pela rede com menos esforço.

• Uma base de código mais modular, genérica e facilmente testável.

"ECST" foi desenvolvido como meu projeto de graduação do BCS.

---

Começando

• Construir instruções

• Exemplo de código

• Licença

---

Mais informações

• Tese de acompanhamento

• Deslizamentos

  • Nota: Estes estão acompanhando uma versão anterior da biblioteca foi a apresentada no C ++ agora 2016

---

Terminologia

• Entidades: definido por Adam Martin (ver tese) como "blocos de construção conceitual fundamental" de um sistema, que representa o OB-IJENT de aplicação concreta. Eles não têm dados ou lógica específicos do aplicativo.

• Componentes: pequenos tipos reutilizáveis ​​que compõem entidades. Novamente, citando Adam Martin em (ver tese) , um tipo de componente "rotula uma entidade como possuindo um aspecto específico". Os componentes armazenam dados, mas não contêm lógica.

• Sistemas: Fornecedores de lógica de implementação para entidades que possuem um conjunto específico de tipos de componentes.

• Paralelismo externo: termo usado no ECST, que define o conceito de executar vários sistemas que não dependem um do outro em paralelo. Seus detalhes de implementação serão analisados ​​no Capítulo 10 (consulte a tese) . Conceitualmente, um gráfico acíclico direcionado implícito é criado em tempo de compilação, graças ao conhecimento das dependências do sistema. A execução da DAG implícita é tratada por um tipo de agendador do sistema especificado durante a definição de configurações.

• Paralelismo interno: Outros que executando sistemas separados em paralelo, o ECST suporta dividir um único sistema em várias subtares, que podem ser executadas em threads separados. Muitos sistemas, como os que representam comutações funcionalmente puras, não contêm efeitos colaterais que modificam seu próprio estado ou que definem interações entre as entidades assinadas: esses são exemplos excelentes de cálculos "embaraçosamente paralelos".

---

Perguntas frequentes

• "Onde posso encontrar documentação para a API?"

  • Veja a edição nº 10.

• "Podemos ter componentes que não são construtíveis padrão?"

  • Isso surgiu antes no passado. A resposta é não - veja a edição 8.

• "Estou tentando ler/escrever de/para o meu componente, mas estou recebendo um erro de compilação. O que está acontecendo? "

  • Os sistemas precisam saber no tempo de compilação quais tipos de componentes eles acessarão e como (somente leitura ou acesso ao acesso) . Isso deve ser especificado ao definir assinaturas do sistema . Veja a edição 4 para obter mais informações.

• "É possível iterar sobre os componentes anexados às entidades, sem estar dentro da função de processo de um sistema?"

  • Veja a edição nº 9.

• "Como controlar se meu sistema é executado em paralelo ou como um único thread? "

  • O paralelismo interno em todo o contexto deve ser ativado chamando allow_inner_parallelism () para permitir que os sistemas sejam divididos em várias submarcas . As estratégias de paralelismo interno podem ser personalizadas e compostas em tempo de compilação para sistemas específicos, durante a definição de assinatura do sistema .

• "Qual é a diferença entre tornar meu sistema um thread único vs desativar o paralelismo interior?"

  • Desativar o paralelismo interno impede que todos os sistemas sejam divididos em várias subtarefas , independentemente de sua estratégia de paralelismo interno. A criação de um sistema único impede que apenas esse sistema seja dividido em várias subtarefas : isso pode ser necessário para sistemas que mantêm estruturas de dados ou que dependam de iterar em todas as entidades no mesmo thread.