Q: Reparei o header contém getters e setters + operators definidos, deixando os "métodos complicados" para implementação no .cpp. Devemos empregar este padrão daqui em diante? R: A ideia é que os .h de uma dada classe tenham as declarações da classe e que o .cpp tenham as implementações de métodos (especialmente os complicados). No entanto, os .h também podem ter métodos e funções (especialmente as que forem simples e inline). Em C++, ter classes distribuídas por pares de ficheiros com o mesmo nome da classe, embora não obrigatória, é muito conveniente e evita problemas de organização de código. |
Q: Adicionei um novo nó XXX_node à pasta "ast" e actualizei o método correspondente do_XXX_node na classe do visitor xml_writer. No entanto, o compilador não compila. R: Devido à estrutura do padrão de desenho Visitor, não é suficiente definir o método do_XXX_node apenas numa das classes concretas dos visitors (na directoria "targets"). É necessária a definição do método em todas as classes dos visitors, incluindo na superclasse basic_ast_visitor. |
Q: Quando adicionei o meu primeiro nó na pasta "ast", tive de propagar a alteração pelo postfix_writter, type_checker e xml_writter, adicionando a assinatura dos métodos do_*_node. De outra forma compilava com erros. É normal ou há alguma forma de ultrapassar isto? R: Sim, é normal: é uma consequência do padrão de desenho Visitor. |
Q: É necessário adicionar classes nós para representar comentário? R: Apenas existem nós para conceitos (semântica) da linguagem. Os comentários não existem, do ponto de vista de materialização sob a forma de código ou dados, logo não é necessário representá-los como elementos da árvore sintáctica do programa. |
Q: Posso adicionar nós ao compilador, mas que já existem na CDK? R: Apenas devem ser incluídos no compilador nós que não existam ainda na CDK. Definir nós com o mesmo significado dos da CDK é um erro de modelação. Não basta mudar o namespace: se o nó tem a mesma semântica do da CDK, então não deve existir no compilador. |
Q: Acrescentei um novo nó ao compilador. O novo nó tem o mesmo nome que um da CDK (mas está noutro namespace). Fiz mal? R: Se o novo nó, apesar de ter o mesmo nome que um da CDK, tiver uma semântica diferente (i.e., representa informação diferente), então pode ter sentido existir. |
Q: Qual é o motivo para as classes de tipos de dados não deverem existir na pasta "ast" do projecto? A CDK já tem nós como integer_node, double_node, etc. R: Os tipos de dados não correspondem a nós da árvore sintáctica, já que estão a outro nível, sendo instâncias da estrutura basic_type (CDK). Os nós integer_node, double_node, etc., não correspondem a tipos, mas sim a literais dos tipos correspondentes. |
Q: Existe a necessidade de criar uma classe pointer_node? R: O conceito de pointer_node (que corresponderia a um literal para o tipo ponteiro), não existe. A razão é que o único literal para ponteiros é 0 (zero), que é um literal inteiro e, como tal, representado por uma instância de integer_node. |
Q: O nil_node que está na CDK corresponde ao literal que pode ser aceite pelo tipo ponteiro? R: Este nó corresponde à ausência de um nó (padrão de desenho Null Object). Os literais de ponteiros não existem (0, o único literal possível para ponteiros, é um literal inteiro). |
Q: É preciso ser feita a distinção entre if-then-else e if-else? Representam a mesma ideia? R: Pode ser conveniente fazer a distinção entre os dois conceitos (apesar de, no fundo, representarem a mesma ideia), já que permite geração de código mais adaptada a cada um deles. |
Q: Relativamente aos conceitos if-then-else e if-else, tenho de os redefinir no compilador "zu"? R: Os nós correspondentes a este dois conceitos já estão definidos no compilador fornecido no repositório (CVS), sendo inteiramente apropriados para o "zu" (ou seja, a sua redefinição é desnecessária). |
Q: Gostaria de saber se, quando se declara uma função, posso definir o valor de retorno por omissão, ou se esse valor só pode ser especificado quando se trata de uma definição de função. R: O valor por omissão só é relevante quando se define a função, já que é apenas utilizado no corpo da função. |
Q: No ficheiro "postfix_writer.cpp" existe um comentário a dizer que "Zu doesn't have functions". No entanto, o manual de referência tem uma secção inteira acerca de funções. Existem funções? R: O material originalmente no CVS, embora corresponda ao compilador para a linguage Zu, é realmente o compilador para a linguagem Simple em todas as ocorrências da palavra "simple" foram indiscriminadamente substituídas por "zu". É, assim, natural que alguns comentários válidos para Simple não o sejam para Zu (isto pode ser visto como uma das necessidades de alteração do compilador de Simple para obter o compilador de Zu). |
Q: O evaluation_node já está definido no Simple. Qual é a sua função? R: Este nó serve para permitir usar expressões onde são esperadas entidades que não produzem valores. O nó permite descartar o resultado calculado por uma expressão (de acordo com o seu tipo), quando esse resultado não é útil (por exemplo, quando a expressão é usada como instrução). |