Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas

Aplicações e Serviços de dados - Apostilas - Informática, Notas de estudo de Informática

Apostilas de Informática sobre Eliminação da diferença de impedância entre aplicações e serviços de dados como emissão de relatórios, análise e replicação oferecidos como parte do produto SQL Server aumentando a abstração do nível lógico para o nível conceitual.

Tipologia: Notas de estudo

2013

Compartilhado em 28/08/2013

Garoto
Garoto 🇪🇸

4.6

(89)

446 documentos

1 / 11

Documentos relacionados


Pré-visualização parcial do texto

Baixe Aplicações e Serviços de dados - Apostilas - Informática e outras Notas de estudo em PDF para Informática, somente na Docsity! Aplica-se a: • ADO.NET • .NET Language Integrated Query (LINQ) • SQL Server Resumo: Eliminar a diferença de impedância entre aplicações e serviços de dados como emissão de relatórios, análise e replicação oferecidos como parte do produto SQL Server aumentando a abstração do nível lógico (relacional) para o nível conceitual (entidade). As pessoas que apenas utilizam o software não reconhecem a dificuldade que é escrevê-lo. O design e o desenvolvimento são as partes divertidas. A parte difícil é fazer com que ele seja executado corretamente (e com a rapidez necessária). Para o programador é como se uma refeição começasse com um delicioso cheesecake duplo de café com creme e terminasse com creme de espinafre. O motivo pelo qual dizemos que a programação é uma arte, e não uma ciência ou disciplina da engenharia, é porque ainda não conseguimos dividi-la em suas etapas constituintes e mecanizá-la. Após fazermos isso com êxito, uma nova escala de possibilidades surge: programas que escrevem programas de linguagens de projeto orientadas a pessoas (PODL), programas para provar a correção do programa e para analisar e suportar a consulta semântica. Até esse ponto, porém, a programação continua sendo uma arte ou pelo menos é isso o que a sabedoria convencional diz. Mas assim como acontece com grande parte da sabedoria convencional, essa analogia não resiste a um exame mais detalhado. A criação de um programa (e já fazemos isso há mais de 20 anos) não é, na verdade, nada parecido com arte – pelo menos não a arte de escrever ficção (e também já fazemos isso há mais de 20 anos). Vou ilustrar essa questão com estes dois fragmentos de programa e prosa. Este primeiro exemplo é parte de um analisador léxico para analisar o Visual C++® 7.1. Ele é assim: if ( index >= TokenID::lastKeyword() ) { string token = tokenString( index ); if (( isdigit( token[ 0 ] )) || ( token[0] == ‘-’ )) { #ifdef TELL_ME display( "!! TokenSet::tokenIdentify: ", "a literal digit: ", token ); #endif return TokenID::TK_Literal; } } Este segundo exemplo é a abertura de um conto que escrevi há cerca de 27 anos, quando morava em Tucson, no Arizona, lecionava e escrevia prosa: We were her pride of 10, Miss Steward named us: the Prodigal, Phoenix, Benjamin, and perspicacious, pacific Suzanne. Hush, child. Benjamin, be still, Miss Steward commanded him gently. People are never just. Ambos os exemplos tiveram uma criação intensiva, ou seja, eu passei muito tempo antes criando a arquitetura geral do trabalho, e os fragmentos refletem esse esforço de criação. O programa tem uma falha de desempenho – eu recupero a entrada de cadeia de caracteres na tabela de cadeia de caracteres associada por valor e não por ponteiro. Se o código precisasse ser produzido, ele exigiria uma revisão óbvia. Isso não tem nada a ver com a correção, mas apenas com o desempenho. Para um programa com código fonte pequeno, a diferença de velocidade não é mensurável e, assim, eu preferi a sintaxe de objeto mais limpa e lenta, uma vez que não gosto dos tokens de manipulação de ponteiros da C/C++. Embora minha prosa não tenha atraído milhões de leitores, aqueles que a leram apreciaram a obra com sua trama emocional sob uma rigorosa estrutura simbólica. Aqueles que não apreciam a prosa tradicional acharam que ela era enganosa, porque não há nada de funcional nela. A finalidade da arte é projetar sentimentos e a realidade de uma vida privada subjetiva em meio aos eventos públicos em um meio plástico em particular – no caso da prosa, as palavras. Obviamente, não há valor nisso, não como o valor intrínseco de um programa. Eu gosto do processo de criação de um programa, e gosto de experimentar o modo como as diferentes partes interagem. Eu gosto de definir abstrações ou famílias de abstrações. Eu as considero meu elenco de personagens. Gosto também de criar interfaces, porque representam as coisas que meus personagens fazem. E é assim como eu realmente escrevo os programas. Eu não gosto de escrever expressões e declarações. Eu gostaria que tivéssemos uma linguagem de programação simbólica na qual eu pensasse melhor e que pudesse memorizar. Honestamente, eu não consigo manter a clareza de expressões e aninhamentos intercalados. Embora eu consiga manter oito seções separadas de texto em minha cabeça e as compare e as ecoe, eu não consigo dar sentido a um programa além das classes que crio e suas interfaces. No excelente artigo de John Markoff sobre a indústria do PC, What the Dormouse Said, ele declara que o objetivo dos visionários iniciais - colocar um computador à disposição de cada pessoa - foi concretizado. Mas ele está errado. Esse objetivo foi concretizado apenas pela metade. O que há de bom em todo esse poder da computação se uma pessoa não pode programá-la? Ainda não realizamos seu sonho porque ainda não descobrimos como tornar a programação uma arte para que todos possam compartilhá-la. Até lá, a programação continua não sendo uma disciplina da ciência, nem um domínio da arte. Por enquanto, a programação é pouco mais do que uma nova alquimia. Ninguém realmente a entende e ninguém ainda transformou uma especificação em ouro verdadeiro. Stanley B. Lippman começou a trabalhar na linguagem C++ junto com seu criador, Bjarne Stroustrup, em1984, na Bell Laboratories. Mais tarde, Stan trabalhou em animação de filmes na Disney e na DreamWorks e atuou como diretor técnico de software no filme Fantasia 2000. Desde então, tem trabalhado como consultor condecorado da JPL e arquiteto na equipe do Visual C++ da Microsoft. P Quando gero uma DLL com suporte de automação usando o Visual C++® 6.0, são geradas algumas funções de registro, mas não para cancelar o registro da minha DLL. Escrevi um DllUnregisterServer que tem esta aparência: STDAPI DllUnregisterServer(void) { AFX_MANAGE_STATE(AfxGetStaticModuleState()); registro de sua DLL. Isso mesmo, o IRegistrar é inteligente o bastante para cancelar o registro. O IRegistrar não está documentado oficialmente em lugar algum que eu pudesse encontrar, mas o código está aqui (encontre-o em atliface.h). Se ainda não está usando o IRegistrar para registrar e cancelar o registro de suas COM DLLs, você deveria mesmo experimentar — isso vai poupar-lhe muito trabalho. Para obter detalhes consulte meu artigo no exemplar de novembro de 1999 . P Meu aplicativo principal tem um menu normal com um submenu de comandos Editar (Recortar, Copiar, Colar etc.). Gostaria de exibir o submenu Editar como um menu de contexto quando o usuário clica com o botão direito na janela principal. O problema é como obter esse submenu a partir do menu principal. Parece que não existe nenhuma ID de comando associada a um submenu. Posso usar o índice começando em zero, mas devido à personalização o menu Editar nem sempre será o segundo menu. Não posso procurar o texto "Editar" porque damos suporte a múltiplos idiomas e a palavra verdadeira pode mudar. Como posso localizar o submenu Editar em todos esses casos? Brian Manlin R Bem, deixe-me salientar que o menu Editar deveria ser o segundo submenu, se você tiver um. As diretrizes de GUI do Official Windows® necessitam que os três primeiros itens de menu sejam Arquivo, Editar, Exibir, nessa ordem — para receberem suporte. Consulte Windows Interface Guidelines for Software Design (em inglês) (Microsoft Press®, 1995). Dito isso, posso ajudá-lo a encontrar seu submenu Editar ou qualquer outro submenu desejado. Você está correto: não existe ID de comando para um submenu. Isso acontece porque internamente o Windows usa o campo de ID de comando para armazenar o HMENU de submenu, se o item de menu é um submenu. Não se preocupe, supondo que o submenu sempre mantenha um comando específico (por exemplo Editar | Recortar) e supondo que o comando sempre tenha a mesma ID (por exemplo, ID_EDIT_CUT), é bem fácil escrever uma função que localize o submenu que contém um determinado comando. A Figura 2 mostra o código. CSubmenuFinder atua de fato como um namespace para armazenar a função estática FindCommandID, que chama a si mesma recursivamente para uma busca detalhada no menu e em todos os submenus por um item cuja ID de comando corresponda à procura. Esse segmento busca no menu principal um submenu que contenha um item de menu cuja ID de comando seja ID_EDIT_CUT e retorna o submenu, se localizado. Escrevi um pequeno programa denominado EdMenu para testar o CSubmenuFinder. O EdMenu usa o código anterior para manipular WM_CONTEXTMENU de modo a exibir um submenu editar exatamente igual ao do menu principal, quando o usuário clica com o botão direito na janela principal. Acredite em mim quando digo que o CSubmenuFinder localiza o menu editar onde quer que ele esteja dentro do menu principal. Na verdade, eu o testei quando mudei temporariamente o menu Editar para adiante do menu Exibir em uma de minhas criações. Experimente você mesmo, faça download da fonte. P Como converto MFC CString em String em C++ gerenciado? Por exemplo, tenho o seguinte código em C++: void GetString(CString& msg) { msg = // build a string } Como posso reescrever essa função usando C++ gerenciado e substituindo o parâmetro CString por uma String gerenciada? O problema é que GetString muda a CString do chamador e eu quero fazer a mesma coisa usando uma String gerenciada. Sumit Prakash R Bem, a resposta depende de você estar usando a nova sintaxe C++/CLI ou as antigas extensões gerenciadas. Os dois tipos de sintaxe podem ser confusos, mas não tenha medo, estou aqui para resolver sua confusão de códigos. Vamos começar pela nova sintaxe, pois estamos em 2006. O truque para acertar a sintaxe é lembrar de duas coisas. Primeiro, em C++/CLI, os objetos gerenciados usam chapéus. Assim, CString torna-se String^. Segundo, lembre-se de que o equivalente gerenciado à referência (&) é a referência de rastreamento, que em C++/CLI é %. Sei, você mal pode enfiar ^ em seu cérebro, mas, com alguma prática, % também logo vai parecer normal. Então, as novas funções ficam assim: // using C++/CLI void GetString(String^% msg) { msg = // build a string } Isso faz sentido? Para mostrar que funciona de fato, escrevi um pequeno programa strnet.cpp (veja a Figura 3). Ele implementa duas classes, CFoo1 e CFoo2, cada uma com um membro GetName. A primeira usa CString& e a segunda usa String^%. Se você compilar e executar esse programa (usando /clr é claro), verá que nos dois casos — o que usa CString e o que usa String — o objeto passado (nativo ou gerenciado) é modificado pela função de membro. Por falar nisso, sempre use uma referência de rastreamento (%) para objetos gerenciados, em vez de usar uma referência nativa (&, que também fará compilação) porque a referência de rastreamento rastreará a referência mesmo se o coletor de lixo mover o objeto dentro de sua pilha gerenciada. Se você está usando a sintaxe no estilo antigo (/clr:oldSyntax), como pode ainda viver na Idade Média? Nada tema, você pode usar uma referência mesmo que seja antiga. Se você está usando extensões gerenciadas, lembre-se apenas de que os objetos gerenciados são __gc pointers e assim CString transforma-se em String __gc *. E, como o compilador já sabe que String é um tipo gerenciado, você nem vai precisar do __gc; um ponteiro simples (*) bastará. A referência é a mesma. Então, a conversão da sintaxe de estilo antigo fica assim: // __gc omitted void GetString(String*& msg) { msg = // build a string } Entendeu? Faz todo o sentido. Sempre que tiver dificuldade em descobrir a sintaxe C++, a solução será voltar ao básico. P Recentemente gerei um aplicativo de console CLR com o Visual Studio® 2005. Reparei que o Visual Studio criou uma função principal como esta: int main(array<System::String ^> ^args) { ... return 0; } Isso parece ser uma mudança da antiga argc/argv com que estou familiarizado no C/C++. Quando tentei acessar args[0], pensando que seria o nome do arquivo (como em C/C++), descobri que args[0] não é o nome do arquivo, mas o primeiro parâmetro da linha de comando. O que aconteceu com o nome do arquivo? Pode me explicar a razão desta mudança? Jason Landrew R Ah, o mundo moderno em que nos divertimos! Nada é igual ao que era, não é verdade? Vivemos com argc/argv desde que a linguagem C foi desenvolvida em 1972 e agora as pessoas de Redmond vieram e mudaram tudo. Talvez eles quisessem ter certeza de que todos saberiam como usar a nova matriz de sintaxe. Uma razão para a nova sintaxe é gerar um programa que compile com /clr:safe, que é a última palavra em segurança de código. É como trancar seu programa dentro de uma sala limpa — um daqueles ambientes estéreis cheios de equipamentos de cromo, em que é preciso entrar através de uma câmara de vácuo de pressão negativa, usando capacete e botas especiais. Quando você aciona o comutador /clr:safe, o compilador impõe todos os tipos de restrições trabalhosas. Não é possível usar tipos nativos. Não é possível usar globais. Você não pode chamar funções não gerenciadas. Em resumo, você não pode fazer nada divertido. E por que você se sujeitaria a tanto sofrimento? Para ter certeza total e absoluta de que o código está seguro. Em termos técnicos, /clr:safe gera código "verificável", o que significa que o CLR (Common Language Runtime) pode verificar que seu código não viola configurações de segurança, tais como tentar acessar um arquivo quando as configurações de segurança do usuário não permitem. Um dos muitos itens da lista proibida do /clr:safe é ponteiros nativos — ou seja, ponteiros. ("Nativo" é redundante, pois não se pode ter um ponteiro de tipo gerenciado.) Como os ponteiros não são permitidos com o /clr:safe, a antiga declaração argv simplesmente não funciona. Assim, as pessoas de Redmond mudaram a declaração para usar uma matriz String^. E como as matrizes conhecem seu comprimento, não há necessidade de argc. A biblioteca de tempo de execução proporciona o código de inicialização apropriado para criar e inicializar a matriz de arg antes de chamar sua função principal. Se você não planeja usar /clr:safe, sempre é possível escrever um principal que use a antiga assinatura argc/argv . Isso explica o motivo de se usar uma matriz gerenciada, mas e o args[0], por que ele é o parâmetro do primeiro comando e não o nome do arquivo? Não posso falar pelas pessoas de Redmond, mas talvez tenham achado que faria mais sentido omitir o nome do arquivo, talvez pensassem que você não precisaria disso. De qualquer modo, não importa muito porque é fácil obter o nome do arquivo. Tenho certeza de que existem muitos modos de fazer isso, mas o mais óbvio e centrado em CLR (compatível com /clr:safe) em que posso pensar é usar a classe de System::Environment. Ela apresenta o seguinte método: static array<String^>^ GetCommandLineArgs () Ao contrário do parâmetro args fornecido para o método principal, a matriz retornada por Environment::GetCommandLineArgs na verdade começa com o nome do arquivo executável. Finalmente, por que você desejaria saber o nome de seu próprio arquivo EXE? Afinal de contas, se você está escrevendo o programa, supostamente sabe como ele se chama. Um motivo seria gerar uma mensagem de ajuda que contenha o nome do programa, sem codificá-lo. A mensagem de ajuda poderia ser mais ou menos assim: FooFile -- Turns every word in your file to "foo" Os eventos mostrados acima são eventos dos próprios componentes da biblioteca .NET Framework. Veja o código para processar o evento Click do botão: Código Verificável Todo programa criado pelo compilador VB.NET e também a maioria dos programas criados pelo compilador C# é dito "verificável". Isto quer dizer que o compilador JIT pode, em tempo de execução/compilação verificar e garantir que o programa não faça nenhuma operação que possa comprometer a segurança e integridade do sistema. Pode parecer estranho, mas existem instruções MSIL capazes de abrir brechas na segurança do sistema, como por exemplo, para manuseio direto de ponteiros ou manuseio da pilha da CPU. Estas instruções são necessárias em alguns casos, como por exemplo para que a própria biblioteca chame a API do Windows. Programas que contem estas instruções são ditos "não-verificáveis". Evidentemente é necessário um privilégio especial de segurança para rodar programas não-verificáveis. O compilador C++ do Visual Studio 2002 sempre gera código não-verificável, o que é sem dúvida uma deficiência. Já o Visual Studio 2003 pode gerar código verificável, desde que se façam alguns ajustes de compilação. Criar código verificável exige uma seqüência de ajustes, documentada sob o tópico "Producing Verifiable Components with Managed Extensions for C++": Conclusão O C++ foi significativamente melhorado no Visual Studio .NET 2003 e com certeza agradará os seus entusiastas, tanto com relação ao uso de recursos RAD como à criação de código verificável.
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved